Re: pull-request: mac80211 2018-09-03

[David Miller]

From: Johannes Berg 
Date: Mon,  3 Sep 2018 14:15:45 +0200

> This time around for mac80211 I have a larger than usual number of
> fixes, in part because Luca dumped our (Intel's) patches out after
> quite a while - we'll try to make sure this doesn't happen again.
> 
> Shortlog below, as usual, each fix is pretty self-contained but it
> adds up to quite a bit overall.
> 
> Please pull and let me know if there's any problem.

Ok pulled, I'll try to get this merged into net-next in the next day
or two.

Thanks.

Re: pull-request: mac80211-next 2018-05-23

[David Miller]

From: Johannes Berg 
Date: Wed, 23 May 2018 14:14:31 +0200

> Here's a new version of the pull request for net-next, now
> with the stack size fixes included, which were the reason I
> withdrew my earlier one. Other things are also included all
> over the map.
> 
> Please pull and let me know if there's any problem.

Looks good, pulled, thank you.

Re: pull-request: wireless-drivers 2018-05-22

[David Miller]

From: Kalle Valo 
Date: Tue, 22 May 2018 17:28:11 +0300

> here's a pull request to net tree for 4.17. Please let me know if you
> have any problems.

Pulled, thanks Kalle.

Re: pull-request: mac80211 2018-05-23

[David Miller]

From: Johannes Berg 
Date: Wed, 23 May 2018 11:47:57 +0200

> Just another handful of fixes as we wind down towards the
> merge window.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Please don't tell me you will soon queue up a patch that
limits wiphy names to 32 bytes :-)

Re: pull-request: wireless-drivers-next 2018-05-17

[David Miller]

From: Kalle Valo 
Date: Thu, 17 May 2018 11:44:34 +0300

> here's a pull request to net-next for 4.18. I forgot to mention in the
> signed tag was that one id is added to include/linux/mmc/sdio_ids.h but
> that was acked by Ulf.
> 
> I suspect hat because of my merge of wireless-drivers into
> wireless-drivers-next the diffstat from request-pull was wrong again. I
> manually replaced that with the diffstat from my test pull to net-next.
> 
> Please let me know if you have any problems.

Pulled, thank you.

Linux Plumbers Networking Track CFP

[David Miller]

Linux Plumbers Networking Track CFP

This is a call for proposals for the networking track at the 2018
edition of the Linux Plumbers Conference which will be held in
Vancouver on November 13th and November 14th.

The LPC Networking Track is a community event, open to everyone, and
does not require an invitation.

We are seeking talks of 40 minutes in length, accompanied by papers of
2 to 10 pages in length.

Although proposals on finished work are perfectly acceptable, there is
even more value for talks on problems, proposals, and proof-of-concept
solutions that require face-to-face discussions and debate.

Please submit your proposals to the LPC Networking Technical Committee
at:

lpc-net...@vger.kernel.org

Proposals must be submitted by July 11th, and submitters will be
notified of acceptance by August 15th.

The format of the submission and other details can be found at:

http://vger.kernel.org/lpc-networking.html

We are looking forward to seeing everyone in November!

Re: pull-request: mac80211-next 2018-05-09

[David Miller]

From: Johannes Berg 
Date: Wed, 09 May 2018 23:29:37 +0200

> Hi,
> 
> Sorry, scratch that.
> 
> I forgot that this commit:
> 
>> Toke Høiland-Jørgensen (3):
> 
>>   cfg80211: Expose TXQ stats and parameters to userspace
> 
> caused a bunch of "too much stack" warnings - I should put in at least
> the non-driver fix for that first, and then coordinate with Kalle to
> send the driver fixes in too.

Ok, tossed.

Re: pull-request: mac80211 2018-05-09

[David Miller]

From: Johannes Berg 
Date: Wed,  9 May 2018 21:36:12 +0200

> We just have a few fixes this time around.
> 
> Please pull and let me know if there's any problem.

Pulled, thank you!

Re: pull-request: wireless-drivers 2018-04-26

[David Miller]

From: Kalle Valo 
Date: Thu, 26 Apr 2018 13:12:54 +0300

> here's a pull request to net tree, more info below. Please let me know
> if you have any problems.

Pulled, thanks Kalle.

Re: [PATCH 1/3] ethtool: Support ETHTOOL_GSTATS2 command.

[David Miller]

From: Johannes Berg 
Date: Thu, 19 Apr 2018 17:26:57 +0200

> On Thu, 2018-04-19 at 08:25 -0700, Ben Greear wrote:
>> 
>> Maybe this could be in followup patches?  It's going to touch a lot of files,
>> and might be hell to get merged all at once, and I've never used spatch, so
>> just maybe someone else will volunteer that part :)
> 
> I guess you'll have to ask davem. :)

Well, first of all, I really don't like this.

The first reason is that every time I see interface foo become foo2,
foo3 is never far behind it.

If foo was not extensible enough such that we needed foo2, we beter
design the new thing with explicitly better extensibility in mind.

Furthermore, what you want here is a specific filter.  Someone else
will want to filter on another criteria, and the next person will
want yet another.

This needs to be properly generalized.

And frankly if we had moved to ethtool netlink/devlink by now, we
could just add a netlink attribute for filtering and not even be
having this conversation.

Re: [PATCH] mac80211: Fix bad line warning

[David Miller]

From: Masanari Iida 
Date: Wed,  4 Apr 2018 20:53:33 +0900

> After 03fe2debbb2771fb90881e merged during 4.17 marge window,
> I start to see following warning during "make xmldocs"
> 
> ./include/net/mac80211.h:2083: warning: bad line:  >
> 
> Replace ">" with "*" fix the issue.
> 
> Signed-off-by: Masanari Iida 

Adding linux-wireless to CC:

