From: Peter Zijlstra <peterz@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
linux-aio@kvack.org, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] aio: fix sleeping while TASK_INTERRUPTIBLE
Date: Tue, 3 Feb 2015 12:27:33 +0100 [thread overview]
Message-ID: <20150203112733.GM26304@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CA+55aFy2URGTL_XKQhEO_4dTc3KNJDm9Z0O_1Gqs4G3TvW7APg@mail.gmail.com>
On Sun, Feb 01, 2015 at 05:18:17PM -0800, Linus Torvalds wrote:
> 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".
block/bsg.c- prepare_to_wait(&bd->wq_done, &wait, TASK_UNINTERRUPTIBLE);
block/bsg.c- spin_unlock_irq(&bd->lock);
block/bsg.c: io_schedule();
block/bsg.c- finish_wait(&bd->wq_done, &wait);
Which is double buggy because:
1) it doesn't loop
2) it sets TASK_UNINTERRUPTIBLE _after_ testing for the sleep event.
drivers/iommu/amd_iommu_v2.c-static void put_device_state_wait(struct device_state *dev_state)
drivers/iommu/amd_iommu_v2.c-{
drivers/iommu/amd_iommu_v2.c- DEFINE_WAIT(wait);
drivers/iommu/amd_iommu_v2.c-
drivers/iommu/amd_iommu_v2.c- prepare_to_wait(&dev_state->wq, &wait, TASK_UNINTERRUPTIBLE);
drivers/iommu/amd_iommu_v2.c- if (!atomic_dec_and_test(&dev_state->count))
drivers/iommu/amd_iommu_v2.c: schedule();
drivers/iommu/amd_iommu_v2.c- finish_wait(&dev_state->wq, &wait);
drivers/iommu/amd_iommu_v2.c-
drivers/iommu/amd_iommu_v2.c- free_device_state(dev_state);
drivers/iommu/amd_iommu_v2.c-}
No loop...
drivers/md/dm-bufio.c-static void __wait_for_free_buffer(struct dm_bufio_client *c)
drivers/md/dm-bufio.c-{
drivers/md/dm-bufio.c- DECLARE_WAITQUEUE(wait, current);
drivers/md/dm-bufio.c-
drivers/md/dm-bufio.c- add_wait_queue(&c->free_buffer_wait, &wait);
drivers/md/dm-bufio.c- set_task_state(current, TASK_UNINTERRUPTIBLE);
drivers/md/dm-bufio.c- dm_bufio_unlock(c);
drivers/md/dm-bufio.c-
drivers/md/dm-bufio.c: io_schedule();
drivers/md/dm-bufio.c-
drivers/md/dm-bufio.c- remove_wait_queue(&c->free_buffer_wait, &wait);
drivers/md/dm-bufio.c-
drivers/md/dm-bufio.c- dm_bufio_lock(c);
drivers/md/dm-bufio.c-}
No loop..
And I'm sure there's a _waaay_ more. And the above examples are all in
relatively well maintained code afaik.
next prev parent reply other threads:[~2015-02-03 11:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-01 14:40 [GIT PULL] aio: fix sleeping while TASK_INTERRUPTIBLE Benjamin LaHaise
2015-02-01 21:01 ` Linus Torvalds
2015-02-01 22:14 ` Benjamin LaHaise
2015-02-01 23:09 ` Linus Torvalds
2015-02-01 23:33 ` Linus Torvalds
2015-02-02 0:16 ` Benjamin LaHaise
2015-02-02 1:18 ` Linus Torvalds
2015-02-02 5:29 ` Dave Chinner
[not found] ` <CA+55aFwvEcq-rAbqF2qTut=kJgFZZnhHptoPi6FSVrF4+1tBNA@mail.gmail.com>
2015-02-02 5:54 ` Dave Chinner
2015-02-02 18:45 ` Linus Torvalds
2015-02-03 22:23 ` Dave Chinner
2015-02-03 23:34 ` Benjamin LaHaise
2015-02-03 11:27 ` Peter Zijlstra [this message]
2015-02-03 11:33 ` Peter Zijlstra
2015-02-03 11:55 ` Peter Zijlstra
2015-02-03 23:24 ` Jens Axboe
2015-02-04 10:18 ` [PATCH] block: Simplify bsg complete all Peter Zijlstra
2015-02-04 17:06 ` Jens Axboe
2015-02-03 12:25 ` [PATCH] iommu/amd: Fix amd_iommu_free_device() Peter Zijlstra
2015-02-03 17:04 ` Jesse Barnes
2015-02-03 17:34 ` Joerg Roedel
2015-02-03 19:23 ` Linus Torvalds
2015-02-03 22:56 ` Joerg Roedel
2015-02-04 14:35 ` Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150203112733.GM26304@twins.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bcrl@kvack.org \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).