2011/5/2 Kai Blin <kai@xxxxxxxxx>: > Pavel Shilovsky <piastry@...> writes: > > Hi Pavel, > >> >> 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'm not sure I fully understand what problem you're trying to solve here. > The Wine server should take care of all the locking-related operations and make > sure the application process should have access to the file. I'm not familiar > with exactly how this happens, but I'm not sure how this would be any different > for CIFS-based file systems opposed to local file systems. I'm pretty sure it > works fine for local file systems. > > Can you elaborate what problem you're seeing that your patches fix? > > Cheers, > Kai > > PS: I'm not subscribed to this list, so please CC me :) > You are right - wineserver takes care about all these things if we work on local filesystem. But if we work on CIFS share the situation changes. When we negotiate mandatory locking style CIFS server compares pid of process who tries to do read/write with file with pid of byte-range lock (if one exists) on this area of the file. If pids don't match it fails operation. So, that's why I did this change - to do read and write operations with the pid of process who sets byte-range locks (wineserver). As the result, with this patch (I splited it into two) we do lock, write and read with the same pid and it works good. -- 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
