linux-kernel - Re: Oops in a driver while using SLUB as a SLAB allocator

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]

Date:	Sun, 24 Jun 2007 11:51:52 +0100
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Hugh Dickins <hugh@...itas.com>
Cc:	Christoph Lameter <clameter@....com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>
Subject: Re: Oops in a driver while using SLUB as a SLAB allocator

On Sun, Jun 24, 2007 at 11:24:16AM +0100, Hugh Dickins wrote:
> On Sun, 24 Jun 2007, Russell King wrote:
> > On Fri, Jun 22, 2007 at 07:39:33PM +0100, Hugh Dickins wrote:
> > > I'm quite happy with this approach for 2.6.23-rc, along with your ARM
> > > dma_map patch which (if I understood aright) rmk approved.
> > 
> > I didn't approve it.  Please re-read my reply - there are still some
> > unanswered questions in it which _really_ need answering.
> 
> Sorry for misrepresenting you.
> 
> > The report talks about the AT91 machines.  These machines do not have
> > cache coherent DMA.  Therefore, the code being patched should be
> > optimised away by the compiler. *Or* we have even bigger problems.
> > 
> > Please forward the original problem report.
> 
> Done.

Okay, that seems to back up my suspicions - it's definitely AT91-based.
Since AT91-based machines do not have a DMA coherent cache,
arch_is_coherent() must be defined to '0'.  The only way that kmalloc
could be reached is if that were defined to something other than '0',
and if that's done on a machine with DMA incoherent caches, that will
lead to data corruption.

I think we need to wait for Nicolas to respond on this issue before
running headlong into applying a sticky plaster for something which is
actually a deeper issue.

However, the arch_is_coherent() path _is_ buggy as it stands, but in
more than the way identified thus far.  Eg, it doesn't set __GFP_DMA
appropriately for various DMA masks, so it might return DMA inaccessible
memory.

If we're after a simple fix for 2.6.22, the _easiest_ solution would be
to delete the entire arch_is_coherent() branches in arch/arm/mm/consistent.c;
that will result in a working solution for everyone, albiet at a slightly
lower performance for the DMA-coherent CPUs.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/