Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1667574 > unrolled thread

Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation.

Started byAnshuman Khandual <khandual@linux.vnet.ibm.com>
First post2017-06-16 11:30 +0200
Last post2017-06-16 21:20 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key  violation. Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2017-06-16 11:30 +0200
    Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection  key violation. Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-06-16 12:40 +0200
      Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key  violation. Ram Pai <linuxram@us.ibm.com> - 2017-06-16 21:20 +0200
        Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection  key violation. Benjamin Herrenschmidt <benh@kernel.crashing.org> - 2017-06-17 01:00 +0200
    Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key  violation. Ram Pai <linuxram@us.ibm.com> - 2017-06-16 21:20 +0200

#1667574 — Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation.

FromAnshuman Khandual <khandual@linux.vnet.ibm.com>
Date2017-06-16 11:30 +0200
SubjectRe: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation.
Message-ID<tSVJL-6Aa-1@gated-at.bofh.it>
On 06/06/2017 06:35 AM, Ram Pai wrote:
> The value of the AMR register at the time of the exception
> is made available in gp_regs[PT_AMR] of the siginfo.

But its already available there in uctxt->uc_mcontext.regs->amr
while inside the signal delivery context in the user space. The
pt_regs already got updated with new AMR register. Then why we
need gp_regs to also contain AMR as well ?

[toc] | [next] | [standalone]


#1667630 — Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation.

FromBenjamin Herrenschmidt <benh@kernel.crashing.org>
Date2017-06-16 12:40 +0200
SubjectRe: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation.
Message-ID<tSWPx-7fv-23@gated-at.bofh.it>
In reply to#1667574
On Fri, 2017-06-16 at 14:50 +0530, Anshuman Khandual wrote:
> On 06/06/2017 06:35 AM, Ram Pai wrote:
> > The value of the AMR register at the time of the exception
> > is made available in gp_regs[PT_AMR] of the siginfo.
> 
> But its already available there in uctxt->uc_mcontext.regs->amr
> while inside the signal delivery context in the user space. The
> pt_regs already got updated with new AMR register. Then why we
> need gp_regs to also contain AMR as well ?

Also changing gp_regs layout/size is a major ABI issue...

Ben.

[toc] | [prev] | [next] | [standalone]


#1668009

FromRam Pai <linuxram@us.ibm.com>
Date2017-06-16 21:20 +0200
Message-ID<tT4WJ-4mQ-1@gated-at.bofh.it>
In reply to#1667630
On Fri, Jun 16, 2017 at 08:33:01PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2017-06-16 at 14:50 +0530, Anshuman Khandual wrote:
> > On 06/06/2017 06:35 AM, Ram Pai wrote:
> > > The value of the AMR register at the time of the exception
> > > is made available in gp_regs[PT_AMR] of the siginfo.
> > 
> > But its already available there in uctxt->uc_mcontext.regs->amr
> > while inside the signal delivery context in the user space. The
> > pt_regs already got updated with new AMR register. Then why we
> > need gp_regs to also contain AMR as well ?
> 
> Also changing gp_regs layout/size is a major ABI issue...

Ben,
	
gp_regs size is not changed, nor is the layout. A unused field in
the gp_regs is used to fill in the AMR contents. Old binaries will not
be knowing about this unused field, and hence should not break.

New binaries can leverage this already existing but newly defined
field; to read the contents of AMR.

Is it still a concern?
RP

> 
> Ben.

-- 
Ram Pai

[toc] | [prev] | [next] | [standalone]


#1668084 — Re: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation.

FromBenjamin Herrenschmidt <benh@kernel.crashing.org>
Date2017-06-17 01:00 +0200
SubjectRe: [RFC PATCH 7/7 v1]powerpc: Deliver SEGV signal on protection key violation.
Message-ID<tT8nE-6yN-13@gated-at.bofh.it>
In reply to#1668009
On Fri, 2017-06-16 at 12:15 -0700, Ram Pai wrote:
> gp_regs size is not changed, nor is the layout. A unused field in
> the gp_regs is used to fill in the AMR contents. Old binaries will not
> be knowing about this unused field, and hence should not break.
> 
> New binaries can leverage this already existing but newly defined
> field; to read the contents of AMR.
> 
> Is it still a concern?

Calls to sys_swapcontext with a made-up context will end up with a crap
AMR if done by code who didn't know about that register.

Ben.

[toc] | [prev] | [next] | [standalone]


#1668011

FromRam Pai <linuxram@us.ibm.com>
Date2017-06-16 21:20 +0200
Message-ID<tT4WJ-4mQ-11@gated-at.bofh.it>
In reply to#1667574
On Fri, Jun 16, 2017 at 02:50:13PM +0530, Anshuman Khandual wrote:
> On 06/06/2017 06:35 AM, Ram Pai wrote:
> > The value of the AMR register at the time of the exception
> > is made available in gp_regs[PT_AMR] of the siginfo.
> 
> But its already available there in uctxt->uc_mcontext.regs->amr
> while inside the signal delivery context in the user space. The
> pt_regs already got updated with new AMR register. Then why we
> need gp_regs to also contain AMR as well ?

It should not be available in uctxt->uc_mcontext.regs->amr.
In fact that field itself should not be there.

The ideas was to use one of the unused fields in gp_regs; without
extending gp_regs, to provide the contents of AMR. the 
PT_AMR offset in gp_regs is currently not used, which I am using
in this patch.

However this patch needs to be modified not to extend pt_regs,
or uctxt->uc_mcontext.regs

Thanks for initiating this concern.
RP

-- 
Ram Pai

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web