> ---
>  include/net/mac80211.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index d2279b2d61aa..b2f3a0c018e7 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -2080,7 +2080,7 @@ struct ieee80211_txq {
>   *   virtual interface might not be given air time for the transmission of
>   *   the frame, as it is not synced with the AP/P2P GO yet, and thus the
>   *   deauthentication frame might not be transmitted.
> - >
> + *
>   * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
>   *   support QoS NDP for AP probing - that's most likely a driver bug.
>   *
> -- 
> 2.17.0.rc2.3.gc2a499e6c31e
> 

Re: pull-request: wireless-drivers-next 2018-03-29

[David Miller]

From: Kalle Valo 
Date: Thu, 29 Mar 2018 16:21:44 +0300

> here's a pull request to net-next for 4.17. If the merge window starts
> on Sunday this will be the last pull request. Do note that I pulled
> wireless-drivers into wireless-drivers-next as iwlwifi needed some
> patches.
> 
> Please let me know if you have any problems.

Pulled, thank you!

Re: pull-request: mac80211-next 2018-03-29

[David Miller]

From: Johannes Berg 
Date: Thu, 29 Mar 2018 15:10:02 +0200

> Last update for -next, I guess, but I wanted to get the ETSI adaptivity
> requirements code and the eapol-over-nl80211 thing out - both have been
> around for a while. A number of other smaller things are also there, of
> course.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: [PATCH net-next 0/5] Introduce net_rwsem to protect net_namespace_list

[David Miller]

From: Kirill Tkhai 
Date: Thu, 29 Mar 2018 19:20:23 +0300

> The series introduces fine grained rw_semaphore, which will be used
> instead of rtnl_lock() to protect net_namespace_list.
> 
> This improves scalability and allows to do non-exclusive sleepable
> iteration for_each_net(), which is enough for most cases.
> 
> scripts/get_maintainer.pl gives enormous list of people, and I add
> all to CC.
> 
> Note, that this patch is independent of "Close race between
> {un, }register_netdevice_notifier and pernet_operations":
> https://patchwork.ozlabs.org/project/netdev/list/?series=36495
> 
> Signed-off-by: Kirill Tkhai 

Great stuff!

Series applied, thanks!

Re: [PATCH 3/4] net: Use octal not symbolic permissions

[David Miller]

Applied.

Re: pull-request: wireless-drivers-next 2018-03-24

[David Miller]

From: Kalle Valo 
Date: Sat, 24 Mar 2018 14:30:01 +0200

> here's the first pull request to net-next for 4.17. What's special here
> is the addition of a new bluetooth driver, but that's been acked by
> Marcel. Also we add a new include file to include/net because of that.
> 
> Please let me know if you have any problems.

Also pulled, thanks Kalle.

Re: pull-request: wireless-drivers 2018-03-24

[David Miller]

From: Kalle Valo 
Date: Sat, 24 Mar 2018 13:03:13 +0200

> This is a pull request to the net tree for 4.16. I'm not planning to
> send anything more in this cycle for 4.16, unless something really major
> comes up.
> 
> Please let me know if you have any problems.

Pulled.

Re: pull-request: mac80211 2018-03-21

[David Miller]

From: Johannes Berg 
Date: Wed, 21 Mar 2018 13:06:54 +0100

> Another few fixes - one for hwsim, so not really all that interesting,
> and two patches to work around an ath9k_htc problem.
> 
> Note that I pulled your net tree today, so you may need to be careful
> to not fast-forward if you don't merge anything else before this.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks a lot Johannes.

Re: [PATCH] net: drivers/net: Remove unnecessary skb_copy_expand OOM messages

[David Miller]

From: Joe Perches 
Date: Mon, 12 Mar 2018 08:07:12 -0700

> skb_copy_expand without __GFP_NOWARN already does a dump_stack
> on OOM so these messages are redundant.
> 
> Signed-off-by: Joe Perches 

Ok, applied to net-next, thanks.

Re: pull-request: wireless-drivers 2018-03-08

[David Miller]

From: Kalle Valo 
Date: Thu, 08 Mar 2018 17:18:29 +0200

> here's a pull requsest to net tree for 4.16. Since the merge window I
> have had some clannges to keep up with some patches but catching up now.
> 
> There should be nothing special here but please let me know if you have
> any problems.

Pulled, thank you.

Re: [PATCH trivial resend^2] net: Spelling s/stucture/structure/

[David Miller]

From: Geert Uytterhoeven 
Date: Fri,  2 Mar 2018 14:43:23 +0100

> Signed-off-by: Geert Uytterhoeven 

I'll let the trivial tree pick this up.

Re: pull-request: mac80211-next 2018-03-02

[David Miller]

From: Johannes Berg 
Date: Fri,  2 Mar 2018 10:06:54 +0100

> Like before... Thanks for pulling net into net-next, the Add-BA patch
> below would otherwise not really be possible :-)

No problem.

> The only sort of interesting thing is the fast-RX improvements from
> Felix, they help on routers where these things (A-MSDU and 4-addr mode)
> are more important and where fast-RX really helps due to the reduced
> CPU load.
> 
> Please pull and let me know if there's any problem.

Ok, pulled, thanks Johannes.

Re: pull-request: mac80211 2018-03-02

[David Miller]

From: Johannes Berg 
Date: Fri,  2 Mar 2018 10:04:46 +0100

> Just a few more patches, but I'll be travelling over the next
> week and probably won't be able to send things to you then.
> 
> Please pull and let me know if there's any problem.

Ok, pulled, safe travels.

Thanks!

Re: pull-request: mac80211-next 2018-02-22

[David Miller]

From: Johannes Berg <johan...@sipsolutions.net>
Date: Fri, 23 Feb 2018 12:29:39 +0100

> On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote:
>> 
>> Pulled, thank you!
> 
> Thanks. I just realized that I have a patch pending for -next that
> depends another commit in net/mac80211 (or would otherwise conflict
> badly while applying, and again while merging later), could I ask you
> to pull net into net-next at some point now?

I'll get that to happen in the next day or two.  Pablo asked for this
as well.

Re: pull-request: mac80211-next 2018-02-22

[David Miller]

From: Johannes Berg 
Date: Thu, 22 Feb 2018 21:16:18 +0100

> Wireless is slow ... but we're preparing for HE (802.11ax),
> so I guess soon we'll have a big chunk of work coming :-)

I wondered where you guys have been hiding :-)

> Please pull and let me know if there's any problem.

Pulled, thank you!

Re: pull-request: mac80211 2018-02-22

[David Miller]

From: Johannes Berg 
Date: Thu, 22 Feb 2018 21:08:39 +0100

> A bunch of fixes, including the nla_put_string() issue
> just in from Kees. Otherwise nothing really super urgent
> or interesting.
> 
> Please pull and let me know if there's any problem.

Pulled.

Thanks for taking care of that NLA_STRING thing so fast.

Re: [PATCH v2] net: make getname() functions return length rather than use int* parameter

[David Miller]

From: Denys Vlasenko 
Date: Mon, 12 Feb 2018 20:00:20 +0100

> Changes since v1:
> Added changes in these files:
> drivers/infiniband/hw/usnic/usnic_transport.c
> drivers/staging/lustre/lnet/lnet/lib-socket.c
> drivers/target/iscsi/iscsi_target_login.c
> drivers/vhost/net.c
> fs/dlm/lowcomms.c
> fs/ocfs2/cluster/tcp.c
> security/tomoyo/network.c
> 
> 
> Before:
> All these functions either return a negative error indicator,
> or store length of sockaddr into "int *socklen" parameter
> and return zero on success.
> 
> "int *socklen" parameter is awkward. For example, if caller does not
> care, it still needs to provide on-stack storage for the value
> it does not need.
> 
> None of the many FOO_getname() functions of various protocols
> ever used old value of *socklen. They always just overwrite it.
> 
> This change drops this parameter, and makes all these functions, on success,
> return length of sockaddr. It's always >= 0 and can be differentiated
> from an error.
> 
> Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
> 
> rpc_sockname() lost "int buflen" parameter, since its only use was
> to be passed to kernel_getsockname() as  and subsequently
> not used in any way.
> 
> Userspace API is not changed.
> 
> textdata bss  dec hex filename
> 30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
> 30108109 2633612  873672 33615393 200ee21 vmlinux.o
> 
> Signed-off-by: Denys Vlasenko 

Applied to net-next, thanks Denys.

Re: [PATCH] net: make getname() functions return length rather than use int* parameter

[David Miller]

From: Denys Vlasenko 
Date: Mon, 12 Feb 2018 15:15:18 +0100

