netdev - Re: [PATCH bpf 1/7] xdp: remove the xdp_attachment_flags

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201204084847.04d9dc46@kicinski-fedora-pc1c0hjn.DHCP.thefacebook.com>
Date:   Fri, 4 Dec 2020 08:48:47 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Andrii Nakryiko <andriin@...com>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        Jesper Dangaard Brouer <hawk@...nel.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Romain Perier <romain.perier@...il.com>,
        Allen Pais <apais@...ux.microsoft.com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Simon Horman <simon.horman@...ronome.com>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        Lorenzo Bianconi <lorenzo@...nel.org>,
        Wei Yongjun <weiyongjun1@...wei.com>,
        Jiri Benc <jbenc@...hat.com>, oss-drivers@...ronome.com,
        linux-omap@...r.kernel.org, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: Re: [PATCH bpf 1/7] xdp: remove the xdp_attachment_flags_ok()
 callback

On Fri, 04 Dec 2020 10:38:06 +0100 Toke Høiland-Jørgensen wrote:
> Jakub Kicinski <kuba@...nel.org> writes:
> > On Thu, 03 Dec 2020 22:35:18 +0100 Toke Høiland-Jørgensen wrote:  
> >> Since we offloaded and non-offloaded programs can co-exist there doesn't
> >> really seem to be any reason for the check anyway, and it's only used in
> >> three drivers so let's just get rid of the callback entirely.  
> >
> > I don't remember exactly now, but I think the concern was that using 
> > the unspecified mode is pretty ambiguous when interface has multiple
> > programs attached.  
> 
> Right. I did scratch my head a bit for why the check was there in the
> first place, but that makes sense, actually :)
> 
> So how about we disallow unload without specifying a mode, but only if
> more than one program is loaded?

Are you including replacing as a form of unload? :)

IMHO the simpler the definition of the API / constraint the better.
"You must specify the same flags" is pretty simple, as is copying 
the old behavior rather than trying to come up with new rules.

But up to you, I don't mind either way, really..

> Since the core code tracks all the programs now, this could just be
> enforced there and we would avoid all the weird interactions with the
> drivers trying to enforce it...

Yup, enforcing in the core now would make perfect sense.