* Matteo Rizzo wrote:
> On Fri, 15 Sept 2023 at 18:30, Lameter, Christopher
> wrote:
> >
> > On Fri, 15 Sep 2023, Dave Hansen wrote:
> >
> > > What's the cost?
> >
> > The only thing that I see is 1-2% on kernel compilations (and "more on
> > machines with lots of cores")?
>
> I used kernel c
* Matteo Rizzo wrote:
> On Mon, 18 Sept 2023 at 19:39, Ingo Molnar wrote:
> >
> > What's the split of the increase in overhead due to SLAB_VIRTUAL=y, between
> > user-space execution and kernel-space execution?
> >
>
> Same benchmark as before (comp
* Federico Vaga wrote:
> On Saturday, August 31, 2019 4:43:44 PM CEST Jonathan Corbet wrote:
> > On Sat, 31 Aug 2019 15:41:16 +0200
> >
> > Federico Vaga wrote:
> > > several CPU's and you want to use spinlocks you can potentially use
> > >
> > > -cheaper versions of the spinlocks. IFF you
* Thomas Gleixner wrote:
> On Sun, 8 Sep 2019, Matthew Wilcox wrote:
> > On Sat, Sep 07, 2019 at 11:17:22PM +0200, Thomas Gleixner wrote:
> > > On Sat, 7 Sep 2019, Markus Heiser wrote:
> > > > Am 07.09.19 um 20:04 schrieb Mauro Carvalho Chehab:
> > > > > No idea. I would actually prefer to just
* Cao jin wrote:
> The fields marked with (reloc) actually are not dedicated for writing,
> but communicating info for relocatable kernel with boot loaders. For
> example:
>
>
> Field name: pref_address
> Type: read (reloc)
> Offset/size
* Hans de Goede wrote:
> Hi All,
>
> Here is v7 of my patch-set to add support for EFI embedded fw to the kernel.
>
> v6 was posted a long time ago, around the 4.18 days. The long wait was for
> a suitable secure-hash for checking the firmware we find embedded in the EFI
> is the one we expec
* Hans de Goede wrote:
> > So I was looking for a high level 0/ boilerplate description of this
> > series, to explain what "EFI embedded fw" is, what problems it solves and
> > how it helps the kernel in general - and found this in 2/8:
>
> Sorry you had to dig into the individual patch chang
please see 'nowatchdog'.
> This is useful when you use a panic=... timeout and
> need the box quickly up again.
Acked-by: Ingo Molnar
Thanks,
Ingo
* Lu Baolu wrote:
> Add Documentation/usb/usb3-debug-port.rst. This document includes
> the user guide for USB3 debug port.
>
> Cc: linux-doc@vger.kernel.org
> Signed-off-by: Lu Baolu
> ---
> Documentation/usb/usb3-debug-port.rst | 95
> +++
> 1 file changed,
arch/s390/Kconfig | 5 ++---
> arch/s390/Kconfig.debug| 3 ---
> arch/x86/Kconfig | 5 ++---
> arch/x86/Kconfig.debug | 11 --
> 13 files changed, 51 insertions(+), 68 deletions(-)
Acked-by: Ingo Mol
* Kees Cook wrote:
> On Thu, Feb 16, 2017 at 2:25 PM, Pavel Machek wrote:
> > Hi!
> >
> >>
> >> -config DEBUG_RODATA
> >> +config STRICT_KERNEL_RWX
> >> bool "Make kernel text and rodata read-only" if
> >> ARCH_OPTIONAL_KERNEL_RWX
> >> depends on ARCH_HAS_STRICT_KERNEL_RWX
> >>
* Thomas Garnier wrote:
> This patch aligns MODULES_END to the beginning of the Fixmap section.
> It optimizes the space available for both sections. The address is
> pre-computed based on the number of pages required by the Fixmap
> section.
>
> It will allow GDT remapping in the Fixmap sectio
* Masami Hiramatsu wrote:
> @@ -1824,6 +1823,30 @@ void unregister_jprobes(struct jprobe **jps, int num)
> EXPORT_SYMBOL_GPL(unregister_jprobes);
>
> #ifdef CONFIG_KRETPROBES
> +
> +/* Try to use free instance first, if failed, try to allocate new instance */
> +struct kretprobe_instance *kr
* Masami Hiramatsu wrote:
> > So this is something I missed while the original code was merged, but the
> > concept
> > looks a bit weird: why do we do any "allocation" while a handler is
> > executing?
> >
> > That's fundamentally fragile. What's the maximum number of parallel
> > 'kretpro
* Masami Hiramatsu wrote:
> On Thu, 30 Mar 2017 08:53:32 +0200
> Ingo Molnar wrote:
>
> >
> > * Masami Hiramatsu wrote:
> >
> > > > So this is something I missed while the original code was merged, but
> > > > the concept
> > >
only user arch/x86/Makefile_32.cpu and deprecate the
> cc-option-align.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> x86 maintainers,
>
> If this patch looks OK, could you give me Acked-by?
LGTM in principle, although I haven't tested it:
Acked-by: Ingo Molnar
Th
* Tom Lendacky wrote:
> This patch series provides support for AMD's new Secure Memory Encryption
> (SME)
> feature.
I'm wondering, what's the typical performance hit to DRAM access latency when
SME
is enabled?
On that same note, if the performance hit is noticeable I'd expect SME to not
b
* Tom Lendacky wrote:
> Create a new function attribute, __nostackp, that can used to turn off
> stack protection on a per function basis.
>
> Signed-off-by: Tom Lendacky
> ---
> include/linux/compiler-gcc.h | 2 ++
> include/linux/compiler.h | 4
> 2 files changed, 6 insertions(+)
>
* Prarit Bhargava wrote:
> The SPCR (Serial Port Console Redirection) Table provides information
> about the configuration of serial port. This information can be used
> to configure the early console.
s/about the configuration of serial port
/about the configuration of the serial port
> SPC
* Prarit Bhargava wrote:
> If I disable "Serial Port Console Debug" in my BIOS I still see the SPCR
> configured:
>
> [root@prarit-lab ~]# dmesg | grep SPCR
> [0.00] ACPI: SPCR 0x69031000 50 (v01
> )
>
> AFAICT the SPCR is always enabled on some syste
Bhupesh Sharma
> Cc: Lv Zheng
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H. Peter Anvin"
> Cc: x...@kernel.org
> Cc: Jonathan Corbet
> Cc: Catalin Marinas
> Cc: Will Deacon
> Cc: "Rafael J. Wysocki"
> Cc: Timur Tab
hargava
> Cc: linux-a...@vger.kernel.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux...@vger.kernel.org
> Cc: linux-ser...@vger.kernel.org
> Cc: Bhupesh Sharma
> Cc: Lv Zheng
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> C
(-)
> create mode 100644 tools/testing/selftests/vm/pkey-helpers.h
> create mode 100644 tools/testing/selftests/vm/protection_keys.c
> delete mode 100644 tools/testing/selftests/x86/pkey-helpers.h
> delete mode 100644 tools/testing/selftests/x86/protection_keys.c
Acked-by: Ingo Molnar
* Prarit Bhargava wrote:
> Commit bbb65d2d365e ("x86: use cpuid vector 0xb when available for
> detecting cpu topology") changed the value of smp_num_siblings from the
> active number of threads in a core to the maximum number threads in a
> core. e.g.) On Intel Haswell and newer systems smp_nu
* Andrea Parri wrote:
> Hi all,
>
> The directory (not yet three years old although, I freely admit, I've
> only recently become aware of it) provides arch. support matrices for
> more than 40 generic kernel features that need per-arch. support:
>
> This is a superb project! ;-) and not a sim
* Andrea Parri wrote:
> In Ingo's words [1]:
>
> "[...] what should be done instead is to write a script that refreshes
>all the arch-support.txt files in-place. [...]
>
>It's OK for the script to have various quirks for weirdly implemented
>features and exceptions: i.e. basical
* Andrea Parri wrote:
> On Wed, Apr 04, 2018 at 06:56:32AM +0200, Ingo Molnar wrote:
> >
> > * Andrea Parri wrote:
> >
> > > In Ingo's words [1]:
> > >
> > > "[...] what should be done instead is to write a script that
resh the
kernel features support matrix list:
- The new 'csky' architecture was added
- s390now supports KASAN
- powerpc now supports stackprotector
- xtensa now supports sg-chain
- arm64 now supports queued-spinlocks
- parisc now supports kprobes-events
- RISC-V now supp
* Yu-cheng Yu wrote:
> +X86 Documentation
> +===
> +
> +Control-flow Enforcement
> +
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + intel_cet
> diff --git a/Documentation/x86/intel_cet.rst b/Documentation/x86/intel_cet.rst
> new file mode 100644
> i
* Yu-cheng Yu wrote:
> On Tue, 2018-11-20 at 10:52 +0100, Ingo Molnar wrote:
> > * Yu-cheng Yu wrote:
> >
> > > +X86 Documentation
> > > [...]
> > > +
> > > +At run time, /proc/cpuinfo shows the availability of SHSTK and IBT.
> >
&g
* Moger, Babu wrote:
> New generation of AMD processors start supporting RDT(or QOS)
> features. Together these features will be called as RESCTRL.
> With more than one vendors supporting these features, it seems
> more appropriate to rename these files.
>
> Create a new directory with the nam
* Borislav Petkov wrote:
> On Fri, Nov 23, 2018 at 08:28:39AM +0100, Ingo Molnar wrote:
> > Ugh, violent NAK on this unreadable directory naming: 'resctrl' is an
> > ugly double/triple abbreviation that nobody recognizes for what it is to
> > begin with, a
* Borislav Petkov wrote:
> On Fri, Nov 23, 2018 at 09:41:17AM +0100, Ingo Molnar wrote:
> > Then at least make the directory name resource_control/, which is only
> > marginally longer and a lot more readable.
> >
> > We really don't have to fit directly name
r ]
triton:~/tip> taskset 1 perf stat --null --pre "sync" --repeat 10 make
kernel/sched/ >/dev/null
Performance counter stats for 'make kernel/sched/' (10 runs):
0.148483807 seconds time elapsed
( +- 0.57% )
A 300% s
* Quan Xu wrote:
> From: Quan Xu
>
> To reduce the cost of poll, we introduce three sysctl to control the
> poll time when running as a virtual machine with paravirt.
>
> Signed-off-by: Yang Zhang
> Signed-off-by: Quan Xu
> ---
> Documentation/sysctl/kernel.txt | 35 +
* Quan Xu wrote:
>
>
> On 2017/11/13 23:08, Ingo Molnar wrote:
> > * Quan Xu wrote:
> >
> > > From: Quan Xu
> > >
> > > To reduce the cost of poll, we introduce three sysctl to control the
> > > poll time when running as a virtua
* Peter Zijlstra wrote:
> On Tue, Nov 14, 2017 at 12:19:26PM +0100, Claudio Scordino wrote:
> > Signed-off-by: Claudio Scordino
> > Signed-off-by: Luca Abeni
> > Acked-by: Daniel Bristot de Oliveira
> > CC: Jonathan Corbet
> > CC: "Peter Zijlstra (Intel
in place; previous discussions about this series are at [1].
>
> Looks good, I've applied the set, thanks.
A belated:
Reviewed-by: Ingo Molnar
Thanks guys!
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message
* Baoquan He wrote:
> In Documentation/x86/x86_64/mm.txt, the style of descritions about
> memory region layout is a little confusing:
>
> - mix size in TB with 'bits'
> - sometimes mention a size in the description and sometimes not
> - sometimes list holes by address, sometimes only as an
* Baoquan He wrote:
> Currently CONFIG_RANDOMIZE_BASE=y is default set, update the relevant
> document about KERNEL_IMAGE_SIZE.
Suggested wording:
x86/KASLR: Update KERNEL_IMAGE_SIZE description
Currently CONFIG_RANDOMIZE_BASE=y is set by default, which makes some of the
old comments
* Baoquan He wrote:
> This clean up is suggested by Ingo.
>
> It firstly fix the confusions in mm layout tables by unifying
> each memory region description in the consistent style.
>
> Secondly take the KASLR words out of the mm layout tables to make
> it as a separate section to only list m
Thomas Gleixner
Cc: cor...@lwn.net
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: thgar...@google.com
Signed-off-by: Ingo Molnar
---
Documentation/x86/x86_64/mm.txt | 172
kernel/sched/core.c |6 +
2 files changed
* Ingo Molnar wrote:
> +
> +| Complete virtual memory map with 4-level page tables |
> +
> +-
sen
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: cor...@lwn.net
Cc: linux-doc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: thgar...@google.com
Signed-off-by: Ingo Molnar
---
Documentation/x86/x86_64/mm.txt |
There's one PTI related layout asymmetry I noticed between 4-level and 5-level
kernels:
47-bit:
> +|
> +| Kernel-space
> virtual memory, shared between all processes:
> +__
* Juergen Gross wrote:
> In the non-EFI boot path the ACPI RSDP table is currently found via
> either EBDA or by searching through low memory for the RSDP magic.
> This requires the RSDP to be located in the first 1MB of physical
> memory. Xen PVH guests, however, get the RSDP address via the s
* Juergen Gross wrote:
> You can just dive into the discussion we had back in February:
That was half a year and a thousand commits ago! ;-)
> https://lore.kernel.org/lkml/20180213163244.j2zuxyhs4kbfh...@gmail.com/
>
> The scheme I have used in V5 of the series is the one you agreed to use
>
* Ahmed Abd El Mawgood wrote:
> This is the 5th version which is 4th version with minor fixes. ROE is a
> hypercall that enables host operating system to restrict guest's access to its
> own memory. This will provide a hardening mechanism that can be used to stop
> rootkits from manipulating k
* Bryan O'Donoghue wrote:
> Currently when setting up an IMR around the kernel's .text area we lock
> that IMR, preventing further modification. While superficially this appears
> to be the right thing to do, in fact this doesn't account for a legitimate
> change in the memory map such as when e
* Bryan O'Donoghue wrote:
> On Thu, 2016-02-18 at 08:58 +0100, Ingo Molnar wrote:
> > So why not simply do the patch below? Very few people use boot
> > parameters, and the
> > complexity does not seem to be worth it.
> >
> > Furthermore I think an IMR
* Luis R. Rodriguez wrote:
> The current documentation refers to using set_memory_wc() as a
> possible hole strategy when you have overlapping ioremap() regions,
The whole explanation should talk about virtual aliases over the same physical
address, not some 'overlapping regions'.
I see where
* Chris Metcalf wrote:
> On 03/03/2016 01:34 PM, Andi Kleen wrote:
> >Chris Metcalf writes:
> >>+config TASK_ISOLATION_ALL
> >>+ bool "Provide task isolation on all CPUs by default (except CPU 0)"
> >>+ depends on TASK_ISOLATION
> >>+ help
> >>+If the user doesn't pass the task_isolat
* Kees Cook wrote:
> On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds
> wrote:
> > On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek wrote:
> >>
> >> Why is kASLR incompatible with hibernation? We can hibernate have
> >> 4.3 kernel resume hibernation image of 4.2 kernel (on x86-64, and I
> >> have pa
* Ingo Molnar wrote:
>
> * Kees Cook wrote:
>
> > On Wed, Apr 6, 2016 at 1:56 PM, Linus Torvalds
> > wrote:
> > > On Wed, Apr 6, 2016 at 1:17 PM, Pavel Machek wrote:
> > >>
> > >> Why is kASLR incompatible with hibernation? We can hib
* Rafael J. Wysocki wrote:
> On Wed, Apr 6, 2016 at 9:44 PM, Kees Cook wrote:
> > When building with both CONFIG_HIBERNATION and CONFIG_RANDOMIZE_BASE,
> > one or the other must be chosen at boot-time. Until now, hibernation
> > was selected when no choice was made on the command line.
> >
> >
* Kees Cook wrote:
> >> I don't think this is a good idea, as it turns off emergency hibernation
> >> of
> >> laptops - many desktop distros support it by default.
> >
> > Right, I forgot about this one.
>
> When I last checked Ubuntu doesn't enable hibernation by default any more:
> https:/
* Rafael J. Wysocki wrote:
> [...]
>
> One of the weak points is the final jump, because it has to be done to the
> physical location of the image kernel's entry point even though the virtual
> addresses of it may differ between the boot and the image kernels. The seed
> is
> not needed fo
* Kees Cook wrote:
> 1) The x86 hibernation and KASLR code don't play well together currently.
Please fix it, don't just work it around ...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More m
* Andy Lutomirski wrote:
> > What new syscalls would be needed for ssh to get all this support?
>
> This patchset or similar, plus some user code and an enclave to use.
>
> Sadly, on current CPUs, you also need Intel to bless the enclave. It looks
> like
> new CPUs might relax that requirem
* Paul E. McKenney wrote:
> Nothing in the control-dependencies section of memory-barriers.txt
> says that control dependencies don't extend beyond the end of the
> if-statement containing the control dependency. Worse yet, in many
> situations, they do extend beyond that if-statement. In part
* Thomas Garnier wrote:
> arch/x86/include/asm/kaslr.h| 12 +++
Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or in
the
x86 tree.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to
* Ingo Molnar wrote:
>
> * Thomas Garnier wrote:
>
> > arch/x86/include/asm/kaslr.h| 12 +++
>
> Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or
> in the
> x86 tree.
Ah, never mind, introduced by the first patch.
* Ingo Molnar wrote:
>
> * Thomas Garnier wrote:
>
> > arch/x86/include/asm/kaslr.h| 12 +++
>
> Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or
> in the
> x86 tree.
So the problem is that this file gets introduced by:
* Masanari Iida wrote:
> This patch fix some spelling typo found in
> Documentation/x86.
>
> Signed-off-by: Masanari Iida
> ---
> Documentation/x86/intel_mpx.txt | 6 +++---
> Documentation/x86/tlb.txt | 4 ++--
> Documentation/x86/x86_64/machinecheck | 2 +-
> 3 files chang
* Byungchul Park wrote:
> On Fri, Jul 08, 2016 at 07:50:39AM +0900, SeongJae Park wrote:
> > > I will add my opinion in korean.
> >
> > Thank you for kind and faithful review. I agree with most of your opinions
> > and
> > suggestions. Most of your suggestions looks much better than mine.
>
: Paul E. McKenney
> > Acked-by: Minchan Kim
> > Signed-off-by: SeongJae Park
>
> If Minchan is OK with this version, if Ingo and Jon have no objections,
> and given the small change below, I will take it.
Acked-by: Ingo Molnar
Thanks,
Ingo
--
To unsub
* Kees Cook wrote:
> > I see 0 up-sides of this approach and, as per the above, a whole bunch of
> > very
> > serious downsides.
> >
> > A global (esp. default inhibited) knob is too coarse and limiting.
>
> I haven't suggested it be default inhibit in the upstream Kconfig. And
> having this
* Arnaldo Carvalho de Melo wrote:
> Hi Ingo,
>
> This is on top of the previously submitted perf-core-for-mingo tag,
> please consider applying,
>
> - Arnaldo
>
> The following changes since commit 5ac76283b32b116c58e362e99542182ddcfc8262:
>
> perf cpumap: Auto initialize cpu__max_{n
* Michael S. Tsirkin wrote:
> Looks like the HPET spec at intel.com got moved.
> It isn't hard to find so drop the link, just mention
> the revision assumed.
>
> Suggested-by: Thomas Gleixner
> Signed-off-by: Michael S. Tsirkin
> ---
> drivers/char/hpet.c | 2 +-
> Documentation/ti
* Kees Cook wrote:
> - The STACKLEAK gcc plugin instruments the kernel code for tracking
> + The STACKLEAK options instruments the kernel code for tracking
speling.
Also, any chance to fix this terrible name? Should be something like
KSTACKZERO or KSTACKCLEAR, to tell people that
* Kees Cook wrote:
> On Wed, May 07, 2025 at 08:45:15PM +0200, Ingo Molnar wrote:
> >
> > * Kees Cook wrote:
> >
> > > - The STACKLEAK gcc plugin instruments the kernel code for tracking
> > > + The STACKLEAK options instruments the kernel code for
71 matches
Mail list logo
