On 09/28/2015 12:25 PM, Christian Borntraeger wrote:
> We do not have the storage keys per page table, but for the page frame
> instead
> (shared among all mappers) so I am not sure if the whole thing will fit for
> s390.
> Having a signal for page protection errors might be useful for us - not
Am 24.09.2015 um 19:15 schrieb Dave Hansen:
> Christian, can you tell us how big s390's storage protection keys are?
> See the discussion below about siginfo...
Dave, sorry for the late answer.
s390 storage keys are 4bit for the protection key (and 1 bit for fetch
protection,
change and referenc
* Dave Hansen wrote:
> On 09/25/2015 11:20 PM, Ingo Molnar wrote:
> > * Dave Hansen wrote:
> ...
> >> Since follow_pte() fails for all huge
> >> pages, it just falls back to pulling the protection key out of the VMA,
> >> which _does_ work for huge pages.
> >
> > That might be true for explici
On 09/25/2015 11:20 PM, Ingo Molnar wrote:
> * Dave Hansen wrote:
...
>> Since follow_pte() fails for all huge
>> pages, it just falls back to pulling the protection key out of the VMA,
>> which _does_ work for huge pages.
>
> That might be true for explicit hugetlb vmas, but what about transpare
* Dave Hansen wrote:
> On 09/25/2015 12:11 AM, Ingo Molnar wrote:
> >>> > > Btw., how does pkey support interact with hugepages?
> >> >
> >> > Surprisingly little. I've made sure that everything works with huge
> >> > pages and
> >> > that the (huge) PTEs and VMAs get set up correctly, but I
On 09/25/2015 12:11 AM, Ingo Molnar wrote:
>>> > > Btw., how does pkey support interact with hugepages?
>> >
>> > Surprisingly little. I've made sure that everything works with huge pages
>> > and
>> > that the (huge) PTEs and VMAs get set up correctly, but I'm not sure I had
>> > to
>> > tou
* Dave Hansen wrote:
> On 09/24/2015 02:30 AM, Ingo Molnar wrote:
> >> To answer your question in the comment: it looks useful to have some sort
> >> of
> >> 'extended page fault error code' information here, which shows why the
> >> page fault
> >> happened. With the regular error_code it's
On 09/24/2015 02:30 AM, Ingo Molnar wrote:
>> To answer your question in the comment: it looks useful to have some sort of
>> 'extended page fault error code' information here, which shows why the page
>> fault
>> happened. With the regular error_code it's easy - with protection keys
>> there's
Christian, can you tell us how big s390's storage protection keys are?
See the discussion below about siginfo...
On 09/24/2015 02:23 AM, Ingo Molnar wrote:
>> +static u16 fetch_pkey(unsigned long address, struct task_struct *tsk)
>> +{
...
>> +struct vm_area_struct *vma = find_vma(tsk-
* Ingo Molnar wrote:
> > --- a/include/uapi/asm-generic/siginfo.h~pkeys-09-siginfo 2015-09-16
> > 10:48:15.584161859 -0700
> > +++ b/include/uapi/asm-generic/siginfo.h2015-09-16 10:48:15.59216
> > -0700
> > @@ -95,6 +95,13 @@ typedef struct siginfo {
> > v
* Dave Hansen wrote:
> A protection key fault is very similar to any other access
> error. There must be a VMA, etc... We even want to take
> the same action (SIGSEGV) that we do with a normal access
> fault.
>
> However, we do need to let userspace know that something
> is different. We do
* Dave Hansen wrote:
> On 09/22/2015 01:27 PM, Thomas Gleixner wrote:
> >> >
> >> > So I defined all the kernel-internal types as u16 since I *know* the
> >> > size of the hardware.
> >> >
> >> > The user-exposed ones should probably be a bit more generic. I did just
> >> > realize that this
On 09/22/2015 01:27 PM, Thomas Gleixner wrote:
>> >
>> > So I defined all the kernel-internal types as u16 since I *know* the
>> > size of the hardware.
>> >
>> > The user-exposed ones should probably be a bit more generic. I did just
>> > realize that this is an int and my proposed syscall is a
On Tue, 22 Sep 2015, Dave Hansen wrote:
> On 09/22/2015 01:03 PM, Thomas Gleixner wrote:
> > On Wed, 16 Sep 2015, Dave Hansen wrote:
> >>
> >> +static inline u16 vma_pkey(struct vm_area_struct *vma)
> >> +{
> >> + u16 pkey = 0;
> >> +#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> >> + unsigne
On 09/22/2015 01:03 PM, Thomas Gleixner wrote:
> On Wed, 16 Sep 2015, Dave Hansen wrote:
>>
>> +static inline u16 vma_pkey(struct vm_area_struct *vma)
>> +{
>> +u16 pkey = 0;
>> +#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
>> +unsigned long f = vma->vm_flags;
>> +pkey |= (!!(f & VM
On Wed, 16 Sep 2015, Dave Hansen wrote:
>
> +static inline u16 vma_pkey(struct vm_area_struct *vma)
> +{
> + u16 pkey = 0;
> +#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> + unsigned long f = vma->vm_flags;
> + pkey |= (!!(f & VM_HIGH_ARCH_0)) << 0;
> + pkey |= (!!(f & VM_HIGH_
A protection key fault is very similar to any other access
error. There must be a VMA, etc... We even want to take
the same action (SIGSEGV) that we do with a normal access
fault.
However, we do need to let userspace know that something
is different. We do this the same way what we did with
SE
17 matches
Mail list logo
