Messages in this thread | | | Subject | Re: [PATCHv3 4/5] mm: make compound_head() robust | From | Vlastimil Babka <> | Date | Mon, 24 Aug 2015 17:49:45 +0200 |
| |
On 08/21/2015 09:34 PM, Andrew Morton wrote: > On Fri, 21 Aug 2015 22:31:09 +0300 "Kirill A. Shutemov" <kirill@shutemov.name> wrote: > >> On Fri, Aug 21, 2015 at 11:11:27AM -0500, Christoph Lameter wrote: >>> On Fri, 21 Aug 2015, Kirill A. Shutemov wrote: >>> >>>>> Is this really true? For example if it's a slab page, will that page >>>>> ever be inspected by code which is looking for the PageTail bit? >>>> >>>> +Christoph. >>>> >>>> What we know for sure is that space is not used in tail pages, otherwise >>>> it would collide with current compound_dtor. >>> >>> Sl*b allocators only do a virt_to_head_page on tail pages. >> >> The question was whether it's safe to assume that the bit 0 is always zero >> in the word as this bit will encode PageTail(). > > That wasn't my question actually... > > What I'm wondering is: if this page is being used for slab, will any > code path ever run PageTail() against it? If not, we don't need to be > concerned about that bit.
Pfn scanners such as compaction might inspect such pages and run compound_head() (and thus PageTail) on them. I think no kind of page within a zone (slab or otherwise) is "protected" from this, which is why it needs to be robust.
> And slab was just the example I chose. The same question petains to > all other uses of that union. >
| |