On May 22, 2017 10:49:06 PM PDT, Ingo Molnar wrote:
>
>* H. Peter Anvin wrote:
>
>> On 05/22/17 04:12, Ingo Molnar wrote:
>> \>>
>> >> This construct might be useful for other arches, which is why I
>called
>> >> it "FP" instead of "BP". But then I ruined that with the last 3
>:-)
>> >
>> > Ple
On May 26, 2017 8:51:48 AM PDT, Linus Torvalds
wrote:
>On Fri, May 26, 2017 at 6:00 AM, Kirill A. Shutemov
> wrote:
>>
>> I don't see how kernel threads can use 4-level paging. It doesn't
>work
>> from virtual memory layout POV. Kernel claims half of full virtual
>address
>> space for itself -- 2
On May 26, 2017 12:23:18 PM PDT, Dave Hansen wrote:
>On 05/26/2017 11:24 AM, h...@zytor.com wrote:
>> The only case where that even has any utility is for an application
>> to want more than 128 TiB address space on a machine with no more
>> than 64 TiB of RAM. It is kind of a narrow use case, I
On May 26, 2017 6:00:57 AM PDT, "Kirill A. Shutemov"
wrote:
>On Thu, May 25, 2017 at 04:24:24PM -0700, Linus Torvalds wrote:
>> On Thu, May 25, 2017 at 1:33 PM, Kirill A. Shutemov
>> wrote:
>> > Here' my first attempt to bring boot-time between 4- and 5-level
>paging.
>> > It looks not too terri
On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov wrote:
>Some 64-bit atomic operations use 'long long' as operand/return type
>(e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h);
>while others use 'long' (e.g. arch/x86/include/asm/atomic64_64.h).
>This makes it impossible to write por
On May 28, 2017 2:29:32 AM PDT, Dmitry Vyukov wrote:
>On Sun, May 28, 2017 at 1:02 AM, wrote:
>> On May 26, 2017 12:09:04 PM PDT, Dmitry Vyukov
>wrote:
>>>Some 64-bit atomic operations use 'long long' as operand/return type
>>>(e.g. asm-generic/atomic64.h, arch/x86/include/asm/atomic64_32.h);
>
On October 17, 2017 5:42:41 PM GMT+02:00, "Kirill A. Shutemov"
wrote:
>On Tue, Oct 03, 2017 at 11:27:54AM +0300, Kirill A. Shutemov wrote:
>> On Fri, Sep 29, 2017 at 05:08:15PM +0300, Kirill A. Shutemov wrote:
>> > The first bunch of patches that prepare kernel to boot-time
>switching
>> > betwee
On June 21, 2018 6:58:51 PM PDT, Ingo Molnar wrote:
>
>* H. Peter Anvin, Intel wrote:
>
>> From: "H. Peter Anvin"
>>
>> Give a debugger access to the visible part of the GDT and LDT. This
>> allows a debugger to find out what a particular segment descriptor
>> corresponds to; e.g. if %cs is 16
On June 22, 2018 7:49:13 AM PDT, Andy Lutomirski wrote:
>On Thu, Jun 21, 2018 at 2:18 PM H. Peter Anvin, Intel
> wrote:
>>
>> From: "H. Peter Anvin"
>>
>> Provide ptrace/regset access to the LDT, if one exists. This
>> interface provides both read and write access. The write code is
>> unified w
On January 21, 2018 6:11:07 PM PST, Linus Torvalds
wrote:
>On Sun, Jan 21, 2018 at 3:46 PM, Nadav Amit
>wrote:
>> I wanted to see whether segments protection can be a replacement for
>PTI
>> (yes, excluding SMEP emulation), or whether speculative execution
>“ignores”
>> limit checks, similarly t
On January 22, 2018 4:32:14 PM PST, "Mehta, Sohil"
wrote:
>On Fri, 2018-01-19 at 16:33 +0200, Andy Shevchenko wrote:
>> Since non atomic readq() and writeq() were added some of the drivers
>> would like to use it in a manner of:
>>
>> #include
>> ...
>> pr_debug("Debug value of some register:
On March 26, 2018 2:11:51 AM PDT, Thomas Gleixner wrote:
>On Mon, 26 Mar 2018, Rajneesh Bhardwaj wrote:
>
>> On Sun, Mar 25, 2018 at 01:50:40PM +0200, Thomas Gleixner wrote:
>> > On Thu, 22 Mar 2018, Anshuman Gupta wrote:
>> >
>> > > From: Rajneesh Bhardwaj
>> > >
>> > > >From Skylake onwards,
On November 23, 2018 1:27:02 AM PST, Julien Thierry
wrote:
>Hi,
>
>I made an attempt at implementing the
>user_access_begin()/user_access_end() macros along with the
>get/put_user_unsafe() for arm64 by toggling the status of PAN (more or
>less similar to x86's STAC/CTAC).
>
>With a small mista
On November 23, 2018 12:03:07 PM PST, Guenter Roeck wrote:
>Hi,
>
>On Mon, Nov 19, 2018 at 07:45:56PM +0100, Borislav Petkov wrote:
>> From: Borislav Petkov
>>
>> Currently, the kernel uses
>>
>> [LM]FENCE; RDTSC
>>
>> in the timekeeping code, to guarantee monotonicity of time where the
>> *
u mean RDTSCP. :)
>
>Also in the sense that you have a single instruction which gives you
>that barrier of waiting for all older insns to retire before reading
>the
>TSC vs two where you don't necessarily know what happens on the uarch
>level. I mean, nothing probably happens but
On November 10, 2018 7:22:29 AM PST, Juergen Gross wrote:
>On 09/11/2018 23:23, H. Peter Anvin wrote:
>> I just noticed this patch -- I missed it because the cover message
>> seemed far more harmless so I didn't notice this change.
>>
>> THIS PATCH IS FATALLY WRONG AND NEEDS TO BE IMMEDIATELY REV
On December 3, 2018 2:38:11 AM PST, Juergen Gross wrote:
>In case a broken boot loader doesn't clear its struct boot_params clear
>rsdp_addr in sanitize_boot_params().
>
>This fixes commit e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP
>address from boot params if available") e.g. for the case of
On June 25, 2018 9:33:35 AM PDT, Randy Dunlap wrote:
>On 06/25/2018 03:25 AM, Jan Beulich wrote:
>> Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms - use
>> 32-bit ones instead.
>
>Hmph. Is that considered a bug (errata)?
>
>URL/references?
>
>Are these changes really only zeroing t
On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski wrote:
>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski
>wrote:
>>
>>
>>
>>> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin
> wrote:
>>>
On 06/22/18 07:24, Andy Lutomirski wrote:
That RPL3 part is false. The following program does:
On June 27, 2018 11:22:14 AM PDT, h...@zytor.com wrote:
>On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski
>wrote:
>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski
>
>>wrote:
>>>
>>>
>>>
On Jun 22, 2018, at 11:29 AM, H. Peter Anvin
>> wrote:
> On 06/22/18 07:24, Andy Lutomirski wr
On June 28, 2018 1:33:24 PM PDT, Andy Lutomirski wrote:
>On Wed, Jun 27, 2018 at 11:22 AM, wrote:
>> On June 27, 2018 11:19:12 AM PDT, Andy Lutomirski
>wrote:
>>>On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski
>
>>>wrote:
> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin
>>> w
On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers
wrote:
>H. Peter,
>
>It was reported [0] that compiling the Linux kernel with Clang +
>CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due
>to
>how GCC does not emit a stack guard for static inline functions (see
>Alistair's excel
On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers
wrote:
>H. Peter,
>
>It was reported [0] that compiling the Linux kernel with Clang +
>CC_STACKPROTECTOR_STRONG was causing a crash in native_save_fl(), due
>to
>how GCC does not emit a stack guard for static inline functions (see
>Alistair's excel
On May 24, 2018 12:49:56 PM PDT, Tom Stellard wrote:
>On 05/24/2018 11:19 AM, h...@zytor.com wrote:
>> On May 23, 2018 3:08:19 PM PDT, Nick Desaulniers
> wrote:
>>> H. Peter,
>>>
>>> It was reported [0] that compiling the Linux kernel with Clang +
>>> CC_STACKPROTECTOR_STRONG was causing a crash i
On May 24, 2018 1:52:16 PM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 1:26 PM Nick Desaulniers
>
>wrote:
>> On Thu, May 24, 2018 at 11:59 AM wrote:
>> > Issue 3: Let's face it, reading and writing the flags should be
>builtins,
>> exactly because it has to do stack operations, which r
On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin wrote:
>> COMPILER AR: "=rm" should NEVER generate worse code than "=r". That
>is
>> unequivocally a compiler bug.
>
>Filed: https://bugs.llvm.org/show_bug.cgi?id=37583
>
>> >> You are claimin
On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 3:43 PM wrote:
>> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
>
>wrote:
>> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin
>wrote:
>> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r".
>That
>>
On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
wrote:
>On Thu, May 24, 2018 at 3:43 PM wrote:
>> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
>
>wrote:
>> >On Thu, May 24, 2018 at 3:05 PM H. Peter Anvin
>wrote:
>> >> COMPILER AR: "=rm" should NEVER generate worse code than "=r".
>That
>>
On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers
wrote:
>On Fri, May 25, 2018 at 9:33 AM wrote:
>> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
>
>wrote:
>> >On Thu, May 24, 2018 at 3:43 PM wrote:
>> >> On May 24, 2018 3:31:05 PM PDT, Nick Desaulniers
>> >
>> >wrote:
>> >> >On Thu, May 24,
On May 25, 2018 10:31:51 AM PDT, Nick Desaulniers
wrote:
>On Fri, May 25, 2018 at 9:53 AM wrote:
>> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers
>
>wrote:
>> >On Fri, May 25, 2018 at 9:33 AM wrote:
>> >> On May 25, 2018 9:27:40 AM PDT, Nick Desaulniers
>> > wrote:
>> >When you say
>> >
>> >
On May 25, 2018 10:49:28 AM PDT, Nick Desaulniers
wrote:
>On Fri, May 25, 2018 at 10:35 AM Tom Stellard
>wrote:
>> On 05/25/2018 10:31 AM, Nick Desaulniers wrote:
>> > On Fri, May 25, 2018 at 9:53 AM wrote:
>> >> On May 25, 2018 9:46:42 AM PDT, Nick Desaulniers <
>ndesaulni...@google.com>
>> >
On May 14, 2018 2:04:38 AM PDT, David Laight wrote:
>From: H. Peter Anvin
>> Sent: 11 May 2018 19:54
>>
>> On 05/10/18 09:39, David Laight wrote:
>> > From: Alexey Dobriyan
>> >> Sent: 07 May 2018 22:38
>> >>
>> >> Use INT3 instead of NOP. All that padding between functions is
>> >> an illegal ar
On May 31, 2018 1:14:59 PM PDT, Andy Lutomirski wrote:
>On Thu, May 31, 2018 at 10:58 AM Chang S. Bae
> wrote:
>>
>> From: Andy Lutomirski
>>
>> ptrace can read FS/GS base using the register access API
>> (PTRACE_PEEKUSER, etc) or PTRACE_ARCH_PRCTL. Make both of these
>> mechanisms return the ac
On May 31, 2018 1:25:39 PM PDT, Andy Lutomirski wrote:
>On Thu, May 31, 2018 at 10:58 AM Chang S. Bae
> wrote:
>>
>> When adding new feature support, patches need to be
>> incrementally applied and tested with temporal parameters.
>> For such testing (or root-only) purposes, the new flag
>> will s
On July 5, 2018 1:09:12 PM PDT, Jarkko Sakkinen
wrote:
>On Thu, Jul 05, 2018 at 08:31:42AM -0700, Dave Hansen wrote:
>> On 07/03/2018 11:19 AM, Jarkko Sakkinen wrote:
>> > +struct sgx_secs {
>> > + uint64_t size;
>> > + uint64_t base;
>> > + uint32_t ssaframesize;
>> > + uint32_t miscselect;
On May 17, 2018 2:30:01 PM PDT, Alexey Dobriyan wrote:
>32-bit instructions are 1 byte shorter than 16-bit instructions.
>
>Signed-off-by: Alexey Dobriyan
>---
>
> arch/x86/kernel/verify_cpu.S |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>--- a/arch/x86/kernel/verify_cpu.S
On May 18, 2018 11:25:32 AM PDT, Linus Torvalds
wrote:
>On Fri, May 18, 2018 at 10:24 AM Nadav Amit wrote:
>
>> Will it be ok just to use a global inline asm to set an “.include”
>directive
>> that gas would later process? (I can probably wrap it in a C macro so
>it
>> won’t be too disgusting)
>
On May 18, 2018 11:00:05 AM PDT, Bart Van Assche wrote:
>The next patch in this series introduces a call to cmpxchg64()
>in the block layer core for those architectures on which this
>functionality is available. Make it possible to test whether
>cmpxchg64() is available by introducing CONFIG_ARCH_
On May 18, 2018 11:50:12 AM PDT, Linus Torvalds
wrote:
>On Fri, May 18, 2018 at 11:34 AM wrote:
>
>> On May 18, 2018 11:25:32 AM PDT, Linus Torvalds <
>torva...@linux-foundation.org> wrote:
>
>> Unfortunately gcc doesn't guarantee that global assembly inlines will
>appear at the top of the file.
On May 18, 2018 12:02:50 PM PDT, Nadav Amit wrote:
>h...@zytor.com wrote:
>
>> On May 18, 2018 11:50:12 AM PDT, Linus Torvalds
> wrote:
>>> On Fri, May 18, 2018 at 11:34 AM wrote:
>>>
On May 18, 2018 11:25:32 AM PDT, Linus Torvalds <
>>> torva...@linux-foundation.org> wrote:
>>>
Unfor
On May 18, 2018 12:21:00 PM PDT, Linus Torvalds
wrote:
>On Fri, May 18, 2018 at 12:18 PM Nadav Amit wrote:
>
>> Gnu ASM manual says: "Each time you run as it assembles exactly one
>source
>> program. The source program is made up of one or more files.”
>
>Ok, that counts as documentation, althou
On May 18, 2018 12:36:20 PM PDT, Nadav Amit wrote:
>h...@zytor.com wrote:
>
>> On May 18, 2018 12:21:00 PM PDT, Linus Torvalds
> wrote:
>>> On Fri, May 18, 2018 at 12:18 PM Nadav Amit
>wrote:
>>>
Gnu ASM manual says: "Each time you run as it assembles exactly one
>>> source
program. Th
On December 10, 2018 5:40:33 PM PST, Linus Torvalds
wrote:
>On Mon, Dec 10, 2018 at 5:23 PM Andy Lutomirski
>wrote:
>>
>> I'm seriously considering sending a patch to remove x32 support from
>> upstream Linux. Here are some problems with it:
>
>I talked to Arnd (I think - we were talking about
On January 6, 2019 11:40:56 PM PST, Cao jin wrote:
>According to objdump output of setup, function memset is not used in
>setup code. Currently, all usage of memset in setup come from macro
>definition of string.h.
>
>Signed-off-by: Cao jin
>---
>Compiled and booted under x86_64; compiled under i
On January 7, 2019 12:52:57 AM PST, Cao jin wrote:
>Hi,
>
>On 1/7/19 3:59 PM, h...@zytor.com wrote:
>> On January 6, 2019 11:40:56 PM PST, Cao jin
> wrote:
>>> According to objdump output of setup, function memset is not used in
>>> setup code. Currently, all usage of memset in setup come from mac
On December 30, 2018 11:21:07 PM PST, Nadav Amit wrote:
>It is sometimes beneficial to have a restartable sequence - very few
>instructions which if they are preempted jump to a predefined point.
>
>To provide such functionality on x86-64, we use an empty REX-prefix
>(opcode 0x40) as an indication
On October 10, 2018 1:17:17 PM PDT, Alan Cox wrote:
>On Tue, 9 Oct 2018 12:19:04 -0700
>"H. Peter Anvin" wrote:
>
>> [Resending to a wider audience]
>>
>> In trying to get the termios2 interface actually implemented in
>glibc,
>> the question came up if we will ever care about baud rates in exce
On November 7, 2018 1:43:39 PM PST, Logan Gunthorpe wrote:
>
>
>On 2018-11-07 11:56 a.m., Nadav Amit wrote:
>> HPA indicated more than once that this is wrong (and that was indeed
>my
>> initial solution), since it is not guaranteed that the compiler would
>put
>&
On October 11, 2018 5:31:34 AM PDT, Alan Cox wrote:
>> I'm mostly wondering if it is worth future-proofing for new
>transports. It sounds like we can have a consensus on leaving the upper
>4 bits of the speed fields reserved, but leave the details of
>implementation for the future?
>
>It seems rea
On October 4, 2018 1:33:33 AM PDT, Ingo Molnar wrote:
>
>* Ingo Molnar wrote:
>
>> I'm also somewhat annoyed at the fact that this series carries a
>boatload
>> of reviewed-by's and acked-by's, yet none of those reviewers found it
>> important to point out the large chasm that is gaping between
>
central file anyway that moves source
>code
>>> away
>>> from where it's used.
>>>
>>> Thanks,
>>>
>>> Ingo
>>
>> It's not just for working around a stupid GCC bug, but it also has a
>huge
>> potential
On October 4, 2018 2:12:22 AM PDT, Ingo Molnar wrote:
>
>* Nadav Amit wrote:
>
>> I can run some tests. (@hpa: I thought you asked about the -pipe
>overhead;
>> perhaps I misunderstood).
>
>Well, tests are unlikely to show the overhead of extra lines of thi
On October 23, 2018 7:53:51 AM PDT, Greg Kroah-Hartman
wrote:
>On Mon, Oct 22, 2018 at 09:19:04AM -0700, H. Peter Anvin (Intel) wrote:
>> From: "H. Peter Anvin"
>>
>> On architectures with CBAUDEX == 0 (Alpha and PowerPC), the code in
>tty_baudrate.c does
>> not do any limit checking on the tty
;t
>really
>> >> find anything so I just assume it's taking input from stdin? The
>issue
>> >> could stem from how GCC forks gas versus how Clang does it. If
>this
>> >> isn't of concern and the maintainers are happy with this patch as
>is,
&
> > >> The reason this patch is labeled RFC is while I can verify
>that this
>> > > > >> fixes the issue, I'm not entirely sure why the '-Wa,-' works
>for GCC
>> > > > >> and not Clang. I looked into what the flag means and I
On May 29, 2018 9:58:10 AM PDT, Prarit Bhargava wrote:
>
>
>On 05/29/2018 12:07 PM, Theodore Y. Ts'o wrote:
>> On Tue, May 29, 2018 at 11:01:07AM -0400, Prarit Bhargava wrote:
>>> Kees, in early boot no pool is available so the stack canary is
>initialized from
>>> the TSC. Later in boot, the sta
On June 6, 2018 2:17:42 AM PDT, "Leizhen (ThunderTown)"
wrote:
>I found that glibc has already dealt with this case. So this issue must
>have been met before, should it be maintained by libc/user?
>
> if (GLRO(dl_sysinfo_dso) == NULL)
> {
> kact.sa_flags |= SA_RESTORER;
On June 6, 2018 12:07:15 PM PDT, Brian Gerst wrote:
>On Wed, Jun 6, 2018 at 1:16 PM, Andy Lutomirski
>wrote:
>> On Wed, Jun 6, 2018 at 9:23 AM Chang S. Bae
> wrote:
>>>
>>> The new entry will be equivalent to that of x86-64 which
>>> stores CPU number. The entry is placed in segment 23 in GDT
>>>
On May 14, 2018 11:54:05 PM PDT, Ingo Molnar wrote:
>
>* h...@zytor.com wrote:
>
>> > I guess it won't try to speculatively execute the 'pad'
>instructions - but you
>> > can never really tell!
>> >
>> >David
>>
>> The CPU doesn't speculate down past an unconditional control
>transfer. Doin
On February 1, 2019 6:43:25 PM PST, Andy Lutomirski wrote:
>Hi hpa-
>
>A while back, you were working on some patches to make modify_ldt()
>play better with this series. What happened to them?
>
>--Andy
Looks like I need to dig them out...
--
Sent from my Android device wit
On February 5, 2019 2:46:11 PM PST, Randy Dunlap wrote:
>On 2/5/19 1:21 PM, Andrew Morton wrote:
>> On Fri, 1 Feb 2019 18:42:29 -0800 Andy Lutomirski
>wrote:
>>
>>> On Fri, Feb 1, 2019 at 12:54 PM Chang S. Bae
> wrote:
For testing (or root-only) purposes, the new flag will serve to tag
On January 24, 2019 12:59:29 PM PST, Joel Fernandes
wrote:
>On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote:
>>
>> On 1/23/19 11:37 PM, Daniel Colascione wrote:
>[..]
>> > > Personally I advocated a more aggressive approach with Joel in
>private:
>> > > just put the darn headers s
On January 25, 2019 11:15:52 AM PST, Daniel Colascione
wrote:
>On Fri, Jan 25, 2019 at 11:01 AM wrote:
>>
>> On January 24, 2019 12:59:29 PM PST, Joel Fernandes
> wrote:
>> >On Thu, Jan 24, 2019 at 07:57:26PM +0100, Karim Yaghmour wrote:
>> >>
>> >> On 1/23/19 11:37 PM, Daniel Colascione wrote:
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
> wrote
" 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 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 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, 202
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 assemb
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 0bdd
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 kill
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 `mul_u64_u64_shr'
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 `mul_u64_u64_shr'
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 due
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 emi
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 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 `mul_u64_u6
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,
>> > which
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 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, Ma
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, Ma
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
>> > UMIP-enable
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
>UMIP-en
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, an
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, f
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 d
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 that
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 t
On February 19, 2019 1:04:09 AM PST, Peter Zijlstra
wrote:
>On Mon, Feb 18, 2019 at 02:30:21PM -0800, H. Peter Anvin wrote:
>> On 2/16/19 2:30 AM, Peter Zijlstra wrote:
>> > On Fri, Feb 15, 2019 at 08:06:56PM -0800, h...@zytor.com wrote:
>> >> This implies we invoke schedule -- a restricted opera
On January 16, 2019 10:47:01 PM PST, Masami Hiramatsu
wrote:
>On Wed, 16 Jan 2019 16:32:43 -0800
>Rick Edgecombe wrote:
>
>> From: Nadav Amit
>>
>> text_mutex is currently expected to be held before text_poke() is
>> called, but we kgdb does not take the mutex, and instead *supposedly*
>> ensu
On January 17, 2019 1:43:54 PM PST, Nadav Amit wrote:
>> On Jan 17, 2019, at 12:47 PM, Andy Lutomirski
>wrote:
>>
>> On Thu, Jan 17, 2019 at 12:27 PM Andy Lutomirski
>wrote:
>>> On Wed, Jan 16, 2019 at 4:33 PM Rick Edgecombe
>>> wrote:
From: Nadav Amit
text_poke() can potentia
On January 17, 2019 2:39:15 PM PST, Nadav Amit wrote:
>> On Jan 17, 2019, at 1:15 PM, h...@zytor.com wrote:
>>
>> On January 16, 2019 10:47:01 PM PST, Masami Hiramatsu
> wrote:
>>> On Wed, 16 Jan 2019 16:32:43 -0800
>>> Rick Edgecombe wrote:
>>>
From: Nadav Amit
text_mutex is c
On January 11, 2019 11:34:34 AM PST, Linus Torvalds
wrote:
>On Fri, Jan 11, 2019 at 11:24 AM wrote:
>>
>> I still don't see why can't simply spin in the #BP handler until the
>patch is complete.
>
>So here's at least one problem:
>
>text_poke_bp()
> text_poke(addr, &int3, sizeof(int3));
> *in
On January 11, 2019 11:34:34 AM PST, Linus Torvalds
wrote:
>On Fri, Jan 11, 2019 at 11:24 AM wrote:
>>
>> I still don't see why can't simply spin in the #BP handler until the
>patch is complete.
>
>So here's at least one problem:
>
>text_poke_bp()
> text_poke(addr, &int3, sizeof(int3));
> *in
On January 14, 2019 3:27:55 PM PST, Andy Lutomirski wrote:
>On Mon, Jan 14, 2019 at 2:01 PM H. Peter Anvin wrote:
>>
>> So I was already in the middle of composing this message when Andy
>posted:
>>
>> > I don't even think this is sufficient. I think we also need
>everyone
>> > who clears the bi
On January 19, 2019 3:25:03 PM PST, Joel Fernandes
wrote:
>On Sat, Jan 19, 2019 at 12:43:35PM -0500, Daniel Colascione wrote:
>> On Sat, Jan 19, 2019 at 11:27 AM Joel Fernandes
> wrote:
>> >
>> > On Sat, Jan 19, 2019 at 09:25:32AM +0100, Greg KH wrote:
>> > > On Fri, Jan 18, 2019 at 05:55:43PM -0
On January 19, 2019 2:36:06 AM PST, Greg KH wrote:
>On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote:
>> This seems like a pretty horrible idea and waste of kernel memory.
>
>It's only a waste if you want it to be a waste, i.e. if you load the
>kernel module.
>
>This really isn't
On January 20, 2019 5:45:53 PM PST, Joel Fernandes
wrote:
>On Sun, Jan 20, 2019 at 01:58:15PM -0800, h...@zytor.com wrote:
>> On January 20, 2019 8:10:03 AM PST, Joel Fernandes
> wrote:
>> >On Sat, Jan 19, 2019 at 11:01:13PM -0800, h...@zytor.com wrote:
>> >> On January 19, 2019 2:36:06 AM PST, G
On January 20, 2019 8:10:03 AM PST, Joel Fernandes
wrote:
>On Sat, Jan 19, 2019 at 11:01:13PM -0800, h...@zytor.com wrote:
>> On January 19, 2019 2:36:06 AM PST, Greg KH
> wrote:
>> >On Sat, Jan 19, 2019 at 02:28:00AM -0800, Christoph Hellwig wrote:
>> >> This seems like a pretty horrible idea an
;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 de
1 - 100 of 281 matches
Mail list logo
