From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753296AbcJCTTw (ORCPT ); Mon, 3 Oct 2016 15:19:52 -0400 Received: from mail-oi0-f43.google.com ([209.85.218.43]:32965 "EHLO mail-oi0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753007AbcJCTTo (ORCPT ); Mon, 3 Oct 2016 15:19:44 -0400 MIME-Version: 1.0 In-Reply-To: References: <205cfce1-d54c-262d-f939-ad9f37b0c52c@huawei.com> <878tud4q6x.fsf@linux.intel.com> <261ada71-8a5d-6e89-7fac-6b6ba88218d7@huawei.com> From: John Stultz Date: Mon, 3 Oct 2016 12:19:42 -0700 Message-ID: Subject: Re: BUG: scheduling while atomic in f_fs when gadget remove driver To: Michal Nazarewicz Cc: Chen Yu , Felipe Balbi , Greg KH , Biggo Wang , lkml , linux-usb@vger.kernel.org, Amit Pundir , Guodong Xu 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-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id u93JJt3W003873 On Wed, Sep 28, 2016 at 2:38 PM, Michal Nazarewicz wrote: > On Wed, Sep 28 2016, Michal Nazarewicz wrote: >> With that done, the only thing which needs a mutex is >> epfile->read_buffer. > > Perhaps this would do: > > ---- >8 -------------------------------------------------- ------------- > From 6416a1065203a39328311f6c58083089efe169aa Mon Sep 17 00:00:00 2001 > From: Michal Nazarewicz > Date: Wed, 28 Sep 2016 23:36:56 +0200 > Subject: [RFC] usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable > MIME-Version: 1.0 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 8bit > > ffs_func_eps_disable is called from atomic context so it cannot sleep > thus cannot grab a mutex. Change the handling of epfile->read_buffer > to use non-sleeping synchronisation method. > > Reported-by: Chen Yu > Signed-off-by: Michał Nazarewicz > Fixes: 9353afbbfa7b ("buffer data from ‘oversized’ OUT requests") So the patch here seems to be in some odd encoding? Can you resend it using git-send-email or in some way other then embedding it inline here? Maybe just point me to a git tree that has it? thanks -john