Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp549486ybm; Fri, 29 May 2020 06:40:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzVT96l6Xj70H6Ot8Nw+LIGlUyNZvVfUJ9/sYidbJkivP3x/euyYvYZ3v4IHYtDtIPDqKKX X-Received: by 2002:a05:6402:31ba:: with SMTP id dj26mr8005616edb.360.1590759606369; Fri, 29 May 2020 06:40:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590759606; cv=none; d=google.com; s=arc-20160816; b=oHlI5BNvM9ms4//W4hxhyJ2/Z7u8gle8vt3QqiKBEKLK9sq0ZyNY211DKlIFGNxn52 tl+preL3zf/ctciR8jgaq7PJrCrkQQnpKZQ04uW4D8t0U9OPxzlLnnz66nx7YdilAiEc wDXFdoGY2I2Mm61zhx+RGjHr/8c1SY/Im0T8kWDw4cpnj379Y2pLSab8fyYo/9iKeMrc X8jNAznlDzkab47WuEPverBLccLtwVaoepZyh5rqIW2xKBPomzPkJyf5i6BMotd91kwB Cmp+jWiRBainvEJJuLxoT8JSnBci+fCpx+/Ld0kMqXeTbnJHzJh75gP354mUn4dY6CP/ Ernw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=USNOCL0zV7zCH70SbQGAxsEDVmTA/oyxhnAkf1llcXI=; b=ft9fAHKqU8IxSIE0fPl7P+ToFk1p0RN7U74n50hT6fgvkDS/E347NklsGYQ7oLOYIt xa3U3QWCjSYW99SSL6Qn51epRb2VOqaorTBNbG9B/UZbjjApT5r3yfn0a6mGxLvP8VQG rzxlXlI5hKOsZR30x5q7iPt7WZ4QPaM0m+BNpiL0zxvDP61YbTseQoYJ8pDvYwFf62ZN 2tKLKy9O9GZDKkU4EnJ22Hk3aFe9utVq6l7F+0VE+JTp6rXZsoJQhg6RFfJWxoR4DVdJ DaYVKzFUjc7yhzRiEjjOVgCy+zYohqXCnASkDiyfQ1MbRqfn2ZyOHEfz+HKJ0qce6Fn7 WvNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t9si5308891edw.208.2020.05.29.06.39.41; Fri, 29 May 2020 06:40:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726934AbgE2Nht (ORCPT + 99 others); Fri, 29 May 2020 09:37:49 -0400 Received: from verein.lst.de ([213.95.11.211]:33056 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726476AbgE2Nht (ORCPT ); Fri, 29 May 2020 09:37:49 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id B6E8C68B02; Fri, 29 May 2020 15:37:44 +0200 (CEST) Date: Fri, 29 May 2020 15:37:44 +0200 From: Christoph Hellwig To: Al Viro Cc: Christoph Hellwig , Linus Torvalds , Ian Kent , David Howells , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-security-module@vger.kernel.org, netfilter-devel@vger.kernel.org Subject: Re: [PATCH 09/14] fs: don't change the address limit for ->write_iter in __kernel_write Message-ID: <20200529133744.GA654@lst.de> References: <20200528054043.621510-1-hch@lst.de> <20200528054043.621510-10-hch@lst.de> <20200528190052.GM23230@ZenIV.linux.org.uk> <20200529055736.GB6788@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200529055736.GB6788@lst.de> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 29, 2020 at 07:57:36AM +0200, Christoph Hellwig wrote: > On Thu, May 28, 2020 at 08:00:52PM +0100, Al Viro wrote: > > On Thu, May 28, 2020 at 07:40:38AM +0200, Christoph Hellwig wrote: > > > If we write to a file that implements ->write_iter there is no need > > > to change the address limit if we send a kvec down. Implement that > > > case, and prefer it over using plain ->write with a changed address > > > limit if available. > > > > Umm... It needs a comment along the lines of "weird shits like > > /dev/sg that currently check for uaccess_kernel() will just > > have to make sure they never switch to ->write_iter()" > > sg and hid has the uaccess_kernel because it accesses userspace memory not > in the range passed to it. Something using write_iter/read_iter should > never access any memory outside the iter passed to. rdma has it because > it uses write as a bidirectional interface, which obviously can't work at > all with an iter. So I'm not sure what we should comment on, but if > you have a desire and a proposal for a comment I'll happily add it. And looking over all three again they actually comment why they check uaccess_kernel. More importantly if someone switched them to the ->write_iter carelessly that means the uaccess outside of the range would actually aways fail now as we didn't allow access to userspace memory, so this should show up when testing instantly.