January 2017 - Wine-Devel - list.winehq.org

Re: [PATCH 1/4] ddraw: Don't write out if a ddraw1 surface of size 0 is requested.
by Marvin Jan. 6, 2017

Jan. 6, 2017

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 https://testbot.winehq.org/JobDetails.pl?Key=27596 Your paranoid android. === w1064 (32 bit ddraw1) === ddraw1.c:2244: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768). === w1064 (64 bit ddraw1) === ddraw1.c:2244: Test failed: Expected (0,0)-(512,384), got (0,0)-(1024,768).

1 0

Re: reg/tests: Add tests for quotes and slashes in keys, values and data
by Marvin Jan. 5, 2017

Jan. 5, 2017

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 https://testbot.winehq.org/JobDetails.pl?Key=27579 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: regedit/tests: Add tests for quotes and slashes in keys, values and data
by Marvin Jan. 5, 2017

Jan. 5, 2017

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 https://testbot.winehq.org/JobDetails.pl?Key=27578 Your paranoid android. === build (build) === Patch failed to apply

1 0

Re: [PATCH 2/6] d3d9/tests: Add test for stale render target views regression.
by Henri Verbeet Jan. 5, 2017

Jan. 5, 2017

On 5 January 2017 at 11:50, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +/* This test exercises a regression in Wine d3d9 implementation. */ The patch is fine, but note that once the bug is fixed it's no longer a regression.

1 0

commctl32: TaskDialog
by Fabian Maurer Jan. 4, 2017

Jan. 4, 2017

Hello, just a question about the TaskDialog/TaskDialogIndirect functions. We already had a few patches in February 2015, but they weren't accepted for some reason. I'd start from scratch anyway, but something to look out for, mistakes that stopped the old series from being accepted? We're in code-freeze now, but I'd already start to give it a try. Another thing, since it's an internal UI class, how do you write test cases for those? I can probably test return value with simulated clicks, but after all, it's mostly visual whether control are properly aligned and shown. Fabian

2 1

Re: msxml3/tests: Mark Win10 behaviour as broken
by Nikolay Sivov Jan. 4, 2017

Jan. 4, 2017

On 04.01.2017 18:49, André Hentschel wrote: > V_VT(&varbody_ref) = VT_VARIANT|VT_BYREF; > V_VARIANTREF(&varbody_ref) = &varbody; > hr = IXMLHttpRequest_send(xhr, varbody_ref); > - EXPECT_HR(hr, S_OK); > + ok(hr == S_OK || broken(hr == E_INVALIDARG) /* win10 */, "got 0x%08x, expected S_OK or E_INVALIDARG\n", hr); I don't think this has any value without understanding why it fails.

1 0

Re: [PATCH] qcap: Release IBaseFilter.
by Jactry Zeng Jan. 4, 2017

Jan. 4, 2017

Hi Andrew, 2017-01-04 21:51 GMT+08:00 Andrew Eikum <aeikum(a)codeweavers.com>: > > This looks OK, but unless it fixes a bug, I'd rather wait until after > code freeze. No problem, I will resend it after code freeze. Thanks for review. -- Regards, Jactry Zeng

1 0

Re: [PATCH] quartz/tests: Skip test_render_run() if test file doesn't exist.
by Andrew Eikum Jan. 4, 2017

Jan. 4, 2017

On Wed, Jan 04, 2017 at 10:52:28AM +0800, Jactry Zeng wrote: > + h = CreateFileW(file, 0, 0, NULL, OPEN_EXISTING, 0, NULL); > + if (h == INVALID_HANDLE_VALUE) { > + skip("Could not read test file \"%s\", skipping test\n", wine_dbgstr_w(file)); > + return; > + } > + CloseHandle(h); > + I like this, but please remove the quote characters: filtergraph.c:359: Tests skipped: Could not read test file "L"test.avi"", skipping test Andrew

1 0

[v2 0/7] x86: enable User-Mode Instruction Prevention
by Ricardo Neri Jan. 3, 2017

Jan. 3, 2017

