Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp5098533ybi; Tue, 28 May 2019 07:31:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqznraJF2hasY/FZC0CtjZfRv85CNh5b09qr48JcYCfv0+wqEnSCrC2Y7xA3tTFKIgK2jO39 X-Received: by 2002:a63:484f:: with SMTP id x15mr62552026pgk.162.1559053889586; Tue, 28 May 2019 07:31:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559053889; cv=none; d=google.com; s=arc-20160816; b=mclvOl5tP12oixxXMg0RwuHSweFdsEkp5OJBb+vXdm4NSyR4xa6yXicl28Ai+I2Dh6 jiIw8edqVHLm/l1KicqbFRWxzv8hL1qGAyHDZdABLSfiOM89ZM5godygjQL4pBxzjUkq sMyHhpMpz9KqtGC0y3Qr/F6OGgu1TATXgZBV5Ylbj5jOgA+3Akkoxsr72xamWRGBi9sG yo0stxSEKCwMi1EhIFgg2JAvs5dgUX3l6frUvONYmIug1mgbIFs3Fo4w5jdRx7BVHuS3 m8Lfa4dej89cCjxAb9BlnkfE3cXAnbxnToCVT7nbCCWW1YygPyRlaIuSAIsPY2U1jh2c Zj0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date; bh=ZKZTqXkEbN74CEM7lcdriB5nB3XD4Wz5u4BVx/rL364=; b=XcO74s8zN5HvKbsphnbxcteCZswAnujDaUPgj8SsHlok7NQ8M7lq3RmH2a5Y1xFhUC fyDGTMqTjmdUETmzdjMFlSMea/+j/CcIlsh7O+drkAxSq37dRtUKTgI8wZTI6QQdQybp U7xgxUtbhffxBBqGGd4nrN9vVhCUfblalgAU/DODKQxxbGQ17Ql076TteMTZE4kI9Anr Yd3ShZ5KFh147qbDsTPgbqQuEjqFw/Lguvlss3UWYOHxHfJbnLntXlc61I6KQuNwrNRS FQ97g2cMx5SCFcWxEZuj/cXDhtndhLIbHhyBKjtDPFl3vizKYxaeqlCDEOnBgpe6ny0V 0k5A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1si22547825pgc.565.2019.05.28.07.31.14; Tue, 28 May 2019 07:31:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727756AbfE1OZO (ORCPT + 99 others); Tue, 28 May 2019 10:25:14 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:38318 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1727192AbfE1OZN (ORCPT ); Tue, 28 May 2019 10:25:13 -0400 Received: (qmail 1867 invoked by uid 2102); 28 May 2019 10:25:12 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 May 2019 10:25:12 -0400 Date: Tue, 28 May 2019 10:25:12 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Oliver Neukum cc: Jaewon Kim , Christoph Hellwig , , , Jaewon Kim , , , , Subject: Re: [RFC PATCH] usb: host: xhci: allow __GFP_FS in dma allocation In-Reply-To: <1559046886.13873.2.camel@suse.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 28 May 2019, Oliver Neukum wrote: > Am Donnerstag, den 23.05.2019, 10:01 -0400 schrieb Alan Stern: > > On Wed, 22 May 2019, Oliver Neukum wrote: > > > > > On Mi, 2019-05-22 at 10:56 -0400, Alan Stern wrote: > > > > On Wed, 22 May 2019, Oliver Neukum wrote: > > > > > > > > > I agree with the problem, but I fail to see why this issue would be > > > > > specific to USB. Shouldn't this be done in the device core layer? > > > > > > > > Only for drivers that are on the block-device writeback path. The > > > > device core doesn't know which drivers these are. > > > > > > Neither does USB know. It is very hard to predict or even tell which > > > devices are block device drivers. I think we must assume that > > > any device may be affected. > > > > All right. Would you like to submit a patch? > > Do you like this one? Hmmm. I might be inclined to move the start of the I/O-protected region a little earlier. For example, the first blocking_notifier_call_chain() might result in some memory allocations. The end is okay; once bus_remove_device() has returned the driver will be completely unbound, so there shouldn't be any pending I/O through the device. Alan Stern