public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Keith Packard <keithp@keithp.com>
Cc: Daniel Vetter <daniel@ffwll.ch>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	stable@kernel.org, linux-kernel <linux-kernel@vger.kernel.org>,
	"Morton, Andrew" <akpm@linux-foundation.org>
Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915: properly prefault for pread/pwrite
Date: Thu, 3 Nov 2011 23:10:24 +0100	[thread overview]
Message-ID: <20111103221024.GG2970@phenom.ffwll.local> (raw)
In-Reply-To: <yunzkgcrk40.fsf@aiko.keithp.com>

On Thu, Nov 03, 2011 at 02:06:55PM -0700, Keith Packard wrote:
> On Mon, 24 Oct 2011 00:11:57 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> 
> > This patch only fixes things up so that we prefault the entire page range
> > and not just the first PAGE_SIZE bytes (i.e. at most 2 pages). So I don't
> > see the risk of extending the current behaviour to all pages. Userspace
> > can already see these zero writes, but only when doing something stupid.
> 
> When we posted a patch to instead fix fault_in_pages_writeable, Andrew
> complained that we'd have modified memory even on a short read, which
> wasn't considered polite. Could we read/write the same value and avoid
> that problem?

Hm, that might be a solution. My current plan was to ditch the prefault
for writing to userspace and beat my pwrite/pread patches into shape for
submission - the bug report only concerns -EFAULT due to handing in a gtt
mapping in pwrite, afaik.

otoh gem objects never change their size and we return -EINVAL if the read
would go past the end of it. And userspace should also never see short
reads due to signals, because the libdrm ioctl automatically restarts the
syscall - and that part is more or less abi. So in practice for our case,
I think it just doesn't matter because userspace really only sees these
zero writes when doing something buggy.

> Also, we should be fixing fault_in_pages_* going forward, rather than
> kludging in more code. And, we'd get to remove the version in ntfs,
> which should end in a patch that removes more code than it adds...

Hm, haven't noticed the version in nfs. The version in pagemap.h does what
all the other users of it want, namely prefault at most PAGE_SIZE bytes
(from at most two pages, in case the user pointer crosses a page boundary).
Which is why I've left it as is.
-Daniel
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48

      reply	other threads:[~2011-11-03 22:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1317203844-2930-1-git-send-email-daniel.vetter@ffwll.ch>
     [not found] ` <1317203844-2930-2-git-send-email-daniel.vetter@ffwll.ch>
     [not found]   ` <f80fcd$212d29@fmsmga001.fm.intel.com>
     [not found]     ` <20111023101830.GE2953@phenom.ffwll.local>
     [not found]       ` <yun7h3vbjgc.fsf@aiko.keithp.com>
     [not found]         ` <20111023221157.GH2953@phenom.ffwll.local>
2011-11-03 21:06           ` [Intel-gfx] [PATCH 2/2] drm/i915: properly prefault for pread/pwrite Keith Packard
2011-11-03 22:10             ` Daniel Vetter [this message]

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=20111103221024.GG2970@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=akpm@linux-foundation.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=keithp@keithp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox