Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Stanislaw Gruszka]

I've updated wireless code on RHEL and get complain that now
cfg80211 and rfkill modules are loaded on machines that do not have
wireless hardware. Modules are auto-loaded because NetworkManager send
nl80211 messages to check if there are wireless devices in the system.

Hence my question, can we revert commit fb4e156886ce
"nl80211: Add generic netlink module alias for cfg80211/nl80211" ?

Auto loading nl80211 does not seems to be necessary, if there are
wireless devices nl80211 will be loaded anyway.

Stanislaw

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Johannes Berg]

On Thu, 2014-11-13 at 13:33 +0100, Stanislaw Gruszka wrote:
> I've updated wireless code on RHEL and get complain that now
> cfg80211 and rfkill modules are loaded on machines that do not have
> wireless hardware. Modules are auto-loaded because NetworkManager send
> nl80211 messages to check if there are wireless devices in the system.
> 
> Hence my question, can we revert commit fb4e156886ce
> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?

Realistically, we can't revert it, but only remove the
MODULE_ALIAS_GENL_FAMILY() line.

> Auto loading nl80211 does not seems to be necessary, if there are
> wireless devices nl80211 will be loaded anyway.

Maybe other applications would like to see an empty list of devices? But
OTOH, if they're robust at all, they have to cope with kernels not even
compiled with nl80211, so I guess for me I don't really see a big
difference in whether the module alias exists or not.

johannes

[PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

[Stanislaw Gruszka]

With the alias cfg80211 module is loaded on systems without the wireless
hardware when user-space use nl80211 to discover if there are wireless
devices, what is considered as resources wastage. On systems with
wireless hardware cfg80211 module will be loaded anyway.

Cc: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
 net/wireless/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/net/wireless/core.c b/net/wireless/core.c
index a4d2792..badcabe 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -34,7 +34,6 @@
 MODULE_AUTHOR("Johannes Berg");
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("wireless configuration support");
-MODULE_ALIAS_GENL_FAMILY(NL80211_GENL_NAME);
 
 /* RCU-protected (and RTNL for writers) */
 LIST_HEAD(cfg80211_rdev_list);
-- 
1.8.3.1

Re: [PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

[Marcel Holtmann]

Hi Stanislaw,

> With the alias cfg80211 module is loaded on systems without the wireless
> hardware when user-space use nl80211 to discover if there are wireless
> devices, what is considered as resources wastage. On systems with
> wireless hardware cfg80211 module will be loaded anyway.
> 
> Cc: Marcel Holtmann <marcel@holtmann.org>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> ---
> net/wireless/core.c | 1 -
> 1 file changed, 1 deletion(-)
> 
> diff --git a/net/wireless/core.c b/net/wireless/core.c
> index a4d2792..badcabe 100644
> --- a/net/wireless/core.c
> +++ b/net/wireless/core.c
> @@ -34,7 +34,6 @@
> MODULE_AUTHOR("Johannes Berg");
> MODULE_LICENSE("GPL");
> MODULE_DESCRIPTION("wireless configuration support");
> -MODULE_ALIAS_GENL_FAMILY(NL80211_GENL_NAME);

NAK.

We want to auto-load cfg80211 when userspace asked for nl80211 netlink family.

Regards

Marcel

Re: [PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

[Stanislaw Gruszka]

Hi

On Thu, Nov 13, 2014 at 10:36:17PM +0900, Marcel Holtmann wrote:
> > With the alias cfg80211 module is loaded on systems without the wireless
> > hardware when user-space use nl80211 to discover if there are wireless
> > devices, what is considered as resources wastage. On systems with
> > wireless hardware cfg80211 module will be loaded anyway.
> > 
> > Cc: Marcel Holtmann <marcel@holtmann.org>
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> > ---
> > net/wireless/core.c | 1 -
> > 1 file changed, 1 deletion(-)
> > 
> > diff --git a/net/wireless/core.c b/net/wireless/core.c
> > index a4d2792..badcabe 100644
> > --- a/net/wireless/core.c
> > +++ b/net/wireless/core.c
> > @@ -34,7 +34,6 @@
> > MODULE_AUTHOR("Johannes Berg");
> > MODULE_LICENSE("GPL");
> > MODULE_DESCRIPTION("wireless configuration support");
> > -MODULE_ALIAS_GENL_FAMILY(NL80211_GENL_NAME);
> 
> NAK.
> 
> We want to auto-load cfg80211 when userspace asked for nl80211 netlink family.

Could you elaborate more why?

Stanislaw

Re: [PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

[Marcel Holtmann]

Hi Stanislaw,

>>> With the alias cfg80211 module is loaded on systems without the wireless
>>> hardware when user-space use nl80211 to discover if there are wireless
>>> devices, what is considered as resources wastage. On systems with
>>> wireless hardware cfg80211 module will be loaded anyway.
>>> 
>>> Cc: Marcel Holtmann <marcel@holtmann.org>
>>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>>> ---
>>> net/wireless/core.c | 1 -
>>> 1 file changed, 1 deletion(-)
>>> 
>>> diff --git a/net/wireless/core.c b/net/wireless/core.c
>>> index a4d2792..badcabe 100644
>>> --- a/net/wireless/core.c
>>> +++ b/net/wireless/core.c
>>> @@ -34,7 +34,6 @@
>>> MODULE_AUTHOR("Johannes Berg");
>>> MODULE_LICENSE("GPL");
>>> MODULE_DESCRIPTION("wireless configuration support");
>>> -MODULE_ALIAS_GENL_FAMILY(NL80211_GENL_NAME);
>> 
>> NAK.
>> 
>> We want to auto-load cfg80211 when userspace asked for nl80211 netlink family.
> 
> Could you elaborate more why?

you want to talk to the nl80211 family. The kernel has a module that allows you to talk to this family. So let it load the netlink family.

If you do not want cfg80211 loaded, then fix NetworkManager and not hack the kernel. NetworkManager asks to talk to nl80211 in the first place. That one is causing the loading of cfg80211 module.

You can also de-install the NetworkManager module for wireless, right. Then none of this should happen. Seriously, fix your userspace and do not blame the kernel for a perfect valid behavior.

Regards

Marcel

Re: [PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

[Dan Williams]

On Thu, 2014-11-13 at 22:48 +0900, Marcel Holtmann wrote:
> Hi Stanislaw,
> 
> >>> With the alias cfg80211 module is loaded on systems without the wireless
> >>> hardware when user-space use nl80211 to discover if there are wireless
> >>> devices, what is considered as resources wastage. On systems with
> >>> wireless hardware cfg80211 module will be loaded anyway.
> >>> 
> >>> Cc: Marcel Holtmann <marcel@holtmann.org>
> >>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> >>> ---
> >>> net/wireless/core.c | 1 -
> >>> 1 file changed, 1 deletion(-)
> >>> 
> >>> diff --git a/net/wireless/core.c b/net/wireless/core.c
> >>> index a4d2792..badcabe 100644
> >>> --- a/net/wireless/core.c
> >>> +++ b/net/wireless/core.c
> >>> @@ -34,7 +34,6 @@
> >>> MODULE_AUTHOR("Johannes Berg");
> >>> MODULE_LICENSE("GPL");
> >>> MODULE_DESCRIPTION("wireless configuration support");
> >>> -MODULE_ALIAS_GENL_FAMILY(NL80211_GENL_NAME);
> >> 
> >> NAK.
> >> 
> >> We want to auto-load cfg80211 when userspace asked for nl80211 netlink family.
> > 
> > Could you elaborate more why?
> 
> you want to talk to the nl80211 family. The kernel has a module that allows you to talk to this family. So let it load the netlink family.
> 
> If you do not want cfg80211 loaded, then fix NetworkManager and not hack the kernel. NetworkManager asks to talk to nl80211 in the first place. That one is causing the loading of cfg80211 module.

Unfortunately there seems to be no reliable way of detecting that an
ethernet-type interface is WiFi (and talks nl80211) or is not WiFi, than
by asking it, using nl80211.  Unless you have suggestions for this?

Dan

Re: [PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

[Marcel Holtmann]

Hi Dan,

>>>>> With the alias cfg80211 module is loaded on systems without the wireless
>>>>> hardware when user-space use nl80211 to discover if there are wireless
>>>>> devices, what is considered as resources wastage. On systems with
>>>>> wireless hardware cfg80211 module will be loaded anyway.
>>>>> 
>>>>> Cc: Marcel Holtmann <marcel@holtmann.org>
>>>>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
>>>>> ---
>>>>> net/wireless/core.c | 1 -
>>>>> 1 file changed, 1 deletion(-)
>>>>> 
>>>>> diff --git a/net/wireless/core.c b/net/wireless/core.c
>>>>> index a4d2792..badcabe 100644
>>>>> --- a/net/wireless/core.c
>>>>> +++ b/net/wireless/core.c
>>>>> @@ -34,7 +34,6 @@
>>>>> MODULE_AUTHOR("Johannes Berg");
>>>>> MODULE_LICENSE("GPL");
>>>>> MODULE_DESCRIPTION("wireless configuration support");
>>>>> -MODULE_ALIAS_GENL_FAMILY(NL80211_GENL_NAME);
>>>> 
>>>> NAK.
>>>> 
>>>> We want to auto-load cfg80211 when userspace asked for nl80211 netlink family.
>>> 
>>> Could you elaborate more why?
>> 
>> you want to talk to the nl80211 family. The kernel has a module that allows you to talk to this family. So let it load the netlink family.
>> 
>> If you do not want cfg80211 loaded, then fix NetworkManager and not hack the kernel. NetworkManager asks to talk to nl80211 in the first place. That one is causing the loading of cfg80211 module.
> 
> Unfortunately there seems to be no reliable way of detecting that an
> ethernet-type interface is WiFi (and talks nl80211) or is not WiFi, than
> by asking it, using nl80211.  Unless you have suggestions for this?

my suggestion is to fix missing DEVTYPE=wlan entries.

If you want to do detection via nl80211, that is fine by me. However then NetworkManager users have to accept that this will then trigger loading of cfg80211 module. But we are not removing a correct module alias because of this.

This is the same thing when you start bluetoothd without any Bluetooth controllers attached to the system. The bluetooth core module will be loaded. We are not removing the correct socket address family module auto-loading because someone does not want to have the module loaded, but poke with the socket for some reason.

Regards

Marcel

Re: [PATCH] cfg80211: remove net-pf-16-proto-16-family-nl80211 module alias

[Stanislaw Gruszka]

On Thu, Nov 13, 2014 at 10:48:11PM +0900, Marcel Holtmann wrote:
> Hi Stanislaw,
> 
> >>> With the alias cfg80211 module is loaded on systems without the wireless
> >>> hardware when user-space use nl80211 to discover if there are wireless
> >>> devices, what is considered as resources wastage. On systems with
> >>> wireless hardware cfg80211 module will be loaded anyway.
> >>> 
> >>> Cc: Marcel Holtmann <marcel@holtmann.org>
> >>> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> >>> ---
> >>> net/wireless/core.c | 1 -
> >>> 1 file changed, 1 deletion(-)
> >>> 
> >>> diff --git a/net/wireless/core.c b/net/wireless/core.c
> >>> index a4d2792..badcabe 100644
> >>> --- a/net/wireless/core.c
> >>> +++ b/net/wireless/core.c
> >>> @@ -34,7 +34,6 @@
> >>> MODULE_AUTHOR("Johannes Berg");
> >>> MODULE_LICENSE("GPL");
> >>> MODULE_DESCRIPTION("wireless configuration support");
> >>> -MODULE_ALIAS_GENL_FAMILY(NL80211_GENL_NAME);
> >> 
> >> NAK.
> >> 
> >> We want to auto-load cfg80211 when userspace asked for nl80211 netlink family.
> > 
> > Could you elaborate more why?
> 
> you want to talk to the nl80211 family. The kernel has a module that allows you to talk to this family. So let it load the netlink family.

This is not strictly true. User-space does not wan to talk to nl80211, it
wants to talk to hardware via nl80211. If there is no hardware, there is
nothing to talk to.

> If you do not want cfg80211 loaded, then fix NetworkManager and not hack the kernel. NetworkManager asks to talk to nl80211 in the first place. That one is causing the loading of cfg80211 module.
> 
> You can also de-install the NetworkManager module for wireless, right. Then none of this should happen. Seriously, fix your userspace and do not blame the kernel for a perfect valid behavior.

Maybe this is perfectly valid behaviour, but if it makes perfect sense
is dubious.

Stanislaw 

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Marcel Holtmann]

Hi Johannes,

>> I've updated wireless code on RHEL and get complain that now
>> cfg80211 and rfkill modules are loaded on machines that do not have
>> wireless hardware. Modules are auto-loaded because NetworkManager send
>> nl80211 messages to check if there are wireless devices in the system.
>> 
>> Hence my question, can we revert commit fb4e156886ce
>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> 
> Realistically, we can't revert it, but only remove the
> MODULE_ALIAS_GENL_FAMILY() line.
> 
>> Auto loading nl80211 does not seems to be necessary, if there are
>> wireless devices nl80211 will be loaded anyway.
> 
> Maybe other applications would like to see an empty list of devices? But
> OTOH, if they're robust at all, they have to cope with kernels not even
> compiled with nl80211, so I guess for me I don't really see a big
> difference in whether the module alias exists or not.

auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.

Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.

Regards

Marcel

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Dan Williams]

On Thu, 2014-11-13 at 22:41 +0900, Marcel Holtmann wrote:
> Hi Johannes,
> 
> >> I've updated wireless code on RHEL and get complain that now
> >> cfg80211 and rfkill modules are loaded on machines that do not have
> >> wireless hardware. Modules are auto-loaded because NetworkManager send
> >> nl80211 messages to check if there are wireless devices in the system.
> >> 
> >> Hence my question, can we revert commit fb4e156886ce
> >> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> > 
> > Realistically, we can't revert it, but only remove the
> > MODULE_ALIAS_GENL_FAMILY() line.
> > 
> >> Auto loading nl80211 does not seems to be necessary, if there are
> >> wireless devices nl80211 will be loaded anyway.
> > 
> > Maybe other applications would like to see an empty list of devices? But
> > OTOH, if they're robust at all, they have to cope with kernels not even
> > compiled with nl80211, so I guess for me I don't really see a big
> > difference in whether the module alias exists or not.
> 
> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
> 
> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.

NM uses nl80211 initially to determine whether *any* ethernet-type
interface (a) is actually WiFi, and (b) should be driven by nl80211 or
WEXT.  Because of the variety of drivers (both in-kernel and
out-of-kernel) and the variety of kernel versions (NM supports back to
early 3.x series) we cannot rely on specific behavior.

So given an ethernet-type interface, how do we determine that it is
wifi?

DEVTYPE=wlan - not always reliable due to driver and kernel versions

"phy80211" in sysfs: same reason; also doesn't capture WEXT or
out-of-tree drivers

nl80211 calls: this is the only 100% reliable mechanism to detect
whether an ethernet-type interface is actually WiFi and nl80211-capable.

And unfortunately calling nl80211 loads the module...

Dan

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Luca Coelho]

On Thu, 2014-11-13 at 20:55 -0600, Dan Williams wrote:
> On Thu, 2014-11-13 at 22:41 +0900, Marcel Holtmann wrote:
> > Hi Johannes,
> > 
> > >> I've updated wireless code on RHEL and get complain that now
> > >> cfg80211 and rfkill modules are loaded on machines that do not have
> > >> wireless hardware. Modules are auto-loaded because NetworkManager send
> > >> nl80211 messages to check if there are wireless devices in the system.
> > >> 
> > >> Hence my question, can we revert commit fb4e156886ce
> > >> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> > > 
> > > Realistically, we can't revert it, but only remove the
> > > MODULE_ALIAS_GENL_FAMILY() line.
> > > 
> > >> Auto loading nl80211 does not seems to be necessary, if there are
> > >> wireless devices nl80211 will be loaded anyway.
> > > 
> > > Maybe other applications would like to see an empty list of devices? But
> > > OTOH, if they're robust at all, they have to cope with kernels not even
> > > compiled with nl80211, so I guess for me I don't really see a big
> > > difference in whether the module alias exists or not.
> > 
> > auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
> > 
> > Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
> 
> NM uses nl80211 initially to determine whether *any* ethernet-type
> interface (a) is actually WiFi, and (b) should be driven by nl80211 or
> WEXT.  Because of the variety of drivers (both in-kernel and
> out-of-kernel) and the variety of kernel versions (NM supports back to
> early 3.x series) we cannot rely on specific behavior.
> 
> So given an ethernet-type interface, how do we determine that it is
> wifi?
> 
> DEVTYPE=wlan - not always reliable due to driver and kernel versions
> 
> "phy80211" in sysfs: same reason; also doesn't capture WEXT or
> out-of-tree drivers
> 
> nl80211 calls: this is the only 100% reliable mechanism to detect
> whether an ethernet-type interface is actually WiFi and nl80211-capable.
> 
> And unfortunately calling nl80211 loads the module...

So, basically the conclusion is: there's no way around it.  If someone
in userspace uses nl80211 it must be loaded, regardless of whether
nl80211 is automatically loaded or if depmod bring it in.

The only way to address Stanislaw's initial concern is, as already
proposed before, to change userspace.

Or, maybe nl80211/cfg80211 could be unloaded automatically as well? If
no driver uses it from below and nobody from userspace uses it for a
period of time, off it goes...

--
Luca.

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Marcel Holtmann]

Hi Luca,

>>>>> I've updated wireless code on RHEL and get complain that now
>>>>> cfg80211 and rfkill modules are loaded on machines that do not have
>>>>> wireless hardware. Modules are auto-loaded because NetworkManager send
>>>>> nl80211 messages to check if there are wireless devices in the system.
>>>>> 
>>>>> Hence my question, can we revert commit fb4e156886ce
>>>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
>>>> 
>>>> Realistically, we can't revert it, but only remove the
>>>> MODULE_ALIAS_GENL_FAMILY() line.
>>>> 
>>>>> Auto loading nl80211 does not seems to be necessary, if there are
>>>>> wireless devices nl80211 will be loaded anyway.
>>>> 
>>>> Maybe other applications would like to see an empty list of devices? But
>>>> OTOH, if they're robust at all, they have to cope with kernels not even
>>>> compiled with nl80211, so I guess for me I don't really see a big
>>>> difference in whether the module alias exists or not.
>>> 
>>> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
>>> 
>>> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
>> 
>> NM uses nl80211 initially to determine whether *any* ethernet-type
>> interface (a) is actually WiFi, and (b) should be driven by nl80211 or
>> WEXT.  Because of the variety of drivers (both in-kernel and
>> out-of-kernel) and the variety of kernel versions (NM supports back to
>> early 3.x series) we cannot rely on specific behavior.
>> 
>> So given an ethernet-type interface, how do we determine that it is
>> wifi?
>> 
>> DEVTYPE=wlan - not always reliable due to driver and kernel versions
>> 
>> "phy80211" in sysfs: same reason; also doesn't capture WEXT or
>> out-of-tree drivers
>> 
>> nl80211 calls: this is the only 100% reliable mechanism to detect
>> whether an ethernet-type interface is actually WiFi and nl80211-capable.
>> 
>> And unfortunately calling nl80211 loads the module...
> 
> So, basically the conclusion is: there's no way around it.  If someone
> in userspace uses nl80211 it must be loaded, regardless of whether
> nl80211 is automatically loaded or if depmod bring it in.

yes, that is how it should be. And actually that is how every other subsystem does. Including modules that get loaded because we have a socket() system call for an address family.

> The only way to address Stanislaw's initial concern is, as already
> proposed before, to change userspace.

Or you just blacklist the module in /etc/modules.conf if you really do not want it loaded. But all of this is a userspace thing and has nothing to do with the kernel exposing the _correct_ module alias.

> Or, maybe nl80211/cfg80211 could be unloaded automatically as well? If
> no driver uses it from below and nobody from userspace uses it for a
> period of time, off it goes...

Actually unloading kernel modules is still considered a race condition. So we should not go that direction. Once loaded, they should stay loaded until reboot.

Regards

Marcel

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Stanislaw Gruszka]

On Fri, Nov 14, 2014 at 03:57:40PM +0900, Marcel Holtmann wrote:
> Hi Luca,
> 
> >>>>> I've updated wireless code on RHEL and get complain that now
> >>>>> cfg80211 and rfkill modules are loaded on machines that do not have
> >>>>> wireless hardware. Modules are auto-loaded because NetworkManager send
> >>>>> nl80211 messages to check if there are wireless devices in the system.
> >>>>> 
> >>>>> Hence my question, can we revert commit fb4e156886ce
> >>>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> >>>> 
> >>>> Realistically, we can't revert it, but only remove the
> >>>> MODULE_ALIAS_GENL_FAMILY() line.
> >>>> 
> >>>>> Auto loading nl80211 does not seems to be necessary, if there are
> >>>>> wireless devices nl80211 will be loaded anyway.
> >>>> 
> >>>> Maybe other applications would like to see an empty list of devices? But
> >>>> OTOH, if they're robust at all, they have to cope with kernels not even
> >>>> compiled with nl80211, so I guess for me I don't really see a big
> >>>> difference in whether the module alias exists or not.
> >>> 
> >>> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
> >>> 
> >>> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
> >> 
> >> NM uses nl80211 initially to determine whether *any* ethernet-type
> >> interface (a) is actually WiFi, and (b) should be driven by nl80211 or
> >> WEXT.  Because of the variety of drivers (both in-kernel and
> >> out-of-kernel) and the variety of kernel versions (NM supports back to
> >> early 3.x series) we cannot rely on specific behavior.
> >> 
> >> So given an ethernet-type interface, how do we determine that it is
> >> wifi?
> >> 
> >> DEVTYPE=wlan - not always reliable due to driver and kernel versions
> >> 
> >> "phy80211" in sysfs: same reason; also doesn't capture WEXT or
> >> out-of-tree drivers
> >> 
> >> nl80211 calls: this is the only 100% reliable mechanism to detect
> >> whether an ethernet-type interface is actually WiFi and nl80211-capable.
> >> 
> >> And unfortunately calling nl80211 loads the module...
> > 
> > So, basically the conclusion is: there's no way around it.  If someone
> > in userspace uses nl80211 it must be loaded, regardless of whether
> > nl80211 is automatically loaded or if depmod bring it in.
> 
> yes, that is how it should be. And actually that is how every other subsystem does. Including modules that get loaded because we have a socket() system call for an address family.

On other subsystems auto loading make sense. For example on netfiler,
we really want to load netfiler modules when user-space want to
configure it and started talking to it by socket. But here situation
is different. If there is no hardware we can not configure it.

Stanislaw

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Marcel Holtmann]

