From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (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 B03CD36BCF2 for ; Tue, 31 Mar 2026 02:59:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.111 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774925951; cv=none; b=cs6xueKpV12P5OiTPiYcn2hMcs9OB/pTPMyCB+afmVzrmfVlGcAzZmzCWYvsDbk2uDooDmXtOnjBw+YqBBteJ6z3gXd0rh7JudJcFg0Z3mQiqquO6fWIe02VQBg/YKVI3on4dZ4MOnphjwvsjCs06DjuhVHikllL7MiAo25oufw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774925951; c=relaxed/simple; bh=+yoXPmvaNm2QWd/DbMfDy8HgpTiSpG8maXlqOVDQdWo=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=tl+miTI/o+lC9TE3/YBBIkEL+smIzkYGzuuOCclichbfJ/FIrUitndkU9kjk38SS4YNZxgVnJ6QUxjKS3FhFcTLucbDGqHnd2FVSRETmAHc+mgUcVpxszh3XticCvULEvruzKWu9MIuBKg8e/EvV8PK4ljyqLxY5lsy6/BdoR1s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=ytNcEi1E; arc=none smtp.client-ip=115.124.30.111 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="ytNcEi1E" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774925940; h=Message-ID:Date:MIME-Version:Subject:From:To:Content-Type; bh=qnEFCuxJf8bvijfk1/OEXlSQgWfpUL2dOo0rrZFQZRY=; b=ytNcEi1ERgWhwqBFPCuia8u/McgkFI2nsAyQ2hVIEKSInk0mi/NjF/a+/ITMN9MC0msZbBby0JKdmhS/zcflJuob3cb2QHPxrWYZGoUDYL1PJuG8qIld0vlUKpUze3SzKbTUy367zRzQNrhkfbeEYb7iaPzl9Y3BTeXZdDmtf/0= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R141e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0X02lc82_1774925938; Received: from 30.221.131.145(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X02lc82_1774925938 cluster:ay36) by smtp.aliyun-inc.com; Tue, 31 Mar 2026 10:58:59 +0800 Message-ID: Date: Tue, 31 Mar 2026 10:58:58 +0800 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] erofs: fix missing folio_unlock causing lock imbalance From: Gao Xiang To: Zhan Xusheng , Gao Xiang Cc: "open list:EROFS FILE SYSTEM" , linux-kernel@vger.kernel.org, Zhan Xusheng References: <20260331023306.18574-1-zhanxusheng@xiaomi.com> <669c3c5c-aece-42a6-907a-fdee99e9f1a8@linux.alibaba.com> In-Reply-To: <669c3c5c-aece-42a6-907a-fdee99e9f1a8@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2026/3/31 10:50, Gao Xiang wrote: > Hi Zhan, > > On 2026/3/31 10:33, Zhan Xusheng wrote: >> folio_trylock() in erofs_try_to_free_all_cached_folios() may >> successfully acquire the folio lock, but the subsequent check >> for erofs_folio_is_managed() can skip unlocking when the folio >> is not managed by EROFS. > > Do you find some real timing? > > I don't think it can really happen, because: > >> >> This leads to a lock imbalance and leaves the folio permanently >> locked, which may cause reclaim stalls or interfere with memory >> management. >> >> Fix this by ensuring folio_unlock() is called before continuing. > > If a folio links to a pcluster, folio->private will be non-NULL, > and pcl->compressed_bvecs[i] points to that folios. > > And z_erofs_cache_release_folio() will be called with folio lock, > and pcl->compressed_bvecs[i] will be set NULL here. > > So I don't think erofs_try_to_free_all_cached_folios() can find > !erofs_folio_is_managed(sbi, folio) in the real world. > >> >> Signed-off-by: Zhan Xusheng >> --- >>   fs/erofs/zdata.c | 4 +++- >>   1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/fs/erofs/zdata.c b/fs/erofs/zdata.c >> index fe8121df9ef2..9d7ff22f1622 100644 >> --- a/fs/erofs/zdata.c >> +++ b/fs/erofs/zdata.c >> @@ -605,8 +605,10 @@ static int erofs_try_to_free_all_cached_folios(struct erofs_sb_info *sbi, >>               if (!folio_trylock(folio)) >>                   return -EBUSY; >> -            if (!erofs_folio_is_managed(sbi, folio)) >> +            if (!erofs_folio_is_managed(sbi, folio)) { >> +                folio_unlock(folio); >>                   continue; >> +            } >>               pcl->compressed_bvecs[i].page = NULL; >>               folio_detach_private(folio); > > But I admit that we should rewrite in function as: > >             if (!erofs_folio_is_managed(sbi, folio)) { >                 DBG_BUGON(1); >             } else { >                 pcl->compressed_bvecs[i].page = NULL; >                 folio_detach_private(folio); >             } Or maybe just: DBG_BUGON(!erofs_folio_is_managed(sbi, folio)); pcl->compressed_bvecs[i].page = NULL; folio_detach_private(folio); folio_unlock(folio); Since if a pcluster goes here (!pcl->lockref.count), `pcl->compressed_bvecs[i]` should leave all valid cached folios (Or some should be recycled by .release_folio instead.) Unless there is the other bug somewhere, but in any case, I don't think your phenomenon is related to EROFS. Thanks, Gao Xiang >             folio_unlock(folio); > > Thanks, > Gao Xiang > > >>               folio_unlock(folio); >