linux-kernel - Re: [GIT PULL] aio: fix sleeping while TASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 1 Feb 2015 17:18:17 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	linux-aio@...ck.org, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] aio: fix sleeping while TASK_INTERRUPTIBLE

On Sun, Feb 1, 2015 at 4:16 PM, Benjamin LaHaise <bcrl@...ck.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/