linux-kernel - Re: kernel BUG at mm/slub.c:3689!

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: <Pine.LNX.4.64.0706111208580.19316@schroedinger.engr.sgi.com>
Date:	Mon, 11 Jun 2007 12:11:19 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Håvard Skinnemoen <hskinnemoen@...il.com>
cc:	Haavard Skinnemoen <hskinnemoen@...el.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	David Brownell <david-b@...bell.net>
Subject: Re: kernel BUG at mm/slub.c:3689!

On Mon, 11 Jun 2007, Håvard Skinnemoen wrote:

> > >
> > > It's not about performance at all, it's about DMA buffers allocated
> > > using kmalloc() getting corrupted. Imagine this:
> > 
> > Uhhh... How about using a separate slab for the DMA buffers?
> 
> If there were just a few, known drivers that did this, sure. But as
> long as Documentation/DMA-mapping.txt includes this paragraph:
> 
>    If you acquired your memory via the page allocator
>    (i.e. __get_free_page*()) or the generic memory allocators
>    (i.e. kmalloc() or kmem_cache_alloc()) then you may DMA to/from
>    that memory using the addresses returned from those routines.
> 
> I think it's best to ensure that memory returned by kmalloc() actually
> can be used for DMA. I used to work around this problem in the SPI
> controller driver by using a temporary DMA buffer when possible
> misalignment was detected, but David Brownell said it was the wrong
> way to do it and pointed at the above paragraph.

Well there are various ways of doing DMA. Memory returned can be used for 
DMA but it may not be suitable for your DMA device if that device has 
issues like alignment or physical address size restrictions.

> But, as I mentioned, perhaps ARCH_KMALLOC_MINALIGN isn't the best way
> to solve the problem. I'll look into the flush-caches-from-dma_unmap
> approach. However, it looks like other arches set
> ARCH_KMALLOC_MINALIGN to various values -- I suspect some of them
> might run into the same problem as well?

Could be. That is why I am looking for a general solution.

> > SLABs mininum object size is 32 thus you had no problems. I see. SLAB
> > does not guarantee 32 byte alignment. It just happened to work. If you
> > switch on CONFIG_SLAB_DEBUG you will likely get into trouble.
> 
> Yeah, that's true. CONFIG_SLAB_DEBUG does indeed cause DMA buffer
> corruption on avr32, and so does CONFIG_SLOB. I've been wanting to fix
> it, but I never understood how. Now that SLUB seems to offer a
> solution that doesn't effectively turn off debugging, I thought I'd
> finally found it...

We should probably make the minimum slab size dependent on 
ARCH_KMALLOC_MINALIGN. There is no point in having smaller slabs anyways. 
They will all have the same size.