https://bugzilla.kernel.org/show_bug.cgi?id=214001 Bug ID: 214001 Summary: [bisected][regression] After commit "drm/ttm: Initialize debugfs from ttm_global_init()" kernels without debugfs explicitly set to 'allow all' fail to boot Product: Drivers Version: 2.5 Kernel Version: 5.14-rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@xxxxxxxxxxxxxxxxxxxx Reporter: untaintableangel@xxxxxxxxxxxxx Regression: No So this is an interesting one. Problem: System hangs indefinitely/refuses to boot up. 5.14rc3 was totally fine but rc4 has the problem and I've bisected the commit to: 69de4421bb4c103ef42a32bafc596e23918c106f is the first bad commit commit 69de4421bb4c103ef42a32bafc596e23918c106f Author: Jason Ekstrand <jason@xxxxxxxxxxxxxx> Date: Wed Jul 21 10:23:57 2021 -0500 drm/ttm: Initialize debugfs from ttm_global_init() We create a bunch of debugfs entries as a side-effect of ttm_global_init() and then never clean them up. This isn't usually a problem because we free the whole debugfs directory on module unload. However, if the global reference count ever goes to zero and then ttm_global_init() is called again, we'll re-create those debugfs entries and debugfs will complain in dmesg that we're creating entries that already exist. This patch fixes this problem by changing the lifetime of the whole TTM debugfs directory to match that of the TTM global state. Signed-off-by: Jason Ekstrand <jason@xxxxxxxxxxxxxx> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx> Link: https://patchwork.freedesktop.org/patch/msgid/20210721152358.2893314-6-jason@xxxxxxxxxxxxxx I then tried loading an ubuntu mainline kernel for 5.14-rc4 and that was fine too, which meant my .config was to blame in conjunction with the change. The specific issue narrowed down to not having debug_fs enabled in my kernel (CONFIG_DEBUG_FS is not set) Now I've not had debugfs enabled for many, many years (is this even necessary on a kernel on which the user makes no use of the information it provides?) and now I see the option CONFIG_DEBUG_FS=y allows for one of three exclusive options. (CONFIG_DEBUG_FS_ALLOW_ALL; CONFIG_DEBUG_FS_DISALLOW_MOUNT and CONFIG_DEBUG_FS_ALLOW_NONE) (*Moving forward, is debug_fs now a critical component of the linux kernel and required to be enabled (CONFIG_DEBUG_FS=Y) with a minimum of the 3rd option of 'allow none' given that so many things want to make use of it? Is debugfs 'expected' to be there to make reference to in driver code from now on?) At any rate, I tested each of the 3 options and can confirm that since the commit in question, the system will _only_ boot now if: CONFIG_DEBUG_FS_ALLOW_ALL=y I suspect that the commit did not account for kernel compilers who don't have debugfs at all - however, it even causes boot issues if debugfs is present but minimalised because neither: CONFIG_DEBUG_FS_DISALLOW_MOUNT "The API is open but filesystem is not loaded. Clients can still do their work and read with debug tools that do not need debugfs filesystem." nor CONFIG_DEBUG_FS_ALLOW_NONE: "Access is off. Clients get -PERM when trying to create nodes in debugfs tree and debugfs is not registered as a filesystem. Client can then back-off or continue without debugfs access." are sufficient to get a successful boot after this commit. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
