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

On 14 October 2016 at 11:00, Johannes Berg wrote: > >> 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,

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

On 14 October 2016 at 11:00, Johannes Berg wrote: > >> 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

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)

> 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 14 October 2016 at 10:25, Johannes Berg wrote: > 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

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

On 14 October 2016 at 10:25, Johannes Berg wrote: > 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. > >

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)

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)

On 14 October 2016 at 10:10, Johannes Berg wrote: > 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 :) > >>

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

On 14 October 2016 at 10:10, Johannes Berg wrote: > 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

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 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 14 October 2016 at 09:55, Johannes Berg wrote: > 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()

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

On 14 October 2016 at 09:55, Johannes Berg wrote: > 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()

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 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)

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: [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: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 09:42, Johannes Berg wrote: > 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

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

On 14 October 2016 at 09:42, Johannes Berg wrote: > 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?

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 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: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)

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)

On 14 October 2016 at 09:39, Ard Biesheuvel wrote: > On 14 October 2016 at 09:28, Johannes Berg wrote: >> >>>1. revert that patch (doing so would need some major adjustments now, >>> since it's pretty old and a number of new things

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

On 14 October 2016 at 09:39, Ard Biesheuvel wrote: > On 14 October 2016 at 09:28, Johannes Berg wrote: >> >>>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

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

On (10/13/16 14:49), Andy Lutomirski wrote: [..] > > > FAIL: 412cba02 > c900802cba02 || 1 -> (412cba02 > > > >> 39) == 130 > > > > Yeah, we already know that in this function the aad variable is on the > > stack, it explicitly is. > > > > The question, though, is why precisely

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

On (10/13/16 14:49), Andy Lutomirski wrote: [..] > > > FAIL: 412cba02 > c900802cba02 || 1 -> (412cba02 > > > >> 39) == 130 > > > > Yeah, we already know that in this function the aad variable is on the > > stack, it explicitly is. > > > > The question, though, is why precisely

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

On 14 October 2016 at 09:28, Johannes Berg wrote: > >>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. > >>

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

On 14 October 2016 at 09:28, Johannes Berg wrote: > >>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

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)

>    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)

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 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 Oct 13, 2016 6:46 AM, "Johannes Berg" wrote: > > 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 > > > >

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

On Oct 13, 2016 6:46 AM, "Johannes Berg" wrote: > > 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 > > > >

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

On (10/14/16 00:00), Sergey Senozhatsky wrote: > kernel: [] ieee80211_crypto_ccmp_decrypt+0x204/0x298 > kernel: [] ieee80211_rx_handlers+0x7df/0x1c1d > kernel: [] ieee80211_prepare_and_rx_handle+0xdc2/0xe79 > kernel: [] ? ieee80211_rx_napi+0x168/0x7b6 > kernel: []

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

On (10/14/16 00:00), Sergey Senozhatsky wrote: > kernel: [] ieee80211_crypto_ccmp_decrypt+0x204/0x298 > kernel: [] ieee80211_rx_handlers+0x7df/0x1c1d > kernel: [] ieee80211_prepare_and_rx_handle+0xdc2/0xe79 > kernel: [] ? ieee80211_rx_napi+0x168/0x7b6 > kernel: []

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

On (10/13/16 15:45), Johannes Berg wrote: > 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 > > > >

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

On (10/13/16 15:45), Johannes Berg wrote: > 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 > > > >

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: [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: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On (10/13/16 22:42), Sergey Senozhatsky wrote: > > On (10/13/16 08:02), Johannes Berg wrote: > > On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote: > > > > > In a pinch, I have these patches sitting around: > > > > > >

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

On (10/13/16 22:42), Sergey Senozhatsky wrote: > > On (10/13/16 08:02), Johannes Berg wrote: > > On Wed, 2016-10-12 at 22:39 -0700, Andy Lutomirski wrote: > > > > > In a pinch, I have these patches sitting around: > > > > > >

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

On (10/13/16 08:02), Johannes Berg wrote: > 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: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On (10/13/16 08:02), Johannes Berg wrote: > 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: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On Wed, Oct 12, 2016 at 7:22 AM, Johannes Berg wrote: > >> > 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

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

On Wed, Oct 12, 2016 at 7:22 AM, Johannes Berg wrote: > >> > 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

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: [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: [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: [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: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

Hello, On (10/12/16 11:05), Johannes Berg wrote: > Sorry - I meant to look into this yesterday but forgot. > > > Andy, can this be related to CONFIG_VMAP_STACK? > > I think it is. yeah, the system works fine with !CONFIG_VMAP_STACK. > > > current -git kills my system. > > Can you elaborate

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

Hello, On (10/12/16 11:05), Johannes Berg wrote: > Sorry - I meant to look into this yesterday but forgot. > > > Andy, can this be related to CONFIG_VMAP_STACK? > > I think it is. yeah, the system works fine with !CONFIG_VMAP_STACK. > > > current -git kills my system. > > Can you elaborate

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)

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)

Cc Andy Andy, can this be related to CONFIG_VMAP_STACK? On (10/11/16 00:03), Sergey Senozhatsky wrote: > Hello, > > current -git kills my system. adding > > if (!virt_addr_valid([2])) { > WARN_ON(1); > return -EINVAL; > } > > to

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

Cc Andy Andy, can this be related to CONFIG_VMAP_STACK? On (10/11/16 00:03), Sergey Senozhatsky wrote: > Hello, > > current -git kills my system. adding > > if (!virt_addr_valid([2])) { > WARN_ON(1); > return -EINVAL; > } > > to

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

Hello, current -git kills my system. adding if (!virt_addr_valid([2])) { WARN_ON(1); return -EINVAL; } to ieee80211_aes_ccm_decrypt() given the following backtrace WARNING: CPU: 5 PID: 252 at net/mac80211/aes_ccm.c:77

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

Hello, current -git kills my system. adding if (!virt_addr_valid([2])) { WARN_ON(1); return -EINVAL; } to ieee80211_aes_ccm_decrypt() given the following backtrace WARNING: CPU: 5 PID: 252 at net/mac80211/aes_ccm.c:77