> Before:
> All these functions either return a negative error indicator,
> or store length of sockaddr into "int *socklen" parameter
> and return zero on success.
> 
> "int *socklen" parameter is awkward. For example, if caller does not
> care, it still needs to provide on-stack storage for the value
> it does not need.
> 
> None of the many FOO_getname() functions of various protocols
> ever used old value of *socklen. They always just overwrite it.
> 
> This change drops this parameter, and makes all these functions, on success,
> return length of sockaddr. It's always >= 0 and can be differentiated
> from an error.
> 
> Tests in callers are changed from "if (err)" to "if (err < 0)", where needed.
> 
> rpc_sockname() lost "int buflen" parameter, since its only use was
> to be passed to kernel_getsockname() as  and subsequently
> not used in any way.
> 
> Userspace API is not changed.
> 
> textdata bss  dec hex filename
> 30108430 2633624  873672 33615726 200ef6e vmlinux.before.o
> 30108109 2633612  873672 33615393 200ee21 vmlinux.o
> 
> Signed-off-by: Denys Vlasenko 

Please do an allmodconfig build, there are still some conversions you
missed:

security/tomoyo/network.c: In function ‘tomoyo_socket_listen_permission’:
security/tomoyo/network.c:658:19: warning: passing argument 3 of 
‘sock->ops->getname’ makes integer from pointer without a cast 
[-Wint-conversion]
, _len, 0);
   ^
