February 2013 - Wine-Devel - list.winehq.org

Re: [PATCH v2 3/8] vfs: Add O_DENYREAD/WRITE flags support for open syscall

by J. Bruce Fields

On Tue, Feb 05, 2013 at 03:45:31PM +0400, Pavel Shilovsky wrote: > 2013/1/31 J. Bruce Fields <bfields(a)fieldses.org>: > > On Thu, Jan 17, 2013 at 08:52:59PM +0400, Pavel Shilovsky wrote: > >> If O_DENYMAND flag is specified, O_DENYREAD/WRITE/MAND flags are > >> translated to flock's flags: > >> > >> !O_DENYREAD -> LOCK_READ > >> !O_DENYWRITE -> LOCK_WRITE > >> O_DENYMAND -> LOCK_MAND > >> > >> and set through flock_lock_file on a file. > >> > >> This change only affects opens that use O_DENYMAND flag - all other > >> native Linux opens don't care about these flags. It allow us to > >> enable this feature for applications that need it (e.g. NFS and > >> Samba servers that export the same directory for Windows clients, > >> or Wine applications that access the same files simultaneously). > > > > The use of an is_conflict callback seems unnecessarily convoluted. > > > > If we need two different behaviors, let's just use another flag (or an > > extra boolean argument if we need to, or something). > > Ok, we can pass "bool is_mand" to flock_lock_file that will pass it > further to flock_locks_conflict. > > > > > The only caller for this new deny_lock_file is in the nfs code--I'm a > > little unclear why that is. > > deny_lock_file is called not only in the nfs code but also in 2 places > of fs/namei.c -- that enable this logic for VFS. Oops, apologies, I overlooked those somehow. What prevents somebody else from grabbing a lock on a newly-created file before we grab our own lock? I couldn't tell on a quick look whether we hold some lock that prevents that. --b.

Feb. 5, 2013

Re: [PATCH v2 4/8] CIFS: Add O_DENY* open flags support

by Pavel Shilovsky

