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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220928072155.600569db@kernel.org>
Date:   Wed, 28 Sep 2022 07:21:55 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Nikolay Aleksandrov <razor@...ckwall.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
        pabeni@...hat.com, Johannes Berg <johannes@...solutions.net>,
        Pablo Neira Ayuso <pablo@...filter.org>,
        Florian Westphal <fw@...len.de>,
        Jamal Hadi Salim <jhs@...atatu.com>,
        Jacob Keller <jacob.e.keller@...el.com>,
        Florent Fourcot <florent.fourcot@...irst.fr>,
        Guillaume Nault <gnault@...hat.com>,
        Nicolas Dichtel <nicolas.dichtel@...nd.com>,
        Hangbin Liu <liuhangbin@...il.com>
Subject: Re: [PATCH net-next] docs: netlink: clarify the historical baggage
 of Netlink flags

On Wed, 28 Sep 2022 10:03:07 +0300 Nikolay Aleksandrov wrote:
> The part about NLM_F_BULK is correct now, but won't be soon. I have patches to add
> bulk delete to mdbs as well, and IIRC there were plans for other object types.
> I can update the doc once they are applied, but IMO it will be more useful to explain
> why they are used instead of who's using them, i.e. the BULK was added to support
> flush for FDBs w/ filtering initially and it's a flag so others can re-use it
> (my first attempt targeted only FDBs[1], but after a discussion it became clear that
> it will be more beneficial if other object types can re-use it so moved to a flag).
> The first version of the fdb flush support used only netlink attributes to do the
> flush via setlink, later moved to a specific RTM command (RTM_FLUSHNEIGH)[2] and
> finally settled on the flag[3][4] so everyone can use it.

I thought that's all FDB-ish stuff. Not really looking forward to the
use of flags spreading but within rtnl it may make some sense. We can
just update the docs tho, no?

BTW how would you define the exact semantics of NLM_F_BULK vs it not
being set, in abstract terms?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