Re: [PATCH] ovl: don't expose EOPENSTALE to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Amir Goldstein <amir73il@xxxxxxxxx>:
> There are more error that you can get same way that you got
> EOPENSTALE. The fact that I filtered EOPENSTALE is fixing a POSIX bug,
> but it does not fix the general problem you described.
>
> For example, I know you can get ENODEV, because I got it on
> out test env. This is the case of a "stale device node" - by the time
> you get to read an access event generated on a device file, the device
> that this file represents does not exists and cannot be opened.
>
> As with the case of EOPENSTALE, your app should just read again
> when that happens.

Thing is, I must treat every unknown error value as critical and exit.
That's because the problem might be persistent and spinning in a read
loop hangs the system.

Unless, of course, the system call API explicitly declares all problems
as transient and tells the application to retry indefinitely. ENODEV
certainly doesn't have the ring of a transient error.

I don't really see why read(2) on the fanotify fd should return any
random errors. The fanotify fd is purely a software device and should
only have a fixed, documented set of failure modes. The other file
descriptor (metadata->fd) is tied to a real file and could fail in a
million ways; that's understandable.


Marko

-- 
+358 44 990 4795
Skype: marko.rauhamaa_f-secure



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux