Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for multiplication to work around Clang incompatibility

On May 5, 2017 11:44:05 AM PDT, Matthias Kaehlcke wrote: >El Fri, May 05, 2017 at 07:50:39PM +0200 Ingo Molnar ha dit: > >> >> * Peter Zijlstra wrote: >> >> > On Fri, May 05, 2017 at 01:11:47AM -0700, tip-bot for Matthias >Kaehlcke wrote: >> > >

Re: [tip:x86/urgent] x86/mm/kaslr: Use the _ASM_MUL macro for multiplication to work around Clang incompatibility

On May 5, 2017 11:44:05 AM PDT, Matthias Kaehlcke wrote: >El Fri, May 05, 2017 at 07:50:39PM +0200 Ingo Molnar ha dit: > >> >> * Peter Zijlstra wrote: >> >> > On Fri, May 05, 2017 at 01:11:47AM -0700, tip-bot for Matthias >Kaehlcke wrote: >> > > Commit-ID:

Re: [Patch v2] x86/build: require only gcc use -maccumulate-outgoing-args

On May 4, 2017 11:23:33 PM PDT, Ingo Molnar wrote: > >* Nick Desaulniers wrote: > >> Other compilers, like clang, treat unknown compiler flags as errors. >> >> Signed-off-by: Nick Desaulniers >> --- >> arch/x86/Makefile

Re: [Patch v2] x86/build: require only gcc use -maccumulate-outgoing-args

On May 4, 2017 11:23:33 PM PDT, Ingo Molnar wrote: > >* Nick Desaulniers wrote: > >> Other compilers, like clang, treat unknown compiler flags as errors. >> >> Signed-off-by: Nick Desaulniers >> --- >> arch/x86/Makefile | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff

Re: [PATCH v2] x86/mm/kaslr: Use _ASM_MUL macro for multiplication

On April 26, 2017 2:21:25 PM PDT, Kees Cook wrote: >On Wed, Apr 26, 2017 at 2:00 PM, wrote: >> On April 26, 2017 1:55:04 PM PDT, Matthias Kaehlcke > wrote: >>>In difference to gas clang doesn't seem to infer the size from the

Re: [PATCH v2] x86/mm/kaslr: Use _ASM_MUL macro for multiplication

On April 26, 2017 2:21:25 PM PDT, Kees Cook wrote: >On Wed, Apr 26, 2017 at 2:00 PM, wrote: >> On April 26, 2017 1:55:04 PM PDT, Matthias Kaehlcke > wrote: >>>In difference to gas clang doesn't seem to infer the size from the >>>operands. Add and use the _ASM_MUL macro which determines the

Re: [PATCH v2] x86/mm/kaslr: Use _ASM_MUL macro for multiplication

On April 26, 2017 1:55:04 PM PDT, Matthias Kaehlcke wrote: >In difference to gas clang doesn't seem to infer the size from the >operands. Add and use the _ASM_MUL macro which determines the operand >size and resolves to the 'mul' instruction with the corresponding >suffix. >

Re: [PATCH v2] x86/mm/kaslr: Use _ASM_MUL macro for multiplication

On April 26, 2017 1:55:04 PM PDT, Matthias Kaehlcke wrote: >In difference to gas clang doesn't seem to infer the size from the >operands. Add and use the _ASM_MUL macro which determines the operand >size and resolves to the 'mul' instruction with the corresponding >suffix. > >This fixes the

Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

On April 13, 2017 5:23:35 PM PDT, Matthias Kaehlcke wrote: >El Thu, Apr 13, 2017 at 04:55:00PM -0700 H. Peter Anvin ha dit: > >> On 04/13/17 16:14, Matthias Kaehlcke wrote: >> > El Mon, Apr 03, 2017 at 04:01:58PM -0700 Matthias Kaehlcke ha dit: >> > >> >> El Fri, Mar 17, 2017

Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

On April 13, 2017 5:23:35 PM PDT, Matthias Kaehlcke wrote: >El Thu, Apr 13, 2017 at 04:55:00PM -0700 H. Peter Anvin ha dit: > >> On 04/13/17 16:14, Matthias Kaehlcke wrote: >> > El Mon, Apr 03, 2017 at 04:01:58PM -0700 Matthias Kaehlcke ha dit: >> > >> >> El Fri, Mar 17, 2017 at 04:50:19PM -0700

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

