[linux-next:master] [fs] 51a146e059: BUG:kernel_hang_in_boot_stage

[linux-next:master] [fs] 51a146e059: BUG:kernel_hang_in_boot_stage

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]



Hello,


we don't have enough knowledge to analyze the connection between the issue and
this change. just observed the issue is quite persistent on 51a146e059 and
clean on its parent.


=========================================================================================
tbox_group/testcase/rootfs/kconfig/compiler/sleep:
  vm-snb-i386/boot/debian-11.1-i386-20220923.cgz/i386-randconfig-2006-20250804/gcc-14/1

d5bc4e31f2a3f301 51a146e0595c638c58097a1660f
---------------- ---------------------------
       fail:runs  %reproduction    fail:runs
           |             |             |
           :200        100%         200:200   last_state.booting
           :200        100%         200:200   last_state.is_incomplete_run
           :200        100%         200:200   dmesg.BUG:kernel_hang_in_boot_stage


we cannot spot out useful information from dmesg which is uploaded to [1]. also
attached one dmesg from parent commit (d5bc4e31f2) FYI.


kernel test robot noticed "BUG:kernel_hang_in_boot_stage" on:

commit: 51a146e0595c638c58097a1660ff6b6e7d3b72f3 ("fs: Remove internal old mount API code")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master

[test failed on linux-next/master cc3aa43b44bdb43dfbac0fcb51c56594a11338a8]

in testcase: boot

config: i386-randconfig-2006-20250804
compiler: gcc-14
test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G

(please refer to attached dmesg/kmsg for entire log/backtrace)



If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202512230315.1717476b-lkp@intel.com


[   15.178608][    T1] signal: max sigframe size: 1760
[   15.669386][    T1] rcu: Hierarchical SRCU implementation.
[   15.785114][    T1] rcu: 	Max phase no-delay instances is 1000.
[  104.130757][    C0] workqueue: round-robin CPU selection forced, expect performance impact
[  110.182304][    C0] random: crng init done
BUG: kernel hang in boot stage



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20251223/202512230315.1717476b-lkp@intel.com [1]



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki


[-- Attachment #2: dmesg-d5bc4e31f2.xz --]
[-- Type: application/x-xz, Size: 11712 bytes --]

Re: [linux-next:master] [fs] 51a146e059: BUG:kernel_hang_in_boot_stage

[Eric Sandeen]

On 12/22/25 8:36 PM, kernel test robot wrote:
> 
> 
> Hello,
> 
> 
> we don't have enough knowledge to analyze the connection between the issue and
> this change. just observed the issue is quite persistent on 51a146e059 and
> clean on its parent.

Odd. Not much to go on, and I don't see any obvious connection either, but
I'll see if i can reproduce.

In the successful dmesg it looks like devtmpfs was next up, maybe that's a clue.

This is probably a classic case of assuming that removing dead code
"can't break anything!" without enough testing. :( I'll see what I can find.

Thanks for the report,
-Eric

> 
> =========================================================================================
> tbox_group/testcase/rootfs/kconfig/compiler/sleep:
>   vm-snb-i386/boot/debian-11.1-i386-20220923.cgz/i386-randconfig-2006-20250804/gcc-14/1
> 
> d5bc4e31f2a3f301 51a146e0595c638c58097a1660f
> ---------------- ---------------------------
>        fail:runs  %reproduction    fail:runs
>            |             |             |
>            :200        100%         200:200   last_state.booting
>            :200        100%         200:200   last_state.is_incomplete_run
>            :200        100%         200:200   dmesg.BUG:kernel_hang_in_boot_stage
> 
> 
> we cannot spot out useful information from dmesg which is uploaded to [1]. also
> attached one dmesg from parent commit (d5bc4e31f2) FYI.
> 
> 
> kernel test robot noticed "BUG:kernel_hang_in_boot_stage" on:
> 
> commit: 51a146e0595c638c58097a1660ff6b6e7d3b72f3 ("fs: Remove internal old mount API code")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> 
> [test failed on linux-next/master cc3aa43b44bdb43dfbac0fcb51c56594a11338a8]
> 
> in testcase: boot
> 
> config: i386-randconfig-2006-20250804
> compiler: gcc-14
> test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> 
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202512230315.1717476b-lkp@intel.com
> 
> 
> [   15.178608][    T1] signal: max sigframe size: 1760
> [   15.669386][    T1] rcu: Hierarchical SRCU implementation.
> [   15.785114][    T1] rcu: 	Max phase no-delay instances is 1000.
> [  104.130757][    C0] workqueue: round-robin CPU selection forced, expect performance impact
> [  110.182304][    C0] random: crng init done
> BUG: kernel hang in boot stage
> 
> 
> 
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20251223/202512230315.1717476b-lkp@intel.com [1]
> 
> 
> 

Re: [linux-next:master] [fs] 51a146e059: BUG:kernel_hang_in_boot_stage

[Eric Sandeen]

On 12/26/25 2:01 PM, Eric Sandeen wrote:
> On 12/22/25 8:36 PM, kernel test robot wrote:
>>
>>
>> Hello,
>>
>>
>> we don't have enough knowledge to analyze the connection between the issue and
>> this change. just observed the issue is quite persistent on 51a146e059 and
>> clean on its parent.
> 
> Odd. Not much to go on, and I don't see any obvious connection either, but
> I'll see if i can reproduce.

I can more or less reproduce, I think, though I am not getting the hung task
warning.

Oddly if I just put the 

	struct dentry *(*mount) ...

member back in struct file_system_type it seems to resolve the problem.
Even if I give it a different symbol name (like mount_foo).

I'm confused.

-Eric