On Fri, Sep 08, 2017 at 10:49:05AM +1000, Dave Chinner wrote: > On Thu, Sep 07, 2017 at 04:56:56PM +0800, Hou Tao wrote: > > > Note that kobject_uevent_env() can also fail during > > > netlink_broadcast_filtered(), so perhaps we should consider all errors well > > > here. > > Yes, to deliver the uevent reliably we need to handle the error returned by > > kobject_uevent_evn(), and abort the filesystem mount if any error occurs. > > Failing to delivery a mount uevent is not a fatal error. An > inconvenience, yes, but it does not prevent the filesystem from > operating. We do not consider errors when other user events we push to > userspace through netlink fail (e.g. quota warnings), so I don't see > why we should treat this any differently, especially as a user can > still configure the filesystem as they need without the mount > uevent... I agree with Dave that it seems excessive to fail the mount just because the uevent transmission failed. I don't see any use case where it's absolutely critical that a configuration knob gets turned. I would also reiterate that I want to see at least an RFC of the userland side of this because I'd rather not have to maintain a kernel feature that is totally unused by upstream userspace. --D > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
