linux-kernel - Re: Oops with DCACHE_WORD

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+55aFwPgWqCPA=ao6XmZy56PaJZ4WC+hOZ_CHGWpo_zO425VA@mail.gmail.com>
Date:	Wed, 2 May 2012 22:57:00 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Nick Piggin <npiggin@...il.com>
Cc:	Jana Saout <jana@...ut.de>, Joel Becker <jlbec@...lplan.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Oops with DCACHE_WORD_ACCESS and ocfs2, autofs4

On Wed, May 2, 2012 at 10:02 PM, Nick Piggin <npiggin@...il.com> wrote:
> Linus did you see this thread?

I did not..

>Any ideas what is going on?

Note that the discussion about aligned allocations is irrelevant. It
doesn't matter at all if the pathname allocation is aligned - what
matters if whether the last *component* of the pathname is aligned or
not, and that is not going to depend on the allocation alignment.

The word-at-a-time code assumes that no allocation will be the last
page (whether kmalloc or normal page allocation), which was always
somewhat optimistic but I thought it would be true on PC's.

And that %rbp value does *not* look like end-of-memory, but maybe
there is something else than just the CONFIG_DEBUG_PAGEALLOC that
causes us to punch holes even in the kernel memory map.

Peter, Ingo - do we unmap kernel pages for PAT etc attributes?

Jana, can you send me the whole dmesg for the bootup up to and
including the oops?

There are multiple ways to fix this, including just marking that
unaligned word access as being able to take an exception, but I had
hoped to avoid having to do that. There are alternatives, like always
padding allocations up by 7 bytes, but those are nasty too. So I'd
like to understand what triggers this for Jana, it's possible we can
just work around that particular issue.

                    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/