From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) (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 B99D329CB24 for ; Wed, 21 Jan 2026 03:27:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768966025; cv=none; b=AdNOPDcc1qf0okj+RRi9/81qnCnr9wQ2IqNFjNvx6YxFCmtikWDwL1n2+pgc+joMIxSB7e9z7NXVnQy0Pz4Gfupb4HCgQJGDFe+Gtj4hAavxE7GMztRvJvHs9X6HOjINBfDIJnadl+dLXg+B6RKyfiy6dx1D1weX9hJXnZ9Bc7g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768966025; c=relaxed/simple; bh=wpnHVLUImBe3S5D1AvpRLTzEhGkMm4KcVuQ3rZwvy4c=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fIiP5Crst41jR7EkE/y8ajNTs976BlWWHX/Ti02iKsEFqWH3Blc9gnceFO0VJFMLmmCk278J+9r5H8m9z0D3WZ9ncoccffn1FozgJmo/4IuB1hFjrDidE2ZRovBvbdA4nzpb06Xaf4Rmsf6TBZ8KZlENYqw11NR/ey61RPqwwHU= 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=A25MxX0J; arc=none smtp.client-ip=115.124.30.131 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="A25MxX0J" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1768966013; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=i+e1O65mnnU7hycl4ztRy67aqKTlunuOzJYMMgsUUoM=; b=A25MxX0JiyYBxUPzSTZ7rLjJk8WCXhaPUAe7TpZVVUtQ6F4jcy6GuRWMVU3HQQ0rp9PUuoK93RthofgwXcTdd1nSzwM093Lq6ib4TxMk7rQfLaCR5TG6i5xoOTMvJiSnVKO9qOVrnnKHFYtoslG+n9anZUzdaXMLm4QVspC61Q8= Received: from 30.221.146.111(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0WxWTA5-_1768965692 cluster:ay36) by smtp.aliyun-inc.com; Wed, 21 Jan 2026 11:21:33 +0800 Message-ID: <90a1bb2f-3c21-4ab8-86e8-b94677c0976b@linux.alibaba.com> Date: Wed, 21 Jan 2026 11:21:32 +0800 Precedence: bulk X-Mailing-List: linux-fsdevel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/3] fuse: use DIV_ROUND_UP() for page count calculations To: Joanne Koong Cc: miklos@szeredi.hu, linux-fsdevel@vger.kernel.org References: <20260116235606.2205801-1-joannelkoong@gmail.com> <20260116235606.2205801-2-joannelkoong@gmail.com> <2295ba7e-b830-4177-bccb-250fca11b142@linux.alibaba.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi Joanne, Thanks for the replying ;) On 1/21/26 4:06 AM, Joanne Koong wrote: > On Tue, Jan 20, 2026 at 11:10 AM Joanne Koong wrote: >> >> On Sun, Jan 18, 2026 at 6:12 PM Jingbo Xu wrote: >>> >>> On 1/17/26 7:56 AM, Joanne Koong wrote: >>>> Use DIV_ROUND_UP() instead of manually computing round-up division >>>> calculations. >>>> >>>> Signed-off-by: Joanne Koong >>>> --- >>>> fs/fuse/dev.c | 6 +++--- >>>> fs/fuse/file.c | 2 +- >>>> 2 files changed, 4 insertions(+), 4 deletions(-) >>>> >>>> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c >>>> index 6d59cbc877c6..698289b5539e 100644 >>>> --- a/fs/fuse/dev.c >>>> +++ b/fs/fuse/dev.c >>>> @@ -1814,7 +1814,7 @@ static int fuse_notify_store(struct fuse_conn *fc, unsigned int size, >>>> >>>> folio_offset = ((index - folio->index) << PAGE_SHIFT) + offset; >>>> nr_bytes = min_t(unsigned, num, folio_size(folio) - folio_offset); >>>> - nr_pages = (offset + nr_bytes + PAGE_SIZE - 1) >> PAGE_SHIFT; >>>> + nr_pages = DIV_ROUND_UP(offset + nr_bytes, PAGE_SIZE); >>>> >>>> err = fuse_copy_folio(cs, &folio, folio_offset, nr_bytes, 0); >>>> if (!folio_test_uptodate(folio) && !err && offset == 0 && >>> >>> IMHO, could we drop page offset, instead just update the file offset and >>> re-calculate folio index and folio offset for each loop, i.e. something >>> like what [1] did? >>> >>> This could make the code simpler and cleaner. >> >> Hi Jingbo, >> >> I'll break this change out into a separate patch. I agree your >> proposed restructuring of the logic makes it simpler to parse. >> >> Thanks, >> Joanne >> >>> >>> BTW, it seems that if the grabbed folio is newly created on hand and the >>> range described by the store notify doesn't cover the folio completely, >>> the folio won't be set as Uptodate and thus the written data may be >>> missed? I'm not sure if this is in design. > > (sorry, forgot to respond to this part of your email) > > I think this is intentional. By "thus the written data may be missed", > I think you're talking about the writeback path? My understanding is > it's the dirty bit, not uptodate, Not exactly. What I'm concerned is the uptodate bit. In the case where "the grabbed folio is newly created on hand and the range described by the store notify doesn't cover the folio completely, the folio won't be set as Uptodate", the following read(2) or write(2) on the folio will discard the content already in the folio, instead it triggers .readpage() to fetch data from FUSE server again. It seems that it is a deliberate constraint for FUSE_NOTIFY_STORE. that determines whether the written > data gets written back. I think Darrick had the same question about > this. AFAICT, it's by design to not have writeback triggered for this > path since the server is the one providing the data so they already > know the state-of-truth for the folio contents and that should already > be reflected on their backend. > -- Thanks, Jingbo