On April 13, 2017 8:51:19 PM PDT, Gary Lin wrote: >On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote: >> On April 11, 2017 3:20:41 AM PDT, Gary Lin wrote: >> >This commit adds the new config options to allow the user to modify >the >> >following fields

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

On April 13, 2017 8:51:19 PM PDT, Gary Lin wrote: >On Thu, Apr 13, 2017 at 03:21:20PM -0700, h...@zytor.com wrote: >> On April 11, 2017 3:20:41 AM PDT, Gary Lin wrote: >> >This commit adds the new config options to allow the user to modify >the >> >following fields in the PE-COFF header. >> > >>

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

On April 11, 2017 3:20:41 AM PDT, Gary Lin wrote: >This commit adds the new config options to allow the user to modify the >following fields in the PE-COFF header. > >UINT16 MajorOperatingSystemVersion >UINT16 MinorOperatingSystemVersion >UINT16 MajorImageVersion >UINT16

Re: [RFC PATCH] x86: Config options to assign versions in the PE-COFF header

On April 11, 2017 3:20:41 AM PDT, Gary Lin wrote: >This commit adds the new config options to allow the user to modify the >following fields in the PE-COFF header. > >UINT16 MajorOperatingSystemVersion >UINT16 MinorOperatingSystemVersion >UINT16 MajorImageVersion >UINT16 MinorImageVersion >

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On April 7, 2017 8:59:45 AM PDT, "Kirill A. Shutemov" wrote: >On Fri, Apr 07, 2017 at 07:05:26PM +0530, Anshuman Khandual wrote: >> On 04/06/2017 07:31 PM, Kirill A. Shutemov wrote: >> > On x86, 5-level paging enables 56-bit userspace virtual address >space. >> > Not all

Re: [PATCH 8/8] x86/mm: Allow to have userspace mappings above 47-bits

On April 7, 2017 8:59:45 AM PDT, "Kirill A. Shutemov" wrote: >On Fri, Apr 07, 2017 at 07:05:26PM +0530, Anshuman Khandual wrote: >> On 04/06/2017 07:31 PM, Kirill A. Shutemov wrote: >> > On x86, 5-level paging enables 56-bit userspace virtual address >space. >> > Not all user space is ready to

Re: [tip:x86/asm] debug: Fix __bug_table[] in arch linker scripts

On April 3, 2017 1:27:49 AM PDT, tip-bot for Peter Zijlstra wrote: >Commit-ID: b5effd3815ccbe3df1a015a6d67d8a24a27813d5 >Gitweb: >http://git.kernel.org/tip/b5effd3815ccbe3df1a015a6d67d8a24a27813d5 >Author: Peter Zijlstra >AuthorDate: Thu, 30 Mar

Re: [tip:x86/asm] debug: Fix __bug_table[] in arch linker scripts

On April 3, 2017 1:27:49 AM PDT, tip-bot for Peter Zijlstra wrote: >Commit-ID: b5effd3815ccbe3df1a015a6d67d8a24a27813d5 >Gitweb: >http://git.kernel.org/tip/b5effd3815ccbe3df1a015a6d67d8a24a27813d5 >Author: Peter Zijlstra >AuthorDate: Thu, 30 Mar 2017 17:49:27 +0200 >Committer: Ingo

Re: [PATCH] x86/fpu: move FPU state into separate cache

On March 29, 2017 2:41:00 PM PDT, Linus Torvalds wrote: >On Wed, Mar 29, 2017 at 2:35 PM, Andy Lutomirski >wrote: >> >> Randomization also needs to leave thread_info at the beginning. Can >it do that? > >Good point, and good question. No idea

Re: [PATCH] x86/fpu: move FPU state into separate cache

