| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <87sf25yqj2.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Wed, 07 Feb 2024 10:08:49 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Barry Song <21cnbao@...il.com>
Cc: Chris Li <chrisl@...nel.org>, Kairui Song <kasong@...cent.com>,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>, Minchan
Kim <minchan@...nel.org>, Yu Zhao <yuzhao@...gle.com>, Barry Song
<v-songbaohua@...o.com>, SeongJae Park <sj@...nel.org>, Hugh Dickins
<hughd@...gle.com>, Johannes Weiner <hannes@...xchg.org>, Matthew Wilcox
<willy@...radead.org>, Michal Hocko <mhocko@...e.com>, Yosry Ahmed
<yosryahmed@...gle.com>, David Hildenbrand <david@...hat.com>,
stable@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] mm/swap: fix race when skipping swapcache
Barry Song <21cnbao@...il.com> writes:
> On Wed, Feb 7, 2024 at 7:18 AM Chris Li <chrisl@...nel.org> wrote:
>>
>> Hi Kairui,
>>
>> Sorry replying to your patch V1 late, I will reply on the V2 thread.
>>
>> On Tue, Feb 6, 2024 at 10:28 AM Kairui Song <ryncsn@...il.com> wrote:
>> >
>> > From: Kairui Song <kasong@...cent.com>
>> >
>> > When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
>> > swapin the same entry at the same time, they get different pages (A, B).
>> > Before one thread (T0) finishes the swapin and installs page (A)
>> > to the PTE, another thread (T1) could finish swapin of page (B),
>> > swap_free the entry, then swap out the possibly modified page
>> > reusing the same entry. It breaks the pte_same check in (T0) because
>> > PTE value is unchanged, causing ABA problem. Thread (T0) will
>> > install a stalled page (A) into the PTE and cause data corruption.
>> >
>> > One possible callstack is like this:
>> >
>> > CPU0 CPU1
>> > ---- ----
>> > do_swap_page() do_swap_page() with same entry
>> > <direct swapin path> <direct swapin path>
>> > <alloc page A> <alloc page B>
>> > swap_read_folio() <- read to page A swap_read_folio() <- read to page B
>> > <slow on later locks or interrupt> <finished swapin first>
>> > ... set_pte_at()
>> > swap_free() <- entry is free
>> > <write to page B, now page A stalled>
>> > <swap out page B to same swap entry>
>> > pte_same() <- Check pass, PTE seems
>> > unchanged, but page A
>> > is stalled!
>> > swap_free() <- page B content lost!
>> > set_pte_at() <- staled page A installed!
>> >
>> > And besides, for ZRAM, swap_free() allows the swap device to discard
>> > the entry content, so even if page (B) is not modified, if
>> > swap_read_folio() on CPU0 happens later than swap_free() on CPU1,
>> > it may also cause data loss.
>> >
>> > To fix this, reuse swapcache_prepare which will pin the swap entry using
>> > the cache flag, and allow only one thread to pin it. Release the pin
>> > after PT unlocked. Racers will simply busy wait since it's a rare
>> > and very short event.
>> >
>> > Other methods like increasing the swap count don't seem to be a good
>> > idea after some tests, that will cause racers to fall back to use the
>> > swap cache again. Parallel swapin using different methods leads to
>> > a much more complex scenario.
>> >
>> > Reproducer:
>> >
>> > This race issue can be triggered easily using a well constructed
>> > reproducer and patched brd (with a delay in read path) [1]:
>> >
>> > With latest 6.8 mainline, race caused data loss can be observed easily:
>> > $ gcc -g -lpthread test-thread-swap-race.c && ./a.out
>> > Polulating 32MB of memory region...
>> > Keep swapping out...
>> > Starting round 0...
>> > Spawning 65536 workers...
>> > 32746 workers spawned, wait for done...
>> > Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!
>> > Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!
>> > Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!
>> > Round 0 Failed, 15 data loss!
>> >
>> > This reproducer spawns multiple threads sharing the same memory region
>> > using a small swap device. Every two threads updates mapped pages one by
>> > one in opposite direction trying to create a race, with one dedicated
>> > thread keep swapping out the data out using madvise.
>> >
>> > The reproducer created a reproduce rate of about once every 5 minutes,
>> > so the race should be totally possible in production.
>> >
>> > After this patch, I ran the reproducer for over a few hundred rounds
>> > and no data loss observed.
>> >
>> > Performance overhead is minimal, microbenchmark swapin 10G from 32G
>> > zram:
>> >
>> > Before: 10934698 us
>> > After: 11157121 us
>> > Non-direct: 13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)
>> >
>> > Fixes: 0bcac06f27d7 ("mm, swap: skip swapcache for swapin of synchronous device")
>> > Reported-by: "Huang, Ying" <ying.huang@...el.com>
>> > Closes: https://lore.kernel.org/lkml/87bk92gqpx.fsf_-_@yhuang6-desk2.ccr.corp.intel.com/
>> > Link: https://github.com/ryncsn/emm-test-project/tree/master/swap-stress-race [1]
>> > Signed-off-by: Kairui Song <kasong@...cent.com>
>> > Reviewed-by: "Huang, Ying" <ying.huang@...el.com>
>> > Acked-by: Yu Zhao <yuzhao@...gle.com>
>> >
>> > ---
>> > Update from V1:
>> > - Add some words on ZRAM case, it will discard swap content on swap_free so the race window is a bit different but cure is the same. [Barry Song]
>> > - Update comments make it cleaner [Huang, Ying]
>> > - Add a function place holder to fix CONFIG_SWAP=n built [SeongJae Park]
>> > - Update the commit message and summary, refer to SWP_SYNCHRONOUS_IO instead of "direct swapin path" [Yu Zhao]
>> > - Update commit message.
>> > - Collect Review and Acks.
>> >
>> > include/linux/swap.h | 5 +++++
>> > mm/memory.c | 15 +++++++++++++++
>> > mm/swap.h | 5 +++++
>> > mm/swapfile.c | 13 +++++++++++++
>> > 4 files changed, 38 insertions(+)
>> >
>> > diff --git a/include/linux/swap.h b/include/linux/swap.h
>> > index 4db00ddad261..8d28f6091a32 100644
>> > --- a/include/linux/swap.h
>> > +++ b/include/linux/swap.h
>> > @@ -549,6 +549,11 @@ static inline int swap_duplicate(swp_entry_t swp)
>> > return 0;
>> > }
>> >
>> > +static inline int swapcache_prepare(swp_entry_t swp)
>> > +{
>> > + return 0;
>> > +}
>> > +
>> > static inline void swap_free(swp_entry_t swp)
>> > {
>> > }
>> > diff --git a/mm/memory.c b/mm/memory.c
>> > index 7e1f4849463a..1749c700823d 100644
>> > --- a/mm/memory.c
>> > +++ b/mm/memory.c
>> > @@ -3867,6 +3867,16 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>> > if (!folio) {
>> > if (data_race(si->flags & SWP_SYNCHRONOUS_IO) &&
>> > __swap_count(entry) == 1) {
>> > + /*
>> > + * Prevent parallel swapin from proceeding with
>> > + * the cache flag. Otherwise, another thread may
>> > + * finish swapin first, free the entry, and swapout
>> > + * reusing the same entry. It's undetectable as
>> > + * pte_same() returns true due to entry reuse.
>> > + */
>> > + if (swapcache_prepare(entry))
>> > + goto out;
>> > +
>>
>> I am puzzled by this "goto out". If I understand this correctly, you
>> have two threads CPU1 and CPU2 racing to set the flag SWAP_HAS_CACHE.
>> The CPU1 will succeed in adding the flag and the CPU2 will get
>> "-EEXIST" from "swapcache_prepare(entry)". Am I understanding it
>> correctly so far?
>>
>> Then the goto out seems wrong to me. For the CPU2, the page fault will
>> return *unhandled*. Even worse, the "-EEXIST" error is not preserved,
>> CPU2 does not even know the page fault is not handled, it will resume
>> from the page fault instruction, possibly generate another page fault
>> at the exact same location. That page fault loop will repeat until
>> CPU1 install the new pte on that faulting virtual address and pick up
>> by CPU2.
>>
>> Am I missing something obvious there?
>
> I feel you are right. any concurrent page faults at the same pte
> will increase the count of page faults for a couple of times now.
>
>>
>> I just re-read your comment: "Racers will simply busy wait since it's
>> a rare and very short event." That might be referring to the above
>> CPU2 page fault looping situation. I consider the page fault looping
>> on CPU2 not acceptable. For one it will mess up the page fault
>> statistics.
>> In my mind, having an explicit loop for CPU2 waiting for the PTE to
>> show up is still better than this page fault loop. You can have more
>> CPU power friendly loops.
>
> I assume you mean something like
>
> while(!pte_same())
> cpu_relax();
>
> then we still have a chance to miss the change of B.
>
> For example, another thread is changing pte to A->B->A, our loop can
> miss B. Thus we will trap into an infinite loop. this is even worse.
>
> is it possible to loop for the success of swapcache_prepare(entry)
> instead?
This doesn't work too. The swap count can increase to > 1 and be put in
swap cache for long time.
Another possibility is to move swapcache_prepare() after
vma_alloc_folio() to reduce the race window.
--
Best Regards,
Huang, Ying
>>
>> This behavior needs more discussion.
>>
>> Chris
>>
>>
>> Chris
>>
>>
>> > /* skip swapcache */
>> > folio = vma_alloc_folio(GFP_HIGHUSER_MOVABLE, 0,
>> > vma, vmf->address, false);
>> > @@ -4116,6 +4126,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>> > unlock:
>> > if (vmf->pte)
>> > pte_unmap_unlock(vmf->pte, vmf->ptl);
>> > + /* Clear the swap cache pin for direct swapin after PTL unlock */
>> > + if (folio && !swapcache)
>> > + swapcache_clear(si, entry);
>> > out:
>> > if (si)
>> > put_swap_device(si);
>> > @@ -4124,6 +4137,8 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
>> > if (vmf->pte)
>> > pte_unmap_unlock(vmf->pte, vmf->ptl);
>> > out_page:
>> > + if (!swapcache)
>> > + swapcache_clear(si, entry);
>> > folio_unlock(folio);
>> > out_release:
>> > folio_put(folio);
>> > diff --git a/mm/swap.h b/mm/swap.h
>> > index 758c46ca671e..fc2f6ade7f80 100644
>> > --- a/mm/swap.h
>> > +++ b/mm/swap.h
>> > @@ -41,6 +41,7 @@ void __delete_from_swap_cache(struct folio *folio,
>> > void delete_from_swap_cache(struct folio *folio);
>> > void clear_shadow_from_swap_cache(int type, unsigned long begin,
>> > unsigned long end);
>> > +void swapcache_clear(struct swap_info_struct *si, swp_entry_t entry);
>> > struct folio *swap_cache_get_folio(swp_entry_t entry,
>> > struct vm_area_struct *vma, unsigned long addr);
>> > struct folio *filemap_get_incore_folio(struct address_space *mapping,
>> > @@ -97,6 +98,10 @@ static inline int swap_writepage(struct page *p, struct writeback_control *wbc)
>> > return 0;
>> > }
>> >
>> > +static inline void swapcache_clear(struct swap_info_struct *si, swp_entry_t entry)
>> > +{
>> > +}
>> > +
>> > static inline struct folio *swap_cache_get_folio(swp_entry_t entry,
>> > struct vm_area_struct *vma, unsigned long addr)
>> > {
>> > diff --git a/mm/swapfile.c b/mm/swapfile.c
>> > index 556ff7347d5f..746aa9da5302 100644
>> > --- a/mm/swapfile.c
>> > +++ b/mm/swapfile.c
>> > @@ -3365,6 +3365,19 @@ int swapcache_prepare(swp_entry_t entry)
>> > return __swap_duplicate(entry, SWAP_HAS_CACHE);
>> > }
>> >
>> > +void swapcache_clear(struct swap_info_struct *si, swp_entry_t entry)
>> > +{
>> > + struct swap_cluster_info *ci;
>> > + unsigned long offset = swp_offset(entry);
>> > + unsigned char usage;
>> > +
>> > + ci = lock_cluster_or_swap_info(si, offset);
>> > + usage = __swap_entry_free_locked(si, offset, SWAP_HAS_CACHE);
>> > + unlock_cluster_or_swap_info(si, ci);
>> > + if (!usage)
>> > + free_swap_slot(entry);
>> > +}
>> > +
>> > struct swap_info_struct *swp_swap_info(swp_entry_t entry)
>> > {
>> > return swap_type_to_swap_info(swp_type(entry));
>> > --
>> > 2.43.0
>
> Thanks
> Barry
Powered by blists - more mailing lists