linux-kernel - Re: 4.0.0-rc4: panic in free

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+55aFwWJU+D_rFhZVf0JZ599XH-2APELyrpBYYuvDsynyoMUw@mail.gmail.com>
Date:	Sun, 22 Mar 2015 16:49:51 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	David Miller <davem@...emloft.net>
Cc:	David Ahern <david.ahern@...cle.com>, sparclinux@...r.kernel.org,
	linux-mm <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 4.0.0-rc4: panic in free_block

On Sun, Mar 22, 2015 at 3:23 PM, David Miller <davem@...emloft.net> wrote:
>
> Yes, using VIS how we do is alright, and in fact I did an audit of
> this about 1 year ago.  This is another one of those "if this is
> wrong, so much stuff would break"

Maybe. But it does seem like Bob Picco has narrowed it down to memmove().

It also bothers me enormously - and perhaps unreasonably - how that
memcpy code has memory barriers in it. I can see _zero_ reason for a
memory barrier inside a memcpy, unless the memcpy does something that
isn't valid to begin with. Are the VIS operatiosn perhaps using some
kind of non-temporal form that doesn't follow the TSO rules? Kind of
like the "movnt" that Intel has?

That kind of stuff makes me worry. For example, the only reason I see for

        membar          #StoreLoad | #StoreStore

after that VIS loop is that the stxa doesn't honor normal memory store
ordering rules, but if that's true, then shouldn't we have a membar
*before* the loop too? How about "ldx"? Does that also do some
unordered loads?

So the memory barriers in there just make me nervous, because they are
either entirely bogus or superfluous, or they are not - and if they
aren't, then that implies that some of the code does something really
odd with memory ordering.

I dunno. I really can't read that code at all, so I'm going entirely
by gut instinct here.

                          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/