2013/1/31 J. Bruce Fields <bfields(a)fieldses.org>: > On Thu, Jan 17, 2013 at 08:53:00PM +0400, Pavel Shilovsky wrote: >> Make CIFSSMBOpen take share_flags as a parm that allows us >> to pass new O_DENY* flags to the server. >> >> Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> >> --- >> fs/cifs/cifsacl.c | 10 ++++++---- >> fs/cifs/cifsglob.h | 12 +++++++++++- >> fs/cifs/cifsproto.h | 9 +++++---- >> fs/cifs/cifssmb.c | 47 +++++++++++++++++++++++++---------------------- >> fs/cifs/dir.c | 13 ++++++++----- >> fs/cifs/file.c | 12 ++++++++---- >> fs/cifs/inode.c | 11 ++++++----- >> fs/cifs/link.c | 10 +++++----- >> fs/cifs/readdir.c | 2 +- >> fs/cifs/smb1ops.c | 15 ++++++++------- >> fs/cifs/smb2file.c | 10 +++++----- >> fs/cifs/smb2inode.c | 4 ++-- >> fs/cifs/smb2ops.c | 10 ++++++---- >> fs/cifs/smb2pdu.c | 6 +++--- >> fs/cifs/smb2proto.h | 14 ++++++++------ >> 15 files changed, 107 insertions(+), 78 deletions(-) >> >> diff --git a/fs/cifs/cifsacl.c b/fs/cifs/cifsacl.c >> index 0fb15bb..a42c77f 100644 >> --- a/fs/cifs/cifsacl.c >> +++ b/fs/cifs/cifsacl.c >> @@ -1184,8 +1184,9 @@ static struct cifs_ntsd *get_cifs_acl_by_path(struct cifs_sb_info *cifs_sb, >> create_options |= CREATE_OPEN_BACKUP_INTENT; >> >> rc = CIFSSMBOpen(xid, tcon, path, FILE_OPEN, READ_CONTROL, >> - create_options, &fid, &oplock, NULL, cifs_sb->local_nls, >> - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); >> + FILE_SHARE_ALL, create_options, &fid, &oplock, >> + NULL, cifs_sb->local_nls, >> + cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); >> if (!rc) { >> rc = CIFSSMBGetCIFSACL(xid, tcon, fid, &pntsd, pacllen); >> CIFSSMBClose(xid, tcon, fid); >> @@ -1245,8 +1246,9 @@ int set_cifs_acl(struct cifs_ntsd *pnntsd, __u32 acllen, >> access_flags = WRITE_DAC; >> >> rc = CIFSSMBOpen(xid, tcon, path, FILE_OPEN, access_flags, >> - create_options, &fid, &oplock, NULL, cifs_sb->local_nls, >> - cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); >> + FILE_SHARE_ALL, create_options, &fid, &oplock, >> + NULL, cifs_sb->local_nls, >> + cifs_sb->mnt_cifs_flags & CIFS_MOUNT_MAP_SPECIAL_CHR); > > It would be easier to tell what you changed in the above two chunks if > you didn't change the whitespace at the same time. > > --b. Ok, thank - will fix it in the further version of the patch. -- Best regards, Pavel Shilovsky.

Feb. 5, 2013

Re: [PATCH v2 3/8] vfs: Add O_DENYREAD/WRITE flags support for open syscall

by Pavel Shilovsky

2013/1/31 J. Bruce Fields <bfields(a)fieldses.org>: > On Thu, Jan 17, 2013 at 08:52:59PM +0400, Pavel Shilovsky wrote: >> If O_DENYMAND flag is specified, O_DENYREAD/WRITE/MAND flags are >> translated to flock's flags: >> >> !O_DENYREAD -> LOCK_READ >> !O_DENYWRITE -> LOCK_WRITE >> O_DENYMAND -> LOCK_MAND >> >> and set through flock_lock_file on a file. >> >> This change only affects opens that use O_DENYMAND flag - all other >> native Linux opens don't care about these flags. It allow us to >> enable this feature for applications that need it (e.g. NFS and >> Samba servers that export the same directory for Windows clients, >> or Wine applications that access the same files simultaneously). > > The use of an is_conflict callback seems unnecessarily convoluted. > > If we need two different behaviors, let's just use another flag (or an > extra boolean argument if we need to, or something). Ok, we can pass "bool is_mand" to flock_lock_file that will pass it further to flock_locks_conflict. > > The only caller for this new deny_lock_file is in the nfs code--I'm a > little unclear why that is. deny_lock_file is called not only in the nfs code but also in 2 places of fs/namei.c -- that enable this logic for VFS. -- Best regards, Pavel Shilovsky.

Feb. 5, 2013

Re: [PATCH v2 0/8] Add O_DENY* support for VFS and CIFS/NFS

by Pavel Shilovsky

2013/1/31 J. Bruce Fields <bfields(a)fieldses.org>: > On Thu, Jan 17, 2013 at 08:52:09PM +0400, Pavel Shilovsky wrote: >> This patchset adds support of O_DENY* flags for Linux fs layer. These flags can be used by any application that needs share reservations to organize a file access. VFS already has some sort of this capability - now it's done through flock/LOCK_MAND mechanis, but that approach is non-atomic. This patchset build new capabilities on top of the existing one but doesn't bring any changes into the flock call semantic. >> >> These flags can be used by NFS (built-in-kernel) and CIFS (Samba) servers and Wine applications through VFS (for local filesystems) or CIFS/NFS modules. This will help when e.g. Samba and NFS server share the same directory for Windows and Linux users or Wine applications use Samba/NFS share to access the same data from different clients. >> >> According to the previous discussions the most problematic question is how to prevent situations like DoS attacks where e.g /lib/liba.so file can be open with DENYREAD, or smth like this. That's why one extra flag O_DENYMAND is added. It indicates to underlying layer that an application want to use O_DENY* flags semantic. It allows us not affect native Linux applications (that don't use O_DENYMAND flag) - so, these flags (and the semantic of open syscall that they bring) are used only for those applications that really want it proccessed that way. > > Maybe that's good enough. A mount flag might be simpler and give > consistent enforcement for all users. > >> >> So, we have four new flags: >> O_DENYREAD - to prevent other opens with read access, >> O_DENYWRITE - to prevent other opens with write access, >> O_DENYDELETE - to prevent delete operations (this flag is not implemented in VFS and NFS part and only suitable for CIFS module), >> O_DENYMAND - to switch on/off three flags above. > > It would be useful to have some really careful documentation of how > these are meant to work. Maybe try updating the open man page? Yes, that's a good idea. Do you mean smth like this? O_DENYMAND - used to inforce a mandatory share reservation scheme of the file access. If this flag is passed, the open fails with -ETXTBSY in following cases: 1) if O_DENYREAD flag is specified and there is another open with O_DENYMAND flag and READ access to the file; 2) if O_DENYWRITE flag is specified and there is another open with O_DENYMAND flag and WRITE access to the file; 3) if READ access is requested and there is another open with O_DENYMAND and O_DENYREAD flags; 4) if WRITE access is requested and there is another open with O_DENYMAND and O_DENYWRITE flags; Also, if O_DENYDELETE flag is specified and the open succeded, any further unlink operation will fail with -ETXTBSY untill this open is closed. Now this flag is processed by CIFS filesystems only. -- Best regards, Pavel Shilovsky.

