On Tue 09-12-14 19:25:50, Yasuaki Ishimatsu wrote: > (2014/12/09 18:08), Michal Hocko wrote: [...] > >Doesn't udev retry the operation if it gets EBUSY or EAGAIN? > > It depend on implementation of udev.rules. So we can retry online/offline > operation in udev.rules. [...] # Memory hotadd request SUBSYSTEM=="memory", ACTION=="add", DEVPATH=="/devices/system/memory/memory*[0-9]", TEST=="/sys$devpath/state", RUN+="/bin/sh -c 'echo online > /sys$devpath/state'" OK so this is not prepared for a temporary failures and retries. > >And again, why cannot we simply make the onlining fail or try_lock and > >retry internally if the event consumer cannot cope with errors? > > Did you mean the following Srinivasan's first patch looks good to you? > https://lkml.org/lkml/2014/12/2/662 Heh, I was just about to post this. Because I haven't noticed the previous patch yet. Yeah, Something like that. Except that I would expect EAGAIN or EBUSY rather than ERESTARTSYS which should never leak into userspace. And that would happen here AFAICS because signal_pending will not be true usually. So there are two options. Either make the udev rule more robust and retry within RUN section or do the retry withing online_pages (try_lock and go into interruptible sleep which gets signaled by finished add_memory()). The later option is safer wrt. the userspace because the operation wouldn't fail unexpectedly. Another option would be generating the sysfs file after all the internal initialization is done and call it outside of the memory hotplug lock. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>