linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Pekka J Enberg <penberg@cs.helsinki.fi>
Cc: Theodore Tso <tytso@mit.edu>, Andreas Dilger <adilger@sun.com>,
	David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	arjan@infradead.org, linux-kernel@vger.kernel.org,
	cl@linux-foundation.org, npiggin@suse.de,
	linux-ext4@vger.kernel.org
Subject: Re: upcoming kerneloops.org item: get_page_from_freelist
Date: Fri, 26 Jun 2009 09:41:24 -0500	[thread overview]
Message-ID: <4A44DE14.2080403@redhat.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0906260815260.18724@melkki.cs.Helsinki.FI>

Pekka J Enberg wrote:
> Hi Ted,
> 
> On Thu, Jun 25, 2009 at 05:11:25PM -0500, Eric Sandeen wrote:
>>> ecryptfs used to do kmalloc(PAGE_CACHE_SIZE) & virt_to_page on that, and
>>> with SLUB + slub debug, that gave back non-aligned memory, causing
>>> eventual corruption ...
> 
> On Thu, 25 Jun 2009, Theodore Tso wrote:
>> Grumble.  Any chance we could add an kmem_cache option which requires
>> the memory to be aligned?  Otherwise we could rewrite our own sub-page
>> allocator in ext4 that only handled aligned filesystem block sizes
>> (i.e., 1k, 2k, 4k, etc.) but that would be really silly and be extra
>> code that really should be done once at core functionality.
> 
> We alredy have SLAB_HW_ALIGN but I wonder if this is a plain old bug in 
> SLUB. Christoph, Nick, don't we need something like this in the allocator? 
> Eric, does this fix your case?

I'll test it; it'd be great if it did, I'm um, a bit ashamed at how I
fixed it ;)

Thanks!
-Eric

> 			Pekka
> 
> diff --git a/mm/slub.c b/mm/slub.c
> index 819f056..7cd1e69 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -2400,7 +2400,7 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
>  	 * user specified and the dynamic determination of cache line size
>  	 * on bootup.
>  	 */
> -	align = calculate_alignment(flags, align, s->objsize);
> +	align = calculate_alignment(flags, align, size);
>  
>  	/*
>  	 * SLUB stores one object immediately after another beginning from


  parent reply	other threads:[~2009-06-26 14:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LFD.2.01.0906241240360.3154@localhost.localdomain>
     [not found] ` <20090624130121.99321cca.akpm@linux-foundation.org>
     [not found]   ` <alpine.LFD.2.01.0906241312090.3154@localhost.localdomain>
     [not found]     ` <alpine.LFD.2.01.0906241334260.3154@localhost.localdomain>
     [not found]       ` <20090624150714.c7264768.akpm@linux-foundation.org>
     [not found]         ` <20090625132544.GB9995@mit.edu>
     [not found]           ` <alpine.DEB.2.00.0906251135440.30090@chino.kir.corp.google.com>
     [not found]             ` <20090625193806.GA6472@mit.edu>
     [not found]               ` <20090625194423.GB6472@mit.edu>
     [not found]                 ` <alpine.DEB.2.00.0906251257040.3086@chino.kir.corp.google.com>
2009-06-25 20:37                   ` upcoming kerneloops.org item: get_page_from_freelist Theodore Tso
2009-06-25 21:05                     ` Joel Becker
2009-06-25 21:26                     ` Andreas Dilger
2009-06-25 22:05                       ` Theodore Tso
2009-06-25 22:11                         ` Eric Sandeen
2009-06-26  1:11                           ` Theodore Tso
2009-06-26  5:16                             ` Pekka J Enberg
2009-06-26  8:56                               ` Nick Piggin
2009-06-26  8:58                                 ` Pekka Enberg
2009-06-26  9:07                                   ` Nick Piggin
2009-06-29 21:06                                   ` Christoph Lameter
2009-06-30  7:59                                     ` Nick Piggin
2009-06-26 14:41                               ` Eric Sandeen [this message]
2009-06-29 21:15                                 ` Christoph Lameter
2009-06-29 21:20                                   ` Eric Sandeen
2009-06-29 22:35                                     ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A44DE14.2080403@redhat.com \
    --to=sandeen@redhat.com \
    --cc=adilger@sun.com \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=cl@linux-foundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=npiggin@suse.de \
    --cc=penberg@cs.helsinki.fi \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).