From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-124.freemail.mail.aliyun.com (out30-124.freemail.mail.aliyun.com [115.124.30.124]) (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 57B8536AB47 for ; Tue, 31 Mar 2026 02:51:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774925467; cv=none; b=BDZ3Evh1uurKf6anVVc+YlYIzZ5OH+YnJ4REys4oFuiRiWQXG4gTaXvMADlxoh5sObFGspb76PlWzQ2owiBzDCXfXxicLkjyPaX/cDrG1luzO/eXZioLqzWOc40178pTDGF1vxTA8/0XFL5ocSEv9qczL+QZHy7wi8rT/6xxxBI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774925467; c=relaxed/simple; bh=0MA4/sup6L5jDB8OPQn64EOAnHwnZhkaEWRHY2s/zMc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=pcm/Qh5ffy8wVsqLP12YB1JAMVy75B430c5KeqzamgZsDnpdv034X3qmLFh4vHGS6OOe50R3u7BaJJMxAus/9ihUVg2hFIWEjNhYVNxmHHiT7lHkQe6WRkIuxarOZa0uTxH10OM2OyPF69oJpF8IGUaVYwea662p+kbTJ08biUQ= 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=j/GHOzkV; arc=none smtp.client-ip=115.124.30.124 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="j/GHOzkV" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1774925456; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=wbmlGbw2cPAdSgrDqYtCFkFQm2JRMrcuo7j3eYrArFs=; b=j/GHOzkV4q/W6QWIkY+HNavwGh1Fc4QLNu0eHS8QJwMkmw4eWGWzuTHoVt9oTY47EWocXxshophYxBWnQHEUsHD+d3XGsNRVKKuq7qehmCXNV9cziIjzQhLuFc8W4NRN5Y4DPcARYhNmHs1s/32TcfDMu2G1pIizYR2V+2ym8wY= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=hsiangkao@linux.alibaba.com;NM=1;PH=DS;RN=5;SR=0;TI=SMTPD_---0X02t.ka_1774925455; Received: from 30.221.131.145(mailfrom:hsiangkao@linux.alibaba.com fp:SMTPD_---0X02t.ka_1774925455 cluster:ay36) by smtp.aliyun-inc.com; Tue, 31 Mar 2026 10:50:55 +0800 Message-ID: <669c3c5c-aece-42a6-907a-fdee99e9f1a8@linux.alibaba.com> Date: Tue, 31 Mar 2026 10:50:54 +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 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> From: Gao Xiang In-Reply-To: <20260331023306.18574-1-zhanxusheng@xiaomi.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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); } folio_unlock(folio); Thanks, Gao Xiang > folio_unlock(folio);