Re: [v2 PATCH 0/2] rhashtable: rhashtable with duplicate objects

On Mon, 2016-09-19 at 11:27 +0200, Johannes Berg wrote: > >  > I have a feeling there's a bug with ht->nelems, since the crash is > always in the grow worker, but I haven't quite put my finger on it > yet. > Btw, I should not actually get into the duplicate case here. johannes

Re: [v2 PATCH 0/2] rhashtable: rhashtable with duplicate objects

On Mon, 2016-09-19 at 17:34 +0800, Herbert Xu wrote: > On Mon, Sep 19, 2016 at 11:27:24AM +0200, Johannes Berg wrote: > > > > > > I have a feeling there's a bug with ht->nelems, since the crash is > > always in the grow worker, but I haven't quite put my finger on

Re: [v2 PATCH 0/2] rhashtable: rhashtable with duplicate objects

On Mon, 2016-09-19 at 12:02 +0200, Johannes Berg wrote: > On Mon, 2016-09-19 at 11:54 +0200, Johannes Berg wrote: > > > > > > > > > > > The stack trace is useless, but my other annotation showed that > > > the > > > table's nelems *und

pull-request: mac80211-next 2016-09-30

mac80211: Add API to report NAN function match David Spinadel (1): cfg80211: Add support for static WEP in the driver Johannes Berg (2): cfg80211: add checks for beacon rate, extend to mesh cfg80211: wext: really don't store non-WEP keys Pedersen, Thomas (2): mac80211: add

Re: pull-request: mac80211-next 2016-09-30

On Mon, 2016-10-03 at 01:54 -0400, David Miller wrote: >  > Could you please look into this and send me a new pull request with > the conflicts resolved? > Sure, will do (tomorrow, we have a holiday today). Would you prefer I send you the merge resolution for your tree, or just pull in net for

Re: [PATCH v6 3/4] cfg80211: configure multicast to unicast for AP interfaces

On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote: > This add a userspace toggle to configure multicast to unicast. >  I applied this, with a bunch of fixes and documentation improvements. johannes

Re: [PATCH v6 4/4] mac80211: multicast to unicast conversion

