Re: PATCH 2.6.21-rc1 aoe: handle zero _count pages in bios

[Christoph Hellwig]

On Thu, Mar 01, 2007 at 05:42:04PM -0800, Andrew Morton wrote:
> Something funny is going on here.

Not so funny for those who've tried to sort out the issue over
the past years and just got ignored..

> Generally, one should increment the refcount of a page when it is put into
> some container.  That means that the page should get +1 when it is added to
> a bio.  (direct-io does this, but the mpage.c pagecache code cheats, and
> relies upon PG_locked and PG-writeback protecting the page).

It's a slab page, and slab pages aren't refcounted (which is a good thing
as you don't own the whole page)

> Similarly, the network code (or its caller) should be incrementing the
> page's refcount as the page goes into a container (ie: the skb) and
> decrementing it as the page is removed.
> 
> But someone somewhere is breaking those rules.  Who?

slab code.  

> So.  Who is breaking refcounting protocol here?  Perhaps it is AOE, failing
> to increment the refcount on pages as they are added to an skb?
> 
> (Do we know which callsite in XFS is adding zero-ref pages to a BIO, btw?)

For example all log I/O is done from kmalloce pages.

Anyway, to rehash what I've been trying to get clarified for ages:


 (1) should we allow to pass slab pages into bios

and

 (2) if yes what's the way lower layers are supposed to handle them
     for any possible refcounting operations like networking or rdma.

There's also a pontial caller in ext3 that can send down kmalloc'ed
buffers: journal_write_metadata_buffer() in need_copy_out && !done_copy_out
case.  But apparently that's an almost dead code path as I've never
seen anyone tripping this one, it's always XFS that people report.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/