From: Al Viro <firstname.lastname@example.org> To: Michael Schmitz <email@example.com> Cc: firstname.lastname@example.org, Geert Uytterhoeven <email@example.com>, Greg Ungerer <firstname.lastname@example.org>, email@example.com 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: <firstname.lastname@example.org> 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.
next prev parent 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).