From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-172.mta0.migadu.com (out-172.mta0.migadu.com [91.218.175.172]) (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 A44D0304BDF for ; Wed, 10 Jun 2026 04:56:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781067400; cv=none; b=ALs+qJUG7wIKQrBkp+l0z2VUZOeRIB7g8u29Q899bNkjU4+6DLOcu/9F/CWxBnGCxosRwE15gDtRRd2DOSRoeAoeRB2JB08yGDJecG5p+C6ZqqKM5p2iICvbndPFFnhYpLXOWUOzPktm2/Z4PI8qgmyMs9mP3JDHV+Awrk/HyGc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781067400; c=relaxed/simple; bh=bQxhAD/TewLo7uE2gN//P4xx7NdJzNAKSEm/w5TcLxg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=URJY8P00azMnICIFp8sQdA62p1S4USF/Dn5G3t4ln8xx0WpQqwtAUuZw/fl4BdGSKDmjVFG5GJwFsVRQEIUU37b8c6VRho+xG+3s4sT933gmvokTUzcf6RVQhyuHUB24LFnQX8eTzaj7QAhD6DlwjUNlO9JdAttuE5flTUTFnuI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=KPuBiriP; arc=none smtp.client-ip=91.218.175.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="KPuBiriP" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1781067391; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3LLL2tbdrNFlBdviOTZn0Zk3ROyJs5PUPFRhZVmiiFc=; b=KPuBiriPYIZuU/h3FBAcrg3LDOjUF8aU1rZmdx4wVK+aflBg2CGKw9m7R1bMQ1FVEQkXRt Ic0ZjdMI9phOAGsUcb1YcW/p9qNnL/7uFt+ILEnBtoNRp9SINuHSrKB/m1sR4ZgqDuouP2 KW72VcXPpVdRT5n0iQZcR6RA7o3P5DY= From: Lance Yang To: kanchanapsridhar2026@gmail.com, yosry@kernel.org, nphamcs@gmail.com, coregee2000@gmail.com Cc: syzkaller@googlegroups.com, hannes@cmpxchg.org, chengming.zhou@linux.dev, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Lance Yang Subject: Re: [Kernel Bug] INFO: task hung in zswap_decompress Date: Wed, 10 Jun 2026 12:56:23 +0800 Message-Id: <20260610045623.10574-1-lance.yang@linux.dev> In-Reply-To: References: 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=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Tue, Jun 09, 2026 at 08:36:29AM -1000, Kanchana P. Sridhar wrote: >On Tue, Jun 9, 2026 at 10:50 AM Yosry Ahmed wrote: >> >> On Tue, Jun 9, 2026 at 8:40 AM Nhat Pham wrote: >> > >> > On Tue, Jun 9, 2026 at 4:51 AM Longxing Li wrote: >> > > >> > > Dear Linux kernel developers and maintainers, Thanks for reporting this! >> > > >> > > We would like to report a new kernel bug found by our tool. INFO: task >> > > hung in zswap_decompress. Details are as follows. >> > > >> > > Kernel commit: v7.0.6 >> > > Kernel config: see attachment >> > > report: see attachment >> >> If I am reading the report correctly, it seems like we are doing >> swapin from the page fault path, and waiting for the per-CPU mutex >> that is held by kswapd. Since we can sleep waiting for decompression >> while holding the mutex, it's possible that we have some kind of >> priority inversion where kswap held the lock, went to sleep, and >> didn't run again for a while. But that always been possible for a long >> time AFAICT. Cool! Worth rerunning with CONFIG_DETECT_HUNG_TASK_BLOCKER=y, Should be on by default with CONFIG_DETECT_HUNG_TASK=y, but I don't see it in the config. With that enabled, the kernel should hopefully tell us which task likely owns the mutex :) If kswapd is sitting on the per-CPU zswap mutex and not getting scheduled back in, that should be pretty clear ;) CONFIG_DETECT_HUNG_TASK=y CONFIG_DETECT_HUNG_TASK_BLOCKER=y # detect after 10s in D state instead of the default 120s echo 10 > /proc/sys/kernel/hung_task_timeout_secs # 0 means use hung_task_timeout_secs as the check interval echo 0 > /proc/sys/kernel/hung_task_check_interval_secs >> >> Do you have any more details? Is this a new regression (observed when >> upgrading to v7.0.6), or is it possible this was a pre-existing issue >> and you just found it on this kernel? >> >> > > >> > > We are currently analyzing the root cause and working on a >> > > reproducible PoC. We will provide further updates in this thread as >> > > soon as we have more information. >> >> Yeah more details like a known-good kernel version, or even better a >> reproducer, would certainly help a lot. >> >> > > >> > > Best regards, >> > > Longxing Li >> > > >> > > ================================================================== >> > > https://drive.google.com/file/d/1Bx2unEf-QntjVi8g6Zw7QNO6OP4cjGO_/view?usp=drive_link >> > > >> > > https://drive.google.com/file/d/16xzUrwOvwE67cnMPH3AhhNRWq6hr26Qj/view?usp=drive_link >> > >> > + Kanchana, who last worked on this piece of code > >Thanks Nhat and Yosry. I agree with Yosry, having a known-good kernel >version would be helpful. > >Also, it appears the kernel stack-trace is from before the merging of >the per-CPU acomp_ctx simplifications wrt the mutex, and resources' >lifetime being tied to that of the zswap pool. > >Looking forward to more details. +1 Cheers, Lance