linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Yosry Ahmed <yosryahmed@google.com>
Cc: Barry Song <21cnbao@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Nhat Pham <nphamcs@gmail.com>,
	Chengming Zhou <chengming.zhou@linux.dev>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Chris Li <chrisl@kernel.org>, Ryan Roberts <ryan.roberts@arm.com>,
	Matthew Wilcox <willy@infradead.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: zswap: add VM_BUG_ON() if large folio swapin is attempted
Date: Fri, 7 Jun 2024 20:52:47 +0200	[thread overview]
Message-ID: <424c6430-e40d-4a60-8297-438fc33056c9@redhat.com> (raw)
In-Reply-To: <CAJD7tkZBzSB_6pAZP0n0nq+W=J1XKQGFzZZLzPmSH0apwaqTNg@mail.gmail.com>

>> I have no strong opinion on this one, but likely a VM_WARN_ON would also
>> be sufficient to find such issues early during testing. No need to crash
>> the machine.
> 
> I thought VM_BUG_ON() was less frowned-upon than BUG_ON(), but after
> some digging I found your patches to checkpatch and Linus clearly
> stating that it isn't.

:) yes.

VM_BUG_ON is not particularly helpful IMHO. If you want something to be 
found early during testing, VM_WARN_ON is good enough.

Ever since Fedora stopped enabling CONFIG_DEBUG_VM, VM_* friends are 
primarily reported during early/development testing only. But maybe some 
distro out there still sets it.

> 
> How about something like the following (untested), it is the minimal
> recovery we can do but should work for a lot of cases, and does
> nothing beyond a warning if we can swapin the large folio from disk:
> 
> diff --git a/mm/page_io.c b/mm/page_io.c
> index f1a9cfab6e748..8f441dd8e109f 100644
> --- a/mm/page_io.c
> +++ b/mm/page_io.c
> @@ -517,7 +517,6 @@ void swap_read_folio(struct folio *folio, struct
> swap_iocb **plug)
>          delayacct_swapin_start();
> 
>          if (zswap_load(folio)) {
> -               folio_mark_uptodate(folio);
>                  folio_unlock(folio);
>          } else if (data_race(sis->flags & SWP_FS_OPS)) {
>                  swap_read_folio_fs(folio, plug);
> diff --git a/mm/zswap.c b/mm/zswap.c
> index 6007252429bb2..cc04db6bb217e 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -1557,6 +1557,22 @@ bool zswap_load(struct folio *folio)
> 
>          VM_WARN_ON_ONCE(!folio_test_locked(folio));
> 
> +       /*
> +        * Large folios should not be swapped in while zswap is being used, as
> +        * they are not properly handled.
> +        *
> +        * If any of the subpages are in zswap, reading from disk would result
> +        * in data corruption, so return true without marking the folio uptodate
> +        * so that an IO error is emitted (e.g. do_swap_page() will sigfault).
> +        *
> +        * Otherwise, return false and read the folio from disk.
> +        */
> +       if (WARN_ON_ONCE(folio_test_large(folio))) {
> +               if (xa_find(tree, &offset, offset +
> folio_nr_pages(folio) - 1, 0))
> +                       return true;
> +               return false;
> +       }
> +
>          /*
>           * When reading into the swapcache, invalidate our entry. The
>           * swapcache can be the authoritative owner of the page and
> @@ -1593,7 +1609,7 @@ bool zswap_load(struct folio *folio)
>                  zswap_entry_free(entry);
>                  folio_mark_dirty(folio);
>          }
> -
> +       folio_mark_uptodate(folio);
>          return true;
>   }
> 
> One problem is that even if zswap was never enabled, the warning will
> be emitted just if CONFIG_ZSWAP is on. Perhaps we need a variable or
> static key if zswap was "ever" enabled.

We should use WARN_ON_ONCE() only for things that cannot happen. So if 
there are cases where this could be triggered today, it would be 
problematic -- especially if it can be triggered from unprivileged user 
space. But if we're concerned of other code messing up our invariant in 
the future (e.g., enabling large folios without taking proper care about 
zswap etc), we're good to add it.

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2024-06-07 18:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-06 18:48 Yosry Ahmed
     [not found] ` <84d78362-e75c-40c8-b6c2-56d5d5292aa7@redhat.com>
2024-06-06 20:31   ` Yosry Ahmed
2024-06-06 20:54     ` Barry Song
2024-06-06 21:00       ` Yosry Ahmed
     [not found]     ` <7507d075-9f4d-4a9b-836c-1fbb2fbd2257@redhat.com>
2024-06-06 21:30       ` Barry Song
2024-06-06 21:37         ` Yosry Ahmed
2024-06-06 21:53           ` Barry Song
2024-06-07  7:11             ` David Hildenbrand
2024-06-07 17:43               ` Yosry Ahmed
2024-06-07 18:52                 ` David Hildenbrand [this message]
2024-06-07 18:58                   ` Yosry Ahmed
2024-06-07 19:03                     ` David Hildenbrand
2024-06-07 21:13                     ` Chris Li
2024-06-07 23:14                       ` Yosry Ahmed
2024-06-07 22:09                     ` Barry Song
2024-06-08  0:28                       ` Yosry Ahmed
2024-06-07 21:20                 ` Barry Song
2024-06-07 23:17                   ` Yosry Ahmed
2024-06-07 22:28                     ` Barry Song
2024-06-08  0:32                       ` Yosry Ahmed
2024-06-06 21:36       ` Yosry Ahmed

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=424c6430-e40d-4a60-8297-438fc33056c9@redhat.com \
    --to=david@redhat.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=chengming.zhou@linux.dev \
    --cc=chrisl@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nphamcs@gmail.com \
    --cc=ryan.roberts@arm.com \
    --cc=willy@infradead.org \
    --cc=yosryahmed@google.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