Re: upcoming kerneloops.org item: get_page_from_freelist

[Andreas Dilger <adilger@sun.com>]

On Jun 25, 2009  16:37 -0400, Theodore Ts'o wrote:
> On Thu, Jun 25, 2009 at 01:18:59PM -0700, David Rientjes wrote:
> > Isn't there also a problem in jbd2_journal_write_metadata_buffer(), 
> > though?
> > 
> > 		tmp = jbd2_alloc(bh_in->b_size, GFP_NOFS);
> 		...
> > 		memcpy(tmp, mapped_data + new_offset, jh2bh(jh_in)->b_size);
> > 
> > jbd2_alloc() is just a wrapper to __get_free_pages() and if it fails, it 
> > appears as though the memcpy() would cause a NULL pointer.
> 
> Nicely spotted.  Yeah, that's a bug; we need to do something about
> that one, too.

IIRC, in the past, jbd_alloc() had a retry mechanism that would loop
indefinitely for some allocations, because they couldn't be aborted
easily.  This was removed for some reason, I'm not sure why.

> And what we're doing is a bit silly; it may make sense
> to use __get_free_pages if filesystem blocksize == PAGE_SIZE, but
> otherwise we should be using a sub-page allocator.  Right now, we're
> chewing up a 16k PPC page for every 4k filesystem metadata page
> allocated in journal_write_metadata_buffer(), and on x86, for the
> (admittedly uncommon) 1k block filesystem, we'd be chewing up a 4k
> page for a 1k block buffer.

IIRC there was also a good reason for this in the past, related to
the buffers being submitted to the block device layer, and if they
were allocated from the slab cache with CONFIG_DEBUG_SLAB or something
similar enabled the buffer would be misaligned and cause grief.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.