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: <20220517103758.353c2476@kernel.org>
Date:   Tue, 17 May 2022 10:37:58 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Johannes Berg <johannes@...solutions.net>
Cc:     Florian Fainelli <f.fainelli@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
        alex.aring@...il.com, stefan@...enfreihafen.org,
        mareklindner@...mailbox.ch, sw@...onwunderlich.de, a@...table.cc,
        sven@...fation.org, linux-wireless@...r.kernel.org,
        linux-wpan@...r.kernel.org
Subject: Re: [PATCH net-next] net: ifdefy the wireless pointers in struct
 net_device

On Tue, 17 May 2022 09:48:24 +0200 Johannes Berg wrote:
> On Mon, 2022-05-16 at 19:12 -0700, Florian Fainelli wrote:
> > 
> > On 5/16/2022 2:56 PM, Jakub Kicinski wrote:  
> > > Most protocol-specific pointers in struct net_device are under
> > > a respective ifdef. Wireless is the notable exception. Since
> > > there's a sizable number of custom-built kernels for datacenter
> > > workloads which don't build wireless it seems reasonable to
> > > ifdefy those pointers as well.
> > > 
> > > While at it move IPv4 and IPv6 pointers up, those are special
> > > for obvious reasons.
> > > 
> > > Signed-off-by: Jakub Kicinski <kuba@...nel.org>  
> > 
> > Could not we move to an union of pointers in the future since in many 
> > cases a network device can only have one of those pointers at any given 
> > time?  
> 
> Then at the very least we'd need some kind of type that we can assign to
> disambiguate, because today e.g. we have a netdev notifier (and other
> code) that could get a non-wireless netdev and check like this:
> 
> static int cfg80211_netdev_notifier_call(struct notifier_block *nb,
>                                          unsigned long state, void *ptr)
> {
>         struct net_device *dev = netdev_notifier_info_to_dev(ptr);
>         struct wireless_dev *wdev = dev->ieee80211_ptr;
> [...]
>         if (!wdev)
>                 return NOTIFY_DONE;

Can we use enum netdev_ml_priv_type netdev::ml_priv and
netdev::ml_priv_type for this?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