On Mon, 2 May 2011 08:13:35 -0400 Jeff Layton <jlayton@xxxxxxxxx> wrote: > 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? One more question though... If I run multiple applications under wine, then do I get multiple wineserver programs? I assume not... If that's the case, then won't this change break locking between multiple wine applications that are operating on the same files? -- 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
