On Sat, 2015-02-28 at 16:41 -0800, Linus Torvalds wrote:
> On Sat, Feb 28, 2015 at 3:02 PM, Benjamin Herrenschmidt
> wrote:
> >
> > Anyway, here's the current patch:
>
> Ok, I think I like this approach better.
>
> Your FAULT_FLAG_EXEC handling is wrong, though. It shouldn't check
> VM_WRITE, it
On Sat, Feb 28, 2015 at 3:02 PM, Benjamin Herrenschmidt
wrote:
>
> Anyway, here's the current patch:
Ok, I think I like this approach better.
Your FAULT_FLAG_EXEC handling is wrong, though. It shouldn't check
VM_WRITE, it should check VM_EXEC. A bit too much copy-paste ;)
Btw, it's quite possib
On Sun, 2015-03-01 at 09:16 +1100, Benjamin Herrenschmidt wrote:
> So for error handling, I'm trying to simply return the VM_FAULT_* flags
> from generic_page_fault see where that takes us. That's a way to avoid
> passing an arch specific struct around. It also allows my hack to
> account major fau
On Sun, 2015-03-01 at 09:16 +1100, Benjamin Herrenschmidt wrote:
> So for error handling, I'm trying to simply return the VM_FAULT_* flags
> from generic_page_fault see where that takes us. That's a way to avoid
> passing an arch specific struct around. It also allows my hack to
> account major fau
On Sat, 2015-02-28 at 13:49 -0800, Linus Torvalds wrote:
.../...
> - we handle write faults separately (see the first part of access_error()
>
> - so now we know it was a read or an instruction fetch
>
> - if PF_PROT is set, that means that the present bit was set in the
> page tables, so i
So for error handling, I'm trying to simply return the VM_FAULT_* flags
from generic_page_fault see where that takes us. That's a way to avoid
passing an arch specific struct around. It also allows my hack to
account major faults with the hypervisor to be done outside the generic
code completely (n
On Sat, Feb 28, 2015 at 1:14 PM, Benjamin Herrenschmidt
wrote:
>
> BTW. I fail to see how x86 checks PF_INSTR vs. VM_NOEXEC ... or it doesn't ?
It doesn't. x86 traditionally doesn't have an execute bit, so
traditionally "read == exec".
So PF_INSTR really wasn't historically very useful, in that
On Sat, 2015-02-28 at 11:56 -0800, Linus Torvalds wrote:
> On Fri, Feb 27, 2015 at 11:12 PM, Benjamin Herrenschmidt
> wrote:
> >
> > Let me know what you think of the approach.
>
> Hmm. I'm not happy with just how many of those arch wrapper/helper
> functions there are, and some of it looks a bit
On Sat, Feb 28, 2015 at 11:56 AM, Linus Torvalds
wrote:
>
> But I don't know. Maybe I'm wrong. I don't hate the patch as-is, I
> just have this feeling that it coudl be more "generic", and less
> "random small arch helpers".
Oh, and I definitely agree with you on the "single handle_bad_fault()"
t
On Fri, Feb 27, 2015 at 11:12 PM, Benjamin Herrenschmidt
wrote:
>
> Let me know what you think of the approach.
Hmm. I'm not happy with just how many of those arch wrapper/helper
functions there are, and some of it looks a bit unportable.
For example, the code "knows" that "err_code" and "addres
On Sat, 2015-02-28 at 18:14 +1100, Benjamin Herrenschmidt wrote:
> On Sat, 2015-02-28 at 18:12 +1100, Benjamin Herrenschmidt wrote:
> >
> > Let me know what you think of the approach. It's boot tested on x86_64
> > in qemu and
>
> ... and powerpc64 LE on qemu as well :-)
One thing I'd like to
On Sat, 2015-02-28 at 18:12 +1100, Benjamin Herrenschmidt wrote:
>
> Let me know what you think of the approach. It's boot tested on x86_64
> in qemu and
... and powerpc64 LE on qemu as well :-)
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Sun, 2015-02-01 at 17:09 -0800, Linus Torvalds wrote:
>
> Of course, what I *really* want would be to make a new
> "generic_mm_fault()" helper that would do all the normal stuff:
>
> - find_vma()
> - check permissions and ranges
> - call 'handle_mm_fault()'
> - do the proper error, retry a
13 matches
Mail list logo
