Re: WARNING in kill_block_super

Michal Hocko wrote: > On Wed 04-04-18 19:53:07, Tetsuo Handa wrote: > > Al and Michal, are you OK with this patch? > > Maybe I've misunderstood, but hasn't Al explained [1] that the > appropriate fix is in the fs code? > > [1] http://lkml.kernel.org/r/20180402143415.gc30...@zeniv.linux.org.uk

Re: WARNING in kill_block_super

Michal Hocko wrote: > On Wed 04-04-18 19:53:07, Tetsuo Handa wrote: > > Al and Michal, are you OK with this patch? > > Maybe I've misunderstood, but hasn't Al explained [1] that the > appropriate fix is in the fs code? > > [1] http://lkml.kernel.org/r/20180402143415.gc30...@zeniv.linux.org.uk

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > The qspinlock slowpath must ensure that the MCS node is fully initialised > before it can be reached by another other CPU. This is currently enforced > by using a RELEASE operation when updating the tail and also when linking > the

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

On Thu, Apr 05, 2018 at 05:59:07PM +0100, Will Deacon wrote: > The qspinlock slowpath must ensure that the MCS node is fully initialised > before it can be reached by another other CPU. This is currently enforced > by using a RELEASE operation when updating the tail and also when linking > the

[PATCH] platform/x86: asus-wireless: Fix NULL pointer dereference

When the module is removed the led workqueue is destroyed in the remove callback, before the led device is unregistered from the led subsystem. This leads to a NULL pointer derefence when the led device is unregistered automatically later as part of the module removal cleanup. Bellow is the

[PATCH] platform/x86: asus-wireless: Fix NULL pointer dereference

When the module is removed the led workqueue is destroyed in the remove callback, before the led device is unregistered from the led subsystem. This leads to a NULL pointer derefence when the led device is unregistered automatically later as part of the module removal cleanup. Bellow is the

Re: [PATCH 08/10] locking/qspinlock: Merge struct __qspinlock into struct qspinlock

On Thu, Apr 05, 2018 at 05:59:05PM +0100, Will Deacon wrote: > struct __qspinlock provides a handy union of fields so that > subcomponents of the lockword can be accessed by name, without having to > manage shifts and masks explicitly and take endianness into account. > > This is useful in

Re: [PATCH 08/10] locking/qspinlock: Merge struct __qspinlock into struct qspinlock

On Thu, Apr 05, 2018 at 05:59:05PM +0100, Will Deacon wrote: > struct __qspinlock provides a handy union of fields so that > subcomponents of the lockword can be accessed by name, without having to > manage shifts and masks explicitly and take endianness into account. > > This is useful in

Re: [PATCH v7 01/11] arm64: dts: actions: Add S900 clock management unit nodes

Hi Andreas, Since the clk driver got applied, can you please take the dts changes through linux-actions tree? Thanks, Mani On Mon, Mar 26, 2018 at 11:08:55PM +0530, Manivannan Sadhasivam wrote: > Add Actions Semi S900 Clock Management Unit (CMU) nodes > > Signed-off-by: Manivannan Sadhasivam

Re: [PATCH v7 01/11] arm64: dts: actions: Add S900 clock management unit nodes

Hi Andreas, Since the clk driver got applied, can you please take the dts changes through linux-actions tree? Thanks, Mani On Mon, Mar 26, 2018 at 11:08:55PM +0530, Manivannan Sadhasivam wrote: > Add Actions Semi S900 Clock Management Unit (CMU) nodes > > Signed-off-by: Manivannan Sadhasivam

Re: [PATCH 1/1] arm64: To remove initrd reserved area entry from memblock

On Fri, Apr 6, 2018 at 9:47 PM, Laura Abbott wrote: > Does this have an impact on anything besides accounting > in memblock? Yes, the impact is only on accounting or debugging. We were trying to reduce the reserved memory by removing initrd reserved area. After disabling

Re: [PATCH 1/1] arm64: To remove initrd reserved area entry from memblock

On Fri, Apr 6, 2018 at 9:47 PM, Laura Abbott wrote: > Does this have an impact on anything besides accounting > in memblock? Yes, the impact is only on accounting or debugging. We were trying to reduce the reserved memory by removing initrd reserved area. After disabling "keepinitrd", only way

