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,
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
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
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
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
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
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
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()"
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
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: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 do is
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 faults
On Sat, Feb 28, 2015 at 3:02 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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 ;)
On Sat, 2015-02-28 at 11:56 -0800, Linus Torvalds wrote:
On Fri, Feb 27, 2015 at 11:12 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
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 faults
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 it
On Sat, Feb 28, 2015 at 1:14 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
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
On Sat, Feb 28, 2015 at 11:56 AM, Linus Torvalds
torva...@linux-foundation.org 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
On Fri, Feb 27, 2015 at 11:12 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
On Sat, 2015-02-28 at 16:41 -0800, Linus Torvalds wrote:
On Sat, Feb 28, 2015 at 3:02 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org 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
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
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
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 and
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 body
26 matches
Mail list logo
