On Tue, Jun 15, 2021 at 12:03:26PM -0700, Siddharth Gupta wrote:I am not fully aware of when devtmpfs is enabled or not, but in
On 6/14/2021 9:56 PM, Greg KH wrote:It isn't an issue of systemd/ueventd, those do not control /dev on a
On Mon, Jun 14, 2021 at 07:21:08PM -0700, Siddharth Gupta wrote:My testing was done with toybox + Android's ueventd ramdisk.
When cdev_add is called after device_add has been called there is noSo this means no one ever ran this code on a system that used devtmpfs?
way for the userspace to know about the addition of a cdev as cdev_add
itself doesn't trigger a uevent notification, or for the kernel to
know about the change to devt. This results in two problems:
- mknod is never called for the cdev and hence no cdev appears on
devtmpfs.
- sysfs links to the new cdev are not established.
The cdev needs to be added and devt assigned before device_add() is
called in order for the relevant sysfs and devtmpfs entries to be
created and the uevent to be properly populated.
How was it ever tested?
As I mentioned in the discussion, the race became evident
recently. I will make sure to test all such changes without
systemd/ueventd in the future.
normal system, that is what devtmpfs is for.
I am not sure of what you mean by a static /dev? Could you
And devtmpfs nodes are only created if you create a struct device
somewhere with a proper major/minor, which you were not doing here, so
you must have had a static /dev on your test systems, right?
thanks,
greg k-h