Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753081Ab2JNSWD (ORCPT ); Sun, 14 Oct 2012 14:22:03 -0400 Received: from mail-bk0-f46.google.com ([209.85.214.46]:54036 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752404Ab2JNSWB (ORCPT ); Sun, 14 Oct 2012 14:22:01 -0400 Message-ID: <507B02C1.1090101@gmail.com> Date: Sun, 14 Oct 2012 20:21:53 +0200 From: Daniel Mack User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: Al Viro CC: Linus Torvalds , Russell King - ARM Linux , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, "linux-arm-kernel@lists.infradead.org" Subject: Re: [revert request for commit 9fff2fa] Re: [git pull] signals pile 3 References: <20121013005334.GM2616@ZenIV.linux.org.uk> <507ADBBB.9090209@gmail.com> <20121014164020.GV2616@ZenIV.linux.org.uk> <20121014172640.GW2616@ZenIV.linux.org.uk> <20121014175541.GX2616@ZenIV.linux.org.uk> In-Reply-To: <20121014175541.GX2616@ZenIV.linux.org.uk> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5977 Lines: 116 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 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 has dependencies on that >>> sucker >>>> and while it survives testing here, it's obviously not ready for mainline. >>>> So, with abject apologies to everyone involved, please revert. >>> >>> Reverting it is not straight forward, and half of this patch doesn't seem >>> to cause issues. >>> >>> I can resend my patch with an S-o-b if you want me to. >> >> Um... That's _really_ interesting. First of all, revert is absolutely >> straightforward; the only change in Kconfig is "remove the damn select" >> and it's not hard to resolve. But I actually wonder what the hell is >> going on with that breakage - the *only* thing your revert changes is >> that instead of letting the kernel_thread callback return all the way >> to returning 0 to ret_from_kernel_thread() on do_execve() success you >> have it do ret_from_kernel_execve() instead. Hmm... >> >> Could you try to print current_pt_regs()->ARM_r0 in kernel_execve() before >> calling ret_from_kernel_execve() with your patch applied? If that somehow >> got non-zero, we'd see trouble, all right, but I don't see any places where >> it could. >> >> Wait a minute... I think I see what might be going on, but I don't >> understand it at all. Look: arm start_thread() is >> #define start_thread(regs,pc,sp) \ >> ({ \ >> unsigned long *stack = (unsigned long *)sp; \ >> memset(regs->uregs, 0, sizeof(regs->uregs)); \ >> if (current->personality & ADDR_LIMIT_32BIT) \ >> regs->ARM_cpsr = USR_MODE; \ >> else \ >> regs->ARM_cpsr = USR26_MODE; \ >> if (elf_hwcap & HWCAP_THUMB && pc & 1) \ >> regs->ARM_cpsr |= PSR_T_BIT; \ >> regs->ARM_cpsr |= PSR_ENDSTATE; \ >> regs->ARM_pc = pc & ~1; /* pc */ \ >> regs->ARM_sp = sp; /* sp */ \ >> regs->ARM_r2 = stack[2]; /* r2 (envp) */ \ >> regs->ARM_r1 = stack[1]; /* r1 (argv) */ \ >> regs->ARM_r0 = stack[0]; /* r0 (argc) */ \ >> nommu_start_thread(regs); \ >> }) >> 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 (it will be able to observe the values in those registers before >> the tracee reaches userland), but there's another oddity involved - "stack" >> is a userland pointer here. Granted, it's been recently written to, so >> we are not likely to hit a pagefault here, but... What happens if we are >> under enough memory pressure to swap those pages out? PF in the kernel >> mode with no exception table entries for those insns? > > FWIW, if you don't mind an experiment, try to take mainline (with that > commit not reverted) and add > strne r0, [sp, #S_R0] > right before > get_thread_info tsk > in ret_from_fork(). And see if that changes behaviour. > I don't mind experiments at all :) However, with that extra line in place as described, I'm still getting the Oops below. If you want me to test anything else, please let me know. [ 4.683182] VFS: Mounted root (nfs filesystem) on device 0:12. [ 4.742007] devtmpfs: mounted [ 4.745746] Freeing init memory: 172K [ 5.038724] Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2 [ 5.046044] Modules linked in: [ 5.049263] CPU: 0 Not tainted (3.6.0-11053-g56c8535-dirty #136) [ 5.055925] PC is at cpsw_probe+0x422/0x9ac [ 5.060314] LR is at trace_hardirqs_on_caller+0x8f/0xfc [ 5.065790] pc : [] lr : [] psr: 60000113 [ 5.065790] sp : cf055fb0 ip : 00000000 fp : 00000000 [ 5.077800] r10: 00000000 r9 : 00000000 r8 : 00000000 [ 5.083270] r7 : 00000000 r6 : 00000000 r5 : c034458d r4 : 00000000 [ 5.090101] r3 : cf057a40 r2 : 00000000 r1 : 00000001 r0 : 00000000 [ 5.096936] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 5.104406] Control: 50c5387d Table: 8f434019 DAC: 00000015 [ 5.110422] Process init (pid: 1, stack limit = 0xcf054240) [ 5.116257] Stack: (0xcf055fb0 to 0xcf056000) [ 5.120824] 5fa0: 00000001 00000000 00000000 00000000 [ 5.129390] 5fc0: cf055fb0 c000d1a8 00000000 00000000 00000000 00000000 00000000 00000000 [ 5.137957] 5fe0: 00000000 becedf10 00000000 b6f81dd0 00000010 00000000 aaaabfaf a8babbaa [ 5.146529] Code: 2206a010 718ef508 0184f8da f8b1f65d (3070f8d8) [ 5.152915] ---[ end trace 7362bbe8e73e6b07 ]--- [ 5.158324] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b [ 5.158324] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/