linux-kernel - Re: [PATCH] Containment measures for slab objects on scatter gather lists

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.0706291339160.10769@blonde.wat.veritas.com>
Date:	Fri, 29 Jun 2007 14:04:15 +0100 (BST)
From:	Hugh Dickins <hugh@...itas.com>
To:	Christoph Lameter <clameter@....com>
cc:	James Bottomley <James.Bottomley@...eleye.com>,
	David Miller <davem@...emloft.net>,
	Russell King <rmk+lkml@....linux.org.uk>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Containment measures for slab objects on scatter gather
 lists

On Thu, 28 Jun 2007, Christoph Lameter wrote:

> I had a talk with James Bottomley last night and it seems that there is an 
> established way of using the page structs of slab objects in the block 
> layer. Drivers may use the DMA interfaces to issue control commands. In 
> that case they may allocate a short structure via the slab allocator and 
> put the control commands into that slab object.
> 
> The driver will then perform a sg_init_one() on the slab object. 
> sg_init_one() calls sg_set_buf() which determines the page struct of a 
> page. In this case sg_set_buf() will determine the page struct of a slab 
> object. The dma layer may then perform operations on the "slab page". The 
> block layer folks seem to have spend some time to make this work right.

Yes, I don't see why this comes as such a surprise and horror to you,
so much in need of dire WARNINGs.  kmalloc memory is not a different
kind of memory from what you get from the page allocators.

I stand by my page_mapping patch, and the remark I made before,
that page_mapping(page) is the correct place to check this.  What is
page_mapping(page) for?  Precisely to return the struct address_space*
from page->mapping when that's what's in there, and not when that field
has been reused for something else.

So lines like
> +	mapping = PageSlab(page) ? NULL : page_mapping(page);
seem to miss the point.

I agree that the only clash found yet has been in flush_dcache_page,
so some bytes and branches can indeed be saved by just doing the
test in there.  Oh, but your VM_BUG_ON cancels out that saving.
And if we were to try to save bytes and branches there, it's the
synthetic swapper_space business (only required in a couple of
places) I'd be wanting to cut out.

To me this all seems like a big fuss to excuse your surprise:
so please don't expect an Ack from me; but if others prefer
this, I won't be Nacking.  (Though I'll probably whine about
it into eternity ;)

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/