All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: "Michael Ellerman" <mpe@ellerman.id.au>,
	"Michal Suchánek" <msuchanek@suse.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
	linuxppc-dev@lists.ozlabs.org,
	Daniel Black <daniel@linux.ibm.com>
Subject: Re: [PATCH] powerpc/fault: kernel can extend a user process's stack
Date: Tue, 21 Jul 2020 10:57:52 +1000	[thread overview]
Message-ID: <87k0yxu1kf.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <878sfethsj.fsf@mpe.ellerman.id.au>

Michael Ellerman <mpe@ellerman.id.au> writes:

> Michal Suchánek <msuchanek@suse.de> writes:
>> Hello,
>>
>> On Wed, Dec 11, 2019 at 08:37:21PM +1100, Daniel Axtens wrote:
>>> > Fixes: 14cf11af6cf6 ("powerpc: Merge enough to start building in
>>> > arch/powerpc.")
>>> 
>>> Wow, that's pretty ancient! I'm also not sure it's right - in that same
>>> patch, arch/ppc64/mm/fault.c contains:
>>> 
>>> ^1da177e4c3f4 (Linus Torvalds         2005-04-16 15:20:36 -0700 213)            if (address + 2048 < uregs->gpr[1]
>>> ^1da177e4c3f4 (Linus Torvalds         2005-04-16 15:20:36 -0700 214)                && (!user_mode(regs) || !store_updates_sp(regs)))
>>> ^1da177e4c3f4 (Linus Torvalds         2005-04-16 15:20:36 -0700 215)                    goto bad_area;
>>> 
>>> Which is the same as the new arch/powerpc/mm/fault.c code:
>>> 
>>> 14cf11af6cf60 (Paul Mackerras 2005-09-26 16:04:21 +1000 234)            if (address + 2048 < uregs->gpr[1]
>>> 14cf11af6cf60 (Paul Mackerras 2005-09-26 16:04:21 +1000 235)                && (!user_mode(regs) || !store_updates_sp(regs)))
>>> 14cf11af6cf60 (Paul Mackerras 2005-09-26 16:04:21 +1000 236)                    goto bad_area;
>>> 
>>> So either they're both right or they're both wrong, either way I'm not
>>> sure how this patch is to blame.
>>
>> Is there any progress on resolving this?
>>
>> I did not notice any followup patch nor this one being merged/refuted.
>
> It ended up with this:
>
> https://lore.kernel.org/linuxppc-dev/20200703141327.1732550-2-mpe@ellerman.id.au/
>
>
> Which I was hoping would get some reviews :)

Ah, I missed this. I'll give it a look as soon as I can.

Kind regards,
Daniel

>
> I'll probably merge the whole series into next this week.
>
> cheers

      reply	other threads:[~2020-07-21  0:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11  1:43 [PATCH] powerpc/fault: kernel can extend a user process's stack Daniel Axtens
2019-12-11  6:14 ` Daniel Black
2019-12-11  7:28 ` Michal Suchánek
2019-12-11  9:37   ` Daniel Axtens
2020-07-20 10:51     ` Michal Suchánek
2020-07-20 13:52       ` Michael Ellerman
2020-07-21  0:57         ` Daniel Axtens [this message]

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=87k0yxu1kf.fsf@dja-thinkpad.axtens.net \
    --to=dja@axtens.net \
    --cc=daniel@linux.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=msuchanek@suse.de \
    --cc=tgl@sss.pgh.pa.us \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.