[PATCH v3 08/10] x86/asm: add unwind hint annotations to sync_core()

This enables objtool to grok the iret in the middle of a C function. Signed-off-by: Josh Poimboeuf --- arch/x86/include/asm/processor.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index

[PATCH v3 08/10] x86/asm: add unwind hint annotations to sync_core()

This enables objtool to grok the iret in the middle of a C function. Signed-off-by: Josh Poimboeuf --- arch/x86/include/asm/processor.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index 6a79547..b27dc9b 100644 ---

[PATCH v3 02/10] x86/entry/64: Initialize the top of the IRQ stack before switching stacks

From: Andy Lutomirski The OOPS unwinder wants the word at the top of the IRQ stack to point back to the previous stack at all times when the IRQ stack is in use. There's currently a one-instruction window in ENTER_IRQ_STACK during which this isn't the case. Fix it by writing

[PATCH v3 02/10] x86/entry/64: Initialize the top of the IRQ stack before switching stacks

From: Andy Lutomirski The OOPS unwinder wants the word at the top of the IRQ stack to point back to the previous stack at all times when the IRQ stack is in use. There's currently a one-instruction window in ENTER_IRQ_STACK during which this isn't the case. Fix it by writing the old RSP to the

[PATCH v3 03/10] x86/dumpstack: fix occasionally missing registers

If two consecutive stack frames have pt_regs, the oops dump code fails to print the second frame's registers. Fix that. Fixes: 3b3fa11bc700 ("x86/dumpstack: Print any pt_regs found on the stack") Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/dumpstack.c | 12

[PATCH v3 03/10] x86/dumpstack: fix occasionally missing registers

If two consecutive stack frames have pt_regs, the oops dump code fails to print the second frame's registers. Fix that. Fixes: 3b3fa11bc700 ("x86/dumpstack: Print any pt_regs found on the stack") Signed-off-by: Josh Poimboeuf --- arch/x86/kernel/dumpstack.c | 12 +++- 1 file changed, 7

[PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

The biggest change is that undwarf was renamed to ORC. Here's the relevant explanation from the docs: Etymology - Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural enemies. Similarly, the ORC unwinder was created in opposition to the complexity and

[PATCH v3 00/10] x86: ORC unwinder (previously undwarf)

The biggest change is that undwarf was renamed to ORC. Here's the relevant explanation from the docs: Etymology - Orcs, fearsome creatures of medieval folklore, are the Dwarves' natural enemies. Similarly, the ORC unwinder was created in opposition to the complexity and

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: > > * Kyle Huey wrote: > >> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >> wrote: >> > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >> >> Should

Re: [PATCH] perf/core: generate overflow signal when samples are dropped (WAS: Re: [REGRESSION] perf/core: PMU interrupts dropped if we entered the kernel in the "skid" region)

On Tue, Jul 11, 2017 at 2:03 AM, Ingo Molnar wrote: > > * Kyle Huey wrote: > >> On Wed, Jul 5, 2017 at 10:07 PM, Robert O'Callahan >> wrote: >> > On Tue, Jul 4, 2017 at 3:21 AM, Mark Rutland wrote: >> >> Should any of those be moved into the "should be dropped" pile? >> > >> > Why not be

Re: [PATCH v2 1/4] scsi: scsi_dh_alua: allow I/O in target port unavailable and standby states

On 07/11/2017 06:18 AM, Hannes Reinecke wrote: NACK. The whole_point_ of having device handlers is to_avoid_ I/O errors during booting. And the ALUA checker is prepared to handle this situation properly. The directio checker of course doesn't know about this, but then no-one expected the

Re: [PATCH v2 1/4] scsi: scsi_dh_alua: allow I/O in target port unavailable and standby states

On 07/11/2017 06:18 AM, Hannes Reinecke wrote: NACK. The whole_point_ of having device handlers is to_avoid_ I/O errors during booting. And the ALUA checker is prepared to handle this situation properly. The directio checker of course doesn't know about this, but then no-one expected the

Re: [PATCH 1/2] staging: atomisp2: hmm: Fixed comment style

On Mon, Jul 10, 2017 at 08:56:20PM +0200, Philipp Guendisch wrote: > This patch fixed comment style. Semantic should not be affected. > There are also two warnings left about too long lines, which > reduce readability if changed. > > Signed-off-by: Philipp Guendisch >

Re: [PATCH 1/2] staging: atomisp2: hmm: Fixed comment style

On Mon, Jul 10, 2017 at 08:56:20PM +0200, Philipp Guendisch wrote: > This patch fixed comment style. Semantic should not be affected. > There are also two warnings left about too long lines, which > reduce readability if changed. > > Signed-off-by: Philipp Guendisch > Signed-off-by: Chris Baller

Re: [PATCH] 9p: hide cachetag option for non-CONFIG_9P_FSCACHE

Arnd Bergmann wrote: > show_options cannot print this option when it is disabled in Kconfig: > > fs/9p/v9fs.c: In function 'v9fs_show_options': > fs/9p/v9fs.c:140:13: error: 'struct v9fs_session_info' has no member named > 'cachetag'; did you mean 'cache'? > > Fixes:

Re: [PATCH] 9p: hide cachetag option for non-CONFIG_9P_FSCACHE

Arnd Bergmann wrote: > show_options cannot print this option when it is disabled in Kconfig: > > fs/9p/v9fs.c: In function 'v9fs_show_options': > fs/9p/v9fs.c:140:13: error: 'struct v9fs_session_info' has no member named > 'cachetag'; did you mean 'cache'? > > Fixes: ccb0055985b9 ("9p:

[PATCH V3 1/2] PCI: Add Extended Tags quirk for Broadcom HT2100 Root Port

All PCIe devices are expected to be able to handle 8-bit tags. 'commit 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")' enabled extended tags for all devices based on the spec direction. The Broadcom HT2100 seems to be having issues with handling 8-bit tags. Mark it as broken.

[PATCH V3 2/2] PCI: Do not enable extended tags if a quirky device is found

According to extended tags ECN document, all PCIe receivers are expected to support extended tags. However, devices with exceptions/quirks were found. If a device with extended tags quirk is found, disable extended tags for all devices in the tree assuming peer-to-peer is possible. Also note that

[PATCH V3 2/2] PCI: Do not enable extended tags if a quirky device is found

According to extended tags ECN document, all PCIe receivers are expected to support extended tags. However, devices with exceptions/quirks were found. If a device with extended tags quirk is found, disable extended tags for all devices in the tree assuming peer-to-peer is possible. Also note that

[PATCH V3 1/2] PCI: Add Extended Tags quirk for Broadcom HT2100 Root Port

All PCIe devices are expected to be able to handle 8-bit tags. 'commit 60db3a4d8cc9 ("PCI: Enable PCIe Extended Tags if supported")' enabled extended tags for all devices based on the spec direction. The Broadcom HT2100 seems to be having issues with handling 8-bit tags. Mark it as broken.

Re: [PATCH V3] perf/x86/intel/uncore: remove nonexistent clockticks event for client uncore

> User observable change with the patch. > clockticks event is removed from CBOX. User may need to change their > script to use uncore_clock/clockticks/ instead. I don't think we can do that and break everyone's scripts. Have to keep the old behavior, even though it is not ideal. Or you fix the

Re: [PATCH V3] perf/x86/intel/uncore: remove nonexistent clockticks event for client uncore

> User observable change with the patch. > clockticks event is removed from CBOX. User may need to change their > script to use uncore_clock/clockticks/ instead. I don't think we can do that and break everyone's scripts. Have to keep the old behavior, even though it is not ideal. Or you fix the

[PATCH] leds: leds-aat1290.c: enclosed arithmetic expression macro

Fixed the unenclosed complex values macro issue generated by scripts/checkpatch.pl: ERROR: Macros with complex values should be enclosed in parentheses Signed-off-by: Lynn Lei --- drivers/leds/leds-aat1290.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] leds: leds-aat1290.c: enclosed arithmetic expression macro

Fixed the unenclosed complex values macro issue generated by scripts/checkpatch.pl: ERROR: Macros with complex values should be enclosed in parentheses Signed-off-by: Lynn Lei --- drivers/leds/leds-aat1290.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] watchdog: w83627hf: make const array chip_name static

