linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Michael Schmitz <schmitzmic@gmail.com>
Cc: linux-m68k@lists.linux-m68k.org,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Greg Ungerer <gerg@linux-m68k.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/3] m68k: leave stack mangling to asm wrapper of sigreturn()
Date: Thu, 16 Sep 2021 03:21:21 +0000	[thread overview]
Message-ID: <YUK4MWzI73lwRq0W@zeniv-ca.linux.org.uk> (raw)
In-Reply-To: <48dafad1-4f0c-4ab7-792c-b34a81d26799@gmail.com>

On Thu, Sep 16, 2021 at 12:53:53PM +1200, Michael Schmitz wrote:
> > You'd need to
> > 	* load the frame type from sigcontext (and deal with EFAULT, etc.)
> > 	* make decision based on that
> > 	* pass the type down into sigreturn(), so we wouldn't run into
> > mismatches.
> > 
> > And all that just to avoid a single "subtract a constant from stack pointer"
> > insn.  We are on a very shallow kernel stack here - it's a syscall entry,
> > after all.  And the stack footprint of do_sigreturn() is fairly small - e.g.
> > stat(2) eats a lot more.
> 
> Thanks, that's what I was wondering. Not worth the extra complexity then.
> 
> > 
> > We are not initializing the gap either - it's just reserved on stack; we only
> > access it if we need to enlarge the stack frame.
> > 
> > IOW, what would be the benefit of trying to avoid unconditional gap there?
> 
> Avoiding a kernel stack overflow - there are comments in the code that warn
> against that, but those may be largely historic...

This is syscall entry; moreover, it critically relies upon the fixed stack
layout - type 0 exception frame + pt_regs + switch_stack + (now) gap.
Followed by fairly shallow C call chain.  I suspect that the deepest you
can get there is when you get an unmapped page when reading the sigframe
and go into page fault handling, with call chain going into some filesystem's
->readpage().  If it was that close to stack overflow, we'd see them all
the time in e.g. random net ioctl doing copy_from_user() - that's going
to be deeper.  Or in stat(2), for that matter.

  reply	other threads:[~2021-09-16  3:21 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-25 17:18 [RFC][CFT] signal handling fixes Al Viro
2021-07-25 17:19 ` [PATCH 1/3] m68k: handle arrivals of multiple signals correctly Al Viro
2021-09-15 22:08   ` Michael Schmitz
2021-07-25 17:19 ` [PATCH 2/3] m68k: update ->thread.esp0 before calling syscall_trace() in ret_from_signal Al Viro
2021-09-15 22:19   ` Michael Schmitz
2021-07-25 17:20 ` [PATCH 3/3] m68k: leave stack mangling to asm wrapper of sigreturn() Al Viro
2021-09-15 23:35   ` Michael Schmitz
2021-09-16  0:19     ` Al Viro
2021-09-16  0:53       ` Michael Schmitz
2021-09-16  3:21         ` Al Viro [this message]
2021-09-16  5:02           ` Michael Schmitz
2021-09-16 16:14             ` Al Viro
2021-07-27 10:21 ` [RFC][CFT] signal handling fixes Finn Thain
2021-07-27 14:42   ` Al Viro
2021-07-28  1:23     ` Finn Thain
2021-08-11  1:42     ` Finn Thain
2021-09-16  9:03 ` Finn Thain
2021-09-23 14:43   ` Geert Uytterhoeven
2021-09-23 14:45 ` Geert Uytterhoeven

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=YUK4MWzI73lwRq0W@zeniv-ca.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=geert@linux-m68k.org \
    --cc=gerg@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@lists.linux-m68k.org \
    --cc=schmitzmic@gmail.com \
    --subject='Re: [PATCH 3/3] m68k: leave stack mangling to asm wrapper of sigreturn()' \
    /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

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).