[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1474562982.23058.140.camel@edumazet-glaptop3.roam.corp.google.com>
Date: Thu, 22 Sep 2016 09:49:42 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Alexander Viro <viro@...iv.linux.org.uk>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Michal Hocko <mhocko@...nel.org>,
netdev@...r.kernel.org
Subject: Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)
On Thu, 2016-09-22 at 18:43 +0200, Vlastimil Babka wrote:
> The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
> with the number of fds passed. We had a customer report page allocation
> failures of order-4 for this allocation. This is a costly order, so it might
> easily fail, as the VM expects such allocation to have a lower-order fallback.
>
> Such trivial fallback is vmalloc(), as the memory doesn't have to be
> physically contiguous. Also the allocation is temporary for the duration of the
> syscall, so it's unlikely to stress vmalloc too much.
vmalloc() uses a vmap_area_lock spinlock, and TLB flushes.
So I guess allowing vmalloc() being called from an innocent application
doing a select() might be dangerous, especially if this select() happens
thousands of time per second.
Powered by blists - more mailing lists