| Message ID | 20191008123111.4019-1-johannes@sipsolutions.net (mailing list archive) |
|---|---|
| State | Not Applicable |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | pull-request: mac80211 2019-10-08 | expand |
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.
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
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 :)
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(-)