linux-kernel - Re: [GIT PULL] aio: fix sleeping while TASK

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 1 Feb 2015 13:01:06 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	linux-aio@...ck.org, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] aio: fix sleeping while TASK_INTERRUPTIBLE

On Sun, Feb 1, 2015 at 6:40 AM, Benjamin LaHaise <bcrl@...ck.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/