[PATCH v2 0/4] Remove checkpatch warnings

This patchset removes some warnings generated by checkpatch for cleanup of the rtl8723bs driver. Also some additional cleanups are introduced in the *[1/4] and *[3/4] patches to make the code according to the kernel coding style. Changes in v2 -Rebase and resend the patches [2/4], [3/4] and

[PATCH v2 0/4] Remove checkpatch warnings

This patchset removes some warnings generated by checkpatch for cleanup of the rtl8723bs driver. Also some additional cleanups are introduced in the *[1/4] and *[3/4] patches to make the code according to the kernel coding style. Changes in v2 -Rebase and resend the patches [2/4], [3/4] and

Re: [PATCH] ACPI/PCI: pci_link: reduce verbosity when IRQ is enabled

Correcting linux-pci email. On 1/16/2018 1:51 PM, Sinan Kaya wrote: > When ACPI Link object is enabled, the message is printed with a warning > prefix. Some test tools are capturing warning and test error types as > errors. Let's reduce the verbosity of success case. > > Signed-off-by: Sinan

Re: [PATCH] ACPI/PCI: pci_link: reduce verbosity when IRQ is enabled

Correcting linux-pci email. On 1/16/2018 1:51 PM, Sinan Kaya wrote: > When ACPI Link object is enabled, the message is printed with a warning > prefix. Some test tools are capturing warning and test error types as > errors. Let's reduce the verbosity of success case. > > Signed-off-by: Sinan

[PATCH] ACPI/PCI: pci_link: reduce verbosity when IRQ is enabled

When ACPI Link object is enabled, the message is printed with a warning prefix. Some test tools are capturing warning and test error types as errors. Let's reduce the verbosity of success case. Signed-off-by: Sinan Kaya --- drivers/acpi/pci_link.c | 2 +- 1 file changed, 1

[PATCH] ACPI/PCI: pci_link: reduce verbosity when IRQ is enabled

When ACPI Link object is enabled, the message is printed with a warning prefix. Some test tools are capturing warning and test error types as errors. Let's reduce the verbosity of success case. Signed-off-by: Sinan Kaya --- drivers/acpi/pci_link.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v2 1/3] trace-cmd: Make read_proc() to return int status via OUT arg

On Tue, 2018-01-16 at 11:27 -0500, Steven Rostedt wrote: > > > :-) That was totally lost in translation. :-) > > No, I didn't mean to have a comment literally saying "why would strtol > return zero and this not be an error", I meant for the comment to > explain it. > > Actually, looking at

Re: [PATCH v2 1/3] trace-cmd: Make read_proc() to return int status via OUT arg

On Tue, 2018-01-16 at 11:27 -0500, Steven Rostedt wrote: > > > :-) That was totally lost in translation. :-) > > No, I didn't mean to have a comment literally saying "why would strtol > return zero and this not be an error", I meant for the comment to > explain it. > > Actually, looking at

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/11/2018 10:45 AM, Jiri Olsa wrote: On Thu, Jan 11, 2018 at 10:21:25AM -0500, Liang, Kan wrote: SNIP hum, but the PEBS drain is specific just for PERF_X86_EVENT_AUTO_RELOAD events, right? Accurately, PEBS drain is specific for PERF_X86_EVENT_FREERUNNING here.

Re: [RESEND PATCH V2 3/4] perf/x86/intel: drain PEBS buffer in event read

On 1/11/2018 10:45 AM, Jiri Olsa wrote: On Thu, Jan 11, 2018 at 10:21:25AM -0500, Liang, Kan wrote: SNIP hum, but the PEBS drain is specific just for PERF_X86_EVENT_AUTO_RELOAD events, right? Accurately, PEBS drain is specific for PERF_X86_EVENT_FREERUNNING here.

Re: [PATCH 1/2] xen/grant-table: Use put_page instead of free_page

On 01/11/2018 04:36 AM, Ross Lagerwall wrote: > The page given to gnttab_end_foreign_access() to free could be a > compound page so use put_page() instead of free_page() since it can > handle both compound and single pages correctly. > > This bug was discovered when migrating a Xen VM with several

Re: [PATCH 1/2] xen/grant-table: Use put_page instead of free_page

On 01/11/2018 04:36 AM, Ross Lagerwall wrote: > The page given to gnttab_end_foreign_access() to free could be a > compound page so use put_page() instead of free_page() since it can > handle both compound and single pages correctly. > > This bug was discovered when migrating a Xen VM with several

