On Oct 13, 2016 6:46 AM, "Johannes Berg" [off-list ref] wrote:

On Thu, 2016-10-13 at 22:42 +0900, Sergey Senozhatsky wrote:

quoted

quoted

quoted

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
t/?h=x86/vmap_stack&id=0a39cfa6fbb5d5635c85253cc7d6b44b54822afd
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commi
t/?h=x86/vmap_stack&id=bf8cfa200b5a01383ea39fc8ce2f32909767baa8

That truly sounds like something we'd rather avoid in the TX/RX
paths though, which should perform well.

didn't fix.

It couldn't, since the new helpers weren't used in mac80211 in those
patches yet.

quoted

so I finally had some time to do a better bug-reporter job.

I added a bunch of printk-s and several virt_addr_valid()-s
to ieee80211_aes_ccm_encrypt().

and right befoe the Oops I see the following report from
virt_addr_valid()


 FAIL: 00004100002cba02 > ffffc900802cba02 || 1 -> (00004100002cba02

quoted

quoted

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 that fails in the crypto code.
Can you send the Oops report itself?

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.

There are a couple (faster!) APIs for crypto that don't use
scatterlists, but I don't think AEAD works with them.

--Andy