From: Colin Ian King Don't populate array chip_name on the stack but instead make it static. Makes the object code smaller by 40 bytes: Before: textdata bss dec hex filename 56412840 384886522a1 drivers/watchdog/w83627hf_wdt.o

[PATCH] watchdog: w83627hf: make const array chip_name static

From: Colin Ian King Don't populate array chip_name on the stack but instead make it static. Makes the object code smaller by 40 bytes: Before: textdata bss dec hex filename 56412840 384886522a1 drivers/watchdog/w83627hf_wdt.o After: textdata

[PATCH] isofs: Fix isofs_show_options()

Hi Al, The isofs patch needs a small fix to handle a signed/unsigned comparison that the compiler didn't flag - thanks to Dan for catching it. It should be noted, however, as mentioned in a previous email, the session number handing appears to be incorrect between where it is parsed and where it

[PATCH] isofs: Fix isofs_show_options()

Hi Al, The isofs patch needs a small fix to handle a signed/unsigned comparison that the compiler didn't flag - thanks to Dan for catching it. It should be noted, however, as mentioned in a previous email, the session number handing appears to be incorrect between where it is parsed and where it

Re: [PATCH 21/21] x86/intel_rdt/mbm: Handle counter overflow

On Mon, 10 Jul 2017, Luck, Tony wrote: > On Fri, Jul 07, 2017 at 08:50:40AM +0200, Thomas Gleixner wrote: > > Aside of that, are you really serious about serializing the world and > > everything on a single global mutex? > > It would be nice to not do that, but there are challenges. At > any

Re: [PATCH 21/21] x86/intel_rdt/mbm: Handle counter overflow

On Mon, 10 Jul 2017, Luck, Tony wrote: > On Fri, Jul 07, 2017 at 08:50:40AM +0200, Thomas Gleixner wrote: > > Aside of that, are you really serious about serializing the world and > > everything on a single global mutex? > > It would be nice to not do that, but there are challenges. At > any

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, May 30, 2017 at 01:17:41PM -0500, Christoph Lameter wrote: > On Fri, 26 May 2017, Marcelo Tosatti wrote: > > > > interrupts and scheduler ticks. But what does this have to do with vmstat? > > > > > > Show me your dpdk code running and trace the tick on / off events as well > > > as the

Re: [patch 2/2] MM: allow per-cpu vmstat_threshold and vmstat_worker configuration

On Tue, May 30, 2017 at 01:17:41PM -0500, Christoph Lameter wrote: > On Fri, 26 May 2017, Marcelo Tosatti wrote: > > > > interrupts and scheduler ticks. But what does this have to do with vmstat? > > > > > > Show me your dpdk code running and trace the tick on / off events as well > > > as the

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:39, Viresh Kumar wrote: > On 10-07-17, 14:46, Rafael J. Wysocki wrote: >> This particular change is about a new feature, so making it in the core is OK >> in two cases IMO: (a) when you actively want everyone to be affected by it >> and > > IMO this change should be done for the

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:39, Viresh Kumar wrote: > On 10-07-17, 14:46, Rafael J. Wysocki wrote: >> This particular change is about a new feature, so making it in the core is OK >> in two cases IMO: (a) when you actively want everyone to be affected by it >> and > > IMO this change should be done for the

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

On Tue, 2017-07-11 at 18:05 +0300, Paul Kocialkowski wrote: > On Tue, 2017-07-11 at 14:54 +, Marcel Ziswiler wrote: > > On Tue, 2017-07-11 at 11:50 +0300, Paul Kocialkowski wrote: > > > On Sun, 2017-07-09 at 19:36 +0300, Paul Kocialkowski wrote: > > > > This registers the host1x node with the

[GIT PULL REQUEST] watchdog - v4.13-rc1 Merge Window

Hi Linus, Please pull from 'master' branch of git://www.linux-watchdog.org/linux-watchdog.git It contains the following: * Add Renesas RZ/A WDT Watchdog driver * STM32 Independent WatchDoG (IWDG) support * UniPhier watchdog support * Add F71868 support * Add support for NCT6793D and

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