On March 29, 2017 2:41:00 PM PDT, Linus Torvalds wrote: >On Wed, Mar 29, 2017 at 2:35 PM, Andy Lutomirski >wrote: >> >> Randomization also needs to leave thread_info at the beginning. Can >it do that? > >Good point, and good question. No idea if the gcc extension can do, >but yes, it clearly

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 3:21:13 PM PDT, Thomas Gleixner <t...@linutronix.de> wrote: >On Tue, 21 Mar 2017, Dmitry Safonov wrote: >> v3: >> - clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA). > >For correctness sake, this wants to be cleared in the IA32 path

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 3:21:13 PM PDT, Thomas Gleixner wrote: >On Tue, 21 Mar 2017, Dmitry Safonov wrote: >> v3: >> - clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA). > >For correctness sake, this wants to be cleared in the IA32 path as >well

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 2:16:48 PM PDT, Adam Borowski wrote: >On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: >> After my changes to mmap(), its code now relies on the bitness of >> performing syscall. According to that, it chooses the base of >allocation: >>

Re: [PATCHv3] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 2:16:48 PM PDT, Adam Borowski wrote: >On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote: >> After my changes to mmap(), its code now relies on the bitness of >> performing syscall. According to that, it chooses the base of >allocation: >> mmap_base for 64-bit mmap()

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 12:07:13 PM PDT, Cyrill Gorcunov wrote: >On Tue, Mar 21, 2017 at 11:51:09AM -0700, h...@zytor.com wrote: >> > >> >indeed, thanks! >> >> I proposed to the ptrace people a virtual register for this and a few >other things, but it got bikeshed to death. > >Any

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 12:07:13 PM PDT, Cyrill Gorcunov wrote: >On Tue, Mar 21, 2017 at 11:51:09AM -0700, h...@zytor.com wrote: >> > >> >indeed, thanks! >> >> I proposed to the ptrace people a virtual register for this and a few >other things, but it got bikeshed to death. > >Any mail reference left?

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 10:45:57 AM PDT, Andy Lutomirski wrote: >On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov >wrote: >> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote: >> ... >>> diff --git a/arch/x86/kernel/process_64.c

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 10:45:57 AM PDT, Andy Lutomirski wrote: >On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov >wrote: >> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote: >> ... >>> diff --git a/arch/x86/kernel/process_64.c >b/arch/x86/kernel/process_64.c >>> index

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 11:40:58 AM PDT, Cyrill Gorcunov wrote: >On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote: >> >> I guess the question comes from that we're releasing CRIU 3.0 with >> 32-bit C/R and some other cool stuff, but we don't support x32 yet. >> As we

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 11:40:58 AM PDT, Cyrill Gorcunov wrote: >On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote: >> >> I guess the question comes from that we're releasing CRIU 3.0 with >> 32-bit C/R and some other cool stuff, but we don't support x32 yet. >> As we don't want release a

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 9:37:12 AM PDT, Dmitry Safonov wrote: >After my changes to mmap(), its code now relies on the bitness of >performing syscall. According to that, it chooses the base of >allocation: >mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall. >It

Re: [PATCHv2] x86/mm: set x32 syscall bit in SET_PERSONALITY()

On March 21, 2017 9:37:12 AM PDT, Dmitry Safonov wrote: >After my changes to mmap(), its code now relies on the bitness of >performing syscall. According to that, it chooses the base of >allocation: >mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall. >It was done by: > commit

Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

On March 19, 2017 1:26:58 AM PDT, "Kirill A. Shutemov" wrote: >On Mar 19, 2017 09:25, "Aneesh Kumar K.V" > >wrote: > >"Kirill A. Shutemov" writes: > >> On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:

Re: [PATCH 26/26] x86/mm: allow to have userspace mappings above 47-bits

On March 19, 2017 1:26:58 AM PDT, "Kirill A. Shutemov" wrote: >On Mar 19, 2017 09:25, "Aneesh Kumar K.V" > >wrote: > >"Kirill A. Shutemov" writes: > >> On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote: >>> "Kirill A. Shutemov" writes: >>> >>> > On x86, 5-level paging enables

Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

On March 16, 2017 5:15:16 PM PDT, Michael Davidson wrote: >Suppress clang warnings about potential unaliged accesses >to members in packed structs. This gets rid of almost 10,000 >warnings about accesses to the ring 0 stack pointer in the TSS. > >Signed-off-by: Michael Davidson