security/tomoyo/network.c:658:19: note: expected ‘int’ but argument is of type 
‘int *’
security/tomoyo/network.c:657:21: error: too many arguments to function 
‘sock->ops->getname’
   const int error = sock->ops->getname(sock, (struct sockaddr *)
 ^~~~
fs/dlm/lowcomms.c: In function ‘lowcomms_error_report’:
fs/dlm/lowcomms.c:495:6: error: too many arguments to function 
‘kernel_getpeername’
  kernel_getpeername(con->sock, (struct sockaddr *), )) {
  ^~
fs/dlm/lowcomms.c: In function ‘tcp_accept_from_sock’:
fs/dlm/lowcomms.c:761:7: warning: passing argument 3 of ‘newsock->ops->getname’ 
makes integer from pointer without a cast [-Wint-conversion]
   , 2)) {
   ^
fs/dlm/lowcomms.c:761:7: note: expected ‘int’ but argument is of type ‘int *’
fs/dlm/lowcomms.c:760:6: error: too many arguments to function 
‘newsock->ops->getname’
  if (newsock->ops->getname(newsock, (struct sockaddr *),
  ^~~

Re: pull-request: wireless-drivers-next 2018-02-08

[David Miller]

From: Kalle Valo 
Date: Thu, 08 Feb 2018 19:54:15 +0200

> first set of fixes for 4.16, unusually many when the merge window hasn't
> even closed yet. Especially the ssb fix is important so I hope there's
> still time to get this to 4.16-rc1. As you can see from the diffstat
> there's one PCI id addition but that has been acked by Bjorn.
> 
> Please let me know if you have any problems.

Device ID additions are always ok regardless of what state of development
we are in.

Pulled, thanks Kalle.

Re: pull-request: wireless-drivers-next 2018-01-26

[David Miller]

From: Kalle Valo 
Date: Fri, 26 Jan 2018 19:04:29 +0200

> this is a pull request to net-next for 4.16, more info in the signed
> tag below. Please let me know if you have any problems.

Pulled, thanks Kalle.

Re: pull-request: wireless-drivers 2018-01-26

[David Miller]

From: Kalle Valo 
Date: Fri, 26 Jan 2018 18:33:33 +0200

> this is a pull request to the net tree for 4.15. I hate to do late pull
> requests like this but today Sven Joachim found a serious regression in
> one of ssb patches, I hope there's still enough time to get this to
> 4.15.
> 
> But if it's too late, just let me know and I'll queue this for 4.16.

I think this is going to have to wait for 4.16, I just sent what I hope
is my last pull to Linus for this cycle.

Thanks.

Re: pull-request: mac80211-next 2018-01-22

[David Miller]

From: Johannes Berg 
Date: Mon, 22 Jan 2018 14:15:00 +0100

> A few more (only four, really) changes have come in, so I figured
> since the merge window hasn't opened yesterday, I'd still send them
> to you.
> 
> Please pull and let me know if there's any problem.

I had to resolve a conflict in mac80211_hwsim.c, please check my
resolution and send me any fixes which are necessary.

Thank you.

Re: pull-request: wireless-drivers-next 2018-01-19

[David Miller]

From: Kalle Valo 
Date: Fri, 19 Jan 2018 10:59:33 +0200

> a pull request to net-next tree for 4.16. This should be the last pull
> request in this cycle, unless Linus releases -rc9 of course. Only few
> patches so should be an easy one. Please let me know if there are any
> problems.

Pulled, thanks Kalle.

Re: pull-request: wireless-drivers 2018-01-17

[David Miller]

From: Kalle Valo 
Date: Wed, 17 Jan 2018 16:30:21 +0200

> here are few more important fixes to the net tree for 4.15, I hope they
> still make it. Please let me know if there are any problems.

Pulled, thanks Kalle.

Re: [PATCH] cfg80211: fix station info handling bugs

[David Miller]

From: Johannes Berg 
Date: Tue, 16 Jan 2018 23:20:22 +0100

> From: Johannes Berg 
> 
> Fix two places where the structure isn't initialized to zero,
> and thus can't be filled properly by the driver.
> 
> Fixes: 4a4b8169501b ("cfg80211: Accept multiple RSSI thresholds for CQM")
> Fixes: 9930380f0bd8 ("cfg80211: implement IWRATE")
> Signed-off-by: Johannes Berg 
> ---
> Dave, can you apply this as an exception? I'm not really expecting
> any other patches to show up now, and seems easier to have a single
> patch than a whole pull request (especially now that patchwork seems
> to be swallowing mine ...)

Sure, applied, thanks Johannes.

Re: pull-request: mac80211 2018-01-15

[David Miller]

From: Johannes Berg 
Date: Mon, 15 Jan 2018 11:51:53 +0100

> I know this comes last minute, so if it doesn't make it then
> I guess we can live with that, but I got the earliest of the
> patches here on Wednesday last week, and that was the most
> uninteresting one - the others didn't come in until Saturday.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: pull-request: wireless-drivers-next 2018-01-13

[David Miller]

From: Kalle Valo 
Date: Sat, 13 Jan 2018 12:33:43 +0200

> this is a pull request to net-next tree for 4.16, more info in the
> signed tag below. I'm not expecting any problems but please let me know
> if you have any.

Pulled, thanks Kalle.

Re: pull-request: wireless-drivers 2018-01-09

[David Miller]

From: Kalle Valo 
Date: Tue, 09 Jan 2018 14:59:37 +0200

> My first pull request in 2018 so Happy New Year!

Happy New Year to you as well :)

> This is for 4.15 to the net tree. Only two fixes this time so should be
> an easy pull.
> 
> This is quite late due to the holidays but it has been pretty quiet so I
> guess I wasn't the only one trying to not touch the computer ;) And
> Linus said that he will be releasing -rc8 anyway so this shouldn't be
> that late.
> 
> Please let me know if you have any problems.

Pulled, thanks Kalle.

Re: pull-request: mac80211 2018-01-04

[David Miller]

From: Johannes Berg 
Date: Thu,  4 Jan 2018 15:56:31 +0100

> It's probably getting quite late for the current cycle, but
> these fixes seemed important enough to send them to you
> separately anyway.
> 
> Please pull and let me know if there's any problem.

Sure, no problem, pulled.

Re: pull-request: wireless-drivers-next 2017-12-18

[David Miller]

From: Kalle Valo 
Date: Mon, 18 Dec 2017 16:17:24 +0200

> a pull request for 4.16 to net-next tree. This is a big one, but on the
> other hand most of the stuff here has been some time on linux-next so
> hopefully there are no nasty surprises. Even though Arnd just send a
> patch[1] five minutes ago about fixing a wcn36xx build warning, but I
> don't think that's critical enough to hold up this, so I'll send it to
> you in the next pull request.
> 
> But this time we actually have a merge conflict due to a000 hardware
> rename in iwlwifi:
> 
> CONFLICT (content): Merge conflict in 
> drivers/net/wireless/intel/iwlwifi/pcie/drv.c
> 
> The fix is quite straightforward, take the 22000 versions and manually
> add an entry for 0xA0F0 device:
> 
> {IWL_PCI_DEVICE(0xA0F0, 0x, iwl22000_2ax_cfg_hr)},
> 
> I put the 'git diff' output of my test resolution below, hopefully it
> helps. I'll also Cc Luca so he can correct any mistakes I did :)
> 
> Please let me know if you have any problems.

Pulled, and thanks for the resolution diff.  It helped a lot.

Re: pull-request: mac80211 2017-12-19

[David Miller]

From: Johannes Berg 
Date: Tue, 19 Dec 2017 10:57:09 +0100

> Other work has been hectic, and I got caught by rc4. We still
> have a few more fixes though - and more build issues were
> reported.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: 76f43b4 fix for stable

[David Miller]

From: Richard Schütz 
Date: Mon, 11 Dec 2017 14:51:33 +0100

> as per netdev-FAQ.txt I'm requesting the submission of commit
> 57629915d568c522ac1422df7bba4bee5b5c7a7c ("mac80211: Fix addition of
> mesh configuration element") to stable. Because of automatic selection
> commit 76f43b4c0a9337af22827d78de4f2b8fd5328489 ("mac80211: Remove
> invalid flag operations in mesh TSF synchronization") was introduced
> into stable recently without this accompanying fix.

Johannes, please take care of this.

Thank you.

Re: pull-request: mac80211 2017-12-11

[David Miller]

From: Johannes Berg 
Date: Mon, 11 Dec 2017 10:52:35 +0100

> Three fixes, two related to build issues with the new regdb stuff,
> and one for some patch overlap problem that caused locking to be
> missing which in turn caused lots of warnings.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks.

Re: pull-request: wireless-drivers 2017-12-08

[David Miller]

From: Kalle Valo 
Date: Fri, 08 Dec 2017 16:32:16 +0200

> this is a pull request to net tree for 4.15, more info in the signed tag
> below. All small fixes and not really expecting any problems, but please
> let me know if you have any.

Pulled, thanks Kalle.

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

[David Miller]

From: David Ahern 
Date: Tue, 5 Dec 2017 11:15:29 -0700

> Is the patch I sent as an attachment good or should I re-send
> standalone? (don't see it in patchwork)

Patchwork has been wonky laterly, please resubmit as a fresh
email for rewiew.

Thanks.

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

[David Miller]

From: Johannes Berg <johan...@sipsolutions.net>
Date: Tue, 05 Dec 2017 18:30:10 +0100

> On Tue, 2017-12-05 at 11:41 -0500, David Miller wrote:
>> 
>> There is no reasonable interpretation for what that application is
>> doing, so I think we can safely call that case as buggy.
>> 
>> We are only trying to handle the situation where a U8 attribute
>> is presented as a bonafide U32 or a correct U8.
>> 
>> Does this make sense?
> 
> Well the application is buggy, but we don't really know in what way?
> Perhaps somebody even did the equivalent of
> nla_put_u32(ATTR, cpu_to_le32(x))
> when they noticed it was broken on BE, and end up with a similar case
> as I had above.
> 
> I don't think there's a good solution to this, applications must be
> fixed anyhow. I'm just saying that I'd save the extra code and stay
> compatible with applications as written today, even if they're now
> broken on BE - and rely on the warning to fix it. Trying to fix it up
> seems to have the potential to just break something else.

You might be right.

Ok let's just go with the warning + existing behavior for now.

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

[David Miller]

From: David Ahern <dsah...@gmail.com>
Date: Tue, 5 Dec 2017 09:41:21 -0700

> On 12/5/17 9:34 AM, Johannes Berg wrote:
>> On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote:
>>>
>>>> We could try to fix up the big endian problem here, but we
>>>> don't know *how* userspace misbehaved - if using nla_put_u32
>>>> then we could, but we also found a debug tool (which we'll
>>>> ignore for the purposes of this regression) that was putting
>>>> the padding into the length.
>> 
>>> We're stuck with this thing forever... I'd like to consider other
>>> options.
>>>
>>> I've seen this problem at least one time before, therefore I
>>> suggest when we see a U8 attribute with a U32's length:
>>>
>>> 1) We access it as a u32, this takes care of all endianness
>>>issues.
>> 
>> Possible, but as I said above, I've seen at least one tool (a debug
>> only script) now that will actually emit a U8 followed by 3 bytes of
>> padding to make it netlink-aligned, but set the length to 4. That would
>> be broken by making this change.
>> 
>> I'm not saying this is bad - but there are different levels of
>> compatibility and I'd probably go for "bug compatibility" here rather
>> than "fix-it-up compatibility".
>> 
>> Your call, ultimately - I've already fixed the tool I had found :-)
>> 
>>> 2) We emit a warning so that the app gets fixes.
>> 
> 
> The attached is my proposal. Basically, allow it the length mismatch but
> print a warning. This restores previous behavior and tells users of bad
> commands.

Where is the "access the U8 attribute as a U32 if length is 4" part
of my #1 above?

That's essential to handle this properly on all endianness.

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

[David Miller]

From: Johannes Berg <johan...@sipsolutions.net>
Date: Tue, 05 Dec 2017 17:34:21 +0100

> On Tue, 2017-12-05 at 11:31 -0500, David Miller wrote:
>> 
>> > We could try to fix up the big endian problem here, but we
>> > don't know *how* userspace misbehaved - if using nla_put_u32
>> > then we could, but we also found a debug tool (which we'll
>> > ignore for the purposes of this regression) that was putting
>> > the padding into the length.
> 
>> We're stuck with this thing forever... I'd like to consider other
>> options.
>> 
>> I've seen this problem at least one time before, therefore I
>> suggest when we see a U8 attribute with a U32's length:
>> 
>> 1) We access it as a u32, this takes care of all endianness
>>issues.
> 
> Possible, but as I said above, I've seen at least one tool (a debug
> only script) now that will actually emit a U8 followed by 3 bytes of
> padding to make it netlink-aligned, but set the length to 4. That would
> be broken by making this change.

There is no reasonable interpretation for what that application is
doing, so I think we can safely call that case as buggy.

We are only trying to handle the situation where a U8 attribute
is presented as a bonafide U32 or a correct U8.

Does this make sense?

Re: [PATCH net 1/2] netlink: add NLA_U8_BUGGY attribute type

[David Miller]

From: Johannes Berg 
Date: Sat,  2 Dec 2017 21:23:31 +0100

