netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ian Kent <raven@themaw.net>, David Howells <dhowells@redhat.com>,
	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
Date: Fri, 29 May 2020 15:37:44 +0200	[thread overview]
Message-ID: <20200529133744.GA654@lst.de> (raw)
In-Reply-To: <20200529055736.GB6788@lst.de>

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.

  reply	other threads:[~2020-05-29 13:37 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-28  5:40 clean up kernel_{read,write} & friends v2 Christoph Hellwig
2020-05-28  5:40 ` [PATCH 01/14] cachefiles: switch to kernel_write Christoph Hellwig
2020-05-28  5:40 ` [PATCH 02/14] autofs: " Christoph Hellwig
2020-05-28  5:40 ` [PATCH 03/14] bpfilter: " Christoph Hellwig
2020-05-28  5:40 ` [PATCH 04/14] fs: unexport __kernel_write Christoph Hellwig
2020-05-28  5:40 ` [PATCH 05/14] fs: check FMODE_WRITE in __kernel_write Christoph Hellwig
2020-05-28  5:40 ` [PATCH 06/14] fs: remove the call_{read,write}_iter functions Christoph Hellwig
2020-05-28 18:56   ` Al Viro
2020-05-29  5:51     ` Christoph Hellwig
2020-05-28  5:40 ` [PATCH 07/14] fs: implement kernel_write using __kernel_write Christoph Hellwig
2020-05-28  5:40 ` [PATCH 08/14] fs: remove __vfs_write Christoph Hellwig
2020-05-28  5:40 ` [PATCH 09/14] fs: don't change the address limit for ->write_iter in __kernel_write Christoph Hellwig
2020-05-28 18:43   ` Linus Torvalds
2020-05-29 12:32     ` Christoph Hellwig
2020-05-31 23:59       ` Logan Gunthorpe
2020-05-28 19:00   ` Al Viro
2020-05-29  5:57     ` Christoph Hellwig
2020-05-29 13:37       ` Christoph Hellwig [this message]
2020-05-28  5:40 ` [PATCH 10/14] fs: add a __kernel_read helper Christoph Hellwig
2020-05-28  5:40 ` [PATCH 11/14] integrity/ima: switch to using __kernel_read Christoph Hellwig
2020-05-28  5:40 ` [PATCH 12/14] fs: implement kernel_read " Christoph Hellwig
2020-05-28  5:40 ` [PATCH 13/14] fs: remove __vfs_read Christoph Hellwig
2020-05-28  5:40 ` [PATCH 14/14] fs: don't change the address limit for ->read_iter in __kernel_read Christoph Hellwig
2020-05-28 19:03   ` Al Viro
2020-05-28 18:51 ` clean up kernel_{read,write} & friends v2 Linus Torvalds
2020-05-28 18:57   ` Sedat Dilek
2020-05-28 19:22   ` Joe Perches
2020-05-28 19:33     ` Al Viro
2020-05-28 19:44       ` Matthew Wilcox
2020-05-28 20:06         ` Al Viro
2020-05-28 20:14           ` Deucher, Alexander
2020-05-28 20:18         ` Joe Perches
2020-05-28 20:29       ` Dave Airlie
2020-05-28 21:03     ` Joe Perches
2020-05-28 20:17 ` David Howells
2020-05-28 21:20   ` Casey Schaufler
2020-05-29 13:08     ` David Laight
2020-05-29 19:19       ` Linus Torvalds
2020-05-29 22:02         ` Casey Schaufler
2020-05-29 23:12         ` [PATCH] checkpatch/coding-style: Allow 100 column lines Joe Perches
2020-05-30 22:14           ` Andreas Dilger
2020-05-30 23:15             ` Joe Perches
2020-06-05  6:36         ` clean up kernel_{read,write} & friends v2 Philippe Mathieu-Daudé
2020-06-05 15:00           ` Nicolas Pitre
  -- strict thread matches above, loose matches on Subject: below --
2020-05-13  6:56 Christoph Hellwig
2020-05-13  6:56 ` [PATCH 09/14] fs: don't change the address limit for ->write_iter in __kernel_write Christoph Hellwig
     [not found] ` <20200516030436.19448-1-hdanton@sina.com>
2020-05-18  6:42   ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200529133744.GA654@lst.de \
    --to=hch@lst.de \
    --cc=dhowells@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=raven@themaw.net \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).