* [PATCH] devcoredump: Send uevent once devcd is ready
@ 2023-11-06 14:25 Mukesh Ojha
2023-11-06 19:36 ` Greg KH
0 siblings, 1 reply; 4+ messages in thread
From: Mukesh Ojha @ 2023-11-06 14:25 UTC (permalink / raw)
To: johannes, gregkh, rafael; +Cc: linux-kernel, Mukesh Ojha
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] devcoredump: Send uevent once devcd is ready
2023-11-06 14:25 [PATCH] devcoredump: Send uevent once devcd is ready Mukesh Ojha
@ 2023-11-06 19:36 ` Greg KH
2023-11-06 19:37 ` Johannes Berg
0 siblings, 1 reply; 4+ messages in thread
From: Greg KH @ 2023-11-06 19:36 UTC (permalink / raw)
To: Mukesh Ojha; +Cc: johannes, rafael, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] devcoredump: Send uevent once devcd is ready
2023-11-06 19:36 ` Greg KH
@ 2023-11-06 19:37 ` Johannes Berg
2023-11-07 11:01 ` Mukesh Ojha
0 siblings, 1 reply; 4+ messages in thread
From: Johannes Berg @ 2023-11-06 19:37 UTC (permalink / raw)
To: Greg KH, Mukesh Ojha; +Cc: rafael, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] devcoredump: Send uevent once devcd is ready
2023-11-06 19:37 ` Johannes Berg
@ 2023-11-07 11:01 ` Mukesh Ojha
0 siblings, 0 replies; 4+ messages in thread
From: Mukesh Ojha @ 2023-11-07 11:01 UTC (permalink / raw)
To: Johannes Berg, Greg KH; +Cc: rafael, linux-kernel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-11-07 11:02 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-06 14:25 [PATCH] devcoredump: Send uevent once devcd is ready Mukesh Ojha
2023-11-06 19:36 ` Greg KH
2023-11-06 19:37 ` Johannes Berg
2023-11-07 11:01 ` Mukesh Ojha
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®