linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Joanne Koong <joannelkoong@gmail.com>
To: "David Hildenbrand (Red Hat)" <david@kernel.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	shakeel.butt@linux.dev,  athul.krishna.kr@protonmail.com,
	miklos@szeredi.hu, stable@vger.kernel.org
Subject: Re: [PATCH v1 2/2] fs/writeback: skip inodes with potential writeback hang in wait_sb_inodes()
Date: Wed, 26 Nov 2025 09:58:40 -0800	[thread overview]
Message-ID: <CAJnrk1a1XsA9u1W-b4GLcyFXvZP41z7kWbJsdnEh7khcoco==A@mail.gmail.com> (raw)
In-Reply-To: <504d100d-b8f3-475b-b575-3adfd17627b5@kernel.org>

On Wed, Nov 26, 2025 at 2:55 AM David Hildenbrand (Red Hat)
<david@kernel.org> wrote:
> >
> >> having a flag that states something like that that
> >> "AS_NO_WRITEBACK_WAIT_ON_DATA_SYNC" would probable be what we would want
> >> to add to avoid waiting for writeback with clear semantics why it is ok
> >> in that specific scenario.
> >
> > Having a separate AS_NO_WRITEBACK_WAIT_ON_DATA_SYNC mapping flag
> > sounds reasonable to me and I agree is more clearer semantically.
>
> Good. Then it's clear that we are not waiting because writeback is
> shaky, but because even if it would be working, because we don't have to
> because there are no such guarantees.
>
> Maybe
>
> AS_NO_DATA_INTEGRITY
>
> or similar would be cleaner, I'll have to leave that to you and Miklos
> to decide what exactly the semantics are that fuse currently doesn't
> provide.

After reading Miklos's reply, I must have misunderstood this then - my
understanding was that the reason we couldn't guarantee data integrity
in fuse was because of the temp pages design where checking the
writeback flag on the real folio doesn't reflect writeback state, but
that removing the temp pages and using the real folio now does
guarantee this. But it seems like it's not as simple as that and
there's no data integrity guarantees for other reasons.

Changing this to AS_NO_DATA_INTEGRITY sounds good to me, if that
sounds good to Miklos as well. Or do you have another preference,
Miklos?

Thanks,
Joanne
>
>
> --
> Cheers
>
> David


  reply	other threads:[~2025-11-26 17:58 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20 18:42 [PATCH v1 0/2] mm: skip wait in wait_sb_inodes() for hangable-writeback mappings Joanne Koong
2025-11-20 18:42 ` [PATCH v1 1/2] mm: rename AS_WRITEBACK_MAY_DEADLOCK_ON_RECLAIM to AS_WRITEBACK_MAY_HANG Joanne Koong
2025-11-20 20:08   ` David Hildenbrand (Red Hat)
2025-11-20 21:28     ` Joanne Koong
2025-11-20 18:42 ` [PATCH v1 2/2] fs/writeback: skip inodes with potential writeback hang in wait_sb_inodes() Joanne Koong
2025-11-20 20:23   ` David Hildenbrand (Red Hat)
2025-11-20 21:20     ` Joanne Koong
2025-11-24 13:58       ` David Hildenbrand (Red Hat)
2025-11-25  1:10         ` Joanne Koong
2025-11-26 10:19           ` Miklos Szeredi
2025-11-26 10:41             ` David Hildenbrand (Red Hat)
2025-11-26 10:55           ` David Hildenbrand (Red Hat)
2025-11-26 17:58             ` Joanne Koong [this message]
2025-12-03  9:28               ` Miklos Szeredi
2025-12-04 18:06                 ` 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='CAJnrk1a1XsA9u1W-b4GLcyFXvZP41z7kWbJsdnEh7khcoco==A@mail.gmail.com' \
    --to=joannelkoong@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=athul.krishna.kr@protonmail.com \
    --cc=david@kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=miklos@szeredi.hu \
    --cc=shakeel.butt@linux.dev \
    --cc=stable@vger.kernel.org \
    /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