Hi Dan,

>>>> I've updated wireless code on RHEL and get complain that now
>>>> cfg80211 and rfkill modules are loaded on machines that do not have
>>>> wireless hardware. Modules are auto-loaded because NetworkManager send
>>>> nl80211 messages to check if there are wireless devices in the system.
>>>> 
>>>> Hence my question, can we revert commit fb4e156886ce
>>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
>>> 
>>> Realistically, we can't revert it, but only remove the
>>> MODULE_ALIAS_GENL_FAMILY() line.
>>> 
>>>> Auto loading nl80211 does not seems to be necessary, if there are
>>>> wireless devices nl80211 will be loaded anyway.
>>> 
>>> Maybe other applications would like to see an empty list of devices? But
>>> OTOH, if they're robust at all, they have to cope with kernels not even
>>> compiled with nl80211, so I guess for me I don't really see a big
>>> difference in whether the module alias exists or not.
>> 
>> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
>> 
>> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
> 
> NM uses nl80211 initially to determine whether *any* ethernet-type
> interface (a) is actually WiFi, and (b) should be driven by nl80211 or
> WEXT.  Because of the variety of drivers (both in-kernel and
> out-of-kernel) and the variety of kernel versions (NM supports back to
> early 3.x series) we cannot rely on specific behavior.
> 
> So given an ethernet-type interface, how do we determine that it is
> wifi?
> 
> DEVTYPE=wlan - not always reliable due to driver and kernel versions

