From: Jia-Ju Bai <baijiaju1990@gmail.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc
Date: Thu, 25 Jan 2018 11:13:56 +0800 [thread overview]
Message-ID: <70efc238-9517-7cfa-03ce-ba9c3ba0ebd4@gmail.com> (raw)
In-Reply-To: <20180125025811.GT13338@ZenIV.linux.org.uk>
On 2018/1/25 10:58, Al Viro wrote:
> On Thu, Jan 25, 2018 at 10:46:26AM +0800, Jia-Ju Bai wrote:
>> The function ioc_create_icq here is not called in atomic context.
>> Thus GFP_ATOMIC is not necessary, and it can be replaced with GFP_KERNEL.
>>
>> This is found by a static analysis tool named DCNS written by myself.
> Umm... Some human-readable analysis would be welcome. FWIW, I've tried to
> put a proof together, but...
> struct blk_mq_ops->timeout = nvme_timeout
> nvme_timeout()
> nvme_alloc_request()
> blk_mq_alloc_request_hctx()
> blk_mq_get_request()
> blk_mq_sched_assign_ioc()
> ... and while I have not traced the call chain further, the look of that
> function (nvme_timeout()) strongly suggests that it *is* meant to be
> called from bloody atomic context.
>
> "My tool has found that place/put together a proof" is nice, but it
> doesn't replace the proof itself...
Thanks for reply :)
I have checked the given call chain, and find that nvme_dev_disable in
nvme_timeout calls mutex_lock that can sleep.
Thus, I suppose this call chain is not in atomic context.
Besides, how do you find that "function (nvme_timeout()) strongly
suggests that it *is* meant to be called from bloody atomic context"?
I check the comments in nvme_timeout, and do not find related description...
By the way, do you mean that I should add "My tool has proved that this
function is never called in atomic context" in the description?
Thanks,
Jia-Ju Bai
next prev parent reply other threads:[~2018-01-25 3:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-25 2:46 [PATCH] block: blk-mq-sched: Replace GFP_ATOMIC with GFP_KERNEL in blk_mq_sched_assign_ioc Jia-Ju Bai
2018-01-25 2:58 ` Al Viro
2018-01-25 3:13 ` Jia-Ju Bai [this message]
2018-01-25 4:16 ` Al Viro
2018-01-25 7:52 ` Jia-Ju Bai
2018-01-25 3:34 ` Jens Axboe
2018-01-25 3:40 ` Jia-Ju Bai
2018-01-25 5:29 ` Ming Lei
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=70efc238-9517-7cfa-03ce-ba9c3ba0ebd4@gmail.com \
--to=baijiaju1990@gmail.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@ZenIV.linux.org.uk \
/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.