dev_coredumpm() creates a devcoredump device and adds it
to the core kernel framework which eventually end up
sending uevent to the user space and later creates a
symbolic link to the failed device. An application
running in userspace may be interested in this symbolic
link to get the name of the failed device.

In a issue scenario, once uevent sent to the user space
it start reading '/sys/class/devcoredump/devcdX/failing_device'
to get the actual name of the device which might not been
created and it is in its path of creation.

To fix this, suppress sending uevent till the failing device
symbolic link gets created and send uevent once symbolic
link is created successfully.

Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
---
 drivers/base/devcoredump.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c
index 91536ee05f14..7e2d1f0d903a 100644
--- a/drivers/base/devcoredump.c
+++ b/drivers/base/devcoredump.c
@@ -362,6 +362,7 @@ void dev_coredumpm(struct device *dev, struct module *owner,
 	devcd->devcd_dev.class = &devcd_class;
 
 	mutex_lock(&devcd->mutex);
+	dev_set_uevent_suppress(&devcd->devcd_dev, true);
 	if (device_add(&devcd->devcd_dev))
 		goto put_device;
 
@@ -376,6 +377,8 @@ void dev_coredumpm(struct device *dev, struct module *owner,
 		              "devcoredump"))
 		dev_warn(dev, "devcoredump create_link failed\n");
 
+	dev_set_uevent_suppress(&devcd->devcd_dev, false);
+	kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD);
 	INIT_DELAYED_WORK(&devcd->del_wk, devcd_del);
 	schedule_delayed_work(&devcd->del_wk, DEVCD_TIMEOUT);
 	mutex_unlock(&devcd->mutex);
-- 
2.7.4

On Mon, Nov 06, 2023 at 07:55:35PM +0530, Mukesh Ojha wrote:
> dev_coredumpm() creates a devcoredump device and adds it
> to the core kernel framework which eventually end up
> sending uevent to the user space and later creates a
> symbolic link to the failed device. An application
> running in userspace may be interested in this symbolic
> link to get the name of the failed device.
> 
> In a issue scenario, once uevent sent to the user space
> it start reading '/sys/class/devcoredump/devcdX/failing_device'
> to get the actual name of the device which might not been
> created and it is in its path of creation.
> 
> To fix this, suppress sending uevent till the failing device
> symbolic link gets created and send uevent once symbolic
> link is created successfully.
> 
> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>

What commit id does this fix?  What in-kernel driver does this affect
that is using devcoredump?

thanks,

greg k-h

On Mon, 2023-11-06 at 20:36 +0100, Greg KH wrote:
> On Mon, Nov 06, 2023 at 07:55:35PM +0530, Mukesh Ojha wrote:
> > dev_coredumpm() creates a devcoredump device and adds it
> > to the core kernel framework which eventually end up
> > sending uevent to the user space and later creates a
> > symbolic link to the failed device. An application
> > running in userspace may be interested in this symbolic
> > link to get the name of the failed device.
> > 
> > In a issue scenario, once uevent sent to the user space
> > it start reading '/sys/class/devcoredump/devcdX/failing_device'
> > to get the actual name of the device which might not been
> > created and it is in its path of creation.
> > 
> > To fix this, suppress sending uevent till the failing device
> > symbolic link gets created and send uevent once symbolic
> > link is created successfully.
> > 
> > Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
> 
> What commit id does this fix? 
> 

I guess the original introduction.

>  What in-kernel driver does this affect
> that is using devcoredump?
> 

All of them really, it's really about how fast userspace is to access it
after the event.

Looks fine to me, FWIW, but a Fixes tag wouldn't hurt.

johannes

On 11/7/2023 1:07 AM, Johannes Berg wrote:
> On Mon, 2023-11-06 at 20:36 +0100, Greg KH wrote:
>> On Mon, Nov 06, 2023 at 07:55:35PM +0530, Mukesh Ojha wrote:
>>> dev_coredumpm() creates a devcoredump device and adds it
>>> to the core kernel framework which eventually end up
>>> sending uevent to the user space and later creates a
>>> symbolic link to the failed device. An application
>>> running in userspace may be interested in this symbolic
>>> link to get the name of the failed device.
>>>
>>> In a issue scenario, once uevent sent to the user space
>>> it start reading '/sys/class/devcoredump/devcdX/failing_device'
>>> to get the actual name of the device which might not been
>>> created and it is in its path of creation.
>>>
>>> To fix this, suppress sending uevent till the failing device
>>> symbolic link gets created and send uevent once symbolic
>>> link is created successfully.
>>>
>>> Signed-off-by: Mukesh Ojha <quic_mojha@quicinc.com>
>>
>> What commit id does this fix?
>>
> 
> I guess the original introduction.
> 
>>   What in-kernel driver does this affect
>> that is using devcoredump?
>>
> 
> All of them really, it's really about how fast userspace is to access it
> after the event.
> 
> Looks fine to me, FWIW, but a Fixes tag wouldn't hurt.

Thanks, will add the Fixes tag.

-Mukesh
> 
> johannes