linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Joanne Koong <joannelkoong@gmail.com>
Cc: miklos@szeredi.hu, akpm@linux-foundation.org,
	linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
	jefflexu@linux.alibaba.com, shakeel.butt@linux.dev,
	bernd.schubert@fastmail.fm, ziy@nvidia.com, jlayton@kernel.org,
	kernel-team@meta.com, Miklos Szeredi <mszeredi@redhat.com>
Subject: Re: [PATCH v7 1/3] mm: add AS_WRITEBACK_INDETERMINATE mapping flag
Date: Fri, 4 Apr 2025 22:13:55 +0200	[thread overview]
Message-ID: <221860f0-092c-47f1-a6f8-ebbe96429b1a@redhat.com> (raw)
In-Reply-To: <CAJnrk1Z2S9K1AsNnYHBOD_kGsOmYuJGyARimtc_4VUgUWDPigQ@mail.gmail.com>

On 04.04.25 22:09, Joanne Koong wrote:
> On Fri, Apr 4, 2025 at 12:13 PM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 04.04.25 20:14, Joanne Koong wrote:
>>> Add a new mapping flag AS_WRITEBACK_INDETERMINATE which filesystems may
>>> set to indicate that writing back to disk may take an indeterminate
>>> amount of time to complete. Extra caution should be taken when waiting
>>> on writeback for folios belonging to mappings where this flag is set.
>>>
>>> Signed-off-by: Joanne Koong <joannelkoong@gmail.com>
>>> Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
>>> Acked-by: Miklos Szeredi <mszeredi@redhat.com>
>>> ---
>>>    include/linux/pagemap.h | 11 +++++++++++
>>>    1 file changed, 11 insertions(+)
>>>
>>> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
>>> index 26baa78f1ca7..762575f1d195 100644
>>> --- a/include/linux/pagemap.h
>>> +++ b/include/linux/pagemap.h
>>> @@ -210,6 +210,7 @@ enum mapping_flags {
>>>        AS_STABLE_WRITES = 7,   /* must wait for writeback before modifying
>>>                                   folio contents */
>>>        AS_INACCESSIBLE = 8,    /* Do not attempt direct R/W access to the mapping */
>>> +     AS_WRITEBACK_INDETERMINATE = 9, /* Use caution when waiting on writeback */
>>>        /* Bits 16-25 are used for FOLIO_ORDER */
>>>        AS_FOLIO_ORDER_BITS = 5,
>>>        AS_FOLIO_ORDER_MIN = 16,
>>> @@ -335,6 +336,16 @@ static inline bool mapping_inaccessible(struct address_space *mapping)
>>>        return test_bit(AS_INACCESSIBLE, &mapping->flags);
>>>    }
>>>
>>> +static inline void mapping_set_writeback_indeterminate(struct address_space *mapping)
>>> +{
>>> +     set_bit(AS_WRITEBACK_INDETERMINATE, &mapping->flags);
>>> +}
>>> +
>>> +static inline bool mapping_writeback_indeterminate(struct address_space *mapping)
>>> +{
>>> +     return test_bit(AS_WRITEBACK_INDETERMINATE, &mapping->flags);
>>> +}
>>> +
>>>    static inline gfp_t mapping_gfp_mask(struct address_space * mapping)
>>>    {
>>>        return mapping->gfp_mask;
>>
>> Staring at this again reminds me of my comment in [1]
>>
>> "
>> b) Call it sth. like AS_WRITEBACK_MIGHT_DEADLOCK_ON_RECLAIM to express
>>        that very deadlock problem.
>> "
>>
>> In the context here now, where we really only focus on the reclaim
>> deadlock that can happen for trusted FUSE servers during reclaim, would
>> it make sense to call it now something like that?
> 
> Happy to make this change. My thinking was that
> 'AS_WRITEBACK_INDETERMINATE' could be reused in the future for stuff
> besides reclaim, but we can cross that bridge if that ends up being
> the case. 

Yes, but I'm afraid one we start using it in other context we're 
reaching the point where we are trying to deal with untrusted user space 
and the page lock would already be a similar problem.

Happy to be wrong on this one.

Wait for other opinions first. Apart from that, no objection from my side.

-- 
Cheers,

David / dhildenb


  reply	other threads:[~2025-04-04 20:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04 18:14 [PATCH v7 0/3] fuse: remove temp page copies in writeback Joanne Koong
2025-04-04 18:14 ` [PATCH v7 1/3] mm: add AS_WRITEBACK_INDETERMINATE mapping flag Joanne Koong
2025-04-04 19:13   ` David Hildenbrand
2025-04-04 20:09     ` Joanne Koong
2025-04-04 20:13       ` David Hildenbrand [this message]
2025-04-09 22:05         ` Shakeel Butt
2025-04-09 23:48           ` Joanne Koong
2025-04-04 18:14 ` [PATCH v7 2/3] mm: skip reclaiming folios in legacy memcg writeback indeterminate contexts Joanne Koong
2025-04-04 18:14 ` [PATCH v7 3/3] fuse: remove tmp folio for writebacks and internal rb tree Joanne Koong
2025-04-09  2:43   ` Jingbo Xu
2025-04-09 23:47     ` Joanne Koong
2025-04-10  2:12       ` Jingbo Xu
2025-04-10 15:07         ` Joanne Koong
2025-04-10 15:11           ` Jingbo Xu
2025-04-10 16:11             ` Joanne Koong
2025-04-14 20:24               ` Joanne Koong
2025-04-15  7:49               ` Jingbo Xu
2025-04-15 15:59                 ` Joanne Koong
2025-04-16  1:40                   ` Jingbo Xu
2025-04-16 16:43                     ` Joanne Koong
2025-04-16 18:05                       ` Bernd Schubert
2025-04-14 16:21 ` [PATCH v7 0/3] fuse: remove temp page copies in writeback Jeff Layton
2025-04-14 20:28   ` Joanne Koong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=221860f0-092c-47f1-a6f8-ebbe96429b1a@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bernd.schubert@fastmail.fm \
    --cc=jefflexu@linux.alibaba.com \
    --cc=jlayton@kernel.org \
    --cc=joannelkoong@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@redhat.com \
    --cc=shakeel.butt@linux.dev \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).