From: Dave Chinner Date: Wed, 4 Feb 2015 00:29:05 +0000 (-0500) Subject: aio: annotate aio_read_event_ring for sleep patterns X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=9c9ce763b114e608b5cf3aa6cb69ad9f6e8b6adf;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git aio: annotate aio_read_event_ring for sleep patterns Under CONFIG_DEBUG_ATOMIC_SLEEP=y, aio_read_event_ring() will throw warnings like the following due to being called from wait_event context: WARNING: CPU: 0 PID: 16006 at kernel/sched/core.c:7300 __might_sleep+0x7f/0x90() do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait_event+0x63/0x110 Modules linked in: CPU: 0 PID: 16006 Comm: aio-dio-fcntl-r Not tainted 3.19.0-rc6-dgc+ #705 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 ffffffff821c0372 ffff88003c117cd8 ffffffff81daf2bd 000000000000d8d8 ffff88003c117d28 ffff88003c117d18 ffffffff8109beda ffff88003c117cf8 ffffffff821c115e 0000000000000061 0000000000000000 00007ffffe4aa300 Call Trace: [] dump_stack+0x4c/0x65 [] warn_slowpath_common+0x8a/0xc0 [] warn_slowpath_fmt+0x46/0x50 [] ? prepare_to_wait_event+0x63/0x110 [] ? prepare_to_wait_event+0x63/0x110 [] __might_sleep+0x7f/0x90 [] mutex_lock+0x24/0x45 [] aio_read_events+0x4c/0x290 [] read_events+0x1ec/0x220 [] ? prepare_to_wait_event+0x110/0x110 [] ? hrtimer_get_res+0x50/0x50 [] SyS_io_getevents+0x4d/0xb0 [] system_call_fastpath+0x12/0x17 ---[ end trace bde69eaf655a4fea ]--- There is not actually a bug here, so annotate the code to tell the debug logic that everything is just fine and not to fire a false positive. Signed-off-by: Dave Chinner Signed-off-by: Benjamin LaHaise --- diff --git a/fs/aio.c b/fs/aio.c index 1b7893ecc296..c428871f1093 100644 --- a/fs/aio.c +++ b/fs/aio.c @@ -1140,6 +1140,13 @@ static long aio_read_events_ring(struct kioctx *ctx, long ret = 0; int copy_ret; + /* + * The mutex can block and wake us up and that will cause + * wait_event_interruptible_hrtimeout() to schedule without sleeping + * and repeat. This should be rare enough that it doesn't cause + * peformance issues. See the comment in read_events() for more detail. + */ + sched_annotate_sleep(); mutex_lock(&ctx->ring_lock); /* Access to ->ring_pages here is protected by ctx->ring_lock. */