From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) (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 F0AE82D23A6 for ; Wed, 3 Dec 2025 23:38:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764805138; cv=none; b=eFtQYG/06Mvcw+N0tIrdwNXrfsXi1FuOkPg+6cIWVpO8Wy/E9Mq5Cf5ZMa50E1UWDidoKb4b8BrV0sg33z9hIDI/Mi6eZt8PUWNegj/tyViOQ+YKT1mm0KusXAO48P7yf6Iv3WgnNNvldmNladEKUm66Fk7H2KUsckVUF742GN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764805138; c=relaxed/simple; bh=iVPK+7PrZQ5PLusYvhDq2y7XA/AgZs/DPjgfuoYyoSQ=; h=Message-ID:Date:MIME-Version:Subject:From:To:References: In-Reply-To:Content-Type; b=TOo6nZGZNC5L4rwP4+z0FdPabHkjEfn3NZc+xeQviwKRnKF1o2RVroBzoVWEzckX3plfMXQdtYWgto9FnHHqNEIayD76l4yne7JD70avHdl+krsTIOeRnnf7lCJao1NnTHoofufh55DiULkxXEn2L59fUSvize6B9SwNu/Gv0nQ= 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=YKRnOhv2; arc=none smtp.client-ip=91.218.175.177 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="YKRnOhv2" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1764805134; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=uOcOVhZpGAazVqRgpz2TINbzQHgOJW3FPeUkJfHNVmc=; b=YKRnOhv2PFuM1nXkDLn3kgMM38mCunkrfUgYbMbVLdWQZR9KrfuPCe2FPCD9y06IcfTLx9 TWxh3qKnz2+dMWT6SKJs+TvvSY2lN29Etofk/HaxrXV0rTMgMxbx5702wanVN/NvnhetZ/ odGCe0Q3gPVis6j68QjU5Ov1bB3Oz3M= Date: Thu, 4 Dec 2025 07:38:51 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 2/2] dm pcache: fix segment info indexing X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Dongsheng Yang To: Li Chen , dm-devel@lists.linux.dev, linux-kernel@vger.kernel.org, Zheng Gu References: <20251202121158.111092-1-me@linux.beauty> <20251202121158.111092-3-me@linux.beauty> <8794c32c-790c-4503-a657-3e66bc541cda@linux.dev> In-Reply-To: <8794c32c-790c-4503-a657-3e66bc541cda@linux.dev> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 在 12/3/2025 1:57 PM, Dongsheng Yang 写道: > > 在 12/2/2025 8:11 PM, Li Chen 写道: >> From: Li Chen >> >> Segment info indexing also used sizeof(struct) instead of the >> 4K metadata stride, so info_index could point between slots and >> subsequent writes would advance incorrectly. Derive info_index >> from the pointer returned by the segment meta search using >> PCACHE_SEG_INFO_SIZE and advance to the next slot for future >> updates. >> >> Signed-off-by: Li Chen >> --- >>   drivers/md/dm-pcache/cache_segment.c | 6 +++++- >>   1 file changed, 5 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/md/dm-pcache/cache_segment.c >> b/drivers/md/dm-pcache/cache_segment.c >> index f0b58980806e..0b4bb08011ce 100644 >> --- a/drivers/md/dm-pcache/cache_segment.c >> +++ b/drivers/md/dm-pcache/cache_segment.c >> @@ -56,7 +56,11 @@ static int cache_seg_info_load(struct >> pcache_cache_segment *cache_seg) >>           ret = -EIO; >>           goto out; >>       } >> -    cache_seg->info_index = cache_seg_info_addr - >> cache_seg_info_addr_base; >> + >> +    cache_seg->info_index = >> +        ((char *)cache_seg_info_addr - (char >> *)cache_seg_info_addr_base) / >> +        PCACHE_SEG_INFO_SIZE; >> +    cache_seg->info_index = (cache_seg->info_index + 1) % >> PCACHE_META_INDEX_MAX; > > > Don't advance info_index at init stage. ignore this incorrect comment, info_index means next slot, we need to advance it here. > >>   out: >>       mutex_unlock(&cache_seg->info_lock); >