2011/5/2 Jeff Layton <jlayton@xxxxxxxxx>: > 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 > Yes, as soon as these patches are applied, I will provide a patch for manpage! -- 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
