From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from stravinsky.debian.org (stravinsky.debian.org [82.195.75.108]) (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 30847363C4A for ; Fri, 20 Mar 2026 10:44:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=82.195.75.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774003454; cv=none; b=HZ8/0eYKuukagpneDvM/MANY1f8n3wm2nQ6r0FHTqHPn3V6jKc4nmpDlg7F7zGU6dYH70nO2Jr1RaATRnuzob7ygGo/EgM6FlaVMNacCLkCea+F8Er1eJ4YRI8m9auECAS82GgQCavjrQqgiblBERZEKwxkk5dNSrdWna/ARsVw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774003454; c=relaxed/simple; bh=+tdWidweTh6G0X36PLqPE3mLtfFJYqsxdNmWZHRpXDk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hCnKB+mFw3/CwSmnnSrECeMtpJ3nQtj6PKCwldiEOZM/6HbHLGicx8n+Gg1VCGUyNMtAS2gM2r/yMhoBj8b1OAYTeyofcfZUGVwfv1EG/rimq8LSUXBZ7S6LrNByaza0DRuOcvHgT39xH7WawUpfdJm8Fhr5mUMlwTa5MHf/ECY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org; spf=none smtp.mailfrom=debian.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b=Oj7eRgST; arc=none smtp.client-ip=82.195.75.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=debian.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=debian.org header.i=@debian.org header.b="Oj7eRgST" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=ypFXggknwhcIjvBkD6cWcZwEM8ckRReuae+YojGI5R8=; b=Oj7eRgSTYlkivlFzJfCm3wzWAR ztqRfdXhRrtF0kh08X9cQG7m14EftaaTngR4Ckw7upOkGtVfvT++sgdRp4xpk+hoqm1aYGYEpCsIf tVjfBtZGbFkqgXrTtmeVR6H6KyTjLZhn20X6eJthBB5f+GAR4rMFXLral3yhFNlbBcBMn95x/0AHW FJ6pcib35nSMHTXqzYsSprvQMaw2F8m9pHfEkSxx65WjRiydNyzxsM6ZDus0m1NkfAutb0mGXg5GJ OA4XXFd5RkkQ8+xm9FfYCM7G/UbA/4K1qFoP7AecvJk61jnJv/aMUM6NmmVIkEpj5CTknSWhkT8if qmFltFkg==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1w3XKq-0059Jn-WF; Fri, 20 Mar 2026 10:44:07 +0000 Date: Fri, 20 Mar 2026 03:44:03 -0700 From: Breno Leitao To: Petr Mladek , song@kernel.org Cc: Tejun Heo , Lai Jiangshan , Andrew Morton , linux-kernel@vger.kernel.org, Omar Sandoval , Song Liu , Danielle Costantino , kasan-dev@googlegroups.com, kernel-team@meta.com Subject: Re: [PATCH v2 0/5] workqueue: Detect stalled in-flight workers Message-ID: References: <20260305-wqstall_start-at-v2-0-b60863ee0899@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: X-Debian-User: leitao > > Showing backtraces of busy workers in stalled CPU-bound worker pools: > > I would expect that the stalled pool was shown by show_one_workqueue(). > > show_one_workqueue() checks pwq->nr_active instead of > list_empty(&pool->worklist). But my understanding is that work items > added to pool->worklist should be counted by the related > pwq->nr_active. In fact, pwq->nr_active seems to be decremented > only when the work is proceed or removed from the queue. So that > it should be counted as nr_active even when it is already in progress. > As a result, show_one_workqueue() should print even pools which have > the last assigned work in-flight. > > Maybe, I miss something. For example, the barriers are not counted > as nr_active, ... Chatting quickly to Song, he believed that we need a barrier in-between adding the worklist and updating last_progress_ts, specifically, the watchdog can see a non-empty worklist (from a list_add) while reading a stale last_progress_ts value, causing a false positive stall report. as well