[Bug 214001] New: [bisected][regression] After commit "drm/ttm: Initialize debugfs from ttm_global_init()" kernels without debugfs explicitly set to 'allow all' fail to boot

[bugzilla-daemon at bugzilla.kernel.org]

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 at kernel-bugs.osdl.org
          Reporter: untaintableangel at hotmail.co.uk
        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 at jlekstrand.net>
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 at jlekstrand.net>
    Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
    Signed-off-by: Daniel Vetter <daniel.vetter at ffwll.ch>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20210721152358.2893314-6-jason@jlekstrand.net

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.