Re: blk-mq: should elv_iosched_store return ENXIO/EINVAL?

[Jens Axboe <axboe@kernel.dk>]

On 12/30/2014 04:37 PM, Sebastian Herbszt wrote:
> Hello,
>
> setting an invalid elevator without blk-mq results in an error:
>
> # cat /sys/block/sda/queue/scheduler
> noop deadline [cfq]
> # echo foo > /sys/block/sda/queue/scheduler
> -bash: echo: write error: Invalid argument
> # dmesg
> [  328.767088] elevator: type foo not found
> [  328.767097] elevator: switch to foo
>   failed
>
> With blk-mq no error is returned:
>
> # cat /sys/block/sda/queue/scheduler
> none
> # echo foo > /sys/block/sda/queue/scheduler
> # echo $?
> 0
>
>
> block/elevator.c got
>
>   988 ssize_t elv_iosched_store(struct request_queue *q, const char *name,
>   989                           size_t count)
>   990 {
>   991         int ret;
>   992
>   993         if (!q->elevator)
>   994                 return count;
>   995
>   996         ret = __elevator_change(q, name);
>
> and
>
>   952 static int __elevator_change(struct request_queue *q, const char *name)
>   953 {
>   954         char elevator_name[ELV_NAME_MAX];
>   955         struct elevator_type *e;
>   956
>   957         if (!q->elevator)
>   958                 return -ENXIO;
>   959
>   960         strlcpy(elevator_name, name, sizeof(elevator_name));
>   961         e = elevator_get(strstrip(elevator_name), true);
>   962         if (!e) {
>   963                 printk(KERN_ERR "elevator: type %s not found\n", elevator_name);
>   964                 return -EINVAL;
>   965         }
>
>
> So !q->elevator is checked in elv_iosched_store and __elevator_change.
>
> Should elv_iosched_store return ENXIO or EINVAL or should __elevator_change
> handle this?

I agree the behavior is strange, but it actually matches what would 
happen for a make_request_fn based driver in this or earlier kernels. So 
there is a worry of changing the API if we modify it in general. The 
safe change would be to have these two lines before the q->elevator check:

if (q->mq_ops)
     return -EINVAL;

since that's new enough not to be a "real" API change. If we do that, we 
could let it slide into the general !q->elevator case after a few revisions.

Or we can just leave it as-is. If you read back the value after writing 
to it, it will always return "none".

-- 
Jens Axboe