On 06/08/16 02:39, Peter Zijlstra wrote:
>
> So I think using bool as return type or argument is fine, using it in
> structures is 'insane'.
>
Yes, scalar use only, and not across the kernel boundary, please.
-hpa
On 06/08/16 02:20, Ingo Molnar wrote:
>
> Also, unless I'm missing something it's not really 'hard' or dangerous per se
> to
> do that change for every architecture, just incredibly boring! ;-)
>
> I'm not sure how much it matters though, given other asymmetries in the
> bitops API
> signatur
On 06/08/16 02:20, Ingo Molnar wrote:
>
> Yeah, absolutely. I hate 'bool' with a vengence but if 'int' generates worse
> code
> with modern compilers then I'm not going to argue for worse code. Would a
> 'char'
> return type be very weird?
>
Yes. I have to admit I don't share your hatred fo
On 06/08/16 02:01, Ingo Molnar wrote:
>
> That's a divergence with an underlying reason - but not harmonizing the
> return
> code is an unforced error AFAICS and can be fixed.
>
Perhaps. It is also no real question that "bool" is the right return
type for a single bit. Changing that in all ar
On 06/08/16 01:28, Ingo Molnar wrote:
>
> It does matter:
>
> In file included from arch/x86/kernel/cpu/common.c:21:0:
> ./arch/x86/include/asm/archrandom.h:95:20: error: redefinition of
> ‘arch_get_random_long’
> static inline bool arch_get_random_long(unsigned long *v)
> In file included f
On 06/08/16 01:00, Peter Zijlstra wrote:
>
> Do you happen to know if GCC plans to support other architectures for
> =@cc ?
>
I think it would depend on those architectures. I suspect it makes
sense for some architectures and not at all for others. Either way, it
is a completely architecture-d
On 06/08/16 01:33, Ingo Molnar wrote:
>
> Note that this particular build error was introduced by b0bdba9825fe, a later
> patch in this series - but in generaly I'm uneasy about allowing function
> signatures diverge between architectures.
>
For the bitops, they already do: PowerPC, for exampl
On June 7, 2016 7:14:41 PM PDT, "Zhangjian (Bamvor)"
wrote:
>Hi,
>
>On 2016/6/8 9:33, Weidong Wang wrote:
>> Test 32 progress and 64 progress on the 64bit system with
>> this progress:
>>
>> int main(int argc, char **argv)
>> {
>> int fd = 0;
>> int i, ret = 0;
>> char
Commit-ID: 8d0d5a8abd88fa9671867b8b8ab4ee61b85c0c81
Gitweb: http://git.kernel.org/tip/8d0d5a8abd88fa9671867b8b8ab4ee61b85c0c81
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:09 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm, boot: Use
Commit-ID: b0bdba9825feefa46998f29225736ef9bd77bd2e
Gitweb: http://git.kernel.org/tip/b0bdba9825feefa46998f29225736ef9bd77bd2e
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:08 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: Use CC_SET
Commit-ID: a7b6cddc8c403195d0052da3bde776ffee2fed10
Gitweb: http://git.kernel.org/tip/a7b6cddc8c403195d0052da3bde776ffee2fed10
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:07 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: Use CC_SET
Commit-ID: ad5bf6a52b7fac127d126434fdf950e7bd6f7554
Gitweb: http://git.kernel.org/tip/ad5bf6a52b7fac127d126434fdf950e7bd6f7554
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:06 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: Use CC_SET
Commit-ID: a2d4cf46b22550edb4d43a46cfa478649ebfe1d7
Gitweb: http://git.kernel.org/tip/a2d4cf46b22550edb4d43a46cfa478649ebfe1d7
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:05 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: Use CC_SET
Commit-ID: 2d81d0e1bd0f48049a6a6e289c937bc24c98649e
Gitweb: http://git.kernel.org/tip/2d81d0e1bd0f48049a6a6e289c937bc24c98649e
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:03 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: define CC_SET
Commit-ID: 560a154bc1fa2143b25b66ca013424a280bd8377
Gitweb: http://git.kernel.org/tip/560a154bc1fa2143b25b66ca013424a280bd8377
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:04 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: change GEN_
Commit-ID: d3f78b979e4e060c1b36402fa7096a36a9c266da
Gitweb: http://git.kernel.org/tip/d3f78b979e4e060c1b36402fa7096a36a9c266da
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:01 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: use bool for
Commit-ID: ebc2b1c0e47ee09960cd2474e3f4091733417f14
Gitweb: http://git.kernel.org/tip/ebc2b1c0e47ee09960cd2474e3f4091733417f14
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:02 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, asm: change the
Commit-ID: 4ec1063787c26243ab709165bc7b7771a1c19bc6
Gitweb: http://git.kernel.org/tip/4ec1063787c26243ab709165bc7b7771a1c19bc6
Author: H. Peter Anvin
AuthorDate: Tue, 7 Jun 2016 16:31:00 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 7 Jun 2016 16:36:42 -0700
x86, bitops: remove use
From: "H. Peter Anvin"
gcc 6+ has the ability to let flags (actually, conditions, which are
specific combinations of flags) to be used directly as asm() outputs.
The syntax for that is "=@cc" where is the same set of
letters that would be used in a j or set instruction
(e.g.
From: "H. Peter Anvin"
The gcc people have confirmed that using "bool" when combined with
inline assembly always is treated as a byte-sized operand that can be
assumed to be 0 or 1, which is exactly what the SET instruction
emits. Change the output types and intermediate
From: "H. Peter Anvin"
Change the GEN_*_RMWcc() macros to use the CC_SET()/CC_OUT() macros
defined in , and disable the use of asm goto if
__GCC_ASM_FLAG_OUTPUTS__ is enabled. This allows gcc to receive the
flags output directly in gcc 6+.
Signed-off-by: H. Peter Anvin
---
arch/x
From: "H. Peter Anvin"
The CC_SET() and CC_OUT() macros can be used together to take
advantage of the new __GCC_ASM_FLAG_OUTPUTS__ feature in gcc 6+ while
remaining backwards compatible. CC_SET() generates a SET instruction
on older compilers; CC_OUT() makes sure the output is recei
Use CC_SET()/CC_OUT() and static_cpu_has(). This produces code good
enough to eliminate ad hoc use of alternatives in ,
greatly simplifying the code.
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/archrandom.h | 113 --
1 file changed, 47 insertions
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/percpu.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/percpu.h b/arch/x86/i
From: "H. Peter Anvin"
Change the lexical defintion of the GEN_*_RMWcc() macros to not take
the condition code as a quoted string. This will help support
changing them to use the new __GCC_ASM_FLAG_OUTPUTS__ feature in a
subsequent patch.
Signed-off-by: H. Peter Anvin
---
arch/x
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
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
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
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
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 = ¤t_thread_info()->flags;
>>>
>>> Why is this conditional? Is there any
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*
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 se
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 add
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
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
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)
>
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 (w
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 t
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 mos
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_hweight
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 __sw_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
&
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
&
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 -
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 standard-co
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 standard-compliant
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 s
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 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 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 consistent
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 by an am
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
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
>should be consi
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 th
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 &quo
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
>> mac
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 volati
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));
>>> > +}
>>>
>>> That
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 cr
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
> Commit
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:
>>
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 r
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.
>
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
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 bu
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:
>>>>
>
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) cl
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
>> fu
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 avail
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
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
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 th
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 de
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 fil
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 de
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
>
>
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 unsigned long memory_ra
On April 18, 2016 2:14:12 AM PDT, "Richard W.M. Jones"
wrote:
>On Sun, Apr 17, 2016 at 06:57:36PM -0700, Josh Triplett wrote:
>> O_NOUMASK seems potentially useful to support implementation of umask
>> entirely in userspace, which also addresses thread-safety. A program
>> could read its process
On 04/17/16 23:14, Andy Lutomirski wrote:
>>
>> It's not "weird", it is the ABI as defined. We have to do this for all
>> the system call arguments, too; you just don't notice it because the
>> compiler does it for us. Some other architectures, e.g. s390, has the
>> opposite convention where the
On 04/17/16 22:48, Andy Lutomirski wrote:
>
> I think I prefer the "reject weird input" behavior over the "accept
> and normalize weird input" if we can get away with it, and I'm fairly
> confident that we can get away with "reject weird input" given that
> distro kernels do exactly that already.
On 04/17/16 22:39, Andy Lutomirski wrote:
>>
>> I'm reasonably confident they have, because we have had security bugs
>> TWICE when someone has tried to "optimize" the code. The masking was
>> generally done with a movl instruction, which confused people.
>>
>>> So the type of the syscall nr is a
On 04/17/16 22:18, Andy Lutomirski wrote:
> On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin wrote:
>> On 04/17/16 17:47, Ben Hutchings wrote:
>>> We've always masked off the top 32 bits when x32 is enabled, but
>>> hopefully no-one relies on that. Now that the slo
On 04/17/16 22:18, Andy Lutomirski wrote:
> On Sun, Apr 17, 2016 at 9:50 PM, H. Peter Anvin wrote:
>> On 04/17/16 17:47, Ben Hutchings wrote:
>>> We've always masked off the top 32 bits when x32 is enabled, but
>>> hopefully no-one relies on that. Now that the slo
On 04/17/16 17:47, Ben Hutchings wrote:
> We've always masked off the top 32 bits when x32 is enabled, but
> hopefully no-one relies on that. Now that the slow path is in C, we
> check all the bits there, regardless of whether x32 is enabled. Let's
> make the fast path consistent with it.
We hav
On 04/17/16 19:37, Josh Triplett wrote:
>
> It seems like one of the main problems with syscall() is that it forces
> userspace to handle weird ABI issues, such as syscall numbers varying by
> architecture, encoding of 64-bit arguments on 32-bit platforms (see the
> example in the syscall manpage)
On 04/17/16 19:12, Josh Triplett wrote:
>>
>> I really like the 'libinux' idea, did anyone every hack up a first-pass
>> at this? And I'm guessing we have more syscalls now that would need to
>> be added (like getrandom(), but that shouldn't be too difficult.
>
> Personally, I'd suggest that libi
On 04/17/16 18:09, Greg KH wrote:
>>
>> There aren't a *lot* of such system calls, but even in that thread the
>> "oh, only two applications need this, let them use syscall(3)" seems to
>> remain.
>
> And only 2 applications will continue to use it because no one wants to
> write syscall() wrapper
On 04/13/16 08:41, Colin Walters wrote:
> On Wed, Apr 13, 2016, at 08:57 AM, Richard W.M. Jones wrote:
>
>> It's not possible to read the process umask without also modifying it,
>> which is what umask(2) does. A library cannot read umask safely,
>> especially if the main program might be multith
On 04/13/16 19:13, Theodore Ts'o wrote:
>
> One other reason to suggest using a /proc file is that you're not at
> the mercy of the glibc folks to wire up a new system call. (Glibc has
> been refusing to wire up getrandom(2), for example. G.)
>
This brings right back up the libinux id
It's really too bad we can't just use follow_link :-/
--
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.
On 04/13/16 12:05, Richard W.M. Jones wrote:
v3 -> v4:
- Rename the syscall: getumask becomes umask2.
- Add flags parameter, with one flag (UMASK_GET_MASK).
- Expand the rationale for this change in the first commit message.
It's not possible to read the process umask without also modi
On 04/12/16 11:12, Linus Torvalds wrote:
So what I want to happen is to "just make /dev/ptmx work". Get rid of
the broken "single instance" crap. The only reason it exists is
exactly because /dev/ptmx does not work.
I think the current situation is completely and utterly broken. We
should neve
On April 11, 2016 5:10:47 PM PDT, ebied...@xmission.com wrote:
>Linus Torvalds writes:
>
>> On Mon, Apr 11, 2016 at 4:37 PM, Eric W. Biederman
>> wrote:
>>>
>>> My practical concern if we worked through the implementation details
>>> would be how would it interact with people who bind mount
>/dev
On April 11, 2016 1:12:22 PM PDT, Andy Lutomirski wrote:
>On Sat, Apr 9, 2016 at 6:27 PM, Linus Torvalds
> wrote:
>>
>> On Apr 9, 2016 5:45 PM, "Andy Lutomirski"
>wrote:
>>>
>>>
>>> What we *do* want to do, though, is to prevent the following:
>>
>> I don't see the point. Why do you bring up this
On April 9, 2016 6:27:36 PM PDT, Linus Torvalds
wrote:
>On Apr 9, 2016 5:45 PM, "Andy Lutomirski" wrote:
>>
>>
>> What we *do* want to do, though, is to prevent the following:
>
>I don't see the point. Why do you bring up this insane scenario that
>nobody
>can possibly care about?
>
>So you actu
On April 9, 2016 5:01:27 PM PDT, Linus Torvalds
wrote:
>On Sat, Apr 9, 2016 at 3:37 PM, H. Peter Anvin wrote:
>>
>> On the flipside, if we were to allow ourselves to break userspace, at
>this point I would suggest making /dev/pts/ptmx have a different device
>number and
On April 9, 2016 7:45:46 AM PDT, ebied...@xmission.com wrote:
>"H. Peter Anvin" writes:
>
>> On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes
> wrote:
>>>
>>>> If anyone has a better idea on how userspace should connect the
>>>master
>
On April 9, 2016 6:09:09 AM PDT, One Thousand Gnomes
wrote:
>
>> If anyone has a better idea on how userspace should connect the
>master
>> pty file descriptor the slave file descriptor, I would be willing to
>> implement that instead.
>
>If we are willing to go away from the existing mess of a t
On 04/04/16 10:01, Mathieu Desnoyers wrote:
>
> Changes since v5:
> - Rename "getcpu_cache" to "thread_local_abi", allowing to extend
> this system call to cover future features such as restartable critical
> sections. Generalizing this system call ensures that we can add
> features similar
On 03/10/2016 01:35 PM, Dave Hansen wrote:
> On 03/10/2016 04:23 PM, Fenghua Yu wrote:
>> A few new AVX-512 instruction groups/features are added in cpufeatures.h
>> for enuermation: AVX512DQ, AVX512BW, and AVX512VL.
>>
>> The specification for latest AVX-512 including the features can be found at
On 03/09/2016 04:46 AM, Ingo Molnar wrote:
>
> * Yu-cheng Yu wrote:
>
>> AVX was mistakenly believed to be dependent on eagerfpu switch.
>> This turns out to be false. The earlier patch should be reverted.
>>
>> Original patch:
>> http://git.kernel.org/tip/394db20ca240741a08d472173db13d6f6a6
301 - 400 of 6113 matches
Mail list logo
