From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 56CCA34AB0B for ; Wed, 11 Feb 2026 18:56:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770836173; cv=none; b=uIAAniCo5mtlgEc2lNfzMnHoTJ3TjF04QdWxc11aK44Ew5UrSdGfmNbwu8Kn7lEe5enAML2KuIfYIR0C+Uw8nvQl/+yO8KbSR/gRbkA/jXKyzXP2nqZMoyVihvXh88VUyz5AYxF9j0fbPatMsyHuSIsvQoBfS782e+rfQmTufK0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770836173; c=relaxed/simple; bh=hvRjQAFFK4pjqGWXEcbjfwjcfMCvTumyM0VaKZ/buaI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=F3jF+GDijhzQuYG3UxJX8grQAj+Em3uh37mCYl1l+JT3kXE4GuisWUBzfSowG8DvYxqDZCJbCwfQ5prqWFvchcH/06JSrEXHtdDFj8c1exGhZbZweDo0LWhCMvJoxad2XnJqwS1CgecCcnrntfL4xcYCox6G2bw/Z/ostdYJW7U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PyRh/B9J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PyRh/B9J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBB09C4CEF7; Wed, 11 Feb 2026 18:56:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770836172; bh=hvRjQAFFK4pjqGWXEcbjfwjcfMCvTumyM0VaKZ/buaI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=PyRh/B9JNcTYDfKUVd/Hfq4SWfu9BBkN2F0C3WOK46AVPGmQdXl18bAOAQhApl5sm jk0tKoC6ttTEz3HrQ4vey4sLtaYtxFGcIrH7mqVwspE/03kzImnByFiSoNhUNsJJzd ZwB94RtYauneel53E+toKnmEP4irENkcohWgUEcqKG6h8o2xWgtp+tcqgt86khT0ij sk9fEWZxuwj2mXd7eOe7gw89I6BX0kfgNAWUyqAC1R2oloukCyu+7j0WwXCP1coTzd Ja7pP8cWvXmDf6KG85q+mphnBKcegw6DPf+4bryUmX2p2eM0AE1air7QIdf1lzPYL3 erd7toUu90bLw== Date: Wed, 11 Feb 2026 08:56:11 -1000 From: Tejun Heo To: Breno Leitao Cc: Lai Jiangshan , Andrew Morton , linux-kernel@vger.kernel.org, Omar Sandoval , kernel-team@meta.com Subject: Re: [PATCH 0/4] workqueue: Detect stalled in-flight workers Message-ID: References: <20260211-wqstall_start-at-v1-0-bd9499a18c19@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: <20260211-wqstall_start-at-v1-0-bd9499a18c19@debian.org> Hello, On Wed, Feb 11, 2026 at 04:29:14AM -0800, Breno Leitao wrote: > The workqueue watchdog detects pools that haven't made forward progress > by checking whether pending work items on the worklist have been waiting > too long. However, this approach has a blind spot: if a pool has only > one work item and that item has already been dequeued and is executing on > a worker, the worklist is empty and the watchdog skips the pool entirely. > This means a single hogged worker with no other pending work is invisible > to the stall detector. > > I was able to come up with the following example that shows this blind > spot: > > static void stall_work_fn(struct work_struct *work) > { > for (;;) { > mdelay(1000); > cond_resched(); > } > } Workqueue doesn't require users to limit execution time. As long as there is enough supply of concurrency to avoid stalling of pending work items, work items can run as long as they want, including indefinitely. Workqueue stall is there to indicate that there is insufficient supply of concurrency. Thanks. -- tejun