linux-kernel - Re: [3.11-rc1] CONFIG_DEBUG_MUTEXES=y using gcc 3.x makes unbootable kernel.

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: <CAKb7UvjH1XZ3f-c=149s5=rqxkxVUhG_7-cfUYH3zrwJwr2_MQ@mail.gmail.com>
Date:	Sun, 8 Sep 2013 01:28:19 -0400
From:	Ilia Mirkin <imirkin@...m.mit.edu>
To:	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:	Maarten Lankhorst <maarten.lankhorst@...onical.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Rob Clark <robdclark@...il.com>, a.p.zijlstra@...llo.nl,
	mingo@...nel.org
Subject: Re: [3.11-rc1] CONFIG_DEBUG_MUTEXES=y using gcc 3.x makes unbootable kernel.

On Sun, Sep 8, 2013 at 12:32 AM, Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
> Hello.
>
> I found what is wrong.
>
> ---------- bad patch start ----------
> >From 3c56dfbd32a9b67ba824ce96128bb513eb65de4b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> Date: Sun, 8 Sep 2013 12:44:20 +0900
> Subject: [PATCH] mutex: Avoid gcc version dependent __builtin_constant_p() usage.
>
> Commit 040a0a37 "mutex: Add support for wound/wait style locks" used
> "!__builtin_constant_p(p == NULL)" which I guess the author meant that
> "__builtin_constant_p(p) && p", but gcc 3.x cannot handle such expression
> correctly, leading to boot failure when built with CONFIG_DEBUG_MUTEXES=y.

I think that !__builtin_constant_p(p == NULL) is basically saying "I
am unable to conclude that p == NULL at build time", which would
translate to something along the lines of

(__builtin_constant_p(p) && p) || !__builtin_constant_p(p)

Your logic will be be false for non-built-in-constants supplied as p.

Or perhaps it's just equivalent to !__builtin_constant_p(p), since the
compiler's ability to conclude whether it is NULL at build-time should
be unaffected by whether it actually is NULL or not. Some simple
experimentation with recent gcc's should be able to determine this.
The more I think about it, the more likely the latter interpretation
is correct and you can just drop the == NULL's. (Although perhaps the
original intent was more like the former.)

  -ilia
--
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/