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]
Message-ID: <CA+55aFx+HVnythC+BpmDMa0Oeq1MxnXXOvs771DXpJ=PBjy1Nw@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