[patch 09/10] timer/migration: Add tracepoints

The timer pull logic needs proper debuging aids. Add tracepoints so the hierarchical idle machinery can be diagnosed. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas Gleixner --- include/trace/events/timer_migration.h | 173

[patch 02/10] timerqueue: Document return values of timerqueue_add/del()

The return values of timerqueue_add/del() are not documented in the kernel doc comment. Add proper documentation. Signed-off-by: Anna-Maria Gleixner Cc: John Stultz Signed-off-by: Thomas Gleixner --- lib/timerqueue.c |8

[patch 09/10] timer/migration: Add tracepoints

The timer pull logic needs proper debuging aids. Add tracepoints so the hierarchical idle machinery can be diagnosed. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas Gleixner --- include/trace/events/timer_migration.h | 173 +

[patch 02/10] timerqueue: Document return values of timerqueue_add/del()

The return values of timerqueue_add/del() are not documented in the kernel doc comment. Add proper documentation. Signed-off-by: Anna-Maria Gleixner Cc: John Stultz Signed-off-by: Thomas Gleixner --- lib/timerqueue.c |8 +--- 1 file changed, 5 insertions(+), 3 deletions(-) Index:

[patch 10/10] timer: Always queue timers on the local CPU

The timer pull model is in place so we can remove the heuristics which try to guess the best target CPU at enqueue/modification time. All non pinned timers are queued on the local cpu in the seperate storage and eventually pulled at expiry time to a remote cpu. Signed-off-by: Richard Cochran

[patch 10/10] timer: Always queue timers on the local CPU

The timer pull model is in place so we can remove the heuristics which try to guess the best target CPU at enqueue/modification time. All non pinned timers are queued on the local cpu in the seperate storage and eventually pulled at expiry time to a remote cpu. Signed-off-by: Richard Cochran

[patch 03/10] timers: Rework idle logic

Storing next event and determining whether the base is idle can be done in __next_timer_interrupt(). Preparatory patch for new call sites which need this information as well. Signed-off-by: Thomas Gleixner --- kernel/time/timer.c | 43

[patch 03/10] timers: Rework idle logic

Storing next event and determining whether the base is idle can be done in __next_timer_interrupt(). Preparatory patch for new call sites which need this information as well. Signed-off-by: Thomas Gleixner --- kernel/time/timer.c | 43 --- 1 file

[patch 04/10] timer: Keep the pinned timers separate from the others

Seperate the storage space for pinned timers. This is preparatory work for changing the NOHZ timer placement from a push at enqueue time to a pull at expiry time model. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner

[patch 04/10] timer: Keep the pinned timers separate from the others

Seperate the storage space for pinned timers. This is preparatory work for changing the NOHZ timer placement from a push at enqueue time to a pull at expiry time model. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas Gleixner ---

[patch 01/10] timer: Invoke timer_start_debug() where it makes sense

The timer start debug function is called before the proper timer base is set. As a consequence the trace data contains the stale CPU and flags values. Call the debug function after setting the new base and flags. Signed-off-by: Anna-Maria Gleixner Signed-off-by:

[patch 01/10] timer: Invoke timer_start_debug() where it makes sense

The timer start debug function is called before the proper timer base is set. As a consequence the trace data contains the stale CPU and flags values. Call the debug function after setting the new base and flags. Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas Gleixner ---

[patch 08/10] timer: Implement the hierarchical pull model

Placing timers at enqueue time on a target CPU based on dubious heuristics does not make any sense: 1) Most timer wheel timers are canceled or rearmed before they expire. 2) The heuristics to predict which CPU will be busy when the timer expires are wrong by definition. So we waste

[patch 08/10] timer: Implement the hierarchical pull model

Placing timers at enqueue time on a target CPU based on dubious heuristics does not make any sense: 1) Most timer wheel timers are canceled or rearmed before they expire. 2) The heuristics to predict which CPU will be busy when the timer expires are wrong by definition. So we waste

[patch 06/10] timer: Restructure internal locking

Move the locking out from __run_timers() to the call sites, so the protected section can be extended at the call site. Preparatory patch for changing the NOHZ timer placement to a pull at expiry time model. No functional change. Signed-off-by: Richard Cochran

[patch 06/10] timer: Restructure internal locking

Move the locking out from __run_timers() to the call sites, so the protected section can be extended at the call site. Preparatory patch for changing the NOHZ timer placement to a pull at expiry time model. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner

[patch 07/10] tick/sched: Split out jiffies update helper function

The logic to get the time of the last jiffies update will be needed by the timer pull model as well. Move the code into a global funtion in anticipation of the new caller. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner

[patch 07/10] tick/sched: Split out jiffies update helper function

The logic to get the time of the last jiffies update will be needed by the timer pull model as well. Move the code into a global funtion in anticipation of the new caller. No functional change. Signed-off-by: Richard Cochran Signed-off-by: Anna-Maria Gleixner Signed-off-by: Thomas Gleixner

[patch 00/10] timer: Move from a push remote at enqueue to a pull at expiry model

Placing timers at enqueue time on a target CPU based on dubious heuristics does not make any sense: 1) Most timer wheel timers are canceled or rearmed before they expire. 2) The heuristics to predict which CPU will be busy when the timer expires are wrong by definition. So we waste

Re: [PATCH] scsi: fc: remove redundant check of an unsigned long being less than zero

On 04/14/2017 06:58 AM, Colin King wrote: > From: Colin Ian King > > The check for an unsigned long being less than zero is always false > so it is a redundant check and can be removed. > > Detected by static analysis with by PVS-Studio > > Signed-off-by: Colin Ian

[patch 00/10] timer: Move from a push remote at enqueue to a pull at expiry model

Placing timers at enqueue time on a target CPU based on dubious heuristics does not make any sense: 1) Most timer wheel timers are canceled or rearmed before they expire. 2) The heuristics to predict which CPU will be busy when the timer expires are wrong by definition. So we waste

Re: [PATCH] scsi: fc: remove redundant check of an unsigned long being less than zero

On 04/14/2017 06:58 AM, Colin King wrote: > From: Colin Ian King > > The check for an unsigned long being less than zero is always false > so it is a redundant check and can be removed. > > Detected by static analysis with by PVS-Studio > > Signed-off-by: Colin Ian King Reviewed-by: Tyrel

Re: [PATCH 4.10 00/29] 4.10.11-stable review

On 04/16/2017 07:37 AM, kernelci.org bot wrote: > stable-rc/linux-4.10.y boot: 102 boots: 5 failed, 96 passed with 1 offline > (v4.10.10-30-ge78d0ce7bd97) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.10.y/kernel/v4.10.10-30-ge78d0ce7bd97/ > Full Build

Re: [PATCH 4.10 00/29] 4.10.11-stable review

On 04/16/2017 07:37 AM, kernelci.org bot wrote: > stable-rc/linux-4.10.y boot: 102 boots: 5 failed, 96 passed with 1 offline > (v4.10.10-30-ge78d0ce7bd97) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.10.y/kernel/v4.10.10-30-ge78d0ce7bd97/ > Full Build

Re: [PATCH 4.4 00/18] 4.4.62-stable review

On 04/16/2017 06:57 AM, kernelci.org bot wrote: > stable-rc/linux-4.4.y boot: 87 boots: 2 failed, 82 passed with 3 offline > (v4.4.61-19-ge153e9e2397b) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.61-19-ge153e9e2397b/ > Full Build Summary:

Re: [PATCH 4.4 00/18] 4.4.62-stable review

On 04/16/2017 06:57 AM, kernelci.org bot wrote: > stable-rc/linux-4.4.y boot: 87 boots: 2 failed, 82 passed with 3 offline > (v4.4.61-19-ge153e9e2397b) > > Full Boot Summary: > https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.61-19-ge153e9e2397b/ > Full Build Summary:

[PATCH v3 2/2] scsi: storvsc: Add support for FC rport.