Re: [PATCH 3/7] x86, LLVM: suppress clang warnings about unaligned accesses

On March 16, 2017 5:15:16 PM PDT, Michael Davidson wrote: >Suppress clang warnings about potential unaliged accesses >to members in packed structs. This gets rid of almost 10,000 >warnings about accesses to the ring 0 stack pointer in the TSS. > >Signed-off-by: Michael Davidson >--- >

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

On March 17, 2017 12:27:46 PM PDT, Peter Zijlstra wrote: >On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote: >> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra > wrote: >> > >> > Be that as it may; what you construct above is disgusting.

Re: [PATCH 6/7] md/raid10, LLVM: get rid of variable length array

On March 17, 2017 12:27:46 PM PDT, Peter Zijlstra wrote: >On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote: >> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra > wrote: >> > >> > Be that as it may; what you construct above is disgusting. Surely >the >> > code can be refactored to

Re: Question Regarding ERMS memcpy

On March 6, 2017 9:12:41 AM PST, Logan Gunthorpe wrote: > > >On 06/03/17 12:28 AM, H. Peter Anvin wrote: >> On 03/05/17 23:01, Logan Gunthorpe wrote: >>> >>> On 05/03/17 12:54 PM, Borislav Petkov wrote: Logan, wanna give that a try, see if it takes care of your issue?

Re: Question Regarding ERMS memcpy

On March 6, 2017 9:12:41 AM PST, Logan Gunthorpe wrote: > > >On 06/03/17 12:28 AM, H. Peter Anvin wrote: >> On 03/05/17 23:01, Logan Gunthorpe wrote: >>> >>> On 05/03/17 12:54 PM, Borislav Petkov wrote: Logan, wanna give that a try, see if it takes care of your issue? >>> >>> Well honestly

Re: Question Regarding ERMS memcpy

On March 6, 2017 5:33:28 AM PST, Borislav Petkov wrote: >On Mon, Mar 06, 2017 at 12:01:10AM -0700, Logan Gunthorpe wrote: >> Well honestly my issue was solved by fixing my kernel config. I have >no >> idea why I had optimize for size in there in the first place. > >I still think

Re: Question Regarding ERMS memcpy

On March 6, 2017 5:33:28 AM PST, Borislav Petkov wrote: >On Mon, Mar 06, 2017 at 12:01:10AM -0700, Logan Gunthorpe wrote: >> Well honestly my issue was solved by fixing my kernel config. I have >no >> idea why I had optimize for size in there in the first place. > >I still think that we should

Re: Question Regarding ERMS memcpy

On March 4, 2017 4:33:49 PM PST, Borislav Petkov wrote: >On Sat, Mar 04, 2017 at 04:23:17PM -0800, h...@zytor.com wrote: >> What are the compilation flags? It may be that gcc still does TRT >> depending on this call site. I'd check what gcc6 or 7 generates, >> though. > >Well, I

Re: Question Regarding ERMS memcpy

On March 4, 2017 4:33:49 PM PST, Borislav Petkov wrote: >On Sat, Mar 04, 2017 at 04:23:17PM -0800, h...@zytor.com wrote: >> What are the compilation flags? It may be that gcc still does TRT >> depending on this call site. I'd check what gcc6 or 7 generates, >> though. > >Well, I don't think that

Re: Question Regarding ERMS memcpy

On March 4, 2017 4:14:47 PM PST, Borislav Petkov wrote: >On Sat, Mar 04, 2017 at 03:55:27PM -0800, h...@zytor.com wrote: >> For newer processors, as determined by -mtune=, it is actually the >> best option for an arbitrary copy. > >So his doesn't have ERMS - it is a SNB - so if for

Re: Question Regarding ERMS memcpy

On March 4, 2017 4:14:47 PM PST, Borislav Petkov wrote: >On Sat, Mar 04, 2017 at 03:55:27PM -0800, h...@zytor.com wrote: >> For newer processors, as determined by -mtune=, it is actually the >> best option for an arbitrary copy. > >So his doesn't have ERMS - it is a SNB - so if for SNB REP_GOOD

Re: Question Regarding ERMS memcpy

On March 4, 2017 3:46:44 PM PST, Logan Gunthorpe wrote: >Hi Borislav, > >Thanks for the help. > >On 04/03/17 03:43 PM, Borislav Petkov wrote: >> You can boot with "debug-alternative" and look for those strings >where > >Here's the symbols for memcpy and the corresponding

Re: Question Regarding ERMS memcpy

On March 4, 2017 3:46:44 PM PST, Logan Gunthorpe wrote: >Hi Borislav, > >Thanks for the help. > >On 04/03/17 03:43 PM, Borislav Petkov wrote: >> You can boot with "debug-alternative" and look for those strings >where > >Here's the symbols for memcpy and the corresponding apply_alternatives

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: > >* Thomas Gleixner wrote: > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: >> > >> > * Jiri Slaby wrote: >> > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >END,

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: > >* Thomas Gleixner wrote: > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: >> > >> > * Jiri Slaby wrote: >> > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >END, >> > > and other macros across x86. When we have all

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: > >* Thomas Gleixner wrote: > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: >> > >> > * Jiri Slaby wrote: >> > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >END,

Re: [PATCH 01/10] x86: assembly, ENTRY for fn, GLOBAL for data

On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote: > >* Thomas Gleixner wrote: > >> On Wed, 1 Mar 2017, Ingo Molnar wrote: >> > >> > * Jiri Slaby wrote: >> > >> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL, >END, >> > > and other macros across x86. When we have all

Re: [PATCH v2] x86/uapi: fix asm/signal.h userspace compilation error

On March 1, 2017 4:18:54 PM PST, "Dmitry V. Levin" wrote: >Replace size_t to fix the following asm/signal.h userspace compilation >error: > >/usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' > size_t ss_size; > >size_t is replaced with __kernel_size_t in all

Re: [PATCH v2] x86/uapi: fix asm/signal.h userspace compilation error

On March 1, 2017 4:18:54 PM PST, "Dmitry V. Levin" wrote: >Replace size_t to fix the following asm/signal.h userspace compilation >error: > >/usr/include/asm/signal.h:126:2: error: unknown type name 'size_t' > size_t ss_size; > >size_t is replaced with __kernel_size_t in all cases except x32

Re: [PATCH] objtool, module: discard __unreachable section for modules

On March 1, 2017 9:01:54 AM PST, Linus Torvalds wrote: >On Wed, Mar 1, 2017 at 8:44 AM, wrote: >> >> I would like to see a name like, say, ".annot.unreachable", since is >odds are pretty high we are going to need more annotations in the >future. >

Re: [PATCH] objtool, module: discard __unreachable section for modules

On March 1, 2017 9:01:54 AM PST, Linus Torvalds wrote: >On Wed, Mar 1, 2017 at 8:44 AM, wrote: >> >> I would like to see a name like, say, ".annot.unreachable", since is >odds are pretty high we are going to need more annotations in the >future. > >Why not just make it ".discard.unreachable",

Re: [PATCH] objtool, module: discard __unreachable section for modules

On March 1, 2017 7:20:03 AM PST, Josh Poimboeuf wrote: >The __unreachable section is only used at compile time. It's discarded >for vmlinux but it should also be discarded for modules. > >Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other >dead ends")

Re: [PATCH] objtool, module: discard __unreachable section for modules

On March 1, 2017 7:20:03 AM PST, Josh Poimboeuf wrote: >The __unreachable section is only used at compile time. It's discarded >for vmlinux but it should also be discarded for modules. > >Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other >dead ends") >Signed-off-by: Josh

Re: [tip:core/urgent] objtool: Fix __unreachable section relocation size

On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf wrote: >Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 >Gitweb: >http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 >Author: Josh Poimboeuf >AuthorDate: Wed, 1 Mar

Re: [tip:core/urgent] objtool: Fix __unreachable section relocation size

On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf wrote: >Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 >Gitweb: >http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5 >Author: Josh Poimboeuf >AuthorDate: Wed, 1 Mar 2017 00:05:04 -0600 >Committer: Ingo

