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:

quoted

quoted

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@fromorbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html