Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757193AbcJNHZh (ORCPT ); Fri, 14 Oct 2016 03:25:37 -0400 Received: from s3.sipsolutions.net ([5.9.151.49]:57178 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753004AbcJNHZb (ORCPT ); Fri, 14 Oct 2016 03:25:31 -0400 Message-ID: <1476429916.4382.12.camel@sipsolutions.net> Subject: Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7) From: Johannes Berg To: Andy Lutomirski 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" , Ard Biesheuvel Date: Fri, 14 Oct 2016 09:25:16 +0200 In-Reply-To: (sfid-20161013_235018_225755_5BCF27D2) 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> (sfid-20161013_235018_225755_5BCF27D2) Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5-1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1390 Lines: 34 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 see, so all this stuff is getting inlined, and we crash in sg_set_buf() because it does sg_set_page() and that obviously needs to do virt_to_page(), which is invalid on this address now. With CONFIG_DEBUG_SG we'd have hit the BUG_ON there instead. It does indeed look like AEAD doesn't have any non-SG API. So ultimately, the bug already goes back to Ard's commit 7ec7c4a9a686 ("mac80211: port CCMP to cryptoapi's CCM driver") since that already potentially used stack space for DMA. Since we don't have any space in the SKB or anywhere else at this point (other than the stack that we can't use), I see two ways out of this: 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) 2. allocate a per-CPU buffer for all the things that we put on the stack and use in SG lists, those are: * CCM/GCM: AAD (32B), B_0/J_0 (16B) * GMAC: AAD (20B), zero (16B) * (not sure why CMAC isn't using this API, but it would be like GMAC) Thoughts? johannes