lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 3 Mar 2021 15:39:32 +0000 From: Will Deacon <will@...nel.org> To: Daniel Borkmann <daniel@...earbox.net> Cc: Björn Töpel <bjorn.topel@...el.com>, Toke Høiland-Jørgensen <toke@...hat.com>, Björn Töpel <bjorn.topel@...il.com>, ast@...nel.org, netdev@...r.kernel.org, bpf@...r.kernel.org, magnus.karlsson@...el.com, jonathan.lemon@...il.com, maximmi@...dia.com, andrii@...nel.org Subject: Re: [PATCH bpf-next 2/2] libbpf, xsk: add libbpf_smp_store_release libbpf_smp_load_acquire On Tue, Mar 02, 2021 at 10:13:21AM +0100, 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.topel@...il.com> writes: > > > > From: Björn Töpel <bjorn.topel@...el.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. > > Would also be great to get Will's ACK on that when you have a v2. :) Please stick me on CC for that and I'll take a look as I've forgotten pretty much everything about this since last time :) Will
Powered by blists - more mailing lists