> From: Johannes Berg 
> 
> This netlink type is used only for backwards compatibility
> with broken userspace that used the wrong size for a given
> u8 attribute, which is now rejected. It would've been wrong
> before already, since on big endian the wrong value (always
> zero) would be used by the kernel, but we can't break the
> existing deployed userspace - hostapd for example now fails
> to initialize entirely.
> 
> We could try to fix up the big endian problem here, but we
> don't know *how* userspace misbehaved - if using nla_put_u32
> then we could, but we also found a debug tool (which we'll
> ignore for the purposes of this regression) that was putting
> the padding into the length.
> 
> Fixes: 28033ae4e0f5 ("net: netlink: Update attr validation to require exact 
> length for some types")
> Signed-off-by: Johannes Berg 

We're stuck with this thing forever... I'd like to consider other
options.

I've seen this problem at least one time before, therefore I
suggest when we see a U8 attribute with a U32's length:

1) We access it as a u32, this takes care of all endianness
   issues.

2) We emit a warning so that the app gets fixes.

Thanks.

Re: pull-request: mac80211 2017-11-27

[David Miller]

From: Johannes Berg 
Date: Mon, 27 Nov 2017 11:32:56 +0100

> Here are a few more fixes, one of which fixes the crash Florian
> reported which I think is the same that zero-day reported.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: pull-request: wireless-drivers 2017-11-22

[David Miller]

From: Kalle Valo 
Date: Wed, 22 Nov 2017 17:27:22 +0200

> here's the first pull request to net tree for 4.15. Please let me know
> if there are any problems.

Pulled, thanks Kalle!

Re: pull-request: mac80211 2017-11-20

[David Miller]

From: Johannes Berg <johan...@sipsolutions.net>
Date: Tue, 21 Nov 2017 12:24:32 +0100

> On Tue, 2017-11-21 at 20:17 +0900, David Miller wrote:
>> From: Johannes Berg <johan...@sipsolutions.net>
>> Date: Mon, 20 Nov 2017 17:06:44 +0100
>> 
>> >   ssh://korg/pub/scm/linux/kernel/git/jberg/mac80211.git 
>> > tags/mac80211-for-davem-2017-11-20
>> 
>> That's an awesome URL, but I don't think I'll be able to pull
>> from it :-)
> 
> Huh. That's what I get for following Konstantin's advice to use
> insteadOf in git configuration ...
> 
> Should be
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
> tags/mac80211-for-davem-2017-11-20
> 
> (or https if you prefer)

That works better, pulled, thanks!

Re: pull-request: mac80211 2017-11-20

[David Miller]

From: Johannes Berg 
Date: Mon, 20 Nov 2017 17:06:44 +0100

>   ssh://korg/pub/scm/linux/kernel/git/jberg/mac80211.git 
> tags/mac80211-for-davem-2017-11-20

That's an awesome URL, but I don't think I'll be able to pull
from it :-)

Re: pull-request: wireless-drivers-next 2017-11-11

[David Miller]

From: Kalle Valo 
Date: Sat, 11 Nov 2017 15:03:14 +0200

> some more patches to net-next for v4.15. Even though I applied the last
> patch only on Saturday morning, all these have been tested by kbuild bot
> and most of them should also be in linux-next. Please let me know if
> there are any problems.

Pulled, but looking at your merge commit message:

> Major changes:
> 
> iwlwifi
> 
> * some new PCI IDs

I doubt this was the only major change in here :-)))

Re: pull-request: wireless-drivers 2017-10-31

[David Miller]

From: Kalle Valo 
Date: Tue, 31 Oct 2017 17:19:24 +0200

> here's a pull request to net tree for 4.14. Due to the ath10k security
> issue I would like to get this to 4.14 still.
> 
> Please let me know if there are any problems.

Pulled, thanks a lot.

Re: pull-request: mac80211 2017-10-25

[David Miller]

From: Johannes Berg 
Date: Wed, 25 Oct 2017 16:03:42 +0200

> Here are a few more fixes for net, we started comprehensive testing
> for the security issues and found that the problem wasn't addressed
> in TKIP, so that's included, along with a handful other fixes.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: pull-request: wireless-drivers-next 2017-10-18

[David Miller]

From: Kalle Valo 
Date: Wed, 18 Oct 2017 12:42:31 +0300

> this for 4.15 stream to net-next tree. Please let me know if there are
> any problems.

Pulled, thanks Kalle.

Re: [PATCH] netlink: fix netlink_ack() extack race

[David Miller]

From: Johannes Berg 
Date: Mon, 16 Oct 2017 17:09:53 +0200

> From: Johannes Berg 
> 
> It seems that it's possible to toggle NETLINK_F_EXT_ACK
> through setsockopt() while another thread/CPU is building
> a message inside netlink_ack(), which could then trigger
> the WARN_ON()s I added since if it goes from being turned
> off to being turned on between allocating and filling the
> message, the skb could end up being too small.
> 
> Avoid this whole situation by storing the value of this
> flag in a separate variable and using that throughout the
> function instead.
> 
> Fixes: 2d4bc93368f5 ("netlink: extended ACK reporting")
> Signed-off-by: Johannes Berg 

Applied and queued up for -stable.

Re: [PATCH] netlink: use NETLINK_CB(in_skb).sk instead of looking it up

[David Miller]

From: Johannes Berg 
Date: Mon, 16 Oct 2017 16:57:49 +0200

> From: Johannes Berg 
> 
> When netlink_ack() reports an allocation error to the sending
> socket, there's no need to look up the sending socket since
> it's available in the SKB's CB. Use that instead of going to
> the trouble of looking it up.
> 
> Note that the pointer is only available since Eric Biederman's
> commit 3fbc290540a1 ("netlink: Make the sending netlink socket availabe in 
> NETLINK_CB")
> which is far newer than the original lookup code (Oct 2003)
> (though the field was called 'ssk' in that commit and only got
> renamed to 'sk' later, I'd actually argue 'ssk' was better - or
> perhaps it should've been 'source_sk' - since there are so many
> different 'sk's involved.)
> 
> Signed-off-by: Johannes Berg 

Applied to net-next.

Re: pull-request: mac80211-next 2017-10-13

[David Miller]

From: Johannes Berg 
Date: Fri, 13 Oct 2017 17:53:31 +0200

> Sorry for the quick succession - there were a few issues with
> the last pull request that only got noticed now, so I'm fixing
> those here.
> 
> Please pull and let me know if there's any problem.

No worries, pulled, thanks Johannes.

Re: pull-request: wireless-drivers 2017-10-13

[David Miller]

From: Kalle Valo 
Date: Fri, 13 Oct 2017 10:25:14 +0300

> here's a pull request to net tree, more info in the signed tag below.
> Please let me know if there are any problems.

Pulled, thanks Kalle.

Re: pull-request: mac80211-next 2017-10-11

[David Miller]

From: Johannes Berg 
Date: Wed, 11 Oct 2017 14:36:12 +0200

> Here's a -next pull request. The only bigger thing here is the
> addition of the regulatory database as firmware, which will
> allow us to - over time - get rid of CRDA, as well as having
> the option of adding more fields to the database where needed,
> this would've been extremely complex with CRDA because it had
> not been built with extensibility in mind.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks!

Re: [PATCH] timer: Remove meaningless .data/.function assignments

[David Miller]

From: Kees Cook 
Date: Mon, 9 Oct 2017 17:10:32 -0700

> Several timer users needlessly reset their .function/.data fields during
> their timer callback, but nothing else changes them. Some users do not
> use their .data field at all. Each instance is removed here.
> 
> Cc: Krzysztof Halasa 
> Cc: Aditya Shankar 
> Cc: Ganesh Krishna 
> Cc: Greg Kroah-Hartman 
> Cc: Jens Axboe 
> Cc: net...@vger.kernel.org
> Cc: linux-wireless@vger.kernel.org
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Kees Cook 
> Acked-by: Greg Kroah-Hartman  # for staging
> Acked-by: Krzysztof Halasa  # for wan/hdlc*
> Acked-by: Jens Axboe  # for amiflop
> ---
> This should go via the timer/core tree, please. It's been acked by each
> of the maintainers. Thanks!

For networking bits:

Acked-by: David S. Miller 

Re: pull-request: mac80211 2017-10-09

[David Miller]

From: Johannes Berg 
Date: Mon,  9 Oct 2017 09:40:12 +0200

> The QCA folks found another netlink problem - we were missing validation
> of some attributes. It's not super problematic since one can only read a
> few bytes beyond the message (and that memory must exist), but here's the
> fix for it.
> 
> I thought perhaps we can make nla_parse_nested() require a policy, but
> given the two-stage validation/parsing in regular netlink that won't work.
> 
> Please pull and let me know if there's any problem.

Yeah, nested parsing is messy validation-wise.

Pulled, thanks Johannes.

Re: [PATCH V2] Fix a sleep-in-atomic bug in shash_setkey_unaligned

[David Miller]

From: Herbert Xu 
Date: Thu, 5 Oct 2017 11:40:54 +0800

> On Tue, Oct 03, 2017 at 07:45:06PM -0300, Marcelo Ricardo Leitner wrote:
>>
>> > Usually if you're invoking setkey from a non-sleeping code-path
>> > you're probably doing something wrong.
>> 
>> Usually but not always. There are 3 calls to that function on SCTP
>> code:
>> - pack a cookie, which is sent on an INIT_ACK packet to the client
>> - unpack the cookie above, after it is sent back by the client on a
>>   COOKIE_ECHO packet
>> - send a chunk authenticated by a hash
> 
> I'm not talking about the code-path in question.  I'm talking
> about the function which generates the secret key in the first
> place.  AFAICS that's only called in GFP_KERNEL context.  What
> am I missing?

The setkey happens in functions like sctp_pack_cookie() and
sctp_unpack_cookie(), which seems to run from software interrupts.

Re: [PATCH 04/13] timer: Remove init_timer_pinned() in favor of timer_setup()

[David Miller]

From: Kees Cook 
Date: Wed,  4 Oct 2017 16:26:58 -0700

> This refactors the only users of init_timer_pinned() to use
> the new timer_setup() and from_timer(). Drops the definition of
> init_timer_pinned().
> 
> Cc: Chris Metcalf 
> Cc: Thomas Gleixner 
> Cc: net...@vger.kernel.org
> Signed-off-by: Kees Cook 

For networking:

Acked-by: David S. Miller 

Re: [PATCH 05/13] timer: Remove init_timer_deferrable() in favor of timer_setup()

[David Miller]

From: Kees Cook 
Date: Wed,  4 Oct 2017 16:26:59 -0700

> This refactors the only users of init_timer_deferrable() to use
> the new timer_setup() and from_timer(). Removes definition of
> init_timer_deferrable().
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Michael Ellerman 
> Cc: Sebastian Reichel 
> Cc: Harish Patil 
> Cc: Manish Chopra 
> Cc: Kalle Valo 
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: net...@vger.kernel.org
> Cc: linux-wireless@vger.kernel.org
> Signed-off-by: Kees Cook 

For networking:

Acked-by: David S. Miller 

Re: [PATCH 10/13] timer: Remove expires and data arguments from DEFINE_TIMER

[David Miller]

From: Kees Cook 
Date: Wed,  4 Oct 2017 16:27:04 -0700

> Drop the arguments from the macro and adjust all callers with the
> following script:
> 
>   perl -pi -e 's/DEFINE_TIMER\((.*), 0, 0\);/DEFINE_TIMER($1);/g;' \
> $(git grep DEFINE_TIMER | cut -d: -f1 | sort -u | grep -v timer.h)
> 
> Signed-off-by: Kees Cook 
> Acked-by: Geert Uytterhoeven  # for m68k parts

For networking:

Acked-by: David S. Miller 

Re: pull-request: wireless-drivers 2017-09-25

[David Miller]

From: Kalle Valo 
Date: Mon, 25 Sep 2017 11:55:22 +0300

> here a pull request to net for 4.14, more info in the signed tag below.
> Please let me know if there are any problems.

Pulled, thanks Kalle.

Re: [PATCH v4 8/9] netlink: fix nla_put_{u8,u16,u32} for KASAN

[David Miller]

From: Arnd Bergmann 
Date: Fri, 22 Sep 2017 23:29:19 +0200

> When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large
> stack frames in some functions. This goes unnoticed normally because
> CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit
> 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with
> KASAN=y").
> 
> The kernelci.org build bot however has the warning enabled and that led
> me to investigate it a little further, as every build produces these warnings:
> 
> net/wireless/nl80211.c:4389:1: warning: the frame size of 2240 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1895:1: warning: the frame size of 3776 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/wireless/nl80211.c:1410:1: warning: the frame size of 2208 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> net/bridge/br_netlink.c:1282:1: warning: the frame size of 2544 bytes is 
> larger than 2048 bytes [-Wframe-larger-than=]
> 
> Most of this problem is now solved in gcc-8, which can consolidate
> the stack slots for the inline function arguments. On older compilers
> we can add a workaround by declaring a local variable in each function
> to pass the inline function argument.
> 
> Cc: sta...@vger.kernel.org
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
> Signed-off-by: Arnd Bergmann 

Applied.

Re: [PATCH v4 7/9] rocker: fix rocker_tlv_put_* functions for KASAN

[David Miller]

From: Arnd Bergmann 
Date: Fri, 22 Sep 2017 23:29:18 +0200

> Inlining these functions creates lots of stack variables that each take
> 64 bytes when KASAN is enabled, leading to this warning about potential
> stack overflow:
> 
> drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 
> 'ofdpa_cmd_flow_tbl_add':
> drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of 
> 2752 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
> 
> gcc-8 can now consolidate the stack slots itself, but on older versions
> we get the same behavior by using a temporary variable that holds a
> copy of the inline function argument.
> 
> Cc: sta...@vger.kernel.org
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715
> Signed-off-by: Arnd Bergmann 

Applied.

Re: pull-request: mac80211 2017-11-19

[David Miller]

From: Johannes Berg 
Date: Tue, 19 Sep 2017 09:20:47 +0200

> Here's a new set of two small changes to prevent null pointer
> dereferences on malformed netlink messages.
> 
> Please pull and let me know if there's any problem.

Pulled, thank you.

Re: pull-request: wireless-drivers 2017-09-08

[David Miller]

From: Kalle Valo 
Date: Fri, 08 Sep 2017 18:50:01 +0300

> few fixes to net tree for 4.14. Note that this pull request contains the
> iwlwifi fix Linus hopes to have by end of the merge window. Please let
> me know if there are any problems.

Pulled, thanks for following up particularly with the iwlwifi fix.

Re: pull-request: mac80211 2017-09-07

[David Miller]

From: Johannes Berg 
Date: Thu,  7 Sep 2017 09:09:38 +0200

> During my long absence some things have accumulated, but there wasn't
> actually all that much that could've gone into the last cycle, and a
> fix or two was taken care of by others.
> 
> The most important thing here is probably the deadlock fix that a few
> people have run into on 4.13, but that was only identified now, and
> perhaps the 40 MHz fix from Emmanuel that helps avoid iwlwifi firmware
> crashes.
> 
> Please pull and let me know if there's any problem.

Pulled, thanks.

Re: [GIT] Networking

[David Miller]

From: Linus Torvalds 
Date: Wed, 6 Sep 2017 16:27:15 -0700

> This pull request completely breaks Intel wireless for me.
> 
> This is my trusty old XPS 13 (9350), using Intel Wireless 8260 (rev 3a).
> 
> That remains a very standard Intel machine with absolutely zero odd
> things going on.
> 
> The firmware is iwlwifi-8000C-28.ucode from
> iwl7260-firmware-25.30.13.0-75.fc26.noarch, and the kernel reports
 ...

Johannes and other Intel folks please look into this.

net-next is CLOSED

[David Miller]

If it isn't a bug fix and it isn't in patchwork right now, I don't
want to see it.

This time around inappropriate submissions will be silently marked
as "deferred" in patchwork and not even looked at by me.

Thanks.

Re: pull-request: wireless-drivers-next 2017-09-01

[David Miller]

From: Kalle Valo 
Date: Fri, 01 Sep 2017 17:34:43 +0300

> here's a pull request to net-next for 4.14. If the merge window opens on
> Sunday I'm planning to have this as the last one.
> 
> Please let me know if there are any problems.

Ok, pulled, thanks.

Re: [PATCH] wl1251: add a missing spin_lock_init()

[David Miller]

From: Pavel Machek 
Date: Thu, 31 Aug 2017 21:59:33 +0200

> Do you plan to send another pull request to Linus, and can you take
> the patch, please?

Yes and yes.

Re: [PATCH] wl1251: add a missing spin_lock_init()

[David Miller]

From: Pavel Machek 
Date: Thu, 31 Aug 2017 20:57:19 +0200

> Hi!
> 
>> From: Pavel Machek 
>> Date: Thu, 31 Aug 2017 16:47:43 +0200
>> 
>> > Dave, Linus -- can you still take the patch?
>> 
>> Pavel, please do not bypass maintainers like this.
>> 
>> It's really rude, and if you do things like that instead of
>> trying to work properly with us, your relationship with
>> these maintainers will suffer in the long term.
> 
> Do you mean I'm being rude to Kalle, or rude to you?

He said "to David", not "David and Linus".

Re: [PATCH] wl1251: add a missing spin_lock_init()

[David Miller]

From: Pavel Machek 
Date: Thu, 31 Aug 2017 16:47:43 +0200

> Dave, Linus -- can you still take the patch?

Pavel, please do not bypass maintainers like this.

It's really rude, and if you do things like that instead of
trying to work properly with us, your relationship with
these maintainers will suffer in the long term.

Thank you.

Re: pull-request: wireless-drivers-next 2017-08-28

[David Miller]

From: Kalle Valo 
Date: Mon, 28 Aug 2017 12:22:34 +0300

> here's a pull request to net-next for 4.14. Because I pulled
> wireless-drivers (at least that's my suspicion) the diffstat was wrong
> again and I created it manually. I recall Linus somewhere saying that in
> certain cases this is normal and it's ok to create the diffstat
> manually, so I don't worry about this anymore.

Yeah, that's fine.

> In this pull request we also add SDIO_DEVICE_ID_CYPRESS_4373 to
> include/linux/mmc/sdio_ids.h which stands out in the diffstat.
> 
> Please let me know if there are any problems.

Pulled, thanks!

Re: pull-request: wireless-drivers 2017-08-25

[David Miller]

From: Kalle Valo 
Date: Fri, 25 Aug 2017 16:37:57 +0300

> here's pull request to net tree for 4.13, more info in the signed
> tag below. Please let me know if there are any problems.

Pulled, thanks Kalle.

Re: [PATCH 3/3 v3] net: tipc: constify genl_ops

[David Miller]

From: Arvind Yadav 
Date: Wed, 23 Aug 2017 16:22:20 +0530

> genl_ops are not supposed to change at runtime. All functions
> working with genl_ops provided by  work with
> const genl_ops. So mark the non-const structs as const.
> 
> Signed-off-by: Arvind Yadav 

Applied.

Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

[David Miller]

From: Dan Williams 
Date: Wed, 16 Aug 2017 21:11:47 -0500

> You'll probably say "aim for the 75% case" or something like that,
> which is fine, but then you're depending on your 75% case to be (a)
> single AP, (b) never move (eg, only bond wifi + ethernet), (c) little
> radio interference.  I'm not sure I'd buy that.  If I've put words in
> your mouth, forgive me.

You can interpret what I'm saying as "some reasonable value is
better than no value at all."

You can keep arguing about AP changes, radio interference, etc.
but anything is better than the current situation.

Start small and simple, try to handle everything over time and
gradually.

Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

[David Miller]

From: Dan Williams 
Date: Wed, 16 Aug 2017 16:22:41 -0500

> My biggest suggestion is that perhaps bonding should grow hysteresis
> for link speeds. Since WiFi can change speed every packet, you probably
> don't want the bond characteristics changing every couple seconds just
> in case your WiFi link is jumping around.  Ethernet won't bounce around
> that much, so the hysteresis would have no effect there.  Or, if people
> are concerned about response time to speed changes on ethernet (where
> you probably do want an instant switch-over) some new flag to indicate
> that certain devices don't have stable speeds over time.

Or just report the average of the range the wireless link can hit, and
be done with it.

I think you guys are overcomplicating things.

Re: Regression: Bug 196547 - Since 4.12 - bonding module not working with wireless drivers

[David Miller]

From: James Feeney 
Date: Wed, 16 Aug 2017 14:44:27 -0600

> On 08/13/2017 11:42 AM, Andreas Born wrote:
>> On a side note I would recommend some of my own reading to you about
>> patch submission in general [1] and on netdev specifically [2].
> 
> Mmm - [2] and [3], I suspect.  Thanks Andreas.  I'll be studying those.  Yeah,
> I'm still learning what is needed and what works.  Sometimes, just a note to 
> the
> author is more than enough to resolve a problem.  Sometimes, discussion is
> needed.  And other times... well, certain people are infamous... but no 
> problem
> here, thankfully.
> 
>> And, just wondering, who's going to eventually close that bugreport?
>> https://bugzilla.kernel.org/show_bug.cgi?id=196547
> 
> I can close it when the patches actually land in the kernel.

All of the patches are in Linus's tree.

Re: pull-request: wireless-drivers 2017-08-15

[David Miller]

From: Kalle Valo 
Date: Tue, 15 Aug 2017 14:30:34 +0300

> more fixes to net tree for 4.13. More info in the signed tag below,
> please let me know if there are any problems.

Pulled, thanks Kalle.

Re: pull-request: wireless-drivers-next 2017-08-07

[David Miller]

From: Kalle Valo 
Date: Mon, 07 Aug 2017 17:55:40 +0300

> here's the first pull request to net-next for 4.14, more info in the
> signed tag below. This time there's a simple conflict in iwlwifi but
> you can fix it just like Stephen did:
> 
> https://lkml.kernel.org/r/20170804120408.0d147...@canb.auug.org.au
> 
> Please let me know if you have any problems.

Pulled, thanks Kalle.

Re: [PATCH 2/2] qlcnic: add const to bin_attribute structure

[David Miller]

From: Bhumika Goyal 
Date: Wed,  2 Aug 2017 23:27:14 +0530

> Add const to bin_attribute structure as it is only passed to the
> functions sysfs_{remove/create}_bin_file. The corresponding
> arguments are of type const, so declare the structure to be const.
> 
> Signed-off-by: Bhumika Goyal 

Applied.

Re: pull-request: wireless-drivers-next 2017-07-28

[David Miller]

From: Kalle Valo 
Date: Fri, 28 Jul 2017 14:05:59 +

> Kalle Valo  writes:
> 
>> Hi Dave,
>>
>> here's a pull request for net, more info the signed tag below. Please
>> let me know if there are any problems.
>>
>> Kalle
>>
>> The following changes since commit d755cbc26e8295ae8e5d30425364e093b4247a85:
>>
>>   Merge tag 'iwlwifi-for-kalle-2017-07-21' of 
>> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes 
>> (2017-07-21 14:33:27 +0300)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
>> tags/wireless-drivers-for-davem-2017-07-28
> 
> Argh, the subject is of course wrong and it should be:
> 
> pull-request: wireless-drivers 2017-07-28

Yeah that makes more sense. :)

> So this pull request is for net tree to get these two brcmfmac fixes to
> 4.13. Otherwise the pull request is correct so I don't submit a new one
> (but let me know if you prefer that).

Pulled, thanks Kalle.

Re: pull-request: wireless-drivers 2017-07-21

[David Miller]

From: Kalle Valo 
Date: Fri, 21 Jul 2017 19:12:54 +0300

> important fixes for net which had accumulated while I was away. I only
> applied the brcmfmac and rtlwifi patches only eight hours ago and I
> haven't seen the kbuild report yet so they might have some build
> breakage in theory. But the patches are so small so the chances that
> they would break something are really small and so I send this to you
> already now to not delay them any longer.
> 
> Please let me know if there are any problems.

Welcome back, pulled, thanks.

Re: [PATCH] wireless: airo: remove unnecessary static in writerids()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:37:11 -0500

> Remove unnecessary static on local function pointer _writer_.
> Such pointer is initialized before being used, on every
> execution path throughout the function. The static has no
> benefit and, removing it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
 ...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] rtlwifi: remove useless code

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:41:06 -0500

