Re: [PATCH] mm: make munlock fast when mlock is canceled by sigkill

[Hiroaki Wakabayashi <primulaelatior@gmail.com>]

Thank you for reviews.

>>> > @@ -254,6 +254,7 @@ static inline void
>>> > mminit_validate_memmodel_limits(unsigned long *start_pfn,
>>> >  #define GUP_FLAGS_FORCE                  0x2
>>> >  #define GUP_FLAGS_IGNORE_VMA_PERMISSIONS 0x4
>>> >  #define GUP_FLAGS_IGNORE_SIGKILL         0x8
>>> > +#define GUP_FLAGS_ALLOW_NULL             0x10
>>> >
>>>
>>> I am worried about adding new flag whenever we need it.
>>> But I think this case makes sense to me.
>>> In addition, I guess ZERO page can also use this flag.
>>>
>>> Kame. What do you think about it?
>>>
>> I do welcome this !
>> Then, I don't have to take care of mlock/munlock in ZERO_PAGE patch.
>>
>> And without this patch, munlock() does copy-on-write just for unpinning memory.
>> So, this patch shows some right direction, I think.
>>
>> One concern is flag name, ALLOW_NULL sounds not very good.
>>
>>  GUP_FLAGS_NOFAULT ?
>>
>> I wonder we can remove a hack of FOLL_ANON for core-dump by this flag, too.
>
> Yeah, GUP_FLAGS_NOFAULT is better.

Me too.
I will change this flag name.

> Plus, this patch change __get_user_pages() return value meaning IOW.
> after this patch, it can return following value,
>
>  return value: 3
>  pages[0]: hoge-page
>  pages[1]: null
>  pages[2]: fuga-page
>
> but, it can be
>
>  return value: 2
>  pages[0]: hoge-page
>  pages[1]: fuga-page
>
> no?

I did misunderstand mean of get_user_pages()'s return value.

When I try to change __get_user_pages(), I got problem.
If remove NULLs from pages,
__mlock_vma_pages_range() cannot know how long __get_user_pages() readed.
So, I have to get the virtual address of the page from vma and page.
Because __mlock_vma_pages_range() have to call
__get_user_pages() many times with different `start' argument.

I try to use page_address_in_vma(), but it failed.
(page_address_in_vma() returned -EFAULT)
I cannot find way to solve this problem.
Are there good ideas?
Please give me some ideas.

Thanks.
--
Hiroaki Wakabayashi

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>