linux-kernel - Re: v4.16+ seeing many unaligned access in dequeue_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]

Message-ID: <20180403073706.GV4082@hirez.programming.kicks-ass.net>
Date:   Tue, 3 Apr 2018 09:37:06 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     "Luck, Tony" <tony.luck@...el.com>
Cc:     Mel Gorman <mgorman@...hsingularity.net>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Patrick Bellasi <patrick.bellasi@....com>,
        Ingo Molnar <mingo@...nel.org>,
        Norbert Manthey <nmanthey@...zon.de>,
        Frederic Weisbecker <frederic@...nel.org>,
        linux-kernel@...r.kernel.org
Subject: Re: v4.16+ seeing many unaligned access in dequeue_task_fair() on
 IA64

On Mon, Apr 02, 2018 at 04:24:49PM -0700, Luck, Tony wrote:
> v4.16 boots cleanly. But with the first bunch of merges
> (Linus HEAD = 46e0d28bdb8e6d00e27a0fe9e1d15df6098f0ffb)
> I see a bunch of:
> 
> ia64_handle_unaligned: 4863 callbacks suppressed
> kernel unaligned access to 0xe00000031660fd74, ip=0xa0000001000f23e0
> kernel unaligned access to 0xe00000033bdffbcc, ip=0xa0000001000f2370
> kernel unaligned access to 0xe00000031660fd74, ip=0xa0000001000f23e0
> kernel unaligned access to 0xe00000033bdffbcc, ip=0xa0000001000f2370
> kernel unaligned access to 0xe00000031660fd74, ip=0xa0000001000f23e0
> 
> The addresses are all 4-byte, but not 8-byte aligned.
> 
> Any guesses before I start to bisect?

That doesn't sound good. The only guess I have at this moment is you
accidentially enabled RANDSTRUCT_PLUGIN and that messes things up.

struct task_struct whould be at least L1_CACHE_BYTES aligned, and C
otherwise makes it fairly hard to cause unaligned accesses. Packed
structures and/or casting are required, and I don't think we added
anything dodgy like that here.