From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out30-130.freemail.mail.aliyun.com (out30-130.freemail.mail.aliyun.com [115.124.30.130]) (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 73025352949 for ; Thu, 22 Jan 2026 01:49:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769046575; cv=none; b=aDAPhddA6TI6asiKFQ8/NU3Y/R6bc3tZpqIJnGahhXUKOTmiMpyK84cq/1ifE/qXQJm9wArwWYJbRbu/BhOs5cDO8PStM30Yhu+JHNwlqddR+HPwc03fu1lVJJ7kiXmbBYeJ2PWlzQBHNlvZKoLCsqLtxxgp7FYalrQWbpkusRg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769046575; c=relaxed/simple; bh=lANgwnZBx7uJ6AaFObhUfdRMzyN4cP9tsw8bYmRA5Ho=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=IUo2wf6AzaOT+lak+MsfYagIQPRV1aogK1BBEjXP8Pqf+R0VNedJ+EBzPiEVGVwX3RswZtlbjJZPDIhMJuCKUsm492IT6IREwQsh1A0KTMJ/pOF8H6xFTO2k7Ln2J8gSRPcQ20kaUuay93I98Qg/tCn0VkRXjJlo6uUku1Gv4Kc= 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=D+lT7U+u; arc=none smtp.client-ip=115.124.30.130 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="D+lT7U+u" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1769046568; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=CSbaboWUbbkVLULY+de+RcFIwy5mlcueIjalB3v17S4=; b=D+lT7U+uu38NRLgPmTR4zxCSNixZuX99xVnUj31NVA0nUitLhPyqTPsPo63l8KfWc58DtThTM04snwoEKkMALzfMjwfJzo8cqc//jeuI8UCU/t6AXcRLoztrn4w57+sB09FrPqhLAr0tZufr34ZFip/LzzpJqS6+0Nx60Iiz5w0= Received: from 30.221.148.85(mailfrom:jefflexu@linux.alibaba.com fp:SMTPD_---0WxaUo2a_1769046567 cluster:ay36) by smtp.aliyun-inc.com; Thu, 22 Jan 2026 09:49:28 +0800 Message-ID: Date: Thu, 22 Jan 2026 09:49:26 +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> <90a1bb2f-3c21-4ab8-86e8-b94677c0976b@linux.alibaba.com> Content-Language: en-US From: Jingbo Xu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 1/22/26 5:59 AM, Joanne Koong wrote: > On Tue, Jan 20, 2026 at 7:21 PM Jingbo Xu wrote: >> >> 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. > > Could you elaborate on why this concerns you? Isn't this necessary > behavior given that it needs to fetch the parts that the store notify > didn't cover? Or is your concern that the contents are discarded? But > the server already has that information stored on their side, so I'm > not seeing why that's a problem. > I'm not thinking it as a problem. As said, I guess it is just a design constraint for FUSE_NOTIFY_STORE. Thanks. -- Thanks, Jingbo