From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Ricardo Leitner Subject: Re: [RFC] memdup_user() and friends Date: Mon, 8 Jan 2018 12:57:20 -0200 Message-ID: <20180108145720.GI725@localhost.localdomain> References: <20180107021651.GB13338@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, netdev@vger.kernel.org To: Al Viro Return-path: Content-Disposition: inline In-Reply-To: <20180107021651.GB13338@ZenIV.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 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