All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.