Messages in this thread | | | Date | Mon, 26 Apr 2004 22:15:19 -0700 | From | Andrew Morton <> | Subject | Re: put_page() tries to handle hugepages but fails |
| |
David Gibson <david@gibson.dropbear.id.au> wrote: > > 1) put_page() can still theoretically call > __page_cache_release() which is wrong (and makes the code misleading)
Don't think so?
void put_page(struct page *page) { if (unlikely(PageCompound(page))) { page = (struct page *)page->private; if (put_page_testzero(page)) { void (*dtor)(struct page *page);
dtor = (void (*)(struct page *))page[1].mapping; (*dtor)(page); } return; } if (!PageReserved(page) && put_page_testzero(page)) __page_cache_release(page); }
> - patch below replaces this with a BUG() if there is no destructor. 2) > what about wli's concern that mapping may be accessed without first > checking for a PageCompound?
That shouldn't be happening (should it?). If someone had such a page they'd need to lock it to play with ->mapping and I cannot think of any code which does all that and yet could stumble across a compound page?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |