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. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