> Remove useless local variables last_read_point and last_txw_point and
> the code related.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

net-next is OPEN

[David Miller]

Tell your friends.

http://vger.kernel.org/~davem/net-next.html

Re: [PATCH V2] brcmfmac: fix possible buffer overflow in brcmf_cfg80211_mgmt_tx()

[David Miller]

From: Arend van Spriel 
Date: Wed, 12 Jul 2017 13:49:23 +0200

> On 7/7/2017 10:09 PM, Arend van Spriel wrote:
>> The lower level nl80211 code in cfg80211 ensures that "len" is between
>> 25 and NL80211_ATTR_FRAME (2304).  We subtract DOT11_MGMT_HDR_LEN (24)
>> from
>> "len" so thats's max of 2280.  However, the action_frame->data[]
>> buffer is
>> only BRCMF_FIL_ACTION_FRAME_SIZE (1800) bytes long so this memcpy()
>> can
>> overflow.
>>
>>  memcpy(action_frame->data, [DOT11_MGMT_HDR_LEN],
>> le16_to_cpu(action_frame->len));
>>
>> Cc: sta...@vger.kernel.org # 3.9.x
>> Fixes: 18e2f61db3b70 ("brcmfmac: P2P action frame tx.")
>> Reported-by: "freenerguo(郭大兴)" 
>> Signed-off-by: Arend van Spriel 
>> ---
>>   V2:
>>- added Fixes: tag and Cc: for stable kernels.
>>- Cc: patch to netdev list.
>> ---
>> Hi David,
>>
>> Here is the patch as Linus send it to us and secur...@kernel.org. I
>> removed the lower bound check as that is already done in cfg80211.
>> Now I signed off on the patch although formally I suppose Linus should
>> sign it off. Putting it out there so people can respond as deemed
>> necessary.
>>
>> The reason for submitting it to your tree is the fact that Kalle is
>> on vacation for next 10 days or so which was indicated to me by
>> Johannes.
>> The patch applies to the master branch of your net repository. For
>> reference V1 of this patch can be found here [1].
> 
> Hi Dave,
> 
> Not sure if you missed this one. It is addressing a reported security
> issue and intended for the net repository, not net-next which is
> obviously closed [2].

Thanks for pointing this out to me, I'll take care of it.

net-next STATUS page

[David Miller]

It has gotten to the point that even casually walking around
Faro, Portugal last week, random German tourists would stop
me in the street and ask if net-next was open or not.

Therefore, in order to avoid any and all confusion I have created this
web site:

http://vger.kernel.org/~davem/net-next.html

Please refer to it if you are ever in doubt.

Thanks!

Re: pull-request: mac80211 2017-07-07

[David Miller]

From: Johannes Berg 
Date: Fri,  7 Jul 2017 11:29:01 +0200

> Just got a set of fixes in from Jouni/QCA, all netlink validation
> fixes. I assume they ran some kind of checker, but I don't know
> what kind :)
> 
> Please pull and let me know if there's any problem.

Pulled, thanks Johannes.

Re: pull-request: wireless-drivers-next 2017-07-03

[David Miller]

From: Kalle Valo 
Date: Mon, 03 Jul 2017 14:39:07 +0300

> here's the late pull request to net-next I mentioned about last week to
> get some new iwlwifi hw support to 4.13.
> 
> If this is too late just drop the request and let me know, I can then
> resend it for 4.14 after the merge window. These patches were included
> in today's linux-next build and I haven't received any reports about
> problems, at least not yet.

Pulled, thanks.

Re: [GIT] [4.13] NFC update

[David Miller]

From: Samuel Ortiz 
Date: Fri, 30 Jun 2017 11:37:20 +0200

> This is the NFC pull request for 4.13. We have:
> 
> - A conversion to unified device and GPIO APIs for the
>   fdp, pn544, and st{21,-nci} drivers.
> - A fix for NFC device IDs allocation.
> - A fix for the nfcmrvl driver firmware download mechanism.
> - A trf7970a DT and GPIO cleanup and clock setting fix.
> - A few fixes for potential overflows in the digital and LLCP code.

Pulled, thanks Samuel.

Re: pull-request: wireless-drivers-next 2017-06-30

[David Miller]

From: Kalle Valo 
Date: Fri, 30 Jun 2017 09:19:37 +0300

> here's a pull request to net-next for 4.13. Actually not really that big
> this time, more info in the signed tag below. Please let me know if you
> have any problems.
> 
> Intel has new hardware coming up and they just submitted patches to
> iwlwifi supporting that, but because the patches were so late they
> didn't make it to this one. Hence I'm planning to send you a one more
> pull request on Monday(ish). I know it will be late but I'll let you
> decide if you want it or not. If it doesn't fit your schedule feel free
> to drop it and I'll just send it again for 4.14.

Pulled, thanks Kalle.