Feb. 5, 2013

Re: Compiling Wine on Mac OS X 10.8.2?

by Jeremiah Flerchinger

Chip, I'm compiling from wine-git again. I had to install the new command line tools for 4.6 and then reboot, since XCode 4.6 didn't seem to be enough. It seems an odd behavior that the patches appeared to force winebuild to use clang, when it had been using gcc before. Thanks and I'll try to see if can switch entirely to clang in my toolchain now. J On Mon, Feb 4, 2013 at 9:32 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > On Feb 4, 2013, at 10:27 AM, Jeremiah Flerchinger wrote: > > Apple's GCC 4.2.1 version 5666.3 > > > > commdlg.vqed9R.s:259:2: error: invalid operand for instruction > lrecompobj.IYZvhS.st:w > 1037 : 2 : error: invalid operand for instruction > ^ > lretw > ^ > compobj.IYZvhS.s:1150:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1195:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1204:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1213:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1222:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1231:2: error: invalid operand for instruction > lretw > ^ > winebuild: /usr/bin/clang failed with status 1 > winegcc: ../../tools/winebuild/ > winebuild failed > make[1]: *** [commdlg.dll16.so] Error 2 > make: *** [dlls/commdlg.dll16] Error 2 > make: *** Waiting for unfinished jobs.... > ../../../tools/winegcc/winegcc -m32 -B../../../tools/winebuild > --sysroot=../../.. -s -Wb,-F,credui_test.exe credui.o testlist.o > -o credui_test-stripped.exe.so ../../../libs/port/libwine_port.a > -lcredui -L/Users/jeremiah/wine/wine-git/lib -L/opt/X11/lib -framework > CoreServices -lz -L/opt/X11/lib -lGL -lGLU > winebuild: /usr/bin/clang failed with status 1 > winegcc: ../../tools/winebuild/winebuild failed > make[1]: *** [compobj.dll16.so] Error 2 > make: *** [dlls/compobj.dll16] Error 2 > echo "credui_test.exe TESTRES \"credui_test-stripped.exe.so\"" | > ../../../tools/wrc/wrc --nostdinc --po-dir=../../../po -m32 -I. -I. > -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES > -DWINE_NO_NAMELESS_EXTENSION -DWIDL_C_INLINE_WRAPPERS -o > ../../../programs/winetest/credui_test.res > could not run 'make -j3' in /Users/jeremiah/wine/build/wine-git - exiting > > Yep, this is related to my patch alright. > > I'm willing to bet you're still running Xcode 4.5, too. Try upgrading to > 4.6. > > Chip > > > > On Sun, Feb 3, 2013 at 11:02 PM, Bill Broach <while1eq1.lists(a)gmail.com>wrote: > >> Which version of gcc are you compiling it with? >> >> Im able to compile no issue with: i686-apple-darwin11-gcc-4.2.1 (GCC) >> 4.2.1 (Apple Inc. build 5666) (dot 3) >> >> On Feb 3, 2013, at 3:58 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: >> >> > >> > On Feb 3, 2013, at 10:50 AM, Saulius Krasuckas wrote: >> > >> >> * On Sun, 3 Feb 2013, Jeremiah Flerchinger wrote: >> >> >> >>> Is anyone compiling Wine from the git repository for OS X version >> >>> 10.8.2? >> >> >> >> Not me... >> >> >> >>> At first I thought I broke my toolchain and could no longer compile >> Wine >> >>> at all, but this is not the case. I can still compile old releases, >> but >> >>> can no longer compile from git. >> >> >> >> ... but I would try running a regression test (git bisect) in your >> case. >> > Why do I get the feeling that when you do, you'll end up at commit >> c14bdaf? >> > >> > How exactly does it break? >> > >> > Chip >> > >> >> >> >> S. >> >> >> >> >> > >> > >> > >> >> > >

