[net-next,04/11] wimax: fix duplicate initializer warning

From: Arnd Bergmann <arnd@arndb.de>

gcc -Wextra points out multiple fields that use the same index '1'
in the wimax_gnl_policy definition:

net/wimax/stack.c:393:29: warning: initialized field overwritten [-Woverride-init]
net/wimax/stack.c:397:28: warning: initialized field overwritten [-Woverride-init]
net/wimax/stack.c:398:26: warning: initialized field overwritten [-Woverride-init]

This seems to work since all four use the same NLA_U32 value, but it
still appears to be wrong. In addition, there is no intializer for
WIMAX_GNL_MSG_PIPE_NAME, which uses the same index '2' as
WIMAX_GNL_RFKILL_STATE.

Johannes already changed this twice to improve it, but I don't think
there is a good solution, so try to work around it by using a
numeric index and adding comments.

Cc: Johannes Berg <johannes.berg@intel.com>
Fixes: 3b0f31f2b8c9 ("genetlink: make policy common to family")
Fixes: b61a5eea5904 ("wimax: use genl_register_family_with_ops()")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 net/wimax/stack.c | 27 +++++++++++++++++----------
 1 file changed, 17 insertions(+), 10 deletions(-)

On Mon, 2020-10-26 at 22:29 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann <arnd@arndb.de>
> 
> gcc -Wextra points out multiple fields that use the same index '1'
> in the wimax_gnl_policy definition:
> 
> net/wimax/stack.c:393:29: warning: initialized field overwritten [-Woverride-init]
> net/wimax/stack.c:397:28: warning: initialized field overwritten [-Woverride-init]
> net/wimax/stack.c:398:26: warning: initialized field overwritten [-Woverride-init]
> 
> This seems to work since all four use the same NLA_U32 value, but it
> still appears to be wrong. In addition, there is no intializer for
> WIMAX_GNL_MSG_PIPE_NAME, which uses the same index '2' as
> WIMAX_GNL_RFKILL_STATE.

That's funny. This means that WIMAX_GNL_MSG_PIPE_NAME was never used,
since it is meant to be a string, and that won't (usually) fit into 4
bytes...

I suppose that's all an artifact of wimax being completely and utterly
dead anyway. We should probably just remove it.

> Johannes already changed this twice to improve it, but I don't think
> there is a good solution, so try to work around it by using a
> numeric index and adding comments.

Yeah, though maybe there's a better solution now.

Given that we (again and properly) have per-ops policy support, which
really was the thing that broke it here (the commit 3b0f31f2b8c9 you
mentioned), we could split this up into per-ops policies and do the
right thing in the separate policies.

OTOH, that really just makes it use more space, for no discernible
effect to userspace.


So as far as the warning fix is concerned:

Acked-by: Johannes Berg <johannes@sipsolutions.net>


Looks like I introduced a bug there with WIMAX_GNL_MSG_PIPE_NAME, but
obviously nobody cared.

johannes

On Tue, Oct 27, 2020 at 8:22 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
> On Mon, 2020-10-26 at 22:29 +0100, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > gcc -Wextra points out multiple fields that use the same index '1'
> > in the wimax_gnl_policy definition:
> >
> > net/wimax/stack.c:393:29: warning: initialized field overwritten [-Woverride-init]
> > net/wimax/stack.c:397:28: warning: initialized field overwritten [-Woverride-init]
> > net/wimax/stack.c:398:26: warning: initialized field overwritten [-Woverride-init]
> >
> > This seems to work since all four use the same NLA_U32 value, but it
> > still appears to be wrong. In addition, there is no intializer for
> > WIMAX_GNL_MSG_PIPE_NAME, which uses the same index '2' as
> > WIMAX_GNL_RFKILL_STATE.
>
> That's funny. This means that WIMAX_GNL_MSG_PIPE_NAME was never used,
> since it is meant to be a string, and that won't (usually) fit into 4
> bytes...
>
> I suppose that's all an artifact of wimax being completely and utterly
> dead anyway. We should probably just remove it.

Makes sense. I checked
https://en.wikipedia.org/wiki/List_of_WiMAX_networks, and it appears
that these entries are all stale, after everyone has migrated to LTE
or discontinued their service altogether.

NetworkManager appears to have dropped userspace support in 2015
https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
www.linuxwimax.org site had already shut down earlier.

WiMax is apparently still being deployed on airport campus
networks ("AeroMACS"), but in a frequency band that was not
supported by the old Intel 2400m (used in Sandy Bridge laptops
and earlier), which is the only driver using the kernel's wimax
stack.

Inaky, do you have any additional information about possible
users? If we are sure there are none, then I'd suggest removing
all the wimax code directly, otherwise it could go through
drivers/staging/ for a release or two (and move it back in case
there are users after all). I can send a patch if you like.

> So as far as the warning fix is concerned:
>
> Acked-by: Johannes Berg <johannes@sipsolutions.net>
>

Thanks!

        Arnd

> From: Arnd Bergmann <arnd@kernel.org>
> 
> Makes sense. I checked
> https://en.wikipedia.org/wiki/List_of_WiMAX_networks, and it appears
> that these entries are all stale, after everyone has migrated to LTE
> or discontinued their service altogether.
> 
> NetworkManager appears to have dropped userspace support in 2015
> https://bugzilla.gnome.org/show_bug.cgi?id=747846, the
> www.linuxwimax.org site had already shut down earlier.
> 
> WiMax is apparently still being deployed on airport campus
> networks ("AeroMACS"), but in a frequency band that was not
> supported by the old Intel 2400m (used in Sandy Bridge laptops
> and earlier), which is the only driver using the kernel's wimax
> stack.
> 
> Inaky, do you have any additional information about possible
> users? If we are sure there are none, then I'd suggest removing
> all the wimax code directly, otherwise it could go through
> drivers/staging/ for a release or two (and move it back in case
> there are users after all). I can send a patch if you like.

I have not

Every now and then I get the occasional message from a student or
researcher asking for support about a production network, but they
have dwindled in the last years.

My vote would be to scrap the whole thing; if there are die hard
users, they can always rise up and move it back from staging.