On Sun, Feb 1, 2015 at 2:14 PM, Benjamin LaHaise <b...@kvack.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 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/
