From: Al Viro <viro@ZenIV.linux.org.uk>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Daniel Mack <zonque@gmail.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arch@vger.kernel.org" <linux-arch@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
Date: Mon, 15 Oct 2012 17:27:32 +0100 [thread overview]
Message-ID: <20121015162732.GG2616@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20121015160710.GC30907@arm.com>
On Mon, Oct 15, 2012 at 05:07:10PM +0100, Catalin Marinas wrote:
> On Sun, Oct 14, 2012 at 08:56:11PM +0100, Al Viro wrote:
> > On Sun, Oct 14, 2012 at 08:24:03PM +0100, Al Viro wrote:
> >
> > > Russell, could you recall what those had been about? I'm not sure if that
> > > had been oopsable that far back (again, oops scenario is userland stack
> > > page getting swapped out before we get to start_thread(), leading to
> > > direct read from an absent page in start_thread() by plain ldr, without
> > > anything in exception table about that insn), but it looks very odd
> > > regardless of that problem.
> >
> > BTW, arm64 has copied that logics, so it also seems to be unsafe and very
> > odd - there we definitely have only ELF to cope with. arm64 folks Cc'd...
>
> Good point. We don't need this on arm64 and probably neither on arm (at
> least since EABI).
>
> Setting x0 may cause other issues as well. The dynamic loader simply
> ignores the startup registers but for static binaries the _start code in
> glibc expects r0 to contain a function pointer to be registered with
> atexit() in __libc_start_main() or NULL. Since we pass argc in there,
> for static binaries the rtld_fini argument to __libc_start_main() is
> neither NULL nor something meaningful.
The value left there by start_thread() will not reach the userland anyway...
WARNING: multiple messages have this Message-ID (diff)
From: viro@ZenIV.linux.org.uk (Al Viro)
To: linux-arm-kernel@lists.infradead.org
Subject: [revert request for commit 9fff2fa] Re: [git pull] signals pile 3
Date: Mon, 15 Oct 2012 17:27:32 +0100 [thread overview]
Message-ID: <20121015162732.GG2616@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20121015160710.GC30907@arm.com>
On Mon, Oct 15, 2012 at 05:07:10PM +0100, Catalin Marinas wrote:
> On Sun, Oct 14, 2012 at 08:56:11PM +0100, Al Viro wrote:
> > On Sun, Oct 14, 2012 at 08:24:03PM +0100, Al Viro wrote:
> >
> > > Russell, could you recall what those had been about? I'm not sure if that
> > > had been oopsable that far back (again, oops scenario is userland stack
> > > page getting swapped out before we get to start_thread(), leading to
> > > direct read from an absent page in start_thread() by plain ldr, without
> > > anything in exception table about that insn), but it looks very odd
> > > regardless of that problem.
> >
> > BTW, arm64 has copied that logics, so it also seems to be unsafe and very
> > odd - there we definitely have only ELF to cope with. arm64 folks Cc'd...
>
> Good point. We don't need this on arm64 and probably neither on arm (at
> least since EABI).
>
> Setting x0 may cause other issues as well. The dynamic loader simply
> ignores the startup registers but for static binaries the _start code in
> glibc expects r0 to contain a function pointer to be registered with
> atexit() in __libc_start_main() or NULL. Since we pass argc in there,
> for static binaries the rtld_fini argument to __libc_start_main() is
> neither NULL nor something meaningful.
The value left there by start_thread() will not reach the userland anyway...
next prev parent reply other threads:[~2012-10-15 16:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-13 0:53 [git pull] signals pile 3 Al Viro
2012-10-14 15:35 ` Daniel Mack
2012-10-14 15:35 ` Daniel Mack
2012-10-14 16:40 ` [revert request for commit 9fff2fa] " Al Viro
2012-10-14 16:40 ` Al Viro
2012-10-14 16:44 ` Daniel Mack
2012-10-14 16:44 ` Daniel Mack
2012-10-14 17:26 ` Al Viro
2012-10-14 17:26 ` Al Viro
2012-10-14 17:55 ` Al Viro
2012-10-14 17:55 ` Al Viro
2012-10-14 18:21 ` Daniel Mack
2012-10-14 18:21 ` Daniel Mack
2012-10-14 19:06 ` Al Viro
2012-10-14 19:06 ` Al Viro
2012-10-14 19:24 ` Al Viro
2012-10-14 19:24 ` Al Viro
2012-10-14 19:56 ` Al Viro
2012-10-14 19:56 ` Al Viro
2012-10-15 16:07 ` Catalin Marinas
2012-10-15 16:07 ` Catalin Marinas
2012-10-15 16:27 ` Al Viro [this message]
2012-10-15 16:27 ` Al Viro
2012-10-15 17:06 ` Catalin Marinas
2012-10-15 17:06 ` Catalin Marinas
2012-10-14 20:24 ` Russell King - ARM Linux
2012-10-14 20:24 ` Russell King - ARM Linux
2012-10-14 22:24 ` Russell King - ARM Linux
2012-10-14 22:24 ` Russell King - ARM Linux
2012-10-14 22:39 ` Daniel Mack
2012-10-14 22:39 ` Daniel Mack
2012-10-14 23:16 ` Russell King - ARM Linux
2012-10-14 23:16 ` Russell King - ARM Linux
2012-10-16 14:04 ` Uwe Kleine-König
2012-10-16 14:04 ` Uwe Kleine-König
2012-10-16 14:05 ` Russell King - ARM Linux
2012-10-16 14:05 ` Russell King - ARM Linux
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=20121015162732.GG2616@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=catalin.marinas@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=torvalds@linux-foundation.org \
--cc=zonque@gmail.com \
/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.