On Fri, 29 Apr 2011 18:41:54 +0400 Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > 2011/4/29 Jeff Layton <jlayton@xxxxxxxxxxxxxxx>: > > On Thu, 21 Apr 2011 17:26:35 +0400 > > Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote: > > > >> Add rwpidforward mount option that switches on a mode when we forward > >> pid of a process who opened a file to any read and write operation. > >> > >> This can prevent applications like WINE from failing on read or write > >> operation on a previously locked file region from the same netfd from > >> another process if we use mandatory brlock style. > >> It is actual for WINE because during a run of WINE program two processes > >> work on the same netfd - share the same file struct between several VFS > >> fds: > >> 1) WINE-server does open and lock; > >> 2) WINE-application does read and write. > >> > > > > I guess I still don't quite get it. Why not always forward the pid > > unconditionally? > > > > For wine, you want to forward the pid in order to emulate windows > > locking semantics. But always forwarding the pid seems like it would > > give you more unix-like semantics when locking unix applications, > > right? IOW, you'd be less likely to block in a read or write operation. > > > > Can you give an example of some use case that would break if you were > > to do this unconditionally? > > Ok. Let's predict: > 1) we negotiate mandatory locking semantic. > 2) we have a file opened my process 'A'. > 3) we do fork() - process 'B' is born and inherits a file. > 4) process 'A' set an exclusive lock on a file (from start to end) > 5) process 'B' write to a file and succeed if we forward pid > unconditionally in this case. - that's wrong according to mandatory > locking semantic > (http://msdn.microsoft.com/en-us/library/aa365202(v=vs.85).aspx) > > So, at least we don't need to forward pid if we negotiate Windows > locking style. As for POSIX - I think that is not affect anything > because we work with advisory locking style and don't care about such > things at all. So, that's why we need it as separate mount option that > switches specific behavior for application like WINE (or any other > client/server applications that send fd though a pipe or a socket and > use a client for i/o operations and a server - to open and lock). > Yuck. It's pretty icky that we have to have 2 separate sets of behavior here to work around a single application. I can't help but think that there must be a better way to do this. That said, I won't stand in the way of this patch if it's really the only option. Also, did you want to send a patch for the mount.cifs manpage to document this? Acked-by: Jeff Layton <jlayton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
