Hi Greg & all,
I would like to add a new debugfs file like in the next patch but
I'm having a problem with commit 56348560d495 ("debugfs: do not
attempt to create a new file before the filesystem is initalized").
The problem is debugfs is initialized after the driver core, during
the core initcall, so I get an -ENOENT failure due to the above commit.
My first reaction is to move the ksysfs_init() and debugfs_init() calls
before the driver core init which works. Would that be ok?
An alternative would be to create the new debugfs file somewhere else
than the driver core, but I'm not sure where would be a good location,
maybe in debugfs_init()? Doesn't seem right.
Any guidance is appreciated, thank you,
Adrian
Adrian Ratiu (1):
drivers: base: Expose probe failures via debugfs
drivers/base/core.c | 76 +++++++++++++++++++++++++++++++++++++++++++--
lib/Kconfig.debug | 23 ++++++++++++++
2 files changed, 96 insertions(+), 3 deletions(-)
--
2.31.1
On Thu, Jun 03, 2021 at 03:55:33PM +0300, Adrian Ratiu wrote:
> Hi Greg & all,
>
> I would like to add a new debugfs file like in the next patch but
> I'm having a problem with commit 56348560d495 ("debugfs: do not
> attempt to create a new file before the filesystem is initalized").
You should have had a problem before that commit happened as well,
right?
>
> The problem is debugfs is initialized after the driver core, during
> the core initcall, so I get an -ENOENT failure due to the above commit.
>
> My first reaction is to move the ksysfs_init() and debugfs_init() calls
> before the driver core init which works. Would that be ok?
>
> An alternative would be to create the new debugfs file somewhere else
> than the driver core, but I'm not sure where would be a good location,
> maybe in debugfs_init()? Doesn't seem right.
I don't really want the driver core to be messing with debugfs at all,
why is that needed? I'll respond on your patch...
thanks,
greg k-h
Hi and thank you for the quick response!
On Thu, 03 Jun 2021, Greg Kroah-Hartman
<[email protected]> wrote:
> On Thu, Jun 03, 2021 at 03:55:33PM +0300, Adrian Ratiu wrote:
>> Hi Greg & all, I would like to add a new debugfs file like in
>> the next patch but I'm having a problem with commit
>> 56348560d495 ("debugfs: do not attempt to create a new file
>> before the filesystem is initalized").
>
> You should have had a problem before that commit happened as
> well, right?
>
Actually no, it works without problems before commit 56348560d495
and also works if I revert that commit or move the debugfs_init()
and its dependency ksysfs_init() before the driver core init.
All these 3 cases work without issues while testing, but none of
them seem to be viable ideas and especially moving debugfs init
earlier just to add this new attr file to the driver core is some
thin reasoning, so that's why I asked via this RFC. :)
>> The problem is debugfs is initialized after the driver core,
>> during the core initcall, so I get an -ENOENT failure due to
>> the above commit. My first reaction is to move the
>> ksysfs_init() and debugfs_init() calls before the driver core
>> init which works. Would that be ok? An alternative would be
>> to create the new debugfs file somewhere else than the driver
>> core, but I'm not sure where would be a good location, maybe in
>> debugfs_init()? Doesn't seem right.
>
> I don't really want the driver core to be messing with debugfs
> at all, why is that needed? I'll respond on your patch...
KernelCI maintainers asked me to add some tests for driver probe()
results similar to how the -EPROBE_DEFER is tested via the
existing debugfs devices_deferred and at the same time to add a
new debugfs interface similar to devices_deferred to avoid parsing
the printk buffer for non-EPROBE_DEFER results.
If you think adding such an interface is a bad idea, please just
tell me so and I will use it as amunition to push back and get the
info from printk. :)
>
> thanks,
>
> greg k-h
On Thu, Jun 03, 2021 at 11:00:00PM +0300, Adrian Ratiu wrote:
> Hi and thank you for the quick response!
>
> On Thu, 03 Jun 2021, Greg Kroah-Hartman <[email protected]> wrote:
> > On Thu, Jun 03, 2021 at 03:55:33PM +0300, Adrian Ratiu wrote:
> > > Hi Greg & all, I would like to add a new debugfs file like in the
> > > next patch but I'm having a problem with commit 56348560d495
> > > ("debugfs: do not attempt to create a new file before the filesystem
> > > is initalized").
> >
> > You should have had a problem before that commit happened as well,
> > right?
> >
>
> Actually no, it works without problems before commit 56348560d495 and also
> works if I revert that commit or move the debugfs_init() and its dependency
> ksysfs_init() before the driver core init.
And the file shows up properly? How can that be? Is it ok to create a
file before the superblock is created in the system? For some reason I
thought these were just silently failing and no one noticed. Maybe we
should revisit that commit...
thanks,
greg k-h
On Fri, 04 Jun 2021, Greg Kroah-Hartman
<[email protected]> wrote:
> On Thu, Jun 03, 2021 at 11:00:00PM +0300, Adrian Ratiu wrote:
>> Hi and thank you for the quick response! On Thu, 03 Jun 2021,
>> Greg Kroah-Hartman <[email protected]> wrote:
>> > On Thu, Jun 03, 2021 at 03:55:33PM +0300, Adrian Ratiu wrote:
>> > > Hi Greg & all, I would like to add a new debugfs file like
>> > > in the next patch but I'm having a problem with commit
>> > > 56348560d495 ("debugfs: do not attempt to create a new file
>> > > before the filesystem is initalized").
>> > You should have had a problem before that commit happened as
>> > well, right?
>> Actually no, it works without problems before commit
>> 56348560d495 and also works if I revert that commit or move the
>> debugfs_init() and its dependency ksysfs_init() before the
>> driver core init.
>
> And the file shows up properly? How can that be? Is it ok to
> create a file before the superblock is created in the system?
> For some reason I thought these were just silently failing and
> no one noticed. Maybe we should revisit that commit...
Yes the file shows up and works properly, but I do not know
why. My tests run after the system boots to an interactive shell
and by that time everything is initialized and working.
I thought maybe there were some specific corner-cases you wanted
to guard against by adding that initialization -ENOENT check, but
honestly since we're not adding a file earlier in the driver core
anymore, I'd just leave it as is because the check makes sense in
general.
Thanks again,
Adrian
>
> thanks,
>
> greg k-h