The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: bb5570ad3b54e7930997aec76ab68256d5236d94
Gitweb:
https://git.kernel.org/tip/bb5570ad3b54e7930997aec76ab68256d5236d94
Author:Matt Fleming
AuthorDate:Thu, 18 Jun 2020 11:20:02 +01:00
Loop Stream Detector (verified using perf events).
Fixes: 1153933703d9 ("x86/asm/64: Micro-optimize __clear_user() - Use immediate
constants")
Cc: "Grimm, Jon"
Cc: "Kumar, Venkataramanan"
CC: Jan Kara
Cc: # v4.19+
Signed-off-by: Matt Fleming
---
arch/x86/li
On Wed, 27 May, at 12:25:33PM, Jiri Olsa wrote:
> On Tue, May 26, 2020 at 02:59:28PM +0100, Matt Fleming wrote:
> > +/*
> > + * Allocate a new event object from the free event cache.
> > + *
> > + * Find the first address range in the cache and carve out enough bytes
&
12.349+7.7%
6475305954370500MB 25.64823.753+7.4%
14218430569416 1000MB 52.80049.036+7.1%
26760562279427 2000MB 97.169 90.129+7.2%
Signed-off-by: Matt Fleming
---
Changes in v2:
- Add --free-event-list parameter to fallback to the linked-list
On Wed, 20 May, at 11:52:34PM, Jiri Olsa wrote:
> On Wed, May 20, 2020 at 02:00:49PM +0100, Matt Fleming wrote:
> >
> > Nope, the tests in this file are unit tests so I'm testing
> > free_cache_{get,put} which are file-local functions by #include'ing
> >
On Mon, 18 May, at 02:04:08PM, Jiri Olsa wrote:
> On Fri, May 15, 2020 at 10:01:51PM +0100, Matt Fleming wrote:
> > ordered_event objects can be placed on the free object cache list in any
> > order which means future allocations may not return objects at
> > sequentia
29MB 1.637 1.587+3.0%
3280413919096253MB 13.38112.349+7.7%
6475305954370500MB 25.64823.753+7.4%
14218430569416 1000MB 52.80049.036+7.1%
26760562279427 2000MB 97.169 90.129+7.2%
Signed-off-by: Matt Fleming
---
tools/include/l
On Fri, 18 Oct, at 01:54:49PM, Mel Gorman wrote:
> On Fri, Oct 18, 2019 at 12:58:49PM +0100, Matt Fleming wrote:
> > On Fri, 18 Oct, at 11:56:03AM, Mel Gorman wrote:
> > > A private report stated that system CPU usage was excessive on an AMD
> > > EPYC 2 machine while
On Fri, 18 Oct, at 11:56:03AM, Mel Gorman wrote:
> A private report stated that system CPU usage was excessive on an AMD
> EPYC 2 machine while building kernels with much longer build times than
> expected. The issue is partially explained by high zone lock contention
> due to the per-cpu page allo
ux/mm.h | 3 ---
> mm/internal.h | 3 +++
> 2 files changed, 3 insertions(+), 3 deletions(-)
Tested-by: Matt Fleming
ge.
>
> Signed-off-by: Mel Gorman
> ---
> mm/page_alloc.c | 23 ---
> 1 file changed, 12 insertions(+), 11 deletions(-)
Tested-by: Matt Fleming
he patch reduces system CPU usage by 69.16% and total build time by
> 27.06%. The variance of system CPU usage is also much reduced.
>
> Cc: sta...@vger.kernel.org # v4.15+
> Signed-off-by: Mel Gorman
> ---
> mm/page_alloc.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
Tested-by: Matt Fleming
On Mon, 07 Oct, at 08:28:16AM, Guenter Roeck wrote:
>
> This patch causes build errors on systems where NUMA does not depend on SMP,
> for example MIPS and PPC. For example, building mips:ip27_defconfig with SMP
> disabled results in
>
> mips-linux-ld: mm/page_alloc.o: in function `get_page_from_
The following commit has been merged into the sched/core branch of tip:
Commit-ID: a55c7454a8c887b226a01d7eed088ccb5374d81e
Gitweb:
https://git.kernel.org/tip/a55c7454a8c887b226a01d7eed088ccb5374d81e
Author:Matt Fleming
AuthorDate:Thu, 08 Aug 2019 20:53:01 +01:00
The following commit has been merged into the sched/core branch of tip:
Commit-ID: a2cbfd46559e809c8165773b7fe8afa058b35414
Gitweb:
https://git.kernel.org/tip/a2cbfd46559e809c8165773b7fe8afa058b35414
Author:Matt Fleming
AuthorDate:Thu, 08 Aug 2019 20:53:00 +01:00
active
balancer kicks in after a few seconds and forcibly moves some threads
to node 4.
Override node_reclaim_distance for AMD Zen.
Signed-off-by: Matt Fleming
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Mel Gorman
Cc: suravee.suthikulpa...@amd.com
Cc: Borislav Petkov
Cc: thomas.lenda...@am
igned-off-by: Matt Fleming
Cc: Tony Luck
Cc: Rik van Riel
Cc: Peter Zijlstra
---
arch/ia64/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 7468d8e50467..997baba02b70 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -389,6 +
tance'
page_alloc.c:(.text+0x7931): undefined reference to `node_reclaim_distance'
Matt Fleming (2):
ia64: Make NUMA select SMP
sched/topology: Improve load balancing on AMD EPYC
arch/ia64/Kconfig | 1 +
arch/x86/kernel/cpu/amd.c | 5 +
include/linux/t
t;
There's still an issue with the active load balancer kicking in after a few
seconds, but I suspect that is related to the use of group capacity
elsewhere
in the load balancer code (like update_sg_lb_stats()).
--
Matt Fleming
SUSE Performance Team
active
balancer kicks in after a few seconds and forcibly moves some threads
to node 4.
Override node_reclaim_distance for AMD Zen.
Signed-off-by: Matt Fleming
Cc: "Suthikulpanit, Suravee"
Cc: Mel Gorman
Cc: "Lendacky, Thomas"
Cc: Borislav Petkov
---
arch/x86/kerne
On Wed, 26 Jun, at 09:18:01PM, Suthikulpanit, Suravee wrote:
>
> We use 16 to designate 1-hop latency (for different node within the same
> socket).
> For across-socket access, since the latency is greater, we set the latency to
> 32
> (twice the latency of 1-hop) not aware of the RECLAIM_DISTAN
On Tue, 18 Jun, at 02:33:18PM, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 11:43:19AM +0100, Matt Fleming wrote:
> > This works for me under all my tests. Thoughts?
> >
> > --->8---
> >
> > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/ker
On Tue, 11 Jun, at 05:22:21PM, Lendacky, Thomas wrote:
> On 6/10/19 4:26 PM, Matt Fleming wrote:
> > On Wed, 05 Jun, at 08:00:35PM, Peter Zijlstra wrote:
> >>
> >> And then we had two magic values :/
> >>
> >> Should we not 'fix' RECLAIM_DIS
On Wed, 05 Jun, at 08:00:35PM, Peter Zijlstra wrote:
>
> And then we had two magic values :/
>
> Should we not 'fix' RECLAIM_DISTANCE for EPYC or something? Because
> surely, if we want to load-balance agressively over 30, then so too
> should we do node_reclaim() I'm thikning.
Yeah we can fix i
active
balancer kicks in after a few seconds and forcibly moves some threads
to node 4.
Update the code in sd_init() to account for modern node distances, and
maintaining backward-compatible behaviour by respecting
RECLAIM_DISTANCE for distances more than 2 hops.
Signed-off-by: Matt Fleming
Cc:
t;
> The traditional memory map for the kernel loader, used for Image or
> --
> 2.16.4
Not sure if this has already been picked up but...
Reviewed-by: Matt Fleming
On Sat, 22 Dec, at 12:07:48PM, Ard Biesheuvel wrote:
> On Fri, 21 Dec 2018 at 20:29, Borislav Petkov wrote:
> >
> > On Fri, Dec 21, 2018 at 06:26:23PM +0100, Ard Biesheuvel wrote:
> > > On Fri, 21 Dec 2018 at 18:13, Borislav Petkov wrote:
> > > >
> > > > On Fri, Dec 21, 2018 at 06:02:29PM +0100,
On Thu, 05 Jul, at 05:54:02PM, Valentin Schneider wrote:
> On 05/07/18 14:27, Matt Fleming wrote:
> > On Thu, 05 Jul, at 11:10:42AM, Valentin Schneider wrote:
> >> Hi,
> >>
> >> On 04/07/18 15:24, Matt Fleming wrote:
> >>> It's possible th
On Thu, 05 Jul, at 02:24:58PM, Matt Fleming wrote:
>
> Hmm.. it still looks to me like we should be saving and restoring IRQs
> since this can be called from IRQ context, no?
>
> The patch was a forward-port from one of our SLE kernels, and I messed
> up the IRQ flag balancing
On Thu, 05 Jul, at 11:10:42AM, Valentin Schneider wrote:
> Hi,
>
> On 04/07/18 15:24, Matt Fleming wrote:
> > It's possible that the CPU doing nohz idle balance hasn't had its own
> > load updated for many seconds. This can lead to huge deltas between
>
On Thu, 05 Jul, at 11:52:21AM, Dietmar Eggemann wrote:
>
> Moving the code from _nohz_idle_balance to nohz_idle_balance let it disappear:
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 02be51c9dcc1..070924f07c68 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
>
: Mike Galbraith
Cc: Peter Zijlstra
Signed-off-by: Matt Fleming
---
kernel/sched/fair.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 2f0a0be4d344..2c81662c858a 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@
On Wed, 30 May, at 04:22:36PM, Peter Zijlstra wrote:
> Hi all,
>
> This is all still very preliminary and could all still go up in flames (it has
> only seen hackbench so far). This is mostly the same code I posted yesterday,
> but hopefully in a more readable form.
>
> This fixes the SIS_PROP as
On Fri, 20 Apr, at 11:50:05AM, Peter Zijlstra wrote:
> On Tue, Apr 17, 2018 at 03:21:19PM +0100, Matt Fleming wrote:
> > Hi guys,
> >
> > We've seen a bug in one of our SLE kernels where the cpu stopper
> > thread ("migration/15") is entering idle b
Hi guys,
We've seen a bug in one of our SLE kernels where the cpu stopper
thread ("migration/15") is entering idle balance. This then triggers
active load balance.
At the same time, a task on another CPU triggers a page fault and NUMA
balancing kicks in to try and migrate the task closer to the N
++ b/kernel/sched/rt.c
> @@ -839,6 +839,8 @@ static int do_sched_rt_period_timer(struct rt_bandwidth
> *rt_b, int overrun)
> continue;
>
> raw_spin_lock(&rq->lock);
> + update_rq_clock(rq);
> +
> if (rt_rq->rt_time) {
> u64 runtime;
Looks good to me.
Reviewed-by: Matt Fleming
On Tue, 05 Dec, at 01:09:07PM, Atish Patra wrote:
> Currently, multiple tasks can wakeup on same cpu from
> select_idle_sibiling() path in case they wakeup simulatenously
> and last ran on the same llc. This happens because an idle cpu
> is not updated until idle task is scheduled out. Any task wak
i_switch_mm() to do this. This improves readability and maintainability.
> Also, instead of maintaining a separate struct "efi_scratch" to store/restore
> efi_pgd, we can use mm_struct to do this.
FWIW this series looks OK to me.
Reviewed-by: Matt Fleming
Commit-ID: 81b60dbff04980a45b348c5b5eeca2713d4594ca
Gitweb: https://git.kernel.org/tip/81b60dbff04980a45b348c5b5eeca2713d4594ca
Author: Matt Fleming
AuthorDate: Wed, 3 Jan 2018 09:44:17 +
Committer: Ingo Molnar
CommitDate: Wed, 3 Jan 2018 14:03:18 +0100
MAINTAINERS: Remove Matt
On Wed, 03 Jan, at 10:13:55AM, Ard Biesheuvel wrote:
> On 3 January 2018 at 09:44, Matt Fleming wrote:
> > Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks
> > as maintainers for the EFI test driver and efivarfs file system.
> >
> > Signed-off-b
Instate Ard Biesheuvel as the sole EFI maintainer and leave other folks
as maintainers for the EFI test driver and efivarfs file system.
Signed-off-by: Matt Fleming
---
MAINTAINERS | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
Ard, if you want to add yourself as co-maintainer of
On Sat, 16 Dec, at 12:19:53PM, Dave Young wrote:
> 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no
> chance to run because the code path is before parse_early_param().
> I believe it worked when the param was introduced but probably later
> some other changes caused the wrong ord
On Sat, 16 Dec, at 03:06:32PM, Ingo Molnar wrote:
>
> * Matt Fleming wrote:
>
> > > x86_init.oem.arch_setup();
> > > @@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p)
> > >
> > > parse_early_para
On Sat, 09 Dec, at 04:52:52PM, Vincent Legoll wrote:
> No need to get into the submenu to disable all related
> config entries.
>
> This makes it easier to disable all EFI config options
> without entering the submenu. It will also enable one
> to see that en/dis-abled state from the outside menu.
On Thu, 14 Dec, at 06:41:19PM, Dave Young wrote:
> On 11/30/17 at 01:23pm, Dave Young wrote:
> > 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no
> > chance to run because the code path is before parse_early_param().
> > I believe it worked when the param was introduced but probab
On Tue, 28 Nov, at 10:39:37PM, Vasyl Gomonovych wrote:
> Fix ptr_ret.cocci warnings:
> drivers/firmware/efi/efi.c:610:8-14: WARNING: PTR_ERR_OR_ZERO can be used
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Generated by: scripts/coccinelle/api/ptr_ret.cocci
>
> Signed-off-by:
(Cc'ing Dave since this is used for kexec on EFI)
On Fri, 01 Dec, at 09:54:43AM, Ard Biesheuvel wrote:
> On 1 December 2017 at 09:48, Greg Kroah-Hartman
> wrote:
> > On Thu, Nov 30, 2017 at 05:18:42PM +, Ard Biesheuvel wrote:
> >> On 30 November 2017 at 17:10, Greg Kroah-Hartman
> >> wrote:
On Fri, 06 Oct, at 11:36:23AM, Matt Fleming wrote:
>
> It's a similar story for hackbench-threads-{pipes,sockets}, i.e. pipes
> regress but performance is restored for sockets.
>
> Of course, like a dope, I forgot to re-run netperf with your WA_WEIGHT
> patch. So I'
On Mon, 25 Sep, at 04:17:23PM, Arvind Yadav wrote:
> pr_err() messages should terminated with a new-line to avoid
> other messages being concatenated onto the end.
>
> Signed-off-by: Arvind Yadav
> ---
> drivers/firmware/efi/capsule-loader.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On Wed, 04 Oct, at 06:18:50PM, Peter Zijlstra wrote:
> On Tue, Oct 03, 2017 at 10:39:32AM +0200, Peter Zijlstra wrote:
> > So I was waiting for Rik, who promised to run a bunch of NUMA workloads
> > over the weekend.
> >
> > The trivial thing regresses a wee bit on the overloaded case, I've not
>
On Wed, 27 Sep, at 01:58:20PM, Rik van Riel wrote:
>
> I like the simplicity of your approach! I hope it does not break
> stuff like netperf...
>
> I have been working on the patch below, which is much less optimistic
> about when to do an affine wakeup than before.
Running netperf for this pat
On Wed, 16 Aug, at 12:03:22PM, Mark Rutland wrote:
>
> I'd expect we'd abort at a higher level, not taking any sample. i.e.
> we'd have the core overflow handler check in_funny_mm(), and if so, skip
> the sample, as with the skid case.
FYI, this is my preferred solution for x86 too.
On Mon, 14 Aug, at 10:54:23PM, Baoquan He wrote:
> The existing map iteration helper for_each_efi_memory_desc_in_map can
> only be used after OS initializes EFI to fill data of struct efi_memory_map.
Should this say "EFI subsystem"? The firmware doesn't care about the
kernel's internal data struct
On Wed, 02 Aug, at 11:41:38AM, Stuart Hayes wrote:
> (Resend because I mistyped the maintainer's email address the first time.)
>
> The kernel's EFI stub locates and copies EFI ROM images into memory,
> which it allocates using the byte-granular EFI allocate_pool
> function. These memory ranges a
On Fri, 04 Aug, at 07:40:05PM, Baoquan He wrote:
> On 08/04/17 at 12:23pm, Matt Fleming wrote:
> > On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote:
> > > Hi Matt,
> > >
> > > On 07/28/17 at 11:55am, Ingo Molnar wrote:
> > > >
> > > >
On Fri, 28 Jul, at 07:26:03PM, Baoquan He wrote:
> Hi Matt,
>
> On 07/28/17 at 11:55am, Ingo Molnar wrote:
> >
> > * Matt Fleming wrote:
> >
> > > On Fri, 21 Jul, at 09:19:56PM, Baoquan He wrote:
> > > >
> > > > There are places whe
On Wed, 26 Jul, at 07:35:51AM, Greg KH wrote:
>
> If it needs a backport and a simple cherry-pick does not work, yes
> please.
Oh, it turns out cherry-picking commit 96b777452d88 to 4.9-stable
works just fine.
On Tue, 25 Jul, at 11:04:39AM, Greg KH wrote:
> On Thu, Jul 20, 2017 at 02:53:09PM +0100, Matt Fleming wrote:
> > From: Konstantin Khlebnikov
> >
> > commit 96b777452d8881480fd5be50112f791c17db4b6b upstream.
> >
> > Commit:
> >
> > 2f5177f0fd7
On Fri, 21 Jul, at 09:19:56PM, Baoquan He wrote:
>
> There are places where the efi map is getting and used like this. E.g
> in efi_high_alloc() of drivers/firmware/efi/libstub/efi-stub-helper.c.
> EFI developers worry the size of efi_memory_desc_t could not be the same
> as e->efi_memdesc_size?
>
On Mon, 10 Jul, at 02:51:36PM, Naoya Horiguchi wrote:
> EFI_BOOT_SERVICES_{CODE|DATA} regions never overlap the kernel now,
> so we can clean up the check in efi_reserve_boot_services().
>
> Signed-off-by: Naoya Horiguchi
> ---
> arch/x86/platform/efi/quirks.c | 23 +--
> 1 f
On Mon, 10 Jul, at 02:51:35PM, Naoya Horiguchi wrote:
> KASLR chooses kernel location from E820_TYPE_RAM regions by walking over
> e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and
> EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to
> UEFI spec, all memory r
Fix/cleanup cgroup teardown/init")
Link:
http://lkml.kernel.org/r/148655324740.424917.5302984537258726349.stgit@buzz
Signed-off-by: Ingo Molnar
Signed-off-by: Matt Fleming
---
kernel/sched/core.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/kernel/s
On Tue, 11 Jul, at 08:00:47AM, Andy Lutomirski wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/misc-tests.git/
>
> I did:
>
> $ ./context_switch_latency_64 0 process same
Ah, that's better. I see about a 3.3% speedup with your patches when
running the context-switch benchmark.
On Fri, 30 Jun, at 01:44:22PM, Matt Fleming wrote:
> On Thu, 29 Jun, at 08:53:12AM, Andy Lutomirski wrote:
> > *** Ingo, even if this misses 4.13, please apply the first patch before
> > *** the merge window.
> >
> > There are three performance benefits here:
>
On Fri, 07 Jul, at 06:11:24AM, Naoya Horiguchi wrote:
> On Fri, Jul 07, 2017 at 11:07:59AM +0800, Baoquan He wrote:
> > On 07/06/17 at 03:57pm, Matt Fleming wrote:
> > > On Thu, 06 Jul, at 08:31:07AM, Naoya Horiguchi wrote:
> > > > + for (i = 0; i < nr_desc;
On Fri, 07 Jul, at 11:07:59AM, Baoquan He wrote:
> On 07/06/17 at 03:57pm, Matt Fleming wrote:
> > On Thu, 06 Jul, at 08:31:07AM, Naoya Horiguchi wrote:
> > > + for (i = 0; i < nr_desc; i++) {
> > > + md = (efi_memory_desc_t *)(p
On Thu, 06 Jul, at 08:31:07AM, Naoya Horiguchi wrote:
>
> KASLR chooses kernel location from E820_TYPE_RAM regions by walking over
> e820 entries now. E820_TYPE_RAM includes EFI_BOOT_SERVICES_CODE and
> EFI_BOOT_SERVICES_DATA, so those regions can be the target. According to
> UEFI spec, all memor
On Tue, 04 Jul, at 04:46:58PM, Thomas Gleixner wrote:
> On Tue, 4 Jul 2017, Baoquan He wrote:
>
> > In fact I just referred to code in setup_arch(). Now I have a question,
> > though CONFIG_EFI=y but efi firmware is not enabled,
> > boot_params.efi_info.efi_loader_signature should be initilized t
On Thu, 29 Jun, at 08:49:13PM, Josef Bacik wrote:
>
> It may be worth to try with schedbench and trace it to see how this turns out
> in
> practice, as that's the workload that generated all this discussion before. I
> imagine generally speaking this works out properly. The small regression I
>
On Thu, 29 Jun, at 08:53:12AM, Andy Lutomirski wrote:
> *** Ingo, even if this misses 4.13, please apply the first patch before
> *** the merge window.
>
> There are three performance benefits here:
>
> 1. TLB flushing is slow. (I.e. the flush itself takes a while.)
>This avoids many of them
o.h |5 +
> arch/x86/mm/ioremap.c | 179
> +
> include/linux/io.h|2 +
> kernel/memremap.c | 20 -
> mm/early_ioremap.c| 18 -
> 5 files changed, 217 insertions(+), 7 deletions(-)
Reviewed-by: Matt Fleming
> Signed-off-by: Tom Lendacky
> ---
> arch/x86/platform/efi/efi_64.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
Reviewed-by: Matt Fleming
ware/efi/efi.c | 33 +
> include/linux/efi.h|7 +++
> 2 files changed, 40 insertions(+)
Reviewed-by: Matt Fleming
/efi/efi.c |6 +++---
> include/linux/efi.h |2 +-
> 3 files changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Matt Fleming
On Tue, 06 Jun, at 02:31:24PM, Kirill A. Shutemov wrote:
> We would need to switch temporarily to compatibility mode during booting
> with 5-level paging enabled. It would require 32-bit code segment
> descriptor.
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Matt Fleming
>
On Tue, 06 Jun, at 02:31:23PM, Kirill A. Shutemov wrote:
> Define __KERNEL_CS GDT entry as long mode (.L=1, .D=0) on 64-bit
> configuration.
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Matt Fleming
> ---
> arch/x86/boot/compressed/eboot.c | 9 +++--
> 1 file cha
On Tue, 06 Jun, at 02:31:22PM, Kirill A. Shutemov wrote:
> This is preparation for following patches without changing semantics of the
> code.
>
> Signed-off-by: Kirill A. Shutemov
> Cc: Matt Fleming
> ---
> arch/x86/boot/compressed/eboot.c | 39 +--
t; ENDPROC(startup_64)
>
> #ifdef CONFIG_EFI_STUB
> ENTRY(efi_pe_entry)
> ... ; a lot of assembly (efi_pe_entry)
> leaqstartup_64(%rax), %rax
> jmp *%rax
> ENDPROC(efi_pe_entry)
> #endif
>
ENDPROC(efi32_stub_entry)
> #endif
>
> Signed-off-by: Jiri Slaby
> Cc: "H. Peter Anvin"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc:
> Cc: David Woodhouse
> Cc: Matt Fleming
> ---
> arch/x86/boot/compressed/head_32.S | 129
> ++---
> 1 file changed, 64 insertions(+), 65 deletions(-)
Reviewed-by: Matt Fleming
On Fri, 19 May, at 04:00:35PM, Matt Fleming wrote:
> On Wed, 17 May, at 12:53:50PM, Peter Zijlstra wrote:
> >
> > Please test..
>
> Results are still coming in but things do look better with your patch
> applied.
>
> It does look like there's a regression
Young
Tested-by: Sabrina Dubroca
Cc: # v4.11+
Signed-off-by: Ard Biesheuvel
Signed-off-by: Matt Fleming
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/efi-bgrt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/efi/efi-bgrt.c b/drivers/firmware/efi/efi-bgrt.c
index
Ard Biesheuvel
Cc: # v4.9+
Signed-off-by: Matt Fleming
---
arch/x86/platform/efi/quirks.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 26615991d69c..e0cf95a83f3f 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x
Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Thomas Garnier
Cc: Kees Cook
Cc: Russ Anderson
Cc: Frank Ramsay
Cc: Borislav Petkov
Cc: Bhupesh Sharma
Signed-off-by: Matt Fleming
---
arch/x86/platform/efi/efi_64.c | 79 +-
1 file changed, 71 insertions
ons in the initial boot - Matt Fleming ]
Since kexec was never intended to work with efi=old_map, disable
runtime services in kexec if booted with efi=old_map, so that we don't
panic.
Signed-off-by: Sai Praneeth Prakhya
Cc: Borislav Petkov
Cc: Ricardo Neri
Cc: Ard Biesheuvel
Cc: Ravi Sha
Hi folks,
Please pull the following fixes. There are patches that resolve a few
boot crashes and some minor build and boot log cleanups.
The following changes since commit 08332893e37af6ae779367e78e444f8f9571511d:
Linux 4.12-rc2 (2017-05-21 19:30:23 -0700)
are available in the git repository
Reviewed-by: David Howells
Cc: Josh Boyer
Cc: Ingo Molnar
Signed-off-by: Matt Fleming
---
drivers/firmware/efi/libstub/secureboot.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/firmware/efi/libstub/secureboot.c
b/drivers/firmware/efi/libstub/secureboot.c
in
ct mapping to build ident mapping, instead need copy pud entry
> one by one from direct mapping.
>
> Fix it.
>
> Signed-off-by: Baoquan He
> Signed-off-by: Dave Young
> Cc: Matt Fleming
> Cc: Ard Biesheuvel
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: "H.
!
>
> [efi=old_map was never intended to work with kexec. The problem with
> using efi=old_map is that the virtual addresses are assigned from the
> memory region used by other kernel mappings; vmalloc() space.
> Potentially there could be collisions when booting kexec if something
&
On Mon, 15 May, at 11:28:16AM, Shuah Khan wrote:
> Hi Matt,
>
> On 05/15/2017 08:36 AM, Matt Fleming wrote:
> > On Fri, 12 May, at 10:01:41AM, Shuah Khan wrote:
> >>
> >> Greg/Matt,
> >>
> >> I started seeing this maybe since 4.11, so it isn
On Wed, 17 May, at 12:53:50PM, Peter Zijlstra wrote:
>
> Please test..
Results are still coming in but things do look better with your patch
applied.
It does look like there's a regression when running hackbench in
process mode and when the CPUs are not fully utilised, e.g. check this
out:
hack
On Mon, 15 May, at 08:35:17PM, Borislav Petkov wrote:
> On Tue, Apr 18, 2017 at 04:19:21PM -0500, Tom Lendacky wrote:
>
> > + paddr = boot_params.efi_info.efi_memmap_hi;
> > + paddr <<= 32;
> > + paddr |= boot_params.efi_info.efi_memmap;
> > + if (phys_addr =
On Wed, 17 May, at 12:53:50PM, Peter Zijlstra wrote:
> On Mon, May 15, 2017 at 02:03:11AM -0700, tip-bot for Peter Zijlstra wrote:
> > sched/fair, cpumask: Export for_each_cpu_wrap()
>
> > -static int cpumask_next_wrap(int n, const struct cpumask *mask, int start,
> > int *wrapped)
> > -{
>
> >
: EFI_MEMMAP is not enabled.
> efi: Failed to lookup EFI memory descriptor for 0xd9e0f018
>
>
> From 816e76129ed5fadd28e526c43397c79775194b5c Mon Sep 17 00:00:00 2001
> From: Matt Fleming
> Date: Mon, 29 Feb 2016 21:22:52 +
> Subject: [PATCH] efi: Allow driver
; Signed-off-by: Sai Praneeth Prakhya
> Cc: Borislav Petkov
> Cc: Ricardo Neri
> Cc: Matt Fleming
> Cc: Ard Biesheuvel
> Cc: Ravi Shankar
>
> Changes since v1:
> 1. Call efi_dump_pagetable() only once from efi_enter_virtual_mode() -
> as suggested by Boris
>
> -
On Thu, 11 May, at 01:43:17PM, Arnd Bergmann wrote:
> gcc-7 shows a harmless warning:
>
> drivers/firmware/efi/libstub/secureboot.c:19:27: error: duplicate 'const'
> declaration specifier [-Werror=duplicate-decl-specifier]
> static const efi_char16_t const efi_SecureBoot_name[] = {
> drivers/fir
use efi_pgd but rather it uses
> kernel's pgd. We don't hit the same panic in a regular kernel because
> it uses old_map_region() and not __map_region().
>
> Signed-off-by: Sai Praneeth Prakhya
> Cc: Borislav Petkov
> Cc: Ricardo Neri
> Cc: Matt Fleming
> Cc:
On Mon, 08 May, at 02:56:33PM, Juergen Gross wrote:
> When booted as Xen dom0 there won't be an EFI memmap allocated. Avoid
> issuing an error message in this case:
>
> [0.144079] efi: Failed to allocate new EFI memmap
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/platform/efi/quirks.c
On Mon, 08 May, at 04:18:30PM, Ivan Hu wrote:
>
>
> On 05/06/2017 04:53 AM, Matt Fleming wrote:
> >On Sat, 29 Apr, at 09:42:52AM, Geliang Tang wrote:
> >>Use memdup_user() helper instead of open-coding to simplify the code.
> >>
> >>Signed-off-by: Gelia
On Tue, 25 Apr, at 08:10:51PM, Fabian Frederick wrote:
> Remove NULL test on kmap()
>
> Signed-off-by: Fabian Frederick
> ---
> drivers/firmware/efi/capsule-loader.c | 5 -
> drivers/firmware/efi/capsule.c| 4
> 2 files changed, 9 deletions(-)
>
> diff --git a/drivers/firmware/
On Tue, 02 May, at 08:51:47AM, Ocean HY1 He wrote:
> The commit 7efe665903d0 ("rtc: Disable EFI rtc for x86") turns off rtc-efi
> option completely for x86 in rtc/Kconfig, to avoid possible crash caused by
> buggy implementations of the time-related EFI runtime services.
>
> In fact, there are mor
1 - 100 of 1787 matches
Mail list logo
