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
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 by
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
>---
> arch/x86/include/asm/asm.
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 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 thr
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 r
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 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 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 pl
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 setting
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 a
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;
>> >> > + * fallth
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 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 co
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 with
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 bo
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 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 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 rando
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 lega
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 February 22, 2019 2:26:35 PM PST, Peter Zijlstra
wrote:
>On Fri, Feb 22, 2019 at 07:10:34PM +0100, Thomas Gleixner wrote:
>
>> But correct :)
>
>> I agree, that a function which is doing the actual copy should be
>callable,
>> but random other functions? NO!
>
>So find the below patch -- which
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* happe
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* happe
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 d
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 the
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 February 14, 2019 2:14:29 AM PST, Peter Zijlstra
wrote:
>On Wed, Feb 13, 2019 at 02:49:47PM -0800, Andy Lutomirski wrote:
>
>> Do we need to backport this thing?
>
>Possibly, just to be safe.
>
>> The problem can’t be too widespread or we would have heard of it
>before.
>
>Yes, so far we've be
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: Thu,
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 featur
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 k
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 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, UACC
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, Pe
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"?
>> >
>> > __asan_{,un}poinson_s
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, the
On January 10, 2019 9:42:57 AM PST, Sean Christopherson
wrote:
>On Thu, Jan 10, 2019 at 12:32:43PM -0500, Steven Rostedt wrote:
>> On Thu, 10 Jan 2019 11:20:04 -0600
>> Josh Poimboeuf wrote:
>>
>>
>> > > While I can't find a reason for hypervisors to emulate this
>instruction,
>> > > smarter p
On January 10, 2019 5:34:21 PM PST, Sean Christopherson
wrote:
>On Thu, Jan 10, 2019 at 04:59:55PM -0800, h...@zytor.com wrote:
>> On January 10, 2019 9:42:57 AM PST, Sean Christopherson
> wrote:
>> >On Thu, Jan 10, 2019 at 12:32:43PM -0500, Steven Rostedt wrote:
>> >> On Thu, 10 Jan 2019 11:20:0
On January 11, 2019 11:03:30 AM PST, Linus Torvalds
wrote:
>On Fri, Jan 11, 2019 at 7:15 AM Josh Poimboeuf
>wrote:
>>
>> >
>> > Now, in the int3 handler can you take the faulting RIP and search
>for it in
>> > the “static-calls” table, writing the RIP+5 (offset) into R10
>(return
>> > address) a
On October 2, 2018 3:59:52 AM PDT, Ingo Molnar wrote:
>
>* Nadav Amit wrote:
>
>> at 1:58 AM, Rasmus Villemoes wrote:
>>
>> > On 2018-09-18 23:28, Nadav Amit wrote:
>> >
>> >> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>> >> index 8f6e7eb8ae9f..944fa3bc9376 100644
>> >> --- a/arch/x86/
On June 10, 2018 7:19:11 AM PDT, Nadav Amit wrote:
>Use assembly macros for jump-labels and call them from inline assembly.
>This not only makes the code more readable, but also improves
>compilation decision, specifically inline decisions which GCC base on
>the number of new lines in inline assem
On May 18, 2018 10:51:36 AM PDT, Alexey Dobriyan wrote:
>On Fri, May 18, 2018 at 09:18:14AM +0200, Ingo Molnar wrote:
>> The concept of built-in kernel tooling working at the machine code
>level is just
>> so powerful - we should have added our own KCC compiler 20 years ago.
>
>...for two very se
On May 7, 2018 2:37:55 PM PDT, Alexey Dobriyan wrote:
>Use INT3 instead of NOP. All that padding between functions is
>an illegal area, no legitimate code should jump into it.
>
>I've checked x86_64 allyesconfig disassembly, all changes looks sane:
>INT3 is only used after RET or unconditional JMP
On January 31, 2017 10:52:11 AM PST, Nicolas Iooss
wrote:
>Hello,
>
>As I have not received any comment on the patch I sent in December, I
>am
>wondering whether I did anything wrong with it. How can I get it queued
>for the next merge window?
>
>Thanks,
>Nicolas
>
>On 18/12/16 20:47, Nicolas Ioo
On February 1, 2017 11:16:00 PM PST, Ingo Molnar wrote:
>
>* Nicolas Iooss wrote:
>
>> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains:
>>
>> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument
>of
>> type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long
>> uns
On January 9, 2017 12:32:23 AM PST, Roman Kagan wrote:
>On Mon, Jan 02, 2017 at 09:19:57AM +0100, Paolo Bonzini wrote:
>> On 28/12/2016 18:09, Roman Kagan wrote:
>> > Am I correct assuming that QEMU is currently the only user of
>> > arch/x86/include/uapi/asm/hyperv.h?
>> >
>> > Then I think we'r
On January 9, 2017 2:16:07 PM PST, tip-bot for Borislav Petkov
wrote:
>Commit-ID: 5dedade6dfa243c130b85d1e4daba6f027805033
>Gitweb:
>http://git.kernel.org/tip/5dedade6dfa243c130b85d1e4daba6f027805033
>Author: Borislav Petkov
>AuthorDate: Mon, 9 Jan 2017 12:41:43 +0100
>Committer: Thoma
On January 10, 2017 1:04:15 AM PST, Borislav Petkov wrote:
>On Mon, Jan 09, 2017 at 04:19:29PM -0800, h...@zytor.com wrote:
>> Any reason to not make these interfaces (leaf, subleaf) from the
>start?
>
>Two, actually:
>
>1. I modelled them after the cpuid_(op) versions
You are introducing a new A
On November 17, 2016 1:02:48 PM PST, Josh Poimboeuf wrote:
>On Wed, Nov 16, 2016 at 03:17:09PM +0100, Arnd Bergmann wrote:
>> The latest binutils are warning about a .fill directive with an
>explicit
>> value in a .bss section:
>>
>> arch/x86/kernel/head_32.S: Assembler messages:
>> arch/x86/kern
) \
>+ $(call cc-option,-mtune=bonnell,$(call cc-option,-mtune=generic))
>
> # AMD Elan support
> cflags-$(CONFIG_MELAN)+= -march=i486
This just breaks backwards compatibility with older gcc. If you want to add a
comment that's fine, though.
Nacked-by: hpa
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf
wrote:
>On 2016.12.20 at 03:10 -0800, H. Peter Anvin wrote:
>> On 12/20/16 02:00, Markus Trippelsdorf wrote:
>> > On 2016.12.20 at 01:30 -0800, H. Peter Anvin wrote:
>> >> I'd strongly prefer a non-data-dependent solution, specifically
>add
On January 2, 2017 8:52:41 AM PST, Andy Lutomirski wrote:
>On Mon, Jan 2, 2017 at 1:49 AM, Kirill A. Shutemov
> wrote:
>> On Fri, Dec 30, 2016 at 06:11:05PM -0800, Andy Lutomirski wrote:
>>> On Fri, Dec 30, 2016 at 7:56 AM, Dmitry Safonov
> wrote:
>>> > Keep task's virtual address space size as mm
On December 14, 2016 12:36:58 AM PST, tip-bot for Josh Poimboeuf
wrote:
>Commit-ID: ec2d86a9b646d93f1948569f368e2c6f5449e6c7
>Gitweb:
>http://git.kernel.org/tip/ec2d86a9b646d93f1948569f368e2c6f5449e6c7
>Author: Josh Poimboeuf
>AuthorDate: Tue, 13 Dec 2016 21:25:35 -0600
>Committer: Ing
On December 2, 2016 8:08:55 AM PST, Ingo Molnar wrote:
>
>* Boris Ostrovsky wrote:
>
>> On 12/02/2016 04:45 AM, Ingo Molnar wrote:
>> > * Boris Ostrovsky wrote:
>> >
>> >> On 10/31/2016 08:33 AM, Boris Ostrovsky wrote:
>> >>>
>> >>> On 10/14/2016 02:05 PM, Boris Ostrovsky wrote:
>> From: Ma
On December 2, 2016 9:49:50 PM PST, Ingo Molnar wrote:
>
>* Boris Ostrovsky wrote:
>
>> > It is tricky to do so safely, because at this stage almost nothing
>of the C
>> > execution environment has been set up.
>
>Yeah - but we do have a fair amount of early C code though.
>
>> I can still give
On December 15, 2016 6:39:44 AM PST, Borislav Petkov wrote:
>On Wed, Dec 14, 2016 at 12:07:54AM +0100, Boris Petkov wrote:
>> Thus I was thinking of adding a build-time check for the gcc version
>> but that might turn out to be more code in the end than those ugly
>> ifnc clauses.
>
>IOW, somethin
On December 15, 2016 11:20:17 AM PST, Andi Kleen wrote:
>
>The code is not calling CPUID in any performance critical path, only
>at initialization. So any discussion about saving a few instructions
>is a complete waste of time.
>
>-Andi
Sort of. The BIOS boot code is very space-constrained for c
On December 15, 2016 11:20:17 AM PST, Andi Kleen wrote:
>
>The code is not calling CPUID in any performance critical path, only
>at initialization. So any discussion about saving a few instructions
>is a complete waste of time.
>
>-Andi
NB: the chief offender is Loadlin, which is still used in so
On November 19, 2016 5:52:57 PM PST, Andy Lutomirski wrote:
>This is a question for the old-timers here, since I can't find
>anything resembling an answer in the SDM.
>
>Suppose an exception happens (#UD in this case, but I assume it
>doesn't really matter). We're not in long mode, and the IDT is
On November 21, 2016 1:21:35 PM PST, Linus Torvalds
wrote:
>On Mon, Nov 21, 2016 at 10:26 AM, H. Peter Anvin wrote:
>> On 11/21/16 10:00, Linus Torvalds wrote:
>>>
>>> I'd much rather we go back to just making the "cs" entry explicitly
>>> 16-bit, and have a separate padding entry, the way we us
On December 8, 2016 10:16:07 AM PST, Linus Torvalds
wrote:
>On Thu, Dec 8, 2016 at 8:21 AM, Kirill A. Shutemov
> wrote:
>>
>> This patchset is still very early. There are a number of things
>missing
>> that we have to do before asking anyone to merge it (listed below).
>> It would be great if fol
On March 21, 2017 9:37:12 AM PDT, Dmitry Safonov wrote:
>After my changes to mmap(), its code now relies on the bitness of
>performing syscall. According to that, it chooses the base of
>allocation:
>mmap_base for 64-bit mmap() and mmap_compat_base for 32-bit syscall.
>It was done by:
> commit 1b
On March 21, 2017 11:40:58 AM PDT, Cyrill Gorcunov wrote:
>On Tue, Mar 21, 2017 at 09:09:40PM +0300, Dmitry Safonov wrote:
>>
>> I guess the question comes from that we're releasing CRIU 3.0 with
>> 32-bit C/R and some other cool stuff, but we don't support x32 yet.
>> As we don't want release a
On March 21, 2017 10:45:57 AM PDT, Andy Lutomirski wrote:
>On Tue, Mar 21, 2017 at 10:17 AM, Cyrill Gorcunov
>wrote:
>> On Tue, Mar 21, 2017 at 07:37:12PM +0300, Dmitry Safonov wrote:
>> ...
>>> diff --git a/arch/x86/kernel/process_64.c
>b/arch/x86/kernel/process_64.c
>>> index d6b784a5520d..d3d4
On March 21, 2017 12:07:13 PM PDT, Cyrill Gorcunov wrote:
>On Tue, Mar 21, 2017 at 11:51:09AM -0700, h...@zytor.com wrote:
>> >
>> >indeed, thanks!
>>
>> I proposed to the ptrace people a virtual register for this and a few
>other things, but it got bikeshed to death.
>
>Any mail reference left?
On March 21, 2017 2:16:48 PM PDT, Adam Borowski wrote:
>On Tue, Mar 21, 2017 at 08:47:11PM +0300, Dmitry Safonov wrote:
>> After my changes to mmap(), its code now relies on the bitness of
>> performing syscall. According to that, it chooses the base of
>allocation:
>> mmap_base for 64-bit mmap()
On March 21, 2017 3:21:13 PM PDT, Thomas Gleixner wrote:
>On Tue, 21 Mar 2017, Dmitry Safonov wrote:
>> v3:
>> - clear x32 syscall flag during x32 -> x86-64 exec() (thanks, HPA).
>
>For correctness sake, this wants to be cleared in the IA32 path as
>well. It&
On March 17, 2017 12:27:46 PM PDT, Peter Zijlstra wrote:
>On Fri, Mar 17, 2017 at 11:52:01AM -0700, Michael Davidson wrote:
>> On Fri, Mar 17, 2017 at 5:44 AM, Peter Zijlstra
> wrote:
>> >
>> > Be that as it may; what you construct above is disgusting. Surely
>the
>> > code can be refactored to no
On March 16, 2017 5:15:16 PM PDT, Michael Davidson wrote:
>Suppress clang warnings about potential unaliged accesses
>to members in packed structs. This gets rid of almost 10,000
>warnings about accesses to the ring 0 stack pointer in the TSS.
>
>Signed-off-by: Michael Davidson
>---
> arch/x86/Ma
On March 19, 2017 1:26:58 AM PDT, "Kirill A. Shutemov"
wrote:
>On Mar 19, 2017 09:25, "Aneesh Kumar K.V"
>
>wrote:
>
>"Kirill A. Shutemov" writes:
>
>> On Fri, Mar 17, 2017 at 11:23:54PM +0530, Aneesh Kumar K.V wrote:
>>> "Kirill A. Shutemov" writes:
>>>
>>> > On x86, 5-level paging enables 56-
On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote:
>
>* Thomas Gleixner wrote:
>
>> On Wed, 1 Mar 2017, Ingo Molnar wrote:
>> >
>> > * Jiri Slaby wrote:
>> >
>> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL,
>END,
>> > > and other macros across x86. When we have all thi
On March 1, 2017 2:27:54 AM PST, Ingo Molnar wrote:
>
>* Thomas Gleixner wrote:
>
>> On Wed, 1 Mar 2017, Ingo Molnar wrote:
>> >
>> > * Jiri Slaby wrote:
>> >
>> > > This is a start of series to unify use of ENTRY, ENDPROC, GLOBAL,
>END,
>> > > and other macros across x86. When we have all thi
On March 4, 2017 3:46:44 PM PST, Logan Gunthorpe wrote:
>Hi Borislav,
>
>Thanks for the help.
>
>On 04/03/17 03:43 PM, Borislav Petkov wrote:
>> You can boot with "debug-alternative" and look for those strings
>where
>
>Here's the symbols for memcpy and the corresponding apply_alternatives
>lines:
On March 4, 2017 4:14:47 PM PST, Borislav Petkov wrote:
>On Sat, Mar 04, 2017 at 03:55:27PM -0800, h...@zytor.com wrote:
>> For newer processors, as determined by -mtune=, it is actually the
>> best option for an arbitrary copy.
>
>So his doesn't have ERMS - it is a SNB - so if for SNB REP_GOOD is
On March 4, 2017 4:33:49 PM PST, Borislav Petkov wrote:
>On Sat, Mar 04, 2017 at 04:23:17PM -0800, h...@zytor.com wrote:
>> What are the compilation flags? It may be that gcc still does TRT
>> depending on this call site. I'd check what gcc6 or 7 generates,
>> though.
>
>Well, I don't think that m
On March 6, 2017 5:33:28 AM PST, Borislav Petkov wrote:
>On Mon, Mar 06, 2017 at 12:01:10AM -0700, Logan Gunthorpe wrote:
>> Well honestly my issue was solved by fixing my kernel config. I have
>no
>> idea why I had optimize for size in there in the first place.
>
>I still think that we should add
On March 6, 2017 9:12:41 AM PST, Logan Gunthorpe wrote:
>
>
>On 06/03/17 12:28 AM, H. Peter Anvin wrote:
>> On 03/05/17 23:01, Logan Gunthorpe wrote:
>>>
>>> On 05/03/17 12:54 PM, Borislav Petkov wrote:
Logan, wanna give that a try, see if it takes care of your issue?
>>>
>>> Well honestly my
On March 1, 2017 12:10:59 AM PST, tip-bot for Josh Poimboeuf
wrote:
>Commit-ID: 90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
>Gitweb:
>http://git.kernel.org/tip/90a7e63a31b8f7d630d12ef0d8d37d3ab87f76e5
>Author: Josh Poimboeuf
>AuthorDate: Wed, 1 Mar 2017 00:05:04 -0600
>Committer: Ingo Mol
On March 1, 2017 7:20:03 AM PST, Josh Poimboeuf wrote:
>The __unreachable section is only used at compile time. It's discarded
>for vmlinux but it should also be discarded for modules.
>
>Fixes: d1091c7fa3d5 ("objtool: Improve detection of BUG() and other
>dead ends")
>Signed-off-by: Josh Poimboe
On March 1, 2017 9:01:54 AM PST, Linus Torvalds
wrote:
>On Wed, Mar 1, 2017 at 8:44 AM, wrote:
>>
>> I would like to see a name like, say, ".annot.unreachable", since is
>odds are pretty high we are going to need more annotations in the
>future.
>
>Why not just make it ".discard.unreachable", a
On March 1, 2017 4:18:54 PM PST, "Dmitry V. Levin" wrote:
>Replace size_t to fix the following asm/signal.h userspace compilation
>error:
>
>/usr/include/asm/signal.h:126:2: error: unknown type name 'size_t'
> size_t ss_size;
>
>size_t is replaced with __kernel_size_t in all cases except x32 wher
186,UNDOC,ND
>1381 UD2 void[ 0f 0b]
> 186
>1382 UD2Avoid[ 0f 0b]
> 186,ND
>
>which seems to use the 2 byte
On February 23, 2017 7:23:09 AM PST, Peter Zijlstra
wrote:
>On Thu, Feb 23, 2017 at 07:09:05AM -0800, h...@zytor.com wrote:
>> Well, it only matters if the instruction extends past a segment
>> boundary or page. However, the CPU instruction decoder will consume
>a
>> modrm for UD1, and so using
On February 24, 2017 12:31:15 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote:
>> The only high level question is whether we trust the trap machinery
>to generate
>> WARN_ON()s. I believe we do.
>>
>> BTW.: why not use INT3 instead of all these weird #
On February 24, 2017 12:31:15 AM PST, Peter Zijlstra
wrote:
>On Fri, Feb 24, 2017 at 08:43:25AM +0100, Ingo Molnar wrote:
>> The only high level question is whether we trust the trap machinery
>to generate
>> WARN_ON()s. I believe we do.
>>
>> BTW.: why not use INT3 instead of all these weird #
On February 15, 2017 6:41:56 AM PST, Chao Peng
wrote:
>Multiboot specification
>(http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multiboot2)
>is an open standard that provides kernels with a uniform way to be
>booted
>by multiboot-compliant bootloaders (like grub).
>
>This pat
On February 15, 2017 12:13:36 PM PST, "Luis R. Rodriguez"
wrote:
>On Wed, Feb 15, 2017 at 10:12:07AM -0800, h...@zytor.com wrote:
>> On February 15, 2017 6:41:56 AM PST, Chao Peng
> wrote:
>> >Multiboot specification
>>
>>(http://git.savannah.gnu.org/cgit/grub.git/tree/doc/multiboot.texi?h=multib
On February 13, 2017 2:53:43 AM PST, Peter Zijlstra
wrote:
>On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>> That way we'd end up with something like:
>>
>> asm("
>> push %rdi;
>> movslq %edi, %rdi;
>> movq __per_cpu_offset(,%rdi,8), %rax;
>> cmpb $0, %[offset](%rax);
>> setne
On February 13, 2017 1:52:20 PM PST, Peter Zijlstra
wrote:
>On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
>> On 02/13/2017 02:42 PM, Waiman Long wrote:
>> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
>> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>> >>> Th
On February 13, 2017 1:52:20 PM PST, Peter Zijlstra
wrote:
>On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
>> On 02/13/2017 02:42 PM, Waiman Long wrote:
>> > On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
>> >> On Mon, Feb 13, 2017 at 11:47:16AM +0100, Peter Zijlstra wrote:
>> >>> Th
On February 13, 2017 11:06:04 AM PST, Andy Lutomirski
wrote:
>On Mon, Feb 13, 2017 at 2:13 AM, Dmitry Safonov
> wrote:
>> Kernel erases R8..R11 registers prior returning to userspace
>> from int80: https://lkml.org/lkml/2009/10/1/164
>>
>> GCC can reuse this registers and doesn't expect them to c
On February 13, 2017 2:34:01 PM PST, Waiman Long wrote:
>On 02/13/2017 04:52 PM, Peter Zijlstra wrote:
>> On Mon, Feb 13, 2017 at 03:12:45PM -0500, Waiman Long wrote:
>>> On 02/13/2017 02:42 PM, Waiman Long wrote:
On 02/13/2017 05:53 AM, Peter Zijlstra wrote:
> On Mon, Feb 13, 2017 at 11:
On February 17, 2017 1:10:27 PM PST, Linus Torvalds
wrote:
>On Fri, Feb 17, 2017 at 1:04 PM, Dave Hansen
>wrote:
>>
>> Is this likely to break anything in practice? Nah. But it would
>nice
>> to avoid it.
>
>So I go the other way: what *I* would like to avoid is odd code that
>is hard to follo
On February 17, 2017 3:02:33 PM PST, Andy Lutomirski
wrote:
>On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
> wrote:
>> On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski
> wrote:
>>>
>>> At the very least, I'd want to see
>>> MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING. I *hate* the current
>>> in
On February 20, 2017 2:02:53 PM PST, Paolo Bonzini wrote:
>
>> > Yes. But 150-200 clock cycles are nothing compared to the cache
>misses
>> > you get from preemption, so I'd ignore that. Saving 300 clock
>cycles on
>> > userspace exits from TR+GSBASE would be about 5% on my Haswell.
>>
>> That'
On February 25, 2017 2:38:08 AM PST, Borislav Petkov wrote:
>On Fri, Feb 24, 2017 at 11:41:33AM +0100, Peter Zijlstra wrote:
>> So yes, its tricky but it could be done. A new single byte #UD
>> instruction would be much nicer though.
>
>Btw, if we did a new insn which means new functionality inste
On February 25, 2017 11:38:44 AM PST, Borislav Petkov wrote:
>On Sat, Feb 25, 2017 at 09:55:45AM -0800, h...@zytor.com wrote:
>> You mean like the INT instruction?
>
>Right, you mentioned reusing INT $9 upthread.
>
>That doesn't have the additional info in the immed8 - it is the vector
>in this ca
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 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 locati
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. Fo
101 - 200 of 281 matches
Mail list logo
