Milan Broz <mbroz@xxxxxxxxxx> writes: > On 08/19/2011 11:13 AM, Eric W. Biederman wrote: >> Milan Broz <mbroz@xxxxxxxxxx> writes: >> >> I think the proper fix is to remove the error return from >> kobject_uevent_env and kobject_uevent, and make it harder to get calling >> of this function wrong. Possibly in conjunction with that tag all of >> the memory allocations of kobject_uevent_env with GFP_NOFAIL or >> something so the memory allocator knows that this path is totally >> not able to deal with failure. >> >> Is kobject_uevent_env anything except an asynchronous best effort >> notification to user-space that a device has come or gone? > > Unfortunately it is for device-mapper. libdevmapper > depends on information that uevent was sent because udev rules uses > semaphore to inform that some action was taken. > So if dm-ioctl returns flag that uevent was not sent, it fallback > to different error path (otherwise it waits for completion forever). > (TBH I am more and more convinced this was not quite clever concept.) If I understand your description and the code right the guarantee that you need is that kobject_uevent will return success only if it has queued a packet in every listening netlink socket. We already ignore ENOBUFS so the guarantee you appear to need in libdevmapper does not appear to be present in kobject_uevent. Does the libdevmapper code work despite getting a spurious failure? If libdevmapper does not work despite a spurious failure I don't see how we could possibly fix kobject_uevent when there is more than one netlink listener. Eric -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
