Messages in this thread | | | Subject | Re: [RFC] Tagging of vmalloc pages for supporting the pmalloc allocator | From | Igor Stoppa <> | Date | Wed, 9 Aug 2017 10:27:32 +0300 |
| |
On 09/08/17 02:15, Jerome Glisse wrote: > On Tue, Aug 08, 2017 at 03:59:36PM +0300, Igor Stoppa wrote:
[...]
>> I am tempted to add >> >> #define VM_PMALLOC 0x00000100
[...]
> VM_PMALLOC sounds fine to me also adding a comment there pointing to > pmalloc documentation would be a good thing to do. The above are flags > that are use only inside vmalloc context and so there is no issue > here of conflicting with other potential user.
ok, will do
>> >> Unless it's acceptable to check the private field in the page struct. >> It would bear the pmalloc magic number. > > I thought you wanted to do: > check struct page mapping field > check vmap->flags for VM_PMALLOC > > bool is_pmalloc(unsigned long addr) > { > struct page *page; > struct vm_struct *vm_struct; > > if (!is_vmalloc_addr(addr)) > return false; > page = vmalloc_to_page(addr); > if (!page) > return false; > if (page->mapping != pmalloc_magic_key)
page->private ? I thought mapping would not work in the cases you mentioned?
> return false; > > vm_struct = find_vm_area(addr); > if (!vm_struct) > return false; > > return vm_struct->flags & VM_PMALLOC; > } > > Did you change your plan ?
No, the code I have is almost 1:1 what you wrote. Apart from mapping <=> private
In my previous mail I referred to page->private.
Maybe I was not very clear in what I wrote, but I'm almost 100% aligned with your snippet.
>> I'm thinking to use a pointer to one of pmalloc data items, as signature. > > What ever is easier for you. Note that dereferencing such pointer before > asserting this is really a pmalloc page would be hazardous.
Yes, it's not even needed in this scenario. It was just a way to ensure that it would be a value that cannot be come out accidentally as pointer value, since it is already taken.
-- igor
| |