* pull-request: mac80211 2019-10-08
@ 2019-10-08 12:31 Johannes Berg
2019-10-09 2:55 ` Jakub Kicinski
0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2019-10-08 12:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
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(-)
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pull-request: mac80211 2019-10-08
2019-10-08 12:31 pull-request: mac80211 2019-10-08 Johannes Berg
@ 2019-10-09 2:55 ` Jakub Kicinski
2019-10-09 6:36 ` Johannes Berg
0 siblings, 1 reply; 4+ messages in thread
From: Jakub Kicinski @ 2019-10-09 2:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, netdev, linux-wireless
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pull-request: mac80211 2019-10-08
2019-10-09 2:55 ` Jakub Kicinski
@ 2019-10-09 6:36 ` Johannes Berg
2019-10-09 17:18 ` Jakub Kicinski
0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2019-10-09 6:36 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: David Miller, netdev, linux-wireless
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pull-request: mac80211 2019-10-08
2019-10-09 6:36 ` Johannes Berg
@ 2019-10-09 17:18 ` Jakub Kicinski
0 siblings, 0 replies; 4+ messages in thread
From: Jakub Kicinski @ 2019-10-09 17:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: David Miller, netdev, linux-wireless
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 :)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-10-09 17:18 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-08 12:31 pull-request: mac80211 2019-10-08 Johannes Berg
2019-10-09 2:55 ` Jakub Kicinski
2019-10-09 6:36 ` Johannes Berg
2019-10-09 17:18 ` Jakub Kicinski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).