linux-kernel - Re: [PATCH] zram: Using GFP_ATOMIC instead of GFP_KERNEL to allocate bitmap memory in backing_dev

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 3 Dec 2023 10:23:26 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Dongyun Liu <dongyun.liu3@...il.com>
Cc:     Sergey Senozhatsky <senozhatsky@...omium.org>, minchan@...nel.org,
        axboe@...nel.dk, linux-kernel@...r.kernel.org,
        linux-block@...r.kernel.org, lincheng.yang@...nssion.com,
        jiajun.ling@...nssion.com, ldys2014@...mail.com,
        Dongyun Liu <dongyun.liu@...nssion.com>
Subject: Re: [PATCH] zram: Using GFP_ATOMIC instead of GFP_KERNEL to allocate
 bitmap memory in backing_dev_store

On (23/12/02 23:50), Dongyun Liu wrote:
> On 2023/12/1 23:39, Sergey Senozhatsky wrote:
> > On (23/11/30 23:20), Dongyun Liu wrote:
> > > INFO: task init:331 blocked for more than 120 seconds.  "echo 0 >
> > > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > > task:init   state:D stack:    0 pid:    1 ppid:     0 flags:0x04000000
> > > Call trace:
> > >    __switch_to+0x244/0x4e4
> > >    __schedule+0x5bc/0xc48
> > >    schedule+0x80/0x164
> > >    rwsem_down_read_slowpath+0x4fc/0xf9c
> > >    __down_read+0x140/0x188
> > >    down_read+0x14/0x24
> > >    try_wakeup_wbd_thread+0x78/0x1ec [zram]
> > >    __zram_bvec_write+0x720/0x878 [zram]
> > >    zram_bvec_rw+0xa8/0x234 [zram]
> > >    zram_submit_bio+0x16c/0x268 [zram]
> > >    submit_bio_noacct+0x128/0x3c8
> > >    submit_bio+0x1cc/0x3d0
> > >    __swap_writepage+0x5c4/0xd4c
> > >    swap_writepage+0x130/0x158
> > >    pageout+0x1f4/0x478
> > >    shrink_page_list+0x9b4/0x1eb8
> > >    shrink_inactive_list+0x2f4/0xaa8
> > >    shrink_lruvec+0x184/0x340
> > >    shrink_node_memcgs+0x84/0x3a0
> > >    shrink_node+0x2c4/0x6c4
> > >    shrink_zones+0x16c/0x29c
> > >    do_try_to_free_pages+0xe4/0x2b4
> > >    try_to_free_pages+0x388/0x7b4
> > >    __alloc_pages_direct_reclaim+0x88/0x278
> > >    __alloc_pages_slowpath+0x4ec/0xf6c
> > >    __alloc_pages_nodemask+0x1f4/0x3dc
> > >    kmalloc_order+0x54/0x338
> > >    kmalloc_order_trace+0x34/0x1bc
> > >    __kmalloc+0x5e8/0x9c0
> > >    kvmalloc_node+0xa8/0x264
> > >    backing_dev_store+0x1a4/0x818 [zram]
> > >    dev_attr_store+0x38/0x8c
> > >    sysfs_kf_write+0x64/0xc4
> > 
> > Hmm, I'm not really following this backtrace. Backing device
> > configuration is only possible on un-initialized zram device.
> > If it's uninitialized, then why is it being used for swapout
> > later in the call stack?
> 
> Uh, at this moment, zram has finished initializing and is
> working. The backing device is an optional zram-based feature.
> I think it can be created later.

backing_dev_store() can't be called on an initialized device,
that's what init_done() at the very beginning of backing_dev_store()
is supposed to ensure:

...
	down_write(&zram->init_lock);
	if (init_done(zram)) {
		pr_info("Can't setup backing device for initialized device\n");
		err = -EBUSY;
		goto out;
	}
...