Return-path: Received: from mail-io0-f181.google.com ([209.85.223.181]:34136 "EHLO mail-io0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751033AbcJNIsU (ORCPT ); Fri, 14 Oct 2016 04:48:20 -0400 Received: by mail-io0-f181.google.com with SMTP id r30so114110142ioi.1 for ; Fri, 14 Oct 2016 01:47:21 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1476434561.31114.7.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> From: Ard Biesheuvel Date: Fri, 14 Oct 2016 09:47:20 +0100 Message-ID: (sfid-20161014_104924_658745_BEAD16E5) 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-wireless-owner@vger.kernel.org List-ID: On 14 October 2016 at 09:42, Johannes Berg wrote: > On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote: > >> > I assume the stack buffer itself is not the problem here, but aad, >> > which is allocated on the stack one frame up. >> > Do we really need to revert the whole patch to fix that? >> >> Ah never mind, this is about 'odata'. Apologies, should have read >> first > > Right, odata also goes into an sg list and further on. > > I think we should wait for Herbert to chime in before we do any further > work though, perhaps he has any better ideas. > Do you have a reference for the sg_set_buf() call on odata? crypto/ccm.c does not seem to have it (afaict), and the same problem does not exist in the accelerated arm64 implementation. In the mean time, I will try and see if we can move aad[] off the stack in the WPA code.