Re: [PATCH] lock_page() doesn't lock if __wait_on_bit_lock returns -EINTR
From: Linus Torvalds
Date: Sat Dec 12 2015 - 14:42:20 EST
On Sat, Dec 12, 2015 at 10:33 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Peter, did that patch also handle just plain "lock_page()" case?
Looking more at it, I think this all goes back to commit 743162013d40
("sched: Remove proliferation of wait_on_bit() action functions").
Before that, we had wait_on_page_bit() doing:
__wait_on_bit(page_waitqueue(page), &wait, sleep_on_page,
TASK_UNINTERRUPTIBLE);
and after that, the "sleep_on_page" got changed to "bit_wait_io".
But that is bogus, because sleep_on_page() used to look like this:
static int sleep_on_page(void *word)
{
io_schedule();
return 0;
}
while bit_wait_io() looks like this:
__sched int bit_wait_io(void *word)
{
if (signal_pending_state(current->state, current))
return 1;
io_schedule();
return 0;
}
which is ok, because as long as the task state is
TASK_UNINTERRUPTIBLE, the whole signal_pending_state() thing turns
into a no-op.
So far, so fine.
However, then commit 68985633bccb ("sched/wait: Fix signal handling in
bit wait helpers") _really_ screwed up, and changed the function to
__sched int bit_wait(struct wait_bit_key *word)
{
schedule();
if (signal_pending(current))
return -EINTR;
return 0;
}
so now it returns an error when no error should happen. Which in turn
makes __wait_on_bit() exit the bit-wait loop early.
It looks like PeterZ's pending patch should fix this, by passing in
the proper TASK_UNINTERRUPTIBLE to the bit_wait_io function, and going
back to signal_pending_state(). PeterZ, did I follow the history of
this correctly?
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/