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]

Message-ID: <CA+55aFzAPms_orX7TY6zGCg=G-yXCrr5z7LMme7xcrXCAk6JAQ@mail.gmail.com>
Date:	Sun, 1 Feb 2015 15:33:25 -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 2:14 PM, Benjamin LaHaise <bcrl@...ck.org> wrote:
>
> It's ugly, but it actually is revealing a bug.  Spurious wake ups caused
> by the task already being added to ctx->wait when calling into mutex_lock()
> could inadvertently cause things to go wrong.  I can envision there being
> code invoked that possibly expects a 1-1 relationship between sleeps and
> wake ups, which being on the additional wait queue might break.

So I'm looking at it, and I don't see it.

One side uses wait_event_interruptible_hrtimeout(), which waits for
the return value (or the timeout), and it doesn't matter how many
times it gets woken up, regardless of what it's waiting for. If it
gets extra wakeups, it will just go through the loop again.

The other side is just a plain aio_read_events() ->
aio_read_events_ring(), and that one just reads as many events as it
can, unless some error happens.

In other words, it really looks like the warning is spurious, and the
comments about how the semaphore could cause it to loop around but it
all works look entirely correct.

So no, I don't see it revealing a bug at all. All I see is a spurious warning.

What's the bug you think could happen?

                         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/