Re: [PATCH] zram: Using GFP_ATOMIC instead of GFP_KERNEL to allocate bitmap memory in backing_dev_store

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 2023/12/3 9:23, Sergey Senozhatsky wrote:
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:


We have modified the logic here to allow backing_dev_store() to be called multiple times. That's why the call trace comes in. On the other hand, I realized that I should show the upstream's call stack instead
of my custom feature next time. Thank you for your toleration.

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




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux