From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752161AbdEDJlZ (ORCPT ); Thu, 4 May 2017 05:41:25 -0400 Received: from mail-pf0-f195.google.com ([209.85.192.195]:35172 "EHLO mail-pf0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750865AbdEDJlS (ORCPT ); Thu, 4 May 2017 05:41:18 -0400 Date: Thu, 4 May 2017 18:41:09 +0900 From: Stafford Horne To: Lokesh Vutla Cc: LKML , Murali Karicheri , Al Viro Subject: Re: [BUG] OpenRISC exec init fails, bisected to 0886551 ("initramfs: finish fput() before accessing any binary from initramfs") Message-ID: <20170504094109.GC17317@lianli.shorne-pla.net> References: <20170504071118.GA17317@lianli.shorne-pla.net> <9860c33a-c940-6a63-3736-64f864b6d602@ti.com> <20170504083544.GB17317@lianli.shorne-pla.net> <5d0954d2-8383-45a8-3989-3dc204fe1dd6@ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d0954d2-8383-45a8-3989-3dc204fe1dd6@ti.com> User-Agent: Mutt/1.8.0 (2017-02-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 04, 2017 at 02:39:38PM +0530, Lokesh Vutla wrote: > > > On Thursday 04 May 2017 02:05 PM, Stafford Horne wrote: > > On Thu, May 04, 2017 at 01:15:23PM +0530, Lokesh Vutla wrote: > >> > >> > >> On Thursday 04 May 2017 12:41 PM, Stafford Horne wrote: > >>> Hello, > >>> > >>> While booting the v4.11 kernel I found the below issue. > >>> > >>> The summary of the issue mentions > >>> > >>> Commit 4a9d4b024a31 ("switch fput to task_work_add") implements a > >>> schedule_work() for completing fput(), but did not guarantee calling > >>> __fput() after unpacking initramfs. Because of this, there is a > >>> possibility that during boot a driver can see ETXTBSY when it tries to > >>> load a binary from initramfs as fput() is still pending on that binary. > >>> > >>> It seems this patch (0886551) introduces that issue though? > >>> > >>> I am looking into it, but any suggestions would be helpful. > >> > >> Can you check if flush_delayed_fput() is being called? Do you have > >> CONFIG_INITRAMFS_FORCE enabled? > > > > This is not enabled. I debugged it and I cant see it getting called. I > > see populate_rootfs getting called but initrd_start is 0, I think there is > > something different happening to unpack in initramfs since ours is compiled > > in. > > What about __initramfs_start, __initramfs_size? Those have the correct values. I think the problem is with openrisc's linker file. In there we have: __initrd_start = .; *(.initrd) __initrd_end = .; In setup_arch() we have: #ifdef CONFIG_BLK_DEV_INITRD initrd_start = (unsigned long)&__initrd_start; initrd_end = (unsigned long)&__initrd_end; if (initrd_start == initrd_end) { initrd_start = 0; initrd_end = 0; } initrd_below_start_ok = 1; #endif That doesnt work because there is nothing in .initrd and __initrd_start is the same as __initrd_end. The initramfs gets linked to the location of __initramfs_start, not __initrd_start. I am guessing the above is something very old. I think I just need to remove all of that __initrd_start/__initrd_end stuff. I'll try it out and send a patch later today or tomorrow. Not much time now. > > > > I am trying to look into it, but I need to relearn how the initramfs gets > > initted for OpenRISC. Perhaps the fix it going to keep the > > flush_delayed_fput() call in init/main.c. > > My initial version of the patch did not remove the call to > flush_delayed_fput() from init/main.c but Al Viro asked to drop it as it > is called in populate_rootfs(). > > May be Al Viro can give more data on what is happening here. Thanks, any comments or history lessons would be good here. -Stafford