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.
BOOT LOG
Compiled-in FDT at c03b9100
Linux version 4.10.0-10351-g0886551 (sho...@lianli.shorne-pla.net) (gcc
version 5.4.0 (GCC) ) #223 Thu May 4 16:01:02 JST 2017
CPU: OpenRISC-0 (revision 0) @20 MHz
...
Freeing unused kernel memory: 2856K
This architecture does not have kernel memory protection.
Failed to execute /init (error -26)
Starting init: /sbin/init exists but couldn't execute it (error -26)
Starting init: /bin/sh exists but couldn't execute it (error -26)
Kernel panic - not syncing: No working init found. Try passing init= option
to kernel. See Linux Documentation/admin-guide/init.rst for guidance.
---[ end Kernel panic - not syncing: No working init found. Try passing
init= option to kernel. See Linux Documentation/admin-guide/init.rst for
guidance.
TO REPRODUCE
The failure is intermittent.
Using some tools:
- initramfs: https://github.com/stffrdhrn/or1k-utils
- compiler: https://github.com/openrisc/or1k-gcc/releases
(or1k-linux-5.4.0-20170218.tar.xz)
- qemu: version 2.9
Make and run using:
make ARCH=openrisc defconfig
make -j5 ARCH=openrisc CROSS_COMPILE=or1k-linux- \
CONFIG_INITRAMFS_SOURCE="../openrisc/or1k-utils/initramfs
../openrisc/or1k-utils/initramfs.devnodes"
qemu-system-or1k -cpu or1200 -M or1k-sim -kernel vmlinux -serial stdio \
-nographic -monitor none
-Stafford
