From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Mike Galbraith <efault@gmx.de>
Cc: Vitaly Wool <vitaly.wool@konsulko.com>,
Oleksandr Natalenko <oleksandr@natalenko.name>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Andrew Morton <akpm@linux-foundation.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-rt-users@vger.kernel.org
Subject: Re: scheduling while atomic in z3fold
Date: Thu, 3 Dec 2020 14:39:34 +0100 [thread overview]
Message-ID: <20201203133934.37aotbdjnd36lrxv@linutronix.de> (raw)
In-Reply-To: <64ab382309c41ca5c7a601fc3efbb6d2a6e68602.camel@gmx.de>
On 2020-12-03 09:18:21 [+0100], Mike Galbraith wrote:
> On Thu, 2020-12-03 at 03:16 +0100, Mike Galbraith wrote:
> > On Wed, 2020-12-02 at 23:08 +0100, Sebastian Andrzej Siewior wrote:
> > Looks like...
> >
> > d8f117abb380 z3fold: fix use-after-free when freeing handles
> >
> > ...wasn't completely effective...
>
> The top two hunks seem to have rendered the thing RT tolerant.
Yes, it appears to. I have no idea if this is a proper fix or not.
Without your write lock, after a few attempts, KASAN says:
| BUG: KASAN: use-after-free in __pv_queued_spin_lock_slowpath+0x293/0x770
| Write of size 2 at addr ffff88800e0e10aa by task kworker/u16:3/237
|
| CPU: 5 PID: 237 Comm: kworker/u16:3 Tainted: G W 5.10.0-rc6-rt13-rt+
| Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-1 04/01/2014
| Workqueue: zswap1 compact_page_work
| Call Trace:
| dump_stack+0x7d/0xa3
| print_address_description.constprop.0+0x19/0x120
| __kasan_report.cold+0x1d/0x35
| kasan_report+0x3a/0x50
| check_memory_region+0x145/0x1a0
| __pv_queued_spin_lock_slowpath+0x293/0x770
| _raw_spin_lock_irq+0xca/0xe0
| rt_read_unlock+0x2c/0x70
| __release_z3fold_page.constprop.0+0x45e/0x620
| do_compact_page+0x674/0xa50
| process_one_work+0x63a/0x1130
| worker_thread+0xd3/0xc80
| kthread+0x401/0x4e0
| ret_from_fork+0x22/0x30
|
| Allocated by task 225 (systemd-journal):
| kasan_save_stack+0x1b/0x40
| __kasan_kmalloc.constprop.0+0xc2/0xd0
| kmem_cache_alloc+0x103/0x2b0
| z3fold_alloc+0x597/0x1970
| zswap_frontswap_store+0x928/0x1bf0
| __frontswap_store+0x117/0x320
| swap_writepage+0x34/0x70
| pageout+0x268/0x7c0
| shrink_page_list+0x13e1/0x1e80
| shrink_inactive_list+0x303/0xde0
| shrink_lruvec+0x3dd/0x660
| shrink_node_memcgs+0x3a1/0x600
| shrink_node+0x3a7/0x1350
| shrink_zones+0x1f1/0x7f0
| do_try_to_free_pages+0x219/0xcc0
| try_to_free_pages+0x1c5/0x4b0
| __perform_reclaim+0x18f/0x2c0
| __alloc_pages_slowpath.constprop.0+0x7ea/0x1790
| __alloc_pages_nodemask+0x5f5/0x700
| page_cache_ra_unbounded+0x30f/0x690
| do_sync_mmap_readahead+0x3e3/0x640
| filemap_fault+0x981/0x1110
| __xfs_filemap_fault+0x12d/0x840
| __do_fault+0xf3/0x4b0
| do_fault+0x202/0x8c0
| __handle_mm_fault+0x338/0x500
| handle_mm_fault+0x1a8/0x670
| do_user_addr_fault+0x409/0x8b0
| exc_page_fault+0x60/0xc0
| asm_exc_page_fault+0x1e/0x30
|
| Freed by task 71 (oom_reaper):
| kasan_save_stack+0x1b/0x40
| kasan_set_track+0x1c/0x30
| kasan_set_free_info+0x1b/0x30
| __kasan_slab_free+0x110/0x150
| kmem_cache_free+0x7f/0x450
| z3fold_free+0x1f8/0xc90
| zswap_free_entry+0x168/0x230
| zswap_frontswap_invalidate_page+0x145/0x190
| __frontswap_invalidate_page+0xe8/0x1a0
| swap_range_free.constprop.0+0x266/0x300
| swapcache_free_entries+0x1dc/0x970
| free_swap_slot+0x19c/0x290
| __swap_entry_free+0x139/0x160
| free_swap_and_cache+0xda/0x230
| zap_pte_range+0x275/0x1590
| unmap_page_range+0x320/0x690
| __oom_reap_task_mm+0x207/0x330
| oom_reap_task_mm+0x78/0x7e0
| oom_reap_task+0x6d/0x1a0
| oom_reaper+0x103/0x290
| kthread+0x401/0x4e0
| ret_from_fork+0x22/0x30
|
| The buggy address belongs to the object at ffff88800e0e1080
| which belongs to the cache z3fold_handle of size 88
| The buggy address is located 42 bytes inside of
| 88-byte region [ffff88800e0e1080, ffff88800e0e10d8)
| The buggy address belongs to the page:
| page:000000002ba661bc refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xe0e1
| flags: 0xffff800000200(slab)
| raw: 000ffff800000200 dead000000000100 dead000000000122 ffff88800aa4eb40
| raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000
| page dumped because: kasan: bad access detected
|
| Memory state around the buggy address:
| ffff88800e0e0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| ffff88800e0e1000: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
| >ffff88800e0e1080: fa fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc
| ^
| ffff88800e0e1100: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
| ffff88800e0e1180: 00 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc
| ==================================================================
| Disabling lock debugging due to kernel taint
with the lock I haven't seen anything.
Sebastian
next prev parent reply other threads:[~2020-12-03 13:39 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-28 14:05 scheduling while atomic in z3fold Oleksandr Natalenko
2020-11-28 14:09 ` Oleksandr Natalenko
2020-11-28 14:27 ` Oleksandr Natalenko
2020-11-29 6:41 ` Mike Galbraith
[not found] ` <79ee43026efe5aaa560953ea8fe29a826ac4e855.camel@gmx.de>
2020-11-29 9:21 ` Mike Galbraith
2020-11-29 10:56 ` Mike Galbraith
2020-11-29 11:29 ` Oleksandr Natalenko
2020-11-29 11:41 ` Mike Galbraith
2020-11-30 13:20 ` Sebastian Andrzej Siewior
2020-11-30 13:53 ` Oleksandr Natalenko
2020-11-30 14:28 ` Sebastian Andrzej Siewior
2020-11-30 14:42 ` Mike Galbraith
2020-11-30 14:52 ` Sebastian Andrzej Siewior
2020-11-30 15:01 ` Mike Galbraith
2020-11-30 15:03 ` Mike Galbraith
2020-11-30 16:03 ` Sebastian Andrzej Siewior
2020-11-30 16:27 ` Mike Galbraith
2020-11-30 16:32 ` Sebastian Andrzej Siewior
2020-11-30 16:36 ` Mike Galbraith
2020-11-30 19:09 ` Mike Galbraith
2020-11-30 16:53 ` Mike Galbraith
2020-12-02 2:30 ` Mike Galbraith
[not found] ` <20201202220826.5chy56mbgvrwmg3d@linutronix.de>
2020-12-03 2:16 ` Mike Galbraith
2020-12-03 8:18 ` Mike Galbraith
2020-12-03 13:39 ` Sebastian Andrzej Siewior [this message]
2020-12-03 14:07 ` Vitaly Wool
2020-12-06 9:18 ` Mike Galbraith
2020-12-07 1:05 ` Vitaly Wool
2020-12-07 2:18 ` Mike Galbraith
2020-12-07 11:52 ` Vitaly Wool
2020-12-07 12:34 ` Mike Galbraith
2020-12-07 15:21 ` Vitaly Wool
2020-12-07 15:41 ` Sebastian Andrzej Siewior
2020-12-07 15:41 ` Mike Galbraith
2020-12-08 23:26 ` Vitaly Wool
2020-12-09 6:13 ` Mike Galbraith
2020-12-09 6:31 ` Mike Galbraith
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=20201203133934.37aotbdjnd36lrxv@linutronix.de \
--to=bigeasy@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-users@vger.kernel.org \
--cc=oleksandr@natalenko.name \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vitaly.wool@konsulko.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;
as well as URLs for NNTP newsgroup(s).