On Tue, 2017-07-11 at 18:05 +0300, Paul Kocialkowski wrote: > On Tue, 2017-07-11 at 14:54 +, Marcel Ziswiler wrote: > > On Tue, 2017-07-11 at 11:50 +0300, Paul Kocialkowski wrote: > > > On Sun, 2017-07-09 at 19:36 +0300, Paul Kocialkowski wrote: > > > > This registers the host1x node with the

[GIT PULL REQUEST] watchdog - v4.13-rc1 Merge Window

Hi Linus, Please pull from 'master' branch of git://www.linux-watchdog.org/linux-watchdog.git It contains the following: * Add Renesas RZ/A WDT Watchdog driver * STM32 Independent WatchDoG (IWDG) support * UniPhier watchdog support * Add F71868 support * Add support for NCT6793D and

Re: [PATCH] cpu_pm: replace raw_notifier to atomic_notifier

On 2017-07-11 17:01:09 [+0200], Rafael J. Wysocki wrote: > > As far as RT is concerned, I am taking this for the next v4.11 release. > > I would appreciate if upstream would apply this as well. > > Rafael do you feel responsible for this? > > I can apply this if no one else wants to. :-) prosze.

Re: [PATCH] cpu_pm: replace raw_notifier to atomic_notifier

On 2017-07-11 17:01:09 [+0200], Rafael J. Wysocki wrote: > > As far as RT is concerned, I am taking this for the next v4.11 release. > > I would appreciate if upstream would apply this as well. > > Rafael do you feel responsible for this? > > I can apply this if no one else wants to. :-) prosze.

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On 7/11/2017 12:56 AM, Borislav Petkov wrote: On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote: If I make the scattered feature support conditional on CONFIG_X86_64 (based on comment below) then cpu_has() will always be false unless CONFIG_X86_64 is enabled. So this won't need to be

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On 7/11/2017 12:56 AM, Borislav Petkov wrote: On Tue, Jul 11, 2017 at 01:07:46AM -0400, Brian Gerst wrote: If I make the scattered feature support conditional on CONFIG_X86_64 (based on comment below) then cpu_has() will always be false unless CONFIG_X86_64 is enabled. So this won't need to be

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:06 PM, Andy Lutomirski wrote: > On Tue, Jul 11, 2017 at 3:35 AM, Kirill A. Shutemov > wrote: >> On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote: >>> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov >>> wrote:

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On 07/11/2017 06:06 PM, Andy Lutomirski wrote: > On Tue, Jul 11, 2017 at 3:35 AM, Kirill A. Shutemov > wrote: >> On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote: >>> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov >>> wrote: On Mon, Jul 10, 2017 at 01:07:13PM -0700,

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: >>> > be even better if you could calculate whether the mode is valid, but I >>> > didn't >>> > spend enough time to figure out if this is possible. >>> >>> Theoretically that might be possible, checking if the requested

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote: >>> > be even better if you could calculate whether the mode is valid, but I >>> > didn't >>> > spend enough time to figure out if this is possible. >>> >>> Theoretically that might be possible, checking if the requested freq >>> matches the

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On 7/11/2017 12:07 AM, Brian Gerst wrote: On Mon, Jul 10, 2017 at 3:41 PM, Tom Lendacky wrote: On 7/8/2017 7:50 AM, Brian Gerst wrote: On Fri, Jul 7, 2017 at 9:38 AM, Tom Lendacky wrote: Update the CPU features to include identifying and

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 15:59, Rafael J. Wysocki wrote: > On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: >> On 11/07/17 07:01, Viresh Kumar wrote: >>> On 10-07-17, 13:02, Dietmar Eggemann wrote: Yes, I will change this. The #define approach is not really necessary here since we're not

Re: [PATCH v9 04/38] x86/CPU/AMD: Add the Secure Memory Encryption CPU feature

On 7/11/2017 12:07 AM, Brian Gerst wrote: On Mon, Jul 10, 2017 at 3:41 PM, Tom Lendacky wrote: On 7/8/2017 7:50 AM, Brian Gerst wrote: On Fri, Jul 7, 2017 at 9:38 AM, Tom Lendacky wrote: Update the CPU features to include identifying and reporting on the Secure Memory Encryption (SME)

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 15:59, Rafael J. Wysocki wrote: > On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: >> On 11/07/17 07:01, Viresh Kumar wrote: >>> On 10-07-17, 13:02, Dietmar Eggemann wrote: Yes, I will change this. The #define approach is not really necessary here since we're not

Re: [PATCH 0/2] Fatal signal handing within uaccess faults

On Tue, Jul 11, 2017 at 08:04:50AM -0700, Andy Lutomirski wrote: > On Tue, Jul 11, 2017 at 7:16 AM, Mark Rutland wrote: > > Hi, > > > > Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals > > correctly, allowing unprivileged users to create an unkillable

Re: [PATCH 0/2] Fatal signal handing within uaccess faults

On Tue, Jul 11, 2017 at 08:04:50AM -0700, Andy Lutomirski wrote: > On Tue, Jul 11, 2017 at 7:16 AM, Mark Rutland wrote: > > Hi, > > > > Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals > > correctly, allowing unprivileged users to create an unkillable task which > > can >

[PATCH] staging: ccree: move FIPS support to kernel infrastructure

The ccree driver had its own FIPS support, complete with a test harness comparable to crypto testmgr and an implementation which disables crypto functionality on FIPS test error detection, either in Linux or from TEE. This patch removes the duplication, while reimplementing the handling of TEE

[PATCH] staging: ccree: move FIPS support to kernel infrastructure

The ccree driver had its own FIPS support, complete with a test harness comparable to crypto testmgr and an implementation which disables crypto functionality on FIPS test error detection, either in Linux or from TEE. This patch removes the duplication, while reimplementing the handling of TEE

Re: [PATCH] cpu_pm: replace raw_notifier to atomic_notifier

On Tuesday, July 11, 2017 05:06:35 PM Sebastian Andrzej Siewior wrote: > On 2017-07-11 22:42:04 [+0800], Alex Shi wrote: > > It is a serious bug: add a waiting lock in idle and cause boot failure > > in arm/arm64 RT. > > > > Any more comments for this change? > > As far as RT is concerned, I am

Re: [PATCH] cpu_pm: replace raw_notifier to atomic_notifier

On Tuesday, July 11, 2017 05:06:35 PM Sebastian Andrzej Siewior wrote: > On 2017-07-11 22:42:04 [+0800], Alex Shi wrote: > > It is a serious bug: add a waiting lock in idle and cause boot failure > > in arm/arm64 RT. > > > > Any more comments for this change? > > As far as RT is concerned, I am

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On Tue, Jul 11, 2017 at 3:35 AM, Kirill A. Shutemov wrote: > On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote: >> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov >> wrote: >> > On Mon, Jul 10, 2017 at 01:07:13PM -0700, Andy

Re: KASAN vs. boot-time switching between 4- and 5-level paging

On Tue, Jul 11, 2017 at 3:35 AM, Kirill A. Shutemov wrote: > On Mon, Jul 10, 2017 at 05:30:38PM -0700, Andy Lutomirski wrote: >> On Mon, Jul 10, 2017 at 2:24 PM, Kirill A. Shutemov >> wrote: >> > On Mon, Jul 10, 2017 at 01:07:13PM -0700, Andy Lutomirski wrote: >> >> Can you give the disassembly

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: > On 11/07/17 07:01, Viresh Kumar wrote: > > On 10-07-17, 13:02, Dietmar Eggemann wrote: > >> Yes, I will change this. The #define approach is not really necessary > >> here since we're not in the scheduler hot-path and inlining is not

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On Tuesday, July 11, 2017 04:06:01 PM Dietmar Eggemann wrote: > On 11/07/17 07:01, Viresh Kumar wrote: > > On 10-07-17, 13:02, Dietmar Eggemann wrote: > >> Yes, I will change this. The #define approach is not really necessary > >> here since we're not in the scheduler hot-path and inlining is not

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Thomas Gleixner wrote: > On Tue, 11 Jul 2017, Tony Lindgren wrote: > > * Thomas Gleixner [170711 02:48]: > > And "external abort on non-linefetch" means something is not clocked > > in this case. The following alone makes things boot for me again, but I >

