[PATCH 08/10] x86, asm: Use CC_SET()/CC_OUT() in

From: "H. Peter Anvin" Remove open-coded uses of set instructions to use CC_SET()/CC_OUT() in . Signed-off-by: H. Peter Anvin --- arch/x86/include/asm/rwsem.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/rwsem.h b/arch/x86/include/a

[PATCH 01/10] x86, bitops: remove use of "sbb" to return CF

From: "H. Peter Anvin" <h...@zytor.com> Use SETC instead of SBB to return the value of CF from assembly. Using SETcc enables uniformity with other flags-returning pieces of assembly code. Signed-off-by: H. Peter Anvin <h...@zytor.com> --- arch/x86/include/

[PATCH 01/10] x86, bitops: remove use of "sbb" to return CF

From: "H. Peter Anvin" Use SETC instead of SBB to return the value of CF from assembly. Using SETcc enables uniformity with other flags-returning pieces of assembly code. Signed-off-by: H. Peter Anvin --- arch/x86/include/asm/bitops.h | 24 arch/x86/i

[PATCH 06/10] x86, asm: Use CC_SET()/CC_OUT() in

From: "H. Peter Anvin" <h...@zytor.com> Remove open-coded uses of set instructions to use CC_SET()/CC_OUT() in . Signed-off-by: H. Peter Anvin <h...@zytor.com> --- arch/x86/include/asm/bitops.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --

[PATCH 06/10] x86, asm: Use CC_SET()/CC_OUT() in

From: "H. Peter Anvin" Remove open-coded uses of set instructions to use CC_SET()/CC_OUT() in . Signed-off-by: H. Peter Anvin --- arch/x86/include/asm/bitops.h | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/x86/include/asm/bitops.h b/arch/x

[PATCH 10/10] x86, asm, boot: Use CC_SET()/CC_OUT() in arch/x86/boot/boot.h

Remove open-coded uses of set instructions to use CC_SET()/CC_OUT() in arch/x86/boot/boot.h. Signed-off-by: H. Peter Anvin <h...@linux.intel.com> --- arch/x86/boot/boot.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/

[PATCH 10/10] x86, asm, boot: Use CC_SET()/CC_OUT() in arch/x86/boot/boot.h

Remove open-coded uses of set instructions to use CC_SET()/CC_OUT() in arch/x86/boot/boot.h. Signed-off-by: H. Peter Anvin --- arch/x86/boot/boot.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/x86/boot/boot.h b/arch/x86/boot/boot.h index 2edb2d5..7c1495f

Re: [PATCH][RFC] x86, hotplug: Use zero page for monitor when resuming from hibernation

On 06/06/16 09:40, Peter Zijlstra wrote: > On Mon, Jun 06, 2016 at 03:59:06PM +, Chen, Yu C wrote: > + if (hibernation_in_resume()) + mwait_ptr = empty_zero_page; + else + mwait_ptr = _thread_info()->flags; >>> >>> Why is this conditional? Is there any

Re: [PATCH][RFC] x86, hotplug: Use zero page for monitor when resuming from hibernation

On 06/06/16 09:40, Peter Zijlstra wrote: > On Mon, Jun 06, 2016 at 03:59:06PM +, Chen, Yu C wrote: > + if (hibernation_in_resume()) + mwait_ptr = empty_zero_page; + else + mwait_ptr = _thread_info()->flags; >>> >>> Why is this conditional? Is there any

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

On 06/02/16 13:22, Eric W. Biederman wrote: > > The problem with lookup_one_len_unlocked is that it still calls > inode_permission. > > As per previous discussions we don't want the path based permission > checks involved in that lookup. > Is it that we don't *want* it, or that we don't *need*

Re: [PATCH tty-next] devpts: Make each mount of devpts an independent filesystem.

