Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753519AbcJNJV6 (ORCPT ); Fri, 14 Oct 2016 05:21:58 -0400 Received: from mail-it0-f42.google.com ([209.85.214.42]:37185 "EHLO mail-it0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752015AbcJNJVu (ORCPT ); Fri, 14 Oct 2016 05:21:50 -0400 MIME-Version: 1.0 In-Reply-To: <1476436248.31114.21.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> <1476429916.4382.12.camel@sipsolutions.net> <1476433699.31114.6.camel@sipsolutions.net> <1476434561.31114.7.camel@sipsolutions.net> <1476435303.31114.14.camel@sipsolutions.net> <1476436248.31114.21.camel@sipsolutions.net> From: Ard Biesheuvel Date: Fri, 14 Oct 2016 10:21:49 +0100 Message-ID: Subject: Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7) To: Johannes Berg Cc: Andy Lutomirski , 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" , Jouni Malinen 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: 1371 Lines: 37 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 are two separate problems here, one which >> affects the WPA code, and one that only affects the generic CCM >> chaining mode (but not the accelerated arm64 implementation) > > Yes. The generic CCM chaining still doesn't typically have a request on > the stack though. In fact, ESP (net/ipv4/esp4.c) for example will do > temporary allocations with kmalloc for every frame, it seems. > 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. >> Unsurprisingly, I would strongly prefer those to be fixed properly >> rather than backing out my patch, but I'm happy to help out whichever >> solution we reach consensus on. > > Yeah, obviously, it would be good to use the accelerated versions after > all. > >> I will check whether this removes the issue when not using >> crypto/ccm.ko > > Ok. I think we can probably live with having those 48 bytes in per-CPU > buffers, but I suppose we don't really want to have ~500. > Agreed.