Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754433AbbBAVBK (ORCPT ); Sun, 1 Feb 2015 16:01:10 -0500 Received: from mail-ie0-f173.google.com ([209.85.223.173]:54999 "EHLO mail-ie0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753493AbbBAVBH (ORCPT ); Sun, 1 Feb 2015 16:01:07 -0500 MIME-Version: 1.0 In-Reply-To: <20150201144058.GM2974@kvack.org> References: <20150201144058.GM2974@kvack.org> Date: Sun, 1 Feb 2015 13:01:06 -0800 X-Google-Sender-Auth: SOEe4iYNO4lUaGgxmmu6VaZBUik 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 Content-Length: 1774 Lines: 40 On Sun, Feb 1, 2015 at 6:40 AM, Benjamin LaHaise wrote: > > Chris Mason (1): > fs/aio: fix sleeping while TASK_INTERRUPTIBLE Ugh. This patch is too ugly to live. As far as I can tell, this is another case of people just mindlessly trying to make the warning go away, rather than fixing anything in teh code itself. In fact, the code gets less readable, and more hacky, with that insane "running" variable that doesn't actually add anything to the logic, just makes the code harder to read, and it's *very* non-obvious why this is done in the first place. If you want to shut up the warning without actually changing the code, use sched_annotate_sleep(). The comment about why the nested sleep isn't a problem ("sleeps in kmap or copy_to_user don't trigger warnings: If we don't copy enough events out, we'll loop through schedule() one time before sleeping"). I'm just about to push out a commit that makes "sched_annotate_sleep()" do the right thing, and *not* set TASK_RUNNING, but instead just disable the warning for that case. Which makes all these games unnecessary. I'm just waiting for my 'allmodconfig' build to finish before I push it out. Just another minute or two, I think. I really detest debug code (or compiler warnings) that encourage people to write code that is *worse* than the code that causes the debug code or warning to trigger. It's fundamentally wrong when those "fixes" actually make the code less readable and maintainable in the long run. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/