On Fri, Mar 30, 2018 at 8:07 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Fri, 30 Mar 2018 19:18:57 -0700 > Matthew Wilcox <willy@xxxxxxxxxxxxx> 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
