linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).