From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CD6B3D9DC4 for ; Wed, 22 Jul 2026 08:29:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784708996; cv=none; b=Aftl02k64YkD6l/Hq5wIAZWo3WgtcDNm4AVcT3/E5BVxs1D+AvutRrtKA5mgPGk9RxiwTE+CeSZTRJ85UlUuvUAh4VnR8WT8pRZ55udH9tdMuq6iaIjVyQ8jWdWwiwdo4yZF8fRskJ60WGRCYYIcF9fFaM3OELuJPZoAslZWP0Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784708996; c=relaxed/simple; bh=D/zlSFd1H5gthfkgYjTudpTd+BpF8ExOfLFelpBdujo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eknFnHyTVrGunHQt2A3BUG45JZxFjngJeAbmDmKgZP15sH/z1cU/+HaqSCxZv8jiGweiUsQDi5oeochYwXbCBq5EGxWzKpY9NdPUInyS3Chq32USGQW4TuCbclGd1o/mfsmnEQ7Nl2mWOpMIoMIQp2ujnMGaFIVvz6oC8flBPr4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=TCQU/kgm; arc=none smtp.client-ip=209.85.221.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="TCQU/kgm" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-47f878135e0so164367f8f.2 for ; Wed, 22 Jul 2026 01:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784708993; x=1785313793; darn=vger.kernel.org; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to :content-type; bh=+o5BhmpQGUXsPUn94swQ8qdBGf076Q7ku70v+i3VIFk=; b=TCQU/kgmUtjBnO3/OVGBkly+eRHPH5Yj4ojhiQFFa67sCF3OdqZNFyhSvA3sdLSm4q fMLPjmhPHEoH3OjZRP2R7toYmHad1jV4aw6CpknluP/By6xFw8GXN9mwrA2hFt1NVikn xpnu2twp4iTztmjldTVnEBx2fm/Jfkqtt/pQOyE9SmWqoXlG4sW7rpMTL3Yz8noVNNaz nDr66oYrVSnDWcHmm8+EDAh6FBG16cO0jyvn3ducg65fXPggWn+oBAV/+hKQxkitXrJi KQhxh6zMY7j4wCrK86bVckPq9ko2mjOmRd8lQxq0nY6SeR9qS3Si2HcQY7Qf9ZDffc5g oK8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784708993; x=1785313793; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+o5BhmpQGUXsPUn94swQ8qdBGf076Q7ku70v+i3VIFk=; b=iotic6O0eObudUMfE64dMNOLdBWgp/99pUfkJyo6IT/Erfs/d00AZ2dPWBxAIBVdJl zpeNjG9BPNC+HwJVi03AyPFgESRLjOa6tR2J+qMe1Lv2TYXwAi+FrhxUvi03DDhLTDnW e7xRv0ZMSssw0EBPO7eIxF6kjg8PRazrBWRpY9xakloGErdven5gGxQChIl4fRtMya1J AgfrNrZ4k2asF7KgPMLtuBmOcVBKTpKJUY7j1REKHo27DUscCW5IZcjlR6yv9uwjq5fB 15tbqoT0BjM19WRi3XM22szQ7FsBDrj9kAtAgYrboHmEN64Xcre7tYDNA/ityzP7SJws jztA== X-Forwarded-Encrypted: i=1; AHgh+RoL4ThMCU7i07QpGXc39mnD/NBoLJyZK2n33Q56PUdGLv0HyRzDGsceSaMJfRXpDBrA90lUzKa2uBw=@vger.kernel.org X-Gm-Message-State: AOJu0YxOqcM0KvTLqucL3OiyTX4xv29uv+iIJv2wxswltLWbHfNeTo5Y Lm+Dip9qmXFcMkyqLoEPAWYeBzptZsUqr/6dH9vVd+zev/3Umnd9x2vjtpviEwMLxjUue9yEx2c 9oVZY X-Gm-Gg: AR+sD11fOJ+IH9OzRmpQxdznMYKmInVDu518c28I7+ylDzR4syrcw4aCen6gKRZureJ aN6uDvrQuNS7IBGf6jRxrxqtpjnZYJ/ou5FIXempkrTTYUcG2CtPp1mWJwbNIdkRjqbKsslOoy6 FvsBLOmxsSyGWDznHIe6Ry6VH+N+Z0HVx6eJsfi/Cygs88qUe01bIN0pEblwI5/z5ycz6hEqbW/ V6wyZgYGhQRKkT1UsAME4WdazyZAg806wa7JwA03UvH+QEs5YvTRnzo7Bnb+Wmcokt53PbwVH/r mJoUdu0e0oMtFL+3a/q9Q3kDgbAX9JOnS0/Ir4I4b/nZrA6L6KxeCvXbVTHb5GP2L54CJ0S6eLu d3HPJzbSC64payVe2AHDh4v8euU61q/pq3laGev9IblWPLNUhMFiplZtQQfsDjPVKfeZRuAnrpQ YLuKr4eV9NTqJE0aSIUcY3GexEBPMNkiPUnZC6nY/dU9g= X-Received: by 2002:a05:6000:240f:b0:47f:83a1:6b7 with SMTP id ffacd0b85a97d-47f83a1070fmr4754652f8f.21.1784708992834; Wed, 22 Jul 2026 01:29:52 -0700 (PDT) Received: from ?IPV6:2a02:3033:6c0:905:69de:a6ba:2af3:1ea6? ([2a02:3033:6c0:905:69de:a6ba:2af3:1ea6]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47f85c6dc25sm4148066f8f.33.2026.07.22.01.29.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Jul 2026 01:29:52 -0700 (PDT) Message-ID: Date: Wed, 22 Jul 2026 10:29:50 +0200 Precedence: bulk X-Mailing-List: linux-usb@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 net-next 5/6] net: usb: pegasus: Move long delayed work on system_dfl_long_wq To: Marco Crivellari , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Frederic Weisbecker , Sebastian Andrzej Siewior , Michal Hocko , Andrew Lunn , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Petko Manolov , linux-usb@vger.kernel.org References: <20260720100902.155605-1-marco.crivellari@suse.com> <20260720100902.155605-6-marco.crivellari@suse.com> Content-Language: en-US From: Oliver Neukum In-Reply-To: <20260720100902.155605-6-marco.crivellari@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 20.07.26 12:08, Marco Crivellari wrote: Hi, > > Since the workqueue work doesn't rely on per-cpu variables, there is no > obvious reason that justify the use of a per-cpu workqueue. So change > system_long_wq with system_dfl_long_wq so that the work may benefit from > scheduler task placement. these changes are problematic, although they look like a good cleanup in first place. But the test you are using to determine whether USB devices need their own work queue is incomplete because you are not considering the reason they allocate their own work queues. These drivers have their own work queues because they are part of the block layer. USB devices can share a device with a block device (storage & UAS) and USB devices have common, per device operations, in particular reset and runtime power management and disconnect handling. Because these operations can be necessary to complete block IO neither they nor anything they depend on can use IO to allocate memory. That is they need to perform any memory allocation with GFP_NOIO or GFP_ATOMIC. That is also true for any operation on a work queue they need to wait for to make progress. That means you cannot limit your check to per-cpu variables. You also need to check for such dependencies. In particular any usage of flush_work() on such queues can deadlock, if you use common queues. Please refrain from making such changes unless you have fully analyzed the dependencies. Regards Oliver