All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Jan Stancek <jstancek@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
	Greg Ungerer <gerg@uclinux.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] fix fault_in_multipages_...() on architectures with no-op access_ok()
Date: Tue, 20 Sep 2016 21:38:21 +0100	[thread overview]
Message-ID: <20160920203821.GQ2356@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CA+55aFx-NuAZS9M0_UUwbMU91VnkG+gxLtqX-uWJQAYrh1Vq6w@mail.gmail.com>

On Tue, Sep 20, 2016 at 01:24:25PM -0700, Linus Torvalds wrote:

> Quite frankly, I think it is access_ok() that should be fixed for s390.
> 
> A wrapping user access is *not* ok, not even if kernel and user memory
> are separate.
> 
> It is insane to make fault_in_multipages..() return EFAULT if a normal
> wrapping user access wouldn't. So the fix is not to change
> fault_in_multipage_xyz, but to make sure any op that tries to wrap
> will properly return EFAULT.

Not the point.  Of course it *would* fail; the problem is that the loop
that would ping each page is never executed.  What happens is
	while (uaddr <= end) 
		touch uaddr
		uaddr += PAGE_SIZE
	if uaddr and end point to different pages
		ping end

What happens if uaddr is greater than end, thanks to wraparound?  Right,
we skip the loop entirely and all we do is one ping of the end.  Which
might very well succeed, leaving us with false positive.

  reply	other threads:[~2016-09-20 20:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 12:56 [bug] pwritev02 hang on s390x with 4.8.0-rc7 Jan Stancek
2016-09-20 15:06 ` Al Viro
2016-09-20 17:11   ` Jan Stancek
2016-09-20 17:30     ` Al Viro
2016-09-21  6:49       ` [LTP] Fwd: writev01/03/04 failures with 4.8-rc7 / was: " Jan Stancek
2016-09-20 19:07     ` [PATCH] fix fault_in_multipages_...() on architectures with no-op access_ok() Al Viro
2016-09-20 20:24       ` Linus Torvalds
2016-09-20 20:38         ` Al Viro [this message]
2016-09-20 20:48           ` Linus Torvalds
2016-09-20 21:03             ` Al Viro
2016-09-20 21:37               ` Al Viro
2016-09-20 23:43               ` Linus Torvalds
2016-09-21  0:38                 ` Al Viro

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=20160920203821.GQ2356@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=arnd@arndb.de \
    --cc=gerg@uclinux.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jstancek@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.