Included in the current storvsc driver for Hyper-V is the ability to access luns on an FC fabric via a virtualized fiber channel adapter exposed by the Hyper-V host. The driver also attaches to the FC transport to allow host and port names to be published under /sys/class/fc_host/hostX. Current

[PATCH v3 2/2] scsi: storvsc: Add support for FC rport.

Included in the current storvsc driver for Hyper-V is the ability to access luns on an FC fabric via a virtualized fiber channel adapter exposed by the Hyper-V host. The driver also attaches to the FC transport to allow host and port names to be published under /sys/class/fc_host/hostX. Current

[PATCH v3 0/2] scsi: storvsc: Add support for FC rport

The updated patch set provides a way for drivers ( specifically storvsc in this case ) that expose virturalized fc devices but that do not expose rports to be manually scanned. This is done via creating a pseudo rport in storvsc and a corresponding dummy initiator rport role in the fc transport.

[PATCH v3 0/2] scsi: storvsc: Add support for FC rport

The updated patch set provides a way for drivers ( specifically storvsc in this case ) that expose virturalized fc devices but that do not expose rports to be manually scanned. This is done via creating a pseudo rport in storvsc and a corresponding dummy initiator rport role in the fc transport.

[PATCH v3 1/2] scsi: scsi_transport_fc: Add dummy initiator role to rport

This patch allows scsi drivers that expose virturalized fibre channel devices but that do not expose rports to successfully rescan the scsi bus via echo "- - -" > /sys/class/scsi_host/hostX/scan. Drivers can create a pseudo rport and indicate FC_PORT_ROLE_FCP_DUMMY_INITIATOR as the rport's role in

[PATCH v3 1/2] scsi: scsi_transport_fc: Add dummy initiator role to rport

This patch allows scsi drivers that expose virturalized fibre channel devices but that do not expose rports to successfully rescan the scsi bus via echo "- - -" > /sys/class/scsi_host/hostX/scan. Drivers can create a pseudo rport and indicate FC_PORT_ROLE_FCP_DUMMY_INITIATOR as the rport's role in

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

Hi Aneesh, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170413] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

Hi Aneesh, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170413] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

On Mon, Apr 17, 2017 at 02:31:28AM -0700, Jiada Wang wrote: > On 04/10/2017 12:44 AM, Jiri Olsa wrote: > > On Sun, Apr 09, 2017 at 07:43:15PM -0700, Jiada Wang wrote: > > > Hello Jiri > > > > > > On 04/09/2017 10:27 AM, Jiri Olsa wrote: > > > > On Tue, Apr 04, 2017 at 11:25:44PM -0700,

Re: [PATCH v3 1/1] perf tools: fix perf build with ARCH=x86_64

On Mon, Apr 17, 2017 at 02:31:28AM -0700, Jiada Wang wrote: > On 04/10/2017 12:44 AM, Jiri Olsa wrote: > > On Sun, Apr 09, 2017 at 07:43:15PM -0700, Jiada Wang wrote: > > > Hello Jiri > > > > > > On 04/09/2017 10:27 AM, Jiri Olsa wrote: > > > > On Tue, Apr 04, 2017 at 11:25:44PM -0700,

Re: [PATCH 4.10 00/29] 4.10.11-stable review

On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.11 release. > There are 29 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.10 00/29] 4.10.11-stable review

On 04/16/2017 02:04 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.11 release. > There are 29 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 -mm -v8 1/3] mm, THP, swap: Delay splitting THP during swap out

On Sat, Apr 15, 2017 at 09:17:04AM +0800, Huang, Ying wrote: > Hi, Johannes, > > Johannes Weiner writes: > > > Hi Huang, > > > > I reviewed this patch based on the feedback I already provided, but > > eventually gave up and rewrote it. Please take review feedback more > >

Re: [PATCH -mm -v8 1/3] mm, THP, swap: Delay splitting THP during swap out

