linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
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: Mon, 2 Feb 2015 16:29:44 +1100	[thread overview]
Message-ID: <20150202052944.GF4251@dastard> (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:
> On Sun, Feb 1, 2015 at 4:16 PM, Benjamin LaHaise <bcrl@kvack.org> wrote:
> >>
> >> What's the bug you think could happen?
> >
> > The bug would be in code that gets run via mutex_lock(), kmap(), or (more
> > likely) in the random mm or filesystem code that could be invoked via
> > copy_to_user().
> 
> 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".

So what's the outcome here? I'm running v3.19-rc7 kernel and
xfstests::generic/036 is still tripping this warning from the aio
code:

[   23.920785] run fstests generic/036 at 2015-02-02 16:13:01
[   24.168001] xfs_io (4814) used greatest stack depth: 11640 bytes left
[   24.187061] ------------[ cut here ]------------
[   24.187071] WARNING: CPU: 1 PID: 4820 at kernel/sched/core.c:7300 __might_sleep+0x7f/0x90()
[   24.187076] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffff810d85a3>] prepare_to_wait_event+0x63/0x110
[   24.187078] Modules linked in:
[   24.187080] CPU: 1 PID: 4820 Comm: aio-dio-fcntl-r Not tainted 3.19.0-rc7-dgc+ #706
[   24.187081] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[   24.187084]  ffffffff821c0372 ffff8800b84d3cd8 ffffffff81daf2bd 0000000000008c8c
[   24.187085]  ffff8800b84d3d28 ffff8800b84d3d18 ffffffff8109beda ffff8800b84d3cf8
[   24.187087]  ffffffff821c115e 0000000000000061 0000000000000000 00007fff38e95180
[   24.187087] Call Trace:
[   24.187093]  [<ffffffff81daf2bd>] dump_stack+0x4c/0x65
[   24.187096]  [<ffffffff8109beda>] warn_slowpath_common+0x8a/0xc0
[   24.187099]  [<ffffffff8109bf56>] warn_slowpath_fmt+0x46/0x50
[   24.187101]  [<ffffffff810d85a3>] ? prepare_to_wait_event+0x63/0x110
[   24.187103]  [<ffffffff810d85a3>] ? prepare_to_wait_event+0x63/0x110
[   24.187104]  [<ffffffff810bdfcf>] __might_sleep+0x7f/0x90
[   24.187107]  [<ffffffff81db8344>] mutex_lock+0x24/0x45
[   24.187111]  [<ffffffff81216b7c>] aio_read_events+0x4c/0x290
[   24.187113]  [<ffffffff81216fac>] read_events+0x1ec/0x220
[   24.187115]  [<ffffffff810d8650>] ? prepare_to_wait_event+0x110/0x110
[   24.187119]  [<ffffffff810fdb10>] ? hrtimer_get_res+0x50/0x50
[   24.187121]  [<ffffffff8121899d>] SyS_io_getevents+0x4d/0xb0
[   24.187124]  [<ffffffff81130b16>] ? __audit_syscall_exit+0x236/0x2e0
[   24.187127]  [<ffffffff81dba5a9>] system_call_fastpath+0x12/0x17
[   24.187128] ---[ end trace 9f078e8e19f765dd ]---

This test does a aio write loop with a single outstanding
event. i.e:

	while (1) {
		io_prep_pwrite(&iocb, fd, buf, BUF_SIZE, BUF_SIZE);
		err = io_submit(ctx, 1, iocbs);
		if (err)
			.....
		err = io_getevents(ctx, 1, 1, &ev, NULL);
		.....
	}

The kernel should not be throwing warnings on basic regression
tests, so something needs to be fixed...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2015-02-02  5:29 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 [this message]
     [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
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=20150202052944.GF4251@dastard \
    --to=david@fromorbit.com \
    --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).