Re: [PATCH] x86: Add early quirk to reset Apple AirPort card

when a driver is loaded for the wireless > card, which may be never if the driver is not installed or blacklisted. [... Snip a very thorough changelog ...] This patch looks fine to me from an EFI perspective. Acked-by: Matt Fleming

[PATCH 1/2] efi: Fix for_each_efi_memory_desc_in_map() for empty memmaps

Kuznetsov <vkuzn...@redhat.com> Cc: Mark Salter <msal...@redhat.com> Cc: "K. Y. Srinivasan" <k...@microsoft.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- include/linux/efi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a

[PATCH 1/2] efi: Fix for_each_efi_memory_desc_in_map() for empty memmaps

Cc: "K. Y. Srinivasan" Signed-off-by: Matt Fleming --- include/linux/efi.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/efi.h b/include/linux/efi.h index c2db3ca22217..f196dd0b0f2f 100644 --- a/include/linux/efi.h +++ b/include

[PATCH 2/2] efi/arm: Fix the format of debug message from efi

lt;ard.biesheu...@linaro.org> Cc: linux-...@vger.kernel.org Cc: Steve McIntyre <st...@einval.com> Cc: Steven Rostedt <rost...@goodmis.org> Cc: Dan Williams <dan.j.willi...@intel.com> Cc: Mark Salter <msal...@redhat.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> ---

[GIT PULL 0/2] EFI urgent fixes

Folks, please pull the following urgent patches which fix a boot crash when using the "noefi" parameter and the debug output on arm. The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git repository at:

[PATCH 2/2] efi/arm: Fix the format of debug message from efi

-by: Dennis Chen Acked-by: Mark Rutland Cc: Catalin Marinas Cc: Steve Capper Cc: Will Deacon Cc: Ard Biesheuvel Cc: linux-...@vger.kernel.org Cc: Steve McIntyre Cc: Steven Rostedt Cc: Dan Williams Cc: Mark Salter Signed-off-by: Matt Fleming --- drivers/firmware/efi/arm-init.c | 14

[GIT PULL 0/2] EFI urgent fixes

Folks, please pull the following urgent patches which fix a boot crash when using the "noefi" parameter and the debug output on arm. The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git repository at:

