From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754346AbbBBBST (ORCPT ); Sun, 1 Feb 2015 20:18:19 -0500 Received: from mail-ie0-f176.google.com ([209.85.223.176]:56873 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750763AbbBBBSS (ORCPT ); Sun, 1 Feb 2015 20:18:18 -0500 MIME-Version: 1.0 In-Reply-To: <20150202001628.GO2974@kvack.org> References: <20150201144058.GM2974@kvack.org> <20150201221458.GN2974@kvack.org> <20150202001628.GO2974@kvack.org> Date: Sun, 1 Feb 2015 17:18:17 -0800 X-Google-Sender-Auth: 2h5CToXvaHTCQco-LIu3UwZtImc Message-ID: Subject: Re: [GIT PULL] aio: fix sleeping while TASK_INTERRUPTIBLE From: Linus Torvalds To: Benjamin LaHaise Cc: linux-aio@kvack.org, Linux Kernel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Feb 1, 2015 at 4:16 PM, Benjamin LaHaise 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". Linus