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? -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- 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
