From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1755582AbcHBIMr (ORCPT <rfc822;w@1wt.eu>);
	Tue, 2 Aug 2016 04:12:47 -0400
Received: from mx2.suse.de ([195.135.220.15]:40507 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751716AbcHBIMm (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 2 Aug 2016 04:12:42 -0400
Message-ID: <1470125172.30985.4.camel@suse.com>
Subject: Re: [RFC] usb: host: u132-hcd: Remove deprecated
 create_singlethread_workqueue
From: Oliver Neukum <oneukum@suse.com>
To: Tejun Heo <tj@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>, Geliang Tang <geliangtang@163.com>,
        Johannes Weiner <hannes@cmpxchg.org>,
        Bhaktipriya Shridhar <bhaktipriya96@gmail.com>,
        "GeyslanG.Bem@Karyakshetra" <geyslan@gmail.com>,
        Masanari Iida <standby24x7@gmail.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Alan Stern <stern@rowland.harvard.edu>,
        Vlastimil Babka <vbabka@suse.cz>,
        Mel Gorman <mgorman@techsingularity.net>, linux-kernel@vger.kernel.org,
        linux-usb@vger.kernel.org, Saurabh Karajgaonkar <skarajga@visteon.com>
Date: Tue, 02 Aug 2016 10:06:12 +0200
In-Reply-To: <20160801142005.GB2542@mtj.duckdns.org>
References: <20160727192308.GP4144@mtj.duckdns.org>
	 <Pine.LNX.4.44L0.1607271637140.1664-100000@iolanthe.rowland.org>
	 <20160729131147.GJ2542@mtj.duckdns.org>
	 <20160801135036.GH13544@dhcp22.suse.cz>
	 <20160801142005.GB2542@mtj.duckdns.org>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.12.11 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 2016-08-01 at 10:20 -0400, Tejun Heo wrote:
> Hello,

> > If any real IO depends on those devices then this is not sufficient and
> > they need some form of guarantee for progress (aka mempool).
> 
> Oliver, Alan, what do you think?  If USB itself can't operate without
> allocating memory during transactions, whatever USB storage drivers

It cannot. The IO must be described to the hardware with a data
structure in memory.

> are doing isn't all that meaningful.  Can we proceed with the
> workqueue patches?  Also, it could be that the only thing GFP_NOIO and
> GFP_ATOMIC are doing is increasing the chance of IO failures under
> memory pressure.  Maybe it'd be a good idea to reconsider the
> approach?

We had actual deadlocks with GFP_KERNEL. It seems to me that the SCSI
layer can deal with IO that cannot be completed due to a lack of memory
at least somewhat, but a deadlock within a driver would obviously be
deadly. So I don't think that mempools would remove the need for
GFP_NOIO as there are places in usbcore we cannot enter the page
laundering path from. They are an additional need.

	Regards
		Oliver