linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH RESEND V2 0/5] Fixes and cleanups to xarray
Date: Tue, 12 Nov 2024 15:48:51 +0000	[thread overview]
Message-ID: <ZzN446h5pdMsYfRa@casper.infradead.org> (raw)
In-Reply-To: <8667a8e9-8052-4a32-817a-2c4ef97ddfbe@huaweicloud.com>

On Tue, Nov 12, 2024 at 03:05:51PM +0800, Kemeng Shi wrote:
> Patch 1 fixes the issue that xas_find_marked() will return a sibling entry
> to users when there is a race to replace old entry with small range with
> a new entry with bigger range. The kernel will crash if users use returned
> sibling entry as a valid entry.
> For example, find_get_entry() will crash if it gets a sibling entry from
> xas_find_marked() when trying to search a writeback folios.

You _think_ this can happen, or you've observed a crash where it _has_
happened?  I don't think it can happen due to the various locks we
have.  I'm not opposed to including this patch, but I don't think it
can happen today.

> Patch 3 fixes the issue that xas_pause() may skip some entry unepxectedly
> after xas_load()(may be called in xas_for_each for first entry) loads a
> large entry with index point at mid of the entry. So we may miss to writeback
> some dirty page and lost user data.

How do we lose user data?  The inode will still contain dirty pages.
We might skip some pages we should not have skipped, but they'll be
caught by a subsequent pass, no?


  reply	other threads:[~2024-11-12 15:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-11 21:53 Kemeng Shi
2024-11-11 21:28 ` Andrew Morton
2024-11-11 21:45   ` Matthew Wilcox
2024-11-12  7:05   ` Kemeng Shi
2024-11-12 15:48     ` Matthew Wilcox [this message]
2024-11-13  1:25       ` Kemeng Shi
2024-11-11 21:53 ` [PATCH RESEND V2 1/5] Xarray: Do not return sibling entries from xas_find_marked() Kemeng Shi
2024-11-11 21:53 ` [PATCH RESEND V2 2/5] Xarray: distinguish large entries correctly in xas_split_alloc() Kemeng Shi
2024-11-11 21:53 ` [PATCH RESEND V2 3/5] Xarray: move forward index correctly in xas_pause() Kemeng Shi
2024-11-11 21:53 ` [PATCH RESEND V2 4/5] Xarray: remove repeat check in xas_squash_marks() Kemeng Shi
2024-11-11 21:53 ` [PATCH RESEND V2 5/5] Xarray: use xa_mark_t in xas_squash_marks() to keep code consistent Kemeng Shi

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=ZzN446h5pdMsYfRa@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=shikemeng@huaweicloud.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