Re: WARNING in can_rcv

On 01/16/2018 07:11 PM, Dmitry Vyukov wrote: >>> Kernel panic - not syncing: panic_on_warn set ... >> >> Invalid packages generate a warning (WARN_ONCE()), and you have >> panic_on_warn active. Should we better silently drop these CAN packages? > > pr_warn_once() will be more appropriate. It

Re: WARNING in can_rcv

On 01/16/2018 07:11 PM, Dmitry Vyukov wrote: >>> Kernel panic - not syncing: panic_on_warn set ... >> >> Invalid packages generate a warning (WARN_ONCE()), and you have >> panic_on_warn active. Should we better silently drop these CAN packages? > > pr_warn_once() will be more appropriate. It

Re: [PATCH] modpost: Remove trailing semicolon

+++ Luis de Bethencourt [16/01/18 13:21 +]: The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: Luis de Bethencourt Applied. Thanks, Jessica

Re: [PATCH] modpost: Remove trailing semicolon

+++ Luis de Bethencourt [16/01/18 13:21 +]: The trailing semicolon is an empty statement that does no operation. Removing it since it doesn't do anything. Signed-off-by: Luis de Bethencourt Applied. Thanks, Jessica

[PATCH v2] crypto/ahash: Require export/import in ahash

Export and import were optional in async hash. As most drivers were rewritten, they become mandatory now, so correct init of ahash transformation. Signed-off-by: Kamil Konieczny --- This is resend of previous patch. As Bartlomiej Zolnierkiewicz pointed out, there

[PATCH v2] crypto/ahash: Require export/import in ahash

Export and import were optional in async hash. As most drivers were rewritten, they become mandatory now, so correct init of ahash transformation. Signed-off-by: Kamil Konieczny --- This is resend of previous patch. As Bartlomiej Zolnierkiewicz pointed out, there are still three crypto drivers

Re: [PATCH] vfio: mdev: make a couple of functions and structure vfio_mdev_driver static

On Fri, 22 Dec 2017 07:12:26 +0800 Xiongwei Song wrote: > The functions vfio_mdev_probe, vfio_mdev_remove and the structure > vfio_mdev_driver are only used in this file, so make them static. > > Clean up sparse warnings: > drivers/vfio/mdev/vfio_mdev.c:114:5: warning: no

Re: [PATCH] vfio: mdev: make a couple of functions and structure vfio_mdev_driver static

On Fri, 22 Dec 2017 07:12:26 +0800 Xiongwei Song wrote: > The functions vfio_mdev_probe, vfio_mdev_remove and the structure > vfio_mdev_driver are only used in this file, so make them static. > > Clean up sparse warnings: > drivers/vfio/mdev/vfio_mdev.c:114:5: warning: no previous prototype >

Re: [PATCH 01/16] x86/entry/32: Rename TSS_sysenter_sp0 to TSS_sysenter_stack

On Tue, 16 Jan 2018, Joerg Roedel wrote: > From: Joerg Roedel > > The stack addresss doesn't need to be stored in tss.sp0 if > we switch manually like on sysenter. Rename the offset so > that it still makes sense when we its location. -ENOSENTENCE Other than that. Makes

Re: [PATCH 01/16] x86/entry/32: Rename TSS_sysenter_sp0 to TSS_sysenter_stack

On Tue, 16 Jan 2018, Joerg Roedel wrote: > From: Joerg Roedel > > The stack addresss doesn't need to be stored in tss.sp0 if > we switch manually like on sysenter. Rename the offset so > that it still makes sense when we its location. -ENOSENTENCE Other than that. Makes sense. >

RE: [REGRESSION][v4.14.y][v4.15] x86/intel_rdt/cqm: Improve limbo list processing

> From: Thomas Gleixner [mailto:t...@linutronix.de] > On Tue, 16 Jan 2018, Joseph Salisbury wrote: > > On 01/16/2018 08:32 AM, Shankar, Ravi V wrote: > > > Vikas on vacation until end of the month. Fenghua will look into > > > this issue. > > > > > > On Jan 16, 2018, at 5:09 AM, Thomas Gleixner

RE: [REGRESSION][v4.14.y][v4.15] x86/intel_rdt/cqm: Improve limbo list processing

> From: Thomas Gleixner [mailto:t...@linutronix.de] > On Tue, 16 Jan 2018, Joseph Salisbury wrote: > > On 01/16/2018 08:32 AM, Shankar, Ravi V wrote: > > > Vikas on vacation until end of the month. Fenghua will look into > > > this issue. > > > > > > On Jan 16, 2018, at 5:09 AM, Thomas Gleixner >

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

On Tue, 16 Jan 2018, Vitaly Kuznetsov wrote: > Hyper-V supports Live Migration notification. This is supposed to be used > in conjunction with TSC emulation: when we are migrated to a host with > different TSC frequency for some short period host emulates our accesses > to TSC and sends us an

Re: [PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

On Tue, 16 Jan 2018, Vitaly Kuznetsov wrote: > Hyper-V supports Live Migration notification. This is supposed to be used > in conjunction with TSC emulation: when we are migrated to a host with > different TSC frequency for some short period host emulates our accesses > to TSC and sends us an

Re: [PATCH v3 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining

On Tue, 16 Jan 2018, Vitaly Kuznetsov wrote: > It is very unlikely for CPUs to get offlined when we run on Hyper-V as > we have a protection in vmbus module which prevents it when we have any > VMBus devices assigned. This, however, may change in future if an option > to reassign an already

Re: [PATCH v3 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining

On Tue, 16 Jan 2018, Vitaly Kuznetsov wrote: > It is very unlikely for CPUs to get offlined when we run on Hyper-V as > we have a protection in vmbus module which prevents it when we have any > VMBus devices assigned. This, however, may change in future if an option > to reassign an already

Re: [PATCH v3 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

On Tue, 16 Jan 2018, Vitaly Kuznetsov wrote: > Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're > not supposed to see many of them. However, it may be important to know > that the event has happened in case we have L2 nested guests. > > Signed-off-by: Vitaly Kuznetsov

Re: [PATCH v3 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

On Tue, 16 Jan 2018, Vitaly Kuznetsov wrote: > Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're > not supposed to see many of them. However, it may be important to know > that the event has happened in case we have L2 nested guests. > > Signed-off-by: Vitaly Kuznetsov

[PATCH v3 2/7] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously

This is going to be used from KVM code where we need to get both TSC and TSC page value. Nobody is supposed to use the function when Hyper-V code is compiled out, just BUG(). Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/hv_init.c | 1 +

[PATCH v3 2/7] x86/hyper-v: add a function to read both TSC and TSC page value simulateneously

This is going to be used from KVM code where we need to get both TSC and TSC page value. Nobody is supposed to use the function when Hyper-V code is compiled out, just BUG(). Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/hv_init.c | 1 + arch/x86/include/asm/mshyperv.h | 23

Re: [PATCH for 4.16 08/10] membarrier: x86: Provide core serializing command (v3)

On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: > There are two places where core serialization is needed by membarrier: > > 1) When returning from the membarrier IPI, > 2) After scheduler updates curr to a thread with a different mm, before >going back to user-space, since the curr->mm is

Re: [PATCH for 4.16 08/10] membarrier: x86: Provide core serializing command (v3)

On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: > There are two places where core serialization is needed by membarrier: > > 1) When returning from the membarrier IPI, > 2) After scheduler updates curr to a thread with a different mm, before >going back to user-space, since the curr->mm is

[PATCH v3 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're not supposed to see many of them. However, it may be important to know that the event has happened in case we have L2 nested guests. Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/hv_init.c |

[PATCH v3 5/7] x86/irq: Count Hyper-V reenlightenment interrupts

Hyper-V reenlightenment interrupts arrive when the VM is migrated, we're not supposed to see many of them. However, it may be important to know that the event has happened in case we have L2 nested guests. Signed-off-by: Vitaly Kuznetsov --- arch/x86/hyperv/hv_init.c | 2 ++

[PATCH v3 6/7] x86/kvm: pass stable clocksource to guests when running nested on Hyper-V

Currently, KVM is able to work in 'masterclock' mode passing PVCLOCK_TSC_STABLE_BIT to guests when the clocksource we use on the host is TSC. When running nested on Hyper-V we normally use a different one: TSC page which is resistant to TSC frequency changes on event like L1 migration. Add support

Re: [PATCH] crypto: mxs-dcp: Add empty hash export and import

On 16.01.2018 18:28, Fabio Estevam wrote: > Hi Kamil, > > On Tue, Jan 16, 2018 at 2:16 PM, Kamil Konieczny > wrote: >> Crypto framework will require async hash export/import, so add empty >> functions to prevent OOPS. > > Which Oops exactly are you getting?

Re: [PATCH] crypto: mxs-dcp: Add empty hash export and import

On 16.01.2018 18:28, Fabio Estevam wrote: > Hi Kamil, > > On Tue, Jan 16, 2018 at 2:16 PM, Kamil Konieczny > wrote: >> Crypto framework will require async hash export/import, so add empty >> functions to prevent OOPS. > > Which Oops exactly are you getting? None now, it is for preparation

[PATCH v3 6/7] x86/kvm: pass stable clocksource to guests when running nested on Hyper-V

Currently, KVM is able to work in 'masterclock' mode passing PVCLOCK_TSC_STABLE_BIT to guests when the clocksource we use on the host is TSC. When running nested on Hyper-V we normally use a different one: TSC page which is resistant to TSC frequency changes on event like L1 migration. Add support

Re: [PATCH for 4.16 07/10] x86: Introduce sync_core_before_usermode (v2)

On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: > Introduce an architecture function that ensures the current CPU > issues a core serializing instruction before returning to usermode. > > This is needed for the membarrier "sync_core" command. > > Architectures defining the

[PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

Hyper-V supports Live Migration notification. This is supposed to be used in conjunction with TSC emulation: when we are migrated to a host with different TSC frequency for some short period host emulates our accesses to TSC and sends us an interrupt to notify about the event. When we're done

Re: [PATCH for 4.16 07/10] x86: Introduce sync_core_before_usermode (v2)

On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: > Introduce an architecture function that ensures the current CPU > issues a core serializing instruction before returning to usermode. > > This is needed for the membarrier "sync_core" command. > > Architectures defining the

[PATCH v3 3/7] x86/hyper-v: reenlightenment notifications support

Hyper-V supports Live Migration notification. This is supposed to be used in conjunction with TSC emulation: when we are migrated to a host with different TSC frequency for some short period host emulates our accesses to TSC and sends us an interrupt to notify about the event. When we're done

[PATCH v3 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining

It is very unlikely for CPUs to get offlined when we run on Hyper-V as we have a protection in vmbus module which prevents it when we have any VMBus devices assigned. This, however, may change in future if an option to reassign an already active channel will be added. It is also possible to run

[PATCH v3 4/7] x86/hyper-v: redirect reenlightment notifications on CPU offlining

It is very unlikely for CPUs to get offlined when we run on Hyper-V as we have a protection in vmbus module which prevents it when we have any VMBus devices assigned. This, however, may change in future if an option to reassign an already active channel will be added. It is also possible to run

[PATCH v3 7/7] x86/kvm: support Hyper-V reenlightenment

When we run nested KVM on Hyper-V guests we need to update masterclocks for all guests when L1 migrates to a host with different TSC frequency. Implement the procedure in the following way: - Pause all guests. - Tell our host (Hyper-V) to stop emulating TSC accesses. - Update our gtod copy,

[PATCH v3 7/7] x86/kvm: support Hyper-V reenlightenment

When we run nested KVM on Hyper-V guests we need to update masterclocks for all guests when L1 migrates to a host with different TSC frequency. Implement the procedure in the following way: - Pause all guests. - Tell our host (Hyper-V) to stop emulating TSC accesses. - Update our gtod copy,

[PATCH v3 1/7] x86/hyper-v: check for required priviliges in hyperv_init()

In hyperv_init() we presume we always have access to VP index and hypercall MSRs while according to the specification we should check if we're allowed to access the corresponding MSRs before accessing them. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Thomas Gleixner

[PATCH v3 1/7] x86/hyper-v: check for required priviliges in hyperv_init()

In hyperv_init() we presume we always have access to VP index and hypercall MSRs while according to the specification we should check if we're allowed to access the corresponding MSRs before accessing them. Signed-off-by: Vitaly Kuznetsov Reviewed-by: Thomas Gleixner ---

[PATCH v3 0/7] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V

Changes since v2: - Add Paolo's Acked-by to PATCH6-7 - Add Thomas' Reviewed-by to PATCH1 - Update the description of PATCH2 to match the reality [Thomas Gleixner] - Add __visible and __irq_entry annotations to hyperv_reenlightenment_intr() [Thomas Gleixner] - Drop spinlock protection and use

[PATCH v3 0/7] x86/kvm/hyperv: stable clocksorce for L2 guests when running nested KVM on Hyper-V

Changes since v2: - Add Paolo's Acked-by to PATCH6-7 - Add Thomas' Reviewed-by to PATCH1 - Update the description of PATCH2 to match the reality [Thomas Gleixner] - Add __visible and __irq_entry annotations to hyperv_reenlightenment_intr() [Thomas Gleixner] - Drop spinlock protection and use

Re: [PATCH 2/5] perf unwind: Do not look at globals

Em Tue, Jan 16, 2018 at 12:36:21PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Jan 16, 2018 at 04:19:15PM +0100, Jiri Olsa escreveu: > > it should get set in apply_config_terms which calls parse_callchain_record > No, it should not set the global parameter, as this is just for a >

Re: [PATCH 2/5] perf unwind: Do not look at globals

Em Tue, Jan 16, 2018 at 12:36:21PM -0300, Arnaldo Carvalho de Melo escreveu: > Em Tue, Jan 16, 2018 at 04:19:15PM +0100, Jiri Olsa escreveu: > > it should get set in apply_config_terms which calls parse_callchain_record > No, it should not set the global parameter, as this is just for a >

Re: LKML admins (syzbot emails are not delivered)

On Mon, Jan 15, 2018 at 5:38 PM, Eric W. Biederman wrote: > When I made the complaint it came to me and to messages on lkml as > .log. With Content-Type: Application/Octent-stream. Where was that? If I am not mistaken you actually didn't. I triple-checked my inbox and

Re: LKML admins (syzbot emails are not delivered)

On Mon, Jan 15, 2018 at 5:38 PM, Eric W. Biederman wrote: > When I made the complaint it came to me and to messages on lkml as > .log. With Content-Type: Application/Octent-stream. Where was that? If I am not mistaken you actually didn't. I triple-checked my inbox and searched internet. The

Re: [PATCH for 4.16 04/10] membarrier: provide SHARED_EXPEDITED command (v2)

On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: > +static int membarrier_shared_expedited(void) > +{ > + int cpu; > + bool fallback = false; > + cpumask_var_t tmpmask; > + > + if (num_online_cpus() == 1) > + return 0; > + > + /* > + * Matches memory barriers

Re: [PATCH for 4.16 04/10] membarrier: provide SHARED_EXPEDITED command (v2)

On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: > +static int membarrier_shared_expedited(void) > +{ > + int cpu; > + bool fallback = false; > + cpumask_var_t tmpmask; > + > + if (num_online_cpus() == 1) > + return 0; > + > + /* > + * Matches memory barriers

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

Draft patch of how the data structs could change. kmem_cache_attr is read only. Index: linux/include/linux/slab.h === --- linux.orig/include/linux/slab.h +++ linux/include/linux/slab.h @@ -135,9 +135,17 @@ struct mem_cgroup; void

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

Draft patch of how the data structs could change. kmem_cache_attr is read only. Index: linux/include/linux/slab.h === --- linux.orig/include/linux/slab.h +++ linux/include/linux/slab.h @@ -135,9 +135,17 @@ struct mem_cgroup; void

Re: [RFC PATCH 00/16] PTI support for x86-32

Joerg, Very cool!. I really appreciate you putting this together. I don't see any real showstoppers or things that I think will *break* 64-bit. I just hope that we can merge this _slowly_ in case it breaks 64-bit along the way. I didn't look at the assembly in too much detail.

Re: [RFC PATCH 00/16] PTI support for x86-32

Joerg, Very cool!. I really appreciate you putting this together. I don't see any real showstoppers or things that I think will *break* 64-bit. I just hope that we can merge this _slowly_ in case it breaks 64-bit along the way. I didn't look at the assembly in too much detail.

RE: [PATCH V4 02/15] perf mmap: introduce perf_mmap__read_init()

> On Mon, Jan 15, 2018 at 12:20:38PM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The perf record has specific codes to calculate the ringbuffer position > > for both overwrite and non-overwrite mode. Now, only perf record > > supports both modes. The perf

RE: [PATCH V4 02/15] perf mmap: introduce perf_mmap__read_init()

> On Mon, Jan 15, 2018 at 12:20:38PM -0800, kan.li...@intel.com wrote: > > From: Kan Liang > > > > The perf record has specific codes to calculate the ringbuffer position > > for both overwrite and non-overwrite mode. Now, only perf record > > supports both modes. The perf top will support both

Re: [PATCH v2] net/core: Increase default optmem_max limit

Am Dienstag, 16. Januar 2018, 18:16:43 CET schrieb Björn 'besser82' Esser: Hi Björn, > With the new Linux Kernel Crypto API User Space Interface > and its underlying AF_ALG socket, the current default value > for `net.core.optmem_max` can be exhausted pretty quick when > using asynchronous IO;

Re: [PATCH v2] net/core: Increase default optmem_max limit

Am Dienstag, 16. Januar 2018, 18:16:43 CET schrieb Björn 'besser82' Esser: Hi Björn, > With the new Linux Kernel Crypto API User Space Interface > and its underlying AF_ALG socket, the current default value > for `net.core.optmem_max` can be exhausted pretty quick when > using asynchronous IO;

Re: WARNING in can_rcv

On Tue, Jan 16, 2018 at 7:07 PM, Marc Kleine-Budde wrote: > On 01/16/2018 06:58 PM, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> a8750ddca918032d6349adbf9a4b6555e7db20da >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >>

Re: [PATCH] MAINTAINERS: Add NuBus subsystem entry

Hi Finn, On Mon, Jan 15, 2018 at 4:41 AM, Finn Thain wrote: > This is legacy code but it might as well have an official maintainer. > > Cc: linux-m...@lists.linux-m68k.org > Signed-off-by: Finn Thain Thanks for stepping up! Applied and

Re: WARNING in can_rcv

On Tue, Jan 16, 2018 at 7:07 PM, Marc Kleine-Budde wrote: > On 01/16/2018 06:58 PM, syzbot wrote: >> Hello, >> >> syzkaller hit the following crash on >> a8750ddca918032d6349adbf9a4b6555e7db20da >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master >> compiler: gcc (GCC)

Re: [PATCH] MAINTAINERS: Add NuBus subsystem entry

Hi Finn, On Mon, Jan 15, 2018 at 4:41 AM, Finn Thain wrote: > This is legacy code but it might as well have an official maintainer. > > Cc: linux-m...@lists.linux-m68k.org > Signed-off-by: Finn Thain Thanks for stepping up! Applied and queued for v4.16. Gr{oetje,eeting}s,

Re: [PATCH 12/16] x86/mm/pae: Populate the user page-table with user pgd's

On 01/16/2018 08:36 AM, Joerg Roedel wrote: > +#ifdef CONFIG_X86_64 > /* >* If this is normal user memory, make it NX in the kernel >* pagetables so that, if we somehow screw up and return to > @@ -134,10 +135,16 @@ pgd_t __pti_set_user_pgd(pgd_t *pgdp, pgd_t pgd) >*

Re: [PATCH 12/16] x86/mm/pae: Populate the user page-table with user pgd's

On 01/16/2018 08:36 AM, Joerg Roedel wrote: > +#ifdef CONFIG_X86_64 > /* >* If this is normal user memory, make it NX in the kernel >* pagetables so that, if we somehow screw up and return to > @@ -134,10 +135,16 @@ pgd_t __pti_set_user_pgd(pgd_t *pgdp, pgd_t pgd) >*

[ANNOUNCE] 4.9.76-rt61

Hello RT Folks! I'm pleased to announce the 4.9.76-rt61 stable release. This release is just an update to the new stable 4.9.76 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 4.9.76-rt61

Hello RT Folks! I'm pleased to announce the 4.9.76-rt61 stable release. This release is just an update to the new stable 4.9.76 version and no RT specific changes have been made. You can get this release via the git tree at:

Re: [PATCH v5 00/14] Modernization and fixes for NuBus subsystem

Hi Finn, On Sat, Jan 13, 2018 at 11:37 PM, Finn Thain wrote: > This series begins with cleanups and fixes for the NuBus subsystem and > finishes with a patch to add support for the Linux Driver Model. > A separate series (which requires this one) modernizes NuBus

Re: [PATCH v5 00/14] Modernization and fixes for NuBus subsystem

Hi Finn, On Sat, Jan 13, 2018 at 11:37 PM, Finn Thain wrote: > This series begins with cleanups and fixes for the NuBus subsystem and > finishes with a patch to add support for the Linux Driver Model. > A separate series (which requires this one) modernizes NuBus drivers. > > Changes since v1: >

Re: [REGRESSION][v4.14.y][v4.15] x86/intel_rdt/cqm: Improve limbo list processing

On Tue, 16 Jan 2018, Joseph Salisbury wrote: > On 01/16/2018 08:32 AM, Shankar, Ravi V wrote: > > Vikas on vacation until end of the month. Fenghua will look into this > > issue. > > > > On Jan 16, 2018, at 5:09 AM, Thomas Gleixner > > wrote: > > >

Re: [REGRESSION][v4.14.y][v4.15] x86/intel_rdt/cqm: Improve limbo list processing

On Tue, 16 Jan 2018, Joseph Salisbury wrote: > On 01/16/2018 08:32 AM, Shankar, Ravi V wrote: > > Vikas on vacation until end of the month. Fenghua will look into this > > issue. > > > > On Jan 16, 2018, at 5:09 AM, Thomas Gleixner > > wrote: > > > >> > >> Vikas,

Re: [PATCH 4.14 000/118] 4.14.14-stable review

On 01/15/2018 05:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.14 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: [PATCH 4.14 000/118] 4.14.14-stable review

On 01/15/2018 05:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.14.14 release. > There are 118 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses

Re: WARNING in can_rcv

On 01/16/2018 06:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > a8750ddca918032d6349adbf9a4b6555e7db20da > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: WARNING in can_rcv

On 01/16/2018 06:58 PM, syzbot wrote: > Hello, > > syzkaller hit the following crash on > a8750ddca918032d6349adbf9a4b6555e7db20da > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console output is

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

On Tue, 16 Jan 2018, Matthew Wilcox wrote: > > Sure this data is never changed. It can be const. > > It's changed at initialisation. Look: > > kmem_cache_create(const char *name, size_t size, size_t align, > slab_flags_t flags, void (*ctor)(void *)) > s =

Re: kmem_cache_attr (was Re: [PATCH 04/36] usercopy: Prepare for usercopy whitelisting)

On Tue, 16 Jan 2018, Matthew Wilcox wrote: > > Sure this data is never changed. It can be const. > > It's changed at initialisation. Look: > > kmem_cache_create(const char *name, size_t size, size_t align, > slab_flags_t flags, void (*ctor)(void *)) > s =

Re: [PATCH 10/16] x86/mm/pti: Populate valid user pud entries

On 01/16/2018 08:36 AM, Joerg Roedel wrote: > > In PAE page-tables at the top-level most bits we usually set > with _KERNPG_TABLE are reserved, resulting in a #GP when > they are loaded by the processor. Can you save me the trip to the SDM and remind me which bits actually cause trouble here?

Re: [PATCH 10/16] x86/mm/pti: Populate valid user pud entries

On 01/16/2018 08:36 AM, Joerg Roedel wrote: > > In PAE page-tables at the top-level most bits we usually set > with _KERNPG_TABLE are reserved, resulting in a #GP when > they are loaded by the processor. Can you save me the trip to the SDM and remind me which bits actually cause trouble here?

Re: [PATCH v2 01/10] perf tools: Integrating the CoreSight decoding library

On Tue, Jan 16, 2018 at 01:15:00PM +0100, Jiri Olsa wrote: > On Mon, Jan 15, 2018 at 11:13:05AM -0700, Mathieu Poirier wrote: > > The Open CoreSight Decoding Library (openCSD) is a free and open > > library to decode traces collected by the CoreSight hardware > > infrastructure. > > > > This

Re: [PATCH v2 01/10] perf tools: Integrating the CoreSight decoding library

On Tue, Jan 16, 2018 at 01:15:00PM +0100, Jiri Olsa wrote: > On Mon, Jan 15, 2018 at 11:13:05AM -0700, Mathieu Poirier wrote: > > The Open CoreSight Decoding Library (openCSD) is a free and open > > library to decode traces collected by the CoreSight hardware > > infrastructure. > > > > This

Re: [PATCH 07/16] x86/mm: Move two more functions from pgtable_64.h to pgtable.h

On 01/16/2018 08:36 AM, Joerg Roedel wrote: > +/* > + * Page table pages are page-aligned. The lower half of the top > + * level is used for userspace and the top half for the kernel. > + * > + * Returns true for parts of the PGD that map userspace and > + * false for the parts that map the

Re: [PATCH 07/16] x86/mm: Move two more functions from pgtable_64.h to pgtable.h

On 01/16/2018 08:36 AM, Joerg Roedel wrote: > +/* > + * Page table pages are page-aligned. The lower half of the top > + * level is used for userspace and the top half for the kernel. > + * > + * Returns true for parts of the PGD that map userspace and > + * false for the parts that map the

Re: LKML admins (syzbot emails are not delivered)

On Mon, Jan 15, 2018 at 5:16 PM, Eric W. Biederman wrote: > Dmitry Vyukov writes: > > 2> On Mon, Jan 15, 2018 at 1:54 PM, Pavel Machek wrote: >>> Hi! >>> > *Snort* > > If the information to solve an issue is not in the Oops

Re: LKML admins (syzbot emails are not delivered)

On Mon, Jan 15, 2018 at 5:16 PM, Eric W. Biederman wrote: > Dmitry Vyukov writes: > > 2> On Mon, Jan 15, 2018 at 1:54 PM, Pavel Machek wrote: >>> Hi! >>> > *Snort* > > If the information to solve an issue is not in the Oops syzbot is > useless. Hi Eric

[PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch

The logic of the original commit 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd") was assumed conditional free of struct kib_conn if the second argument free_conn in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true. But this hunk of code was

[PATCH] staging: lustre: Fix avoid intensive reconnecting for ko2iblnd patch

The logic of the original commit 4d99b2581eff ("staging: lustre: avoid intensive reconnecting for ko2iblnd") was assumed conditional free of struct kib_conn if the second argument free_conn in function kiblnd_destroy_conn(struct kib_conn *conn, bool free_conn) is true. But this hunk of code was

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 2018-01-16 at 16:41 +0100, Frederic Weisbecker wrote: > On Fri, Jan 12, 2018 at 02:18:13PM -0500, Luiz Capitulino wrote: > > > Why are extending isolcpus= given that it's a deprecated interface? > > Some people have already moved away from isolcpus= now, but with this > > new feature they

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

On Tue, 2018-01-16 at 16:41 +0100, Frederic Weisbecker wrote: > On Fri, Jan 12, 2018 at 02:18:13PM -0500, Luiz Capitulino wrote: > > > Why are extending isolcpus= given that it's a deprecated interface? > > Some people have already moved away from isolcpus= now, but with this > > new feature they

Re: [PATCH 00/10] perf tools: Add support for CoreSight trace decoding

On Tue, Jan 16, 2018 at 11:01:02AM -0600, Kim Phillips wrote: > On Tue, 16 Jan 2018 12:35:26 + > Mike Leach wrote: > > > Hi, > > > > On 11 January 2018 at 22:18, Mathieu Poirier > > wrote: > > > On 11 January 2018 at 14:49, Kim Phillips

Re: [PATCH 00/10] perf tools: Add support for CoreSight trace decoding

On Tue, Jan 16, 2018 at 11:01:02AM -0600, Kim Phillips wrote: > On Tue, 16 Jan 2018 12:35:26 + > Mike Leach wrote: > > > Hi, > > > > On 11 January 2018 at 22:18, Mathieu Poirier > > wrote: > > > On 11 January 2018 at 14:49, Kim Phillips wrote: > > >> On Thu, 11 Jan 2018 14:11:00 -0700 >

Re: [PATCH v3] arm64: fix unwind_frame() for filtered out fn for function graph tracing

On Fri, Jan 12, 2018 at 11:48:32AM +0100, Jerome Marchand wrote: > diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c > index 76809ccd309c..5a528c58ef68 100644 > --- a/arch/arm64/kernel/stacktrace.c > +++ b/arch/arm64/kernel/stacktrace.c > @@ -59,6 +59,10 @@ int notrace

Re: [PATCH v3] arm64: fix unwind_frame() for filtered out fn for function graph tracing

On Fri, Jan 12, 2018 at 11:48:32AM +0100, Jerome Marchand wrote: > diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c > index 76809ccd309c..5a528c58ef68 100644 > --- a/arch/arm64/kernel/stacktrace.c > +++ b/arch/arm64/kernel/stacktrace.c > @@ -59,6 +59,10 @@ int notrace

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