[systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf

[Zbigniew Jędrzejewski-Szmek]

On Thu, Apr 24, 2014 at 06:35:58AM +0200, Lennart Poettering wrote:
> On Thu, 24.04.14 02:47, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
> 
> > > Supporting less reliable operation modes for something that just needs
> > > to be configured in the kernel seems the wrong approach, especially
> > > when it involves filesystem operations on user data like tmpfiles
> > > does, we just depend on CONFIG_FHANDLE.
> > OK, what about this:
> > 
> > -------8<--------------------------------------------------------------
> > 
> >     udev: warn when name_to_handle_at is not implemented
> >     
> >     We have a bunch of reports from people who have a custom kernel and
> >     are confused why udev is not running. Issue a warning on
> >     error. Barring an error in the code, the only error that is possible
> >     is ENOSYS.
> >     
> >     https://bugzilla.redhat.com/show_bug.cgi?id=1072966
> > 
> > diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
> > index 0a2ab82..b9972c9 100644
> > --- a/src/libudev/libudev-monitor.c
> > +++ b/src/libudev/libudev-monitor.c
> > @@ -115,9 +115,11 @@ static bool udev_has_devtmpfs(struct udev *udev) {
> >          int r;
> >  
> >          r = name_to_handle_at(AT_FDCWD, "/dev", &h.handle, &mount_id, 0);
> > -        if (r < 0)
> > +        if (r < 0) {
> > +                if (errno != EOPNOTSUPP)
> > +                        udev_err(udev, "name_to_handle_at on /dev: %m\n");
> >                  return false;
> > -
> > +        }
> >  
> >          f = fopen("/proc/self/mountinfo", "re");
> >          if (!f)
> > 
> > -------8<--------------------------------------------------------------
> > 
> > Note that this makes missing name_to_handle_at behave similar to failing
> > socket(), etc, so seems to be in line with surrounding code.
> 
> Have you checked that EOPNOTSUPP is really the error that is returned by
> name_to_handle_at() if the kernel has the entire syscall disabled? Note
> that there are two different cases to distuingish here: a file system
> not supporting the operation, and the kernel not supporting the
> syscal...
It's warning on everything except EOPNOTSUPP. My reasoning is:

EOPNOTSUPP -> syscall supported, but wrong fs type, -> return false
ENOSYS -> syscall not supported -> warn and return false
any other error -> memory error or other major screw-up -> warn and return false

> Looking at path_is_mount_point() suggests ENOSYS is used? Or is that
> function checking for the wrong error code?

Zbyszek