[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <871tq077dt.fsf@rasmusvillemoes.dk>
Date: Wed, 22 Oct 2014 11:58:54 +0200
From: Rasmus Villemoes <linux@...musvillemoes.dk>
To: Andrey Ryabinin <a.ryabinin@...sung.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Michal Marek <mmarek@...e.cz>,
Sasha Levin <sasha.levin@...cle.com>, x86@...nel.org,
linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org,
Theodore Ts'o <tytso@....edu>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Dmitry Vyukov <dvyukov@...gle.com>,
Konstantin Khlebnikov <koct9i@...il.com>
Subject: Re: [RFC PATCH] UBSan: run-time undefined behavior sanity checker
On Mon, Oct 20 2014, Andrey Ryabinin <a.ryabinin@...sung.com> wrote:
> UBSan uses compile-time instrumentation to catch undefined behavior (UB).
> Compiler inserts code that perform certain kinds of
> checks before operations that could cause UB.
> If check fails (i.e. UB detected) __ubsan_handle_* function called.
> to print error message.
>
> So the most of the work is done by compiler.
> This patch just implements ubsan handlers printing errors.
>
> GCC supports this since 4.9, however upcoming GCC 5.0 has
> more checkers implemented.
[...]
> +
> +#define REPORTED_BIT 31
> +#define COLUMN_MASK (~(1U << REPORTED_BIT))
> +
> +static bool is_disabled(struct source_location *location)
> +{
> + return test_and_set_bit(REPORTED_BIT,
> + (unsigned long *)&location->column);
> +}
[...]
> +struct source_location {
> + const char *file_name;
> + u32 line;
> + u32 column;
> +};
AFAICT, this introduces UB and/or memory corruption on big-endian
systems with BITS_PER_LONG==64. (Also, on both LE and BE 64 bit systems,
there's the issue of the alignment of location->column, which is likely
to be 4-but-not-8 byte aligned).
Is the layout of struct source_location dictated by gcc?
Rasmus
--
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