| 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
| ||
|
Date: Sun, 22 Mar 2015 19:57:43 -0400 (EDT) From: David Miller <davem@...emloft.net> To: torvalds@...ux-foundation.org Cc: david.ahern@...cle.com, sparclinux@...r.kernel.org, linux-mm@...ck.org, linux-kernel@...r.kernel.org Subject: Re: 4.0.0-rc4: panic in free_block From: Linus Torvalds <torvalds@...ux-foundation.org> Date: Sun, 22 Mar 2015 16:49:51 -0700 > 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? The special cache line clearing stores (the ASI_BLK_INIT_QUAD_LDD_P stuff) do not adhere to the memory model. I had elided the memory barriers originally, but it caused memory corruption. So yes, this is similar to the 'movnt' situation. -- 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