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

[PATCH v3 1/7] fcntl: Introduce new O_DENY* open flags

by Pavel Shilovsky

This patch adds 4 flags: 1) O_DENYREAD that doesn't permit read access, 2) O_DENYWRITE that doesn't permit write access, 3) O_DENYDELETE that doesn't permit delete or rename, 4) O_DENYMAND that enables O_DENY* flags checks. Network filesystems CIFS, SMB2.0, SMB3.0 and NFSv4 have such flags - this change can benefit cifs and nfs modules as well as Samba and NFS file servers. These flags are only take affect for opens with O_DENYMAND flags - there is no impact on native Linux opens. Signed-off-by: Pavel Shilovsky <piastry(a)etersoft.ru> --- fs/fcntl.c | 5 +++-- include/uapi/asm-generic/fcntl.h | 14 ++++++++++++++ 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/fs/fcntl.c b/fs/fcntl.c index 71a600a..d88a548 100644 --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -730,14 +730,15 @@ static int __init fcntl_init(void) * Exceptions: O_NONBLOCK is a two bit define on parisc; O_NDELAY * is defined as O_NONBLOCK on some platforms and not on others. */ - BUILD_BUG_ON(19 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32( + BUILD_BUG_ON(23 - 1 /* for O_RDONLY being 0 */ != HWEIGHT32( O_RDONLY | O_WRONLY | O_RDWR | O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | O_APPEND | /* O_NONBLOCK | */ __O_SYNC | O_DSYNC | FASYNC | O_DIRECT | O_LARGEFILE | O_DIRECTORY | O_NOFOLLOW | O_NOATIME | O_CLOEXEC | - __FMODE_EXEC | O_PATH + __FMODE_EXEC | O_PATH | O_DENYREAD | + O_DENYWRITE | O_DENYDELETE | O_DENYMAND )); fasync_cache = kmem_cache_create("fasync_cache", diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h index a48937d..6e4e979 100644 --- a/include/uapi/asm-generic/fcntl.h +++ b/include/uapi/asm-generic/fcntl.h @@ -84,6 +84,20 @@ #define O_PATH 010000000 #endif +#ifndef O_DENYREAD +#define O_DENYREAD 020000000 /* Do not permit read access */ +#endif +#ifndef O_DENYWRITE +#define O_DENYWRITE 040000000 /* Do not permit write access */ +#endif +/* FMODE_NONOTIFY 0100000000 */ +#ifndef O_DENYDELETE +#define O_DENYDELETE 0200000000 /* Do not permit delete or rename */ +#endif +#ifndef O_DENYMAND +#define O_DENYMAND 0400000000 /* Enable O_DENY flags checks */ +#endif + #ifndef O_NDELAY #define O_NDELAY O_NONBLOCK #endif -- 1.8.1.2

Feb. 28, 2013

[PATCH v3 0/7] Add O_DENY* support for VFS and CIFS/NFS

by Pavel Shilovsky

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. 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. Also, this version of the patchset fixes the problem of data races on newely created files: open with O_CREAT can return the -ETXTBSY error for a successfully created file if this files was locked with a deny lock by another task. The #1 patch adds flags to fcntl, the #2 patch implements VFS part. The patches #3, #4, #5 are related to CIFS-specific changes, #6 and #7 describe NFS and NFSD parts. The preliminary patch for Samba that replaces the existing use of flock/LOCK_MAND mechanism with O_DENY* flags: http://git.etersoft.ru/people/piastry/packages/?p=samba.git;a=commitdiff;h=… The future part of open man page patch: ----- 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. 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. This mechanism is done through flocks. If O_DENYMAND is specified and flock syscall is processed after the open. The share modes are translated into flock according the following rules: 1) O_DENYMAND -> LOCK_MAND 2) !O_DENYREAD -> LOCK_READ 3) !O_DENYWRITE -> LOCK_WRITE ----- Pavel Shilovsky (7): fcntl: Introduce new O_DENY* open flags vfs: Add O_DENYREAD/WRITE flags support for open syscall CIFS: Add O_DENY* open flags support CIFS: Use NT_CREATE_ANDX command for forcemand mounts CIFS: Translate SHARING_VIOLATION to -ETXTBSY error code for SMB2 NFSv4: Add O_DENY* open flags support NFSD: Pass share reservations flags to VFS fs/cifs/cifsacl.c | 6 +- fs/cifs/cifsglob.h | 12 +++- fs/cifs/cifsproto.h | 9 +-- fs/cifs/cifssmb.c | 47 ++++++++-------- fs/cifs/dir.c | 14 +++-- fs/cifs/file.c | 18 ++++-- 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/smb2maperror.c | 2 +- fs/cifs/smb2ops.c | 10 ++-- fs/cifs/smb2pdu.c | 6 +- fs/cifs/smb2proto.h | 14 +++-- fs/fcntl.c | 5 +- fs/locks.c | 117 +++++++++++++++++++++++++++++++++++---- fs/namei.c | 44 ++++++++++++++- fs/nfs/nfs4xdr.c | 24 ++++++-- fs/nfsd/nfs4state.c | 46 ++++++++++++++- include/linux/fs.h | 6 ++ include/uapi/asm-generic/fcntl.h | 14 +++++ 23 files changed, 345 insertions(+), 101 deletions(-) -- 1.8.1.2

Feb. 28, 2013

GSoC 2013 guidelines.

by Tejas Nikumbh

Hi, I am Tejas Nikumbh, an undergrad at Indian Institute of Technology Bombay. I will be participating in GSoC this year. [GSoC 2013]. In order to imporve my chances for getting selected this year, I would like to start contributing early on to Open Source development via Wine. Here's a little background info : *Languages proficient in : *Java, Python, Javascript [+jQuery] , HTML[+HTML5 Canvas], CSS [+CSS3]. C++ should be on the list soon. *CS Theory :* Discrete Math, Probablity and Random Processes, Data Structures and Algorithms. *SVN : *Github, Mercurial . *Basic Machine learning [Regression algos and some classification algos]* Based on the above info, are there any projects which might suit me? Also, Picking up something reasonable quickly shouldn't be a problem. Thanks, -- Tejas Nikumbh, Third Year Undergraduate, Electrical Engineering Department, IIT Bombay.

Feb. 28, 2013

Re: ieframe: Fixed QI tests on IE10, where IStdMarshalInfo is supported by WebBrowser object.

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=24550 Your paranoid android. === WNT4WSSP6 (32 bit webbrowser) === Timeout === W2KPROSP4 (32 bit webbrowser) === webbrowser.c:2607: Test failed: expected GetOverridesKeyPath webbrowser.c:2612: Test failed: expected Invoke_SETSECURELOCKICON webbrowser.c:2613: Test failed: expected Invoke_FILEDOWNLOAD webbrowser.c:3041: Test failed: doc_disp == NULL webbrowser: unhandled exception c0000005 at 00402F21

Feb. 28, 2013

Re: msvcrt/tests: Mark win8 behaviour as broken (try 2)

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=24548 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Feb. 27, 2013

Fix name order in the authors file.

by Tae Wong

You’ve found Kazuyuki Sato in inverted name order. Apostrophes on the O-section are not ignored. O'Callahan, Robert O'Neill, Damien O'Regan, Mike Oberhumer, Stefan Oberndorfer, Peter Ogburn, Walt Ognyanoff, Damyan Olsen, Henrik Olsen, Magnus Olson, Roger Olver, Neil Ortiz, Jose Manuel Ferrer Osmundsen, Knut St. It should be ignored so the section should be sorted as: Oberhumer, Stefan Oberndorfer, Peter O'Callahan, Robert Ogburn, Walt Ognyanoff, Damyan Olsen, Henrik Olsen, Magnus Olson, Roger Olver, Neil O'Neill, Damien O'Regan, Mike Ortiz, Jose Manuel Ferrer Osmundsen, Knut St.

Feb. 27, 2013

Re: d3dx9: Avoid expensive computations

by Matteo Bruni

