Linux block layer
 help / color / mirror / Atom feed
From: David Jeffery <djeffery@redhat.com>
To: Ming Lei <tom.leiming@gmail.com>
Cc: linux-block <linux-block@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>
Subject: Re: [PATCH] block: Fix warning when I/O elevator is changed as request_queue is being removed
Date: Tue, 8 Aug 2017 14:13:14 -0400	[thread overview]
Message-ID: <dada2f16-1c86-e474-a71b-b6d51be9e77a@redhat.com> (raw)
In-Reply-To: <CACVXFVPqY-Sz65uUtWAWu2wSS=Z0nU0NQnTaGmfOdfxcMVnwzQ@mail.gmail.com>

On 08/07/2017 07:53 PM, Ming Lei wrote:
> On Tue, Aug 8, 2017 at 3:38 AM, David Jeffery <djeffery@redhat.com> wrote:

>>
>> Signed-off-by: David Jeffery <djeffery@redhat.com>
>> ---
>>  block/blk-sysfs.c |    2 ++
>>  block/elevator.c  |    4 ++++
>>  2 files changed, 6 insertions(+)
>>
>>
>> diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
>> index 27aceab..b8362c0 100644
>> --- a/block/blk-sysfs.c
>> +++ b/block/blk-sysfs.c
>> @@ -931,7 +931,9 @@ void blk_unregister_queue(struct gendisk *disk)
>>         if (WARN_ON(!q))
>>                 return;
>>
>> +       mutex_lock(&q->sysfs_lock);
>>         queue_flag_clear_unlocked(QUEUE_FLAG_REGISTERED, q);
>> +       mutex_unlock(&q->sysfs_lock);
> 
> Could you share why the lock of 'q->sysfs_lock' is needed here?

As the elevator change is initiated through a sysfs attr file in the
queue directory, the task doing the elevator change already acquires the
q->sysfs_lock before it can try and change the elevator.  Adding the
lock around clearing QUEUE_FLAG_REGISTERED ensures that the queue state
will be stable while the elevator is being changed.  It prevents a race
condition where the bit is checked but then cleared and queue removed
from sysfs before the elevator change completes.

> 
>>
>>         wbt_exit(q);
>>
>> diff --git a/block/elevator.c b/block/elevator.c
>> index 4bb2f0c..51da592 100644
>> --- a/block/elevator.c
>> +++ b/block/elevator.c
>> @@ -1055,6 +1055,10 @@ static int __elevator_change(struct request_queue *q, const char *name)
>>         char elevator_name[ELV_NAME_MAX];
>>         struct elevator_type *e;
>>
>> +       /* Make sure queue is not in the middle of being removed */
>> +       if (!test_bit(QUEUE_FLAG_REGISTERED, &q->queue_flags))
>> +               return -ENOENT;
>> +
> 
> I suggest to check 'e->registered' here, which should be more
> reasonable or straightforward.
> 

e->registered is not the state needing to be checked.  We need to know
the state of the associated request queue.

Before changing the elevator, we need to ensure the request queue is
still connected to sysfs.  i.e. We need to know that kobject_del has not
been called on the request queue.  When QUEUE_FLAG_REGISTERED is not set
it means the request queue either has had kobject_del called or will
have it called soon, so we should fail the elevator change attempt.

  reply	other threads:[~2017-08-08 18:13 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-07 19:38 [PATCH] block: Fix warning when I/O elevator is changed as request_queue is being removed David Jeffery
2017-08-07 23:53 ` Ming Lei
2017-08-08 18:13   ` David Jeffery [this message]
2017-08-09  1:44     ` Ming Lei
2017-08-23  3:34       ` Ming Lei
2017-08-28  1:36         ` Ming Lei
2017-08-28 16:54           ` Jens Axboe

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=dada2f16-1c86-e474-a71b-b6d51be9e77a@redhat.com \
    --to=djeffery@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tom.leiming@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox