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

2016-10-14 Thread Ard Biesheuvel
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)

2016-10-14 Thread Johannes Berg
> 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)

2016-10-14 Thread Ard Biesheuvel
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)

2016-10-14 Thread Sergey Senozhatsky
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)

2016-10-14 Thread Ard Biesheuvel
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)

2016-10-14 Thread Johannes Berg
>    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)

2016-10-14 Thread Johannes Berg
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)

2016-10-13 Thread Sergey Senozhatsky
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)

2016-10-13 Thread Sergey Senozhatsky
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)

2016-10-13 Thread Johannes Berg
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)

2016-10-13 Thread Sergey Senozhatsky
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)

2016-10-13 Thread Sergey Senozhatsky
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)

2016-10-13 Thread Johannes Berg
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)

2016-10-12 Thread Johannes Berg
> > 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)

2016-10-12 Thread Sergey Senozhatsky
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)

2016-10-12 Thread Johannes Berg
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)

2016-10-10 Thread Sergey Senozhatsky
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