2013/2/26 Rico Schüller <kgbricola(a)web.de>: > Hi Nozomi, > > this is pretty fast. Just some numbers (run time on my machine, so it might > not be that representative)... > > before: 43s > previous patch: 27s > this patch: 21s > native: 16s > > So from the speed point of view, it's a lot closer than the rest. > > Though, I would split this into 2 patches, one for D3DXMatrixDeterminant and > one for D3DXMatrixInverse. That's probably a good idea. > I think it's a nice step forward. Thought we > might test the speed of an sse version and may use it later ... > > Are there any other opinions? > My main concern is that the effort in optimizing further those two functions might not have significant effects on actual application execution times (think diminishing returns). I'm not against making the code faster, especially if that doesn't make the code unreadable, but it might not be the best place to work on if you want to optimize d3dx9. You might want to profile some applications and see what the actual bottlenecks are. Specifically on these functions, an SSE-based version will probably run significantly faster, but you need to solve the issues with compatibility with older CPUs e.g. by selecting the correct function implementation at runtime in some fashion, as Henri mentioned. BTW there might be other potential problems, such as applications setting the SSE control register in some unexpected way (although that happens with the FPU control word too). You can also give a shot to GCC optimization options, such as "-mfpmath=sse" (and a suitable -march value). Obviously we don't want to use them in general but it might be interesting to see what GCC can do there. Keep in mind that the compiler has to stay on the safe side when optimizing and you might need to add attributes around to allow more aggressive optimizations. From a quick Google search I found http://locklessinc.com/articles/vectorize/ which seems to show the general idea. Cheers, Matteo. > Cheers > Rico > > > > On 25.02.2013 12:34, Nozomi Kodama wrote: >> >> Rico, >> >> can you give a try to this patch? >> If it is slightly slower than native, we could at first merge it. >> >> >> Anyway, if the application is well coded, this function should not be >> called often. Usually an application uses transformations matrices that >> are a lot easier to inverse >> >> Nozomi >> >> >> ------------------------------------------------------------------------ >> *De :* Henri Verbeet <hverbeet(a)gmail.com> >> *À :* Rico Schüller <kgbricola(a)web.de> >> *Cc :* wine-devel(a)winehq.org; Nozomi Kodama <nozomi.kodama(a)yahoo.com> >> *Envoyé le :* Lundi 25 février 2013 0h08 >> *Objet :* Re: d3dx9: Avoid expensive computations >> >> >> On 25 February 2013 10:24, Rico Schüller <kgbricola(a)web.de >> <mailto:kgbricola(a)web.de>> wrote: >> > I did some small tests for speed with the following results. You may >> also >> > avoid such a lot of variable assignments like *pout = out and you may >> use 4 >> > vecs instead. This should save ~48 assignments and it should also >> improve >> > the speed a bit more (~10%). Though, native is still 40% faster than >> that. >> > >> I'd somewhat expect native to use SSE versions of this kind of thing >> when the CPU supports those instructions. You also generally want to >> pay attention to the order in which you access memory, although >> perhaps it doesn't matter so much here because an entire matrix should >> be able to fit in a single cacheline, provided it's properly aligned. >> >> > > >

Feb. 27, 2013

Re: secur32: Report SecPkgContext_ConnectionInfo in bits, not bytes.

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=24544 Your paranoid android. === W2KPROSP4 (32 bit schannel) === schannel.c:762: Test failed: conn_info.dwHashStrength = 128 === WXPPROSP3 (32 bit schannel) === schannel.c:762: Test failed: conn_info.dwHashStrength = 128 === W2K3R2SESP2 (32 bit schannel) === schannel.c:762: Test failed: conn_info.dwHashStrength = 128

Feb. 27, 2013

Re: mmdevapi: Prevent 64 bit overflow within a few days of audio device use.

by Michael Stefaniuc

Hello Joerg, On 02/27/2013 02:46 PM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > The idea to replace X * numerator / denominator > by X / den * mul + remainder from euclidian division > came from can you please use an inline function for that? > http://blog.airsource.co.uk/index.php/2010/03/15/quelle-heure-est-il/ thanks bye michael

Feb. 27, 2013

Re: [PATCH 2/4] vbscript: Added color constants.

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=24538 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

Feb. 27, 2013