Feb. 5, 2013

Re: comctl32/listview: do not touch icon spacing if set explicitly

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24258 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Feb. 4, 2013

Re: comctl32/listview: always use large icon size when calculating icon spacing

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24257 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Feb. 4, 2013

Re: comctl32/listview: correct icon spacing calculation when set to 0 or -1

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=24256 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Feb. 4, 2013

Re: Compiling Wine on Mac OS X 10.8.2?

by Charles Davis

On Feb 4, 2013, at 10:27 AM, Jeremiah Flerchinger wrote: > Apple's GCC 4.2.1 version 5666.3 > > > > commdlg.vqed9R.s:259:2: error: invalid operand for instruction > lrecompobj.IYZvhS.st:w > 1037 : 2 : error: invalid operand for instruction > ^ > lretw > ^ > compobj.IYZvhS.s:1150:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1195:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1204:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1213:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1222:2: error: invalid operand for instruction > lretw > ^ > compobj.IYZvhS.s:1231:2: error: invalid operand for instruction > lretw > ^ > winebuild: /usr/bin/clang failed with status 1 > winegcc: ../../tools/winebuild/ > winebuild failed > make[1]: *** [commdlg.dll16.so] Error 2 > make: *** [dlls/commdlg.dll16] Error 2 > make: *** Waiting for unfinished jobs.... > ../../../tools/winegcc/winegcc -m32 -B../../../tools/winebuild --sysroot=../../.. -s -Wb,-F,credui_test.exe credui.o testlist.o -o credui_test-stripped.exe.so ../../../libs/port/libwine_port.a -lcredui -L/Users/jeremiah/wine/wine-git/lib -L/opt/X11/lib -framework CoreServices -lz -L/opt/X11/lib -lGL -lGLU > winebuild: /usr/bin/clang failed with status 1 > winegcc: ../../tools/winebuild/winebuild failed > make[1]: *** [compobj.dll16.so] Error 2 > make: *** [dlls/compobj.dll16] Error 2 > echo "credui_test.exe TESTRES \"credui_test-stripped.exe.so\"" | ../../../tools/wrc/wrc --nostdinc --po-dir=../../../po -m32 -I. -I. -I../../../include -I../../../include -DWINE_STRICT_PROTOTYPES -DWINE_NO_NAMELESS_EXTENSION -DWIDL_C_INLINE_WRAPPERS -o ../../../programs/winetest/credui_test.res > could not run 'make -j3' in /Users/jeremiah/wine/build/wine-git - exiting Yep, this is related to my patch alright. I'm willing to bet you're still running Xcode 4.5, too. Try upgrading to 4.6. Chip > > > On Sun, Feb 3, 2013 at 11:02 PM, Bill Broach <while1eq1.lists(a)gmail.com> wrote: > Which version of gcc are you compiling it with? > > Im able to compile no issue with: i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) > > On Feb 3, 2013, at 3:58 PM, Charles Davis <cdavis5x(a)gmail.com> wrote: > > > > > On Feb 3, 2013, at 10:50 AM, Saulius Krasuckas wrote: > > > >> * On Sun, 3 Feb 2013, Jeremiah Flerchinger wrote: > >> > >>> Is anyone compiling Wine from the git repository for OS X version > >>> 10.8.2? > >> > >> Not me... > >> > >>> At first I thought I broke my toolchain and could no longer compile Wine > >>> at all, but this is not the case. I can still compile old releases, but > >>> can no longer compile from git. > >> > >> ... but I would try running a regression test (git bisect) in your case. > > Why do I get the feeling that when you do, you'll end up at commit c14bdaf? > > > > How exactly does it break? > > > > Chip > > > >> > >> S. > >> > >> > > > > > > > >

Feb. 4, 2013

Re: [2/5] windowscodecs: Implement IPropertyBag2::CountProperties

by Ludger Sprenker

Looks as if the testbot mixed an older patch-set with the new one. Is there a way to prevent this? Am Montag, 4. Februar 2013, 20:46:31 schrieb Marvin: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=24252 > > Your paranoid android. > > > === WINEBUILD (build) === > Patch failed to apply

Feb. 4, 2013