pull-request: mac80211 2019-10-08

pull-request: mac80211 2019-10-08

[Johannes Berg]

Hi Dave,

Another week, another set of fixes.

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

Thanks,
johannes



The following changes since commit 3afb0961884046c8fb4acbce65139088959681c8:

  tcp: fix slab-out-of-bounds in tcp_zerocopy_receive() (2019-10-03 12:05:34 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2019-10-08

for you to fetch changes up to dc0c18ed229cdcca283dd78fefa38273ec37a42c:

  mac80211: fix scan when operating on DFS channels in ETSI domains (2019-10-07 22:10:50 +0200)

----------------------------------------------------------------
A number of fixes:
 * allow scanning when operating on radar channels in
   ETSI regdomains
 * accept deauth frames in IBSS - we have code to parse
   and handle them, but were dropping them early
 * fix an allocation failure path in hwsim
 * fix a failure path memory leak in nl80211 FTM code
 * fix RCU handling & locking in multi-BSSID parsing
 * reject malformed SSID in mac80211 (this shouldn't
   really be able to happen, but defense in depth)
 * avoid userspace buffer overrun in ancient wext code
   if SSID was too long

----------------------------------------------------------------
Aaron Komisar (1):
      mac80211: fix scan when operating on DFS channels in ETSI domains

Johannes Berg (1):
      mac80211: accept deauth frames in IBSS mode

Michael Vassernis (1):
      mac80211_hwsim: fix incorrect dev_alloc_name failure goto

Navid Emamdoost (1):
      nl80211: fix memory leak in nl80211_get_ftm_responder_stats

Sara Sharon (1):
      cfg80211: fix a bunch of RCU issues in multi-bssid code

Will Deacon (2):
      mac80211: Reject malformed SSID elements
      cfg80211: wext: avoid copying malformed SSIDs

 drivers/net/wireless/mac80211_hwsim.c |  2 +-
 include/net/cfg80211.h                |  8 ++++++++
 net/mac80211/mlme.c                   |  5 +++--
 net/mac80211/rx.c                     | 11 ++++++++++-
 net/mac80211/scan.c                   | 30 ++++++++++++++++++++++++++++--
 net/wireless/nl80211.c                |  2 +-
 net/wireless/reg.c                    |  1 +
 net/wireless/reg.h                    |  8 --------
 net/wireless/scan.c                   | 23 +++++++++++++----------
 net/wireless/wext-sme.c               |  8 ++++++--
 10 files changed, 71 insertions(+), 27 deletions(-)

Re: pull-request: mac80211 2019-10-08

[Jakub Kicinski]

On Tue,  8 Oct 2019 14:31:10 +0200, Johannes Berg wrote:
> Hi Dave,
> 
> Another week, another set of fixes.
> 
> Please pull and let me know if there's any problem.

Pulled into net. Let me know if did it wrong :)

FWIW there was this little complaint from checkpatch:

---------------------------------------------------------------
0006-mac80211-accept-deauth-frames-in-IBSS-mode.patch
---------------------------------------------------------------
WARNING: Duplicate signature
#14: 
Signed-off-by: Johannes Berg <johannes.berg@intel.com>

total: 0 errors, 1 warnings, 0 checks, 19 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

0006-mac80211-accept-deauth-frames-in-IBSS-mode.patch has style problems, please review.

Re: pull-request: mac80211 2019-10-08

[Johannes Berg]

Hi Jakub,

> Pulled into net. Let me know if did it wrong :)

Oops, didn't know it was your "turn" again, guess I haven't been reading
netdev enough.

Looks good, but I didn't think this could possibly go wrong :)

> FWIW there was this little complaint from checkpatch:
[...]
> WARNING: Duplicate signature
> #14: 
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>

Hmm, yeah, so ... I was actually not sure about that and I guess it
slipped by. Most of the time, I've been editing it out, but what happens
is this:

 1) I send a patch to our internal tree, to fix up some things. Unless
    it's really urgent, I don't necessarily post it externally at the
    same time. This obviously has my S-o-b.
 2) Luca goes through our internal tree and sends out the patches to the
    list, adding his S-o-b.
 3) For the patches to the stack, I apply them, and git-am adds my S-o-b
    again because it's not the last.

So now we have

S-o-b: Johannes
S-o-b: Luca
S-o-b: Johannes

If I edit it just to be "S-o-b: Johannes", then it looks strange because
I've applied a patch from the list and dropped an S-o-b. It's still my
code, and Luca doesn't normally have to make any changes to it, but ...
This is what I've normally been doing I think, but it always felt a bit
weird because then it's not the patch I actually applied, it's like I
pretend the whole process described above never happened.

If I edit and remove my first S-o-b then it's weird because the Author
isn't the first S-o-b, making it look like I didn't sign it off when I
authored it?

If I edit and remove the last S-o-b, how did it end up in my tree?

So basically my first S-o-b is certifying (a) or maybe occasionally (b)
under the DCO, while Luca's and my second are certifying (c) (and maybe
occasionally also (a) or (b) if any changes were made.)


Is there any convention on this that I could adhere to? :)

johannes

Re: pull-request: mac80211 2019-10-08

[Jakub Kicinski]

On Wed, 09 Oct 2019 08:36:57 +0200, Johannes Berg wrote:
> Hi Jakub,
> 
> > Pulled into net. Let me know if did it wrong :)  
> 
> Oops, didn't know it was your "turn" again, guess I haven't been reading
> netdev enough.

It's more of a ad hoc whenever Dave needs to step away for a day 
or two thing, than a schedule. Also I'm quite happy to pick things 
up from patchwork and the mailing list, so no real need to CC me,
anyway :)

> Looks good, but I didn't think this could possibly go wrong :)
> 
> > FWIW there was this little complaint from checkpatch:  
> [...]
> > WARNING: Duplicate signature
> > #14: 
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>  
> 
> Hmm, yeah, so ... I was actually not sure about that and I guess it
> slipped by. Most of the time, I've been editing it out, but what happens
> is this:
> 
>  1) I send a patch to our internal tree, to fix up some things. Unless
>     it's really urgent, I don't necessarily post it externally at the
>     same time. This obviously has my S-o-b.
>  2) Luca goes through our internal tree and sends out the patches to the
>     list, adding his S-o-b.
>  3) For the patches to the stack, I apply them, and git-am adds my S-o-b
>     again because it's not the last.
> 
> So now we have
> 
> S-o-b: Johannes
> S-o-b: Luca
> S-o-b: Johannes
> 
> If I edit it just to be "S-o-b: Johannes", then it looks strange because
> I've applied a patch from the list and dropped an S-o-b. It's still my
> code, and Luca doesn't normally have to make any changes to it, but ...
> This is what I've normally been doing I think, but it always felt a bit
> weird because then it's not the patch I actually applied, it's like I
> pretend the whole process described above never happened.
> 
> If I edit and remove my first S-o-b then it's weird because the Author
> isn't the first S-o-b, making it look like I didn't sign it off when I
> authored it?
> 
> If I edit and remove the last S-o-b, how did it end up in my tree?
> 
> So basically my first S-o-b is certifying (a) or maybe occasionally (b)
> under the DCO, while Luca's and my second are certifying (c) (and maybe
> occasionally also (a) or (b) if any changes were made.)
> 
> 
> Is there any convention on this that I could adhere to? :)

Thanks for the explanation, seems like a reasonable stand so as long as
you're aware this is happening, I'm happy :)