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: Fri, 22 Jun 2007 06:37:03 +0100 (BST) From: Hugh Dickins <hugh@...itas.com> To: Christoph Lameter <clameter@....com> cc: Nicolas Ferre <nicolas.ferre@....atmel.com>, ARM Linux Mailing List <linux-arm-kernel@...ts.arm.linux.org.uk>, Linux Kernel list <linux-kernel@...r.kernel.org>, Marc Pignat <marc.pignat@...s.ch>, Andrew Victor <andrew@...people.com>, Pierre Ossman <drzeus@...eus.cx>, Andrew Morton <akpm@...ux-foundation.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Russell King <rmk@....linux.org.uk> Subject: Re: Oops in a driver while using SLUB as a SLAB allocator On Thu, 21 Jun 2007, Christoph Lameter wrote: > On Fri, 22 Jun 2007, Hugh Dickins wrote: > > > However... what gives you confidence that flush_dcache_page is > > never applied to other slab pages? > > Flush dcache page is supposed to run on pages not objects of varying > length. It is suprising that this has not lead to earlier problems. > Objects allocated this way may straddle a page boundary under some > conditions and in that case virt_to_page may not lead to a page that > covers the complete object that is supposed to be flushed. Hopefully the > "size" of the allocated object were whole pages. No, that's the wrong way round. Neither ARM nor PA-RISC expects flush_dcache_page to flush any dcache when given a slab allocation: they just expect it to pass through, not to oops. Hugh - 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