On 06/02/16 13:22, Eric W. Biederman wrote: > > The problem with lookup_one_len_unlocked is that it still calls > inode_permission. > > As per previous discussions we don't want the path based permission > checks involved in that lookup. > Is it that we don't *want* it, or that we don't *need*

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/17/16 12:28, Kees Cook wrote: >> >> I think there is something way more subtle going on here, and it bothers >> me exactly because it is subtle. It may be that it is OK right now, but >> there are alarm bells going on all over my brain on this. I'm going to >> stare at this for a bit and

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/17/16 12:28, Kees Cook wrote: >> >> I think there is something way more subtle going on here, and it bothers >> me exactly because it is subtle. It may be that it is OK right now, but >> there are alarm bells going on all over my brain on this. I'm going to >> stare at this for a bit and

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/17/16 06:53, Kees Cook wrote: >> >> Either look at the inputs, or add the -q option to the link line >> (--emit-relocs); that preserves the relocations into the output file >> (the same we use to generate the relocation tables to be able to >> relocate the kernel proper.) > > (FWIW, this

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/17/16 06:53, Kees Cook wrote: >> >> Either look at the inputs, or add the -q option to the link line >> (--emit-relocs); that preserves the relocations into the output file >> (the same we use to generate the relocation tables to be able to >> relocate the kernel proper.) > > (FWIW, this

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/17/16 01:13, Kees Cook wrote: > On Mon, May 16, 2016 at 3:30 AM, Ingo Molnar <mi...@kernel.org> wrote: >> >> * H. Peter Anvin <h...@zytor.com> wrote: >> >>> On 05/12/16 15:54, Kees Cook wrote: >>>>> >>>>> It would be far

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/17/16 01:13, Kees Cook wrote: > On Mon, May 16, 2016 at 3:30 AM, Ingo Molnar wrote: >> >> * H. Peter Anvin wrote: >> >>> On 05/12/16 15:54, Kees Cook wrote: >>>>> >>>>> It would be far better to warn on the *type* of relocations

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 16, 2016 10:06:08 AM PDT, Peter Zijlstra wrote: >On Mon, May 16, 2016 at 11:49:05PM +0800, Zhaoxiu Zeng wrote: >> On 2016/5/11 17:31, Peter Zijlstra wrote: >> > Please use the GEN_*_RMWcc() stuff to avoid the setpo where >possible. >> >> Setpo is better. >> In most

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 16, 2016 10:06:08 AM PDT, Peter Zijlstra wrote: >On Mon, May 16, 2016 at 11:49:05PM +0800, Zhaoxiu Zeng wrote: >> On 2016/5/11 17:31, Peter Zijlstra wrote: >> > Please use the GEN_*_RMWcc() stuff to avoid the setpo where >possible. >> >> Setpo is better. >> In most cases, we need to store

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 11, 2016 2:31:39 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 05:16:38PM +0800, zengzhao...@163.com wrote: > >> +static inline unsigned int __arch_parity4(unsigned int w) >> +{ >> +unsigned int res = 0; >> + >> +asm("test $0xf, %1; setpo %b0" >> +

Re: [patch V4 09/31] bitops: Add x86-specific parity functions

On May 11, 2016 2:31:39 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 05:16:38PM +0800, zengzhao...@163.com wrote: > >> +static inline unsigned int __arch_parity4(unsigned int w) >> +{ >> +unsigned int res = 0; >> + >> +asm("test $0xf, %1; setpo %b0" >> +: "+q" (res)

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/12/16 15:54, Kees Cook wrote: >> >> It would be far better to warn on the *type* of relocations rather than in >> which section they feel. > > I'm open to specific changes. What's the best way to detect what you want > here? > Use readelf -r and look for inappropriate relocation types

Re: [PATCH] x86/boot: Refuse to build with data relocations

On 05/12/16 15:54, Kees Cook wrote: >> >> It would be far better to warn on the *type* of relocations rather than in >> which section they feel. > > I'm open to specific changes. What's the best way to detect what you want > here? > Use readelf -r and look for inappropriate relocation types

Re: [PATCH] x86/boot: Refuse to build with data relocations

On May 12, 2016 1:31:04 PM PDT, Kees Cook wrote: >The compressed kernel is built with -fPIC/-fPIE so that it can run in >any >location a bootloader happens to put it. However, since ELF relocation >processing is not happening (and all the relocation information has >already

Re: [PATCH] x86/boot: Refuse to build with data relocations

On May 12, 2016 1:31:04 PM PDT, Kees Cook wrote: >The compressed kernel is built with -fPIC/-fPIE so that it can run in >any >location a bootloader happens to put it. However, since ELF relocation >processing is not happening (and all the relocation information has >already been stripped at link

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 11, 2016 4:24:09 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 07:15:19AM -0400, Brian Gerst wrote: > >> I think he meant the out of line version would be asm, so you could >> control what registers were clobbered. > >Yeah, it might save a few cycles on the

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 11, 2016 4:24:09 AM PDT, Peter Zijlstra wrote: >On Wed, May 11, 2016 at 07:15:19AM -0400, Brian Gerst wrote: > >> I think he meant the out of line version would be asm, so you could >> control what registers were clobbered. > >Yeah, it might save a few cycles on the call, but given that

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On 05/10/16 12:10, Borislav Petkov wrote: > On Tue, May 10, 2016 at 12:03:48PM -0700, H. Peter Anvin wrote: >> Also, to be fair... if the problem is with these being in C then we >> could just do it in assembly easily enough. > > I thought about converting the __sw_hwe

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On 05/10/16 12:10, Borislav Petkov wrote: > On Tue, May 10, 2016 at 12:03:48PM -0700, H. Peter Anvin wrote: >> Also, to be fair... if the problem is with these being in C then we >> could just do it in assembly easily enough. > > I thought about converting the __sw_hwe

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 10, 2016 10:23:13 AM PDT, Peter Zijlstra wrote: >On Tue, May 10, 2016 at 06:53:18PM +0200, Borislav Petkov wrote: >> static __always_inline unsigned int __arch_hweight32(unsigned int w) >> { >> -unsigned int res = 0; >> +unsigned int res; >> >> -asm

Re: [PATCH -v2] x86/hweight: Get rid of the special calling convention

On May 10, 2016 10:23:13 AM PDT, Peter Zijlstra wrote: >On Tue, May 10, 2016 at 06:53:18PM +0200, Borislav Petkov wrote: >> static __always_inline unsigned int __arch_hweight32(unsigned int w) >> { >> -unsigned int res = 0; >> +unsigned int res; >> >> -asm (ALTERNATIVE("call

Re: linux/bitops.h

On May 6, 2016 1:07:13 PM PDT, Sasha Levin <sasha.le...@oracle.com> wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>>>> Beware that shifting by an amount

Re: linux/bitops.h

On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>>>> Beware that shifting by an amount >= the number of bits in the &

Re: linux/bitops.h

On May 6, 2016 1:07:13 PM PDT, Sasha Levin <sasha.le...@oracle.com> wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>>>> Beware that shifting by an amount

Re: linux/bitops.h

On May 6, 2016 1:07:13 PM PDT, Sasha Levin wrote: >On 05/04/2016 08:30 PM, H. Peter Anvin wrote: >> On 05/04/16 15:06, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>>>> Beware that shifting by an amount >= the number of bits in the &

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > > So this is why I tend to take a much more pragmatic viewpoint on > things. Sure, it makes sense to pay attention to what the C standard > writers are trying to do to us; but if we need to suppress certain > optimizations to write sane kernel code

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > > So this is why I tend to take a much more pragmatic viewpoint on > things. Sure, it makes sense to pay attention to what the C standard > writers are trying to do to us; but if we need to suppress certain > optimizations to write sane kernel code

Re: better patch for linux/bitops.h

On May 5, 2016 3:18:09 PM PDT, ty...@mit.edu wrote: >On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On May 5, 2016 3:18:09 PM PDT, ty...@mit.edu wrote: >On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On 05/05/2016 03:18 PM, ty...@mit.edu wrote: > On Thu, May 05, 2016 at 05:34:50PM -0400, Sandy Harris wrote: >> >> I completely fail to see why tests or compiler versions should be >> part of the discussion. The C standard says the behaviour in >> certain cases is undefined, so a

Re: better patch for linux/bitops.h

On 05/04/16 21:03, Jeffrey Walton wrote: On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: ... But instead of arguing over what works and doesn't, let's just create the the test set and just try it on a wide range of compilers and architectures, hmmm? What are the

Re: better patch for linux/bitops.h

On 05/04/16 21:03, Jeffrey Walton wrote: On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: ... But instead of arguing over what works and doesn't, let's just create the the test set and just try it on a wide range of compilers and architectures, hmmm? What are the requirements? Here's a

Re: better patch for linux/bitops.h

On May 4, 2016 7:54:12 PM PDT, Jeffrey Walton <noloa...@gmail.com> wrote: >On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin <h...@zytor.com> wrote: >> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton <noloa...@gmail.com> >wrote: >>>On Wed, May 4, 2016 at 5:5

Re: better patch for linux/bitops.h

On May 4, 2016 7:54:12 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 10:41 PM, H. Peter Anvin wrote: >> On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton >wrote: >>>On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >>>> On 05/04/2016 02:42 PM, I wro

Re: better patch for linux/bitops.h

On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >> On 05/04/2016 02:42 PM, I wrote: >> >>> I find it very odd that the other seven functions were not >>> upgraded. I suggest the attached fix-others.diff

Re: better patch for linux/bitops.h

On May 4, 2016 6:35:44 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 5:52 PM, John Denker wrote: >> On 05/04/2016 02:42 PM, I wrote: >> >>> I find it very odd that the other seven functions were not >>> upgraded. I suggest the attached fix-others.diff would make >>> things more

Re: linux/bitops.h

On May 4, 2016 6:20:32 PM PDT, Jeffrey Walton <noloa...@gmail.com> wrote: >On Wed, May 4, 2016 at 7:06 PM, Andi Kleen <a...@firstfloor.org> wrote: >> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrot

Re: linux/bitops.h

On May 4, 2016 6:20:32 PM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 7:06 PM, Andi Kleen wrote: >> On Wed, May 04, 2016 at 03:06:04PM -0700, John Denker wrote: >>> On 05/04/2016 02:56 PM, H. Peter Anvin wrote: >>> >> Beware that shifting b

Re: linux/bitops.h

On 05/04/16 15:06, John Denker wrote: On 05/04/2016 02:56 PM, H. Peter Anvin wrote: Beware that shifting by an amount >= the number of bits in the word remains Undefined Behavior. This construct has been supported as a rotate since at least gcc2. How then should we understand the st

Re: linux/bitops.h

On 05/04/16 15:06, John Denker wrote: On 05/04/2016 02:56 PM, H. Peter Anvin wrote: Beware that shifting by an amount >= the number of bits in the word remains Undefined Behavior. This construct has been supported as a rotate since at least gcc2. How then should we understand the st

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

code, including some very counterintuitive >Bad Things. > >On Wed, May 04, 2016 at 11:29:57AM -0700, H. Peter Anvin wrote: >>> >>> If bitops.h doesn't do the right thing, we need to >>> fix bitops.h. > >Most of the ror and rol functions in linux/bitops.h >

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

counterintuitive >Bad Things. > >On Wed, May 04, 2016 at 11:29:57AM -0700, H. Peter Anvin wrote: >>> >>> If bitops.h doesn't do the right thing, we need to >>> fix bitops.h. > >Most of the ror and rol functions in linux/bitops.h >should be considered unsa

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On 05/04/2016 12:07 PM, ty...@thunk.org wrote: > > If we are all agreed that what is in bitops.h is considered valid, > then we can start converting people over to using the version defined > in bitops.h, and if there is some compiler issue we need to work > around, at least we only need to put

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On 05/04/2016 12:07 PM, ty...@thunk.org wrote: > > If we are all agreed that what is in bitops.h is considered valid, > then we can start converting people over to using the version defined > in bitops.h, and if there is some compiler issue we need to work > around, at least we only need to put

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 01:22 PM, Borislav Petkov wrote: > On Wed, May 04, 2016 at 12:49:17PM -0700, H. Peter Anvin wrote: >> Sigh. Doesn't look like -Wa is going to help due to the lack of the >> equivalent of an -include option in gas. > > So much for the register "

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 01:22 PM, Borislav Petkov wrote: > On Wed, May 04, 2016 at 12:49:17PM -0700, H. Peter Anvin wrote: >> Sigh. Doesn't look like -Wa is going to help due to the lack of the >> equivalent of an -include option in gas. > > So much for the register "

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:41 PM, Borislav Petkov wrote: > On Wed, May 04, 2016 at 12:33:24PM -0700, H. Peter Anvin wrote: >> Most likely not. It would be nice to have some more uniform solution to >> that. I'm wondering if we could use the -Wa option to load some kind of >> macro pa

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:41 PM, Borislav Petkov wrote: > On Wed, May 04, 2016 at 12:33:24PM -0700, H. Peter Anvin wrote: >> Most likely not. It would be nice to have some more uniform solution to >> that. I'm wondering if we could use the -Wa option to load some kind of >> macro pa

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:31 PM, Brian Gerst wrote: >> >> - asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT) >> -: "="REG_OUT (res) >> -: REG_IN (w)); >> + if (likely(static_cpu_has(X86_FEATURE_POPCNT))) { >> + asm

Re: [RFC PATCH] x86/hweight: Get rid of the special calling convention

On 05/04/2016 12:31 PM, Brian Gerst wrote: >> >> - asm (ALTERNATIVE("call __sw_hweight32", POPCNT32, X86_FEATURE_POPCNT) >> -: "="REG_OUT (res) >> -: REG_IN (w)); >> + if (likely(static_cpu_has(X86_FEATURE_POPCNT))) { >> + asm

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On May 4, 2016 11:22:25 AM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 1:49 PM, wrote: >> On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >>> > +static inline u32 rotl32(u32 v, u8 n) >>> > +{ >>> > + return (v << n) | (v >>

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On May 4, 2016 11:22:25 AM PDT, Jeffrey Walton wrote: >On Wed, May 4, 2016 at 1:49 PM, wrote: >> On Wed, May 04, 2016 at 10:40:20AM -0400, Jeffrey Walton wrote: >>> > +static inline u32 rotl32(u32 v, u8 n) >>> > +{ >>> > + return (v << n) | (v >> (sizeof(v) * 8 - n)); >>> > +} >>> >>>

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On May 4, 2016 10:30:41 AM PDT, ty...@mit.edu wrote: >On Tue, May 03, 2016 at 10:50:25AM +0200, Stephan Mueller wrote: >> > +/* >> > + * crng_init = 0 --> Uninitialized >> > + *2 --> Initialized >> > + *3 --> Initialized from input_pool >> > + */ >> > +static int

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

On May 4, 2016 10:30:41 AM PDT, ty...@mit.edu wrote: >On Tue, May 03, 2016 at 10:50:25AM +0200, Stephan Mueller wrote: >> > +/* >> > + * crng_init = 0 --> Uninitialized >> > + *2 --> Initialized >> > + *3 --> Initialized from input_pool >> > + */ >> > +static int

Re: [tip:x86/asm] x86/mm/xen: Suppress hugetlbfs in PV guests

On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote: > Commit-ID: 103f6112f253017d7062cd74d17f4a514ed4485c > Gitweb: http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c > Author: Jan Beulich > AuthorDate: Thu, 21 Apr 2016 00:27:04 -0600 > Committer:

Re: [tip:x86/asm] x86/mm/xen: Suppress hugetlbfs in PV guests

On 04/22/2016 02:47 AM, tip-bot for Jan Beulich wrote: > Commit-ID: 103f6112f253017d7062cd74d17f4a514ed4485c > Gitweb: http://git.kernel.org/tip/103f6112f253017d7062cd74d17f4a514ed4485c > Author: Jan Beulich > AuthorDate: Thu, 21 Apr 2016 00:27:04 -0600 > Committer: Ingo Molnar >

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 8:52:01 AM PDT, Thomas Garnier <thgar...@google.com> wrote: >On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin <h...@zytor.com> wrote: >> On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky ><boris.ostrov...@oracle.com> wrote: >>> >>>

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >> On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >>> >>> >>>On 04/15/2016 06:03 PM, Thomas Garnier wrote: >>

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky wrote: > > >On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> +void __init kernel_randomize_memory(void) >> +{ >> +size_t i; >> +unsigned long addr = memory_rand_start; >> +unsigned long padding, rand,

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky wrote: > > >On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> +void __init kernel_randomize_memory(void) >> +{ >> +size_t i; >> +unsigned long addr = memory_rand_start; >> +unsigned long padding, rand, mem_tb; >> +struct rnd_state

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On April 20, 2016 2:36:37 PM PDT, Borislav Petkov <b...@alien8.de> wrote: >On Wed, Apr 20, 2016 at 02:06:33PM -0700, H. Peter Anvin wrote: >> Setting ret to sem doesn't make any sense. Just use "=a" and "a". > >Yeah, that's what Michal's patch ontop does.

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On April 20, 2016 2:36:37 PM PDT, Borislav Petkov wrote: >On Wed, Apr 20, 2016 at 02:06:33PM -0700, H. Peter Anvin wrote: >> Setting ret to sem doesn't make any sense. Just use "=a" and "a". > >Yeah, that's what Michal's patch ontop does. > >And to ans

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On 04/20/2016 01:45 PM, Borislav Petkov wrote: > On Wed, Apr 20, 2016 at 11:04:05AM -0700, H. Peter Anvin wrote: >> The reason it breaks is because the same register can't be an >> input-output register and a separate input. However, the input side of >> the input-output

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On 04/20/2016 01:45 PM, Borislav Petkov wrote: > On Wed, Apr 20, 2016 at 11:04:05AM -0700, H. Peter Anvin wrote: >> The reason it breaks is because the same register can't be an >> input-output register and a separate input. However, the input side of >> the input-output

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On April 20, 2016 6:40:19 AM PDT, Peter Zijlstra wrote: >On Wed, Apr 13, 2016 at 02:49:43PM +0200, Michal Hocko wrote: >> On Wed 13-04-16 12:27:31, Ingo Molnar wrote: >> > >> > * Ingo Molnar wrote: >> > >> > > I'm testing your patches today, if they are

Re: [PATCH 10/11] x86, rwsem: provide __down_write_killable

On April 20, 2016 6:40:19 AM PDT, Peter Zijlstra wrote: >On Wed, Apr 13, 2016 at 02:49:43PM +0200, Michal Hocko wrote: >> On Wed 13-04-16 12:27:31, Ingo Molnar wrote: >> > >> > * Ingo Molnar wrote: >> > >> > > I'm testing your patches today, if they are otherwise OK [...] >> > >> > got this

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 20, 2016 4:50:53 AM PDT, "Austin S. Hemmelgarn" <ahferro...@gmail.com> wrote: >On 2016-04-19 23:27, Eric W. Biederman wrote: >> "H. Peter Anvin" <h...@zytor.com> writes: >> >>> On April 19, 2016 12:25:03 PM PDT, "H. Peter An

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 20, 2016 4:50:53 AM PDT, "Austin S. Hemmelgarn" wrote: >On 2016-04-19 23:27, Eric W. Biederman wrote: >> "H. Peter Anvin" writes: >> >>> On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" >wrote: >>>&g

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 6:24:12 PM PDT, Linus Torvalds wrote: >On Tue, Apr 19, 2016 at 4:29 PM, Linus Torvalds > wrote: >> >> I _violently_ oppose the stupid DEVPTS_MULTIPLE_INSTANCES config >option. > >So just to show what I want to

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 6:24:12 PM PDT, Linus Torvalds wrote: >On Tue, Apr 19, 2016 at 4:29 PM, Linus Torvalds > wrote: >> >> I _violently_ oppose the stupid DEVPTS_MULTIPLE_INSTANCES config >option. > >So just to show what I want to actually happen, here's the hacky patch >on top of my (now merged)

Re: Does anyone care about a race free ptsname?

On 04/19/2016 04:23 PM, Linus Torvalds wrote: > On Tue, Apr 19, 2016 at 11:44 AM, Eric W. Biederman > wrote: >> >> I will take a look in a minute. Before I do that I want to mention >> why I care about /dev/pts/ptmx. >> >> There is a posix function that is widely used

Re: Does anyone care about a race free ptsname?

On 04/19/2016 04:23 PM, Linus Torvalds wrote: > On Tue, Apr 19, 2016 at 11:44 AM, Eric W. Biederman > wrote: >> >> I will take a look in a minute. Before I do that I want to mention >> why I care about /dev/pts/ptmx. >> >> There is a posix function that is widely used called ptsname. It's >>

Re: Does anyone care about a race free ptsname?

On 04/19/2016 01:32 PM, Eric W. Biederman wrote: > > The challenge came in operations such as granpt. Where you are passed > in a ptmx file descriptor from who knows where, and you pass it on > to applications such as pt_chown which run with elevatated privileged. > > As the information is

Re: Does anyone care about a race free ptsname?

On 04/19/2016 01:32 PM, Eric W. Biederman wrote: > > The challenge came in operations such as granpt. Where you are passed > in a ptmx file descriptor from who knows where, and you pass it on > to applications such as pt_chown which run with elevatated privileged. > > As the information is

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" <h...@zytor.com> wrote: >On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >>"H. Peter Anvin" <h...@zytor.com> writes: >> >>>>- Support for reserving ptys for the system dev

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:25:03 PM PDT, "H. Peter Anvin" wrote: >On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >>"H. Peter Anvin" writes: >> >>>>- Support for reserving ptys for the system devpts instance using >>>> /pro

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" <h...@zytor.com> writes: > >>>- Support for reserving ptys for the system devpts instance using >>> /proc/sys/kernel/pty/reserve needs to be removed. >>> >>&g

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 12:03:47 PM PDT, ebied...@xmission.com wrote: >"H. Peter Anvin" writes: > >>>- Support for reserving ptys for the system devpts instance using >>> /proc/sys/kernel/pty/reserve needs to be removed. >>> >>>Eric >&g

Re: Does anyone care about a race free ptsname?

On April 19, 2016 11:44:40 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> What this does is get rid of the horrible notion of having that >> >> struct inode *ptmx_inode >> >> be the interface between the pty code and devpts. By de-emphasizing

Re: Does anyone care about a race free ptsname?

On April 19, 2016 11:44:40 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> What this does is get rid of the horrible notion of having that >> >> struct inode *ptmx_inode >> >> be the interface between the pty code and devpts. By de-emphasizing >the >> ptmx inode, a lot of

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts.

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts. To retain the notion of a primary system instance of

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

On April 19, 2016 10:19:47 AM PDT, Steven Rostedt wrote: >On Tue, 19 Apr 2016 16:55:28 + (UTC) >Mathieu Desnoyers wrote: > >> - On Apr 19, 2016, at 10:34 AM, rostedt rost...@goodmis.org >wrote: >> >> > From: Steven Rostedt

Re: [RFC][PATCH 2/4] tracing: Use pid bitmap instead of a pid array for set_event_pid

On April 19, 2016 10:19:47 AM PDT, Steven Rostedt wrote: >On Tue, 19 Apr 2016 16:55:28 + (UTC) >Mathieu Desnoyers wrote: > >> - On Apr 19, 2016, at 10:34 AM, rostedt rost...@goodmis.org >wrote: >> >> > From: Steven Rostedt >> > >> > In order to add the ability to let tasks that are

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts.

Re: [PATCH 14/16] vfs: Implement mount_super_once

On April 19, 2016 11:22:24 AM PDT, ebied...@xmission.com wrote: >Linus Torvalds writes: > >> On Fri, Apr 15, 2016 at 8:35 AM, Eric W. Biederman >> wrote: >>> The devpts filesystem has a notion of a system or primary instance >of >>> devpts. To retain the notion of a primary system instance of

Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()

On April 19, 2016 4:35:01 AM PDT, Borislav Petkov wrote: >On Tue, Apr 19, 2016 at 01:15:30PM +0200, Ingo Molnar wrote: >> So I'd suggest the following renames to harmonize these concepts: >> >> - CONFIG_IA32_EMULATION => CONFIG_X86_32_ABI >>this lines up nicely with:

Re: [tip:x86/asm] x86/entry: Rename is_{ia32,x32}_task() to in_{ia32,x32}_syscall()

On April 19, 2016 4:35:01 AM PDT, Borislav Petkov wrote: >On Tue, Apr 19, 2016 at 01:15:30PM +0200, Ingo Molnar wrote: >> So I'd suggest the following renames to harmonize these concepts: >> >> - CONFIG_IA32_EMULATION => CONFIG_X86_32_ABI >>this lines up nicely with: CONFIG_X86_X32_ABI >

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 18, 2016 7:46:05 AM PDT, Joerg Roedel wrote: >On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static const unsigned long memory_rand_end = KASAN_SHADOW_START; >> +#elfif defined(CONFIG_X86_ESPFIX64) >> +static const

<    2   3   4   5   6   7   8   9   10   11   >