On Thu, Apr 19, 2018 at 01:06:30PM +0200, Vlastimil Babka wrote: > On 04/18/2018 08:49 PM, Matthew Wilcox wrote: > > From: Matthew Wilcox <mawilcox@xxxxxxxxxxxxx> > > More rationale? Such as "This will allow us to ... later in the series"? Sure. Probably the best rationale at this point is that it'll allow us to move slub's counters into a union with s_mem later in the series. > > slub now needs to set page->mapping to NULL as it frees the page, just > > like slab does. > > I wonder if they should be touching the mapping field, and rather not > the slab_cache field, with a comment why it has to be NULLed? I add that to the documentation at the end of the series: * If you allocate the page using alloc_pages(), you can use some of the * space in struct page for your own purposes. The five words in the first * union are available, except for bit 0 of the first word which must be * kept clear. Many users use this word to store a pointer to an object * which is guaranteed to be aligned. If you use the same storage as * page->mapping, you must restore it to NULL before freeing the page. Thanks for your review!
