Re: [PATCH v6 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

Hi, On 01/15/2018 08:58 AM, Sudeep Holla wrote: On Fri, Jan 12, 2018 at 06:59:13PM -0600, Jeremy Linton wrote: ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the

Re: [PATCH v2] retpoline/module: Warn for missing retpoline in module

On Fri, 12 Jan 2018, Andi Kleen wrote: > From: Andi Kleen > void stop_this_cpu(void *dummy); > void df_debug(struct pt_regs *regs, long error_code); > + > +void disable_retpoline(void); > +bool retpoline_enabled(void); Can you please use a consistent name space?

Re: [PATCH v6 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

Hi, On 01/15/2018 08:58 AM, Sudeep Holla wrote: On Fri, Jan 12, 2018 at 06:59:13PM -0600, Jeremy Linton wrote: ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the

Re: [PATCH v2] retpoline/module: Warn for missing retpoline in module

On Fri, 12 Jan 2018, Andi Kleen wrote: > From: Andi Kleen > void stop_this_cpu(void *dummy); > void df_debug(struct pt_regs *regs, long error_code); > + > +void disable_retpoline(void); > +bool retpoline_enabled(void); Can you please use a consistent name space? retpoline_ ... or such? > +/*

[PATCH v3] retpoline: Add retpoline tag to VERMAGIC

From: Andi Kleen Add a marker for retpoline to the module VERMAGIC. This catches the case when a non RETPOLINE compiled module gets loaded into a retpoline kernel, making it insecure. It doesn't handle the case when retpoline has been runtime disabled. Even in this case

[PATCH v3] retpoline: Add retpoline tag to VERMAGIC

From: Andi Kleen Add a marker for retpoline to the module VERMAGIC. This catches the case when a non RETPOLINE compiled module gets loaded into a retpoline kernel, making it insecure. It doesn't handle the case when retpoline has been runtime disabled. Even in this case the match of the

linux-next: Signed-off-by missing for commit in the gfs2 tree

Hi all, Commit 7d2040199855 ("gfs2: Add gfs2_blk2rgrpd comment and fix incorrect use") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell

linux-next: Signed-off-by missing for commit in the gfs2 tree

Hi all, Commit 7d2040199855 ("gfs2: Add gfs2_blk2rgrpd comment and fix incorrect use") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 12:11:58PM -0800, Luck, Tony wrote: > I think so. The erratum (see below) says the problem only occurs > on the large-cache SKUs. So we only need to avoid the update if > we are on a big cache SKU that is also running old microcode. ... and there's not a more reliable way

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

On Tue, Jan 16, 2018 at 11:08:13AM -0700, Shuah Khan wrote: > 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

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 12:11:58PM -0800, Luck, Tony wrote: > I think so. The erratum (see below) says the problem only occurs > on the large-cache SKUs. So we only need to avoid the update if > we are on a big cache SKU that is also running old microcode. ... and there's not a more reliable way

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

On Tue, Jan 16, 2018 at 11:08:13AM -0700, Shuah Khan wrote: > 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

Re: KASAN: use-after-free Read in psock_write_space

On Tue, Jan 16, 2018 at 12:40 PM, syzbot wrote: > syzkaller has found reproducer for the following crash on > a8750ddca918032d6349adbf9a4b6555e7db20da > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master > compiler: gcc

Re: KASAN: use-after-free Read in psock_write_space

On Tue, Jan 16, 2018 at 12:40 PM, syzbot wrote: > syzkaller has found reproducer for 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

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

- On Jan 16, 2018, at 2:22 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Jan 16, 2018, at 1:29 PM, Thomas Gleixner t...@linutronix.de wrote: > >> On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: >> >>> There are two places where core serialization is needed by

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

- On Jan 16, 2018, at 2:22 PM, Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote: > - On Jan 16, 2018, at 1:29 PM, Thomas Gleixner t...@linutronix.de wrote: > >> On Mon, 15 Jan 2018, Mathieu Desnoyers wrote: >> >>> There are two places where core serialization is needed by

[PATCH 2/2] macintosh/rack-meter: Improve a size determination in rackmeter_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 21:26:52 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style

[PATCH 2/2] macintosh/rack-meter: Improve a size determination in rackmeter_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 21:26:52 +0100 Replace the specification of a data structure by a pointer dereference as the parameter for the operator "sizeof" to make the corresponding size determination a bit safer according to the Linux coding style convention. This issue was

[PATCH 1/2] macintosh/rack-meter: Delete an error message for a failed memory allocation in rackmeter_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 21:23:36 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] macintosh/rack-meter: Delete an error message for a failed memory allocation in rackmeter_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 21:23:36 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/macintosh/rack-meter.c | 1 - 1 file changed, 1 deletion(-)

[PATCH] kconfig: Clarify menu and 'if' dependency propagation

It is not obvious that the last two cases refer to menus and ifs, respectively, in the conditional that sets 'parentdep'. Automatic submenu creation is done later, so the parent can't be a symbol here. No functional changes. Only comments added. Signed-off-by: Ulf Magnusson

[PATCH] kconfig: Clarify menu and 'if' dependency propagation

It is not obvious that the last two cases refer to menus and ifs, respectively, in the conditional that sets 'parentdep'. Automatic submenu creation is done later, so the parent can't be a symbol here. No functional changes. Only comments added. Signed-off-by: Ulf Magnusson ---

[PATCH 0/2] macintosh/rack-meter: Adjustments for rackmeter_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 21:36:56 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination

[PATCH 0/2] macintosh/rack-meter: Adjustments for rackmeter_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 21:36:56 +0100 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Delete an error message for a failed memory allocation Improve a size determination drivers/macintosh/rack-meter.c | 3 +-- 1

Re: [PATCH 4.9 00/96] 4.9.77-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.9.77 release. > There are 96 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.9 00/96] 4.9.77-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.9.77 release. > There are 96 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

[GIT] Networking

1) Two read past end of buffer fixes in AF_KEY, from Eric Biggers. 2) Memory leak in key_notify_policy(), from Steffen Klassert. 3) Fix overflow with bpf arrays, from Daniel Borkmann. 4) Fix RDMA regression with mlx5 due to mlx5 no longer using pci_irq_get_affinity(), from Saeed Mahameed.

[GIT] Networking

1) Two read past end of buffer fixes in AF_KEY, from Eric Biggers. 2) Memory leak in key_notify_policy(), from Steffen Klassert. 3) Fix overflow with bpf arrays, from Daniel Borkmann. 4) Fix RDMA regression with mlx5 due to mlx5 no longer using pci_irq_get_affinity(), from Saeed Mahameed.

Re: general protection fault in skb_segment

On Tue, Jan 2, 2018 at 12:23 PM, Willem de Bruijn wrote: >> Actually, changes just to inet_gso_segment and ipv6_gso_segment >> will suffice: >> >>bool udpfrag = false, fixedid = false, gso_partial, encap; >> struct sk_buff *segs = ERR_PTR(-EINVAL);

Re: general protection fault in skb_segment

On Tue, Jan 2, 2018 at 12:23 PM, Willem de Bruijn wrote: >> Actually, changes just to inet_gso_segment and ipv6_gso_segment >> will suffice: >> >>bool udpfrag = false, fixedid = false, gso_partial, encap; >> struct sk_buff *segs = ERR_PTR(-EINVAL); >> + unsigned int offset =

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

Hello Marc, On Thu, Jan 11, 2018 at 08:51:37AM +, Marc Zyngier wrote: > > [ I also added cntfrq here for safety as theoretically it could > > trigger the trap as well. However, my another test case (with > > mrc insturction) doesn't seem to trigger a trap. So I would > > drop it in the

Re: [PATCH RFC v1] arm64: Handle traps from accessing CNTVCT/CNTFRQ for CONFIG_COMPAT

Hello Marc, On Thu, Jan 11, 2018 at 08:51:37AM +, Marc Zyngier wrote: > > [ I also added cntfrq here for safety as theoretically it could > > trigger the trap as well. However, my another test case (with > > mrc insturction) doesn't seem to trigger a trap. So I would > > drop it in the

Re: [PATCH 3.18 00/46] 3.18.92-stable review

On 01/15/2018 05:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.92 release. > There are 46 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 3.18 00/46] 3.18.92-stable review

On 01/15/2018 05:33 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.92 release. > There are 46 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 v2 01/10] perf tools: Integrating the CoreSight decoding library

On 16 January 2018 at 05:15, 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 16 January 2018 at 05:15, 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 patch adds the

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

On Tue, 16 Jan 2018, Joerg Roedel wrote: > @@ -89,13 +89,9 @@ static inline void refresh_sysenter_cs(struct > thread_struct *thread) > /* This is used when switching tasks or entering/exiting vm86 mode. */ > static inline void update_sp0(struct task_struct *task) > { > - /* On x86_64, sp0

Re: [PATCH 02/16] x86/entry/32: Enter the kernel via trampoline stack

On Tue, 16 Jan 2018, Joerg Roedel wrote: > @@ -89,13 +89,9 @@ static inline void refresh_sysenter_cs(struct > thread_struct *thread) > /* This is used when switching tasks or entering/exiting vm86 mode. */ > static inline void update_sp0(struct task_struct *task) > { > - /* On x86_64, sp0

Re: [PATCH] bnxt_en: don't update cpr->rx_bytes with uninitialized length len

From: Colin King Date: Tue, 16 Jan 2018 10:22:50 + > From: Colin Ian King > > Currently in the cases where cmp_type == CMP_TYPE_RX_L2_TPA_START_CMP or > CMP_TYPE_RX_L2_TPA_END_CMP the exit path updates cpr->rx_bytes with an >

Re: [PATCH] bnxt_en: don't update cpr->rx_bytes with uninitialized length len

From: Colin King Date: Tue, 16 Jan 2018 10:22:50 + > From: Colin Ian King > > Currently in the cases where cmp_type == CMP_TYPE_RX_L2_TPA_START_CMP or > CMP_TYPE_RX_L2_TPA_END_CMP the exit path updates cpr->rx_bytes with an > uninitialized length len. Fix this by adding a new exit path

Re: [PATCH 4.4 00/87] 4.4.112-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.4.112 release. > There are 87 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.4 00/87] 4.4.112-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.4.112 release. > There are 87 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: [05/12] watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice

On Tue, Jan 16, 2018 at 02:55:57PM -0500, Lyude Paul wrote: > Thank you for this cleanup, the gotos that were in this code are really > confusing to read through! I'd recommend one very small change described > below. Assuming you add that in the next version: > > Reviewed-by: Lyude Paul

Re: [05/12] watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice

On Tue, Jan 16, 2018 at 02:55:57PM -0500, Lyude Paul wrote: > Thank you for this cleanup, the gotos that were in this code are really > confusing to read through! I'd recommend one very small change described > below. Assuming you add that in the next version: > > Reviewed-by: Lyude Paul > > On

Re: [PATCH v6 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

Hi, On 01/15/2018 09:48 AM, Sudeep Holla wrote: On Fri, Jan 12, 2018 at 06:59:13PM -0600, Jeremy Linton wrote: ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the

Re: [PATCH v6 05/12] ACPI/PPTT: Add Processor Properties Topology Table parsing

Hi, On 01/15/2018 09:48 AM, Sudeep Holla wrote: On Fri, Jan 12, 2018 at 06:59:13PM -0600, Jeremy Linton wrote: ACPI 6.2 adds a new table, which describes how processing units are related to each other in tree like fashion. Caches are also sprinkled throughout the tree and describe the

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

Oh has this patchset already been reviwed and pushed upstream? I checked patchwork beforehand and it looked like it was still pending On Tue, 2018-01-16 at 12:11 -0800, Guenter Roeck wrote: > On Tue, Jan 16, 2018 at 02:34:19PM -0500, Lyude Paul wrote: > > Sorry this review took so long! Just sent

Re: [PATCH] [v3] media: s3c-camif: fix out-of-bounds array access

Hi Arnd, Thank you for the patch. On Tuesday, 16 January 2018 18:47:24 EET Arnd Bergmann wrote: > While experimenting with older compiler versions, I ran > into a warning that no longer shows up on gcc-4.8 or newer: > > drivers/media/platform/s3c-camif/camif-capture.c: In function >

Re: [PATCH] [v3] media: s3c-camif: fix out-of-bounds array access

Hi Arnd, Thank you for the patch. On Tuesday, 16 January 2018 18:47:24 EET Arnd Bergmann wrote: > While experimenting with older compiler versions, I ran > into a warning that no longer shows up on gcc-4.8 or newer: > > drivers/media/platform/s3c-camif/camif-capture.c: In function >

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

Oh has this patchset already been reviwed and pushed upstream? I checked patchwork beforehand and it looked like it was still pending On Tue, 2018-01-16 at 12:11 -0800, Guenter Roeck wrote: > On Tue, Jan 16, 2018 at 02:34:19PM -0500, Lyude Paul wrote: > > Sorry this review took so long! Just sent

Re: [03/12] watchdog: sp5100_tco: Use request_muxed_region where possible

On Tue, Jan 16, 2018 at 02:44:23PM -0500, Lyude Paul wrote: > On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > > Use request_muxed_region for multiplexed IO memory regions. > > Also, SP5100_IO_PM_INDEX_REG/SP5100_IO_PM_DATA_REG are only > > used during initialization; it is unnecessary to

Re: [03/12] watchdog: sp5100_tco: Use request_muxed_region where possible

On Tue, Jan 16, 2018 at 02:44:23PM -0500, Lyude Paul wrote: > On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > > Use request_muxed_region for multiplexed IO memory regions. > > Also, SP5100_IO_PM_INDEX_REG/SP5100_IO_PM_DATA_REG are only > > used during initialization; it is unnecessary to

Re: [PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

Hi Ayan, On Mon, Jan 15, 2018 at 03:47:44PM +, Ayan Halder wrote: > On Tue, Jan 09, 2018 at 02:28:33PM +0100, Maxime Ripard wrote: > > On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote: > > > On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote: > > > > There's a bunch

Re: [PATCH 01/19] drm/fourcc: Add a function to tell if the format embeds alpha

Hi Ayan, On Mon, Jan 15, 2018 at 03:47:44PM +, Ayan Halder wrote: > On Tue, Jan 09, 2018 at 02:28:33PM +0100, Maxime Ripard wrote: > > On Tue, Jan 09, 2018 at 02:29:58PM +0200, Laurent Pinchart wrote: > > > On Tuesday, 9 January 2018 12:56:20 EET Maxime Ripard wrote: > > > > There's a bunch

[PATCH] Net: ethernet: ti: netcp: Fix inbound ping crash if MTU size is greater than 1500

In the receive queue for 4096 bytes fragments, the page address set in the SW data0 field of the descriptor is not the one we got when doing the reassembly in receive. The page structure was retrieved from the wrong descriptor into SW data0 which is then causing a page fault when UDP checksum is

[PATCH] Net: ethernet: ti: netcp: Fix inbound ping crash if MTU size is greater than 1500

In the receive queue for 4096 bytes fragments, the page address set in the SW data0 field of the descriptor is not the one we got when doing the reassembly in receive. The page structure was retrieved from the wrong descriptor into SW data0 which is then causing a page fault when UDP checksum is

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 09:01:49PM +0100, Borislav Petkov wrote: > On Tue, Jan 16, 2018 at 05:24:27PM +, Luck, Tony wrote: > > > I'll look for someone who can confirm the 2.5MB/core detail. > > > > Ok ... re-read the erratum. The 2.5MB/core is clear. The E5+E7 is clear. > > > > No mention

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 09:01:49PM +0100, Borislav Petkov wrote: > On Tue, Jan 16, 2018 at 05:24:27PM +, Luck, Tony wrote: > > > I'll look for someone who can confirm the 2.5MB/core detail. > > > > Ok ... re-read the erratum. The 2.5MB/core is clear. The E5+E7 is clear. > > > > No mention

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

On Tue, Jan 16, 2018 at 02:34:19PM -0500, Lyude Paul wrote: > Sorry this review took so long! Just sent off a big patchset myself to > nouveau's mailing list. > > Anyway, unfortunately it should be noted that as I've learned from this thread > that I have no machines that i know of with an actual

Re: [01/12] watchdog: sp5100_tco: Always use SP5100_IO_PM_{INDEX_REG, DATA_REG}

On Tue, Jan 16, 2018 at 02:34:19PM -0500, Lyude Paul wrote: > Sorry this review took so long! Just sent off a big patchset myself to > nouveau's mailing list. > > Anyway, unfortunately it should be noted that as I've learned from this thread > that I have no machines that i know of with an actual

Re: [PATCH] retpoline/module: Taint kernel for missing retpoline in module

On Sat, Jan 13, 2018 at 04:36:44PM +0100, Greg KH wrote: > On Sat, Jan 13, 2018 at 06:53:00AM -0800, Andi Kleen wrote: > > > > When the a module hasn't been compiled with a retpoline > > > > aware compiler, print a warning and set a taint flag. > > > > > > Isn't that caught by the "build with a

Re: [PATCH] retpoline/module: Taint kernel for missing retpoline in module

On Sat, Jan 13, 2018 at 04:36:44PM +0100, Greg KH wrote: > On Sat, Jan 13, 2018 at 06:53:00AM -0800, Andi Kleen wrote: > > > > When the a module hasn't been compiled with a retpoline > > > > aware compiler, print a warning and set a taint flag. > > > > > > Isn't that caught by the "build with a

Re: [PATCH] workqueue: Handle race between wake up and rebind

On 01/16/2018 11:05 PM, Tejun Heo wrote: Hello, Neeraj. On Mon, Jan 15, 2018 at 02:08:12PM +0530, Neeraj Upadhyay wrote: - kworker/0:0 gets chance to run on cpu1; while processing a work, it goes to sleep. However, it does not decrement pool->nr_running. This is because WORKER_REBOUND

Re: [PATCH] workqueue: Handle race between wake up and rebind

On 01/16/2018 11:05 PM, Tejun Heo wrote: Hello, Neeraj. On Mon, Jan 15, 2018 at 02:08:12PM +0530, Neeraj Upadhyay wrote: - kworker/0:0 gets chance to run on cpu1; while processing a work, it goes to sleep. However, it does not decrement pool->nr_running. This is because WORKER_REBOUND

Power domain clock warnings on recent next

Hi everyone, Anyone already noticed or started bisecting warnings coming from clk_core_disable_lock/exynos_pd_power on recent linux-next? On next-20180116, Odroid XU3 and HC1 (Exynso5422): [0.882736] EXYNOS5420 PMU initialized [0.891979] [ cut here

Power domain clock warnings on recent next

Hi everyone, Anyone already noticed or started bisecting warnings coming from clk_core_disable_lock/exynos_pd_power on recent linux-next? On next-20180116, Odroid XU3 and HC1 (Exynso5422): [0.882736] EXYNOS5420 PMU initialized [0.891979] [ cut here

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

Em Tue, Jan 16, 2018 at 08:55:55PM +0100, Jiri Olsa escreveu: > On Tue, Jan 16, 2018 at 04:45:20PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Jan 16, 2018 at 08:30:35PM +0100, Jiri Olsa escreveu: > > > On Tue, Jan 16, 2018 at 12:36:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em

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

Em Tue, Jan 16, 2018 at 08:55:55PM +0100, Jiri Olsa escreveu: > On Tue, Jan 16, 2018 at 04:45:20PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Jan 16, 2018 at 08:30:35PM +0100, Jiri Olsa escreveu: > > > On Tue, Jan 16, 2018 at 12:36:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em

Re: [08/12] watchdog: sp5100_tco: Clean up function and variable names

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use more common function and variable names. > > Use pdev instead of dev for platform device. > Use sp5100_tco_probe() instead of sp5100_tco_init() for the probe function. > Drop

Re: [08/12] watchdog: sp5100_tco: Clean up function and variable names

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use more common function and variable names. > > Use pdev instead of dev for platform device. > Use sp5100_tco_probe() instead of sp5100_tco_init() for the probe function. > Drop sp5100_tco_cleanup(); just move

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

Em Tue, Jan 16, 2018 at 08:49:09PM +0100, Jiri Olsa escreveu: > On Tue, Jan 16, 2018 at 03:26:50PM -0300, Arnaldo Carvalho de Melo wrote: > > SNIP > > > diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c > > index c0debc3f79b6..c0815a37fdb5 100644 > > --- a/tools/perf/builtin-c2c.c

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

Em Tue, Jan 16, 2018 at 08:49:09PM +0100, Jiri Olsa escreveu: > On Tue, Jan 16, 2018 at 03:26:50PM -0300, Arnaldo Carvalho de Melo wrote: > > SNIP > > > diff --git a/tools/perf/builtin-c2c.c b/tools/perf/builtin-c2c.c > > index c0debc3f79b6..c0815a37fdb5 100644 > > --- a/tools/perf/builtin-c2c.c

[PATCH] mailbox/pcc: Delete an error message for a failed memory allocation in acpi_pcc_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 20:55:22 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH] mailbox/pcc: Delete an error message for a failed memory allocation in acpi_pcc_probe()

From: Markus Elfring Date: Tue, 16 Jan 2018 20:55:22 +0100 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring --- drivers/mailbox/pcc.c | 4 +--- 1 file changed, 1 insertion(+), 3

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 05:24:27PM +, Luck, Tony wrote: > > I'll look for someone who can confirm the 2.5MB/core detail. > > Ok ... re-read the erratum. The 2.5MB/core is clear. The E5+E7 is clear. > > No mention of the platform ID, but Jia is dropping that part. > > Boris ... what

Re: [PATCH v2] x86/microcode/intel: Extend BDW late-loading with LLC size check

On Tue, Jan 16, 2018 at 05:24:27PM +, Luck, Tony wrote: > > I'll look for someone who can confirm the 2.5MB/core detail. > > Ok ... re-read the erratum. The 2.5MB/core is clear. The E5+E7 is clear. > > No mention of the platform ID, but Jia is dropping that part. > > Boris ... what

Re: [PATCH] dmaengine: avoid map_cnt overflow with CONFIG_DMA_ENGINE_RAID

On 12 Jan 2018, at 11:56, Vinod Koul wrote: On Mon, Jan 08, 2018 at 10:50:50AM -0500, Zi Yan wrote: From: Zi Yan When CONFIG_DMA_ENGINE_RAID is enabled, unmap pool size can reach to 256. But in struct dmaengine_unmap_data, map_cnt is only u8, wrapping to 0, if the

Re: [PATCH] dmaengine: avoid map_cnt overflow with CONFIG_DMA_ENGINE_RAID

On 12 Jan 2018, at 11:56, Vinod Koul wrote: On Mon, Jan 08, 2018 at 10:50:50AM -0500, Zi Yan wrote: From: Zi Yan When CONFIG_DMA_ENGINE_RAID is enabled, unmap pool size can reach to 256. But in struct dmaengine_unmap_data, map_cnt is only u8, wrapping to 0, if the unmap pool is maximally

Re: [07/12] watchdog: sp5100_tco: Use dev_ print functions where possible

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use dev_ instead of pr_ functions where possible. > > Cc: Zoltán Böszörményi > Signed-off-by: Guenter Roeck > --- > drivers/watchdog/sp5100_tco.c | 40

Re: [07/12] watchdog: sp5100_tco: Use dev_ print functions where possible

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Use dev_ instead of pr_ functions where possible. > > Cc: Zoltán Böszörményi > Signed-off-by: Guenter Roeck > --- > drivers/watchdog/sp5100_tco.c | 40 +--- > 1 file changed,

Re: [PATCH] [RESEND] spufs: use timespec64 for timestamps

On Tue, Jan 16, 2018 at 8:07 PM, Jeremy Kerr wrote: > Hi Arnd, > >> The switch log prints the tv_sec portion of timespec as a 32-bit >> number, while overflows in 2106. It also uses the timespec type, >> which is safe on 64-bit architectures, but deprecated because >> it causes

Re: [PATCH] [RESEND] spufs: use timespec64 for timestamps

On Tue, Jan 16, 2018 at 8:07 PM, Jeremy Kerr wrote: > Hi Arnd, > >> The switch log prints the tv_sec portion of timespec as a 32-bit >> number, while overflows in 2106. It also uses the timespec type, >> which is safe on 64-bit architectures, but deprecated because >> it causes overflows in 2038

Re: [06/12] watchdog: sp5100_tco: Match PCI device early

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Match PCI device in module init function, not in the probe function. > It is pointless trying to probe if we can determine early that the device > is not supported. > > Cc: Zoltán Böszörményi

Re: [06/12] watchdog: sp5100_tco: Match PCI device early

Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > Match PCI device in module init function, not in the probe function. > It is pointless trying to probe if we can determine early that the device > is not supported. > > Cc: Zoltán Böszörményi > Signed-off-by:

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

On Tue, Jan 16, 2018 at 04:45:20PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Jan 16, 2018 at 08:30:35PM +0100, Jiri Olsa escreveu: > > On Tue, Jan 16, 2018 at 12:36:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Jan 16, 2018 at 04:19:15PM +0100, Jiri Olsa escreveu: > > > > On

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

On Tue, Jan 16, 2018 at 04:45:20PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Jan 16, 2018 at 08:30:35PM +0100, Jiri Olsa escreveu: > > On Tue, Jan 16, 2018 at 12:36:21PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Jan 16, 2018 at 04:19:15PM +0100, Jiri Olsa escreveu: > > > > On

Re: [05/12] watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice

Thank you for this cleanup, the gotos that were in this code are really confusing to read through! I'd recommend one very small change described below. Assuming you add that in the next version: Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: >

Re: [05/12] watchdog: sp5100_tco: Clean up sp5100_tco_setupdevice

Thank you for this cleanup, the gotos that were in this code are really confusing to read through! I'd recommend one very small change described below. Assuming you add that in the next version: Reviewed-by: Lyude Paul On Sun, 2017-12-24 at 13:04 -0800, Guenter Roeck wrote: > There are too many

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

Hi Linus, On Tue, Jan 16, 2018 at 10:59:01AM -0800, Linus Torvalds wrote: > Yes, I'm very happy to see that this is actually not nearly as bad as > I feared it might be, Yeah, I was looking at the original PTI patches and my impression was that a lot of the complicated stuff (like setting up the

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

Hi Linus, On Tue, Jan 16, 2018 at 10:59:01AM -0800, Linus Torvalds wrote: > Yes, I'm very happy to see that this is actually not nearly as bad as > I feared it might be, Yeah, I was looking at the original PTI patches and my impression was that a lot of the complicated stuff (like setting up the

[PATCH v4 3/3] trace-cmd: Making stat to report when the stack tracer is ON

trace-cmd stat is a handy way for users to see what tracing is currently going on, but currently it does not say anything about the stack tracing. This patch makes the command to show a message when the stack tracer is ON. Signed-off-by: Vladislav Valtchev (VMware)

[PATCH v4 3/3] trace-cmd: Making stat to report when the stack tracer is ON

trace-cmd stat is a handy way for users to see what tracing is currently going on, but currently it does not say anything about the stack tracing. This patch makes the command to show a message when the stack tracer is ON. Signed-off-by: Vladislav Valtchev (VMware) --- trace-cmd.h | 2 ++

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

This patch changes both the implementation and the interface of read_proc() in trace-stack.c. First, it makes the function to read a string from the proc file and then parse it as an integer using strtol(). Then, it makes the function to return the integer read from the proc file using the int

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

This patch changes both the implementation and the interface of read_proc() in trace-stack.c. First, it makes the function to read a string from the proc file and then parse it as an integer using strtol(). Then, it makes the function to return the integer read from the proc file using the int

[PATCH v4 0/3] Integrate stack tracer status in 'stat'

This short patch series makes trace-cmd stat aware of the stack tracer: now, when the stack tracker is ON, the command will report that. Vladislav Valtchev (VMware) (3): trace-cmd: Make read_proc() to return int status via OUT arg trace-cmd: Remove the die() call from read_proc() trace-cmd:

[PATCH v4 2/3] trace-cmd: Remove the die() call from read_proc()

As trace-stack.c's read_proc() function is going to be used by trace-cmd stat, we don't want it to make the program die in case something went wrong. Therefore, this simple patch makes read_proc() to just return -1 in case the proc file was empty or read() failed with an error, instead of using

[PATCH v4 0/3] Integrate stack tracer status in 'stat'

This short patch series makes trace-cmd stat aware of the stack tracer: now, when the stack tracker is ON, the command will report that. Vladislav Valtchev (VMware) (3): trace-cmd: Make read_proc() to return int status via OUT arg trace-cmd: Remove the die() call from read_proc() trace-cmd:

[PATCH v4 2/3] trace-cmd: Remove the die() call from read_proc()

As trace-stack.c's read_proc() function is going to be used by trace-cmd stat, we don't want it to make the program die in case something went wrong. Therefore, this simple patch makes read_proc() to just return -1 in case the proc file was empty or read() failed with an error, instead of using

[PATCH v2 11/10] objtool: Even more complex static block checks

Subject: objtool: Even more complex static block checks From: Peter Zijlstra Date: Tue Jan 16 20:17:01 CET 2018 I've observed GCC transform: f() { if (!static_branch_unlikely()) return; static_assert(); A; } g() {

[PATCH v2 11/10] objtool: Even more complex static block checks

Subject: objtool: Even more complex static block checks From: Peter Zijlstra Date: Tue Jan 16 20:17:01 CET 2018 I've observed GCC transform: f() { if (!static_branch_unlikely()) return; static_assert(); A; } g() { f(); }

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