Messages in this thread | | | From | Joel Fernandes <> | Date | Fri, 30 Mar 2018 22:44:51 -0700 | Subject | Re: [PATCH v1] kernel/trace:check the val against the available mem |
| |
On Fri, Mar 30, 2018 at 8:07 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Fri, 30 Mar 2018 19:18:57 -0700 > Matthew Wilcox <willy@infradead.org> wrote: > >> Again though, this is the same pattern as vmalloc. There are any number >> of places where userspace can cause an arbitrarily large vmalloc to be >> attempted (grep for kvmalloc_array for a list of promising candidates). >> I'm pretty sure that just changing your GFP flags to GFP_KERNEL | >> __GFP_NOWARN will give you the exact behaviour that you want with no >> need to grub around in the VM to find out if your huge allocation is >> likely to succeed. > > Not sure how this helps. Note, I don't care about consecutive pages, so > this is not an array. It's a link list of thousands of pages. How do > you suggest allocating them? The ring buffer is a link list of pages.
Yeah I didn't understand the suggestion either. If I remember correctly, not using either NO_RETRY or RETRY_MAY_FAIL, and just plain GFP_KERNEL was precisely causing the buffer_size_kb write to cause an OOM in my testing. So I think Steven's patch does the right thing in checking in advance.
thanks,
- Joel
| |