Re: [PATCH] test/nvme/003: add test case for patch "nvme: don't send keep-alives to the discovery controller"

On Tue, Mar 27, 2018 at 11:31:47AM +0200, Johannes Thumshirn wrote: > Add a regression test for the patch titled "nvme: don't send > keep-alives to the discovery controller". > > This patch creates a local loopback nvme target and then connects to > it. If the patch is not applied we see two

Re: [PATCH] test/nvme/003: add test case for patch "nvme: don't send keep-alives to the discovery controller"

On Tue, Mar 27, 2018 at 11:31:47AM +0200, Johannes Thumshirn wrote: > Add a regression test for the patch titled "nvme: don't send > keep-alives to the discovery controller". > > This patch creates a local loopback nvme target and then connects to > it. If the patch is not applied we see two

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

Jason Ekstrand writes: > Is the given sequence number guaranteed to be hit in finite time? Certainly, it's a finite value... However, realistically, it's just like all of the other vblank interfaces where you can specify a crazy sequence and block for a very long time.

Re: [PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

Jason Ekstrand writes: > Is the given sequence number guaranteed to be hit in finite time? Certainly, it's a finite value... However, realistically, it's just like all of the other vblank interfaces where you can specify a crazy sequence and block for a very long time. So, no different from

Re: [PATCH] drivers/memory: can't open emif-asm-offsets.s for writing

2018-04-06 22:00 GMT+09:00 Anders Roxell : > Build failes due to that the directory isn't created before we execute > the build rule. > cc1: fatal error: can’t open ‘drivers/memory/emif-asm-offsets.s’ for > writing: No such file or directory compilation terminated. >

Re: [PATCH] drivers/memory: can't open emif-asm-offsets.s for writing

2018-04-06 22:00 GMT+09:00 Anders Roxell : > Build failes due to that the directory isn't created before we execute > the build rule. > cc1: fatal error: can’t open ‘drivers/memory/emif-asm-offsets.s’ for > writing: No such file or directory compilation terminated. >

Re: [PATCH ipmi/kcs_bmc v1] ipmi: kcs_bmc: optimize the data buffers allocation

On 2018-04-07 05:47, Corey Minyard wrote: On 03/15/2018 07:20 AM, Haiyue Wang wrote: Allocate a continuous memory block for the three KCS data buffers with related index assignment. I'm finally getting to this. Is there a reason you want to do this?  In general, it's better to not try to

Re: [PATCH ipmi/kcs_bmc v1] ipmi: kcs_bmc: optimize the data buffers allocation

On 2018-04-07 05:47, Corey Minyard wrote: On 03/15/2018 07:20 AM, Haiyue Wang wrote: Allocate a continuous memory block for the three KCS data buffers with related index assignment. I'm finally getting to this. Is there a reason you want to do this?  In general, it's better to not try to

Re: [PATCH] selftests/livepatch: introduce tests

On Wed, Mar 28, 2018 at 03:49:48PM -0400, Joe Lawrence wrote: > Add a few livepatch modules and simple target modules that the included > regression suite can run tests against. > > Signed-off-by: Joe Lawrence > --- > lib/Kconfig.debug |

Re: [PATCH v9 06/10] time: tick-sched: Split tick_nohz_stop_sched_tick()

On Wed, Apr 04, 2018 at 10:41:13AM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > In order to address the issue with short idle duration predictions > by the idle governor after the scheduler tick has been stopped, split > tick_nohz_stop_sched_tick()

Re: [PATCH] selftests/livepatch: introduce tests

On Wed, Mar 28, 2018 at 03:49:48PM -0400, Joe Lawrence wrote: > Add a few livepatch modules and simple target modules that the included > regression suite can run tests against. > > Signed-off-by: Joe Lawrence > --- > lib/Kconfig.debug | 12 + > lib/Makefile

Re: [PATCH v9 06/10] time: tick-sched: Split tick_nohz_stop_sched_tick()

On Wed, Apr 04, 2018 at 10:41:13AM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > In order to address the issue with short idle duration predictions > by the idle governor after the scheduler tick has been stopped, split > tick_nohz_stop_sched_tick() into two separate routines,

Re: 4.15.14 crash with iscsi target and dvd

On Fri, 2018-04-06 at 21:03 -0400, Wakko Warner wrote: > Bart Van Assche wrote: > > On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote: > > > I know now why scsi_print_command isn't doing anything. cmd->cmnd is > > > null. > > > I added a dev_printk in scsi_print_command where the 2 if

Re: 4.15.14 crash with iscsi target and dvd

On Fri, 2018-04-06 at 21:03 -0400, Wakko Warner wrote: > Bart Van Assche wrote: > > On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote: > > > I know now why scsi_print_command isn't doing anything. cmd->cmnd is > > > null. > > > I added a dev_printk in scsi_print_command where the 2 if

[RFC linux v2] init: make all setup_arch() output string to boot_command_line[]

From: yuan linyu then all arch boot parameter handled in the same way in start_kernel() Signed-off-by: yuan linyu --- v2: fix kbuild issue of parisc arch/alpha/kernel/setup.c | 4 +--- arch/arc/kernel/setup.c

[RFC linux v2] init: make all setup_arch() output string to boot_command_line[]

From: yuan linyu then all arch boot parameter handled in the same way in start_kernel() Signed-off-by: yuan linyu --- v2: fix kbuild issue of parisc arch/alpha/kernel/setup.c | 4 +--- arch/arc/kernel/setup.c| 5 + arch/arm/kernel/setup.c| 7

Re: [PATCH v5 04/10] drivers: qcom: rpmh: add RPMH helper functions

Quoting Lina Iyer (2018-04-05 09:18:28) > diff --git a/include/soc/qcom/rpmh.h b/include/soc/qcom/rpmh.h > new file mode 100644 > index ..95334d4c1ede > --- /dev/null > +++ b/include/soc/qcom/rpmh.h > @@ -0,0 +1,34 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c)

