All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: cel@citi.umich.edu
Cc: cel@netapp.com, linux-kernel@vger.kernel.org, trond.myklebust@fys.uio.no
Subject: Re: [PATCH 5/6] nfs: check all iov segments for correct memory access rights
Date: Fri, 19 May 2006 13:07:12 -0700	[thread overview]
Message-ID: <20060519130712.01828395.akpm@osdl.org> (raw)
In-Reply-To: <446E1E4D.7050800@citi.umich.edu>

Chuck Lever <cel@citi.umich.edu> wrote:
>
> Andrew Morton wrote:
> >> +		if (unlikely(!access_ok(type, buf, len))) {
> >> +			retval = -EFAULT;
> >> +			goto out;
> >> +		}
> > 
> > Now what's up here?  Why does NFS, at this level, care about the page's
> > virtual address?  get_user_pages() will handle that?
> 
> I guess I'm not clear on what behavior is desired for scatter/gather if 
> one of the segments in an iov fails.
> 
> If one of the iov's will cause an EFAULT, how is that reported back to 
> the application,

If nothing has yet been transferred to/from userspace, return -EFAULT.

If something has been transferred, return the number of bytes transferred.

> and what happens to the I/O being requested in the 
> other segments of the vector?

The filesystem driver needs to handle it somehow.

>  When do we use an "all or nothing" 
> semantic, and when is it OK for some segments to fail?

Actually, fs/direct-io.c cheats and doesn't implement the correct
semantics.  It returns either all-bytes-transferred or -EFOO.  The way I
justify that is to point out that returning a partial transfer count
doesn't make a lot of sense when the I/Os could complete in any order -
yes, we know how much data got transferred, but we don't know whereabouts
in the user's memory that data ended up.  So the user cannot trust _any_ of
it.

NFS direct-io can do the same.

But access_ok() isn't sufficient.  All it tells you is that the virtual
address is a legal one for an application.  But we could still get EFAULT
when trying to access it.


  reply	other threads:[~2006-05-19 20:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-19 17:56 [PATCH 0/6] Support scatter/gather I/O in NFS direct I/O path Chuck Lever
2006-05-19 18:00 ` [PATCH 1/6] nfs: "open code" the NFS direct write rescheduler Chuck Lever
2006-05-19 18:10   ` Andrew Morton
2006-05-19 18:37     ` Chuck Lever
2006-05-19 18:46       ` Andrew Morton
2006-05-19 18:56         ` Chuck Lever
2006-05-19 18:00 ` [PATCH 2/6] nfs: remove user_addr and user_count from nfs_direct_req Chuck Lever
2006-05-19 18:00 ` [PATCH 3/6] nfs: Eliminate nfs_get_user_pages() Chuck Lever
2006-05-19 18:17   ` Andrew Morton
2006-05-19 19:18     ` Chuck Lever
2006-05-19 18:00 ` [PATCH 4/6] nfs: alloc nfs_read/write_data as direct I/O is scheduled Chuck Lever
2006-05-19 18:00 ` [PATCH 5/6] nfs: check all iov segments for correct memory access rights Chuck Lever
2006-05-19 18:22   ` Andrew Morton
2006-05-19 18:46     ` Chuck Lever
2006-05-19 19:36     ` Chuck Lever
2006-05-19 20:07       ` Andrew Morton [this message]
2006-05-19 18:25   ` Badari Pulavarty
2006-05-22 11:27   ` Andi Kleen
2006-05-19 18:00 ` [PATCH 6/6] nfs: Support vector I/O throughout the NFS direct I/O path Chuck Lever

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=20060519130712.01828395.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=cel@citi.umich.edu \
    --cc=cel@netapp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=trond.myklebust@fys.uio.no \
    /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.