Re: [GIT pull] irq updates for 4.13

On Tue, 11 Jul 2017, Thomas Gleixner wrote: > On Tue, 11 Jul 2017, Tony Lindgren wrote: > > * Thomas Gleixner [170711 02:48]: > > And "external abort on non-linefetch" means something is not clocked > > in this case. The following alone makes things boot for me again, but I > > don't > > quite

Re: [PATCH] cpu_pm: replace raw_notifier to atomic_notifier

On 2017-07-11 22:42:04 [+0800], Alex Shi wrote: > It is a serious bug: add a waiting lock in idle and cause boot failure > in arm/arm64 RT. > > Any more comments for this change? As far as RT is concerned, I am taking this for the next v4.11 release. I would appreciate if upstream would apply

Re: [PATCH] cpu_pm: replace raw_notifier to atomic_notifier

On 2017-07-11 22:42:04 [+0800], Alex Shi wrote: > It is a serious bug: add a waiting lock in idle and cause boot failure > in arm/arm64 RT. > > Any more comments for this change? As far as RT is concerned, I am taking this for the next v4.11 release. I would appreciate if upstream would apply

[PATCH v2] xattr: Enable security.capability in user namespaces

From: Stefan Berger This patch enables security.capability in user namespaces but also takes a more general approach to enabling extended attributes in user namespaces. The following rules describe the approach using security.foo as a 'user namespace enabled'

[PATCH v2] xattr: Enable security.capability in user namespaces

From: Stefan Berger This patch enables security.capability in user namespaces but also takes a more general approach to enabling extended attributes in user namespaces. The following rules describe the approach using security.foo as a 'user namespace enabled' extended attribute: Reading of

Re: [PATCH 1/5] mm/persistent-memory: match IORES_DESC name and enum memory_type one

On Tue, Jul 11, 2017 at 12:31:22AM -0700, Dan Williams wrote: > On Wed, Jul 5, 2017 at 11:49 AM, Jerome Glisse wrote: > > On Wed, Jul 05, 2017 at 09:15:35AM -0700, Dan Williams wrote: > >> On Wed, Jul 5, 2017 at 7:25 AM, Jerome Glisse wrote: > >> > On Mon,

Re: [PATCH 1/5] mm/persistent-memory: match IORES_DESC name and enum memory_type one

On Tue, Jul 11, 2017 at 12:31:22AM -0700, Dan Williams wrote: > On Wed, Jul 5, 2017 at 11:49 AM, Jerome Glisse wrote: > > On Wed, Jul 05, 2017 at 09:15:35AM -0700, Dan Williams wrote: > >> On Wed, Jul 5, 2017 at 7:25 AM, Jerome Glisse wrote: > >> > On Mon, Jul 03, 2017 at 04:49:18PM -0700, Dan

[PATCH v2] Enable namespaced file capabilities

From: Stefan Berger The primary goal of the following patch is to enable file capabilities in user namespaces without affecting the file capabilities that are effective on the host. This is to prevent that any unprivileged user on the host maps his own uid to root in

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

On Tue, 2017-07-11 at 14:54 +, Marcel Ziswiler wrote: > On Tue, 2017-07-11 at 11:50 +0300, Paul Kocialkowski wrote: > > On Sun, 2017-07-09 at 19:36 +0300, Paul Kocialkowski wrote: > > > This registers the host1x node with the SMMU (as HC swgroup) to > > > allow > > > the host1x code to attach

[PATCH v2] Enable namespaced file capabilities

From: Stefan Berger The primary goal of the following patch is to enable file capabilities in user namespaces without affecting the file capabilities that are effective on the host. This is to prevent that any unprivileged user on the host maps his own uid to root in a private namespace, writes

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

