On 3/2/21 10:16 AM, Björn Töpel wrote:
On 2021-03-02 10:13, Daniel Borkmann wrote:
On 3/2/21 9:05 AM, Björn Töpel wrote:
On 2021-03-01 17:10, Toke Høiland-Jørgensen wrote:
Björn Töpel <bjorn.to...@gmail.com> writes:
From: Björn Töpel <bjorn.to...@intel.com>
Now that the AF_XDP rings have load-acquire/store-release semantics,
move libbpf to that as well.
The library-internal libbpf_smp_{load_acquire,store_release} are only
valid for 32-bit words on ARM64.
Also, remove the barriers that are no longer in use.
So what happens if an updated libbpf is paired with an older kernel (or
vice versa)?
"This is fine." ;-) This was briefly discussed in [1], outlined by the
previous commit!
...even on POWER.
Could you put a summary or quote of that discussion on 'why it is okay and does
not
cause /forward or backward/ compat issues with user space' directly into patch
1's
commit message?
I feel just referring to a link is probably less suitable in this case as it
should
rather be part of the commit message that contains the justification on why it
is
waterproof - at least it feels that specific area may be a bit
under-documented, so
having it as direct part certainly doesn't hurt.
I agree; It's enough in the weed as it is already.
I wonder if it's possible to cook a LKMM litmus test for this...?
That would be amazing! :-)
(Another option which can be done independently could be to update [0] with
outlining a
pairing scenario as we have here describing the forward/backward compatibility
on the
barriers used, I think that would be quite useful as well.)
[0] Documentation/memory-barriers.txt
Would also be great to get Will's ACK on that when you have a v2. :)
Yup! :-)
Björn
Thanks,
Daniel
[1] https://lore.kernel.org/bpf/20200316184423.GA14143@willie-the-truck/
