Messages in this thread | | | Date | Wed, 27 Apr 2022 14:34:23 +0800 | Subject | Re: [PATCH] mm/mprotect: reduce Committed_AS if memory protection is changed to PROT_NONE | From | liusongtang <> |
| |
On 2022/4/27 4:34, Andrew Morton wrote:
> On Tue, 26 Apr 2022 19:27:05 +0800 liusongtang <liusongtang@huawei.com> wrote: > >> If PROT_WRITE is set, the size of vm area will be added to Committed_AS. >> However, if memory protection is changed to PROT_NONE, >> the corresponding physical memory will not be used, but Committed_AS still >> count the size of the PROT_NONE memory. >> >> This patch reduce Committed_AS and free the corresponding memory if >> memory protection is changed to PROT_NONE. >> >> ... >> >> --- a/mm/mprotect.c >> +++ b/mm/mprotect.c >> @@ -497,6 +497,12 @@ mprotect_fixup(struct vm_area_struct *vma, struct vm_area_struct **pprev, >> } >> >> success: >> + if ((newflags & (VM_READ | VM_WRITE | VM_EXEC | VM_LOCKED | VM_ACCOUNT)) == VM_ACCOUNT) { >> + zap_page_range(vma, start, end - start); >> + newflags &= ~VM_ACCOUNT; >> + vm_unacct_memory((end - start) >> PAGE_SHIFT); >> + } >> + >> /* >> * vm_flags and vm_page_prot are protected by the mmap_lock >> * held in write mode. > Surprised. If userspace does mprotect(addr, len. PROT_NONE) then > mprotect(addr, len. PROT_READ), what is now at *addr? Zeroes? > .
1. In the case mentioned above, I think data in *addr is invalid after mprotect(addr, len. PROT_NONE), so clear it will not cause a problem. 2. Another idea is we can check if this vm area is populated before reduce Committed_AS.
| |