> @@ -2242,6 +2242,20 @@ static int ieee80211_set_wds_peer(struct wiphy > *wiphy, struct net_device *dev, >   return 0; >  } >   > +static int ieee80211_set_multicast_to_unicast(struct wiphy *wiphy, > +   struct net_device > *dev, > +

Re: [PATCH] mac80211: fix incorrect error return path on tmp allocation failure

On Fri, 2016-10-28 at 19:08 +0100, Colin King wrote: > From: Colin Ian King > > The current exit path when tmp fails to be allocated is via the > fail label which frees tfm2 which has not yet been allocated, > which is problematic since tfm2 is not initialized and is a

Re: [PATCH] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map

On Fri, 2016-10-28 at 16:38 +0200, Filip Matusiak wrote: > This is a workaround for VHT-enabled STAs which break the spec > and have the VHT-MCS Rx map filled in with value 3 for all eight > spacial streams. > > As per spec, in section 22.1.1 Introduction to the VHT PHY > A VHT STA shall support

Re: [PATCH] wireless: fix bogus maybe-uninitialized warning

> Ideally we prefer that drivers/net/wireless and net/wireless changes > are > split into different patches as they get applied to different trees. > Johannes, is it ok if I take this change through my tree this time? Sure, please do, thanks. (I don't particularly care about the lib80211 stuff

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Thu, 2016-10-13 at 14:49 -0700, Andy Lutomirski wrote: >  > It's failing before that.  With CONFIG_VMAP_STACK=y, the stack may > not be physically contiguous and can't be used for DMA, so putting it > in a scatterlist is bogus in general, and the crypto code mostly > wants a scatterlist. I

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Fri, 2016-10-14 at 10:05 +0100, Ard Biesheuvel wrote: >  > Indeed. And the decrypt path does the same for auth_tag[]. Hadn't gotten that far, due to the BUG_ON() in CONFIG_DEBUG_SG in the encrypt path :) > But that still means there are two separate problems here, one which > affects the WPA

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote: > > I assume the stack buffer itself is not the problem here, but aad, > > which is allocated on the stack one frame up. > > Do we really need to revert the whole patch to fix that? > > Ah never mind, this is about 'odata'. Apologies,

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

>    1. revert that patch (doing so would need some major adjustments now, >   since it's pretty old and a number of new things were added in the >   meantime) This it will have to be, I guess. >    2. allocate a per-CPU buffer for all the things that we put on the >   stack and use

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

> So why is the performance hit acceptable for ESP but not for WPA? We > could easily implement the same thing, i.e., > kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it > on the stack Yeah, maybe we should. It's likely a much bigger allocation, but I don't actually know if

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Fri, 2016-10-14 at 17:39 +0900, Sergey Senozhatsky wrote: >  > given that we have a known issue shouldn't VMAP_STACK be > disabled for now, or would you rather prefer to mark MAC80211 > as incompatible: "depends on CFG80211 && !VMAP_STACK"? Yeah. It's a bit complicated by the fact that most

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Fri, 2016-10-14 at 09:47 +0100, Ard Biesheuvel wrote: >  > Do you have a reference for the sg_set_buf() call on odata? > crypto/ccm.c does not seem to have it (afaict), It's indirect - crypto_ccm_encrypt() calls crypto_ccm_init_crypt() which does it. > and the same problem > does not exist

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Fri, 2016-10-14 at 10:21 +0100, Ard Biesheuvel wrote: > It is annotated with a TODO, though :-) > > 38320c70d282b (Herbert Xu   2008-01-28 19:35:05 > -0800  41) >  * TODO: Use spare space in skb for this where possible. I saw that, but I don't think generally there will be spare

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

For reference, this was my patch moving the mac80211 buffers to percpu. diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c index 7663c28ba353..c3709ddf71e9 100644 --- a/net/mac80211/aes_ccm.c +++ b/net/mac80211/aes_ccm.c @@ -29,6 +29,8 @@ void ieee80211_aes_ccm_encrypt(struct

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

> So use kzalloc Do we really need kzalloc()? We have things on the stack right now, and don't initialize, so surely we don't really need to zero things? > This only addresses one half of the problem. The other problem, i.e., > the fact that the aad[] array lives on the stack of the caller, is

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

> > Is the aad[] actually reused? I would assume it only affects the mac > on encryption, and the verification on decryption but I don't think > we actually need it back from the crypto routines. I don't think it's reused. > Exactly what you said above :-) My patch only touches CCM but as you

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

On Fri, 2016-10-14 at 15:10 +0200, Johannes Berg wrote: > > > > So use kzalloc > > Do we really need kzalloc()? We have things on the stack right now, > and don't initialize, so surely we don't really need to zero things?  Err, never mind, I'm an idiot - we *do* initi

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

On Fri, 2016-10-14 at 14:13 +0100, Ard Biesheuvel wrote: >  > > But if we allocate things anyway, is it worth expending per-CPU > > buffers on these? > > Ehmm, maybe not. I could spin a v2 that allocates a bigger buffer, > and copies aad[] into it as well Copies in/out, I guess. Also there's

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Mon, 2016-10-17 at 08:37 +0100, Ard Biesheuvel wrote: >  > Could we get a statement first whether it is supported to allocate > aead_req (and other crypto req structures) on the stack? Well, we haven't heard from Herbert :) > If not, then > we have our work cut out for us. But if it is, I'd

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Mon, 2016-10-17 at 08:50 +0100, Ard Biesheuvel wrote: > I just realised that patch should probably use > aead_request_alloc/aead_request_free [and drop the memset]. That also > fixes the latent bug where the alignment of the req ctx is not take > into account. Good point, I'll fix that up. >

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> > Well, if your other patch to make it OK to be on-stack would be > > applied instead, this wouldn't make much sense either :) > > > > Yes but that one only fixes ccm not gcm Yes, but we can do the same for GCM, no? > > In this particular patch, we could reduce the size of the struct, > >

[PATCH] mac80211: move struct aead_req off the stack

From: Johannes Berg <johannes.b...@intel.com> Some crypto implementations (such as the generic CCM wrapper in crypto/) use scatterlists to map fields of private data in their struct aead_req. This means these data structures cannot live in the vmalloc area, which means that they canno

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> Apologies for going back and forth on this, but it appears there may > be another way to deal with this. > > First of all, we only need this handling for the authenticated data, Are you sure b_0/j_0 aren't needed? We pass those to aead_request_set_crypt(), and I wasn't sure what that really

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote: > The CCM code goes out of its way to perform the CTR encryption of the > MAC using the subordinate CTR driver. To this end, it tweaks the > input and output scatterlists so the aead_req 'odata' and/or > 'auth_tag' fields [which may live on

[PATCH v3] mac80211: move extra crypto data off the stack

From: Johannes Berg <johannes.b...@intel.com> As the stack can (on x86-64) now be virtually mapped rather than using "normal" kernel memory, Sergey noticed mac80211 isn't using the SG APIs correctly by putting on-stack buffers into SG tables. This leads to kernel crashes. Fix th

[PATCH v3] mac80211: move struct aead_req off the stack

From: Johannes Berg <johannes.b...@intel.com> Some crypto implementations (such as the generic CCM wrapper in crypto/) use scatterlists to map fields of private data in their struct aead_req. This means these data structures cannot live in the vmalloc area, which means that they canno

Re: [PATCH v3] mac80211: move extra crypto data off the stack

[snip] Sorry, this went out by mistake. johannes

[PATCH v4] mac80211: move extra crypto data off the stack

From: Johannes Berg <johannes.b...@intel.com> As the stack can (on x86-64) now be virtually mapped rather than using "normal" kernel memory, Sergey noticed mac80211 isn't using the SG APIs correctly by putting on-stack buffers into SG tables. This leads to kernel crashes. Fix th

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On Mon, 2016-10-17 at 10:30 +0100, Ard Biesheuvel wrote: > Yes. But as I replied, setting the req size is not supported atm, > although it is reasonable to demand a way to allocate additional data > in the request specifically for this issue. So let's proceed with the > aead_request_alloc/free

[PATCH v2] mac80211: move struct aead_req off the stack

From: Johannes Berg <johannes.b...@intel.com> Some crypto implementations (such as the generic CCM wrapper in crypto/) use scatterlists to map fields of private data in their struct aead_req. This means these data structures cannot live in the vmalloc area, which means that they canno

Re: [PATCH] mac80211_hwsim: suggest nl80211 instead of wext driver in documentation

On Mon, 2016-10-17 at 00:39 +0200, Linus Lüssing wrote: > For mac80211_hwsim interfaces, suggest to use wpa_supplicant with the > more modern, netlink based driver instead of wext. Makes sense, applied. > Actually, I wasn't even able to make a connection with the > configuration > files and

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote: >  > > Hmm. Is it really worth having a per-CPU variable for each possible > > key? You could have a large number of those (typically three when > > you're a client on an AP, and 1 + 1 for each client when you're the > > AP). 2 + 1 for each

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote: >  > + aead_req = *this_cpu_ptr(ccmp->reqs); > + if (!aead_req) { > + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC); > + if (!aead_req) > + return -ENOMEM; > +

Re: [PATCH 3/5] genetlink: statically initialize families

On Tue, 2016-10-25 at 11:25 +, David Laight wrote: > > Actually, with the new system where it's not const, I could even > > split this up and submit per subsystem, i.e. the fourth patch > > doesn't depend on it. I thought it would, since I wanted to make it > > const, but since I failed it

Re: [PATCH 3/5] genetlink: statically initialize families

On Mon, 2016-10-24 at 14:40 +0200, Johannes Berg wrote: > From: Johannes Berg <johannes.b...@intel.com> > > Instead of providing macros/inline functions to initialize > the families, make all users initialize them statically and > get rid of the macros. > > This r

[PATCH 2/5] genetlink: no longer support using static family IDs

From: Johannes Berg <johannes.b...@intel.com> Static family IDs have never really been used, the only use case was the workaround I introduced for those users that assumed their family ID was also their multicast group ID. Additionally, because static family IDs would never be re

[PATCH 0/5] genetlink improvements

This series contains some generic netlink improvements, making the API safer to use, and making the function pointers in the family struct safer by allowing it to be __ro_after_init. The first patch, introducing genl_family_attrbuf(), just ensures that the users of family->attrbuf aren't actually

[PATCH 5/5] genetlink: mark families as __ro_after_init

From: Johannes Berg <johannes.b...@intel.com> Now genl_register_family() is the only thing (other than the users themselves, perhaps, but I didn't find any doing that) writing to the family struct. In all families that I found, genl_register_family() is only called from __init functions

[PATCH 3/5] genetlink: statically initialize families

From: Johannes Berg <johannes.b...@intel.com> Instead of providing macros/inline functions to initialize the families, make all users initialize them statically and get rid of the macros. This reduces the kernel code size by about 1.6k on x86-64 (with allyesconfig). Signed-off-by: Johanne

[PATCH 1/5] genetlink: introduce and use genl_family_attrbuf()

From: Johannes Berg <johannes.b...@intel.com> This helper function allows family implementations to access their family's attrbuf. This gets rid of the attrbuf usage in families, and also adds locking validation, since it's not valid to use the attrbuf with parallel_ops or outside of the

[PATCH 4/5] genetlink: use idr to track families

From: Johannes Berg <johannes.b...@intel.com> Since generic netlink family IDs are small integers, allocated densely, IDR is an ideal match for lookups. Replace the existing hand-written hash-table with IDR for allocation and lookup. This lets the families only be written to once,

Re: [PATCH net-next v2 3/9] net: use core MTU range checking in wireless drivers

tu in p80211netdev, remove wlan_change_mtu > - set min/max_mtu in net/mac80211/iface.c and remove ieee80211_change_mtu For the mac80211 part, Acked-by: Johannes Berg <johan...@sipsolutions.net> Dave, I'm assuming you'll pick this up, but if you prefer not to I can also coordinate with Kal

Re: [PATCH net-next 2/6] net: use core MTU range checking in wireless drivers

> > I guess we should do the same in net/mac80211/iface.c? > > Yeah. I thought I'd located all places this needed to happen, but > obviously not. I'll get this added and do another sweep for others I > might have missed. No worries. I can also do it if you prefer, just wanted to ask :)

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote: > On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote: > > > > > > Annoyingly, all this complication with scatterlists etc is for > > doing > > asynchronous crypto via DMA capable crypto accelerators, and the > > networking code

Re: [PATCH net-next 2/6] net: use core MTU range checking in wireless drivers

On Tue, 2016-10-18 at 22:33 -0400, Jarod Wilson wrote: > - set max_mtu in wil6210 driver > - set max_mtu in atmel driver > - set min/max_mtu in cisco airo driver, remove airo_change_mtu > - set min/max_mtu in ipw2100/ipw2200 drivers, remove > libipw_change_mtu > - set min/max_mtu in p80211netdev,

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On Wed, 2016-10-19 at 08:59 -0700, Ben Greear wrote: >  > Do you actually expect performance regressions?  I'll be complaining > if so, but will test first :) I think we can expect this to use a bit more CPU time, but unless you're very tight on that you probably shouldn't expect any throughput

pull-request: mac80211 2016-10-18

to prevent controlled port bypass Ard Biesheuvel (1): mac80211: move struct aead_req off the stack Johannes Berg (4): mac80211: discard multicast and 4-addr A-MSDUs cfg80211: let ieee80211_amsdu_to_8023s() take

Re: [PATCH] genetlink: fix unsigned int comparison with less than zero

On Thu, 2016-11-10 at 09:11 -0800, Cong Wang wrote: > On Thu, Nov 10, 2016 at 7:57 AM, Colin King > wrote: > > > > From: Colin Ian King > > > > family->id is unsigned, so the less than zero check for > > failure return from idr_alloc is

Re: [PATCH 0/4] Fix -Wunused-but-set-variable in net/mac80211/

On Wed, 2016-11-23 at 20:45 -0800, Kirtika Ruchandani wrote: > This patchset is part of the effort led by Arnd Bergmann to clean up > warnings in the kernel. This and following patchsets will focus on > "-Wunused-but-set-variable" as it among the noisier ones. These were > found compiling with

Re: [PATCH] mac80211: Remove unused 'struct rate_control_ref' variable

On Mon, 2016-11-21 at 22:54 -0800, Kirtika Ruchandani wrote: > Commit 3b17fbf87d5d introduced sta_get_expected_throughput() > leaving variable 'struct rate_control_ref* ref' set but unused. > Compiling with W=1 gives the following warning, fix it. > > net/mac80211/sta_info.c: In function

pull-request: mac80211 2016-11-18

with wrong rx_mcs_map Johannes Berg (1): cfg80211: limit scan results cache size Pedersen, Thomas (1): cfg80211: add bitrate for 20MHz MCS 9 drivers/net/wireless/mac80211_hwsim.c | 2 +- net/mac80211/sta_info.c | 2 +- net/mac80211/tx.c | 14 +-- ne

Re: [PATCH] genetlink: fix unsigned int comparison with less than zero

> > I suppose it could be, since family IDs are allocated in a 16-bit > > range > > anyway. But family IDs can also never actually be negative, so > > having > > an unsigned int in the struct makes sense too. > > All idr_* API's accept int, rather than unsigned int. This is my > point. Sure,

Re: [PATCH v7 2/2] mac80211: multicast to unicast conversion

On Mon, 2016-10-31 at 14:41 +0100, Michael Braun wrote:   > +static int ieee80211_set_multicast_to_unicast(struct wiphy *wiphy, > +   struct net_device > *dev, > +   const bool enabled) > +{ > + struct

Re: [PATCH v7 1/2] nl80211: multicast_to_unicast can be changed while IFF_UP

On Mon, 2016-10-31 at 14:40 +0100, Michael Braun wrote: > There is no need to prevent toggling multicast_to_unicast while > interface is already up. This change simplifies reconfiguration > from hostapd. Applied. This check never should've been there anyway, if desired, NEED_NETDEV_UP should've

Re: [PATCH V2] mac80211: Ignore VHT IE from peer with wrong rx_mcs_map

On Wed, 2016-11-02 at 10:04 +0100, Filip Matusiak wrote: > This is a workaround for VHT-enabled STAs which break the spec > and have the VHT-MCS Rx map filled in with value 3 for all eight > spacial streams, an example is AR9462 in AP mode. > > As per spec, in section 22.1.1 Introduction to the

pull-request: mac80211 2016-10-27

* small markup fixes for the sphinx documentation conversion that's coming into the tree via the doc tree Jani Nikula (1): mac80211: fix some sphinx warnings Johannes Berg (1): cfg80211: process events caused

pull-request: mac80211-next 2016-10-28

211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger mac80211: uapsd_queues is in QoS IE order Ilan Peer (1): cfg80211: allow aborting in-progress connection atttempts Johannes Berg (17): mac80211: remove unnecessary mesh check mac80211_hwsim: make mul

Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr

>  /** > + * nla_memdup - duplicate attribute memory (kmemdup) > + * @src: netlink attribute to duplicate from > + * @gfp: GFP mask Actually, is there any point in passing a GFP mask? None of the current users need it, and it seems fairly unlikely to be needed since this is typically used on the

Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr

On Wed, 2016-10-26 at 10:53 +0200, Thomas Graf wrote: > Wrap several common instances of: > kmemdup(nla_data(attr), nla_len(attr), GFP_KERNEL); Makes sense Acked-by: Johannes Berg <johan...@sipsolutions.net> johannes

[v2] pull-request: mac80211-next 2016-10-28

atttempts Johannes Berg (17): mac80211: remove unnecessary mesh check mac80211_hwsim: make multi-channel ops const mac80211: preserve more bits when building QoS header nl80211: correctly use nl80211_nan_srf_policy nl80211: ifdef WoWLAN related policies wireless: rad

Re: [PATCH] mac80211: fils_aead: fix encrypt error handling

On Fri, 2016-10-28 at 12:25 +0200, Arnd Bergmann wrote: > gcc -Wmaybe-uninitialized reports a bug in aes_siv_encryp: > > net/mac80211/fils_aead.c: In function ‘aes_siv_encrypt.constprop’: > net/mac80211/fils_aead.c:84:26: error: ‘tfm2’ may be used > uninitialized in this function

Re: [PATCH net-next] genetlink: Fix generic netlink family unregister

s and forgot this wasn't even executed. Sorry about that! Reviewed-by: Johannes Berg <johan...@sipsolutions.net> johannes

Re: [RFC] make kmemleak scan __ro_after_init section (was: Re: [PATCH 0/5] genetlink improvements)

Hi, Sorry for not chipping in earlier - LPC is taking my time. > > > > Looks like we are missing a kfree(family->attrbuf); on error > > > > path, but it is not related to Johannes' recent patches. Actually, I think it *is* related to my patch - I inserted the code there in the wrong place or

Re: [PATCH net-next] netlink: Add nla_memdup() to wrap kmemdup() use on nlattr

On Wed, 2016-10-26 at 11:52 +0200, Thomas Graf wrote: > On 10/26/16 at 10:59am, Johannes Berg wrote: > > > > > > > > > >  /** > > > + * nla_memdup - duplicate attribute memory (kmemdup) > > > + * @src: netlink attribute to duplicate from >

[PATCH] net_sched actions: use nla_parse_nested()

From: Johannes Berg <johannes.b...@intel.com> Use nla_parse_nested instead of open-coding the call to nla_parse() with the attribute data/len. Signed-off-by: Johannes Berg <johannes.b...@intel.com> --- net/sched/act_api.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

Hi, Sorry - I meant to look into this yesterday but forgot. > Andy, can this be related to CONFIG_VMAP_STACK? I think it is. > > current -git kills my system. Can you elaborate on how exactly it kills your system? > > adding > > > > if (!virt_addr_valid([2])) { > >

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

> > Can you elaborate on how exactly it kills your system? > > the last time I saw it it was a NULL deref at > ieee80211_aes_ccm_decrypt. Hm. I was expecting something within the crypto code would cause the crash, this seems strange. Anyway, I'm surely out of my depth wrt. the actual cause.

Re: [PATCH v6 2/4] mac80211: filter multicast data packets on AP / AP_VLAN

On Mon, 2016-10-10 at 19:12 +0200, Michael Braun wrote: > This patch adds filtering for multicast data packets on AP_VLAN > interfaces >  [...] Applied patches 1 and 2 for now, I'll look at the others again later. johannes

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote: >  > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi > > > t/?h=x86/vmap_stack=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd > > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi > > >

Re: [PATCH v5 3/4] cfg80211: configure multicast to unicast for AP interfaces

>   * > + * @NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED: Multicast packets > should be > + *  send out as unicast to all stations. You should document what type of attribute is expected. You probably wanted a flag attribute, but ... > + [NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED] = {

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote: > In a pinch, I have these patches sitting around: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vmap_stack=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd >

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> Indeed. And it keeps the clutter inside the aes_xxx.c files, which > could easily be updated in the future to use some auxdata feature if > it ever materializes. > > I think it would help this code, but also the ESP code you pointed > out, to have some kind of 'ordered synchronous' CRYPTO_xxx

Re: [PATCH v4] mac80211: move struct aead_req off the stack

On Mon, 2016-10-17 at 15:05 +0100, Ard Biesheuvel wrote: > From: Johannes Berg <johannes.b...@intel.com> That really ought to have been you - I think I may have lost that by accident. I'll change it. > In addition, take care not to put any of our own stack allocations > into

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On Mon, 2016-10-17 at 14:06 +0100, Ard Biesheuvel wrote: >  > Actually, while I think it will be worthwhile going forward to > implement such an 'auxiliary data' feature in a generic way, I still > think we should address the issue at hand without too much > complication. > > If we pedal back to

pull-request: mac80211-next 2016-12-09

to use a single attribute for two purposes) * fix a long-standing BSS leak that happens when an association attempt is abandoned Johannes Berg (2): nl80211: fix logic inversion in start_nan() cfg80211/mac80211: fix BSS

Re: [PATCH mac80211-next] rfkill: hide unused goto label

On Fri, 2016-12-16 at 09:44 +0100, Arnd Bergmann wrote: > A cleanup introduced a harmless warning in some configurations: > > net/rfkill/core.c: In function 'rfkill_init': > net/rfkill/core.c:1350:1: warning: label 'error_input' defined but > not used [-Wunused-label] > > This adds another

pull-request: mac80211 2016-12-16

when forwarding mesh pkt Johannes Berg (1): mac80211: don't call drv_set_default_unicast_key() for VLANs net/mac80211/key.c | 3 ++- net/mac80211/rx.c | 2 +- net/mac80211/sta_info.c | 14 -- 3 files changed, 11 insertions(+), 8 deletions(-)

Re: [PATCH v2 2/2] net: rfkill: Add rfkill-any LED trigger

On Thu, 2016-12-08 at 08:30 +0100, Michał Kępień wrote: > Add a new "global" (i.e. not per-rfkill device) LED trigger, rfkill- > any, > which may be useful on laptops with a single "radio LED" and multiple > radio transmitters.  The trigger is meant to turn a LED on whenever > there is at least

Re: [PATCH v2 1/2] net: rfkill: Cleanup error handling in rfkill_init()

On Thu, 2016-12-08 at 08:30 +0100, Michał Kępień wrote: > Use a separate label per error condition in rfkill_init() to make it > a bit cleaner and easier to extend. applied. johannes

Re: [PATCH 10/10] virtio: enable endian checks for sparse builds

On Tue, 2016-12-06 at 17:41 +0200, Michael S. Tsirkin wrote: > It seems that there should be a better way to do it, > but this works too. In some cases there might be: > --- a/drivers/s390/virtio/Makefile > +++ b/drivers/s390/virtio/Makefile > @@ -6,6 +6,8 @@ >  # it under the terms of the GNU

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote: > gcc-7 complains that wl3501_cs passes NULL into a function that > then uses the argument as the input for memcpy: > > drivers/net/wireless/wl3501_cs.c: In function 'wl3501_get_scan': > include/net/iw_handler.h:559:3: error: argument 2 null

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

On Wed, 2017-01-11 at 16:00 +0100, Arnd Bergmann wrote: > On Wed, Jan 11, 2017 at 3:38 PM, Johannes Berg > <johan...@sipsolutions.net> wrote: > > On Wed, 2017-01-11 at 15:35 +0100, Arnd Bergmann wrote: > > > This works fine here because iwe->u.data.length is gua

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote: > On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote: > > > > Applied. Also fixed the typo in the subject :) > > Thanks! Unfortunately I now got another warning for the same > function, and thou

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

On Wed, 2017-01-11 at 21:39 +0100, Arnd Bergmann wrote: > On Wednesday, January 11, 2017 4:06:17 PM CET Johannes Berg wrote: > > > > Applied. Also fixed the typo in the subject :) > > Thanks! Unfortunately I now got another warning for the same > function, and thou

Re: [PATCH] wext: handle NULL exta data in iwe_stream_add_point better

> Come to think of it, I'm thinking I should drop this patch and the > driver should just use iwe_stream_add_event() instead? It'll be > somewhat tricky to get the length correct though. No, turns out that's basically impossible with all the compat etc. stuff here. johannes

Re: To netlink or not to netlink, that is the question

On Thu, 2017-01-12 at 20:02 +0100, Jason A. Donenfeld wrote: > Hi Dan, > > Thanks for your response. I'd thought about this, at least for > adding/removing wgpeers/wgipmasks and for configuring wgdevices. This > would fit into multiple smaller messages indeed. > > But what about fetching the

pull-request: mac80211-next 2017-01-13

: store probability variance instead of standard deviation mac80211: minstrel: make prob_ewma u16 instead of u32 mac80211: minstrel_ht: remove obsolete #if for >= 3 streams Ilan peer (1): mac80211: Fix addition of mesh configuration element Johannes Berg (7): rfkill

pull-request: mac80211 2017-01-13

): cfg80211: consider VHT opmode on station update Cedric Izoard (1): mac80211: Fix headroom allocation when forwarding mesh pkt Emmanuel Grumbach (1): mac80211: fix the TID on NDPs sent as EOSP carrier Felix Fietkau (1): mac80211: initialize SMPS field in HT capabilities Johannes Berg

Re: [PATCH net-next] bridge: multicast to unicast

> > Exactly. My point is that this is breaking the expectation that > > hosts are actually able to drop such packets. > > [readding CCs I removed earlier] > > Ah! Thanks. I was worried about creating packetloss :D. Ah, well, no - at least not in this case. > Hm, for this other other way

Re: [PATCH 2/2] net: rfkill: Add rfkill-any LED trigger

> Thanks, these are obviously all valid concerns.  Sorry for being > sloppy > with the ifdefs.  If I get positive feedback on the proposed feature > itself, all these issues (and the warning pointed out in the other > message) will be resolved in v2. Looks fine, please do that. johannes

Re: BROKEN Re: [PATCH] netlink: 2-clause nla_ok()

> Maybe someone could vouch that other checks prevent > this kind of situation from happening but not me. No, now that you spell it out (and I see the patch) - this is absolutely needed because nla_for_each_attr() [1] can be called on arbitrary data coming from userspace in a message, e.g. by

Re: [PATCH net-next] bridge: multicast to unicast

On Mon, 2017-01-02 at 20:32 +0100, Linus Lüssing wrote: > Implements an optional, per bridge port flag and feature to deliver > multicast packets to any host on the according port via unicast > individually. This is done by copying the packet per host and > changing the multicast destination MAC

Re: [PATCH v3] rfkill: Add rfkill-any LED trigger

> I'm not super happy with this conditional locking - can't we instead > defer the necessary work to a workqueue, or so, for purposes of the > LED? Actually, since you can sleep in here, and do various other things like scheduling etc. this can't even be correct as is - one thread might be in

Re: [PATCH v3] rfkill: Add rfkill-any LED trigger

On Mon, 2017-01-02 at 13:21 +0100, Johannes Berg wrote: > > I'm not super happy with this conditional locking - can't we > > instead > > defer the necessary work to a workqueue, or so, for purposes of the > > LED? > > Actually, since you can sleep in here, and

Re: SIOCSIWFREQ while in NL80211_IFTYPE_STATION

+linux-wireless, where this should've gone > I am running a single wlan0 interface in managed mode (no aliases, > no  other wireless interfaces). > The association with the AP still hasn't happened. > > I noticed that if trying to change the frequency to one of the valid  > values, the driver

<    6   7   8   9   10   11   12   13   14   15   >