All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dongyun Liu <dongyun.liu3@gmail.com>
To: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: minchan@kernel.org, axboe@kernel.dk,
	linux-kernel@vger.kernel.org, linux-block@vger.kernel.org,
	lincheng.yang@transsion.com, jiajun.ling@transsion.com,
	ldys2014@foxmail.com, Dongyun Liu <dongyun.liu@transsion.com>
Subject: Re: [PATCH] zram: Using GFP_ATOMIC instead of GFP_KERNEL to allocate bitmap memory in backing_dev_store
Date: Sun, 3 Dec 2023 22:45:44 +0800	[thread overview]
Message-ID: <90e0e6ca-da7c-44c4-b1be-3de19a887c5d@gmail.com> (raw)
In-Reply-To: <20231203012326.GE404241@google.com>



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;
> 	}
> ...

  reply	other threads:[~2023-12-03 14:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30 15:20 [PATCH] zram: Using GFP_ATOMIC instead of GFP_KERNEL to allocate bitmap memory in backing_dev_store Dongyun Liu
2023-11-30 15:37 ` Jens Axboe
2023-12-01  6:51   ` Dongyun Liu
2023-12-01 14:19     ` Jens Axboe
2023-12-01 15:28       ` Sergey Senozhatsky
2023-12-02 13:54       ` Dongyun Liu
2023-12-01 15:39 ` Sergey Senozhatsky
2023-12-02 15:50   ` Dongyun Liu
2023-12-03  1:23     ` Sergey Senozhatsky
2023-12-03 14:45       ` Dongyun Liu [this message]
2023-12-01 18:41 ` Minchan Kim
2023-12-06  8:08 kernel test robot

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=90e0e6ca-da7c-44c4-b1be-3de19a887c5d@gmail.com \
    --to=dongyun.liu3@gmail.com \
    --cc=axboe@kernel.dk \
    --cc=dongyun.liu@transsion.com \
    --cc=jiajun.ling@transsion.com \
    --cc=ldys2014@foxmail.com \
    --cc=lincheng.yang@transsion.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=senozhatsky@chromium.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.