[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <90e0e6ca-da7c-44c4-b1be-3de19a887c5d@gmail.com>
Date: Sun, 3 Dec 2023 22:45:44 +0800
From: Dongyun Liu <dongyun.liu3@...il.com>
To: Sergey Senozhatsky <senozhatsky@...omium.org>
Cc: 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 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;
> }
> ...
Powered by blists - more mailing lists