synchronization (or lack thereof) for uevents

synchronization (or lack thereof) for uevents

[goggin, edward]

Is it possible to ignore a hotplug event and deal only with the associated
uevent?

It seems that the asynchronous nature of uevents, (that is, they are sent to
a netlink
socket as datagrams -- therefore without a reply acknowledgement), makes it
difficult
to reliably act upon one when it is possible that multiple, related uevents,
which although
being sent later, may affect the servicing of the current one.

Ed Goggin


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: synchronization (or lack thereof) for uevents

[Kay Sievers]

On Mon, Oct 17, 2005 at 11:26:21AM -0400, goggin, edward wrote:
> Is it possible to ignore a hotplug event and deal only with the associated
> uevent?
> 
> It seems that the asynchronous nature of uevents, (that is, they are sent to
> a netlink
> socket as datagrams -- therefore without a reply acknowledgement), makes it
> difficult
> to reliably act upon one when it is possible that multiple, related uevents,
> which although
> being sent later, may affect the servicing of the current one.

I don't really get it. /sbin/hotplug events and netlink uevents are
carrying the same content and fired at the same time. Both have the same
SEQNUM and the same keys.
Netlink uevents are a complete replacement for /sbin/hotplug.

What would an ack for the uevent be good for. These events are sent to
the socket buffer and reliable as long as they fit into the buffer. The
current udev has a buffer of 16MB which can carry app. 50.000 events
if udevd is not reading anything.
udevd reads the events and excutes them in parallel anyway. This is
intentional and there is no need or it would make sense to serialize
events besides events for the same device or a child device still
running.

What is _exactly_ your problem?

Kay


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: synchronization (or lack thereof) for uevents

[Greg KH]

On Mon, Oct 17, 2005 at 11:26:21AM -0400, goggin, edward wrote:
> Is it possible to ignore a hotplug event and deal only with the associated
> uevent?

Yes, udevd does that today when we set /proc/kernel/sys/hotplug to NULL

> It seems that the asynchronous nature of uevents, (that is, they are sent to
> a netlink socket as datagrams -- therefore without a reply
> acknowledgement), makes it difficult to reliably act upon one when it
> is possible that multiple, related uevents, which although being sent
> later, may affect the servicing of the current one.

No, it seems to work quite well.  What problems are you having?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: synchronization (or lack thereof) for uevents

[goggin, edward]

Multipathd is trying to handle the uevents for removal of
multiple SCSI target LUNs for multiple targets.  Uevents
for each LUN for each of the multiple targets are being
generated concurrently.  Multiple uevents can be related
if they are for paths to the same SCSI logical unit.

It also appears that the code following the kobject_hotplug()
call in del_gendisk() has executed since when a uevent is
serviced, the call to kobject_del() has already deleted the
sysfs directory for the block device being removed.

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com] 
> Sent: Monday, October 17, 2005 9:28 PM
> To: goggin, edward
> Cc: 'linux-hotplug-devel@lists.sourceforge.net'
> Subject: Re: synchronization (or lack thereof) for uevents
> 
> On Mon, Oct 17, 2005 at 11:26:21AM -0400, goggin, edward wrote:
> > Is it possible to ignore a hotplug event and deal only with 
> the associated
> > uevent?
> 
> Yes, udevd does that today when we set 
> /proc/kernel/sys/hotplug to NULL
> 
> > It seems that the asynchronous nature of uevents, (that is, 
> they are sent to
> > a netlink socket as datagrams -- therefore without a reply
> > acknowledgement), makes it difficult to reliably act upon 
> one when it
> > is possible that multiple, related uevents, which although 
> being sent
> > later, may affect the servicing of the current one.
> 
> No, it seems to work quite well.  What problems are you having?
> 
> thanks,
> 
> greg k-h
> 


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: synchronization (or lack thereof) for uevents

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?


On Mon, Oct 17, 2005 at 09:53:20PM -0400, goggin, edward wrote:
> Multipathd is trying to handle the uevents for removal of
> multiple SCSI target LUNs for multiple targets.  Uevents
> for each LUN for each of the multiple targets are being
> generated concurrently.  Multiple uevents can be related
> if they are for paths to the same SCSI logical unit.

Then sort by that unit based on the sequence number like udevd does.

> It also appears that the code following the kobject_hotplug()
> call in del_gendisk() has executed since when a uevent is
> serviced, the call to kobject_del() has already deleted the
> sysfs directory for the block device being removed.

Yes, you get the event after the sysfs stuff is gone, how else could
that work?  :)

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: synchronization (or lack thereof) for uevents

[goggin, edward]

 

> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com] 
> Sent: Monday, October 17, 2005 10:33 PM
> To: goggin, edward
> Cc: 'linux-hotplug-devel@lists.sourceforge.net'
> Subject: Re: synchronization (or lack thereof) for uevents
> 
> 
> A: http://en.wikipedia.org/wiki/Top_post
> Q: Were do I find info about this thing called top-posting?
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
> 
> A: No.
> Q: Should I include quotations after my reply?
> 
> 
> On Mon, Oct 17, 2005 at 09:53:20PM -0400, goggin, edward wrote:
> > Multipathd is trying to handle the uevents for removal of
> > multiple SCSI target LUNs for multiple targets.  Uevents
> > for each LUN for each of the multiple targets are being
> > generated concurrently.  Multiple uevents can be related
> > if they are for paths to the same SCSI logical unit.
> 
> Then sort by that unit based on the sequence number like udevd does.
> 
> > It also appears that the code following the kobject_hotplug()
> > call in del_gendisk() has executed since when a uevent is
> > serviced, the call to kobject_del() has already deleted the
> > sysfs directory for the block device being removed.
> 
> Yes, you get the event after the sysfs stuff is gone, how else could
> that work?  :)

The kernel code is calling kobject_hotplug before calling kobject_del.
Doesn't this mean that the event is generated before the sysfs stuff
is gone?  It is only the fact that the event is queued in the receiver's
socket buffer before being serviced that causes the receiver to see the
sysfs stuff being gone by the time it gets to service the event.

> 
> thanks,
> 
> greg k-h
> 


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

RE: synchronization (or lack thereof) for uevents

[goggin, edward]

> -----Original Message-----
> From: Kay Sievers [mailto:kay.sievers@vrfy.org] 
> Sent: Monday, October 17, 2005 9:07 PM
> To: goggin, edward
> Cc: 'linux-hotplug-devel@lists.sourceforge.net'
> Subject: Re: synchronization (or lack thereof) for uevents
> 
> On Mon, Oct 17, 2005 at 11:26:21AM -0400, goggin, edward wrote:
> > Is it possible to ignore a hotplug event and deal only with 
> the associated
> > uevent?
> > 
> > It seems that the asynchronous nature of uevents, (that is, 
> they are sent to
> > a netlink
> > socket as datagrams -- therefore without a reply 
> acknowledgement), makes it
> > difficult
> > to reliably act upon one when it is possible that multiple, 
> related uevents,
> > which although
> > being sent later, may affect the servicing of the current one.
> 
> I don't really get it. /sbin/hotplug events and netlink uevents are
> carrying the same content and fired at the same time. Both 
> have the same
> SEQNUM and the same keys.
> Netlink uevents are a complete replacement for /sbin/hotplug.
> 

My bad.  I assumed that a hotplug event was handled as a request/reply
message sequence while a uevent was simply a one-way message queued in
a socket.

> What would an ack for the uevent be good for. These events are sent to
> the socket buffer and reliable as long as they fit into the 
> buffer. The
> current udev has a buffer of 16MB which can carry app. 50.000 events
> if udevd is not reading anything.
> udevd reads the events and excutes them in parallel anyway. This is
> intentional and there is no need or it would make sense to serialize
> events besides events for the same device or a child device still
> running.

Using the device mapper one can create mapped devices which are
comprised of multiple target devices.  There is nothing serializing
the events associated with the multiple target devices of the same
mapped device.

> 
> What is _exactly_ your problem?
> 
> Kay
> 


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: synchronization (or lack thereof) for uevents

[Greg KH]

On Mon, Oct 17, 2005 at 10:42:22PM -0400, goggin, edward wrote:
> > > It also appears that the code following the kobject_hotplug()
> > > call in del_gendisk() has executed since when a uevent is
> > > serviced, the call to kobject_del() has already deleted the
> > > sysfs directory for the block device being removed.
> > 
> > Yes, you get the event after the sysfs stuff is gone, how else could
> > that work?  :)
> 
> The kernel code is calling kobject_hotplug before calling kobject_del.

Yes, how else would it work?  kobject_del() destroys the data that
kobject_hotplug needs to work properly.

> Doesn't this mean that the event is generated before the sysfs stuff
> is gone?

By a few cycles, yes.

> It is only the fact that the event is queued in the receiver's
> socket buffer before being serviced that causes the receiver to see the
> sysfs stuff being gone by the time it gets to service the event.

No, same thing happens if you use the /sbin/hotplug call too.  Been this
way since we started generating hotplug remove events.

Is this a problem somehow?

thanks,

greg k-h


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel