Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752502AbcJNJ0E (ORCPT ); Fri, 14 Oct 2016 05:26:04 -0400 Received: from s3.sipsolutions.net ([5.9.151.49]:58003 "EHLO sipsolutions.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752282AbcJNJZ6 (ORCPT ); Fri, 14 Oct 2016 05:25:58 -0400 Message-ID: <1476437149.31114.27.camel@sipsolutions.net> Subject: Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7) From: Johannes Berg To: Ard Biesheuvel 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 Date: Fri, 14 Oct 2016 11:25:49 +0200 In-Reply-To: (sfid-20161014_112151_166035_C00E6A9E) 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> (sfid-20161014_112151_166035_C00E6A9E) 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: 924 Lines: 23 On Fri, 2016-10-14 at 10:21 +0100, Ard Biesheuvel wrote: > 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. I saw that, but I don't think generally there will be spare space for it - the stuff there is likely far too big. Anyway ... same problem that we have. I'm not inclined to allocate ~500 bytes temporarily for every frame either though. Maybe we could try to manage it in mac80211, we'd "only" need 5 AEAD structs (which are today on the stack) in parallel for each key (4 TX, 1 RX), but in a typical case of having 3 keys that's already 7.5K worth of memory that we almost never use. Again, with more complexity, we could know that the TX will not be used if the driver does the TX, but the single RX one we'd need unconditionally... decisions decisions... johannes