On Tue, Oct 16, 2012 at 04:04:14PM +0200, Uwe Kleine-König wrote:
> I used:
> movne r0, r4
> - movne lr, pc
> - movne pc, r5
> + blxne r5
> get_thread_info tsk
>
> but I assume Russell's patch is better. (Probably because blx doesn't
> exist everywhere?!)
Correct.
Hello,
On Mon, Oct 15, 2012 at 12:16:49AM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 15, 2012 at 12:39:40AM +0200, Daniel Mack wrote:
> > Tested-by: Daniel Mack
> >
> > Many thanks for the very prompt response!
>
> Thanks Daniel.
>
> I've also tested this on my OMAP4430 board
Hello,
On Mon, Oct 15, 2012 at 12:16:49AM +0100, Russell King - ARM Linux wrote:
On Mon, Oct 15, 2012 at 12:39:40AM +0200, Daniel Mack wrote:
Tested-by: Daniel Mack zon...@gmail.com
Many thanks for the very prompt response!
Thanks Daniel.
I've also tested this on my OMAP4430 board
On Tue, Oct 16, 2012 at 04:04:14PM +0200, Uwe Kleine-König wrote:
I used:
movne r0, r4
- movne lr, pc
- movne pc, r5
+ blxne r5
get_thread_info tsk
but I assume Russell's patch is better. (Probably because blx doesn't
exist everywhere?!)
Correct.
So if
On Mon, Oct 15, 2012 at 05:27:32PM +0100, Al Viro wrote:
> 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
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
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
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
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
On Mon, Oct 15, 2012 at 05:27:32PM +0100, Al Viro wrote:
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
On Mon, Oct 15, 2012 at 12:39:40AM +0200, Daniel Mack wrote:
> Tested-by: Daniel Mack
>
> Many thanks for the very prompt response!
Thanks Daniel.
I've also tested this on my OMAP4430 board running in ARM mode, so that
still works - we've covered the possibilities between us here between
ARM
On 15.10.2012 00:24, Russell King - ARM Linux wrote:
> Okay, here's the post-mortem diagnosis.
>
> What's happening is as follows (I'm very certain of this.)
>
> We come through the usual init, and issue (see init/main.c):
>
> kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
>
Okay, here's the post-mortem diagnosis.
What's happening is as follows (I'm very certain of this.)
We come through the usual init, and issue (see init/main.c):
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
This creates a new thread, which falls through to the
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> I rebased my ARM development branch and figured that your patch 9fff2fa
> ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
> board right after init is invoked via NFS:
Ok, I'm not going to assign blame to Al's
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
On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
> and the last 3 make no sense whatsoever. Note that on normal execve() we'll
> be going through the syscall return, so the userland will see 0 in there,
> no matter what do we do here. Theoretically, it might've been done for
> ptrace
On Sun, Oct 14, 2012 at 08:21:53PM +0200, Daniel Mack wrote:
> On 14.10.2012 19:55, Al Viro wrote:
> > On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
> >> On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
> >>> On Oct 14, 2012 6:40 PM, "Al Viro" wrote:
>
> On Sun,
On 14.10.2012 19:55, Al Viro wrote:
> On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
>> On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
>>> On Oct 14, 2012 6:40 PM, "Al Viro" wrote:
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> I rebased
On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
> On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
> > On Oct 14, 2012 6:40 PM, "Al Viro" wrote:
> > >
> > > On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> > >
> > > > I rebased my ARM development branch and
On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
> On Oct 14, 2012 6:40 PM, "Al Viro" wrote:
> >
> > On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> >
> > > I rebased my ARM development branch and figured that your patch 9fff2fa
> > > ("arm: switch to saner
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
> I rebased my ARM development branch and figured that your patch 9fff2fa
> ("arm: switch to saner kernel_execve() semantics") breaks the boot on my
> board right after init is invoked via NFS:
OK, revert it is, then. Nothing in the
Hi Al,
On 13.10.2012 02:53, Al Viro wrote:
> The last bits of infrastructure for kernel_thread() et.al., with alpha/arm/x86
> use of those. Plus sanitizing the asm glue and do_notify_resume() on alpha,
> fixing the "disabled irq while running task_work stuff" breakage there.
>
> At that point
Hi Al,
On 13.10.2012 02:53, Al Viro wrote:
The last bits of infrastructure for kernel_thread() et.al., with alpha/arm/x86
use of those. Plus sanitizing the asm glue and do_notify_resume() on alpha,
fixing the disabled irq while running task_work stuff breakage there.
At that point the rest
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
I rebased my ARM development branch and figured that your patch 9fff2fa
(arm: switch to saner kernel_execve() semantics) breaks the boot on my
board right after init is invoked via NFS:
OK, revert it is, then. Nothing in the tree
On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
On Oct 14, 2012 6:40 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
I rebased my ARM development branch and figured that your patch 9fff2fa
(arm: switch to saner
On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
On Oct 14, 2012 6:40 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
I rebased my ARM development branch and
On 14.10.2012 19:55, Al Viro wrote:
On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
On Oct 14, 2012 6:40 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
I rebased my
On Sun, Oct 14, 2012 at 08:21:53PM +0200, Daniel Mack wrote:
On 14.10.2012 19:55, Al Viro wrote:
On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
On Sun, Oct 14, 2012 at 06:44:12PM +0200, Daniel Mack wrote:
On Oct 14, 2012 6:40 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Sun,
On Sun, Oct 14, 2012 at 06:26:40PM +0100, Al Viro wrote:
and the last 3 make no sense whatsoever. Note that on normal execve() we'll
be going through the syscall return, so the userland will see 0 in there,
no matter what do we do here. Theoretically, it might've been done for
ptrace sake
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
On Sun, Oct 14, 2012 at 05:35:23PM +0200, Daniel Mack wrote:
I rebased my ARM development branch and figured that your patch 9fff2fa
(arm: switch to saner kernel_execve() semantics) breaks the boot on my
board right after init is invoked via NFS:
Ok, I'm not going to assign blame to Al's
Okay, here's the post-mortem diagnosis.
What's happening is as follows (I'm very certain of this.)
We come through the usual init, and issue (see init/main.c):
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
This creates a new thread, which falls through to the
On 15.10.2012 00:24, Russell King - ARM Linux wrote:
Okay, here's the post-mortem diagnosis.
What's happening is as follows (I'm very certain of this.)
We come through the usual init, and issue (see init/main.c):
kernel_thread(kernel_init, NULL, CLONE_FS | CLONE_SIGHAND);
This
On Mon, Oct 15, 2012 at 12:39:40AM +0200, Daniel Mack wrote:
Tested-by: Daniel Mack zon...@gmail.com
Many thanks for the very prompt response!
Thanks Daniel.
I've also tested this on my OMAP4430 board running in ARM mode, so that
still works - we've covered the possibilities between us here
The last bits of infrastructure for kernel_thread() et.al., with alpha/arm/x86
use of those. Plus sanitizing the asm glue and do_notify_resume() on alpha,
fixing the "disabled irq while running task_work stuff" breakage there.
At that point the rest of kernel_thread/kernel_execve/sys_execve work
The last bits of infrastructure for kernel_thread() et.al., with alpha/arm/x86
use of those. Plus sanitizing the asm glue and do_notify_resume() on alpha,
fixing the disabled irq while running task_work stuff breakage there.
At that point the rest of kernel_thread/kernel_execve/sys_execve work
36 matches
Mail list logo
