Re: [PATCH 0/7] objtool: retpoline validation

On 02/01/2018 08:51 AM, David Woodhouse wrote: > > No, we just need to set IBRS before doing it. The same applies to any > EFI runtime calls, APM and all kinds of other random crap that calls > into firmware. I'm not sure why those aren't showing up. > Dave, Are you planning to update your

[RFC v6 2/5] drm/nouveau: Add support for BLCG on Kepler1

This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On Mon, Jan 29, 2018 at 07:31:07PM +, Valentin Schneider wrote: > But for load update via _nohz_idle_balance(), we iterate through all of the > nohz CPUS and unconditionally call update_blocked_averages(). This could be > avoided by remembering which CPUs have stale load before going idle. >

[RFC v6 1/5] drm/nouveau: Add support for basic clockgating on Kepler1

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling

Re: [PATCH 0/7] objtool: retpoline validation

On 02/01/2018 08:51 AM, David Woodhouse wrote: > > No, we just need to set IBRS before doing it. The same applies to any > EFI runtime calls, APM and all kinds of other random crap that calls > into firmware. I'm not sure why those aren't showing up. > Dave, Are you planning to update your

[RFC v6 2/5] drm/nouveau: Add support for BLCG on Kepler1

This enables BLCG optimization for kepler1. When using clockgating, nvidia's firmware has a set of registers which are initially programmed by the vbios with various engine delays and other mysterious settings that are safe enough to bring up the GPU. However, the values used by the vbios are more

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On Mon, Jan 29, 2018 at 07:31:07PM +, Valentin Schneider wrote: > But for load update via _nohz_idle_balance(), we iterate through all of the > nohz CPUS and unconditionally call update_blocked_averages(). This could be > avoided by remembering which CPUs have stale load before going idle. >

[RFC v6 1/5] drm/nouveau: Add support for basic clockgating on Kepler1

This adds support for enabling automatic clockgating on nvidia GPUs for Kepler1. While this is not technically a clockgating level, it does enable clockgating using the clockgating values initially set by the vbios (which should be safe to use). This introduces two therm helpers for controlling

[RFC v6 3/5] drm/nouveau: Add support for BLCG on Kepler2

Same as the previous patch, but for Kepler2 now Signed-off-by: Lyude Paul Reviewed-by: Martin Peres --- drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +--

[PATCH 1/2 v5] lib: debugobjects: export max loops counter

Currently max chain counter is exported to debugfs, it just record the counter of inner loop, however, there might be significant iterations of external loop then it may take significant amount of time to finish all of the checks. This may cause lockup on !CONFIG_PREEMPT kernel build occasionally.

[PATCH 2/2 v5] lib: debugobjects: handle objects free in a batch outside the loop

There are nested loops on debug objects free path, sometimes it may take over hundred thousands of loops, then cause soft lockup with !CONFIG_PREEMPT occasionally, like below: NMI watchdog: BUG: soft lockup - CPU#15 stuck for 22s! [stress-ng-getde:110342] CPU: 15 PID: 110342 Comm:

[RFC v6 3/5] drm/nouveau: Add support for BLCG on Kepler2

Same as the previous patch, but for Kepler2 now Signed-off-by: Lyude Paul Reviewed-by: Martin Peres --- drivers/gpu/drm/nouveau/include/nvkm/subdev/fb.h | 1 + drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 8 +-- drivers/gpu/drm/nouveau/nvkm/engine/gr/gk110.c| 62

[PATCH 1/2 v5] lib: debugobjects: export max loops counter

Currently max chain counter is exported to debugfs, it just record the counter of inner loop, however, there might be significant iterations of external loop then it may take significant amount of time to finish all of the checks. This may cause lockup on !CONFIG_PREEMPT kernel build occasionally.

[PATCH 2/2 v5] lib: debugobjects: handle objects free in a batch outside the loop

There are nested loops on debug objects free path, sometimes it may take over hundred thousands of loops, then cause soft lockup with !CONFIG_PREEMPT occasionally, like below: NMI watchdog: BUG: soft lockup - CPU#15 stuck for 22s! [stress-ng-getde:110342] CPU: 15 PID: 110342 Comm:

