lkml.org 
[lkml]   [2022]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: zram corruption due to uninitialized do_swap_page fault
On Fri, Mar 18, 2022 at 10:32:07AM -0700, Minchan Kim wrote:
> On Fri, Mar 18, 2022 at 09:30:09AM -0700, Ivan Babrou wrote:
> > On Wed, Mar 16, 2022 at 11:26 AM Ivan Babrou <ivan@cloudflare.com> wrote:
> > > I'm making an internal build and will push it to some location to see
> > > how it behaves, but it might take a few days to get any sort of
> > > confidence in the results (unless it breaks immediately).
> > >
> > > I've also pushed my patch that disables SWP_SYNCHRONOUS_IO to a few
> > > locations yesterday to see how it fares.
> >
> > I have some updates before the weekend. There are two experimental groups:
> >
> > * My patch that removes the SWP_SYNCHRONOUS_IO flag. There are 704
> > machines in this group across 5 datacenters with cumulative uptime of
> > 916 days.
> > * Minchan's patch to remove swap_slot_free_notify. There are 376
> > machines in this group across 3 datacenters with cumulative uptime of
> > 240 days.
> >
> > Our machines take a couple of hours to start swapping anything after
> > boot, and I discounted these two hours from the cumulative uptime.
> >
> > Neither of these two groups experienced unexpected coredumps or
> > rocksdb corruptions.
> >
> > I think at this point it's reasonable to proceed with Minchan's patch
> > (including a backport).
>
> Let me cook the patch and then will post it.
>
> Thanks for the testing as well as reporting, Ivan!

From 1ede54d46f0b1958bfc624f17fe709637ef8f12a Mon Sep 17 00:00:00 2001
From: Minchan Kim <minchan@kernel.org>
Date: Tue, 15 Mar 2022 14:14:23 -0700
Subject: [PATCH] mm: fix unexpected zeroed page mapping with zram swap

Two processes under CLONE_VM cloning, user process can be
corrupted by seeing zeroed page unexpectedly.

CPU A CPU B

do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage valid data
swap_slot_free_notify
delete zram entry
swap_readpage zeroed(invalid) data
pte_lock
map the *zero data* to userspace
pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return and next refault will
read zeroed data

The swap_slot_free_notify is bogus for CLONE_VM case since it doesn't
increase the refcount of swap slot at copy_mm so it couldn't catch up
whether it's safe or not to discard data from backing device.
In the case, only the lock it could rely on to synchronize swap slot
freeing is page table lock. Thus, this patch gets rid of the
swap_slot_free_notify function. With this patch, CPU A will see
correct data.

CPU A CPU B

do_swap_page do_swap_page
SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path
swap_readpage original data
pte_lock
map the original data
swap_free
swap_range_free
bd_disk->fops->swap_slot_free_notify
swap_readpage read zeroed data
pte_unlock
pte_lock
if (!pte_same)
goto out_nomap;
pte_unlock
return
on next refault will see mapped data by CPU B

The concern of the patch would increase memory consumption since it
could keep wasted memory with compressed form in zram as well as
uncompressed form in address space. However, most of cases of zram
uses no readahead and do_swap_page is followed by swap_free so it will
free the compressed form from in zram quickly.

Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device")
Cc: <stable@vger.kernel.org> # 4.14+
Reported-by: Ivan Babrou <ivan@cloudflare.com>
Tested-by: Ivan Babrou <ivan@cloudflare.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
---
mm/page_io.c | 54 ----------------------------------------------------
1 file changed, 54 deletions(-)

diff --git a/mm/page_io.c b/mm/page_io.c
index b417f000b49e..89fbf3cae30f 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -51,54 +51,6 @@ void end_swap_bio_write(struct bio *bio)
bio_put(bio);
}

-static void swap_slot_free_notify(struct page *page)
-{
- struct swap_info_struct *sis;
- struct gendisk *disk;
- swp_entry_t entry;
-
- /*
- * There is no guarantee that the page is in swap cache - the software
- * suspend code (at least) uses end_swap_bio_read() against a non-
- * swapcache page. So we must check PG_swapcache before proceeding with
- * this optimization.
- */
- if (unlikely(!PageSwapCache(page)))
- return;
-
- sis = page_swap_info(page);
- if (data_race(!(sis->flags & SWP_BLKDEV)))
- return;
-
- /*
- * The swap subsystem performs lazy swap slot freeing,
- * expecting that the page will be swapped out again.
- * So we can avoid an unnecessary write if the page
- * isn't redirtied.
- * This is good for real swap storage because we can
- * reduce unnecessary I/O and enhance wear-leveling
- * if an SSD is used as the as swap device.
- * But if in-memory swap device (eg zram) is used,
- * this causes a duplicated copy between uncompressed
- * data in VM-owned memory and compressed data in
- * zram-owned memory. So let's free zram-owned memory
- * and make the VM-owned decompressed page *dirty*,
- * so the page should be swapped out somewhere again if
- * we again wish to reclaim it.
- */
- disk = sis->bdev->bd_disk;
- entry.val = page_private(page);
- if (disk->fops->swap_slot_free_notify && __swap_count(entry) == 1) {
- unsigned long offset;
-
- offset = swp_offset(entry);
-
- SetPageDirty(page);
- disk->fops->swap_slot_free_notify(sis->bdev,
- offset);
- }
-}
-
static void end_swap_bio_read(struct bio *bio)
{
struct page *page = bio_first_page_all(bio);
@@ -114,7 +66,6 @@ static void end_swap_bio_read(struct bio *bio)
}

SetPageUptodate(page);
- swap_slot_free_notify(page);
out:
unlock_page(page);
WRITE_ONCE(bio->bi_private, NULL);
@@ -394,11 +345,6 @@ int swap_readpage(struct page *page, bool synchronous)
if (sis->flags & SWP_SYNCHRONOUS_IO) {
ret = bdev_read_page(sis->bdev, swap_page_sector(page), page);
if (!ret) {
- if (trylock_page(page)) {
- swap_slot_free_notify(page);
- unlock_page(page);
- }
-
count_vm_event(PSWPIN);
goto out;
}
--
2.35.1.894.gb6a874cedc-goog

\
 
 \ /
  Last update: 2022-03-18 19:55    [W:0.594 / U:0.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site