From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (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 9C3403859CB for ; Wed, 22 Jul 2026 08:29:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784708997; cv=none; b=j+tJlEk9g8i1tfUu+i1Sfk2OJd+BRXNNNFaxzqAD65TFOpWS84no6Ug3o5F8HMARcNPKbMcSpmn+1VC7QcAnU2LuzTqkrBjnCzV+eWaHk2/HdFPf3D9mt7ApOuL/WjBWcwJj/qEeDotxDd12vNdB4Arv12XW5iuVzx5pAv1oQdY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784708997; c=relaxed/simple; bh=D/zlSFd1H5gthfkgYjTudpTd+BpF8ExOfLFelpBdujo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Q3qUBFgKqMFmhvvG01i4TeJIOZKhzab/GY/mBgCRdGf+TQVnMwRcL7pAXZSMWzVlxAwG6I2K6Kb0K5OvfIax5HuwiLYuFGloMqB3EGBDCpBiLHgVm4dvCalkLIwY3DlQAQTXmASec2osgUjZt6nLFr9Ik2LoKaA1ZrsKXWgtEK8= 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.48 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-f48.google.com with SMTP id ffacd0b85a97d-47f7444576cso2297918f8f.0 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=qbrYqeuvPtJ4VoDTaeVMDGpEF+wPLNrg/JZIorU/XkjKHDdIB7UjXGmym2/pzizNMR jRoXs5wgYwjchn7w+ix3bfHxpwaVl671vjV12rcts0yO2L33HEB5hMoXOAL7lw1S6w/j YDdc1Pdvk+5bqbZ3/HTNY+D09euHDqHE7kZIHSgdjDCBUw0PZ1OSBt7TLWBk6e8WpN59 DNh4Rn/5WIG/wHm8/MJdsSh0O0VEebkt037Qfq4OTWx+neqdk24eJl0iMtgLh8iZZm23 8G8tOvuQwpxhEVIJofkOYpDzCscvTZdwS6s/SvrOzrryYZHPz0q2UKXVWip3NMORx4v4 3b1Q== X-Forwarded-Encrypted: i=1; AHgh+RoB+8/sija4xojd6PZxxG//8zDkFdsvWjEWY8G2Hg2j5Pb3g0uHg8e3daGLL2EZnUzJvsy3HCvjwuH/uqE=@vger.kernel.org X-Gm-Message-State: AOJu0YyF2LMNTIqstUyVYMktKfhDpejr+njmXGubR8pPMujETavjX/C4 6D/nZCiZsJ2V34d+yLli42Ilyjd517PxH8RIWcrou9dLQl/ptxiSNDWe7iN7yiDmDWY= X-Gm-Gg: AR+sD12TTG9sUmW+evb0w5rr9d37nlG02kLqzZxAycNbgLAtyu1R/08uk2bgnimmxby XCj/HA0d1Q6pMH23VS48pcVl0mYKkFjuH6iOSXA53F7WSkWLjvfBBfk4zh/6UL1Jm6viwixBf/I N7boEicDs8+J7NCbiWfU+S7ifeo+J9oIHvekXpKbu7UAXD9EOW27Wz6pXPlpOqLo/0yYzVQWV4j jJt81vWEfTIzNwG36+6x4Ei2aJyZYPrWVNZ8JxPgrrJ0nlHPZbDr963ZL6ex4dmPNG9Q4zWtGh/ kohXgDkhJY/EBIpVYFciX+Dgprhv1UPByBYMCtXHRDmMlrCFgJvCTIGmRSTuL8XHuotiASClYjU EtsvF0W2qx5jq55oWFAfGElyzDdlE5TwEDCXuCcUByNZxet+8qh+fsELjbOYWc61LuAqcI+vQvR V3CwzbeIZ/RoZpJlT7NyhQ6FfNhRXpFL959u6dMB1yp0k= 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-kernel@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