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). -- Best regards, Pavel Shilovsky. -- 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
