public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andrew Morton <akpm@osdl.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	linux-kernel@vger.kernel.org, ext2-devel@lists.sourceforge.net
Subject: Re: [BLOCK] bh: Ensure bh fits within a page
Date: Tue, 01 Aug 2006 15:08:36 -0400	[thread overview]
Message-ID: <1154459316.29772.5.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0608011034540.18006@schroedinger.engr.sgi.com>

On Tue, 2006-08-01 at 10:36 -0700, Christoph Lameter wrote:
> On Mon, 31 Jul 2006, Andrew Morton wrote:
> 
> > > Sure, this particular instance is in journal_write_metadata_buffer
> > > where the bh may be constructed from kmalloc memory (search for the
> > > call to jbd_rep_kmalloc).  Because the memory returned by kmalloc
> > > may straddle a page (when slab debugging is enabled that is), this
> > > causes a broken bh to be injected into submit_bh.
> > > 
> > 
> > Crap, that's hard to fix.   Am I allowed to blame submit_bh()? ;)
> > 
> > uhm, we don't want to lose kmalloc redzoning, so I guess we need to create
> > on-demand ext3-private slab caches for 1024, 2048, and 4096 bytes.  With
> > the appropriate slab flags to defeat the redzoning.
> 
> The slab allocator gives no guarantee that a structure is not straddling a 
> page boundary regardless of debug or not. It may just happen that the 
> objects are arranged if kmem_cache_cretae() is called with certain 
> parameters. Another arch with other cacheline alignment and another page 
> size may arrange the objects differently.

If you set the alignment for ext3 the same as the size (ie 1024, 2048,
4096 for the above respectively) then wouldn't that guarantee not
straddling a page?

-- Steve



  parent reply	other threads:[~2006-08-01 19:09 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-01  3:04 [BLOCK] bh: Ensure bh fits within a page Herbert Xu
2006-08-01  4:04 ` Andrew Morton
2006-08-01  5:02   ` Herbert Xu
2006-08-01  5:54     ` Andrew Morton
2006-08-01 11:06       ` Herbert Xu
2006-08-01 14:45         ` Andrew Morton
2006-08-01 17:36       ` Christoph Lameter
2006-08-01 19:08         ` Pekka Enberg
2006-08-01 19:08         ` Steven Rostedt [this message]
2006-08-01 19:10           ` Christoph Lameter
2006-08-01 19:35             ` Steven Rostedt
2006-08-01 19:55               ` Christoph Lameter
2006-08-01  7:23 ` Jens Axboe
2006-08-01 23:30   ` Herbert Xu
2006-08-01 23:32     ` Herbert Xu
2006-08-02  6:23       ` Jens Axboe
2006-08-01 23:44     ` Andrew Morton
2006-08-17 23:14     ` Badari Pulavarty
2006-08-18  2:53       ` Herbert Xu
2006-08-01 19:33 ` Andi Kleen
2006-08-01 22:09   ` Herbert Xu
2006-08-02 11:06     ` Jens Axboe

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=1154459316.29772.5.camel@localhost.localdomain \
    --to=rostedt@goodmis.org \
    --cc=akpm@osdl.org \
    --cc=clameter@sgi.com \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-kernel@vger.kernel.org \
    /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