Re: [PATCH v1 1/3] fuse: use DIV_ROUND_UP() for page count calculations

[Jingbo Xu <jefflexu@linux.alibaba.com>]

On 1/22/26 5:59 AM, Joanne Koong wrote:
> On Tue, Jan 20, 2026 at 7:21 PM Jingbo Xu <jefflexu@linux.alibaba.com> 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 <joannelkoong@gmail.com> wrote:
>>>>
>>>> On Sun, Jan 18, 2026 at 6:12 PM Jingbo Xu <jefflexu@linux.alibaba.com> 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 <joannelkoong@gmail.com>
>>>>>> ---
>>>>>>  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