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: <550F51D5.2010804@oracle.com>
Date:	Sun, 22 Mar 2015 17:35:49 -0600
From:	David Ahern <david.ahern@...cle.com>
To:	David Miller <davem@...emloft.net>, torvalds@...ux-foundation.org
CC:	sparclinux@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Bob Picco <bpicco@...oft.net>
Subject: Re: 4.0.0-rc4: panic in free_block

On 3/22/15 4:23 PM, David Miller wrote:
>> I don't even know which version of memcpy ends up being used on M7.
>> Some of them do things like use VIS. I can follow some regular sparc
>> asm, there's no way I'm even *looking* at that. Is it really ok to use
>> VIS registers in random contexts?
>
> 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"
>
> The only thing funny some of these routines do is fetch 2 64-byte
> blocks of data ahead in the inner loops, but that should be fine
> right?
>
> On the M7 we'll use the Niagara-4 memcpy.
>
> Hmmm... I'll run this silly sparc kernel memmove through the glibc
> testsuite and see if it barfs.
>

I don't know if you caught Bob's message; he has a hack to bypass memcpy 
and memmove in mm/slab.c use a for loop to move entries. With the hack 
he is not seeing the problem.

This is the hack:

+static void move_entries(void *dest, void *src, int nr)
+{
+       unsigned long *dp = dest;
+       unsigned long *sp = src;
+
+       for (; nr; nr--, dp++, sp++)
+               *dp = *sp;
+}
+

and then replace the mempy and memmove calls in transfer_objects, 
cache_flusharray and drain_array to use move_entries.

I just put it on 4.0.0-rc4 and ditto -- problem goes away, so it clearly 
suggests the memcpy or memmove are the root cause.

David

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