Date: Thu, 26 Aug 1999 22:02:25 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: will@iki.fi (Ville-Pertti Keinonen) Cc: tlambert@primenet.com, wes@softweyr.com, hackers@FreeBSD.ORG Subject: Re: Mandatory locking? Message-ID: <199908262202.PAA09492@usr06.primenet.com> In-Reply-To: <19990826065947.19862.qmail@ns.oeno.com> from "Ville-Pertti Keinonen" at Aug 26, 99 06:59:47 am
next in thread | previous in thread | raw e-mail | index | archive | help
> I was assuming that mandatory locking, in the context of this > discussion, does not mean automatic, forced exclusion on open, but > rather explicit locks, applied by calls similar to those used for > advisory locking, that are enforced by the kernel. It's not mandatory, if it's not implicit. You can't enforce locks against processes that don't make lock calls, if it's not implicit. I think this has been the basis of your objection so far. If so, it's a fundamental misunderstanding of "mandatory". In this context it means that no program has the option of not participating in the locking protocol. > > Also, I believe your example is flawed. If a file is opened by a > > Not for explicit locking, I hope. By your definiton of explicit, no. However, explicit locking is voluntary, just as advisory locking is voluntary, in terms of whether programs participate (or not). This pretty much means that explicit locking degrades to advisory locking, in the presence of (un)intentionally non-participatory programs. Since we already have advisory locking, this case is not really interesting to consider. > So if a process wishes to use explicit locking calls, it indicates > that intent when opening the file - otherwise, the open implicitly > locks the file. So multiple writers, or simultaneous readers and > writers are only permitted for programs that indicate that they are > going to use explicit locks on the file. This is a case of "the excluded middle". It presumes, incorrectly, that there will always be at least one program engaged in explicit locking on a file to which explicit locking must be applied (the kernel can only enfoce exclusion of non-participating programs if it know that the file has explicit access semantices). This neglects the case of a file that requires these semantics, but which is not currently in use by a program which employs them. In that particular case, non-participating programs are (incorrectly) permitted access to the file. There are obscure ways around this. You could implement, for example, an access manager, and use file permissions to protect the file. Then you require all programs accessing the file to obtain the fd they will use via a transaction that results in an open, with the explicit locking semantics, which passes the resulting fd to the requesting program via descriptor passing. This is incredibly arcane, and doesn't work over a network (where descriptor passing won't work), but it's one method of turning explicit participation in a locking protocol into something useful. > > You have to have mandatory locking to implement transactions... > > like updating the parity bits on a RAID 5 stripe. > > But you certainly don't want to use open/read/write/close cycles for > such a purpose. No. Which is why you would want to implement mandatory participation in a range locking protocol, and prohibit reads and writes. This is somewhat defeated by FreeBSD's unified VM and buffer cache, in that you would have to disallow mmap() of such files, seperate the access semantics into a semantic VFS stacking layer with its own idea of backing store, or hack the VM to make the pages virtually unmapped -- that is, take read and write faults, and enforce the lock semantics at fault time. It's ugly, but it's useful. My gut tells me that software RAID 5 belongs in kernel space, or if in user space, requires a seperate VFS stacking layer to proxy the user space requests into kernel space, at the expense of explicit backing store and underlying object coherency. > > This is already possible, using O_EXCL. Likewise, it doesn't > > I think you mean O_EXLOCK. It sets an advisory lock, it does not help > against programs that don't use locks. Yes, for 4.4BSD, it's O_EXLOCK. For everything else, it's O_EXCL. > > apply to device files, and can not be applied (via fcntl(2)) to > > any files whose vnodes indirect through other than the vfsops > > version of "struct fileops". > > It doesn't depend on the struct fileops selected, fcntl checks > explicitly that f_type is DTYPE_VNODE before assuming that f_data > points to a vnode. The mechanics are irrelevant for the open call, which goes through the VFS to specfs for devices. It would be more relevant if we were talking about lock operations after the open. As shown above, though, these are not useful in the sense that mandatory locks are useful. > > For SVR4 semantics, you can set the suid/sgid permission bits on a > > non-executable file. > > The document describing "mandatory" locking in Linux seems to indicate > that setting sgid changes the behavior of locking calls to apply > explicit locks rather than merely advisory ones, and that this is what > is done by other operating systems as well. > > Actually an implementation could still use the existing (advisory) > locks internally, but apply advisory locks in the kernel for the > duration of operations that need them (read/write/some cases of open). This is really insufficient. The unified VM and buffer cache case makes this difficult. In an non-unified system, you would have the coherency code that you could use to enforce you semantics (at the expense of requiring the coherency to be synchronous to give immediate failure feedback at system call time). SVR4 has the coherency code which it can use for this. I imagine that the current Solaris 2.6 kernel code to handle this compatability case looks rather, uh, "insane". > > The act of opening the file for O_RDONLY sets a read lock on the > > entire file, which allows multiple readers, and the act of opening > > the file O_RDWR sets a write lock on the file, which allows a single > > writer. > > I'm fairly certain this is not what is being discussed. Certainly not > by more than half of the participants in the discussion. ;--) Heh. 8-). > > Again, there are no issues with badly behaved processes. There > > is no such thing as a badly behaved process. > > I agree, for implicit locks there isn't. I think this is what fit's Greg's bill the best: implict, forced participation in the locking protocol. It's also the only safe bet, if you have badly behaved processes, since explicit locking can fail, in that case. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908262202.PAA09492>