From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout06.his.huawei.com (canpmsgout06.his.huawei.com [113.46.200.221]) (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 341208F4A for ; Tue, 6 Jan 2026 03:30:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.221 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767670250; cv=none; b=hs8WR7WA8lBu5F91dhw5Bjh2jxm/KYZxAEvmfLom6dyqjE9dGWoK5PEe81D1TNK5ST4TEbcbDJdPQHUm3wdHr62l5l2Mvzf2gHECGbi+l6XMx2OW2q/YsVx5PL7sVHF7pbNHSFNxE3jpAnZNI3oqISApKcLmmzQkMG5jHHtoPJY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767670250; c=relaxed/simple; bh=kHc1IHptie3TjnBkN6hoSEw24fpyXikQUZ1w8izRcCo=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=oD24uUHsz+GfH3YvNzsIfkoXFRHkZ3HeMcEn/8BLTcx8dQRFp06Zp6jqVyfVKbFx4QMEug3ceWDYce8gMdqN5tQ30uwcGm4ufbQ2nFi5CdP1Hz1m21ABIwMmtz40pbD4kXa2eqRjfDyylpEGrq//IQ9ClTSkbIXS9O07PSYHeqw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=Ve26SldA; arc=none smtp.client-ip=113.46.200.221 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="Ve26SldA" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=fH5tAFDXoyQRCxCzKZzMPwXjTcOhHzQLMuR5OLTiTYU=; b=Ve26SldAtsQg5RJxLicZ5Nsgeze4pQ8cFv4h1O9kXvMpaFUsg7/svzzgf/ZFNGIfOl+zsgtn9 d1IbyP3iXQFZ8fCdDKE1LkmVyqoduMnV/31zzwOyYC5wbG5VLW5aCd+8fb85vecm3gwCCviJJnF OFBYH0pLe5Ss4NMXRWAzMbI= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout06.his.huawei.com (SkyGuard) with ESMTPS id 4dlc6d1mQKzRhRZ; Tue, 6 Jan 2026 11:27:21 +0800 (CST) Received: from kwepemr500015.china.huawei.com (unknown [7.202.195.162]) by mail.maildlp.com (Postfix) with ESMTPS id 2DCF64056C; Tue, 6 Jan 2026 11:30:36 +0800 (CST) Received: from [10.67.111.104] (10.67.111.104) by kwepemr500015.china.huawei.com (7.202.195.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 6 Jan 2026 11:30:35 +0800 Message-ID: Date: Tue, 6 Jan 2026 11:30:34 +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 v1] erofs: Fix state inconsistency when updating fsid/domain_id Content-Language: en-US To: Baolin Liu , , CC: , , , , , , Baolin Liu References: <20260106025502.133470-1-liubaolin12138@163.com> From: Hongbo Li In-Reply-To: <20260106025502.133470-1-liubaolin12138@163.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: kwepems100002.china.huawei.com (7.221.188.206) To kwepemr500015.china.huawei.com (7.202.195.162) Hi, On 2026/1/6 10:55, Baolin Liu wrote: > From: Baolin Liu > > When updating fsid or domain_id, the code frees the old pointer before > allocating a new one. If allocation fails, the pointer becomes NULL > while the old value is already freed, causing state inconsistency. > > Fix by allocating the new value first, and only freeing the old value > on success. > > Signed-off-by: Baolin Liu > --- > fs/erofs/super.c | 18 ++++++++++++------ > 1 file changed, 12 insertions(+), 6 deletions(-) > > diff --git a/fs/erofs/super.c b/fs/erofs/super.c > index 937a215f626c..6e083d7e634c 100644 > --- a/fs/erofs/super.c > +++ b/fs/erofs/super.c > @@ -509,16 +509,22 @@ static int erofs_fc_parse_param(struct fs_context *fc, > break; > #ifdef CONFIG_EROFS_FS_ONDEMAND > case Opt_fsid: > - kfree(sbi->fsid); > - sbi->fsid = kstrdup(param->string, GFP_KERNEL); > - if (!sbi->fsid) > + char *new_fsid; > + > + new_fsid = kstrdup(param->string, GFP_KERNEL); May be there is no need to keep the old pointer. Because 1) The fsid/domain_id is ignored in reconfiguration. 2) Even if memory allocation fails when the user first mounts with multi fsid/domain_id options (like -o fsid=xxx1,fsid=xxx2), the old fsid pointer would also need to be released in cleanup procedure. so am I right? Thanks, Hongbo > + if (!new_fsid) > return -ENOMEM; > + kfree(sbi->fsid); > + sbi->fsid = new_fsid; > break; > case Opt_domain_id: > - kfree(sbi->domain_id); > - sbi->domain_id = kstrdup(param->string, GFP_KERNEL); > - if (!sbi->domain_id) > + char *new_domain_id; > + > + new_domain_id = kstrdup(param->string, GFP_KERNEL); > + if (!new_domain_id) > return -ENOMEM; > + kfree(sbi->domain_id); > + sbi->domain_id = new_domain_id; > break; > #else > case Opt_fsid: