[systemd-devel] Antw: Re: how to debug kernel panic which generated by udevadm at systemd?

[Ulrich Windl]

>>> Mantas Mikulenas <grawity at gmail.com> schrieb am 15.10.2019 um 20:32 in
Nachricht
<CAPWNY8Whzf+G6AWBkHTLFAXUo=fRm_VtqO+i1tYt-yaobOCU8g at mail.gmail.com>:
> On Tue, Oct 15, 2019 at 3:02 PM www <ouyangxuan10 at 163.com> wrote:
> 
>> Dear all,
>>
>> I add a new driver to kernel, and it probe success. When enter into
>> systemd, the udevadm generate a kernel panic.
>> I want to ask how to debug it and find out where the error occurred? When
>> did udevadm load? What commands are used by udevadm, and what are the
>> specific operations?
>>
> 
> There aren't many udevadm calls in systemd... The main one is
> systemd-udev-trigger.service, which calls `udevadm trigger
> --type=subsystems --action=add`, then repeats the same for type=devices. It
> tries to generate coldplug uevents by writing 'add' to each found device's
> /sys/.../uevent file.

That's waht I guessed: The driver being loaded created siome udev event (with
probably invalid data in it), so when processing those, problems are
triggered.

I'm not arguing whether all thge components involved are robust enough (to
avoid a kernel panic), but is there a kind of "driver validation tool" (like
inserting the module, querying it's metedata, udev events, removing the module
again, etc.)?


Regards,
Ulrich

> 
> (The second is systemd-udev-settle.service, but it is disabled by default
> on most systems and just waits for udev's job queue to empty.)
> 
> -- 
> Mantas Mikulėnas