Message ID | 20210630074433.41992-1-xuhuijie2@huawei.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | add kernel log when allocate a new virtual mapping failed because of overcommit | expand |
On Wed, Jun 30, 2021 at 03:44:33PM +0800, Xu Huijie wrote: > From: xuhuijie <xuhuijie2@huawei.com> > > diff --git a/mm/mmap.c b/mm/mmap.c > index aa9de981b..f019fc6b2 100644 > --- a/mm/mmap.c > +++ b/mm/mmap.c > @@ -1758,8 +1758,10 @@ unsigned long mmap_region(struct file *file, unsigned long addr, > */ > if (accountable_mapping(file, vm_flags)) { > charged = len >> PAGE_SHIFT; > - if (security_vm_enough_memory_mm(mm, charged)) > + if (security_vm_enough_memory_mm(mm, charged)) { > + pr_err("Unable to allocate a new virtual mapping because of the overcommit\n"); No, we don't let unprivileged processes flood the kernel logs. If this is genuinely useful, something like pr_info_ratelimited() might be appropriate. It certainly doesn't rise to the level of "error".
diff --git a/mm/mmap.c b/mm/mmap.c index aa9de981b..f019fc6b2 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -1758,8 +1758,10 @@ unsigned long mmap_region(struct file *file, unsigned long addr, */ if (accountable_mapping(file, vm_flags)) { charged = len >> PAGE_SHIFT; - if (security_vm_enough_memory_mm(mm, charged)) + if (security_vm_enough_memory_mm(mm, charged)) { + pr_err("Unable to allocate a new virtual mapping because of the overcommit\n"); return -ENOMEM; + } vm_flags |= VM_ACCOUNT; }
From: xuhuijie <xuhuijie2@huawei.com>