On Sun, Jan 07, 2018 at 02:16:56AM +0000, Al Viro wrote: ... > > Everything else is definitely fine with GFP_USER - it's stuff like "copy of > ioctl > arguments in an ioctl never issued by the kernel code, must have come > straight from > ioctl(2)" and things like that. IMO we should simply switch memdup_user() to > GFP_USER and be done with that. Limiting the size ought to be done by > callers and > IMO there's no point in __GFP_NOWARN there.
I don't really follow the __GFP_NOWARN part here. You mean that there is no point on using __GFP_NOWARN there? I would think pretty much otherwise. There is no point in logging the trace as it is always a totally recoverable fault. > > What I propose is > * switch memdup_user() to GFP_USER > * add vmemdup_user(), using kvmalloc() instead of kmalloc() (also with > GFP_USER) > * switch open-coded instances of the latter to calling it > * switch some of the memdup_user() callers to vmemdup_user() - the ones > that > don't need physically contiguous copy and might be larger than a couple of > pages. > * add apriori bounds on size in the call sites that do not have those > yet - > that'll require comments from maintainers of the code in question in some > cases. > > Objections? None. Good timing, btw. I also got reports about such open size allocations and I'm finishing a patchset for SCTP to limit those. Will migrate sctp code to vmemdup_user() when available. Thanks, Marcelo
