From: Nick Piggin <npiggin@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org
Subject: Re: [patch 3/8] mm: merge nopfn into fault
Date: Sat, 19 May 2007 03:46:23 +0200 [thread overview]
Message-ID: <20070519014623.GF15569@wotan.suse.de> (raw)
In-Reply-To: <alpine.LFD.0.98.0705180817550.3890@woody.linux-foundation.org>
On Fri, May 18, 2007 at 08:23:53AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 18 May 2007, akpm@linux-foundation.org wrote:
> >
> > From: Nick Piggin <npiggin@suse.de>
> >
> > Remove ->nopfn and reimplement the existing handlers with ->fault
>
> So this is why you kept address.
Ah yeah..
> No no no.
>
> If we are changing the calling semantics of "nopage", then we should also
> remove the horrible, horrible hack of making the "nopfn" function itself
> do the "populate the page tables".
Hey, just now you wanted me to pass down a bloody pte_t! :)
> It would be *much* better to just
>
> > +static struct page *spufs_mem_mmap_fault(struct vm_area_struct *vma,
> > + struct fault_data *fdata)
> > {
> > struct spu_context *ctx = vma->vm_file->private_data;
> > unsigned long pfn, offset, addr0 = address;
> > @@ -137,9 +137,11 @@ static unsigned long spufs_mem_mmap_nopf
> > }
> > #endif /* CONFIG_SPU_FS_64K_LS */
> >
> > - offset = (address - vma->vm_start) + (vma->vm_pgoff << PAGE_SHIFT);
> > - if (offset >= LS_SIZE)
> > - return NOPFN_SIGBUS;
> > + offset = fdata->pgoff << PAGE_SHIFT
> > + if (offset >= LS_SIZE) {
> > + fdata->type = VM_FAULT_SIGBUS;
> > + return NULL;
> > + }
>
> if (offset >= LS_SIZE)
> return -EINVAL; /* or whatever error value */
>
> and *remove* the "vm_insert_pfn":
>
> > - vm_insert_pfn(vma, address, pfn);
> > + vm_insert_pfn(vma, fdata->address, pfn);
> >
> > spu_release(ctx);
> >
> > - return NOPFN_REFAULT;
> > + fdata->type = VM_FAULT_MINOR;
> > + return NULL;
> > }
>
> And instead on success do
>
> fdata->pfn = pfn;
> /* Or: 'fdata->pte = pte' */
> return VM_FAULT_MINOR;
>
> and let the caller always insert the thing into the page tables.
>
> Wouldn't it be nice if we never had drivers etc modifying page tables
> directly? Even with helpers like "vm_insert_pfn()"?
Yeah it would be logically nicer, but it puts more code and branches
in the ->fault fastpaths, which I was trying to avoid.
However, if you are willing to make that small tradeoff, and we have
handlers signal back to the caller that they are returning a pfn, then
OK.
But I don't think this is nearly so bad a violation than filesystems
doing ->populate or calculating their own pgoff. The reason? If the
driver is messing with pfns itself, then it already knows about some
aspect of memory management internals. At that point, I think it is
clean enough to have it call the vm_insert_pfn helper.
> And once you don't return "struct page *", the return values can be a lot
> more descriptive too.
That I agree with.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2007-05-19 1:46 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-18 7:37 akpm, Nick Piggin
2007-05-18 15:23 ` Linus Torvalds
2007-05-19 1:46 ` Nick Piggin [this message]
2007-05-23 23:40 ` Benjamin Herrenschmidt
2007-05-24 1:42 ` Nick Piggin
2007-05-24 2:04 ` Linus Torvalds
2007-05-24 2:16 ` Nick Piggin
2007-05-24 3:17 ` Benjamin Herrenschmidt
2007-05-24 3:26 ` Benjamin Herrenschmidt
2007-05-24 3:37 ` Linus Torvalds
2007-05-24 3:45 ` Nick Piggin
2007-05-24 10:07 ` Christoph Hellwig
2007-05-24 10:15 ` Benjamin Herrenschmidt
2007-05-24 3:48 ` Benjamin Herrenschmidt
2007-05-25 11:18 ` Nick Piggin
2007-05-25 16:36 ` Linus Torvalds
2007-05-26 7:34 ` Nick Piggin
2007-05-26 8:03 ` Nick Piggin
2007-05-26 15:44 ` Linus Torvalds
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=20070519014623.GF15569@wotan.suse.de \
--to=npiggin@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox