Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp2186544ybd; Mon, 24 Jun 2019 02:11:29 -0700 (PDT) X-Google-Smtp-Source: APXvYqzrEiQj8BfoeRSMhjhEOSv/54V8AywBWxtAo1E1Z+c2ZcVvf7x3COl2YWxYGMSqSofw18XS X-Received: by 2002:a63:c44f:: with SMTP id m15mr31363859pgg.34.1561367488875; Mon, 24 Jun 2019 02:11:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561367488; cv=none; d=google.com; s=arc-20160816; b=pOyoI1Iu2njFxr4+pMfJZgEfiXG5XfJ+SOEsv6QkN0R0Ub3fqOF92oAA5XerhBMwxY KDvrEim9Netr7s0vXtmJpPHeSqGmMavQ4nHxZ9S97WY8Hyc1g3bpHz81ZSdIgx+VfmMA GVnApHTLplyGAjQhpmvDvsqIZqJcs1ePWGYEuUOUa8lvWkREVXSDf/KGb0n8bDhgnoKs Ub8EQa3RTnG9p5g49e5NKhiUsTIpwivgFg8Z9BIA6wa7Lh9a5pwN4TgOyJ0XF6W2r3w6 /CmqNh+g1R+o/NQsEtIybHQeyEV+RuxV5SutwyA1jDO/iQ9Arfi0TiUb3/mcid085hHX 2X8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=lRDk2dVg2rjLqXupTUzQ2W4fdOLJivsr0lrfpq7UJns=; b=QtRmJtLexv1vhZlHjms7xklWZzW/IRPcniP0Ljzklmww/k6bSaBzR1/mUZQzCumDgJ aAAc/yOFDK/E+2ps0GircjGAfN6htC8GL6zPLbpAO4+6YDu5ueEeP22HZh0hJNTwWb/K Mk2SjXwFyGxbE5IRQshPGtsCnh21R23gNSTQ5kI2oUrtF7Jw09BUMGiejSyQWedf7nMJ Jiw/b2hVZ9jG7Y6OOcmpragh1hPKv+ofHIf9idzxtGQ05OVGUDJ9o0uHXgnFqa7JnLSL 82w5DKy7TPkvB+HNL9C3+PwHfbDBj4oZfxHt6+uu/ueJztIEar0lU8zltJjHD2GNZAXY QNtw== 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 i10si9186054pgs.231.2019.06.24.02.11.12; Mon, 24 Jun 2019 02:11:28 -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 S1728341AbfFXJKe (ORCPT + 99 others); Mon, 24 Jun 2019 05:10:34 -0400 Received: from mx2.suse.de ([195.135.220.15]:49894 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1728019AbfFXJKe (ORCPT ); Mon, 24 Jun 2019 05:10:34 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 63E10AB87; Mon, 24 Jun 2019 09:10:33 +0000 (UTC) Message-ID: <1561366612.2846.10.camel@suse.com> Subject: Re: [RFC] deadlock with flush_work() in UAS From: Oliver Neukum To: Tejun Heo , Alan Stern Cc: Kernel development list , USB list Date: Mon, 24 Jun 2019 10:56:52 +0200 In-Reply-To: <20190620140937.GJ657710@devbig004.ftw2.facebook.com> References: <1560871774.3184.16.camel@suse.com> <20190620140937.GJ657710@devbig004.ftw2.facebook.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Donnerstag, den 20.06.2019, 07:10 -0700 schrieb Tejun Heo: > Hello, > > On Tue, Jun 18, 2019 at 11:59:39AM -0400, Alan Stern wrote: > > > > Even if you disagree, perhaps we should have a global workqueue with a > > > > permanently set noio flag. It could be shared among multiple drivers > > > > such as uas and the hub driver for purposes like this. (In fact, the > > > > hub driver already has its own dedicated workqueue.) > > > > > > That is a good idea. But does UAS need WQ_MEM_RECLAIM? > > > > These are good questions, and I don't have the answers. Perhaps Tejun > > or someone else on LKML can help. > > Any device which may host a filesystem or swap needs to use > WQ_MEM_RECLAIM workqueues on anything which may be used during normal > IOs including e.g. error handling which may be invoked. One > WQ_MEM_RECLAIM workqueue guarantees one level of concurrency for all > its tasks regardless of memory situation, so as long as there's no > interdependence between work items, the workqueue can be shared. Ouch. Alan, in that case anything doing a reset, suspend or resume needs to use WQ_MEM_RECLAIM, it looks to me. What do we do? Regards Oliver