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
