On March 9, 2021 1:24:44 PM PST, Peter Zijlstra wrote:
>On Tue, Mar 09, 2021 at 12:05:19PM -0500, Steven Rostedt wrote:
>> On Tue, 9 Mar 2021 17:58:17 +0100
>> Peter Zijlstra wrote:
>>
>> > Hi,
>> >
>> > AFAICT everything made in the past 10 years ends up using p6_nops.
>Is it
>> > time to
" LFENCE in
>kernel entry SWAPGS path */
>> #define X86_FEATURE_SPLIT_LOCK_DETECT (11*32+ 6) /* #AC for split
>lock */
>> #define X86_FEATURE_PER_THREAD_MBA (11*32+ 7) /* "" Per-thread
>Memory Bandwidth Allocation */
>> +#define X86_FEATURE_CRC32C (
On December 25, 2020 11:29:30 PM PST, John Millikin wrote:
>When compiling with Clang, the `$(CLANG_FLAGS)' variable contains
>additional flags needed to cross-compile C and Assembly sources:
>
>* `-no-integrated-as' tells clang to assemble with GNU Assembler
> instead of its built-in LLVM
On December 21, 2020 7:01:39 PM PST, tonywwang...@zhaoxin.com wrote:
>On December 22, 2020 3:27:33 AM GMT+08:00, h...@zytor.com wrote:
>>On December 20, 2020 6:46:25 PM PST, tonywwang...@zhaoxin.com wrote:
>>>On December 16, 2020 1:56:45 AM GMT+08:00, Eric Biggers
>>> wrote:
On Tue, Dec 15,
On December 20, 2020 6:46:25 PM PST, tonywwang...@zhaoxin.com wrote:
>On December 16, 2020 1:56:45 AM GMT+08:00, Eric Biggers
> wrote:
>>On Tue, Dec 15, 2020 at 10:15:29AM +0800, Tony W Wang-oc wrote:
>>>
>>> On 15/12/2020 04:41, Eric Biggers wrote:
>>> > On Mon, Dec 14, 2020 at 10:28:19AM +0800,
On December 5, 2020 7:23:05 PM PST, Al Viro wrote:
>On Thu, Dec 03, 2020 at 11:03:36PM +, Al Viro wrote:
>> > > The answer (for mainline) is that mips compat does *NOT* want
>> > > COMPAT_BINFMT_ELF. Not a problem with that series, though, so
>I'd
>> > > retested it (seems to work, both for
On November 30, 2020 5:13:06 PM PST, Nick Desaulniers
wrote:
>A revert of the following two commits.
>commit de3accdaec88 ("x86, build: Build 16-bit code with -m16 where
>possible")
>commit a9cfccee6604 ("x86, build: Change code16gcc.h from a C header to
>an assembly header")
>
>Since commit
On October 23, 2020 2:52:16 PM PDT, David Laight
wrote:
>From: Linus Torvalds
>> Sent: 23 October 2020 22:11
>>
>> On Fri, Oct 23, 2020 at 2:00 PM wrote:
>> >
>> > There is no same reason to mess around with hacks when we are
>talking about dx:ax, though.
>>
>> Sure there is.
>>
>> "A"
On October 23, 2020 2:11:19 PM PDT, Linus Torvalds
wrote:
>On Fri, Oct 23, 2020 at 2:00 PM wrote:
>>
>> There is no same reason to mess around with hacks when we are talking
>about dx:ax, though.
>
>Sure there is.
>
>"A" doesn't actually mean %edx:%eax like you seem to think.
>
>It actually
On October 23, 2020 1:55:22 PM PDT, Linus Torvalds
wrote:
>Thanks, applied.
>
>On Fri, Oct 23, 2020 at 1:32 PM Rasmus Villemoes
> wrote:
>>
>> I'm wondering if one would also need to make __ptr_pu and __ret_pu
>> explicitly "%"_ASM_CX".
>
>No, the "c"/"0" thing is much better, and makes it
On October 23, 2020 1:42:39 PM PDT, Andy Lutomirski wrote:
>On Fri, Oct 23, 2020 at 1:32 PM Rasmus Villemoes
> wrote:
>>
>> Quoting
>> https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html:
>>
>> You can define a local register variable and associate it with a
>> specified
On October 15, 2020 9:12:16 AM PDT, Ian Rogers wrote:
>From: Numfor Mbiziwo-Tiapo
>
>Don't perform unaligned loads in __get_next and __peek_nbyte_next as
>these are forms of undefined behavior.
>
>These problems were identified using the undefined behavior sanitizer
>(ubsan) with the tools
inition on x86 to also include
>> > the redirection for x32.
>> >
>> > Signed-off-by: Arnd Bergmann
>>
>> Adding the x86 maintainers and Brian Gerst. Brian proposed another
>> problem to the mess that most of the compat syscall handlers used by
>&g
On September 1, 2020 9:18:57 AM PDT, Nadav Amit wrote:
>From: Nadav Amit
>
>The __force_order logic seems to be inverted. __force_order is
>supposedly used to manipulate the compiler to use its memory
>dependencies analysis to enforce orders between CR writes and reads.
>Therefore, the memory
On August 24, 2020 5:30:56 PM PDT, Andy Lutomirski wrote:
>On Mon, Aug 24, 2020 at 4:52 PM H. Peter Anvin wrote:
>>
>> On 2020-08-24 14:10, Andy Lutomirski wrote:
>> >
>> > PTRACE_READ_SEGMENT_DESCRIPTOR to read a segment descriptor.
>> >
>> > PTRACE_SET_FS / PTRACE_SET_GS: Sets FS or GS and
On August 21, 2020 2:28:32 AM PDT, Thomas Gleixner wrote:
>On Fri, Aug 21 2020 at 10:09, Paolo Bonzini wrote:
>> On 21/08/20 09:47, Borislav Petkov wrote:
>>> On Thu, Aug 20, 2020 at 07:50:50PM -0700, Sean Christopherson wrote:
+ * Disallow RDPID if KVM is enabled as it may consume a
On August 4, 2020 10:08:08 PM PDT, Borislav Petkov wrote:
>On Tue, Aug 04, 2020 at 09:58:25PM -0700, h...@zytor.com wrote:
>> Because why use an alternative to jump over one instruction?
>>
>> I personally would prefer to have the IRET put out of line
>
>Can't yet - SERIALIZE CPUs are a minority
On August 4, 2020 9:48:40 PM PDT, Borislav Petkov wrote:
>On Tue, Aug 04, 2020 at 07:10:59PM -0700, Ricardo Neri wrote:
>> The SERIALIZE instruction gives software a way to force the processor
>to
>> complete all modifications to flags, registers and memory from
>previous
>> instructions and
On July 27, 2020 1:36:19 AM PDT, pet...@infradead.org wrote:
>On Sun, Jul 26, 2020 at 10:55:15PM -0700, h...@zytor.com wrote:
>> For a really overenginered solution, but which might perform
>> unnecessary poorly on existing hardware:
>>
>> asm volatile("1: .byte 0xf, 0x1, 0xe8; 2:"
>>
On July 27, 2020 1:20:03 AM PDT, pet...@infradead.org wrote:
>On Sun, Jul 26, 2020 at 09:31:32PM -0700, Ricardo Neri wrote:
>> +static inline void serialize(void)
>> +{
>> +asm volatile(".byte 0xf, 0x1, 0xe8");
>> +}
>
>Can we pretty please have a comment with the binutils version that has
On July 26, 2020 11:24:25 PM PDT, Christoph Hellwig wrote:
>On Sun, Jul 26, 2020 at 11:20:41PM -0700, h...@zytor.com wrote:
>> On July 26, 2020 8:05:34 PM PDT, Al Viro
>wrote:
>> >On Tue, Jul 14, 2020 at 09:04:22PM +0200, Christoph Hellwig wrote:
>> >> Don't rely on the implicit
On July 26, 2020 8:05:34 PM PDT, Al Viro wrote:
>On Tue, Jul 14, 2020 at 09:04:22PM +0200, Christoph Hellwig wrote:
>> Don't rely on the implicit set_fs(KERNEL_DS) for ksys_open to work,
>but
>> instead open a struct file for /dev/console and then install it as FD
>> 0/1/2 manually.
>
>I really
On July 26, 2020 10:55:15 PM PDT, h...@zytor.com wrote:
>On July 26, 2020 9:31:32 PM PDT, Ricardo Neri
> wrote:
>>The SERIALIZE instruction gives software a way to force the processor
>>to
>>complete all modifications to flags, registers and memory from
>previous
>>instructions and drain all
On July 26, 2020 9:31:32 PM PDT, Ricardo Neri
wrote:
>The SERIALIZE instruction gives software a way to force the processor
>to
>complete all modifications to flags, registers and memory from previous
>instructions and drain all buffered writes to memory before the next
>instruction is fetched
On July 18, 2020 12:25:46 PM PDT, Andy Lutomirski wrote:
>
>> On Jul 18, 2020, at 10:57 AM, h...@zytor.com wrote:
>>
>> On July 9, 2020 3:33:55 AM PDT, Joerg Roedel
>wrote:
>>> From: Joerg Roedel
>>>
>>> On x86-32 the idt_table with 256 entries needs only 2048 bytes. It
>is
>>> page-aligned,
On July 9, 2020 3:33:55 AM PDT, Joerg Roedel wrote:
>From: Joerg Roedel
>
>On x86-32 the idt_table with 256 entries needs only 2048 bytes. It is
>page-aligned, but the end of the .bss..page_aligned section is not
>guaranteed to be page-aligned.
>
>As a result, symbols from other .bss sections
On July 14, 2020 5:03:31 PM PDT, "Zhang, Cathy" wrote:
>On 7/15/2020 7:05 AM, h...@zytor.com wrote:
>> On July 14, 2020 3:42:08 PM PDT, "Zhang, Cathy"
> wrote:
>>> On 7/14/2020 11:00 AM, Sean Christopherson wrote:
On Tue, Jul 07, 2020 at 10:16:22AM +0800, Cathy Zhang wrote:
> SERIALIZE
On July 14, 2020 3:42:08 PM PDT, "Zhang, Cathy" wrote:
>On 7/14/2020 11:00 AM, Sean Christopherson wrote:
>> On Tue, Jul 07, 2020 at 10:16:22AM +0800, Cathy Zhang wrote:
>>> SERIALIZE instruction is supported by intel processors,
>>> like Sapphire Rapids. Expose it in KVM supported cpuid.
>>
t'
>>>>>
>>>> You must be kidding.
>>>>
>>>> If you want to change it, change it to sizeof(bd->dbuf) instead,
>but
>>> this flag
>>>> is at least in my opinion a total joke. For sizeof(int) !=
>>> sizeof(uns
ge the type in sizeof to 'unsigned int'
>>>
>> You must be kidding.
>>
>> If you want to change it, change it to sizeof(bd->dbuf) instead, but
>this flag
>> is at least in my opinion a total joke. For sizeof(int) !=
>sizeof(unsigned
>> int) is
On July 10, 2020 3:45:25 PM PDT, Brendan Shanks wrote:
>Add emulation/spoofing of SLDT and STR for both 32- and 64-bit
>processes.
>
>Wine users have found a small number of Windows apps using SLDT that
>were crashing when run on UMIP-enabled systems.
>
>Reported-by: Andreas Rammhold
On July 9, 2020 8:17:57 AM PDT, Christoph Hellwig wrote:
>Hi all,
>
>this series starts to move the early init code away from requiring
>KERNEL_DS to be implicitly set during early startup. It does so by
>first removing legacy unused cruft, and the switches away the code
>from struct file based
On July 3, 2020 5:18:48 PM PDT, antlists wrote:
>On 03/07/2020 04:40, H. Peter Anvin wrote:
>> On 2020-06-15 05:53, Christoph Hellwig wrote:
>>> BLKFLSBUF used to be overloaded for the ramdisk driver to free the
>whole
>>> ramdisk, which was completely different behavior compared to all
>other
On June 16, 2020 10:17:29 AM PDT, Brian Gerst wrote:
>On Tue, Jun 16, 2020 at 12:49 PM Andy Lutomirski
>wrote:
>>
>> On Tue, Jun 16, 2020 at 7:23 AM Brian Gerst
>wrote:
>> >
>> > The ABI prefix for syscalls specifies the argument register
>mapping, so
>> > there is no specific reason to
On June 19, 2020 5:03:33 PM PDT, ron minnich wrote:
>It seems fine to me, but I did not initially object to the use of that
>name anyway. hpa, what do you think?
>
>On Fri, Jun 19, 2020 at 7:31 AM Tom Rini wrote:
>>
>> Most architectures have been passing the l
On June 1, 2020 6:59:26 AM PDT, Andy Lutomirski wrote:
>
>
>> On Jun 1, 2020, at 2:23 AM, Billy Laws wrote:
>>
>>
>>>
>>> On May 30, 2020, at 5:26 PM, Gabriel Krisman Bertazi
> wrote:
>>>
>>> Andy Lutomirski writes:
>>>
>>> On May 29, 2020, at 11:00 PM, Gabriel Krisman Bertazi
>
On May 24, 2020 2:19:45 PM PDT, Sasha Levin wrote:
>On Sun, May 24, 2020 at 12:45:18PM -0700, h...@zytor.com wrote:
>>There are legitimate reasons to write a root-hole module, the main one
>being able to test security features like SMAP. I have requested before
>a TAINT flag specifically for this
On May 22, 2020 5:45:39 PM PDT, Thomas Gleixner wrote:
>Don,
>
>Don Porter writes:
>> On 5/19/20 12:48 PM, Jarkko Sakkinen wrote:
>>> On Tue, May 19, 2020 at 01:03:25AM +0200, Thomas Gleixner wrote:
That justifies to write books which recommend to load a kernel
>module
which
On May 10, 2020 4:59:17 AM PDT, David Laight wrote:
>From: Peter Anvin
>> Sent: 08 May 2020 18:32
>> On 2020-05-08 10:21, Nick Desaulniers wrote:
>> >>
>> >> One last suggestion. Add the "b" modifier to the mask operand:
>"orb
>> >> %b1, %0". That forces the compiler to use the 8-bit register
On May 8, 2020 3:58:17 AM PDT, Uros Bizjak wrote:
>Current minimum required version of binutils is 2.23,
>which supports RDRAND and RDSEED instruction mnemonics.
>
>Replace the byte-wise specification of RDRAND and
>RDSEED with these proper mnemonics.
>
>Signed-off-by: Uros Bizjak
>CC: "H. Peter
On May 7, 2020 8:09:35 AM PDT, David Laight wrote:
>From: Brian Gerst
>> Sent: 07 May 2020 14:32
>...
>> I think the bug this worked around was that the compiler didn't
>detect
>> that CONST_MASK(nr) was also constant and doesn't need to be put into
>> a register. The question is does that bug
On May 7, 2020 6:32:24 AM PDT, Brian Gerst wrote:
>On Thu, May 7, 2020 at 3:02 AM wrote:
>>
>> On May 6, 2020 11:18:09 PM PDT, Brian Gerst
>wrote:
>> >On Tue, May 5, 2020 at 1:47 PM Nick Desaulniers
>> > wrote:
>> >>
>> >> From: Sedat Dilek
>> >>
>> >> It turns out that if your config tickles
On May 7, 2020 4:34:22 AM PDT, Peter Zijlstra wrote:
>On Tue, May 05, 2020 at 11:07:24AM -0700, h...@zytor.com wrote:
>> On May 5, 2020 10:44:22 AM PDT, Nick Desaulniers
> wrote:
>
>> >@@ -54,7 +54,7 @@ arch_set_bit(long nr, volatile unsigned long
>*addr)
>> >if (__builtin_constant_p(nr)) {
On May 7, 2020 1:35:01 AM PDT, David Laight wrote:
>From: h...@zytor.com
>> Sent: 07 May 2020 08:59
>> On May 7, 2020 12:44:44 AM PDT, David Laight
> wrote:
>> >From: Brian Gerst
>> >> Sent: 07 May 2020 07:18
>> >...
>> >> > --- a/arch/x86/include/asm/bitops.h
>> >> > +++
On May 7, 2020 12:44:44 AM PDT, David Laight wrote:
>From: Brian Gerst
>> Sent: 07 May 2020 07:18
>...
>> > --- a/arch/x86/include/asm/bitops.h
>> > +++ b/arch/x86/include/asm/bitops.h
>> > @@ -54,7 +54,7 @@ arch_set_bit(long nr, volatile unsigned long
>*addr)
>> > if
On May 6, 2020 11:18:09 PM PDT, Brian Gerst wrote:
>On Tue, May 5, 2020 at 1:47 PM Nick Desaulniers
> wrote:
>>
>> From: Sedat Dilek
>>
>> It turns out that if your config tickles __builtin_constant_p via
>> differences in choices to inline or not, this now produces invalid
>> assembly:
>>
>> $
On May 6, 2020 7:03:52 AM PDT, Jason Yan wrote:
>The '==' expression itself is bool, no need to convert it to bool
>again.
>This fixes the following coccicheck warning:
>
>arch/x86/net/bpf_jit_comp32.c:1478:50-55: WARNING: conversion to bool
>not needed here
On May 5, 2020 10:44:22 AM PDT, Nick Desaulniers
wrote:
>From: Sedat Dilek
>
>It turns out that if your config tickles __builtin_constant_p via
>differences in choices to inline or not, this now produces invalid
>assembly:
>
>$ cat foo.c
>long a(long b, long c) {
> asm("orb\t%1, %0" : "+q"(c):
On October 18, 2019 3:45:14 AM PDT, David Laight
wrote:
>From: Luck, Tony
>> Sent: 18 October 2019 00:28
>...
>> 2) Fix set_bit() et. al. to not issue atomic operations that cross
>boundaries.
>>
>> Fenghua had been pursuing option #1 in previous iterations. He found
>a few
>> more places with
On September 23, 2019 11:15:20 AM PDT, Steve Wahl wrote:
>Our hardware (UV aka Superdome Flex) has address ranges marked
>reserved by the BIOS. Access to these ranges is caught as an error,
>causing the BIOS to halt the system.
>
>Initial page tables mapped a large range of physical addresses
On September 12, 2019 8:00:39 AM GMT+01:00, Adrian Hunter
wrote:
>On 29/08/19 2:46 PM, Peter Zijlstra wrote:
>> On Thu, Aug 29, 2019 at 12:40:56PM +0300, Adrian Hunter wrote:
>>> Can you expand on "and ensure the poke_handler preserves the
>existing
>>> control flow"? Whatever the INT3-handler
On September 10, 2019 7:28:28 AM GMT+01:00, Ingo Molnar
wrote:
>
>* h...@zytor.com wrote:
>
>> I would strongly suggest that we change the term "emulation" to
>> "spoofing" for these instructions. We need to explain that we do
>*not*
>> execute these instructions the was the CPU would have,
On September 6, 2019 12:22:21 AM GMT+01:00, Brendan Shanks
wrote:
>Add emulation of the sgdt, sidt, and smsw instructions for 64-bit
>processes.
>
>Wine users have encountered a number of 64-bit Windows games that use
>these instructions (particularly sgdt), and were crashing when run on
On September 8, 2019 8:22:48 AM GMT+01:00, Borislav Petkov
wrote:
>On Sat, Sep 07, 2019 at 02:26:10PM -0700, Ricardo Neri wrote:
>> > Wine users have encountered a number of 64-bit Windows games that
>use
>> > these instructions (particularly sgdt), and were crashing when run
>on
>> >
On August 15, 2019 8:05:30 AM PDT, "Theodore Y. Ts'o" wrote:
>On Thu, Aug 15, 2019 at 03:22:45PM +0200, Arnd Bergmann wrote:
>> If 64-bit Windows relies on a working EFI RTC implementation, we
>could
>> decide to leave the driver enabled on 64-bit and only disable it for
>> 32-bit EFI. That way,
On August 14, 2019 9:26:36 AM PDT, David Laight wrote:
>From: Theodore Y. Ts'o
>> Sent: 14 August 2019 01:06
>> On Tue, Aug 13, 2019 at 10:30:34AM -0700, Linus Torvalds wrote:
>> >
>> > I suspect the only actual _valid_ use in the kernel for a time zone
>> > setting is likely for RTC clock
On August 1, 2019 5:24:29 AM PDT, Peter Zijlstra wrote:
>On Wed, Jul 31, 2019 at 11:10:36PM -0700, h...@zytor.com wrote:
>> On July 31, 2019 4:55:47 PM PDT, Miguel Ojeda
> wrote:
>> >On Wed, Jul 31, 2019 at 11:01 PM wrote:
>> >>
>> >> The standard is moving toward adding this as an attribute
On July 31, 2019 4:55:47 PM PDT, Miguel Ojeda
wrote:
>On Wed, Jul 31, 2019 at 11:01 PM wrote:
>>
>> The standard is moving toward adding this as an attribute with the
>[[fallthrough]] syntax; it is in C++17, not sure when it will be in C
>be if it isn't already.
>
>Not yet, but it seems to be
On July 31, 2019 10:34:26 PM PDT, Andy Lutomirski wrote:
>On Mon, Jul 29, 2019 at 2:58 PM Dmitry Safonov wrote:
>>
>> As it has been discussed on timens RFC, adding a new conditional
>branch
>> `if (inside_time_ns)` on VDSO for all processes is undesirable.
>> It will add a penalty for everybody
On July 31, 2019 11:48:32 AM PDT, Peter Zijlstra wrote:
>On Wed, Jul 31, 2019 at 11:24:36AM -0700, h...@zytor.com wrote:
>> >> > +/*
>> >> > + * Add the pseudo keyword 'fallthrough' so case statement
>blocks
>> >> > + * must end with any of these keywords:
>> >> > + * break;
>> >> > + *
On July 31, 2019 10:51:37 AM PDT, Joe Perches wrote:
>On Wed, 2019-07-31 at 19:14 +0200, Pavel Machek wrote:
>> On Tue 2019-07-30 22:35:18, Joe Perches wrote:
>> > Reserve the pseudo keyword 'fallthrough' for the ability to convert
>the
>> > various case block /* fallthrough */ style comments to
On July 30, 2019 1:08:43 AM PDT, Peter Zijlstra wrote:
>On Mon, Jul 29, 2019 at 11:44:17PM +0300, Alexey Dobriyan wrote:
>> On Mon, Jul 29, 2019 at 12:04:47PM +0200, Peter Zijlstra wrote:
>> > +#define _ASM_ARG1B__ASM_FORM_RAW(dil)
>> > +#define _ASM_ARG2B__ASM_FORM_RAW(sil)
>> >
On July 25, 2019 2:48:30 PM PDT, Thomas Gleixner wrote:
>On Thu, 25 Jul 2019, John Hubbard wrote:
>> On 7/25/19 12:22 AM, Thomas Gleixner wrote:
>> > It removes the clearing of the range between kbd_status and hdr
>without any
>> > replacement. It neither clears edid_info.
>>
>>
>> Yes. Somehow
On July 24, 2019 4:15:28 PM PDT, john.hubb...@gmail.com wrote:
>From: John Hubbard
>
>Recent gcc compilers (gcc 9.1) generate warnings about an
>out of bounds memset, if you trying memset across several fields
>of a struct. This generated a couple of warnings on x86_64 builds.
>
>Because struct
On June 7, 2019 11:10:19 AM PDT, Andy Lutomirski wrote:
>
>
>> On Jun 7, 2019, at 10:34 AM, Peter Zijlstra
>wrote:
>>
>> On Sat, Jun 08, 2019 at 12:47:08AM +0900, Masami Hiramatsu wrote:
>>
This fits almost all text_poke_bp() users, except
arch_unoptimize_kprobe() which restores
On May 17, 2019 7:16:04 PM PDT, Rob Landley wrote:
>On 5/17/19 4:41 PM, H. Peter Anvin wrote:
>> On 5/17/19 1:18 PM, h...@zytor.com wrote:
>>>
>>> Ok... I just realized this does not work for a modular initramfs,
>composed at load time from multiple files, which is a very real
>problem. Should be
g
>the
>>> files, which most archivers won't do.
>>>
>>> Either way it seems cleaner to have this per file; especially if/as
>it
>>> can be done without actually mucking up the format.
>>>
>>> I need to run, but I'll post a more detailed
On May 20, 2019 4:19:28 PM PDT, Thomas Garnier wrote:
>From: Thomas Garnier
>
>Add a new _ASM_MOVABS macro to fetch a symbol address. It will be used
>to replace "_ASM_MOV $, %dst" code construct that are not
>compatible with PIE.
>
>Signed-off-by: Thomas Garnier
>---
>
On May 17, 2019 9:55:19 AM PDT, Roberto Sassu wrote:
>This patch adds support for an alternative method to add xattrs to
>files in
>the rootfs filesystem. Instead of extracting them directly from the ram
>disk image, they are extracted from a regular file called .xattr-list,
>that
>can be added
On May 12, 2019 8:31:05 AM PDT, Dominik Brodowski
wrote:
>On Sun, May 12, 2019 at 03:18:16AM -0700, h...@zytor.com wrote:
>> > Couldn't this parsing of the .xattr-list file and the setting of
>the xattrs
>> > be done equivalently by the initramfs' /init? Why is kernel
>involvement
>> > actually
On May 12, 2019 5:02:30 PM PDT, Mimi Zohar wrote:
>On Sun, 2019-05-12 at 17:31 +0200, Dominik Brodowski wrote:
>> On Sun, May 12, 2019 at 08:52:47AM -0400, Mimi Zohar wrote:
>
>
>> > It's too late. The /init itself should be signed and verified.
>>
>> Could you elaborate a bit more about the
On May 12, 2019 2:17:48 AM PDT, Dominik Brodowski
wrote:
>On Thu, May 09, 2019 at 01:24:17PM +0200, Roberto Sassu wrote:
>> This proposal consists in marshaling pathnames and xattrs in a file
>called
>> .xattr-list. They are unmarshaled by the CPIO parser after all files
>have
>> been extracted.
On May 6, 2019 12:20:12 AM PDT, Ingo Molnar wrote:
>Linus,
>
>Please pull the latest core-objtool-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>core-objtool-for-linus
>
># HEAD: 29da93fea3ea39ab9b12270cc6be1b70ef201c9e mm/uaccess: Use
>'unsigned long' to
On April 21, 2019 11:28:42 AM PDT, Ingo Molnar wrote:
>
>* Alexey Dobriyan wrote:
>
>> TASK_SIZE macro is quite deceptive: it looks like a constant but in
>fact
>> compiles to 50+ bytes.
>>
>> Space savings on x86_64 defconfig:
>>
>> add/remove: 1/0 grow/shrink: 3/24 up/down: 77/-2247 (-2170)
On March 29, 2019 3:05:54 PM PDT, "Paul E. McKenney"
wrote:
>On Fri, Mar 29, 2019 at 02:51:26PM -0700, H. Peter Anvin wrote:
>> On 3/29/19 2:09 PM, Paul E. McKenney wrote:
>> >>
>> >> Note: the atomic versions of these functions obviously need to
>have
>> >> "volatile" and the clobber anyway, as
On March 21, 2019 11:18:53 AM PDT, Linus Torvalds
wrote:
>On Thu, Mar 21, 2019 at 11:05 AM Andy Lutomirski
>wrote:
>>
>> In the long run, I think the right solution is to rewrite even more
>of
>> this mess in C. We really ought to be able to put the IRQ flag
>> tracing and the context tracking
On March 21, 2019 10:25:05 AM PDT, Denys Vlasenko wrote:
>On 3/18/19 7:10 PM, Linus Torvalds wrote:
>> On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra
> wrote:
>>>
>>> How about I do a patch that schedules EFLAGS for both 32bit and
>64bit,
>>> mark this for backporting to infinity.
>>>
>>> And
On March 18, 2019 11:10:22 AM PDT, Linus Torvalds
wrote:
>On Mon, Mar 18, 2019 at 10:51 AM Peter Zijlstra
>wrote:
>>
>> How about I do a patch that schedules EFLAGS for both 32bit and
>64bit,
>> mark this for backporting to infinity.
>>
>> And then at the end, after the objtool-ac bits land, I
On March 18, 2019 4:52:19 PM PDT, Matthias Kaehlcke wrote:
>On Mon, Mar 18, 2019 at 04:44:03PM -0700, h...@zytor.com wrote:
>> On March 18, 2019 3:16:39 PM PDT, Matthias Kaehlcke
> wrote:
>> >On Mon, Mar 18, 2019 at 02:50:44PM -0700, h...@zytor.com wrote:
>> >> On March 18, 2019 2:31:13 PM PDT,
On March 18, 2019 4:52:19 PM PDT, Matthias Kaehlcke wrote:
>On Mon, Mar 18, 2019 at 04:44:03PM -0700, h...@zytor.com wrote:
>> On March 18, 2019 3:16:39 PM PDT, Matthias Kaehlcke
> wrote:
>> >On Mon, Mar 18, 2019 at 02:50:44PM -0700, h...@zytor.com wrote:
>> >> On March 18, 2019 2:31:13 PM PDT,
On March 18, 2019 3:16:39 PM PDT, Matthias Kaehlcke wrote:
>On Mon, Mar 18, 2019 at 02:50:44PM -0700, h...@zytor.com wrote:
>> On March 18, 2019 2:31:13 PM PDT, Matthias Kaehlcke
> wrote:
>> >On Fri, Mar 15, 2019 at 01:54:50PM -0700, Matthias Kaehlcke wrote:
>> >> The compiler may emit calls to
On March 18, 2019 2:56:05 PM PDT, Matthias Kaehlcke wrote:
>On Mon, Mar 18, 2019 at 02:47:13PM -0700, 'Nick Desaulniers' via Clang
>Built Linux wrote:
>> On Mon, Mar 18, 2019 at 2:10 PM Matthias Kaehlcke
>wrote:
>> >
>> > The clang option -Oz enables *aggressive* optimization for size,
>> >
On March 18, 2019 2:31:13 PM PDT, Matthias Kaehlcke wrote:
>On Fri, Mar 15, 2019 at 01:54:50PM -0700, Matthias Kaehlcke wrote:
>> The compiler may emit calls to __lshrti3 from the compiler runtime
>> library, which results in undefined references:
>>
>> arch/x86/kvm/x86.o: In function
On March 15, 2019 4:47:01 PM PDT, Matthias Kaehlcke wrote:
>On Fri, Mar 15, 2019 at 03:12:08PM -0700, h...@zytor.com wrote:
>> On March 15, 2019 3:06:37 PM PDT, Nick Desaulniers
> wrote:
>> >On Fri, Mar 15, 2019 at 1:54 PM Matthias Kaehlcke
>> >wrote:
>> >>
>> >> The compiler may emit calls to
On March 15, 2019 4:34:10 PM PDT, Matthias Kaehlcke wrote:
>Hi Peter,
>
>On Fri, Mar 15, 2019 at 03:08:57PM -0700, h...@zytor.com wrote:
>> On March 15, 2019 3:06:37 PM PDT, Nick Desaulniers
> wrote:
>> >On Fri, Mar 15, 2019 at 1:54 PM Matthias Kaehlcke
>> >wrote:
>> >>
>> >> The compiler may
On March 15, 2019 3:29:06 PM PDT, Matthias Kaehlcke wrote:
>Hi Nick,
>
>On Fri, Mar 15, 2019 at 02:31:09PM -0700, 'Nick Desaulniers' via Clang
>Built Linux wrote:
>> On Fri, Mar 15, 2019 at 12:54 PM Matthias Kaehlcke
>wrote:
>> >
>> > Building the 32-bit vDSO with a recent clang version fails
On March 15, 2019 3:06:37 PM PDT, Nick Desaulniers
wrote:
>On Fri, Mar 15, 2019 at 1:54 PM Matthias Kaehlcke
>wrote:
>>
>> The compiler may emit calls to __lshrti3 from the compiler runtime
>> library, which results in undefined references:
>>
>> arch/x86/kvm/x86.o: In function
On March 15, 2019 3:06:37 PM PDT, Nick Desaulniers
wrote:
>On Fri, Mar 15, 2019 at 1:54 PM Matthias Kaehlcke
>wrote:
>>
>> The compiler may emit calls to __lshrti3 from the compiler runtime
>> library, which results in undefined references:
>>
>> arch/x86/kvm/x86.o: In function
On March 9, 2019 10:18:40 PM PST, Greg Kroah-Hartman
wrote:
>On Sat, Mar 09, 2019 at 10:10:19PM -0800, h...@zytor.com wrote:
>> On March 8, 2019 4:50:03 AM PST, Greg Kroah-Hartman
> wrote:
>> >5.0-stable review patch. If anyone has any objections, please let
>me
>> >know.
>> >
>>
On March 8, 2019 4:50:03 AM PST, Greg Kroah-Hartman
wrote:
>5.0-stable review patch. If anyone has any objections, please let me
>know.
>
>--
>
>From: Kirill A. Shutemov
>
>commit 6f913de3231e1d70a871135b38219da7810df218 upstream.
>
>EFI systems do not necessarily provide a
On March 7, 2019 3:12:07 PM PST, Joel Fernandes wrote:
>Enrico,
>
>On Thu, Mar 07, 2019 at 11:11:22PM +0100, Enrico Weigelt, metux IT
>consult wrote:
>> On 07.03.19 21:55, Greg KH wrote:
>>
>> > Ick, no, no more squashfs please, let's just kill that mess once
>and for
>> > all :)
>>
>> okay,
On March 7, 2019 10:48:13 AM PST, Peter Zijlstra wrote:
>On Thu, Mar 07, 2019 at 09:54:14AM -0800, Linus Torvalds wrote:
>> On Thu, Mar 7, 2019 at 9:41 AM Peter Zijlstra
>wrote:
>> > >
>> > > What's the call site that made you go "just add __memset() to the
>list"?
>> >
>> >
On March 7, 2019 9:18:29 AM PST, Josh Poimboeuf wrote:
>On Thu, Mar 07, 2019 at 09:04:36AM -0800, h...@zytor.com wrote:
>> On March 7, 2019 8:47:05 AM PST, Josh Poimboeuf
>wrote:
>> >On Thu, Mar 07, 2019 at 02:13:12PM +0100, Peter Zijlstra wrote:
>> >> On Thu, Mar 07, 2019 at 01:55:26PM +0100,
On March 7, 2019 3:45:11 AM PST, Peter Zijlstra wrote:
>Teach objtool to validate the UACCESS (SMAP, PAN) rules with are
>currently
>unenforced and (therefore obviously) violated.
>
>UACCESS sections should be small; we want to limit the amount of code
>that can
>touch userspace. Furthermore,
On March 7, 2019 8:47:05 AM PST, Josh Poimboeuf wrote:
>On Thu, Mar 07, 2019 at 02:13:12PM +0100, Peter Zijlstra wrote:
>> On Thu, Mar 07, 2019 at 01:55:26PM +0100, Peter Zijlstra wrote:
>> > On Thu, Mar 07, 2019 at 01:03:17PM +0100, Peter Zijlstra wrote:
>>
>>
>> > > 01be 20d3: 31 c0
On March 7, 2019 8:33:26 AM PST, Linus Torvalds
wrote:
>On Thu, Mar 7, 2019 at 3:52 AM Peter Zijlstra
>wrote:
>>
>> XXX: are we sure we want __memset marked AC-safe?
>
>It's certainly one of the safer functions to call with AC set, but it
>sounds wrong anyway. It's not like it's likely to leak
On March 6, 2019 11:29:47 PM PST, Borislav Petkov wrote:
>On Mon, Feb 11, 2019 at 08:42:51PM +0100, Borislav Petkov wrote:
>> On Mon, Feb 11, 2019 at 11:27:03AM -0800, Nadav Amit wrote:
>> > Is there any comment over static_cpu_has()? ;-)
>>
>> Almost:
>>
>> /*
>> * Static testing of CPU
On March 7, 2019 7:10:36 AM PST, Borislav Petkov wrote:
>On Mon, Feb 11, 2019 at 12:32:41PM -0800, Nadav Amit wrote:
>> BTW: the “__pure” attribute is useless when “__always_inline” is
>used.
>> Unless it is intended to be some sort of comment, of course.
>
>---
>From: Borislav Petkov
>Date:
On February 23, 2019 12:39:42 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 22, 2019 at 03:39:48PM -0800, h...@zytor.com wrote:
>> Objtool could also detect CLAC-STAC or STAC-CLAC sequences without
>> memory operations and remove them; don't know how often that happens,
>> but I know it *does*
On February 23, 2019 12:39:42 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 22, 2019 at 03:39:48PM -0800, h...@zytor.com wrote:
>> Objtool could also detect CLAC-STAC or STAC-CLAC sequences without
>> memory operations and remove them; don't know how often that happens,
>> but I know it *does*
1 - 100 of 438 matches
Mail list logo
