* [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE
@ 2018-11-01 17:00 miles.chen
2018-11-01 17:09 ` Michal Hocko
2018-11-01 21:47 ` Andrew Morton
0 siblings, 2 replies; 7+ messages in thread
From: miles.chen @ 2018-11-01 17:00 UTC (permalink / raw)
To: Andrew Morton, Michal Hocko, Joe Perches, Matthew Wilcox
Cc: linux-mm, linux-kernel, linux-arm-kernel, linux-mediatek,
wsd_upstream, Miles Chen, Michal Hocko
From: Miles Chen <miles.chen@mediatek.com>
The page owner read might allocate a large size of memory with
a large read count. Allocation fails can easily occur when doing
high order allocations.
Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation
and avoid allocation fails due to high order allocation.
Change since v3:
- remove the change in kvmalloc
- keep kmalloc in page_owner.c
Change since v2:
- improve kvmalloc, allow sub page allocations fallback to
vmalloc when CONFIG_HIGHMEM=y
Change since v1:
- use kvmalloc()
- clamp buffer size to PAGE_SIZE
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
Cc: Joe Perches <joe@perches.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Michal Hocko <mhocko@kernel.org>
---
mm/page_owner.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/page_owner.c b/mm/page_owner.c
index 87bc0dfdb52b..b83f295e4eca 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -351,6 +351,7 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn,
.skip = 0
};
+ count = count > PAGE_SIZE ? PAGE_SIZE : count;
kbuf = kmalloc(count, GFP_KERNEL);
if (!kbuf)
return -ENOMEM;
--
2.18.0
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE
2018-11-01 17:00 [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE miles.chen
@ 2018-11-01 17:09 ` Michal Hocko
2018-11-01 21:47 ` Andrew Morton
1 sibling, 0 replies; 7+ messages in thread
From: Michal Hocko @ 2018-11-01 17:09 UTC (permalink / raw)
To: miles.chen
Cc: Andrew Morton, Joe Perches, Matthew Wilcox, linux-mm,
linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream
On Fri 02-11-18 01:00:07, miles.chen@mediatek.com wrote:
> From: Miles Chen <miles.chen@mediatek.com>
>
> The page owner read might allocate a large size of memory with
> a large read count. Allocation fails can easily occur when doing
> high order allocations.
>
> Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation
> and avoid allocation fails due to high order allocation.
It is good to mention that interface is root only so the harm due to
unbounded allocation request is somehow reduced.
I believe we want to use seq_file infrastructure in the long term
solution.
> Change since v3:
> - remove the change in kvmalloc
> - keep kmalloc in page_owner.c
>
> Change since v2:
> - improve kvmalloc, allow sub page allocations fallback to
> vmalloc when CONFIG_HIGHMEM=y
>
> Change since v1:
> - use kvmalloc()
> - clamp buffer size to PAGE_SIZE
>
> Signed-off-by: Miles Chen <miles.chen@mediatek.com>
> Cc: Joe Perches <joe@perches.com>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Michal Hocko <mhocko@kernel.org>
Acked-by: Michal Hocko <mhocko@suse.com>
Thanks!
> ---
> mm/page_owner.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/mm/page_owner.c b/mm/page_owner.c
> index 87bc0dfdb52b..b83f295e4eca 100644
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -351,6 +351,7 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn,
> .skip = 0
> };
>
> + count = count > PAGE_SIZE ? PAGE_SIZE : count;
> kbuf = kmalloc(count, GFP_KERNEL);
> if (!kbuf)
> return -ENOMEM;
> --
> 2.18.0
>
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE
2018-11-01 17:00 [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE miles.chen
2018-11-01 17:09 ` Michal Hocko
@ 2018-11-01 21:47 ` Andrew Morton
2018-11-01 23:30 ` Joe Perches
2018-11-02 0:41 ` William Kucharski
1 sibling, 2 replies; 7+ messages in thread
From: Andrew Morton @ 2018-11-01 21:47 UTC (permalink / raw)
To: miles.chen
Cc: Michal Hocko, Joe Perches, Matthew Wilcox, linux-mm,
linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
Michal Hocko
On Fri, 2 Nov 2018 01:00:07 +0800 <miles.chen@mediatek.com> wrote:
> From: Miles Chen <miles.chen@mediatek.com>
>
> The page owner read might allocate a large size of memory with
> a large read count. Allocation fails can easily occur when doing
> high order allocations.
>
> Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation
> and avoid allocation fails due to high order allocation.
>
> ...
>
> --- a/mm/page_owner.c
> +++ b/mm/page_owner.c
> @@ -351,6 +351,7 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn,
> .skip = 0
> };
>
> + count = count > PAGE_SIZE ? PAGE_SIZE : count;
> kbuf = kmalloc(count, GFP_KERNEL);
> if (!kbuf)
> return -ENOMEM;
A bit tidier:
--- a/mm/page_owner.c~mm-page_owner-clamp-read-count-to-page_size-fix
+++ a/mm/page_owner.c
@@ -351,7 +351,7 @@ print_page_owner(char __user *buf, size_
.skip = 0
};
- count = count > PAGE_SIZE ? PAGE_SIZE : count;
+ count = min_t(size_t, count, PAGE_SIZE);
kbuf = kmalloc(count, GFP_KERNEL);
if (!kbuf)
return -ENOMEM;
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE
2018-11-01 21:47 ` Andrew Morton
@ 2018-11-01 23:30 ` Joe Perches
2018-11-02 0:03 ` Matthew Wilcox
2018-11-02 0:41 ` William Kucharski
1 sibling, 1 reply; 7+ messages in thread
From: Joe Perches @ 2018-11-01 23:30 UTC (permalink / raw)
To: Andrew Morton, miles.chen
Cc: Michal Hocko, Matthew Wilcox, linux-mm, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, Michal Hocko
On Thu, 2018-11-01 at 14:47 -0700, Andrew Morton wrote:
> On Fri, 2 Nov 2018 01:00:07 +0800 <miles.chen@mediatek.com> wrote:
>
> > From: Miles Chen <miles.chen@mediatek.com>
> >
> > The page owner read might allocate a large size of memory with
> > a large read count. Allocation fails can easily occur when doing
> > high order allocations.
> >
> > Clamp buffer size to PAGE_SIZE to avoid arbitrary size allocation
> > and avoid allocation fails due to high order allocation.
> >
> > ...
> >
> > --- a/mm/page_owner.c
> > +++ b/mm/page_owner.c
> > @@ -351,6 +351,7 @@ print_page_owner(char __user *buf, size_t count, unsigned long pfn,
> > .skip = 0
> > };
> >
> > + count = count > PAGE_SIZE ? PAGE_SIZE : count;
> > kbuf = kmalloc(count, GFP_KERNEL);
> > if (!kbuf)
> > return -ENOMEM;
>
> A bit tidier:
>
> --- a/mm/page_owner.c~mm-page_owner-clamp-read-count-to-page_size-fix
> +++ a/mm/page_owner.c
> @@ -351,7 +351,7 @@ print_page_owner(char __user *buf, size_
> .skip = 0
> };
>
> - count = count > PAGE_SIZE ? PAGE_SIZE : count;
> + count = min_t(size_t, count, PAGE_SIZE);
> kbuf = kmalloc(count, GFP_KERNEL);
> if (!kbuf)
> return -ENOMEM;
A bit tidier still might be
if (count > PAGE_SIZE)
count = PAGE_SIZE;
as that would not always cause a write back to count.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE
2018-11-01 23:30 ` Joe Perches
@ 2018-11-02 0:03 ` Matthew Wilcox
0 siblings, 0 replies; 7+ messages in thread
From: Matthew Wilcox @ 2018-11-02 0:03 UTC (permalink / raw)
To: Joe Perches
Cc: Andrew Morton, miles.chen, Michal Hocko, linux-mm, linux-kernel,
linux-arm-kernel, linux-mediatek, wsd_upstream, Michal Hocko
On Thu, Nov 01, 2018 at 04:30:12PM -0700, Joe Perches wrote:
> On Thu, 2018-11-01 at 14:47 -0700, Andrew Morton wrote:
> > +++ a/mm/page_owner.c
> > @@ -351,7 +351,7 @@ print_page_owner(char __user *buf, size_
> > .skip = 0
> > };
> >
> > - count = count > PAGE_SIZE ? PAGE_SIZE : count;
> > + count = min_t(size_t, count, PAGE_SIZE);
> > kbuf = kmalloc(count, GFP_KERNEL);
> > if (!kbuf)
> > return -ENOMEM;
>
> A bit tidier still might be
>
> if (count > PAGE_SIZE)
> count = PAGE_SIZE;
>
> as that would not always cause a write back to count.
90% chance 'count' is already in a register and will stay there. 99.9%
chance that if it's not in a register, it's on the top of the stack,
which is by definition a hot, local, dirty cacheline.
What you're saying makes sense for a struct which might well be in a
shared cacheline state. But for a function-local variable? No.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE
2018-11-01 21:47 ` Andrew Morton
2018-11-01 23:30 ` Joe Perches
@ 2018-11-02 0:41 ` William Kucharski
2018-11-06 21:51 ` Andrew Morton
1 sibling, 1 reply; 7+ messages in thread
From: William Kucharski @ 2018-11-02 0:41 UTC (permalink / raw)
To: Andrew Morton
Cc: miles.chen, Michal Hocko, Joe Perches, Matthew Wilcox, linux-mm,
linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
Michal Hocko
> On Nov 1, 2018, at 3:47 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> - count = count > PAGE_SIZE ? PAGE_SIZE : count;
> + count = min_t(size_t, count, PAGE_SIZE);
> kbuf = kmalloc(count, GFP_KERNEL);
> if (!kbuf)
> return -ENOMEM;
Is the use of min_t vs. the C conditional mostly to be more self-documenting?
The compiler-generated assembly between the two versions seems mostly a wash.
William Kucharski
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE
2018-11-02 0:41 ` William Kucharski
@ 2018-11-06 21:51 ` Andrew Morton
0 siblings, 0 replies; 7+ messages in thread
From: Andrew Morton @ 2018-11-06 21:51 UTC (permalink / raw)
To: William Kucharski
Cc: miles.chen, Michal Hocko, Joe Perches, Matthew Wilcox, linux-mm,
linux-kernel, linux-arm-kernel, linux-mediatek, wsd_upstream,
Michal Hocko
On Thu, 1 Nov 2018 18:41:33 -0600 William Kucharski <william.kucharski@oracle.com> wrote:
>
>
> > On Nov 1, 2018, at 3:47 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> >
> > - count = count > PAGE_SIZE ? PAGE_SIZE : count;
> > + count = min_t(size_t, count, PAGE_SIZE);
> > kbuf = kmalloc(count, GFP_KERNEL);
> > if (!kbuf)
> > return -ENOMEM;
>
> Is the use of min_t vs. the C conditional mostly to be more self-documenting?
Yup. It saves the reader from having to parse the code to figure out
"this is a min operation".
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-11-06 21:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-01 17:00 [PATCH v4] mm/page_owner: clamp read count to PAGE_SIZE miles.chen
2018-11-01 17:09 ` Michal Hocko
2018-11-01 21:47 ` Andrew Morton
2018-11-01 23:30 ` Joe Perches
2018-11-02 0:03 ` Matthew Wilcox
2018-11-02 0:41 ` William Kucharski
2018-11-06 21:51 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).