Re: [PATCH v5 04/10] drivers: qcom: rpmh: add RPMH helper functions

Quoting Lina Iyer (2018-04-05 09:18:28) > diff --git a/include/soc/qcom/rpmh.h b/include/soc/qcom/rpmh.h > new file mode 100644 > index ..95334d4c1ede > --- /dev/null > +++ b/include/soc/qcom/rpmh.h > @@ -0,0 +1,34 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (c)

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On (04/06/18 18:00), Joe Perches wrote: [..] > This finds the current two bad uses in addition to > the existing similar message for string concatenation > without a space char between concatenated fragments. > > For example: > > WARNING: break quoted strings at a space character > #3550: FILE:

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On (04/06/18 18:00), Joe Perches wrote: [..] > This finds the current two bad uses in addition to > the existing similar message for string concatenation > without a space char between concatenated fragments. > > For example: > > WARNING: break quoted strings at a space character > #3550: FILE:

Re: [PATCH v5 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

Quoting Lina Iyer (2018-04-05 09:18:26) > diff --git a/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt > b/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt > new file mode 100644 > index ..dcf71a5b302f > --- /dev/null > +++

Re: [PATCH v5 02/10] dt-bindings: introduce RPMH RSC bindings for Qualcomm SoCs

Quoting Lina Iyer (2018-04-05 09:18:26) > diff --git a/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt > b/Documentation/devicetree/bindings/soc/qcom/rpmh-rsc.txt > new file mode 100644 > index ..dcf71a5b302f > --- /dev/null > +++

[PATCH v5] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

[PATCH v5] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On Fri, Apr 06, 2018 at 05:47:29PM -0700, Dave Hansen wrote: > On 04/06/2018 05:09 PM, Ram Pai wrote: > >> - /* > >> - * Look for a protection-key-drive execute-only mapping > >> - * which is now being given permissions that are not > >> - * execute-only. Move it back to the default pkey.

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On Fri, Apr 06, 2018 at 05:47:29PM -0700, Dave Hansen wrote: > On 04/06/2018 05:09 PM, Ram Pai wrote: > >> - /* > >> - * Look for a protection-key-drive execute-only mapping > >> - * which is now being given permissions that are not > >> - * execute-only. Move it back to the default pkey.

Re: 4.15.14 crash with iscsi target and dvd

Bart Van Assche wrote: > On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote: > > I know now why scsi_print_command isn't doing anything. cmd->cmnd is null. > > I added a dev_printk in scsi_print_command where the 2 if statements return. > > Logs: > > [ 29.866415] sr 3:0:0:0: cmd->cmnd is NULL

Re: 4.15.14 crash with iscsi target and dvd

Bart Van Assche wrote: > On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote: > > I know now why scsi_print_command isn't doing anything. cmd->cmnd is null. > > I added a dev_printk in scsi_print_command where the 2 if statements return. > > Logs: > > [ 29.866415] sr 3:0:0:0: cmd->cmnd is NULL

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On Sat, 2018-04-07 at 09:33 +0900, Sergey Senozhatsky wrote: > Hi Joe, > > On (04/06/18 16:59), Joe Perches wrote: > > > > > > Can we tweak checkpatch to catch such things? > > > > Not really, no. > > > > Adding regex logic for this is tricky at best > > and probably not worth the effort

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On Sat, 2018-04-07 at 09:33 +0900, Sergey Senozhatsky wrote: > Hi Joe, > > On (04/06/18 16:59), Joe Perches wrote: > > > > > > Can we tweak checkpatch to catch such things? > > > > Not really, no. > > > > Adding regex logic for this is tricky at best > > and probably not worth the effort

Re: Differences between builtins and modules

On 02/24/2015 05:02 PM, Lucas De Marchi wrote: > On Mon, Feb 23, 2015 at 12:51 PM, Michal Marek wrote: >> On 2015-02-23 15:30, Lucas De Marchi wrote: >>> This could be particularly bad if in a kernel version an option was >>> tristate and in a new version it changed to boolean.

Re: Differences between builtins and modules

On 02/24/2015 05:02 PM, Lucas De Marchi wrote: > On Mon, Feb 23, 2015 at 12:51 PM, Michal Marek wrote: >> On 2015-02-23 15:30, Lucas De Marchi wrote: >>> This could be particularly bad if in a kernel version an option was >>> tristate and in a new version it changed to boolean. I'm not sure if

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On 04/06/2018 05:09 PM, Ram Pai wrote: >> -/* >> - * Look for a protection-key-drive execute-only mapping >> - * which is now being given permissions that are not >> - * execute-only. Move it back to the default pkey. >> - */ >> -if (vma_is_pkey_exec_only(vma) && >> -

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On 04/06/2018 05:09 PM, Ram Pai wrote: >> -/* >> - * Look for a protection-key-drive execute-only mapping >> - * which is now being given permissions that are not >> - * execute-only. Move it back to the default pkey. >> - */ >> -if (vma_is_pkey_exec_only(vma) && >> -

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

Hi Joe, On (04/06/18 16:59), Joe Perches wrote: > > > > Can we tweak checkpatch to catch such things? > > Not really, no. > > Adding regex logic for this is tricky at best > and probably not worth the effort because of > the various bits of patch contexts aren't > necessarily visible. Agreed.

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

Hi Joe, On (04/06/18 16:59), Joe Perches wrote: > > > > Can we tweak checkpatch to catch such things? > > Not really, no. > > Adding regex logic for this is tricky at best > and probably not worth the effort because of > the various bits of patch contexts aren't > necessarily visible. Agreed.

[PATCH v5] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and

[PATCH v5] x86,sched: allow topologies where NUMA nodes share an LLC

From: Alison Schofield Intel's Skylake Server CPUs have a different LLC topology than previous generations. When in Sub-NUMA-Clustering (SNC) mode, the package is divided into two "slices", each containing half the cores, half the LLC, and one memory controller and each slice is enumerated to

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 12:00:45PM -0700, Alison Schofield wrote: > On Wed, Apr 04, 2018 at 11:42:11AM -0700, Tim Chen wrote: > > On 04/04/2018 10:38 AM, Alison Schofield wrote: > > > On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > > >> On 04/03/2018 02:12 PM, Alison Schofield wrote: >

Re: [PATCH v4] x86,sched: allow topologies where NUMA nodes share an LLC

On Wed, Apr 04, 2018 at 12:00:45PM -0700, Alison Schofield wrote: > On Wed, Apr 04, 2018 at 11:42:11AM -0700, Tim Chen wrote: > > On 04/04/2018 10:38 AM, Alison Schofield wrote: > > > On Wed, Apr 04, 2018 at 10:24:49AM -0700, Tim Chen wrote: > > >> On 04/03/2018 02:12 PM, Alison Schofield wrote: >

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On Mon, Mar 26, 2018 at 10:27:27AM -0700, Dave Hansen wrote: > > From: Dave Hansen > > I got a bug report that the following code (roughly) was > causing a SIGSEGV: > > mprotect(ptr, size, PROT_EXEC); > mprotect(ptr, size, PROT_NONE); >

Re: [PATCH 4/9] x86, pkeys: override pkey when moving away from PROT_EXEC

On Mon, Mar 26, 2018 at 10:27:27AM -0700, Dave Hansen wrote: > > From: Dave Hansen > > I got a bug report that the following code (roughly) was > causing a SIGSEGV: > > mprotect(ptr, size, PROT_EXEC); > mprotect(ptr, size, PROT_NONE); > mprotect(ptr, size, PROT_READ); >

[PATCH 0/1] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

(This is an RFC on whether this pair of ioctls seems reasonable. The code compiles, but I haven't tested it as I'm away from home this weekend.) I'm rewriting my implementation of the Vulkan EXT_display_control extension, which provides a way to signal a Vulkan fence at vblank time. I had

[PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

crtc_queue_syncobj creates a new syncobj that will get signaled at a specified vblank sequence count. crtc_get_syncobj returns the time and vblank sequence count when the syncobj was signaled. The pair of these allows use of syncobjs instead of events for monitoring vblank activity.

[PATCH 0/1] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

(This is an RFC on whether this pair of ioctls seems reasonable. The code compiles, but I haven't tested it as I'm away from home this weekend.) I'm rewriting my implementation of the Vulkan EXT_display_control extension, which provides a way to signal a Vulkan fence at vblank time. I had

[PATCH] drm: Add crtc_queue_syncobj and crtc_get_syncobj ioctls

crtc_queue_syncobj creates a new syncobj that will get signaled at a specified vblank sequence count. crtc_get_syncobj returns the time and vblank sequence count when the syncobj was signaled. The pair of these allows use of syncobjs instead of events for monitoring vblank activity.

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On Sat, 2018-04-07 at 08:52 +0900, Sergey Senozhatsky wrote: > On (04/05/18 16:55), Joe Perches wrote: > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote: > > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote: > > > > Even just git grep -1 -E '%p"$' finds %pt and %po > > > > which

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On Sat, 2018-04-07 at 08:52 +0900, Sergey Senozhatsky wrote: > On (04/05/18 16:55), Joe Perches wrote: > > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote: > > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote: > > > > Even just git grep -1 -E '%p"$' finds %pt and %po > > > > which

[GIT PULL] leaking_addresses: changes for 14.17-rc1

Hi Linus, This is your favourite noob maintainer requesting that you pretty please with sugar on top pull the leaking_addresses patch set. I have hopefully lifted my game after the abysmal effort last merge window. The script now actually runs in an acceptable time, the tree is on kernel.org

[GIT PULL] leaking_addresses: changes for 14.17-rc1

Hi Linus, This is your favourite noob maintainer requesting that you pretty please with sugar on top pull the leaking_addresses patch set. I have hopefully lifted my game after the abysmal effort last merge window. The script now actually runs in an acceptable time, the tree is on kernel.org

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On (04/05/18 16:55), Joe Perches wrote: > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote: > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote: > > > Even just git grep -1 -E '%p"$' finds %pt and %po > > > which should get fixed before somebody claims those extensions. > > > >

Re: [PATCH v4 4/9] vsprintf: Consolidate handling of unknown pointer specifiers

On (04/05/18 16:55), Joe Perches wrote: > On Thu, 2018-04-05 at 16:45 -0700, Joe Perches wrote: > > On Thu, 2018-04-05 at 16:25 +0200, Rasmus Villemoes wrote: > > > Even just git grep -1 -E '%p"$' finds %pt and %po > > > which should get fixed before somebody claims those extensions. > > > >

Re: [PATCH] sched/fair: schedutil: update only with all info available

On Fri, Apr 6, 2018 at 10:28 AM, Patrick Bellasi wrote: > Schedutil is not properly updated when the first FAIR task wakes up on a > CPU and when a RQ is (un)throttled. This is mainly due to the current > integration strategy, which relies on updates being triggered

Re: [PATCH] sched/fair: schedutil: update only with all info available

On Fri, Apr 6, 2018 at 10:28 AM, Patrick Bellasi wrote: > Schedutil is not properly updated when the first FAIR task wakes up on a > CPU and when a RQ is (un)throttled. This is mainly due to the current > integration strategy, which relies on updates being triggered implicitly > each time a

Re: 4.15.14 crash with iscsi target and dvd

Bart Van Assche wrote: > On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote: > > I know now why scsi_print_command isn't doing anything. cmd->cmnd is null. > > I added a dev_printk in scsi_print_command where the 2 if statements return. > > Logs: > > [ 29.866415] sr 3:0:0:0: cmd->cmnd is NULL

Re: 4.15.14 crash with iscsi target and dvd

Bart Van Assche wrote: > On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote: > > I know now why scsi_print_command isn't doing anything. cmd->cmnd is null. > > I added a dev_printk in scsi_print_command where the 2 if statements return. > > Logs: > > [ 29.866415] sr 3:0:0:0: cmd->cmnd is NULL

Re: [PATCH] blk-cgroup: remove entries in blkg_tree before queue release

Hi Alexandru, Thank you for the patch! Yet something to improve: [auto build test ERROR on block/for-next] [also build test ERROR on v4.16 next-20180406] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH] blk-cgroup: remove entries in blkg_tree before queue release

Hi Alexandru, Thank you for the patch! Yet something to improve: [auto build test ERROR on block/for-next] [also build test ERROR on v4.16 next-20180406] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

Re: [PATCH v7 [RESEND] 1/2] drivers: qcom: add command DB driver

Quoting Lina Iyer (2018-04-06 08:13:55) > From: Mahesh Sivasubramanian > > Command DB is a simple database in the shared memory of QCOM SoCs, that > provides information regarding shared resources. Some shared resources > in the SoC have properties that are probed

[PATCH v6] earlycon: Use a pointer table to fix __earlycon_table stride

Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") tried to fix __earlycon_table stride by forcing the earlycon_id struct alignment to 32 and asking the linker to 32-byte align the __earlycon_table symbol. This fix was based on commit 07fca0e57fca92 ("tracing: Properly align linker

Re: [PATCH v7 [RESEND] 1/2] drivers: qcom: add command DB driver

Quoting Lina Iyer (2018-04-06 08:13:55) > From: Mahesh Sivasubramanian > > Command DB is a simple database in the shared memory of QCOM SoCs, that > provides information regarding shared resources. Some shared resources > in the SoC have properties that are probed dynamically at boot by the >

[PATCH v6] earlycon: Use a pointer table to fix __earlycon_table stride

Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") tried to fix __earlycon_table stride by forcing the earlycon_id struct alignment to 32 and asking the linker to 32-byte align the __earlycon_table symbol. This fix was based on commit 07fca0e57fca92 ("tracing: Properly align linker

Re: [PATCH v7 [RESEND] 2/2] dt-bindings: introduce Command DB for QCOM SoCs

Quoting Lina Iyer (2018-04-06 08:13:56) > From: Mahesh Sivasubramanian > > Command DB provides information on shared resources like clocks, > regulators etc., probed at boot by the remote subsytem and made > available in shared memory. > > Cc: devicet...@vger.kernel.org

Re: [PATCH v7 [RESEND] 2/2] dt-bindings: introduce Command DB for QCOM SoCs

Quoting Lina Iyer (2018-04-06 08:13:56) > From: Mahesh Sivasubramanian > > Command DB provides information on shared resources like clocks, > regulators etc., probed at boot by the remote subsytem and made > available in shared memory. > > Cc: devicet...@vger.kernel.org > Signed-off-by: Mahesh

Re: [PATCH v7 [RESEND] 1/2] drivers: qcom: add command DB driver

Quoting Lina Iyer (2018-04-06 08:13:55) > From: Mahesh Sivasubramanian > > Command DB is a simple database in the shared memory of QCOM SoCs, that > provides information regarding shared resources. Some shared resources > in the SoC have properties that are probed

Re: [PATCH v7 [RESEND] 1/2] drivers: qcom: add command DB driver

Quoting Lina Iyer (2018-04-06 08:13:55) > From: Mahesh Sivasubramanian > > Command DB is a simple database in the shared memory of QCOM SoCs, that > provides information regarding shared resources. Some shared resources > in the SoC have properties that are probed dynamically at boot by the >

Re: [PATCH v3 1/4] Ktest: add email support

I just fixed them up and pulled them in myself. ;-) I also added the following on top of them (and testing this, live while testing ftrace patches and other builds). Thanks Steve! diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl index 30a4c053f98b..837fa75cbb47 100755

Re: [PATCH v3 1/4] Ktest: add email support

I just fixed them up and pulled them in myself. ;-) I also added the following on top of them (and testing this, live while testing ftrace patches and other builds). Thanks Steve! diff --git a/tools/testing/ktest/ktest.pl b/tools/testing/ktest/ktest.pl index 30a4c053f98b..837fa75cbb47 100755

Re: [PATCH] MIPS: vmlinuz: Fix compiler intrinsics location and build directly

On Thu, Apr 05, 2018 at 10:42:19PM +0100, James Hogan wrote: > On Thu, Apr 05, 2018 at 11:13:14AM +0100, Matt Redfearn wrote: > > Actually, this patch would be better inserted as patch 3 in the series > > since it can pull in the generic ashldi3 before the MIPS one is removed > > in the final

Re: [PATCH] MIPS: vmlinuz: Fix compiler intrinsics location and build directly

On Thu, Apr 05, 2018 at 10:42:19PM +0100, James Hogan wrote: > On Thu, Apr 05, 2018 at 11:13:14AM +0100, Matt Redfearn wrote: > > Actually, this patch would be better inserted as patch 3 in the series > > since it can pull in the generic ashldi3 before the MIPS one is removed > > in the final

Re: [GIT PULL] SELinux patches for v4.17

On Tue, Apr 3, 2018 at 6:37 PM, Paul Moore wrote: > > Everything passes the selinux-testsuite, but there are a few known > merge conflicts. The first is with the netdev tree and is in > net/sctp/socket.c. Unfortunately it is a bit ugly, thankfully Stephen > Rothwell has

Re: [GIT PULL] SELinux patches for v4.17

On Tue, Apr 3, 2018 at 6:37 PM, Paul Moore wrote: > > Everything passes the selinux-testsuite, but there are a few known > merge conflicts. The first is with the netdev tree and is in > net/sctp/socket.c. Unfortunately it is a bit ugly, thankfully Stephen > Rothwell has already done the heavy

Re: [PATCH v2] pstore: fix crypto dependencies without compression

On Fri, Apr 6, 2018 at 12:56 AM, Arnd Bergmann wrote: > On Fri, Apr 6, 2018 at 9:25 AM, Tobias Regnery > wrote: >> Commit 58eb5b670747 ("pstore: fix crypto dependencies") fixed up the crypto >> dependencies but missed the case when no compression is

Re: [PATCH v2] pstore: fix crypto dependencies without compression

On Fri, Apr 6, 2018 at 12:56 AM, Arnd Bergmann wrote: > On Fri, Apr 6, 2018 at 9:25 AM, Tobias Regnery > wrote: >> Commit 58eb5b670747 ("pstore: fix crypto dependencies") fixed up the crypto >> dependencies but missed the case when no compression is selected. >> >> With CONFIG_PSTORE=y,

Re: [PATCH v3 1/4] Ktest: add email support

On Fri, 6 Apr 2018 15:19:48 -0700 Tim Tianyang Chen wrote: > > The full path name needs to be here. > > > > tools/testing/ktest/ktest.pl > > > Sorry I was working on my private folder, version tracked with other > stuff. Just re-sent them. I just fixed them up

Re: [PATCH v3 1/4] Ktest: add email support

On Fri, 6 Apr 2018 15:19:48 -0700 Tim Tianyang Chen wrote: > > The full path name needs to be here. > > > > tools/testing/ktest/ktest.pl > > > Sorry I was working on my private folder, version tracked with other > stuff. Just re-sent them. I just fixed them up and pulled them in myself.

Re: x32 suspend failuer in Re: linux-next: Tree for Apr 4

Previous versions suspended/resumed fine but broke networking. I bisected networking breakage to c16add24522547bf52c189b3c0d1ab6f5c2b4375 which is slightly weird. But it modifies ACPI in strange way, so maybe not that weird. Networking breakag

Re: x32 suspend failuer in Re: linux-next: Tree for Apr 4

Previous versions suspended/resumed fine but broke networking. I bisected networking breakage to c16add24522547bf52c189b3c0d1ab6f5c2b4375 which is slightly weird. But it modifies ACPI in strange way, so maybe not that weird. Networking breakag

Re: [PATCH] Input: synaptics-rmi4 - Fix an unchecked out of memory error path

On Mon, Apr 02, 2018 at 05:52:52PM -0700, Andrew Duggan wrote: > > On 04/02/2018 07:03 AM, Christophe JAILLET wrote: > > When extending the rmi_spi buffers, we must check that no out of memory > > error occurs, otherwise we may access data above the currently allocated > > memory. > > > >

Re: [PATCH] Input: synaptics-rmi4 - Fix an unchecked out of memory error path

On Mon, Apr 02, 2018 at 05:52:52PM -0700, Andrew Duggan wrote: > > On 04/02/2018 07:03 AM, Christophe JAILLET wrote: > > When extending the rmi_spi buffers, we must check that no out of memory > > error occurs, otherwise we may access data above the currently allocated > > memory. > > > >

Re: [PATCH v2 1/2] livepatch: Initialize shadow variables safely by a custom callback

On Thu, Apr 05, 2018 at 02:23:14PM +0200, Petr Mladek wrote: > @@ -150,6 +149,23 @@ static void *__klp_shadow_get_or_alloc(void *obj, > unsigned long id, void *data, > goto exists; > } > > + new_shadow->obj = obj; > + new_shadow->id = id; > + > + if (ctor) { > +

Re: [PATCH v2 1/2] livepatch: Initialize shadow variables safely by a custom callback

On Thu, Apr 05, 2018 at 02:23:14PM +0200, Petr Mladek wrote: > @@ -150,6 +149,23 @@ static void *__klp_shadow_get_or_alloc(void *obj, > unsigned long id, void *data, > goto exists; > } > > + new_shadow->obj = obj; > + new_shadow->id = id; > + > + if (ctor) { > +

[PATCH] block/compat_ioctl: fix range check in BLKGETSIZE

kernel ulong and compat_ulong_t may not be same width. Use type directly to eliminate mismatches. This would result in truncation rather than EFBIG for 32bit mode for large disks. Signed-off-by: Khazhismel Kumykov --- block/compat_ioctl.c | 2 +- 1 file changed, 1

Re: [PATCH 4.9 000/102] 4.9.93-stable review

On Fri, Apr 06, 2018 at 03:22:41PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.93 release. > There are 102 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

[PATCH] block/compat_ioctl: fix range check in BLKGETSIZE

kernel ulong and compat_ulong_t may not be same width. Use type directly to eliminate mismatches. This would result in truncation rather than EFBIG for 32bit mode for large disks. Signed-off-by: Khazhismel Kumykov --- block/compat_ioctl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 4.9 000/102] 4.9.93-stable review

On Fri, Apr 06, 2018 at 03:22:41PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.93 release. > There are 102 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

Re: [PATCH 3.18 00/93] 3.18.103-stable review

On 04/06/2018 07:22 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.103 release. > There are 93 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/93] 3.18.103-stable review

On 04/06/2018 07:22 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.103 release. > There are 93 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

  1   2   3   4   5   6   7   8   9   10   >