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: <20231203012326.GE404241@google.com> 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; } ...
Powered by blists - more mailing lists