Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752875AbcJNJFJ (ORCPT ); Fri, 14 Oct 2016 05:05:09 -0400 Received: from mail-io0-f178.google.com ([209.85.223.178]:36592 "EHLO mail-io0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750846AbcJNJFB (ORCPT ); Fri, 14 Oct 2016 05:05:01 -0400 MIME-Version: 1.0 In-Reply-To: <1476435303.31114.14.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> From: Ard Biesheuvel Date: Fri, 14 Oct 2016 10:05:00 +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: 1091 Lines: 29 On 14 October 2016 at 09:55, Johannes Berg wrote: > On Fri, 2016-10-14 at 09:47 +0100, Ard Biesheuvel wrote: >> >> Do you have a reference for the sg_set_buf() call on odata? >> crypto/ccm.c does not seem to have it (afaict), > > It's indirect - crypto_ccm_encrypt() calls crypto_ccm_init_crypt() > which does it. > Indeed. And the decrypt path does the same for auth_tag[]. 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) 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. >> 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. > > I had that with per-CPU buffers, just sent the patch upthread. > I will check whether this removes the issue when not using crypto/ccm.ko