On Tue, 2017-07-11 at 14:54 +, Marcel Ziswiler wrote: > On Tue, 2017-07-11 at 11:50 +0300, Paul Kocialkowski wrote: > > On Sun, 2017-07-09 at 19:36 +0300, Paul Kocialkowski wrote: > > > This registers the host1x node with the SMMU (as HC swgroup) to > > > allow > > > the host1x code to attach

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:01, Viresh Kumar wrote: > On 10-07-17, 13:02, Dietmar Eggemann wrote: >> Yes, I will change this. The #define approach is not really necessary >> here since we're not in the scheduler hot-path and inlining is not >> really required here. > > It would be part of scheduler hot-path

Re: [PATCH v2 02/10] cpufreq: provide data for frequency-invariant load-tracking support

On 11/07/17 07:01, Viresh Kumar wrote: > On 10-07-17, 13:02, Dietmar Eggemann wrote: >> Yes, I will change this. The #define approach is not really necessary >> here since we're not in the scheduler hot-path and inlining is not >> really required here. > > It would be part of scheduler hot-path

Re: [PATCH 0/2] Fatal signal handing within uaccess faults

On Tue, Jul 11, 2017 at 7:16 AM, Mark Rutland wrote: > Hi, > > Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals > correctly, allowing unprivileged users to create an unkillable task which can > lock up the system. Please check whether your arch is

Re: [PATCH 0/2] Fatal signal handing within uaccess faults

On Tue, Jul 11, 2017 at 7:16 AM, Mark Rutland wrote: > Hi, > > Arch maintainer tl;dr: most arch fault code doesn't handle fatal signals > correctly, allowing unprivileged users to create an unkillable task which can > lock up the system. Please check whether your arch is affected. I haven't

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 12:56 AM, Daniel Vetter wrote: > On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote: >> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote: >> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: >> >> Currently the

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Tue, Jul 11, 2017 at 12:56 AM, Daniel Vetter wrote: > On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote: >> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote: >> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: >> >> Currently the hikey dsi logic cannot generate

Re: [PATCH v5 5/5] intel_idle: Add S0ix validation

On Monday, July 10, 2017 03:24:14 PM dbasehore . wrote: > On Mon, Jul 10, 2017 at 3:09 PM, Rafael J. Wysocki wrote: > > On Monday, July 10, 2017 02:57:48 PM dbasehore . wrote: > >> On Mon, Jul 10, 2017 at 6:33 AM, Rafael J. Wysocki > >> wrote: > >> > On

Re: [PATCH v5 5/5] intel_idle: Add S0ix validation

On Monday, July 10, 2017 03:24:14 PM dbasehore . wrote: > On Mon, Jul 10, 2017 at 3:09 PM, Rafael J. Wysocki wrote: > > On Monday, July 10, 2017 02:57:48 PM dbasehore . wrote: > >> On Mon, Jul 10, 2017 at 6:33 AM, Rafael J. Wysocki > >> wrote: > >> > On Friday, July 07, 2017 05:03:03 PM Derek

RE: HELLO

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your

RE: HELLO

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your

Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On 7/10/2017 11:58 PM, Brian Gerst wrote: On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote: On 7/8/2017 7:57 AM, Brian Gerst wrote: On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky wrote: Currently there is a check if the address being

Re: [PATCH v9 07/38] x86/mm: Remove phys_to_virt() usage in ioremap()

On 7/10/2017 11:58 PM, Brian Gerst wrote: On Mon, Jul 10, 2017 at 3:50 PM, Tom Lendacky wrote: On 7/8/2017 7:57 AM, Brian Gerst wrote: On Fri, Jul 7, 2017 at 9:39 AM, Tom Lendacky wrote: Currently there is a check if the address being mapped is in the ISA range (is_ISA_range()), and if it

RE: HELLO

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your

RE: HELLO

I am Ms.Ella Golan, I am the Executive Vice President Banking Division with FIRST INTERNATIONAL BANK OF ISRAEL LTD (FIBI). I am getting in touch with you regarding an extremely important and urgent matter. If you would oblige me the opportunity, I shall provide you with details upon your

Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

Thanks for your comments. > What I think Rafał is saying is that it would be better to have this > code in cfg80211 so other drivers including mac80211 could use it. While I agree that moving all wireless LED triggers to cfg80211 would be an ideal situation, it seems a bit out of scope for what

Re: [PATCH v4 00/10] PCID and improved laziness

