On Sun, Feb 1, 2015 at 4:16 PM, Benjamin LaHaise <b...@kvack.org> wrote:
>>
>> What's the bug you think could happen?
>
> The bug would be in code that gets run via mutex_lock(), kmap(), or (more
> likely) in the random mm or filesystem code that could be invoked via
> copy_to_user().
Ahh. That would be a bug, yes, but it wouldn't be one in the aio code.
If somebody just does a "schedule()" and thinks that their own private
events are the only thing that can wake it up, and doesn't use one of
the millions of "wait_event_xyz()" variations to actually wait for the
real completion, that is just buggy. Always. Always has been.
So I wouldn't worry too much about it. It has never been correct to do
that, and it's not one of the standard patterns for sleeping anyway.
Which is not to say that it might not exist in some dank corner of the
kernel, of course, but you shouldn't write code trying to make buggy
code like that happy. If we ever find code like that, let's just fix
it where the bug exists, not try to write odd code in places where it
isn't.
And I'd actually be a bit surprised to see that kind of really broken
code. You really almost have to work at it. All our normal "sleep
until X" patterns are much more obvious, and it's just _simpler_ to do
the right thing with "wait_event()" than to mis-code an explicit "set
task state and then just schedule without actually checking the thing
you are waiting for".
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
