linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] powerpc: Fix possible deadlock on page fault
Date: Thu, 05 Sep 2013 21:50:35 +1000	[thread overview]
Message-ID: <1378381835.4321.169.camel@pasglop> (raw)
In-Reply-To: <87a9jrwkuc.fsf@linux.vnet.ibm.com>

On Thu, 2013-09-05 at 17:18 +0530, Aneesh Kumar K.V wrote:
> Paul Mackerras <paulus@samba.org> writes:
> 
> > On Thu, Sep 05, 2013 at 12:47:02PM +0530, Aneesh Kumar K.V wrote:
> >
> >> @@ -280,6 +280,13 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
> >>  
> >>  	perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
> >>  
> >> +	/*
> >> +	 * We want to do this outside mmap_sem, because reading code around nip
> >> +	 * can result in fault, which will cause a deadlock when called with
> >> +	 * mmap_sem held
> >> +	 */
> >> +	store_update = store_updates_sp(regs);
> >
> > We should only call store_updates_sp() if user_mode(regs); that was
> > the previous behaviour.
> 
> Updated to 
> 
> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
> index 8726779..fad7af6 100644
> --- a/arch/powerpc/mm/fault.c
> +++ b/arch/powerpc/mm/fault.c
> @@ -206,7 +206,7 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
>  	int trap = TRAP(regs);
>   	int is_exec = trap == 0x400;
>  	int fault;
> -	int rc = 0;
> +	int rc = 0, store_update = 0;

Keep the "sp", in the name, it's confusing otherwise. It's not just
about "store update", it's about specifically recognizing instructions
used to update the stack frame in order to let them and only them
significantly lower the stack pointer.

Cheers,
Ben.

>  #if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
>  	/*
> @@ -280,6 +280,14 @@ int __kprobes do_page_fault(struct pt_regs *regs, unsigned long address,
>  
>  	perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address);
>  
> +	/*
> +	 * We want to do this outside mmap_sem, because reading code around nip
> +	 * can result in fault, which will cause a deadlock when called with
> +	 * mmap_sem held
> +	 */
> +	if (user_mode(regs))
> +		store_update = store_updates_sp(regs);
> +
>  	/* When running in the kernel we expect faults to occur only to
>  	 * addresses in user space.  All other faults represent errors in the
>  	 * kernel and should generate an OOPS.  Unfortunately, in the case of an
> @@ -345,8 +353,7 @@ retry:
>  		 * between the last mapped region and the stack will
>  		 * expand the stack rather than segfaulting.
>  		 */
> -		if (address + 2048 < uregs->gpr[1]
> -		    && (!user_mode(regs) || !store_updates_sp(regs)))
> +		if (address + 2048 < uregs->gpr[1] && !store_update)
>  			goto bad_area;
>  	}
>  	if (expand_stack(vma, address))

  reply	other threads:[~2013-09-05 11:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05  7:17 [PATCH] powerpc: Fix possible deadlock on page fault Aneesh Kumar K.V
2013-09-05  9:53 ` Paul Mackerras
2013-09-05 11:48   ` Aneesh Kumar K.V
2013-09-05 11:50     ` Benjamin Herrenschmidt [this message]
2013-09-05 12:35       ` Aneesh Kumar K.V

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=1378381835.4321.169.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=paulus@samba.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;
as well as URLs for NNTP newsgroup(s).