On Tue, Jul 11, 2017 at 4:32 AM, Matt Fleming wrote: > 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. >> >

Re: [PATCH] brcmfmac: added LED triggers for transmit/receive

Thanks for your comments. > What I think Rafał is saying is that it would be better to have this > code in cfg80211 so other drivers including mac80211 could use it. While I agree that moving all wireless LED triggers to cfg80211 would be an ideal situation, it seems a bit out of scope for what

Re: [PATCH v4 00/10] PCID and improved laziness

On Tue, Jul 11, 2017 at 4:32 AM, Matt Fleming wrote: > 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

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > When there's a fatal signal pending, arm64's do_page_fault() > implementation returns 0. The intent is that we'll return to the > faulting userspace instruction, delivering the signal on the way. > > However, if we take a fatal

Re: [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > When there's a fatal signal pending, arm64's do_page_fault() > implementation returns 0. The intent is that we'll return to the > faulting userspace instruction, delivering the signal on the way. > > However, if we take a fatal

Re: [PATCH 2/5] mm/device-public-memory: device memory cache coherent with CPU v2

On Tue, Jul 11, 2017 at 02:12:15PM +1000, Balbir Singh wrote: > On Mon, 3 Jul 2017 17:14:12 -0400 > Jérôme Glisse wrote: > > > Platform with advance system bus (like CAPI or CCIX) allow device > > memory to be accessible from CPU in a cache coherent fashion. Add > > a new

Re: [PATCH 2/5] mm/device-public-memory: device memory cache coherent with CPU v2

On Tue, Jul 11, 2017 at 02:12:15PM +1000, Balbir Singh wrote: > On Mon, 3 Jul 2017 17:14:12 -0400 > Jérôme Glisse wrote: > > > Platform with advance system bus (like CAPI or CCIX) allow device > > memory to be accessible from CPU in a cache coherent fashion. Add > > a new type of ZONE_DEVICE to

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

On Tue, 2017-07-11 at 11:50 +0300, Paul Kocialkowski wrote: > On Sun, 2017-07-09 at 19:36 +0300, Paul Kocialkowski wrote: > > This registers the host1x node with the SMMU (as HC swgroup) to > > allow > > the host1x code to attach to it. It avoid failing the probe > > sequence, > > which resulted

Re: [PATCH] ARM: tegra: Register host1x node with iommu binding on tegra124

On Tue, 2017-07-11 at 11:50 +0300, Paul Kocialkowski wrote: > On Sun, 2017-07-09 at 19:36 +0300, Paul Kocialkowski wrote: > > This registers the host1x node with the SMMU (as HC swgroup) to > > allow > > the host1x code to attach to it. It avoid failing the probe > > sequence, > > which resulted

Re: [RFC v5 00/38] powerpc: Memory Protection Keys

On Wed 05-07-17 14:21:37, Ram Pai wrote: > Memory protection keys enable applications to protect its > address space from inadvertent access or corruption from > itself. > > The overall idea: > > A process allocates a key and associates it with > an address range withinits address

Re: [RFC v5 00/38] powerpc: Memory Protection Keys

On Wed 05-07-17 14:21:37, Ram Pai wrote: > Memory protection keys enable applications to protect its > address space from inadvertent access or corruption from > itself. > > The overall idea: > > A process allocates a key and associates it with > an address range withinits address

Re: [PATCH linux-next v4 4/4] spi: imx: Add support for SPI Slave mode

On Thu, Jun 08, 2017 at 02:16:03PM +0900, Jiada Wang wrote: > Previously i.MX SPI controller only works in Master mode. > This patch adds support to i.MX51, i.MX53 and i.MX6 ECSPI > controller to work also in Slave mode. This doesn't apply against current code, please check and resend.

Re: [PATCH linux-next v4 4/4] spi: imx: Add support for SPI Slave mode

On Thu, Jun 08, 2017 at 02:16:03PM +0900, Jiada Wang wrote: > Previously i.MX SPI controller only works in Master mode. > This patch adds support to i.MX51, i.MX53 and i.MX6 ECSPI > controller to work also in Slave mode. This doesn't apply against current code, please check and resend.

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