Re: [RFCv2 05/17] media: Document the media request API

On 01/31/2018 02:24 AM, Alexandre Courbot wrote: > From: Laurent Pinchart > > The media request API is made of a new ioctl to implement request > management. Document it. > > Signed-off-by: Laurent Pinchart >

Re: [RFCv2 05/17] media: Document the media request API

On 01/31/2018 02:24 AM, Alexandre Courbot wrote: > From: Laurent Pinchart > > The media request API is made of a new ioctl to implement request > management. Document it. > > Signed-off-by: Laurent Pinchart > [acour...@chromium.org: adapt for newest API] > Signed-off-by: Alexandre Courbot >

Re: [PATCH v2] Documentation/process: kernel maintainer PGP guide

On Thu, 1 Feb 2018 09:42:33 -0500 Konstantin Ryabitsev wrote: > This guide is an adapted version of the more general "Protecting Code > Integrity" guide written and maintained by The Linux Foundation IT for > use with open-source projects. It provides the

[RFC v6 0/5] Implement full clockgating for Kepler1 and 2

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ Some small changes (shouldn't change anything functionally): - Made gf100_therm_new,

Re: [PATCH v2] Documentation/process: kernel maintainer PGP guide

On Thu, 1 Feb 2018 09:42:33 -0500 Konstantin Ryabitsev wrote: > This guide is an adapted version of the more general "Protecting Code > Integrity" guide written and maintained by The Linux Foundation IT for > use with open-source projects. It provides the oft-lacking guidance on > the following

[RFC v6 0/5] Implement full clockgating for Kepler1 and 2

Next version of my patchseries for adding clockgating support for kepler1 and 2 on nouveau. The first version of this series can be found here: https://patchwork.freedesktop.org/series/36504/ Some small changes (shouldn't change anything functionally): - Made gf100_therm_new,

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On Wed, Jan 24, 2018 at 09:25:36AM +0100, Vincent Guittot wrote: > @@ -8861,7 +8875,14 @@ static int idle_balance(struct rq *this_rq, struct > rq_flags *rf) > update_next_balance(sd, _balance); > rcu_read_unlock(); > > - if (time_after(jiffies,

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On Wed, Jan 24, 2018 at 09:25:36AM +0100, Vincent Guittot wrote: > @@ -8861,7 +8875,14 @@ static int idle_balance(struct rq *this_rq, struct > rq_flags *rf) > update_next_balance(sd, _balance); > rcu_read_unlock(); > > - if (time_after(jiffies,

Re: [PATCH] KVM: x86: fix backward migration with async_PF

On 01/02/2018 12:50, Radim Krčmář wrote: > Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT > bit when enabling async_PF, but this bit is reserved on old hypervisors, > which results in a failure upon migration. > > Guests at least expect that

Re: [PATCH] KVM: x86: fix backward migration with async_PF

On 01/02/2018 12:50, Radim Krčmář wrote: > Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT > bit when enabling async_PF, but this bit is reserved on old hypervisors, > which results in a failure upon migration. > > Guests at least expect that

Re: possible deadlock in do_ip_getsockopt

syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > c4e0ca7fa24137e372d6135fe16e8df8e123f116 (Fri Jan 26 23:10:50 2018 +) > Merge tag 'riscv-for-linus-4.15-maintainers' of >

Re: possible deadlock in do_ip_getsockopt

syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > c4e0ca7fa24137e372d6135fe16e8df8e123f116 (Fri Jan 26 23:10:50 2018 +) > Merge tag 'riscv-for-linus-4.15-maintainers' of > git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux > > So far this crash

[git pull] Input updates for v4.16-rc0

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - evdev interface has been adjusted to extend the life of timestamps on 32 bit systems to the year of 2108 - Synaptics RMI4

[git pull] Input updates for v4.16-rc0

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get: - evdev interface has been adjusted to extend the life of timestamps on 32 bit systems to the year of 2108 - Synaptics RMI4

Re: clang warning: implicit conversion in intel_ddi.c:1481

On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote: > Dear Rodrigo Vivi, Ville Syrjälä, > > My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We > intend to use static analysis tools on the kernel source to identify, > analyze and report issues. As a very first step,

Re: clang warning: implicit conversion in intel_ddi.c:1481

On Thu, Feb 01, 2018 at 06:33:30PM +0100, Ozan Alpay wrote: > Dear Rodrigo Vivi, Ville Syrjälä, > > My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We > intend to use static analysis tools on the kernel source to identify, > analyze and report issues. As a very first step,

[PATCH v11 08/10] mm: Clear arch specific VM flags on protection change

When protection bits are changed on a VMA, some of the architecture specific flags should be cleared as well. An examples of this are the PKEY flags on x86. This patch expands the current code that clears PKEY flags for x86, to support similar functionality for other architectures as well.

[PATCH v11 09/10] mm: Allow arch code to override copy_highpage()

Some architectures can support metadata for memory pages and when a page is copied, its metadata must also be copied. Sparc processors from M7 onwards support metadata for memory pages. This metadata provides tag based protection for access to memory pages. To maintain this protection, the tag

[PATCH v11 08/10] mm: Clear arch specific VM flags on protection change

When protection bits are changed on a VMA, some of the architecture specific flags should be cleared as well. An examples of this are the PKEY flags on x86. This patch expands the current code that clears PKEY flags for x86, to support similar functionality for other architectures as well.

[PATCH v11 09/10] mm: Allow arch code to override copy_highpage()

Some architectures can support metadata for memory pages and when a page is copied, its metadata must also be copied. Sparc processors from M7 onwards support metadata for memory pages. This metadata provides tag based protection for access to memory pages. To maintain this protection, the tag

[PATCH v11 10/10] sparc64: Add support for ADI (Application Data Integrity)

ADI is a new feature supported on SPARC M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data

[PATCH v11 10/10] sparc64: Add support for ADI (Application Data Integrity)

ADI is a new feature supported on SPARC M7 and newer processors to allow hardware to catch rogue accesses to memory. ADI is supported for data fetches only and not instruction fetches. An app can enable ADI on its data pages, set version tags on them and use versioned addresses to access the data

[PATCH v11 04/10] sparc64: Add HV fault type handlers for ADI related faults

ADI (Application Data Integrity) feature on M7 and newer processors adds new fault types for hypervisor - Invalid ASI and MCD disabled. This patch expands data access exception handler to handle these faults. Signed-off-by: Khalid Aziz Cc: Khalid Aziz

[PATCH v11 04/10] sparc64: Add HV fault type handlers for ADI related faults

ADI (Application Data Integrity) feature on M7 and newer processors adds new fault types for hypervisor - Invalid ASI and MCD disabled. This patch expands data access exception handler to handle these faults. Signed-off-by: Khalid Aziz Cc: Khalid Aziz Reviewed-by: Anthony Yznaga --- v7:

[PATCH v11 02/10] mm, swap: Add infrastructure for saving page metadata on swap

If a processor supports special metadata for a page, for example ADI version tags on SPARC M7, this metadata must be saved when the page is swapped out. The same metadata must be restored when the page is swapped back in. This patch adds two new architecture specific functions -

[PATCH v11 02/10] mm, swap: Add infrastructure for saving page metadata on swap

If a processor supports special metadata for a page, for example ADI version tags on SPARC M7, this metadata must be saved when the page is swapped out. The same metadata must be restored when the page is swapped back in. This patch adds two new architecture specific functions -

[PATCH] ath5k: remove duplicated re-assignment to pointer 'tq'

From: Colin Ian King Pointer tq is initialized with >ah_txq[queue] and then a few lines later is re-assigned the same value, hence this duplicate assignment is redundant and can be removed. Cleans up clang warning: drivers/net/wireless/ath/ath5k/qcu.c:326:25: warning:

[PATCH] ath5k: remove duplicated re-assignment to pointer 'tq'

From: Colin Ian King Pointer tq is initialized with >ah_txq[queue] and then a few lines later is re-assigned the same value, hence this duplicate assignment is redundant and can be removed. Cleans up clang warning: drivers/net/wireless/ath/ath5k/qcu.c:326:25: warning: Value stored to 'tq'

[PATCH v11 07/10] mm: Add address parameter to arch_validate_prot()

A protection flag may not be valid across entire address space and hence arch_validate_prot() might need the address a protection bit is being set on to ensure it is a valid protection flag. For example, sparc processors support memory corruption detection (as part of ADI feature) flag on memory

[PATCH v11 07/10] mm: Add address parameter to arch_validate_prot()

A protection flag may not be valid across entire address space and hence arch_validate_prot() might need the address a protection bit is being set on to ensure it is a valid protection flag. For example, sparc processors support memory corruption detection (as part of ADI feature) flag on memory

[PATCH v11 06/10] sparc64: Add auxiliary vectors to report platform ADI properties

ADI feature on M7 and newer processors has three important properties relevant to userspace apps using ADI capabilities - (1) Size of block of memory an ADI version tag applies to, (2) Number of uppermost bits in virtual address used to encode ADI tag, and (3) The value M7 processor will force the

[PATCH v11 06/10] sparc64: Add auxiliary vectors to report platform ADI properties

ADI feature on M7 and newer processors has three important properties relevant to userspace apps using ADI capabilities - (1) Size of block of memory an ADI version tag applies to, (2) Number of uppermost bits in virtual address used to encode ADI tag, and (3) The value M7 processor will force the

[PATCH v11 03/10] sparc64: Add support for ADI register fields, ASIs and traps

SPARC M7 processor adds new control register fields, ASIs and a new trap to support the ADI (Application Data Integrity) feature. This patch adds definitions for these register fields, ASIs and a handler for the new precise memory corruption detected trap. Signed-off-by: Khalid Aziz

[PATCH v11 03/10] sparc64: Add support for ADI register fields, ASIs and traps

SPARC M7 processor adds new control register fields, ASIs and a new trap to support the ADI (Application Data Integrity) feature. This patch adds definitions for these register fields, ASIs and a handler for the new precise memory corruption detected trap. Signed-off-by: Khalid Aziz Cc: Khalid

[PATCH v11 01/10] signals, sparc: Add signal codes for ADI violations

SPARC M7 processor introduces a new feature - Application Data Integrity (ADI). ADI allows MMU to catch rogue accesses to memory. When a rogue access occurs, MMU blocks the access and raises an exception. In response to the exception, kernel sends the offending task a SIGSEGV with si_code that

[PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

V11 changes: This series is same as v10 and was simply rebased on 4.15 kernel. Can mm maintainers please review patches 2, 7, 8 and 9 which are arch independent, and include/linux/mm.h and mm/ksm.c changes in patch 10 and ack these if everything looks good? SPARC M7 processor adds additional

[PATCH v11 01/10] signals, sparc: Add signal codes for ADI violations

SPARC M7 processor introduces a new feature - Application Data Integrity (ADI). ADI allows MMU to catch rogue accesses to memory. When a rogue access occurs, MMU blocks the access and raises an exception. In response to the exception, kernel sends the offending task a SIGSEGV with si_code that

[PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

V11 changes: This series is same as v10 and was simply rebased on 4.15 kernel. Can mm maintainers please review patches 2, 7, 8 and 9 which are arch independent, and include/linux/mm.h and mm/ksm.c changes in patch 10 and ack these if everything looks good? SPARC M7 processor adds additional

[PATCH 4/5] fs/dcache: Use read_word_at_a_time() in dentry_string_cmp()

dentry_string_cmp() performs the word-at-a-time reads from 'cs' and may read slightly more than it was requested in kmallac(). Normally this would make KASAN to report out-of-bounds access, but this was workarounded by commit df4c0e36f1b1 ("fs: dcache: manually unpoison dname after allocation to

[PATCH 4/5] fs/dcache: Use read_word_at_a_time() in dentry_string_cmp()

dentry_string_cmp() performs the word-at-a-time reads from 'cs' and may read slightly more than it was requested in kmallac(). Normally this would make KASAN to report out-of-bounds access, but this was workarounded by commit df4c0e36f1b1 ("fs: dcache: manually unpoison dname after allocation to

[PATCH 5/5] fs: dcache: Revert "manually unpoison dname after allocation to shut up kasan's reports"

This reverts commit df4c0e36f1b1782b0611a77c52cc240e5c4752dd. It's no longer needed since dentry_string_cmp() now uses read_word_at_a_time() to avoid kasan's reports. Signed-off-by: Andrey Ryabinin --- fs/dcache.c | 5 - 1 file changed, 5 deletions(-) diff --git

[PATCH v11 05/10] sparc64: Add handler for "Memory Corruption Detected" trap

M7 and newer processors add a "Memory corruption Detected" trap with the addition of ADI feature. This trap is vectored into kernel by HV through resumable error trap with error attribute for the resumable error set to 0x0800. Signed-off-by: Khalid Aziz Cc: Khalid

[PATCH 5/5] fs: dcache: Revert "manually unpoison dname after allocation to shut up kasan's reports"

This reverts commit df4c0e36f1b1782b0611a77c52cc240e5c4752dd. It's no longer needed since dentry_string_cmp() now uses read_word_at_a_time() to avoid kasan's reports. Signed-off-by: Andrey Ryabinin --- fs/dcache.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/dcache.c b/fs/dcache.c

[PATCH v11 05/10] sparc64: Add handler for "Memory Corruption Detected" trap

M7 and newer processors add a "Memory corruption Detected" trap with the addition of ADI feature. This trap is vectored into kernel by HV through resumable error trap with error attribute for the resumable error set to 0x0800. Signed-off-by: Khalid Aziz Cc: Khalid Aziz Reviewed-by: Anthony

[PATCH 3/5] lib/strscpy: Shut up KASAN false-positives in strscpy()

strscpy() performs the word-at-a-time optimistic reads. So it may may access the memory past the end of the object, which is perfectly fine since strscpy() doesn't use that (past-the-end) data and makes sure the optimistic read won't cross a page boundary. Use new read_word_at_a_time() to shut up

[PATCH 2/5] compiler.h: Add read_word_at_a_time() function.

Sometimes we know that it's safe to do potentially out-of-bounds access because we know it won't cross a page boundary. Still, KASAN will report this as a bug. Add read_word_at_a_time() function which is supposed to be used in such cases. In read_word_at_a_time() KASAN performs relaxed check -

[PATCH 3/5] lib/strscpy: Shut up KASAN false-positives in strscpy()

strscpy() performs the word-at-a-time optimistic reads. So it may may access the memory past the end of the object, which is perfectly fine since strscpy() doesn't use that (past-the-end) data and makes sure the optimistic read won't cross a page boundary. Use new read_word_at_a_time() to shut up

[PATCH 2/5] compiler.h: Add read_word_at_a_time() function.

Sometimes we know that it's safe to do potentially out-of-bounds access because we know it won't cross a page boundary. Still, KASAN will report this as a bug. Add read_word_at_a_time() function which is supposed to be used in such cases. In read_word_at_a_time() KASAN performs relaxed check -

[PATCH 1/5] compiler.h, kasan: Avoid duplicating __read_once_size_nocheck()

Instead of having two identical __read_once_size_nocheck() functions with different attributes, consolidate all the difference in new macro __no_kasan_or_inline and use it. No functional changes. Signed-off-by: Andrey Ryabinin --- include/linux/compiler.h | 14

[PATCH 1/5] compiler.h, kasan: Avoid duplicating __read_once_size_nocheck()

Instead of having two identical __read_once_size_nocheck() functions with different attributes, consolidate all the difference in new macro __no_kasan_or_inline and use it. No functional changes. Signed-off-by: Andrey Ryabinin --- include/linux/compiler.h | 14 ++ 1 file changed, 6

Re: [RFC][PATCH] printk: do not flush printk_safe from irq_work

On Mon, 29 Jan 2018 11:29:18 +0900 Sergey Senozhatsky wrote: > On (01/26/18 16:26), Petr Mladek wrote: > [..] > > First, this delays showing eventually valuable information until > > the preemption is enabled. It might never happen if the system > > is in big

Re: [RFC][PATCH] printk: do not flush printk_safe from irq_work

On Mon, 29 Jan 2018 11:29:18 +0900 Sergey Senozhatsky wrote: > On (01/26/18 16:26), Petr Mladek wrote: > [..] > > First, this delays showing eventually valuable information until > > the preemption is enabled. It might never happen if the system > > is in big troubles. In each case, it might be

[PATCH v2] powerpc: pseries: use of_irq_get helper in request_event_sources_irqs

Instead of calling both of_irq_parse_one and irq_create_of_mapping, call of_irq_get instead which does essentially the same thing. of_irq_get also calls irq_find_host for deferred probe support, but this should be fine as irq_create_of_mapping also calls that internally. This gets us closer to

[PATCH v2] powerpc: pseries: use of_irq_get helper in request_event_sources_irqs

Instead of calling both of_irq_parse_one and irq_create_of_mapping, call of_irq_get instead which does essentially the same thing. of_irq_get also calls irq_find_host for deferred probe support, but this should be fine as irq_create_of_mapping also calls that internally. This gets us closer to

[PATCH] KVM: x86: fix backward migration with async_PF

Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT bit when enabling async_PF, but this bit is reserved on old hypervisors, which results in a failure upon migration. Guests at least expect that KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT might not be present when booting, so we allow

[PATCH] KVM: x86: fix backward migration with async_PF

Guests on new hypersiors might set KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT bit when enabling async_PF, but this bit is reserved on old hypervisors, which results in a failure upon migration. Guests at least expect that KVM_ASYNC_PF_DELIVERY_AS_PF_VMEXIT might not be present when booting, so we allow

Re: [PATCH] Documentation/ABI: update infiniband sysfs interfaces

On 2/1/2018 8:32 AM, Aishwarya Pant wrote: > Add documentation for core and hardware specific infiniband interfaces. > The descriptions have been collected from git commit logs, reading > through code and data sheets. Some drivers have incomplete doc and are > annotated with the comment '[to be

Re: [PATCH] Documentation/ABI: update infiniband sysfs interfaces

On 2/1/2018 8:32 AM, Aishwarya Pant wrote: > Add documentation for core and hardware specific infiniband interfaces. > The descriptions have been collected from git commit logs, reading > through code and data sheets. Some drivers have incomplete doc and are > annotated with the comment '[to be

[GIT PULL] tracing: Updates for 4.16

Linus, Mostly clean ups and small fixes There's not many changes for the tracing system this release. Mostly small clean ups and fixes. The biggest change is to how bprintf works. bprintf is used by trace_printk() to just save the format and args of a printf call, and the formatting is done

[GIT PULL] tracing: Updates for 4.16

Linus, Mostly clean ups and small fixes There's not many changes for the tracing system this release. Mostly small clean ups and fixes. The biggest change is to how bprintf works. bprintf is used by trace_printk() to just save the format and args of a printf call, and the formatting is done

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On 02/01/2018 06:37 PM, KarimAllah Ahmed wrote: On 02/01/2018 02:25 PM, David Woodhouse wrote: On Wed, 2018-01-31 at 23:26 -0500, Konrad Rzeszutek Wilk wrote: diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 6a9f4ec..bfc80ff 100644 --- a/arch/x86/kvm/vmx.c +++

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On 02/01/2018 06:37 PM, KarimAllah Ahmed wrote: On 02/01/2018 02:25 PM, David Woodhouse wrote: On Wed, 2018-01-31 at 23:26 -0500, Konrad Rzeszutek Wilk wrote: diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 6a9f4ec..bfc80ff 100644 --- a/arch/x86/kvm/vmx.c +++

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, Feb 01, 2018 at 06:14:27PM +0100, Peter Zijlstra wrote: > On Thu, Feb 01, 2018 at 04:51:35PM +, David Woodhouse wrote: > > > Ideally we'd have a way to mark the module 'unsafe' or something. > > > > No, we just need to set IBRS before doing it. > > That would work, assuming IBRS is

Re: [PATCH 0/7] objtool: retpoline validation

On Thu, Feb 01, 2018 at 06:14:27PM +0100, Peter Zijlstra wrote: > On Thu, Feb 01, 2018 at 04:51:35PM +, David Woodhouse wrote: > > > Ideally we'd have a way to mark the module 'unsafe' or something. > > > > No, we just need to set IBRS before doing it. > > That would work, assuming IBRS is

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

On 01/29, Jerome Brunet wrote: > On Thu, 2017-12-21 at 18:15 -0800, Stephen Boyd wrote: > > On 12/19, Michael Turquette wrote: > > > Quoting Jerome Brunet (2017-12-01 13:51:50) > > > > This Patchset is related the RFC [0] and the discussion around > > > > CLK_SET_RATE_GATE available here [1] > > >

Re: [PATCH v5 00/10] clk: implement clock rate protection mechanism

On 01/29, Jerome Brunet wrote: > On Thu, 2017-12-21 at 18:15 -0800, Stephen Boyd wrote: > > On 12/19, Michael Turquette wrote: > > > Quoting Jerome Brunet (2017-12-01 13:51:50) > > > > This Patchset is related the RFC [0] and the discussion around > > > > CLK_SET_RATE_GATE available here [1] > > >

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On 02/01/2018 02:25 PM, David Woodhouse wrote: On Wed, 2018-01-31 at 23:26 -0500, Konrad Rzeszutek Wilk wrote: diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 6a9f4ec..bfc80ff 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -594,6 +594,14 @@ struct vcpu_vmx {  

Re: [PATCH v5 4/5] KVM: VMX: Allow direct access to MSR_IA32_SPEC_CTRL

On 02/01/2018 02:25 PM, David Woodhouse wrote: On Wed, 2018-01-31 at 23:26 -0500, Konrad Rzeszutek Wilk wrote: diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c index 6a9f4ec..bfc80ff 100644 --- a/arch/x86/kvm/vmx.c +++ b/arch/x86/kvm/vmx.c @@ -594,6 +594,14 @@ struct vcpu_vmx {  

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

On 1 February 2018 at 09:04, AKASHI Takahiro wrote: > This is a fix against the issue that crash dump kernel may hang up > during booting, which can happen on any ACPI-based system with "ACPI > Reclaim Memory." > > (kernel messages after panic kicked off kdump) >

Re: [PATCH] arm64: acpi,efi: fix alignment fault in accessing ACPI tables at kdump

On 1 February 2018 at 09:04, AKASHI Takahiro wrote: > This is a fix against the issue that crash dump kernel may hang up > during booting, which can happen on any ACPI-based system with "ACPI > Reclaim Memory." > > (kernel messages after panic kicked off kdump) >(snip...) >

[GIT PULL] DeviceTree updates for 4.16

Linus, Please pull DT updates for 4.16. There will be a trivial context conflict with the PCI tree in drivers/of/Kconfig, but looks like I'm first. Rob The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36: Linux 4.15-rc3 (2017-12-10 17:56:26 -0800) are available in

[GIT PULL] DeviceTree updates for 4.16

Linus, Please pull DT updates for 4.16. There will be a trivial context conflict with the PCI tree in drivers/of/Kconfig, but looks like I'm first. Rob The following changes since commit 50c4c4e268a2d7a3e58ebb698ac74da0de40ae36: Linux 4.15-rc3 (2017-12-10 17:56:26 -0800) are available in

Re: [PATCH 1/7] arm64: zynqmp: Add support for Xilinx zcu100-revC

On 1.2.2018 17:41, Rob Herring wrote: > On Fri, Jan 19, 2018 at 6:55 AM, Michal Simek wrote: >> This board has 2GB of memory, i2c, sd, wifi sdio, spis, uarts, display >> port and usbs. >> Board is using fixed clocks because clock driver hasn't been merged yet. >> >>

Re: [PATCH 1/7] arm64: zynqmp: Add support for Xilinx zcu100-revC

On 1.2.2018 17:41, Rob Herring wrote: > On Fri, Jan 19, 2018 at 6:55 AM, Michal Simek wrote: >> This board has 2GB of memory, i2c, sd, wifi sdio, spis, uarts, display >> port and usbs. >> Board is using fixed clocks because clock driver hasn't been merged yet. >> >> Signed-off-by: Michal Simek

clang warning: implicit conversion in intel_ddi.c:1481

Dear Rodrigo Vivi, Ville Syrjälä, My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We intend to use static analysis tools on the kernel source to identify, analyze and report issues. As a very first step, we are looking into clang compiler warnings and will then move to

clang warning: implicit conversion in intel_ddi.c:1481

Dear Rodrigo Vivi, Ville Syrjälä, My name is Ozan Alpay, and I am a student mentored by Lukas Bulwahn. We intend to use static analysis tools on the kernel source to identify, analyze and report issues. As a very first step, we are looking into clang compiler warnings and will then move to

Re: [PATCH 1/3] compiler-gcc.h: Introduce __optimize function attribute

On 1 February 2018 at 10:21, Geert Uytterhoeven wrote: > Create a new function attribute __optimize, which allows to specify an > optimization level on a per-function basis. > > Signed-off-by: Geert Uytterhoeven Acked-by: Ard Biesheuvel

Re: [PATCH 1/3] compiler-gcc.h: Introduce __optimize function attribute

On 1 February 2018 at 10:21, Geert Uytterhoeven wrote: > Create a new function attribute __optimize, which allows to specify an > optimization level on a per-function basis. > > Signed-off-by: Geert Uytterhoeven Acked-by: Ard Biesheuvel > --- > I assume this is supported as of gcc-4.4: > -

Re: [PATCH 3/3] crypto: sha3-generic - Use __optimize to support old compilers

On 1 February 2018 at 10:22, Geert Uytterhoeven wrote: > With gcc-4.1.2: > > crypto/sha3_generic.c:39: warning: ‘__optimize__’ attribute directive > ignored > > Use the newly introduced __optimize macro to fix this. > > Fixes: 83dee2ce1ae791c3 ("crypto: sha3-generic -

Re: [PATCH 3/3] crypto: sha3-generic - Use __optimize to support old compilers

On 1 February 2018 at 10:22, Geert Uytterhoeven wrote: > With gcc-4.1.2: > > crypto/sha3_generic.c:39: warning: ‘__optimize__’ attribute directive > ignored > > Use the newly introduced __optimize macro to fix this. > > Fixes: 83dee2ce1ae791c3 ("crypto: sha3-generic - rewrite KECCAK

[PATCH] vmxnet3: remove redundant initialization of pointer 'rq'

From: Colin Ian King Pointer rq is being initialized but this value is never read, it is being updated inside a for-loop. Remove the initialization and move it into the scope of the for-loop. Cleans up clang warning: drivers/net/vmxnet3/vmxnet3_drv.c:2763:27: warning:

[PATCH] vmxnet3: remove redundant initialization of pointer 'rq'

From: Colin Ian King Pointer rq is being initialized but this value is never read, it is being updated inside a for-loop. Remove the initialization and move it into the scope of the for-loop. Cleans up clang warning: drivers/net/vmxnet3/vmxnet3_drv.c:2763:27: warning: Value stored to 'rq'

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On 1 February 2018 at 17:57, Peter Zijlstra wrote: > On Wed, Jan 24, 2018 at 09:25:36AM +0100, Vincent Guittot wrote: >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 898785d..ed90303 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@

Re: [RFC PATCH 2/5] sched: Add NOHZ_STATS_KICK

On 1 February 2018 at 17:57, Peter Zijlstra wrote: > On Wed, Jan 24, 2018 at 09:25:36AM +0100, Vincent Guittot wrote: >> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >> index 898785d..ed90303 100644 >> --- a/kernel/sched/fair.c >> +++ b/kernel/sched/fair.c >> @@ -7356,6 +7356,17 @@

Re: [PATCH 2/7] arm64: zynqmp: Add support for Xilinx zcu102

On 1.2.2018 17:46, Rob Herring wrote: > On Fri, Jan 19, 2018 at 6:55 AM, Michal Simek wrote: >> This patch is adding revA, revB and rev1.0. There are also other >> revisions between which should be backward compatible with previous >> versions. Unfortunately all revs are

Re: [PATCH 2/7] arm64: zynqmp: Add support for Xilinx zcu102

On 1.2.2018 17:46, Rob Herring wrote: > On Fri, Jan 19, 2018 at 6:55 AM, Michal Simek wrote: >> This patch is adding revA, revB and rev1.0. There are also other >> revisions between which should be backward compatible with previous >> versions. Unfortunately all revs are still in use. > >

<    2   3   4   5   6   7   8   9   10   11   >