Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934359AbcJMVua (ORCPT ); Thu, 13 Oct 2016 17:50:30 -0400 Received: from mail-vk0-f48.google.com ([209.85.213.48]:32884 "EHLO mail-vk0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756831AbcJMVuU (ORCPT ); Thu, 13 Oct 2016 17:50:20 -0400 MIME-Version: 1.0 In-Reply-To: <1476366354.4904.31.camel@sipsolutions.net> References: <20161010150358.GA514@swordfish> <20161010153050.GA836@swordfish> <1476263106.5271.23.camel@sipsolutions.net> <20161012141245.GA436@swordfish> <1476282127.5271.30.camel@sipsolutions.net> <1476338524.4904.1.camel@sipsolutions.net> <20161013134252.GA583@swordfish> <1476366354.4904.31.camel@sipsolutions.net> From: Andy Lutomirski Date: Thu, 13 Oct 2016 14:49:55 -0700 Message-ID: Subject: Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7) To: Johannes Berg Cc: Stephen Rothwell , "linux-next@vger.kernel.org" , Sergey Senozhatsky , Network Development , Sergey Senozhatsky , Herbert Xu , "David S. Miller" , Linux Wireless List , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1588 Lines: 45 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&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. > > > 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 > > >> 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