Re: [PATCH] x86: Implement __WARN using UD0

On February 25, 2017 11:38:44 AM PST, Borislav Petkov wrote: >On Sat, Feb 25, 2017 at 09:55:45AM -0800, h...@zytor.com wrote: >> You mean like the INT instruction? > >Right, you mentioned reusing INT $9 upthread. > >That doesn't have the additional info in the immed8 - it is the

Re: [PATCH] x86: Implement __WARN using UD0

On February 25, 2017 11:38:44 AM PST, Borislav Petkov wrote: >On Sat, Feb 25, 2017 at 09:55:45AM -0800, h...@zytor.com wrote: >> You mean like the INT instruction? > >Right, you mentioned reusing INT $9 upthread. > >That doesn't have the additional info in the immed8 - it is the vector >in this

Re: [PATCH] x86: Implement __WARN using UD0

On February 25, 2017 2:38:08 AM PST, Borislav Petkov wrote: >On Fri, Feb 24, 2017 at 11:41:33AM +0100, Peter Zijlstra wrote: >> So yes, its tricky but it could be done. A new single byte #UD >> instruction would be much nicer though. > >Btw, if we did a new insn which means new

Re: [PATCH] x86: Implement __WARN using UD0

On February 25, 2017 2:38:08 AM PST, Borislav Petkov wrote: >On Fri, Feb 24, 2017 at 11:41:33AM +0100, Peter Zijlstra wrote: >> So yes, its tricky but it could be done. A new single byte #UD >> instruction would be much nicer though. > >Btw, if we did a new insn which means new functionality

Re: [PATCH] x86: Implement __WARN using UD0

On February 24, 2017 12:31:15 AM PST, Peter Zijlstra wrote: >On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote: >> The only high level question is whether we trust the trap machinery >to generate >> WARN_ON()s. I believe we do. >> >> BTW.: why not use INT3

Re: [PATCH] x86: Implement __WARN using UD0

On February 24, 2017 12:31:15 AM PST, Peter Zijlstra wrote: >On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote: >> The only high level question is whether we trust the trap machinery >to generate >> WARN_ON()s. I believe we do. >> >> BTW.: why not use INT3 instead of all these weird

Re: [PATCH] x86: Implement __WARN using UD0

On February 24, 2017 12:31:15 AM PST, Peter Zijlstra wrote: >On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote: >> The only high level question is whether we trust the trap machinery >to generate >> WARN_ON()s. I believe we do. >> >> BTW.: why not use INT3

Re: [PATCH] x86: Implement __WARN using UD0

On February 24, 2017 12:31:15 AM PST, Peter Zijlstra wrote: >On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote: >> The only high level question is whether we trust the trap machinery >to generate >> WARN_ON()s. I believe we do. >> >> BTW.: why not use INT3 instead of all these weird

Re: [PATCH] x86: Implement __WARN using UD0

On February 23, 2017 7:23:09 AM PST, Peter Zijlstra wrote: >On Thu, Feb 23, 2017 at 07:09:05AM -0800, h...@zytor.com wrote: >> Well, it only matters if the instruction extends past a segment >> boundary or page. However, the CPU instruction decoder will consume >a >> modrm

Re: [PATCH] x86: Implement __WARN using UD0

On February 23, 2017 7:23:09 AM PST, Peter Zijlstra wrote: >On Thu, Feb 23, 2017 at 07:09:05AM -0800, h...@zytor.com wrote: >> Well, it only matters if the instruction extends past a segment >> boundary or page. However, the CPU instruction decoder will consume >a >> modrm for UD1, and so using

Re: [PATCH] x86: Implement __WARN using UD0

[ 0f b9] > 186,UNDOC,ND >1381 UD2 void[ 0f 0b] > 186 >1382 UD2Avoid[ 0f 0b] > 186,ND

Re: [PATCH] x86: Implement __WARN using UD0

186,UNDOC,ND >1381 UD2 void[ 0f 0b] > 186 >1382 UD2Avoid[ 0f 0b] > 186,ND > >which seems to use the 2 byte

Re: RFC: Getting rid of LTR in VMX