Re: [PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

(Cc'ing Mark, the original author) On Wed, 25 May, at 04:36:55PM, Vitaly Kuznetsov wrote: > Commit 78ce248faa3c ("efi: Iterate over efi.memmap in > for_each_efi_memory_desc()") introduced a regression for systems booted > with 'noefi' kernel option. In particular, I observe early kernel hang in >

Re: [PATCH] efi: fix for_each_efi_memory_desc_in_map() for empty memmaps

(Cc'ing Mark, the original author) On Wed, 25 May, at 04:36:55PM, Vitaly Kuznetsov wrote: > Commit 78ce248faa3c ("efi: Iterate over efi.memmap in > for_each_efi_memory_desc()") introduced a regression for systems booted > with 'noefi' kernel option. In particular, I observe early kernel hang in >

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote: > > I looked into this and this would be a large change also to parse tables > and build lists. It occurred to me that this could all be taken care of > if the early_memremap calls were changed to early_ioremap calls. Looking > in the git log I

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Tue, 24 May, at 09:54:31AM, Tom Lendacky wrote: > > I looked into this and this would be a large change also to parse tables > and build lists. It occurred to me that this could all be taken care of > if the early_memremap calls were changed to early_ioremap calls. Looking > in the git log I

Re: [GIT PULL] EFI fix

On Mon, 16 May, at 01:05:45PM, Linus Torvalds wrote: > > I think the right fix is to just get rid of that silly conditional > frame pointer thing, and always use frame pointers in this stub > function. And then we don't need that (odd) load to get the old stack > pointer into %rax - we can just

Re: [GIT PULL] EFI fix

On Mon, 16 May, at 01:05:45PM, Linus Torvalds wrote: > > I think the right fix is to just get rid of that silly conditional > frame pointer thing, and always use frame pointers in this stub > function. And then we don't need that (odd) load to get the old stack > pointer into %rax - we can just

Re: [PATCH 2/3] sched,fair: Fix local starvation

the indirect call in the case we do a local wakeup. > > Cc: Pavan Kondeti <pkond...@codeaurora.org> > Cc: Ben Segall <bseg...@google.com> > Cc: Matt Fleming <m...@codeblueprint.co.uk> > Cc: Morten Rasmussen <morten.rasmus...@arm.com> > Cc: Paul Turner <p...@

Re: [PATCH 2/3] sched,fair: Fix local starvation

the indirect call in the case we do a local wakeup. > > Cc: Pavan Kondeti > Cc: Ben Segall > Cc: Matt Fleming > Cc: Morten Rasmussen > Cc: Paul Turner > Cc: Thomas Gleixner > Cc: byungchul.p...@lge.com > Cc: Andrew Hunter > Fixes: 3a47d5124a95 ("sched/fair:

Re: [Xen-devel] [GIT PULL] EFI ARM Xen support

On Wed, 18 May, at 12:46:38PM, Ingo Molnar wrote: > > I have no particular objections, since this seems to be Xen-next merged to > the EFI > tree that is already upstream, plus this single commit on top of t: > > 11ee5491e5ff Xen: EFI: Parse DT parameters for Xen specific UEFI > > Which, if

Re: [Xen-devel] [GIT PULL] EFI ARM Xen support

On Wed, 18 May, at 12:46:38PM, Ingo Molnar wrote: > > I have no particular objections, since this seems to be Xen-next merged to > the EFI > tree that is already upstream, plus this single commit on top of t: > > 11ee5491e5ff Xen: EFI: Parse DT parameters for Xen specific UEFI > > Which, if

Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

On Wed, 18 May, at 03:01:27AM, Yuyang Du wrote: > On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote: > > So, if the code looks like the following, either now or in the future, > > > > static void __schedule(bool preempt) > > { > > ... > >

Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

On Wed, 18 May, at 03:01:27AM, Yuyang Du wrote: > On Tue, May 17, 2016 at 01:24:15PM +0100, Matt Fleming wrote: > > So, if the code looks like the following, either now or in the future, > > > > static void __schedule(bool preempt) > > { > > ... > >

Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

On Tue, 17 May, at 04:11:09AM, Yuyang Du wrote: > On Mon, May 16, 2016 at 10:46:38AM +0100, Matt Fleming wrote: > > > > No because if someone calls rq_clock() immediately after __schedule(), > > or even immediately after we clear RQCF_ACT_SKIP in __schedule(), we > &g

Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

On Tue, 17 May, at 04:11:09AM, Yuyang Du wrote: > On Mon, May 16, 2016 at 10:46:38AM +0100, Matt Fleming wrote: > > > > No because if someone calls rq_clock() immediately after __schedule(), > > or even immediately after we clear RQCF_ACT_SKIP in __schedule(), we > &g

Re: [PATCH 1/2] Create UV efi_call macros

On Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote: > > I was simply re-using the efi_call implementation. Boris suggested that > I re-write this using the efi_call_virt macro, so I just went with that. > It all seems to work just fine, so I don't see much reason to stray away > from that

Re: [PATCH 1/2] Create UV efi_call macros

On Mon, 16 May, at 05:58:40PM, Alex Thorlton wrote: > > I was simply re-using the efi_call implementation. Boris suggested that > I re-write this using the efi_call_virt macro, so I just went with that. > It all seems to work just fine, so I don't see much reason to stray away > from that

Re: [GIT PULL] EFI fix

On Tue, 17 May, at 10:04:34AM, Matt Fleming wrote: > > Now I'm wondering whether other users of FRAME_BEGIN/FRAME_END make > this same mistake. Coccinelle might be able to detect it perhaps. A quick bit of sed turned up the code in arch/x86/entry/entry_64.S, which looks to suffer from

Re: [GIT PULL] EFI fix

On Tue, 17 May, at 10:04:34AM, Matt Fleming wrote: > > Now I'm wondering whether other users of FRAME_BEGIN/FRAME_END make > this same mistake. Coccinelle might be able to detect it perhaps. A quick bit of sed turned up the code in arch/x86/entry/entry_64.S, which looks to suffer from

Re: [GIT PULL] EFI fix

On Mon, 16 May, at 01:05:45PM, Linus Torvalds wrote: > > So that whole 8-vs-16 offset confusion depends on the frame pointer! > If frame pointers were enabled, it will be 16. If they weren't, it > will be 8. That patch that changes it from 8 to 16 will just move the > bug around. Before, it was

Re: [GIT PULL] EFI fix

On Mon, 16 May, at 01:05:45PM, Linus Torvalds wrote: > > So that whole 8-vs-16 offset confusion depends on the frame pointer! > If frame pointers were enabled, it will be 16. If they weren't, it > will be 8. That patch that changes it from 8 to 16 will just move the > bug around. Before, it was

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

rnel/mcount_64.S > +++ b/arch/x86/kernel/mcount_64.S > @@ -182,7 +182,8 @@ GLOBAL(ftrace_graph_call) > jmp ftrace_stub > #endif > > -GLOBAL(ftrace_stub) > +/* This is weak to keep gas from relaxing the jumps */ > +WEAK(ftrace_stub) > retq > END(ftrac

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

rnel/mcount_64.S > +++ b/arch/x86/kernel/mcount_64.S > @@ -182,7 +182,8 @@ GLOBAL(ftrace_graph_call) > jmp ftrace_stub > #endif > > -GLOBAL(ftrace_stub) > +/* This is weak to keep gas from relaxing the jumps */ > +WEAK(ftrace_stub) > retq > END(ftrace_caller) Works for me. Tested-by: Matt Fleming

Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

ch series doesn't address is that some callers of update_rq_clock() do not pin rq->lock, which makes the diagnostic checks useless in that case. I plan on handling that next, but I wanted to get this series out as soon as possible for review. > On Thu, May 12, 2016 at 08:49:53PM +0100, Matt Fl

Re: [RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

ch series doesn't address is that some callers of update_rq_clock() do not pin rq->lock, which makes the diagnostic checks useless in that case. I plan on handling that next, but I wanted to get this series out as soon as possible for review. > On Thu, May 12, 2016 at 08:49:53PM +0100, Matt Fl

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Fri, 13 May, at 10:06:10AM, Steven Rostedt wrote: > Matt, > > This bug looks very similar to what you were hitting with the function > profiler. Can you apply this patch and see if it fixes the issue for > you. Yep, this patch fixes it for me. For the record, this is what objdump tells me

Re: [PATCH] ftrace/x86: Fix function graph tracer reset path

On Fri, 13 May, at 10:06:10AM, Steven Rostedt wrote: > Matt, > > This bug looks very similar to what you were hitting with the function > profiler. Can you apply this patch and see if it fixes the issue for > you. Yep, this patch fixes it for me. For the record, this is what objdump tells me

Re: [PATCH 2/5] efibc: Fix excessive stack footprint warning

On Wed, 11 May, at 05:16:24PM, Jeremy Compostella wrote: > From 3a54e6872e220e1ac4db0eae126a20b5383dae3e Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Tue, 10 May 2016 10:34:21 +0200 > Subject: [PATCH] efibc: report more information in the error

Re: [PATCH 2/5] efibc: Fix excessive stack footprint warning

On Wed, 11 May, at 05:16:24PM, Jeremy Compostella wrote: > From 3a54e6872e220e1ac4db0eae126a20b5383dae3e Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Tue, 10 May 2016 10:34:21 +0200 > Subject: [PATCH] efibc: report more information in the error messages > > Report the name of the

[GIT PULL] EFI ARM Xen support

copy batch size to 16 Matt Fleming (1): Merge branch 'xen/linux-next' into efi/arm-xen Shannon Zhao (16): Xen: ACPI: Hide UART used by Xen xen/grant-table: Move xlated_setup_gnttab_pages to common place Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn ar

[GIT PULL] EFI ARM Xen support

copy batch size to 16 Matt Fleming (1): Merge branch 'xen/linux-next' into efi/arm-xen Shannon Zhao (16): Xen: ACPI: Hide UART used by Xen xen/grant-table: Move xlated_setup_gnttab_pages to common place Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn ar

Re: [PATCH v2] Xen: EFI: Parse DT parameters for Xen specific UEFI

calls and they are always enabled. So it > sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and > bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES > flag is set already. > > CC: Matt Fleming <m...@codeblueprint.co.uk> > Signed-off-by:

Re: [PATCH v2] Xen: EFI: Parse DT parameters for Xen specific UEFI

lways enabled. So it > sets the EFI_RUNTIME_SERVICES flag if it finds /hyperviosr/uefi node and > bails out in arm_enable_runtime_services() when EFI_RUNTIME_SERVICES > flag is set already. > > CC: Matt Fleming > Signed-off-by: Shannon Zhao > --- > v2: rebase it on top of EFI

[PATCH] x86/efi: Fix 7th argument to efi_call

avis <tra...@sgi.com> Cc: Borislav Petkov <b...@suse.de> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Ingo Molnar <mi...@redhat.com> Cc: "H. Peter Anvin" <h...@zytor.com> Cc: x...@kernel.org Cc: linux-...@vger.kernel.org Cc: <sta...@vger.kernel.org> [ Upda

[PATCH] x86/efi: Fix 7th argument to efi_call

ot; Cc: x...@kernel.org Cc: linux-...@vger.kernel.org Cc: [ Updated changelog. ] Signed-off-by: Matt Fleming --- arch/x86/platform/efi/efi_stub_64.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/platform/efi/efi_stub_64.S b/arch/x86/platform/efi/efi_stub_64.S index 92

[GIT PULL] EFI urgent fix

The following changes since commit c10fcb14c7afd6688c7b197a814358fecf244222: x86/sysfb_efi: Fix valid BAR address range check (2016-05-05 16:01:00 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent for you to fetch

[GIT PULL] EFI urgent fix

The following changes since commit c10fcb14c7afd6688c7b197a814358fecf244222: x86/sysfb_efi: Fix valid BAR address range check (2016-05-05 16:01:00 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-urgent for you to fetch

Re: [PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

On Fri, 13 May, at 08:23:47AM, Joe Perches wrote: > On Fri, 2016-05-13 at 17:11 +0200, Xose Vazquez Perez wrote: > > Matt Fleming wrote: > > > > > > > > Mark reported that having asterisks on the end of directory names > > > confuses get_maint

Re: [PATCH 1/3] MAINTAINERS: Remove asterisk from EFI directory names

On Fri, 13 May, at 08:23:47AM, Joe Perches wrote: > On Fri, 2016-05-13 at 17:11 +0200, Xose Vazquez Perez wrote: > > Matt Fleming wrote: > > > > > > > > Mark reported that having asterisks on the end of directory names > > > confuses get_maint

[RFC][PATCH 0/5] sched: Diagnostic checks for missing rq clock updates

d this entire series as RFC. All the diagnostic code is guarded by CONFIG_SCHED_DEBUG, but there are minimal changes to __schedule() in patch 5 for the !SCHED_DEBUG case. Matt Fleming (5): sched/fair: Update the rq clock before detaching tasks sched: Add wrappers for lockdep_(un)pin_lock()

[RFC][PATCH 0/5] sched: Diagnostic checks for missing rq clock updates

d this entire series as RFC. All the diagnostic code is guarded by CONFIG_SCHED_DEBUG, but there are minimal changes to __schedule() in patch 5 for the !SCHED_DEBUG case. Matt Fleming (5): sched/fair: Update the rq clock before detaching tasks sched: Add wrappers for lockdep_(un)pin_lock()

[RFC][PATCH 2/5] sched: Add wrappers for lockdep_(un)pin_lock()

.@gmail.com> Cc: Wanpeng Li <wanpeng...@hotmail.com> Cc: Luca Abeni <luca.ab...@unitn.it> Cc: Yuyang Du <yuyang...@intel.com> Cc: Byungchul Park <byungchul.p...@lge.com> Cc: Rik van Riel <r...@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.co

[RFC][PATCH 2/5] sched: Add wrappers for lockdep_(un)pin_lock()

uct rq_flags *'. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman Cc: Thomas Gleixner Cc: Frederic Weisbecker Cc: Wanpeng Li Cc: Luca Abeni Cc: Yuyang Du Cc: Byungchul Park Cc: Rik van Riel Cc: "Rafael J. Wysocki" Signed-off-by: Matt Fleming --- kernel

[RFC][PATCH 1/5] sched/fair: Update the rq clock before detaching tasks

y.net> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Cc: Yuyang Du <yuyang...@intel.com> Cc: Byungchul Park <byungchul.p...@lge.com> Cc: Rik van Riel <r...@redhat.com> Cc: Frederic Weisbecker <fweis...@gmail.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk&

[RFC][PATCH 1/5] sched/fair: Update the rq clock before detaching tasks

: Frederic Weisbecker Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 218f8e83db73..02856647339d 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8378,6 +8378,8 @@ static void

[RFC][PATCH 3/5] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

Cc: Mel Gorman <mgor...@techsingularity.net> Cc: Thomas Gleixner <t...@linutronix.de> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- kernel/sched/core.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index dfdd8c3

[RFC][PATCH 3/5] sched/core: Reset RQCF_ACT_SKIP before unpinning rq->lock

->clock_skip_update immediately before unpinning the rq lock. This will avoid the new warnings which check if update_rq_clock() is being actively skipped. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Mike Galbraith Cc: Mel Gorman Cc: Thomas Gleixner Signed-off-by: Matt Fleming --- kernel/sched/core.c

[RFC][PATCH 4/5] sched/fair: Push rq lock pin/unpin into idle_balance()

l.org> Cc: Mike Galbraith <umgwanakikb...@gmail.com> Cc: Mel Gorman <mgor...@techsingularity.net> Cc: Yuyang Du <yuyang...@intel.com> Cc: Byungchul Park <byungchul.p...@lge.com> Cc: Rik van Riel <r...@redhat.com> Cc: Frederic Weisbecker <fweis...@gmail.com> Signe

[RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

: Mel Gorman <mgor...@techsingularity.net> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Frederic Weisbecker <fweis...@gmail.com> Cc: Yuyang Du <yuyang...@intel.com> Cc: "Rafael J. Wysocki" <rafael.j.wyso...@intel.com> Signed-off-by: Matt Fleming <m...@codeblueprint.c

[RFC][PATCH 4/5] sched/fair: Push rq lock pin/unpin into idle_balance()

Du Cc: Byungchul Park Cc: Rik van Riel Cc: Frederic Weisbecker Signed-off-by: Matt Fleming --- kernel/sched/fair.c | 27 +++ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7f776a99bde0..217e3a9d78db 100644

[RFC][PATCH 5/5] sched/core: Add debug code to catch missing update_rq_clock()

socki" Signed-off-by: Matt Fleming --- kernel/sched/core.c | 13 +++--- kernel/sched/sched.h | 70 +++- 2 files changed, 73 insertions(+), 10 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index d2112c268fd1..0999b3f23

Re: [PATCH 1/2] Create UV efi_call macros

e more details in the changelog on why your machine doesn't boot without this change? > Signed-off-by: Alex Thorlton <athorl...@sgi.com> > Cc: Dimitri Sivanich <sivan...@sgi.com> > Cc: Russ Anderson <r...@sgi.com> > Cc: Mike Travis <tra...@sgi.com> > Cc: Matt Flemin

Re: [PATCH 1/2] Create UV efi_call macros

e more details in the changelog on why your machine doesn't boot without this change? > Signed-off-by: Alex Thorlton > Cc: Dimitri Sivanich > Cc: Russ Anderson > Cc: Mike Travis > Cc: Matt Fleming > Cc: Borislav Petkov > Cc: Thomas Gleixner > Cc: Ingo Molnar &g

Re: [PATCH 2/2] Fix efi_call

On Thu, 12 May, at 08:48:35AM, Ingo Molnar wrote: > > * Alex Thorlton wrote: > > > The efi_call assembly code has a slight error that prevents us from > > using arguments 7 and higher, which will be passed in on the stack. > > > > mov (%rsp), %rax > > mov

Re: [PATCH 2/2] Fix efi_call

On Thu, 12 May, at 08:48:35AM, Ingo Molnar wrote: > > * Alex Thorlton wrote: > > > The efi_call assembly code has a slight error that prevents us from > > using arguments 7 and higher, which will be passed in on the stack. > > > > mov (%rsp), %rax > > mov 8(%rax), %rax > >

Re: [PATCH 2/2] Fix efi_call

h argument > to the EFI runtime function that we're about to call. This change gets > our EFI runtime calls that need to pass more than 6 arguments working > again. > > Signed-off-by: Alex Thorlton <athorl...@sgi.com> > Cc: Dimitri Sivanich <sivan...@sgi.com> > Cc

Re: [PATCH 2/2] Fix efi_call

h argument > to the EFI runtime function that we're about to call. This change gets > our EFI runtime calls that need to pass more than 6 arguments working > again. > > Signed-off-by: Alex Thorlton > Cc: Dimitri Sivanich > Cc: Russ Anderson > Cc: Mike Travis > Cc:

Re: [PATCH 0/3] sched: Fix wakeup preemption regression

On Tue, 10 May, at 07:43:14PM, Peter Zijlstra wrote: > A recent commit caused an interactivity/starvation issue because we wrecked rq > local wakeup preemption. > > These patches rectify this while also (hopefully) keeping the problem that led > to the fault patch fixed. > > Mike, Pavan, could

Re: [PATCH 0/3] sched: Fix wakeup preemption regression

On Tue, 10 May, at 07:43:14PM, Peter Zijlstra wrote: > A recent commit caused an interactivity/starvation issue because we wrecked rq > local wakeup preemption. > > These patches rectify this while also (hopefully) keeping the problem that led > to the fault patch fixed. > > Mike, Pavan, could

Re: [PATCH 1/3] sched,fair: Move record_wakee()

On Tue, 10 May, at 07:43:15PM, Peter Zijlstra wrote: > Since I want to make ->task_woken() conditional on the task getting > migrated, we cannot use it to call record_wakee(). You mean ->task_waking(), right?

Re: [PATCH 1/3] sched,fair: Move record_wakee()

On Tue, 10 May, at 07:43:15PM, Peter Zijlstra wrote: > Since I want to make ->task_woken() conditional on the task getting > migrated, we cannot use it to call record_wakee(). You mean ->task_waking(), right?

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote: > > As said above, I will rebase this patch on top of the EFI next branch. OK thanks. Note that it is not possible to escape merge conflicts, since there are changes in the xen tip tree that are not in the EFI next branch and vice versa. For

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Thu, 12 May, at 10:22:07AM, Shannon Zhao wrote: > > As said above, I will rebase this patch on top of the EFI next branch. OK thanks. Note that it is not possible to escape merge conflicts, since there are changes in the xen tip tree that are not in the EFI next branch and vice versa. For

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote: > > > > Also, why do you need to setup efi.runtime_version here? Isn't that > > done inside uefi_init()? > > > I don't see any codes which setup efi.runtime_version in uefi_init(). Look in the EFI tree,

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Wed, 11 May, at 09:35:47PM, Shannon Zhao wrote: > > > > Also, why do you need to setup efi.runtime_version here? Isn't that > > done inside uefi_init()? > > > I don't see any codes which setup efi.runtime_version in uefi_init(). Look in the EFI tree,

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Wed, 11 May, at 07:37:52PM, Peter Zijlstra wrote: > On Wed, May 11, 2016 at 12:55:56PM +0100, Matt Fleming wrote: > > > This breaks my POWER7 box which presumably doesn't have > > SD_SHARE_PKG_RESOURCES, > > > index 978b3ef2d87e..d27153adee4d 100644 > > --

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Wed, 11 May, at 07:37:52PM, Peter Zijlstra wrote: > On Wed, May 11, 2016 at 12:55:56PM +0100, Matt Fleming wrote: > > > This breaks my POWER7 box which presumably doesn't have > > SD_SHARE_PKG_RESOURCES, > > > index 978b3ef2d87e..d27153adee4d 100644 > > --

Re: [PATCH 2/5] efibc: Fix excessive stack footprint warning

On Tue, 10 May, at 10:40:22AM, Jeremy Compostella wrote: > Why not. See patch as attachment. > > Thanks, > > Jérémy > > From 8a9b07e2d7242fa8a36157f1025202a96c3c7c9a Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Tue, 10 May 2016 10:34:21 +0200 >

Re: [PATCH 2/5] efibc: Fix excessive stack footprint warning

On Tue, 10 May, at 10:40:22AM, Jeremy Compostella wrote: > Why not. See patch as attachment. > > Thanks, > > Jérémy > > From 8a9b07e2d7242fa8a36157f1025202a96c3c7c9a Mon Sep 17 00:00:00 2001 > From: Jeremy Compostella > Date: Tue, 10 May 2016 10:34:21 +0200 > Subject: [PATCH] efibc: report

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Fri, 06 May, at 09:52:42AM, Mathieu Poirier wrote: > > +static int __init efi_remap_init(void) > > +{ > > + u64 mapsize; > > + > > + pr_info("Remapping and enabling EFI services.\n"); > > + > > + mapsize = memmap.map_end - memmap.map; > > + memmap.map = (__force void

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

On Fri, 06 May, at 09:52:42AM, Mathieu Poirier wrote: > > +static int __init efi_remap_init(void) > > +{ > > + u64 mapsize; > > + > > + pr_info("Remapping and enabling EFI services.\n"); > > + > > + mapsize = memmap.map_end - memmap.map; > > + memmap.map = (__force void

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

from bare metal? - Why is it OK to force enable EFI runtime services for Xen? I think it would also be good to explicitly state that we do not expect to find both Xen EFI DT parameters and bare metal EFI DT parameters when performing the search; the two should be mutually exclusive

Re: [PATCH] Xen: EFI: Parse DT parameters for Xen specific UEFI

o force enable EFI runtime services for Xen? I think it would also be good to explicitly state that we do not expect to find both Xen EFI DT parameters and bare metal EFI DT parameters when performing the search; the two should be mutually exclusive. > CC: Matt Fleming > Signed-off-by: Sh

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Mon, 09 May, at 12:48:11PM, Peter Zijlstra wrote: > Move the nr_busy_cpus thing from its hacky sd->parent->groups->sgc > location into the much more natural sched_domain_shared location. > > Signed-off-by: Peter Zijlstra (Intel) > --- > include/linux/sched.h|1 +

Re: [RFC][PATCH 4/7] sched: Replace sd_busy/nr_busy_cpus with sched_domain_shared

On Mon, 09 May, at 12:48:11PM, Peter Zijlstra wrote: > Move the nr_busy_cpus thing from its hacky sd->parent->groups->sgc > location into the much more natural sched_domain_shared location. > > Signed-off-by: Peter Zijlstra (Intel) > --- > include/linux/sched.h|1 + >

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote: > The EFI tables are not encrypted and need to be accessed as such. Be sure > to memmap them without the encryption attribute set. For EFI support that > lives outside of the arch/x86 tree, create a routine that uses the __weak > attribute so that

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Tue, 26 Apr, at 05:57:40PM, Tom Lendacky wrote: > The EFI tables are not encrypted and need to be accessed as such. Be sure > to memmap them without the encryption attribute set. For EFI support that > lives outside of the arch/x86 tree, create a routine that uses the __weak > attribute so that

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > If you think we're violating EFI rules by accessing these registers from > both sides of the fence, please let me know. I'd like to make sure that > we get everything behaving the way it should be! Oh no, I don't think this is violating

Re: [BUG] x86/efi: MMRs no longer properly mapped after switch to isolated page table

On Mon, 02 May, at 04:39:31PM, Alex Thorlton wrote: > > If you think we're violating EFI rules by accessing these registers from > both sides of the fence, please let me know. I'd like to make sure that > we get everything behaving the way it should be! Oh no, I don't think this is violating

[tip:efi/core] efi/capsule: Move 'capsule' to the stack in efi_capsule_supported()

Commit-ID: fb7a84cac03541f4da18dfa25b3f4767d4efc6fc Gitweb: http://git.kernel.org/tip/fb7a84cac03541f4da18dfa25b3f4767d4efc6fc Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Fri, 6 May 2016 22:39:29 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat

[tip:efi/core] efi/capsule: Move 'capsule' to the stack in efi_capsule_supported()

Commit-ID: fb7a84cac03541f4da18dfa25b3f4767d4efc6fc Gitweb: http://git.kernel.org/tip/fb7a84cac03541f4da18dfa25b3f4767d4efc6fc Author: Matt Fleming AuthorDate: Fri, 6 May 2016 22:39:29 +0100 Committer: Ingo Molnar CommitDate: Sat, 7 May 2016 07:06:13 +0200 efi/capsule: Move 'capsule

[tip:efi/core] efi/capsule: Make efi_capsule_pending() lockless

Commit-ID: 62075e581802ea1842d5d3c490a7e46330bdb9e1 Gitweb: http://git.kernel.org/tip/62075e581802ea1842d5d3c490a7e46330bdb9e1 Author: Matt Fleming <m...@codeblueprint.co.uk> AuthorDate: Fri, 6 May 2016 22:39:27 +0100 Committer: Ingo Molnar <mi...@kernel.org> CommitDate: Sat

[tip:efi/core] efi/capsule: Make efi_capsule_pending() lockless

Commit-ID: 62075e581802ea1842d5d3c490a7e46330bdb9e1 Gitweb: http://git.kernel.org/tip/62075e581802ea1842d5d3c490a7e46330bdb9e1 Author: Matt Fleming AuthorDate: Fri, 6 May 2016 22:39:27 +0100 Committer: Ingo Molnar CommitDate: Sat, 7 May 2016 07:06:13 +0200 efi/capsule: Make

[PATCH 5/5] efivarfs: Make efivarfs_file_ioctl static

From: Peter Jones <pjo...@redhat.com> There are no callers except through the file_operations struct below this, so it should be static like everything else here. Signed-off-by: Peter Jones <pjo...@redhat.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- fs/e

[PATCH 4/5] efi: Merge boolean flag arguments

m> Cc: Saurabh Sengar <saurabh.tr...@gmail.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/efivars.c | 5 ++--- drivers/firmware/efi/vars.c| 23 ++- fs/efivarfs/super.c| 3 +-- include/linux/efi.h

[PATCH 5/5] efivarfs: Make efivarfs_file_ioctl static

From: Peter Jones There are no callers except through the file_operations struct below this, so it should be static like everything else here. Signed-off-by: Peter Jones Signed-off-by: Matt Fleming --- fs/efivarfs/file.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs

[PATCH 4/5] efi: Merge boolean flag arguments

duplicating the lock code. Signed-off-by: Julia Lawall Cc: Ard Biesheuvel Cc: Matthew Garrett Cc: Jeremy Kerr Cc: Vaishali Thakkar Cc: Saurabh Sengar Signed-off-by: Matt Fleming --- drivers/firmware/efi/efivars.c | 5 ++--- drivers/firmware/efi/vars.c| 23 ++- fs/efivarfs

[PATCH 3/5] efi/capsule: Move 'capsule' to the stack in efi_capsule_supported()

v Petkov <b...@alien8.de> Cc: Kweh Hock Leong <hock.leong.k...@intel.com> Cc: Bryan O'Donoghue <pure.lo...@nexus-software.ie> Cc: joeyli <j...@suse.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/capsule.c | 29 +++

[PATCH 3/5] efi/capsule: Move 'capsule' to the stack in efi_capsule_supported()

t very big and doesn't need to persist after the function returns. Place 'capsule' on the stack instead. Suggested-by: Ard Biesheuvel Acked-by: Ard Biesheuvel Reported-by: Dan Carpenter Cc: Borislav Petkov Cc: Kweh Hock Leong Cc: Bryan O'Donoghue Cc: joeyli Signed-off-by: Matt Fleming --

[GIT PULL 0/5] EFI changes for v4.7

efi_capsule_pending() was grabbing a mutex in the emergency reboot path - Matt Fleming * Fix a compiler warning about excessive stack usage in the new efibc driver by kmalloc'ing the efivar_entry object - Jeremy Compostella * Dan Carpenter reported that it's potentially unsafe to pass the address

[PATCH 1/5] efi/capsule: Make efi_capsule_pending() lockless

k.leong.k...@intel.com> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: Bryan O'Donoghue <pure.lo...@nexus-software.ie> Cc: joeyli <j...@suse.com> Signed-off-by: Matt Fleming <m...@codeblueprint.co.uk> --- drivers/firmware/efi/capsule.c | 36 ++-

[PATCH 2/5] efibc: Fix excessive stack footprint warning

erflow. Reported-by: Ingo Molnar <mi...@kernel.org> Reported-by: Arnd Bergmann <a...@arndb.de> Signed-off-by: Jeremy Compostella <jeremy.composte...@intel.com> Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> [ Updated changelog to include gcc error ] Signed-off-by: Matt Fle

[GIT PULL 0/5] EFI changes for v4.7

efi_capsule_pending() was grabbing a mutex in the emergency reboot path - Matt Fleming * Fix a compiler warning about excessive stack usage in the new efibc driver by kmalloc'ing the efivar_entry object - Jeremy Compostella * Dan Carpenter reported that it's potentially unsafe to pass the address

[PATCH 1/5] efi/capsule: Make efi_capsule_pending() lockless

O'Donoghue Cc: joeyli Signed-off-by: Matt Fleming --- drivers/firmware/efi/capsule.c | 36 ++-- 1 file changed, 26 insertions(+), 10 deletions(-) diff --git a/drivers/firmware/efi/capsule.c b/drivers/firmware/efi/capsule.c index 0de55944ac0b..4703dc9b8fbd 100644

<    4   5   6   7   8   9   10   11   12   13   >