netdev - Re: [PATCH net-next 5/8] rtnetlink: do not depend on RTNL for many attributes

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: <CANn89i+ZKZrbmqxKU33XgN_ZyqqkFa7+BqAqFWCYdj3He1Xy8g@mail.gmail.com>
Date: Sun, 5 May 2024 17:00:10 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Simon Horman <horms@...nel.org>
Cc: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, eric.dumazet@...il.com
Subject: Re: [PATCH net-next 5/8] rtnetlink: do not depend on RTNL for many attributes

On Sun, May 5, 2024 at 4:47 PM Simon Horman <horms@...nel.org> wrote:
>
> On Fri, May 03, 2024 at 07:20:56PM +0000, Eric Dumazet wrote:
> > Following device fields can be read locklessly
> > in rtnl_fill_ifinfo() :
> >
> > type, ifindex, operstate, link_mode, mtu, min_mtu, max_mtu, group,
> > promiscuity, allmulti, num_tx_queues, gso_max_segs, gso_max_size,
> > gro_max_size, gso_ipv4_max_size, gro_ipv4_max_size, tso_max_size,
> > tso_max_segs, num_rx_queues.
>
> Hi Eric,
>
> * Regarding mtu, as the comment you added to sruct net_device
>   some time ago mentions, mtu is written in many places.
>
>   I'm wondering if, in particular wrt ndo_change_mtu implementations,
>   if some it is appropriate to add WRITE_ONCE() annotations.

Sure thing. I called for these changes in commit
501a90c94510 ("inet: protect against too small mtu values.")
when I said "Hopefully we will add the missing ones in followup patches."


>
> * Likewise, is it appropriate to add WRITE_ONCE() to dev_set_group() ?

In general, a lot of write sides would need to be changed.

In practice, most compilers will not perform store tearing, this would
be quite expensive.

Also, adding WRITE_ONCE() will not prevent a reader from reading some
temporary values,
take a look at dev_change_tx_queue_len() for instance.