On February 20, 2017 2:02:53 PM PST, Paolo Bonzini wrote: > >> > Yes. But 150-200 clock cycles are nothing compared to the cache >misses >> > you get from preemption, so I'd ignore that. Saving 300 clock >cycles on >> > userspace exits from TR+GSBASE would be about 5% on my

Re: RFC: Getting rid of LTR in VMX

On February 20, 2017 2:02:53 PM PST, Paolo Bonzini wrote: > >> > Yes. But 150-200 clock cycles are nothing compared to the cache >misses >> > you get from preemption, so I'd ignore that. Saving 300 clock >cycles on >> > userspace exits from TR+GSBASE would be about 5% on my Haswell. >> >>

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On February 17, 2017 3:02:33 PM PST, Andy Lutomirski wrote: >On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds > wrote: >> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski > wrote: >>> >>> At the very least, I'd want to see

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On February 17, 2017 3:02:33 PM PST, Andy Lutomirski wrote: >On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds > wrote: >> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski > wrote: >>> >>> At the very least, I'd want to see >>> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING. I *hate* the current >>>

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On February 17, 2017 1:10:27 PM PST, Linus Torvalds wrote: >On Fri, Feb 17, 2017 at 1:04 PM, Dave Hansen >wrote: >> >> Is this likely to break anything in practice? Nah. But it would >nice >> to avoid it. > >So I go the other way: what *I*

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

On February 17, 2017 1:10:27 PM PST, Linus Torvalds wrote: >On Fri, Feb 17, 2017 at 1:04 PM, Dave Hansen >wrote: >> >> Is this likely to break anything in practice? Nah. But it would >nice >> to avoid it. > >So I go the other way: what *I* would like to avoid is odd code that >is hard to

Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able

On February 15, 2017 12:13:36 PM PST, "Luis R. Rodriguez" wrote: >On Wed, Feb 15, 2017 at 10:12:07AM -0800, h...@zytor.com wrote: >> On February 15, 2017 6:41:56 AM PST, Chao Peng > wrote: >> >Multiboot specification >>

Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able

On February 15, 2017 12:13:36 PM PST, "Luis R. Rodriguez" wrote: >On Wed, Feb 15, 2017 at 10:12:07AM -0800, h...@zytor.com wrote: >> On February 15, 2017 6:41:56 AM PST, Chao Peng > wrote: >> >Multiboot specification >>

Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able

On February 15, 2017 6:41:56 AM PST, Chao Peng wrote: >Multiboot specification >(http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2) >is an open standard that provides kernels with a uniform way to be >booted >by multiboot-compliant

Re: [RFC PATCH] x86/boot: make ELF kernel multiboot-able

On February 15, 2017 6:41:56 AM PST, Chao Peng wrote: >Multiboot specification >(http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2) >is an open standard that provides kernels with a uniform way to be >booted >by multiboot-compliant bootloaders (like grub). > >This

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 2:34:01 PM PST, Waiman Long wrote: >On 02/13/2017 04:52 PM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: >>> On 02/13/2017 02:42 PM, Waiman Long wrote: On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > On

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 2:34:01 PM PST, Waiman Long wrote: >On 02/13/2017 04:52 PM, Peter Zijlstra wrote: >> On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: >>> On 02/13/2017 02:42 PM, Waiman Long wrote: On 02/13/2017 05:53 AM, Peter Zijlstra wrote: > On Mon, Feb 13, 2017 at

Re: [PATCHv3] x86/selftests: add clobbers for int80 on x86_64

On February 13, 2017 11:06:04 AM PST, Andy Lutomirski wrote: >On Mon, Feb 13, 2017 at 2:13 AM, Dmitry Safonov > wrote: >> Kernel erases R8..R11 registers prior returning to userspace >> from int80: https://lkml.org/lkml/2009/10/1/164 >> >> GCC can

Re: [PATCHv3] x86/selftests: add clobbers for int80 on x86_64

