> From: Andrew Morton [mailto:akpm@xxxxxxxxxxxxxxxxxxxx] > Subject: Re: [PATCHv12 2/4] zbud: add to mm/ > > On Wed, 29 May 2013 15:42:36 -0500 Seth Jennings <sjenning@xxxxxxxxxxxxxxxxxx> wrote: > > > > > > I worry about any code which independently looks at the pageframe > > > > > tables and expects to find page struts there. One example is probably > > > > > memory_failure() but there are probably others. > > > > > > ^^ this, please. It could be kinda fatal. > > > > I'll look into this. > > > > The expected behavior is that memory_failure() should handle zbud pages in the > > same way that it handles in-use slub/slab/slob pages and return -EBUSY. > > memory_failure() is merely an example of a general problem: code which > reads from the memmap[] array and expects its elements to be of type > `struct page'. Other examples might be memory hotplugging, memory leak > checkers etc. I have vague memories of out-of-tree patches > (bigphysarea?) doing this as well. > > It's a general problem to which we need a general solution. <Obi-tmem Kenobe slowly materializes... "use the force, Luke!"> One could reasonably argue that any code that makes incorrect assumptions about the contents of a struct page structure is buggy and should be fixed. Isn't the "general solution" already described in the following comment, excerpted from include/linux/mm.h, which implies that "scribbling on existing pageframes" [carefully], is fine? (And, if not, shouldn't that comment be fixed, or am I misreading it?) <start excerpt> * For the non-reserved pages, page_count(page) denotes a reference count. * page_count() == 0 means the page is free. page->lru is then used for * freelist management in the buddy allocator. * page_count() > 0 means the page has been allocated. * * Pages are allocated by the slab allocator in order to provide memory * to kmalloc and kmem_cache_alloc. In this case, the management of the * page, and the fields in 'struct page' are the responsibility of mm/slab.c * unless a particular usage is carefully commented. (the responsibility of * freeing the kmalloc memory is the caller's, of course). * * A page may be used by anyone else who does a __get_free_page(). * In this case, page_count still tracks the references, and should only * be used through the normal accessor functions. The top bits of page->flags * and page->virtual store page management information, but all other fields * are unused and could be used privately, carefully. The management of this * page is the responsibility of the one who allocated it, and those who have * subsequently been given references to it. * * The other pages (we may call them "pagecache pages") are completely * managed by the Linux memory manager: I/O, buffers, swapping etc. * The following discussion applies only to them. <end excerpt> <Obi-tmem Kenobe slowly dematerializes> _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
