bug-hurd
[Top][All Lists]
Advanced

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

Re: [PATCH 1/6] libfshelp_rlock


From: Svante Signell
Subject: Re: [PATCH 1/6] libfshelp_rlock
Date: Tue, 20 Dec 2016 11:36:21 +0100

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]