On February 13, 2017 11:06:04 AM PST, Andy Lutomirski wrote: >On Mon, Feb 13, 2017 at 2:13 AM, Dmitry Safonov > wrote: >> Kernel erases R8..R11 registers prior returning to userspace >> from int80: https://lkml.org/lkml/2009/10/1/164 >> >> GCC can reuse this registers and doesn't expect them to

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 1:52:20 PM PST, Peter Zijlstra wrote: >On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: >> On 02/13/2017 02:42 PM, Waiman Long wrote: >> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: >> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 1:52:20 PM PST, Peter Zijlstra wrote: >On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: >> On 02/13/2017 02:42 PM, Waiman Long wrote: >> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: >> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: >> >>>

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 1:52:20 PM PST, Peter Zijlstra wrote: >On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: >> On 02/13/2017 02:42 PM, Waiman Long wrote: >> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: >> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 1:52:20 PM PST, Peter Zijlstra wrote: >On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote: >> On 02/13/2017 02:42 PM, Waiman Long wrote: >> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote: >> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: >> >>>

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 2:53:43 AM PST, Peter Zijlstra wrote: >On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: >> That way we'd end up with something like: >> >> asm(" >> push %rdi; >> movslq %edi, %rdi; >> movq __per_cpu_offset(,%rdi,8), %rax; >> cmpb $0,

Re: [PATCH v2] x86/paravirt: Don't make vcpu_is_preempted() a callee-save function

On February 13, 2017 2:53:43 AM PST, Peter Zijlstra wrote: >On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote: >> That way we'd end up with something like: >> >> asm(" >> push %rdi; >> movslq %edi, %rdi; >> movq __per_cpu_offset(,%rdi,8), %rax; >> cmpb $0, %[offset](%rax); >> setne

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On February 1, 2017 11:16:00 PM PST, Ingo Molnar wrote: > >* Nicolas Iooss wrote: > >> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains: >> >> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument >of >> type ‘long long int’, but

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On February 1, 2017 11:16:00 PM PST, Ingo Molnar wrote: > >* Nicolas Iooss wrote: > >> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains: >> >> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument >of >> type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long >>

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On January 31, 2017 10:52:11 AM PST, Nicolas Iooss wrote: >Hello, > >As I have not received any comment on the patch I sent in December, I >am >wondering whether I did anything wrong with it. How can I get it queued >for the next merge window? > >Thanks, >Nicolas >

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

On January 31, 2017 10:52:11 AM PST, Nicolas Iooss wrote: >Hello, > >As I have not received any comment on the patch I sent in December, I >am >wondering whether I did anything wrong with it. How can I get it queued >for the next merge window? > >Thanks, >Nicolas > >On 18/12/16 20:47, Nicolas

Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

On January 10, 2017 1:04:15 AM PST, Borislav Petkov wrote: >On Mon, Jan 09, 2017 at 04:19:29PM -0800, h...@zytor.com wrote: >> Any reason to not make these interfaces (leaf, subleaf) from the >start? > >Two, actually: > >1. I modelled them after the cpuid_(op) versions You are

Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

On January 10, 2017 1:04:15 AM PST, Borislav Petkov wrote: >On Mon, Jan 09, 2017 at 04:19:29PM -0800, h...@zytor.com wrote: >> Any reason to not make these interfaces (leaf, subleaf) from the >start? > >Two, actually: > >1. I modelled them after the cpuid_(op) versions You are introducing a new

Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

On January 9, 2017 2:16:07 PM PST, tip-bot for Borislav Petkov wrote: >Commit-ID: 5dedade6dfa243c130b85d1e4daba6f027805033 >Gitweb: >http://git.kernel.org/tip/5dedade6dfa243c130b85d1e4daba6f027805033 >Author: Borislav Petkov >AuthorDate: Mon, 9 Jan 2017

Re: [tip:x86/urgent] x86/CPU: Add native CPUID variants returning a single datum

On January 9, 2017 2:16:07 PM PST, tip-bot for Borislav Petkov wrote: >Commit-ID: 5dedade6dfa243c130b85d1e4daba6f027805033 >Gitweb: >http://git.kernel.org/tip/5dedade6dfa243c130b85d1e4daba6f027805033 >Author: Borislav Petkov >AuthorDate: Mon, 9 Jan 2017 12:41:43 +0100 >Committer:

<    1   2   3   4   5   >