if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug.

> "phy80211" in sysfs: same reason; also doesn't capture WEXT or
> out-of-tree drivers
> 
> nl80211 calls: this is the only 100% reliable mechanism to detect
> whether an ethernet-type interface is actually WiFi and nl80211-capable.
> 
> And unfortunately calling nl80211 loads the module...

So be it then, the cfg80211 modules gets loaded. People have to live with that.

And just to be clear, this is not a kernel bug. Exposing the correct module alias for its netlink family is what the module should be doing.

Regards

Marcel

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Stanislaw Gruszka]

On Fri, Nov 14, 2014 at 04:02:33PM +0900, Marcel Holtmann wrote:
> Hi Dan,
> 
> >>>> I've updated wireless code on RHEL and get complain that now
> >>>> cfg80211 and rfkill modules are loaded on machines that do not have
> >>>> wireless hardware. Modules are auto-loaded because NetworkManager send
> >>>> nl80211 messages to check if there are wireless devices in the system.
> >>>> 
> >>>> Hence my question, can we revert commit fb4e156886ce
> >>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> >>> 
> >>> Realistically, we can't revert it, but only remove the
> >>> MODULE_ALIAS_GENL_FAMILY() line.
> >>> 
> >>>> Auto loading nl80211 does not seems to be necessary, if there are
> >>>> wireless devices nl80211 will be loaded anyway.
> >>> 
> >>> Maybe other applications would like to see an empty list of devices? But
> >>> OTOH, if they're robust at all, they have to cope with kernels not even
> >>> compiled with nl80211, so I guess for me I don't really see a big
> >>> difference in whether the module alias exists or not.
> >> 
> >> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
> >> 
> >> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
> > 
> > NM uses nl80211 initially to determine whether *any* ethernet-type
> > interface (a) is actually WiFi, and (b) should be driven by nl80211 or
> > WEXT.  Because of the variety of drivers (both in-kernel and
> > out-of-kernel) and the variety of kernel versions (NM supports back to
> > early 3.x series) we cannot rely on specific behavior.
> > 
> > So given an ethernet-type interface, how do we determine that it is
> > wifi?
> > 
> > DEVTYPE=wlan - not always reliable due to driver and kernel versions
> 
> if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug.

NM can be run with older kernel versions, which does not have DEVTYPE=wlan.
I guess NM could check the kernel version and don't use nl80211 if
kernel is sufficiency modern.

> > "phy80211" in sysfs: same reason; also doesn't capture WEXT or
> > out-of-tree drivers
> > 
> > nl80211 calls: this is the only 100% reliable mechanism to detect
> > whether an ethernet-type interface is actually WiFi and nl80211-capable.
> > 
> > And unfortunately calling nl80211 loads the module...
> 
> So be it then, the cfg80211 modules gets loaded. People have to live with that.

It's 700k of kernel memory. People running many instances of guest OS
with this module loaded are quite unhappy.

> And just to be clear, this is not a kernel bug. Exposing the correct module alias for its netlink family is what the module should be doing.

This is not a kernel bug, but not having the alias is also not
a kernel bug :-)

Stanislaw

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Dan Williams]

On Fri, 2014-11-14 at 16:02 +0900, Marcel Holtmann wrote:
> Hi Dan,
> 
> >>>> I've updated wireless code on RHEL and get complain that now
> >>>> cfg80211 and rfkill modules are loaded on machines that do not have
> >>>> wireless hardware. Modules are auto-loaded because NetworkManager send
> >>>> nl80211 messages to check if there are wireless devices in the system.
> >>>> 
> >>>> Hence my question, can we revert commit fb4e156886ce
> >>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> >>> 
> >>> Realistically, we can't revert it, but only remove the
> >>> MODULE_ALIAS_GENL_FAMILY() line.
> >>> 
> >>>> Auto loading nl80211 does not seems to be necessary, if there are
> >>>> wireless devices nl80211 will be loaded anyway.
> >>> 
> >>> Maybe other applications would like to see an empty list of devices? But
> >>> OTOH, if they're robust at all, they have to cope with kernels not even
> >>> compiled with nl80211, so I guess for me I don't really see a big
> >>> difference in whether the module alias exists or not.
> >> 
> >> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
> >> 
> >> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
> > 
> > NM uses nl80211 initially to determine whether *any* ethernet-type
> > interface (a) is actually WiFi, and (b) should be driven by nl80211 or
> > WEXT.  Because of the variety of drivers (both in-kernel and
> > out-of-kernel) and the variety of kernel versions (NM supports back to
> > early 3.x series) we cannot rely on specific behavior.
> > 
> > So given an ethernet-type interface, how do we determine that it is
> > wifi?
> > 
> > DEVTYPE=wlan - not always reliable due to driver and kernel versions
> 
> if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug.

Yeah, that's nice, and should be done.  It seems a number of drivers
don't have it.  Obviously everything mac80211 does, and it seems we're
left with:

1) legacy drivers that only support WEXT (airo, etc)
2) out-of-tree drivers (wl.o and various realtek/ralink stuff?)

So it seems that new best practice is:

a) if DEVTYPE=wlan, hit up nl80211 to determine whether the interface
supports nl80211 or WEXT (minimal cfg80211 ports like ipw2x00 don't
actually support nl80211 at all and must use WEXT)

b) if DEVTYPE is missing, WEXT can be tried if it is available

c) treat interface as 'ethernet'; out-of-tree WiFi drivers may end up
here but that is life

Does that sound valid to everyone else?

Dan

> > "phy80211" in sysfs: same reason; also doesn't capture WEXT or
> > out-of-tree drivers
> > 
> > nl80211 calls: this is the only 100% reliable mechanism to detect
> > whether an ethernet-type interface is actually WiFi and nl80211-capable.
> > 
> > And unfortunately calling nl80211 loads the module...
> 
> So be it then, the cfg80211 modules gets loaded. People have to live with that.
> 
> And just to be clear, this is not a kernel bug. Exposing the correct module alias for its netlink family is what the module should be doing.
> 
> Regards
> 
> Marcel
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Dan Williams]

On Fri, 2014-11-14 at 10:02 -0600, Dan Williams wrote:
> On Fri, 2014-11-14 at 16:02 +0900, Marcel Holtmann wrote:
> > Hi Dan,
> > 
> > >>>> I've updated wireless code on RHEL and get complain that now
> > >>>> cfg80211 and rfkill modules are loaded on machines that do not have
> > >>>> wireless hardware. Modules are auto-loaded because NetworkManager send
> > >>>> nl80211 messages to check if there are wireless devices in the system.
> > >>>> 
> > >>>> Hence my question, can we revert commit fb4e156886ce
> > >>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> > >>> 
> > >>> Realistically, we can't revert it, but only remove the
> > >>> MODULE_ALIAS_GENL_FAMILY() line.
> > >>> 
> > >>>> Auto loading nl80211 does not seems to be necessary, if there are
> > >>>> wireless devices nl80211 will be loaded anyway.
> > >>> 
> > >>> Maybe other applications would like to see an empty list of devices? But
> > >>> OTOH, if they're robust at all, they have to cope with kernels not even
> > >>> compiled with nl80211, so I guess for me I don't really see a big
> > >>> difference in whether the module alias exists or not.
> > >> 
> > >> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
> > >> 
> > >> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
> > > 
> > > NM uses nl80211 initially to determine whether *any* ethernet-type
> > > interface (a) is actually WiFi, and (b) should be driven by nl80211 or
> > > WEXT.  Because of the variety of drivers (both in-kernel and
> > > out-of-kernel) and the variety of kernel versions (NM supports back to
> > > early 3.x series) we cannot rely on specific behavior.
> > > 
> > > So given an ethernet-type interface, how do we determine that it is
> > > wifi?
> > > 
> > > DEVTYPE=wlan - not always reliable due to driver and kernel versions
> > 
> > if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug.
> 
> Yeah, that's nice, and should be done.  It seems a number of drivers
> don't have it.  Obviously everything mac80211 does, and it seems we're
> left with:
> 
> 1) legacy drivers that only support WEXT (airo, etc)
> 2) out-of-tree drivers (wl.o and various realtek/ralink stuff?)
> 
> So it seems that new best practice is:
> 
> a) if DEVTYPE=wlan, hit up nl80211 to determine whether the interface
> supports nl80211 or WEXT (minimal cfg80211 ports like ipw2x00 don't
> actually support nl80211 at all and must use WEXT)
> 
> b) if DEVTYPE is missing, WEXT can be tried if it is available
> 
> c) treat interface as 'ethernet'; out-of-tree WiFi drivers may end up
> here but that is life
> 
> Does that sound valid to everyone else?

Potential NM fix filed at:

https://bugzilla.gnome.org/show_bug.cgi?id=740131

Dan

Re: Can fb4e156886ce6e8309e912d8b370d192330d19d3 be reverted ?

[Dan Williams]

On Fri, 2014-11-14 at 11:10 -0600, Dan Williams wrote:
> On Fri, 2014-11-14 at 10:02 -0600, Dan Williams wrote:
> > On Fri, 2014-11-14 at 16:02 +0900, Marcel Holtmann wrote:
> > > Hi Dan,
> > > 
> > > >>>> I've updated wireless code on RHEL and get complain that now
> > > >>>> cfg80211 and rfkill modules are loaded on machines that do not have
> > > >>>> wireless hardware. Modules are auto-loaded because NetworkManager send
> > > >>>> nl80211 messages to check if there are wireless devices in the system.
> > > >>>> 
> > > >>>> Hence my question, can we revert commit fb4e156886ce
> > > >>>> "nl80211: Add generic netlink module alias for cfg80211/nl80211" ?
> > > >>> 
> > > >>> Realistically, we can't revert it, but only remove the
> > > >>> MODULE_ALIAS_GENL_FAMILY() line.
> > > >>> 
> > > >>>> Auto loading nl80211 does not seems to be necessary, if there are
> > > >>>> wireless devices nl80211 will be loaded anyway.
> > > >>> 
> > > >>> Maybe other applications would like to see an empty list of devices? But
> > > >>> OTOH, if they're robust at all, they have to cope with kernels not even
> > > >>> compiled with nl80211, so I guess for me I don't really see a big
> > > >>> difference in whether the module alias exists or not.
> > > >> 
> > > >> auto-loading cfg80211 module when userspace requests nl80211 netlink family is exactly the right thing to do. Systems compiled without nl80211 support and systems with no wireless device attached are two different things.
> > > >> 
> > > >> Someone can fix NetworkManager to not send nl80211 messages or just plain accept that cfg80211 will be loaded.
> > > > 
> > > > NM uses nl80211 initially to determine whether *any* ethernet-type
> > > > interface (a) is actually WiFi, and (b) should be driven by nl80211 or
> > > > WEXT.  Because of the variety of drivers (both in-kernel and
> > > > out-of-kernel) and the variety of kernel versions (NM supports back to
> > > > early 3.x series) we cannot rely on specific behavior.
> > > > 
> > > > So given an ethernet-type interface, how do we determine that it is
> > > > wifi?
> > > > 
> > > > DEVTYPE=wlan - not always reliable due to driver and kernel versions
> > > 
> > > if anybody wants to write kernel patches, then making sure that all wireless drivers expose DEVTYPE=wlan is the way to go. If for some reason a driver does not do it, that is a bug.
> > 
> > Yeah, that's nice, and should be done.  It seems a number of drivers
> > don't have it.  Obviously everything mac80211 does, and it seems we're
> > left with:
> > 
> > 1) legacy drivers that only support WEXT (airo, etc)
> > 2) out-of-tree drivers (wl.o and various realtek/ralink stuff?)
> > 
> > So it seems that new best practice is:
> > 
> > a) if DEVTYPE=wlan, hit up nl80211 to determine whether the interface
> > supports nl80211 or WEXT (minimal cfg80211 ports like ipw2x00 don't
> > actually support nl80211 at all and must use WEXT)
> > 
> > b) if DEVTYPE is missing, WEXT can be tried if it is available
> > 
> > c) treat interface as 'ethernet'; out-of-tree WiFi drivers may end up
> > here but that is life
> > 
> > Does that sound valid to everyone else?
> 
> Potential NM fix filed at:
> 
> https://bugzilla.gnome.org/show_bug.cgi?id=740131

Merged after review and backported to 0.9.10 too.

Dan