From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25BA9369207 for ; Fri, 5 Jun 2026 17:30:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780680614; cv=none; b=cX5soPSCty8rc53IsHY4xuxMe0I0r7WF/1LrOSeJzvj9KLgfPoV0JRaJfHMYG/MCdr1KpN3pyvZiaKAj/noEnWunI5iP9BJq1czET4aECPxYattELsx0gNWBVw9ycnvvuEc7Zim+o9MEOuNCTL7/V9QGq5u2R/Bb6Ham//9EuCo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780680614; c=relaxed/simple; bh=uurwa78wtrxvK2TkgHc0aEMWkjl4WtSiYMs9zC7P9rs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YdseraUMxP0npjDEP86egG/tUAhXIBmbPLQC2xt5AU7ewHee1DunODAAUW+jQ4Mbk8RrSg0sZGUdwhiVxXTYGILpDjgzUv7mBroB44dio2zqYd+QAH7YnkK9cVOet+OysvBlOZkiXFHm4fABUPtwHpL0kIa6kVuAP4Z9nwgIx1w= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=El/IpoLc; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="El/IpoLc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C6311F00893; Fri, 5 Jun 2026 17:30:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780680609; bh=P/fPzBZSNscDTC569xs4RPRnZKowYFglEBw2zR6jMKg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=El/IpoLcyJGjYjLAO0VirilDg9OMgj2BI9KgZC7L5MTguCLaHOMGwcGT0sGDaN7Vj liAx4pTymMOSi4At8yzu6p5GA1uI0ZNOo7vnc1QHM7VRd+BvZSnUXp9ryu7bFqWC+5 qWmvQO28j/MqdUg8bFSH8DbJJddFAYOU4WZchVWheseRPxbqz+/qQSCwy5q8R9qndf XIfdEmMw7LnZpggnXPmVWlQJRDAGVtAddQXpc3aA813Owj5d+a6w6XvFPpsyrJ5MUF SJGlDgCJpHH/cKGizrCbMRoWUu+0K0rC1pAx5p0Hg36AIF2l2sG2Tl8lC2GxbxHPZg McKGakXkjA7Og== Date: Fri, 5 Jun 2026 07:30:08 -1000 From: Tejun Heo To: Breno Leitao Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, marco.crivellari@suse.com, frederic@kernel.org, bigeasy@linutronix.de, Hillf Danton , kernel-team@meta.com Subject: Re: [PATCH v2 1/4] workqueue: park kicked worker on pool->kicked_list Message-ID: References: <20260603-fastwake-v2-0-2977512fe7fa@debian.org> <20260603-fastwake-v2-1-2977512fe7fa@debian.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hello, On Fri, Jun 05, 2026 at 07:40:43AM -0700, Breno Leitao wrote: ... > > > task state, so a kicked-but-not-yet-scheduled worker is still a valid > > > cull victim -- the cull can reap it before it consumes the just-enqueued > > > work, stranding the item. The window is narrow today but later patches > > > in this series defer the wakeup outside pool->lock, widening it. > > > > Have you actually reproduced this? > > No -- not without artificially changing the timeout in the kernel. So far this > is a theoretical race window rather than something I've hit in > practice; it was flagged as a critical issue by sashiko: > > https://sashiko.dev/#/patchset/20260526-fastwake-v1-0-e69ad86923e6%40debian.org > > The only way I could get it to actually strand an item was by shrinking > IDLE_WORKER_TIMEOUT 150,000x (300s -> 2ms), so that a worker counts as > "timed out" almost immediately. I see. This is a bug then. It shouldn't happen even with that. > Would it make sense to refresh last_active when a worker is kicked? The > cull walks tail->head and breaks at the first non-expired worker, so a > freshly-stamped kicked worker would simply be skipped while genuinely > old workers behind it are still reaped. I don't think timestamping is where the problem is. The intention of the code is that the idle thread minimum count + how workers transition their states can't lead to a situation where a work item is pending without an idle worker to execute it regardless of timing. Can you instrument code with the lowered threshold and record the sequence of events. If we record the sequence of work item and worker state transitions, it should tell us what's broken. We shouldn't need to protect all kicked workers to fix this. Thanks. -- tejun