On Tue, 2016-12-20 at 02:03 +0100, Samuel Thibault wrote:
> Hello,
>
> Svante Signell, on Mon 19 Dec 2016 18:25:58 +0100, wrote:
> > It seems like the open mode for /dev/null does not contain O_READ/O_WRITE
> > flags
>
> ? It does, see cred->po->openmodes.
Seems to be a difference between libdiskfs/libnetfs and libtrivfs:
diskfs.h/netfs.h:
struct protid
{
...
struct peropen *po;
...
}
struct peropen
{
...
int openstat;
...
};
trivfs.h:
struct trivfs_protid
{
...
struct trivfs_peropen *po;
};
struct trivfs_peropen
{
...
int openmodes;
...
};
The variable open_modes I mentioned in that mail is taken from
libdiskfs/libnetfs:
int open_mode = cred->po->openstat;
if ((open_mode & O_RDONLY) && !(open_mode & O_WRONLY)) open_mode |= O_WRONLY;
etc.
That open_mode, flags in libdiskfs/file-lock.c(diskfs_S_file_lock),
libnetfs/file-lock.c(netfs_S_file_lock) does not contain O_READ or O_WRITE for
/dev/null. That's what I reported in that mail. Why don't you believe me?
Here is an output snippet from rpctrace test_flock /dev/null:
111<--143(pid1852)->dir_lookup ("dev/null" 17 384) = 0 1 "" 159<
--158(pid1852)
159<--158(pid1852)->term_getctty () = 0xfffffed1 ((ipc/mig) bad request
message ID)
157<--156(pid1852)->io_write ("test_flock: file=/dev/null \n" -1)test_flock:
file=/dev/null
= 0 28
157<--156(pid1852)->io_write ("Requesting a shared lock: LOCK_SH: "
-1)Requesting a shared lock: LOCK_SH: = 0 35
159<--158(pid1852)->file_lock (1) = 0x4000000d (Permission denied)
It works for a regular file.
> > making flock tests as well as fcntl tests fail, when proxied through
> > libtrivfs/file-lock.c (trivfs_S_file_lock).
>
> Well, do we really want to support locks on /dev/null? Neal's
> implementation proxies the support to the realnode when there is one
> (null doesn't have one), I don't think we want to achieve more than
> this.
How come things work when I remove the conditions then, both for Case i) and
ii)? Which code path is taken when as you say /dev/null does not have a
realnode? BTW: This /dev/null test came about after your test case
in Bug#759008: libtdb1.
How do you know if there is a realnode behind? Note: I'm still on the learning
curve, and this is maybe not part of the basic course :D
BTW: I had written a different solution for libtrivfs, but was strongly
recommended by Justus to use the proxy fallback solution, as implemented now.
> > Any advice given here is appreciated. Maybe the special devices, should be
> > opened with modes similar to regular files?
>
> We don't care about null. We may want to care about e.g. locking
> /dev/com0, but I don't think applications actually hope that this is
> portable at all, so I don't think we want to care, and just get the
> implementation in for regular files at last.
OK, let's forget about locking device files then.