On Sat, Apr 15, 2017 at 09:17:04AM +0800, Huang, Ying wrote: > Hi, Johannes, > > Johannes Weiner writes: > > > Hi Huang, > > > > I reviewed this patch based on the feedback I already provided, but > > eventually gave up and rewrote it. Please take review feedback more > > seriously in the

[PATCH 2/2 v2] char: misc: use octal permissions for the proc entry

Set the permissions for /proc/misc to 0444 explicitly. At the moment, we're using 0 and have proc_create_data() convert this to 0444. This fixes a checkpatch warning. Signed-off-by: Martin Kaiser --- v2: separate patch for each checkpatch warning drivers/char/misc.c |2

[PATCH 2/2 v2] char: misc: use octal permissions for the proc entry

Set the permissions for /proc/misc to 0444 explicitly. At the moment, we're using 0 and have proc_create_data() convert this to 0444. This fixes a checkpatch warning. Signed-off-by: Martin Kaiser --- v2: separate patch for each checkpatch warning drivers/char/misc.c |2 +- 1 file

[PATCH 1/2 v2] char: misc: move the EXPORT_SYMBOL() declarations

This fixes a checkpatch warning: EXPORT_SYMBOL(foo); should immediately follow its function/variable. Signed-off-by: Martin Kaiser --- v2: separate patch for each checkpatch warning drivers/char/misc.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[PATCH 1/2 v2] char: misc: move the EXPORT_SYMBOL() declarations

This fixes a checkpatch warning: EXPORT_SYMBOL(foo); should immediately follow its function/variable. Signed-off-by: Martin Kaiser --- v2: separate patch for each checkpatch warning drivers/char/misc.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

Re: [PATCH 4.9 00/31] 4.9.23-stable review

On 04/16/2017 02:03 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.23 release. > There are 31 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/31] 4.9.23-stable review

On 04/16/2017 02:03 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.9.23 release. > There are 31 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/18] 4.4.62-stable review

On 04/16/2017 02:02 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.62 release. > There are 18 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/18] 4.4.62-stable review

On 04/16/2017 02:02 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.62 release. > There are 18 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 000/145] 3.18.49-stable review

On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.49 release. > There are 145 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. > > -

Re: [PATCH 3.18 000/145] 3.18.49-stable review

On 04/16/2017 04:48 AM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.49 release. > There are 145 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. > > -

Re: [PATCH 4/5] acpi, nfit: support "map failed" dimms

On Fri, 2017-04-14 at 09:58 -0700, Dan Williams wrote: > Stop requiring dimms be successfully mapped into a > system-physical-address range. For provisioning and hardware > remediation purposes the kernel should account for failed devices in > sysfs. If possible it should still allow management

Re: [PATCH 4/5] acpi, nfit: support "map failed" dimms

On Fri, 2017-04-14 at 09:58 -0700, Dan Williams wrote: > Stop requiring dimms be successfully mapped into a > system-physical-address range. For provisioning and hardware > remediation purposes the kernel should account for failed devices in > sysfs. If possible it should still allow management

Re: [PATCH linux 2/2] net sched actions: fix refcount decrement on error

On Sat, Apr 15, 2017 at 11:48 AM, Wolfgang Bumiller wrote: > >> On April 15, 2017 at 8:20 PM Cong Wang wrote: >> >> >> On Fri, Apr 14, 2017 at 2:08 AM, Wolfgang Bumiller >> wrote: >> > Before I do that - trying to wrap my

Re: [PATCH linux 2/2] net sched actions: fix refcount decrement on error

On Sat, Apr 15, 2017 at 11:48 AM, Wolfgang Bumiller wrote: > >> On April 15, 2017 at 8:20 PM Cong Wang wrote: >> >> >> On Fri, Apr 14, 2017 at 2:08 AM, Wolfgang Bumiller >> wrote: >> > Before I do that - trying to wrap my head around the interdependencies >> > here better to be thorough - I

RE: ID:431 -Account Reset Notification

From: Mike Nolan Sent: 17 April 2017 17:25 To: Mike Nolan Subject: ID:431 -Account Reset Notification This message is sent from a trusted sender. Account Confirmation Dear User, We received a request from you yesterday to terminate your account

RE: ID:431 -Account Reset Notification

From: Mike Nolan Sent: 17 April 2017 17:25 To: Mike Nolan Subject: ID:431 -Account Reset Notification This message is sent from a trusted sender. Account Confirmation Dear User, We received a request from you yesterday to terminate your account

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin wrote: > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote: >> On 13 April 2017 at 04:58, Gary Lin wrote: >> > This commit adds the new config options to allow the user to modify the >> > following fields in

Re: [PATCH v2] efi: Config options to assign versions in the PE-COFF header

On Thu, Apr 13, 2017 at 12:47 AM, Gary Lin wrote: > On Thu, Apr 13, 2017 at 08:26:04AM +0100, Ard Biesheuvel wrote: >> On 13 April 2017 at 04:58, Gary Lin wrote: >> > This commit adds the new config options to allow the user to modify the >> > following fields in the PE-COFF header. >> > >> >

[PATCH RESEND] dm ioctl: Remove double parentheses

The extra pair of parantheses is not needed and causes clang to generate the following warning: drivers/md/dm-ioctl.c:1776:11: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality] if ((cmd == DM_DEV_CREATE_CMD)) { ^~~~

[PATCH RESEND] dm ioctl: Remove double parentheses

The extra pair of parantheses is not needed and causes clang to generate the following warning: drivers/md/dm-ioctl.c:1776:11: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality] if ((cmd == DM_DEV_CREATE_CMD)) { ^~~~

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, Apr 17, 2017 at 10:52:29AM -0600, Logan Gunthorpe wrote: > > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > > But is it ? For example take a GPU, does it, in your scheme, need an > > additional "p2pmem" child ? Why can't the GPU driver just use some > > helper to instantiate the

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, Apr 17, 2017 at 10:52:29AM -0600, Logan Gunthorpe wrote: > > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: > > But is it ? For example take a GPU, does it, in your scheme, need an > > additional "p2pmem" child ? Why can't the GPU driver just use some > > helper to instantiate the

Re: [PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

On Mon, Apr 17, 2017 at 09:26:03AM -0700, Eric Anholt wrote: > We were returning without decrementing if the error happened, meaning > that at the next submit we wouldn't try to bring up the power domain. > > Signed-off-by: Eric Anholt This change looks good to me. It seems a

Re: [PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors out.

On Mon, Apr 17, 2017 at 09:26:03AM -0700, Eric Anholt wrote: > We were returning without decrementing if the error happened, meaning > that at the next submit we wouldn't try to bring up the power domain. > > Signed-off-by: Eric Anholt This change looks good to me. It seems a little odd to wrap

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

Hi Aneesh, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170413] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH 5/7] mm/follow_page_mask: Add support for hugepage directory entry

Hi Aneesh, [auto build test ERROR on linus/master] [also build test ERROR on v4.11-rc7 next-20170413] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

Hey, On Mon, Apr 17, 2017 at 10:34:34AM -0700, Eduardo Valentin wrote: > Hey, > > On Mon, Apr 17, 2017 at 11:31:45AM +0530, Viresh Kumar wrote: > > Hi Guys, > > > > The cpu_cooling driver is designed to use CPU frequency scaling to avoid > > high thermal states for a platform. But it wasn't

Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

Hey, On Mon, Apr 17, 2017 at 10:34:34AM -0700, Eduardo Valentin wrote: > Hey, > > On Mon, Apr 17, 2017 at 11:31:45AM +0530, Viresh Kumar wrote: > > Hi Guys, > > > > The cpu_cooling driver is designed to use CPU frequency scaling to avoid > > high thermal states for a platform. But it wasn't

Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: >> Like you said, what do we do by default is the question. Should we opt >> for safe like we are doing, or try to save some power. > I think safety is paramount. Every user should be able to boot safely > without any kernel parameters. We don't want

Re: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

On 4/17/2017 12:38 PM, Bjorn Helgaas wrote: >> Like you said, what do we do by default is the question. Should we opt >> for safe like we are doing, or try to save some power. > I think safety is paramount. Every user should be able to boot safely > without any kernel parameters. We don't want

Re: [PATCH net-next] net: mvneta: fix failed to suspend if WOL is enabled

From: Jisheng Zhang Date: Fri, 14 Apr 2017 19:07:32 +0800 > Recently, suspend/resume and WOL support are added into mvneta driver. > If we enable WOL, then we get some error as below on Marvell BG4CT > platforms during suspend: > > [ 184.149723] dpm_run_callback():

Re: [PATCH net-next] net: mvneta: fix failed to suspend if WOL is enabled

From: Jisheng Zhang Date: Fri, 14 Apr 2017 19:07:32 +0800 > Recently, suspend/resume and WOL support are added into mvneta driver. > If we enable WOL, then we get some error as below on Marvell BG4CT > platforms during suspend: > > [ 184.149723] dpm_run_callback(): mdio_bus_suspend+0x0/0x50

Re: [PATCH] coresight: etm_perf: Fix using uninitialised work

On Fri, Apr 07, 2017 at 03:48:10PM +0100, Mike Leach wrote: > Tested against the 4.11-rc1 OpenCSD perf tree - reproduced the problem > and confirmed the patch fixes it on Juno r1. > Noted that the command line > ./perf record -e cs_etm/@2001.etf/ uname > also causes the same problem, > >

Re: [PATCH] coresight: etm_perf: Fix using uninitialised work

On Fri, Apr 07, 2017 at 03:48:10PM +0100, Mike Leach wrote: > Tested against the 4.11-rc1 OpenCSD perf tree - reproduced the problem > and confirmed the patch fixes it on Juno r1. > Noted that the command line > ./perf record -e cs_etm/@2001.etf/ uname > also causes the same problem, > >

[PATCH v2] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Besides reusing existing code this removes the special case handling for 64-bit masks, which causes clang to raise a shift count overflow warning due to https://bugs.llvm.org//show_bug.cgi?id=10030. Suggested-by: Dmitry Torokhov Signed-off-by: Matthias Kaehlcke

[PATCH v2] clocksource: Use GENMASK_ULL in definition of CLOCKSOURCE_MASK

Besides reusing existing code this removes the special case handling for 64-bit masks, which causes clang to raise a shift count overflow warning due to https://bugs.llvm.org//show_bug.cgi?id=10030. Suggested-by: Dmitry Torokhov Signed-off-by: Matthias Kaehlcke --- Changes in v2: - Remove

[PATCH 2/2] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

On implementing of nested pid namespaces support in CRIU (checkpoint-restore in userspace tool) we run into the situation, that it's impossible to create a task with specific NSpid effectively. After commit 49f4d8b93ccf "pidns: Capture the user namespace and filter ns_last_pid" it is impossible to

[PATCH 1/2] nsfs: Add namespace-specific ioctl (NS_SPECIFIC_IOC)

Some namespaces types want have their own ioctls. For, example, pid namespace needs a ioctl, allowing to set vector of ns_last_pid on namespaces hierarchy. This patch introduces proc_ns_operations::ns_ioctl() to allow namespaces determine specific ioctls. Signed-off-by: Kirill Tkhai

Re: [PATCH] net/ncsi: fix checksum validation in response packet

From: Cédric Le Goater Date: Fri, 14 Apr 2017 10:56:37 +0200 > htonl was used instead of ntohl. Surely a typo. > > Signed-off-by: Cédric Le Goater I don't think so, "checksum" is of type "u32" thus is in host byte order. Therefore "htonl()" is correct.

Re: [PATCH] net/ncsi: fix checksum validation in response packet

From: Cédric Le Goater Date: Fri, 14 Apr 2017 10:56:37 +0200 > htonl was used instead of ntohl. Surely a typo. > > Signed-off-by: Cédric Le Goater I don't think so, "checksum" is of type "u32" thus is in host byte order. Therefore "htonl()" is correct.

[PATCH 2/2] pid_ns: Introduce ioctl to set vector of ns_last_pid's on ns hierarhy

On implementing of nested pid namespaces support in CRIU (checkpoint-restore in userspace tool) we run into the situation, that it's impossible to create a task with specific NSpid effectively. After commit 49f4d8b93ccf "pidns: Capture the user namespace and filter ns_last_pid" it is impossible to

[PATCH 1/2] nsfs: Add namespace-specific ioctl (NS_SPECIFIC_IOC)

Some namespaces types want have their own ioctls. For, example, pid namespace needs a ioctl, allowing to set vector of ns_last_pid on namespaces hierarchy. This patch introduces proc_ns_operations::ns_ioctl() to allow namespaces determine specific ioctls. Signed-off-by: Kirill Tkhai ---

[PATCH 0/2] nsfs: Introduce ioctl to set vector of ns_last_pid's on pid ns hierarhy

On implementing of nested pid namespaces support in CRIU (checkpoint-restore in userspace tool) we run into the situation, that it's impossible to create a task with specific NSpid effectively. After commit 49f4d8b93ccf "pidns: Capture the user namespace and filter ns_last_pid" it is impossible to

[PATCH 0/2] nsfs: Introduce ioctl to set vector of ns_last_pid's on pid ns hierarhy

On implementing of nested pid namespaces support in CRIU (checkpoint-restore in userspace tool) we run into the situation, that it's impossible to create a task with specific NSpid effectively. After commit 49f4d8b93ccf "pidns: Capture the user namespace and filter ns_last_pid" it is impossible to

Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

Hey, On Mon, Apr 17, 2017 at 11:31:45AM +0530, Viresh Kumar wrote: > Hi Guys, > > The cpu_cooling driver is designed to use CPU frequency scaling to avoid > high thermal states for a platform. But it wasn't glued really well with > cpufreq core. > > This series tries to improve interactions

Re: [PATCH V2 00/17] thermal: cpu_cooling: improve interaction with cpufreq core

Hey, On Mon, Apr 17, 2017 at 11:31:45AM +0530, Viresh Kumar wrote: > Hi Guys, > > The cpu_cooling driver is designed to use CPU frequency scaling to avoid > high thermal states for a platform. But it wasn't glued really well with > cpufreq core. > > This series tries to improve interactions

Re: [PATCH v2 net 0/2] Fix crash caused by reporting inconsistent skb->len to BQL

From: Date: Fri, 14 Apr 2017 11:19:10 +0800 > From: Sean Wang > > Changes since v1: > - fix inconsistent enumeration which easily causes the potential bug Series applied, thanks.

Re: [PATCH v2 net 0/2] Fix crash caused by reporting inconsistent skb->len to BQL

From: Date: Fri, 14 Apr 2017 11:19:10 +0800 > From: Sean Wang > > Changes since v1: > - fix inconsistent enumeration which easily causes the potential bug Series applied, thanks.

Re: [PATCH v3] net: phy: micrel: fix crash when statistic requested for KSZ9031 phy

From: Grygorii Strashko Date: Thu, 13 Apr 2017 14:11:27 -0500 > Now the command: > ethtool --phy-statistics eth0 > will cause system crash with meassage "Unable to handle kernel NULL pointer > dereference at virtual address 0010" from: > > (kszphy_get_stats)

Re: [PATCH v3] net: phy: micrel: fix crash when statistic requested for KSZ9031 phy

From: Grygorii Strashko Date: Thu, 13 Apr 2017 14:11:27 -0500 > Now the command: > ethtool --phy-statistics eth0 > will cause system crash with meassage "Unable to handle kernel NULL pointer > dereference at virtual address 0010" from: > > (kszphy_get_stats) from []

Re: [lkp-robot] [KEYS] bdf7c0f8bf: ltp.add_key02.fail

On Mon, Apr 17, 2017 at 02:26:41PM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: bdf7c0f8bf282ba44827ce3c7fd7936c8e90a18a ("KEYS: fix dereferencing > NULL payload with nonzero length") > url: >

Re: [lkp-robot] [KEYS] bdf7c0f8bf: ltp.add_key02.fail

On Mon, Apr 17, 2017 at 02:26:41PM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: bdf7c0f8bf282ba44827ce3c7fd7936c8e90a18a ("KEYS: fix dereferencing > NULL payload with nonzero length") > url: >

Re: [PATCH 2/5] acpi, nfit: add support for acpi 6.1 dimm state flags

On Fri, 2017-04-14 at 09:58 -0700, Dan Williams wrote: > Add support for the ACPI_NFIT_MEM_MAP_FAILED ("map_fail") and > ACPI_NFIT_MEM_HEALTH_ENABLED ("smart_notify") health state flags. The > "map_fail" flag identifies DIMMs that were not mapped into one or > more physical address ranges. The

Re: [PATCH 2/5] acpi, nfit: add support for acpi 6.1 dimm state flags

On Fri, 2017-04-14 at 09:58 -0700, Dan Williams wrote: > Add support for the ACPI_NFIT_MEM_MAP_FAILED ("map_fail") and > ACPI_NFIT_MEM_HEALTH_ENABLED ("smart_notify") health state flags. The > "map_fail" flag identifies DIMMs that were not mapped into one or > more physical address ranges. The

Re: drivers:watchdog:aspeed_wdt: using msleep instead of mdelay

On Mon, Apr 17, 2017 at 07:05:30PM +0200, Karim Eshapa wrote: > On Sun, 16 Apr 2017 12:53:28 -0700,Guenter Roeck wrote: > > On 04/16/2017 09:33 AM, Karim Eshapa wrote: > >> > >> that's useful for the scheduler, power management unless > >> the driver needs to delay in atomic context > >> look at

Re: drivers:watchdog:aspeed_wdt: using msleep instead of mdelay

On Mon, Apr 17, 2017 at 07:05:30PM +0200, Karim Eshapa wrote: > On Sun, 16 Apr 2017 12:53:28 -0700,Guenter Roeck wrote: > > On 04/16/2017 09:33 AM, Karim Eshapa wrote: > >> > >> that's useful for the scheduler, power management unless > >> the driver needs to delay in atomic context > >> look at

Re: [PATCH] coresight: etm_perf: Fix using uninitialised work

On Fri, Mar 31, 2017 at 07:18:51PM +0100, Suzuki K Poulose wrote: > With 4.11-rc4, the following command triggers a WARN_ON, > when a sink is not enabled. > > perf record -e cs_etm/@2001.etf/ > > [88286.547741] [ cut here ] > [88286.552332] WARNING: CPU: 3 PID:

Re: [PATCH] coresight: etm_perf: Fix using uninitialised work

On Fri, Mar 31, 2017 at 07:18:51PM +0100, Suzuki K Poulose wrote: > With 4.11-rc4, the following command triggers a WARN_ON, > when a sink is not enabled. > > perf record -e cs_etm/@2001.etf/ > > [88286.547741] [ cut here ] > [88286.552332] WARNING: CPU: 3 PID:

Re: [PATCH v4 2/2] vfio/type1: Prune vfio_pin_page_external()

On Mon, 17 Apr 2017 14:54:21 +0800 Peter Xu wrote: > On Sun, Apr 16, 2017 at 07:42:39PM -0600, Alex Williamson wrote: > > With vfio_lock_acct() testing the locked memory limit under mmap_sem, > > it's redundant to do it here for a single page. We can also reorder > > our

Re: [PATCH v4 2/2] vfio/type1: Prune vfio_pin_page_external()

On Mon, 17 Apr 2017 14:54:21 +0800 Peter Xu wrote: > On Sun, Apr 16, 2017 at 07:42:39PM -0600, Alex Williamson wrote: > > With vfio_lock_acct() testing the locked memory limit under mmap_sem, > > it's redundant to do it here for a single page. We can also reorder > > our tests such that we can

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