All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Veltzer <mark.veltzer@gmail.com>
To: Andrea Arcangeli <aarcange@redhat.com>, linux-kernel@vger.kernel.org
Cc: Hugh Dickins <hugh.dickins@tiscali.co.uk>,
	Andi Kleen <andi@firstfloor.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Michael Kerrisk <mtk.manpages@gmail.com>,
	Nick Piggin <npiggin@suse.de>
Subject: Re: get_user_pages question
Date: Sun, 29 Nov 2009 00:22:17 +0200	[thread overview]
Message-ID: <200911290022.17568.mark.veltzer@gmail.com> (raw)
In-Reply-To: <20091128185052.GB30235@random.random>

On Saturday 28 November 2009 20:50:52 you wrote:
> Hi Hugh and everyone,
> 
> On Tue, Nov 10, 2009 at 04:33:30PM +0000, Hugh Dickins wrote:
> > In fairness I've added Andrea and KOSAKI-san to the Cc, since I know
> > they are two people keen to fix this issue once and for all.  Whereas
> 
> Right, I'm sure Nick also wants to fix this once and for all (adding
> him too to Cc ;).
> 
> I thought and I still think it's bad to leave races like this open for
> people to find out the hard way. It just takes somebody to use
> pthread_create, open a file with O_DIRECT with 512byte (not page
> ....

Hello all!

First let me state that I solved my problems by simply avoiding GUP completely 
and going with a clean mmap implemenation (with the nopage version) which 
causes no problems what so ever. mmap does not suffer from all the problems 
discussed above (aside from the fact that you have to do your own book keeping 
as far as vma_open and vma_close and fault function goes...). Please correct 
me if I'm wrong...:)

The fact that I solved all my problems with mmap and the complexity of the 
proposed solutions got me thinking about GUP in more general terms. Would it 
be fair to say that mmap is much more aligned to the kernels way of doing 
things than GUP? It feels like the vma concept which is a solid one and 
probably works well for most architectures is in conflict with GUP and so is 
fork. It also feels like the vma concept is well aligned with fork which means 
in turn that mmap is well aligned with fork while GUP is not. This is a new 
conclusion for me and one which did not register back when reading the LDD 
book (I got the impression that you can pick between mmap and GUP and it does 
not really matter but now I feel that mmap is much advanced and trouble free).

Testing it out I grepped the drivers folder of a recent kernel with ONLY 26 
mentions of GUP in the entire drivers folder! The main drivers using GUP are 
scsi st and infiniband. If GUP is so unused is it really essential as an in 
kernel interface? If GUP is slowly dropped and drivers converted to mmap would 
it not simplify kernel code or at least prevent complex solutions to GUP 
problems from complicating mm code even more? Again, I'm no kernel expert so 
please don't flame me too hard if I'm talking heresy or nonsense, I would just 
like to hear your take on this. It may well be that I simply have no clue and 
so my conclusions are way too radical...

Cheers,
	Mark

  reply	other threads:[~2009-11-28 22:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-09  6:50 get_user_pages question Mark Veltzer
2009-11-09  9:31 ` Andi Kleen
2009-11-09 10:32   ` Hugh Dickins
2009-11-09 22:13     ` Mark Veltzer
2009-11-10 16:33       ` Hugh Dickins
2009-11-28 18:50         ` Andrea Arcangeli
2009-11-28 22:22           ` Mark Veltzer [this message]
2009-11-30 12:01             ` Nick Piggin
2009-11-30 16:12               ` Andrea Arcangeli
2009-11-30 11:54           ` Nick Piggin
  -- strict thread matches above, loose matches on Subject: below --
2004-05-01 11:12 Eli Cohen
2004-05-01 11:32 ` Arjan van de Ven
2004-05-01 11:41   ` Eli Cohen

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=200911290022.17568.mark.veltzer@gmail.com \
    --to=mark.veltzer@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=hugh.dickins@tiscali.co.uk \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=npiggin@suse.de \
    /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.