This is v2 of my first submission done a while ago[1]. I apologize for the delay. User-Mode Instruction Prevention (UMIP) is a security feature present in new Intel Processors. If enabled, it prevents the execution of certain instructions if the Current Privilege Level (CPL) is greater than 0. If these instructions were executed while in CPL > 0, user space applications could have access to system-wide settings such as the global and local descriptor tables, the segment selectors to the current task state and the local descriptor table. These are the instructions covered by UMIP: * SGDT - Store Global Descriptor Table * SIDT - Store Interrupt Descriptor Table * SLDT - Store Local Descriptor Table * SMSW - Store Machine Status Word * STR - Store Task Register If any of these instructions is executed with CPL > 0, a general protection exception is issued when UMIP is enabled. There is a caveat, however. Certain applications rely on some of these instructions to function. An example of this are applications that use WineHQ[2]. For instance, these applications rely on sidt returning a non- accesible memory location[3]. During the discussions, it was proposed that the fault could be relied to the user-space and perform the emulation in user-mode. However, this would break existing applications until, for instance, they update to a new WineHQ version. However, this approach would require UMIP to be disabled by default. The concensus in this forum is to always enable it. This patchset initially treated tasks running in virtual-8086 mode as a special case. However, I received clarification that DOSEMU[4] does not support applications that use these instructions. It relies on WineHQ for this[4]. Furthermore, the applications for which the concern was raised run in protected mode [3]. This version keeps UMIP enabled at all times and by default. If a general protection fault caused by the instructions protected by UMIP is detected, such fault will be fixed-up by returning dummy values as follows: * SGDT and SIDT return a base address to a dummy location in kernel memory and a limit of 0. * STR, SLDT returns 0 as the segment selector. This seems OK since we are providing a dummy value as the base address of the global descriptor table. * SMSW returns 0. Lastly, I found very useful the code for Intel MPX (Memory Protection Extensions) used to parse opcodes and the memory locations contained in the general purpose registers when used as operands. I put some of this code in a separate file that both MPX and UMIP can access and avoid code duplication. While here, I fixed two small bugs that I found in the MPX implementation. The code that I used to test the emulated instructions can be found in [6]. [1]. https://lwn.net/Articles/705877/ [2]. https://www.winehq.org/ [3]. https://www.winehq.org/pipermail/wine-devel/2016-November/115320.html [4]. http://www.dosemu.org/ [5]. http://marc.info/?l=linux-kernel&m=147876798717927&w=2 [6]. https://github.com/01org/luv-yocto/tree/rneri/umip/meta-luv/recipes-core/um… Thanks and BR, Ricardo Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Liang Z Li <liang.z.li(a)intel.com> Cc: x86(a)kernel.org Cc: linux-msdos(a)vger.kernel.org Changes since V1: * Virtual-8086 mode tasks are not treated in a special manner. All code for this purpose was removed. * Instead of attempting to disable UMIP during a context switch or when entering virtual-8086 mode, UMIP remains enabled all the time. General protection faults that occur are fixed-up by returning dummy values as detailed above. * Removed umip= kernel parameter in favor of using clearcpuid=514 to disable UMIP. * Removed selftests designed to detect the absence of SIGSEGV signals when running in virtual-8086 mode. * Reused code from MPX to decode instructions operands. For this purpose code was put in a common location. * Fixed two bugs in MPX code that decodes operands. Ricardo Neri (7): x86/mpx: Do not use SIB index if index points to R/ESP x86/mpx: Fail when implicit zero-displacement is used along with R/EBP x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils x86/cpufeature: Add User-Mode Instruction Prevention definitions x86: Add emulation code for UMIP instructions x86/traps: Fixup general protection faults caused by UMIP x86: Enable User-Mode Instruction Prevention arch/x86/Kconfig | 10 ++ arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/disabled-features.h | 8 +- arch/x86/include/asm/insn.h | 6 + arch/x86/include/asm/umip.h | 16 +++ arch/x86/include/uapi/asm/processor-flags.h | 2 + arch/x86/kernel/Makefile | 1 + arch/x86/kernel/cpu/common.c | 16 ++- arch/x86/kernel/traps.c | 4 + arch/x86/kernel/umip.c | 170 ++++++++++++++++++++++++++++ arch/x86/lib/Makefile | 2 +- arch/x86/lib/insn-utils.c | 148 ++++++++++++++++++++++++ arch/x86/mm/mpx.c | 119 +------------------ 13 files changed, 382 insertions(+), 121 deletions(-) create mode 100644 arch/x86/include/asm/umip.h create mode 100644 arch/x86/kernel/umip.c create mode 100644 arch/x86/lib/insn-utils.c -- 2.9.3

5 30

Re: [1/3] ntdll: Define more file information classes.
by Jonathan Doron Jan. 3, 2017

Jan. 3, 2017

Hello I would like to understand how to proceed with this. I tried to keep the patchset to minimum amount of changes so it wont affect anything else. Thanks, -- Jon. On Mon, Jan 2, 2017 at 10:04 PM, Marvin <testbot(a)winehq.org> wrote: > Thank you for your contribution to Wine! > > This is an automated notification to let you know that your patch has > been reviewed and its status set to "Deferred". > > This means that the patch is deferred because of code freeze for an > upcoming release. You need to either resend after the release, make > the patch less intrusive, or make a convincing argument that it needs > to be included in the release. > > If you do not understand the reason for this status, disagree with our > assessment, or are simply not sure how to proceed next, please ask for > clarification by replying to this email. >

2 1