Wine-Devel
By thread
wine-devel@list.winehq.org
By month
Messages by month
- ----- 2026 -----
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2001 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
December 2016
- 57 participants
- 271 messages
Re: [v2 2/7] x86/mpx: Fail when implicit zero-displacement is used along with R/EBP
by Ricardo Neri
On Fri, 2016-12-23 at 17:58 -0800, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
> <ricardo.neri-calderon(a)linux.intel.com> wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when memory addressing with no
> > explicit displacement (i.e, mod part of ModR/M is 0), a SIB byte is used
> > and the base of the SIB byte points to (R/EBP) (i.e., base = 5), an
> > explicit displacement of 0 must be used.
> >
> > Make the address decoder to return -EINVAL in such a case.
> >
> > Cc: Dave Hansen <dave.hansen(a)linux.intel.com>
> > Cc: Adam Buchbinder <adam.buchbinder(a)gmail.com>
> > Cc: Colin Ian King <colin.king(a)canonical.com>
> > Cc: Lorenzo Stoakes <lstoakes(a)gmail.com>
> > Cc: Qiaowei Ren <qiaowei.ren(a)intel.com>
> > Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com>
> > Cc: x86(a)kernel.org
> > Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
> > ---
> > arch/x86/mm/mpx.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
> > index 6a75a75..71681d0 100644
> > --- a/arch/x86/mm/mpx.c
> > +++ b/arch/x86/mm/mpx.c
> > @@ -120,6 +120,13 @@ static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
> >
> > case REG_TYPE_BASE:
> > regno = X86_SIB_BASE(insn->sib.value);
> > + if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
> > + WARN_ONCE(1, "An explicit displacement is required when %sBP used as SIB base.",
> > + (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) ?
> > + "R13 or R" : "E");
> > + return -EINVAL;
> > + }
> > +
>
> Now that I've read the cover letter, I see what's going on. This
> should not warn -- user code can easily trigger this deliberately.
OK, I'll remove it. Are you concerned about the warning printing the
calltrace, even only once?
Dec. 27, 2016
Re: [v2 1/7] x86/mpx: Do not use SIB index if index points to R/ESP
by Ricardo Neri
On Fri, 2016-12-23 at 17:57 -0800, Andy Lutomirski wrote:
> On Fri, Dec 23, 2016 at 5:37 PM, Ricardo Neri
> <ricardo.neri-calderon(a)linux.intel.com> wrote:
> > Section 2.2.1.2 of the Intel 64 and IA-32 Architectures Software
> > Developer's Manual volume 2A states that when memory addressing is used
> > (i.e., mod part of ModR/M is not 3), a SIB byte is used and the index of
> > the SIB byte points to the R/ESP (i.e.,index = 4), the index should not be
> > used in the computation of the memory address.
> >
> > An example of such instruction could be
> >
> > insn -0x80(%rsp)
> >
> > This is represented as:
> >
> > [opcode] 4c 24 80
> >
> > ModR/M: mod: 1, reg: 1: r/m: 4 (R/ESP)
> > SIB 24: sc: 0, index: 100 (R/ESP), base(R/ESP): 100
> > Displacement -0x80
> >
> > The correct address is (base) + displacement; no index is used.
> >
> > Care is taken to allow R12 to be used as index, which is a valid scenario.
>
> Since I have no idea what this patch has to do with the rest of the
> series, I'll ask a question:
Thanks for your feedback! I saw in a previous e-mail that you read the
cover-letter. :)
>
> Why isn't this code in the standard x86 instruction decoder? Is the
> decoder similarly buggy?
I did not find any bug in the instruction decoder. I think the reason
this code is not in the decoder is that the decoder only gives you the
bytes of the instructions without any meaning. For instance, it gives
you the ModRM byte but it does not tell you what register or addressing
mode is used.
To fully emulate the UMIP instructions I need to give meaning to the
ModRM and SIB bytes. Since I was trying many operand combinations, I ran
into this issue.
Thanks and BR,
Ricardo
Dec. 27, 2016
Re: wined3d Add Amd rx 480 binary driver
by Austin English
On Dec 26, 2016 12:04 AM, "Jarkko Korpi" <jarkko_korpi(a)hotmail.com> wrote:
http://source.winehq.org/git/wine.git/commit/c63e3261f37e8116e59c70b9bed20a
a90c39e8a1
Since that commit Rx 480 supposed to be recognized, but I am using closed
source drivers, because the audio patches arent in upstream yet. I found a
real problem from SC2 appdatabase and I could confirm it myself. When you
start SC2 and go to options it limits your GPU graphics options and
complains not enough memory. With the attached patch here the options are
not limited anymore.
Patches should be sent to wine-patches(a)winehq.org
Dec. 26, 2016
wined3d Add Amd rx 480 binary driver
by Jarkko Korpi
http://source.winehq.org/git/wine.git/commit/c63e3261f37e8116e59c70b9bed20a…
Since that commit Rx 480 supposed to be recognized, but I am using closed source drivers, because the audio patches arent in upstream yet. I found a real problem from SC2 appdatabase and I could confirm it myself. When you start SC2 and go to options it limits your GPU graphics options and complains not enough memory. With the attached patch here the options are not limited anymore.
Dec. 26, 2016
(no subject)
by Jarkko Korpi
http://source.winehq.org/git/wine.git/commit/c63e3261f37e8116e59c70b9bed20a…
Since that commit Rx 480 supposed to be recognized, but I am using closed source drivers, because the audio patches arent in upstream yet. I found a real problem from SC2 appdatabase and I could confirm it myself. When you start SC2 and go to options it limits your GPU graphics options. With the attached patch here the options are not limited anymore.
Dec. 26, 2016
Re: [v2 5/7] x86: Add emulation code for UMIP instructions
by Masami Hiramatsu
On Fri, 23 Dec 2016 17:37:43 -0800
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote:
> +static int __identify_insn(struct insn *insn)
> +{
> + /* by getting modrm we also get the opcode */
> + insn_get_modrm(insn);
> + if (insn->opcode.bytes[0] != 0xf)
> + return -EINVAL;
> +
> + if (insn->opcode.bytes[1] == 0x1) {
> + switch (X86_MODRM_REG(insn->modrm.value)) {
> + case 0:
> + return UMIP_SGDT;
> + case 1:
> + return UMIP_SIDT;
> + case 4:
> + return UMIP_SMSW;
> + default:
> + return -EINVAL;
> + }
> + } else if (insn->opcode.bytes[1] == 0x0) {
> + if (X86_MODRM_REG(insn->modrm.value) == 0)
> + return UMIP_SLDT;
> + else if (X86_MODRM_REG(insn->modrm.value) == 1)
> + return UMIP_STR;
> + else
> + return -EINVAL;
> + }
gcc detected an error here, you may need return "-EINVAL".
Thanks,
--
Masami Hiramatsu <mhiramat(a)kernel.org>
Dec. 25, 2016
Re: [v2 3/7] x86/mpx, x86/insn: Relocate insn util functions to a new insn-utils
by Masami Hiramatsu
Hi Ricado,
On Fri, 23 Dec 2016 17:37:41 -0800
Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> wrote:
> Other kernel submodules can benefit from using the utility functions
> defined in mpx.c to obtain the addresses and values of operands contained
> in the general purpose registers. An instance of this is the emulation code
> used for instructions protected by the Intel User-Mode Instruction
> Prevention feature.
>
> Thus, these functions are relocated to a new insn-utils.c file. The reason
> to not relocate these utilities for insn.c is that the latter solely
> analyses instructions given by a struct insn. The file insn-utils.c intends
> to be used when, for instance, determining addresses from the contents
> of the general purpose registers.
>
> To avoid creating a new insn-utils.h, insn.h is used. One caveat, however,
> is that several #include's were needed by the utility functions.
>
> Functions are simply relocated. There are not functional or indentation
> changes.
Thank you for your great work! :)
> ---
> arch/x86/include/asm/insn.h | 6 ++
> arch/x86/lib/Makefile | 2 +-
> arch/x86/lib/insn-utils.c | 148 ++++++++++++++++++++++++++++++++++++++++++++
> arch/x86/mm/mpx.c | 136 +---------------------------------------
> 4 files changed, 156 insertions(+), 136 deletions(-)
> create mode 100644 arch/x86/lib/insn-utils.c
>
> diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
> index b3e32b0..9dc9d42 100644
> --- a/arch/x86/include/asm/insn.h
> +++ b/arch/x86/include/asm/insn.h
> @@ -22,6 +22,10 @@
>
> /* insn_attr_t is defined in inat.h */
> #include <asm/inat.h>
> +#include <linux/compiler.h>
> +#include <linux/bug.h>
> +#include <linux/err.h>
> +#include <asm/ptrace.h>
>
> struct insn_field {
> union {
> @@ -106,6 +110,8 @@ extern void insn_get_sib(struct insn *insn);
> extern void insn_get_displacement(struct insn *insn);
> extern void insn_get_immediate(struct insn *insn);
> extern void insn_get_length(struct insn *insn);
> +extern void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs);
> +extern int get_reg_offset_rm(struct insn *insn, struct pt_regs *regs);
Could you also rename this to add "insn_" prefix?
Other part looks good to me :)
(btw, I saw a kbuild bot warning, would you also test it with
CONFIG_X86_DECODER_SELFTEST=y?)
Thanks again!
>
> /* Attribute will be determined after getting ModRM (for opcode groups) */
> static inline void insn_get_attribute(struct insn *insn)
> diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
> index 34a7413..0d01d82 100644
> --- a/arch/x86/lib/Makefile
> +++ b/arch/x86/lib/Makefile
> @@ -23,7 +23,7 @@ lib-y := delay.o misc.o cmdline.o cpu.o
> lib-y += usercopy_$(BITS).o usercopy.o getuser.o putuser.o
> lib-y += memcpy_$(BITS).o
> lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
> -lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o
> +lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-utils.o
> lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
>
> obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
> diff --git a/arch/x86/lib/insn-utils.c b/arch/x86/lib/insn-utils.c
> new file mode 100644
> index 0000000..598bbd6
> --- /dev/null
> +++ b/arch/x86/lib/insn-utils.c
> @@ -0,0 +1,148 @@
> +/*
> + * Utility functions for x86 operand and address decoding
> + *
> + * Copyright (C) Intel Corporation 2016
> + */
> +#include <linux/kernel.h>
> +#include <linux/string.h>
> +#include <asm/inat.h>
> +#include <asm/insn.h>
> +
> +enum reg_type {
> + REG_TYPE_RM = 0,
> + REG_TYPE_INDEX,
> + REG_TYPE_BASE,
> +};
> +
> +static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
> + enum reg_type type)
> +{
> + int regno = 0;
> +
> + static const int regoff[] = {
> + offsetof(struct pt_regs, ax),
> + offsetof(struct pt_regs, cx),
> + offsetof(struct pt_regs, dx),
> + offsetof(struct pt_regs, bx),
> + offsetof(struct pt_regs, sp),
> + offsetof(struct pt_regs, bp),
> + offsetof(struct pt_regs, si),
> + offsetof(struct pt_regs, di),
> +#ifdef CONFIG_X86_64
> + offsetof(struct pt_regs, r8),
> + offsetof(struct pt_regs, r9),
> + offsetof(struct pt_regs, r10),
> + offsetof(struct pt_regs, r11),
> + offsetof(struct pt_regs, r12),
> + offsetof(struct pt_regs, r13),
> + offsetof(struct pt_regs, r14),
> + offsetof(struct pt_regs, r15),
> +#endif
> + };
> + int nr_registers = ARRAY_SIZE(regoff);
> + /*
> + * Don't possibly decode a 32-bit instructions as
> + * reading a 64-bit-only register.
> + */
> + if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64)
> + nr_registers -= 8;
> +
> + switch (type) {
> + case REG_TYPE_RM:
> + regno = X86_MODRM_RM(insn->modrm.value);
> + if (X86_REX_B(insn->rex_prefix.value))
> + regno += 8;
> + break;
> +
> + case REG_TYPE_INDEX:
> + regno = X86_SIB_INDEX(insn->sib.value);
> + if (X86_REX_X(insn->rex_prefix.value))
> + regno += 8;
> + /*
> + * If mod !=3, SP is not used as index. Check is done after
> + * looking at REX.X This is because R12 can be used as an
> + * index.
> + */
> + if (regno == 4 && X86_MODRM_RM(insn->modrm.value) != 3)
> + return 0;
> + break;
> +
> + case REG_TYPE_BASE:
> + regno = X86_SIB_BASE(insn->sib.value);
> + if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
> + WARN_ONCE(1, "An explicit displacement is required when %sBP used as SIB base.",
> + (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) ?
> + "R13 or R" : "E");
> + return -EINVAL;
> + }
> +
> + if (X86_REX_B(insn->rex_prefix.value))
> + regno += 8;
> + break;
> +
> + default:
> + pr_err("invalid register type");
> + BUG();
> + break;
> + }
> +
> + if (regno >= nr_registers) {
> + WARN_ONCE(1, "decoded an instruction with an invalid register");
> + return -EINVAL;
> + }
> + return regoff[regno];
> +}
> +
> +int get_reg_offset_rm(struct insn *insn, struct pt_regs *regs)
> +{
> + return get_reg_offset(insn, regs, REG_TYPE_RM);
> +}
> +
> +/*
> + * return the address being referenced be instruction
> + * for rm=3 returning the content of the rm reg
> + * for rm!=3 calculates the address using SIB and Disp
> + */
> +void __user *insn_get_addr_ref(struct insn *insn, struct pt_regs *regs)
> +{
> + unsigned long addr, base, indx;
> + int addr_offset, base_offset, indx_offset;
> + insn_byte_t sib;
> +
> + insn_get_modrm(insn);
> + insn_get_sib(insn);
> + sib = insn->sib.value;
> +
> + if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> + addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
> + if (addr_offset < 0)
> + goto out_err;
> + addr = regs_get_register(regs, addr_offset);
> + } else {
> + if (insn->sib.nbytes) {
> + base_offset = get_reg_offset(insn, regs, REG_TYPE_BASE);
> + if (base_offset < 0)
> + goto out_err;
> +
> + indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX);
> + if (indx_offset < 0)
> + goto out_err;
> +
> + base = regs_get_register(regs, base_offset);
> + if (indx_offset)
> + indx = regs_get_register(regs, indx_offset);
> + else
> + indx = 0;
> + addr = base + indx * (1 << X86_SIB_SCALE(sib));
> + } else {
> + addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
> + if (addr_offset < 0)
> + goto out_err;
> + addr = regs_get_register(regs, addr_offset);
> + }
> + addr += insn->displacement.value;
> + }
> + return (void __user *)addr;
> +out_err:
> + return (void __user *)-1;
> +}
> diff --git a/arch/x86/mm/mpx.c b/arch/x86/mm/mpx.c
> index 71681d0..32ba342 100644
> --- a/arch/x86/mm/mpx.c
> +++ b/arch/x86/mm/mpx.c
> @@ -59,140 +59,6 @@ static unsigned long mpx_mmap(unsigned long len)
> return addr;
> }
>
> -enum reg_type {
> - REG_TYPE_RM = 0,
> - REG_TYPE_INDEX,
> - REG_TYPE_BASE,
> -};
> -
> -static int get_reg_offset(struct insn *insn, struct pt_regs *regs,
> - enum reg_type type)
> -{
> - int regno = 0;
> -
> - static const int regoff[] = {
> - offsetof(struct pt_regs, ax),
> - offsetof(struct pt_regs, cx),
> - offsetof(struct pt_regs, dx),
> - offsetof(struct pt_regs, bx),
> - offsetof(struct pt_regs, sp),
> - offsetof(struct pt_regs, bp),
> - offsetof(struct pt_regs, si),
> - offsetof(struct pt_regs, di),
> -#ifdef CONFIG_X86_64
> - offsetof(struct pt_regs, r8),
> - offsetof(struct pt_regs, r9),
> - offsetof(struct pt_regs, r10),
> - offsetof(struct pt_regs, r11),
> - offsetof(struct pt_regs, r12),
> - offsetof(struct pt_regs, r13),
> - offsetof(struct pt_regs, r14),
> - offsetof(struct pt_regs, r15),
> -#endif
> - };
> - int nr_registers = ARRAY_SIZE(regoff);
> - /*
> - * Don't possibly decode a 32-bit instructions as
> - * reading a 64-bit-only register.
> - */
> - if (IS_ENABLED(CONFIG_X86_64) && !insn->x86_64)
> - nr_registers -= 8;
> -
> - switch (type) {
> - case REG_TYPE_RM:
> - regno = X86_MODRM_RM(insn->modrm.value);
> - if (X86_REX_B(insn->rex_prefix.value))
> - regno += 8;
> - break;
> -
> - case REG_TYPE_INDEX:
> - regno = X86_SIB_INDEX(insn->sib.value);
> - if (X86_REX_X(insn->rex_prefix.value))
> - regno += 8;
> - /*
> - * If mod !=3, SP is not used as index. Check is done after
> - * looking at REX.X This is because R12 can be used as an
> - * index.
> - */
> - if (regno == 4 && X86_MODRM_RM(insn->modrm.value) != 3)
> - return 0;
> - break;
> -
> - case REG_TYPE_BASE:
> - regno = X86_SIB_BASE(insn->sib.value);
> - if (regno == 5 && X86_MODRM_RM(insn->modrm.value) == 0) {
> - WARN_ONCE(1, "An explicit displacement is required when %sBP used as SIB base.",
> - (IS_ENABLED(CONFIG_X86_64) && insn->x86_64) ?
> - "R13 or R" : "E");
> - return -EINVAL;
> - }
> -
> - if (X86_REX_B(insn->rex_prefix.value))
> - regno += 8;
> - break;
> -
> - default:
> - pr_err("invalid register type");
> - BUG();
> - break;
> - }
> -
> - if (regno >= nr_registers) {
> - WARN_ONCE(1, "decoded an instruction with an invalid register");
> - return -EINVAL;
> - }
> - return regoff[regno];
> -}
> -
> -/*
> - * return the address being referenced be instruction
> - * for rm=3 returning the content of the rm reg
> - * for rm!=3 calculates the address using SIB and Disp
> - */
> -static void __user *mpx_get_addr_ref(struct insn *insn, struct pt_regs *regs)
> -{
> - unsigned long addr, base, indx;
> - int addr_offset, base_offset, indx_offset;
> - insn_byte_t sib;
> -
> - insn_get_modrm(insn);
> - insn_get_sib(insn);
> - sib = insn->sib.value;
> -
> - if (X86_MODRM_MOD(insn->modrm.value) == 3) {
> - addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
> - if (addr_offset < 0)
> - goto out_err;
> - addr = regs_get_register(regs, addr_offset);
> - } else {
> - if (insn->sib.nbytes) {
> - base_offset = get_reg_offset(insn, regs, REG_TYPE_BASE);
> - if (base_offset < 0)
> - goto out_err;
> -
> - indx_offset = get_reg_offset(insn, regs, REG_TYPE_INDEX);
> - if (indx_offset < 0)
> - goto out_err;
> -
> - base = regs_get_register(regs, base_offset);
> - if (indx_offset)
> - indx = regs_get_register(regs, indx_offset);
> - else
> - indx = 0;
> - addr = base + indx * (1 << X86_SIB_SCALE(sib));
> - } else {
> - addr_offset = get_reg_offset(insn, regs, REG_TYPE_RM);
> - if (addr_offset < 0)
> - goto out_err;
> - addr = regs_get_register(regs, addr_offset);
> - }
> - addr += insn->displacement.value;
> - }
> - return (void __user *)addr;
> -out_err:
> - return (void __user *)-1;
> -}
> -
> static int mpx_insn_decode(struct insn *insn,
> struct pt_regs *regs)
> {
> @@ -305,7 +171,7 @@ siginfo_t *mpx_generate_siginfo(struct pt_regs *regs)
> info->si_signo = SIGSEGV;
> info->si_errno = 0;
> info->si_code = SEGV_BNDERR;
> - info->si_addr = mpx_get_addr_ref(&insn, regs);
> + info->si_addr = insn_get_addr_ref(&insn, regs);
> /*
> * We were not able to extract an address from the instruction,
> * probably because there was something invalid in it.
> --
> 2.9.3
>
--
Masami Hiramatsu <mhiramat(a)kernel.org>
Dec. 25, 2016
Re: msvcirt: Avoid "array subscript above array bounds" warnings in test_ostrstream and test_strstreambuf.
by Gerald Pfeifer
Hi Piotr,
On Fri, 4 Nov 2016, Piotr Caban wrote:
> sorry for long reply time.
sorry, now it's taken me a while due to travel and other things),
and...
>> - ok(ssb1.base.ebuf == buffer + 0x7fffffff || ssb1.base.ebuf == (char*)-1,
>> + ok((size_t)ssb1.base.ebuf == (size_t)buffer + 0x7fffffff || ssb1.base.ebuf == (char*)-1,
> Is casting buffer to char* enough to get away with the warning? I think I
> would prefer it to be done this way if it works.
...I believe I tried this and it did not work. On the positive side,
Alexandre ran into this now as well and fixed it two days ago, so you
and me can close this. ;-) (Thanks, Alexandre!)
commit c28816cc378a580258bfb35a8fc8a32d1b40afde
Author: Alexandre Julliard <julliard(a)winehq.org>
Date: Thu Dec 22 15:07:05 2016 +0100
msvcirt/tests: Silence a compiler warning.
Filip, from what I have seen, this should also address what you
reported below?
Gerald
On Thu, 10 Nov 2016, Filip Frackiewicz wrote:
> In wine-1.9.22-129-g906e770 I see the array subscript warnings in the
> following location:
>
> ../../../../wine/dlls/msvcirt/tests/msvcirt.c: In function ‘test_strstream’:
> ../../../../wine/dlls/msvcirt/tests/msvcirt.c:6861:34: warning: array
> subscript is above array bounds [-Warray-bounds]
> ok(pssb->base.ebuf == buffer + 0x7fffffff || pssb->base.ebuf == (char*) -1,
> ~~~~~~~^~~~~~~~~~~~
> ../../../../wine/dlls/msvcirt/tests/msvcirt.c:6868:35: warning: array
> subscript is above array bounds [-Warray-bounds]
> ok(pssb->base.epptr == buffer + 0x7fffffff || pssb->base.epptr ==
> (char*) -1,
Dec. 24, 2016
Re: [v2 6/7] x86/traps: Fixup general protection faults caused by UMIP
by kbuild test robot
Hi Ricardo,
[auto build test ERROR on tip/auto-latest]
[also build test ERROR on next-20161223]
[cannot apply to tip/x86/core v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ricardo-Neri/x86-enable-User-Mode-…
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from arch/x86/tools/test_get_len.c:27:0:
>> arch/x86/include/asm/insn.h:26:23: fatal error: linux/bug.h: No such file or directory
#include <linux/bug.h>
^
compilation terminated.
--
In file included from tools/include/linux/compiler.h:55:0,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> tools/include/linux/types.h:28:18: error: conflicting types for 'u64'
typedef uint64_t u64;
^~~
In file included from /usr/include/asm-generic/types.h:6:0,
from /usr/include/x86_64-linux-gnu/asm/types.h:4,
from tools/include/linux/types.h:9,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
include/asm-generic/int-ll64.h:25:28: note: previous declaration of 'u64' was here
typedef unsigned long long u64;
^~~
In file included from tools/include/linux/compiler.h:55:0,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> tools/include/linux/types.h:29:17: error: conflicting types for 's64'
typedef int64_t s64;
^~~
In file included from /usr/include/asm-generic/types.h:6:0,
from /usr/include/x86_64-linux-gnu/asm/types.h:4,
from tools/include/linux/types.h:9,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
include/asm-generic/int-ll64.h:24:26: note: previous declaration of 's64' was here
typedef signed long long s64;
^~~
In file included from tools/include/linux/types.h:4:0,
from tools/include/linux/compiler.h:55,
from arch/x86/include/asm/insn.h:25,
from arch/x86/tools/insn_sanity.c:34:
>> include/linux/stddef.h:10:2: error: expected identifier before numeric constant
false = 0,
^
In file included from arch/x86/include/asm/ptrace.h:5:0,
from arch/x86/include/asm/insn.h:28,
from arch/x86/tools/insn_sanity.c:34:
>> arch/x86/include/asm/page_types.h:61:15: error: unknown type name 'phys_addr_t'
static inline phys_addr_t get_max_mapped(void)
^~~~~~~~~~~
arch/x86/include/asm/page_types.h: In function 'get_max_mapped':
>> arch/x86/include/asm/page_types.h:63:10: error: 'phys_addr_t' undeclared (first use in this function)
return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
^~~~~~~~~~~
arch/x86/include/asm/page_types.h:63:10: note: each undeclared identifier is reported only once for each function it appears in
>> arch/x86/include/asm/page_types.h:63:22: error: expected ';' before 'max_pfn_mapped'
return (phys_addr_t)max_pfn_mapped << PAGE_SHIFT;
^~~~~~~~~~~~~~
In file included from arch/x86/include/asm/insn.h:28:0,
from arch/x86/tools/insn_sanity.c:34:
arch/x86/include/asm/ptrace.h: At top level:
>> arch/x86/include/asm/ptrace.h:33:8: error: redefinition of 'struct pt_regs'
struct pt_regs {
^~~~~~~
In file included from arch/x86/include/asm/insn.h:26:0,
from arch/x86/tools/insn_sanity.c:34:
include/linux/bug.h:13:8: note: originally defined here
struct pt_regs;
^~~~~~~
vim +33 arch/x86/include/asm/ptrace.h
92bc2056 include/asm-x86/ptrace.h Harvey Harrison 2008-02-08 27 unsigned long sp;
92bc2056 include/asm-x86/ptrace.h Harvey Harrison 2008-02-08 28 unsigned long ss;
65ea5b03 include/asm-x86/ptrace.h H. Peter Anvin 2008-01-30 29 };
8fc37f2c include/asm-x86/ptrace.h Thomas Gleixner 2007-10-23 30
8fc37f2c include/asm-x86/ptrace.h Thomas Gleixner 2007-10-23 31 #else /* __i386__ */
8fc37f2c include/asm-x86/ptrace.h Thomas Gleixner 2007-10-23 32
65ea5b03 include/asm-x86/ptrace.h H. Peter Anvin 2008-01-30 @33 struct pt_regs {
e90e147c arch/x86/include/asm/ptrace.h Denys Vlasenko 2015-02-26 34 /*
e90e147c arch/x86/include/asm/ptrace.h Denys Vlasenko 2015-02-26 35 * C ABI says these regs are callee-preserved. They aren't saved on kernel entry
e90e147c arch/x86/include/asm/ptrace.h Denys Vlasenko 2015-02-26 36 * unless syscall needs a complete, fully filled "struct pt_regs".
:::::: The code at line 33 was first introduced by commit
:::::: 65ea5b0349903585bfed9720fa06f5edb4f1cd25 x86: rename the struct pt_regs members for 32/64-bit consistency
:::::: TO: H. Peter Anvin <hpa(a)zytor.com>
:::::: CC: Ingo Molnar <mingo(a)elte.hu>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Dec. 24, 2016
Re: [v2 7/7] x86: Enable User-Mode Instruction Prevention
by kbuild test robot
Hi Ricardo,
[auto build test WARNING on tip/auto-latest]
[also build test WARNING on next-20161223]
[cannot apply to tip/x86/core v4.9]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ricardo-Neri/x86-enable-User-Mode-…
config: x86_64-acpi-redef (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All warnings (new ones prefixed by >>):
arch/x86/kernel/umip.c: In function '__identify_insn':
>> arch/x86/kernel/umip.c:65:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
vim +65 arch/x86/kernel/umip.c
78301541 Ricardo Neri 2016-12-23 49 return UMIP_SGDT;
78301541 Ricardo Neri 2016-12-23 50 case 1:
78301541 Ricardo Neri 2016-12-23 51 return UMIP_SIDT;
78301541 Ricardo Neri 2016-12-23 52 case 4:
78301541 Ricardo Neri 2016-12-23 53 return UMIP_SMSW;
78301541 Ricardo Neri 2016-12-23 54 default:
78301541 Ricardo Neri 2016-12-23 55 return -EINVAL;
78301541 Ricardo Neri 2016-12-23 56 }
78301541 Ricardo Neri 2016-12-23 57 } else if (insn->opcode.bytes[1] == 0x0) {
78301541 Ricardo Neri 2016-12-23 58 if (X86_MODRM_REG(insn->modrm.value) == 0)
78301541 Ricardo Neri 2016-12-23 59 return UMIP_SLDT;
78301541 Ricardo Neri 2016-12-23 60 else if (X86_MODRM_REG(insn->modrm.value) == 1)
78301541 Ricardo Neri 2016-12-23 61 return UMIP_STR;
78301541 Ricardo Neri 2016-12-23 62 else
78301541 Ricardo Neri 2016-12-23 63 return -EINVAL;
78301541 Ricardo Neri 2016-12-23 64 }
78301541 Ricardo Neri 2016-12-23 @65 }
78301541 Ricardo Neri 2016-12-23 66
78301541 Ricardo Neri 2016-12-23 67 static int __emulate_umip_insn(struct insn *insn, enum umip_insn umip_inst,
78301541 Ricardo Neri 2016-12-23 68 unsigned char *data, int *data_size)
78301541 Ricardo Neri 2016-12-23 69 {
78301541 Ricardo Neri 2016-12-23 70 unsigned long const *dummy_base_addr;
78301541 Ricardo Neri 2016-12-23 71 unsigned short dummy_limit = 0;
78301541 Ricardo Neri 2016-12-23 72 unsigned short dummy_value = 0;
78301541 Ricardo Neri 2016-12-23 73
:::::: The code at line 65 was first introduced by commit
:::::: 7830154191c35fde49ef59c2b9328f6b32203be4 x86: Add emulation code for UMIP instructions
:::::: TO: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com>
:::::: CC: 0day robot <fengguang.wu(a)intel.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Dec. 24, 2016