Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, 12 May 2017, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > > > Hello, Nicolas! > > > > > > > > Saw the TTY write

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, 12 May 2017, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > > > Hello, Nicolas! > > > > > > > > Saw the TTY write

Re: [PATCH] usb: musb: tusb6010_omap: Do not reset the other direction's packet size

On Fri, May 12, 2017 at 04:48:48PM +0300, Peter Ujfalusi wrote: > We have one register for each EP to set the maximum packet size for both > TX and RX. > If for example an RX programming would happen before the previous TX > transfer finishes we would reset the TX packet side. > > To fix this

Re: [PATCH] usb: musb: tusb6010_omap: Do not reset the other direction's packet size

On Fri, May 12, 2017 at 04:48:48PM +0300, Peter Ujfalusi wrote: > We have one register for each EP to set the maximum packet size for both > TX and RX. > If for example an RX programming would happen before the previous TX > transfer finishes we would reset the TX packet side. > > To fix this

[PATCH v2 RFC] mnt: umount mounts one by one in umount_tree()

With this patch, we don't try to umount all mounts of a tree together. Instead of this we umount them one by one. In this case, we see a significant improvement in performance for the worsе case. v2: create a sorted list of mounts, so that umount a child before its parent. The reason of this

[PATCH v2 RFC] mnt: umount mounts one by one in umount_tree()

With this patch, we don't try to umount all mounts of a tree together. Instead of this we umount them one by one. In this case, we see a significant improvement in performance for the worsе case. v2: create a sorted list of mounts, so that umount a child before its parent. The reason of this

Re: [git pull] drm fixes for v4.12-rc1

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote: > > It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 > which is new in this kernel and is preliminary support so may have a > fair bit of movement. Note: I will *not* be taking these kinds of pull

Re: [git pull] drm fixes for v4.12-rc1

On Thu, May 11, 2017 at 11:00 PM, Dave Airlie wrote: > > It also has an amdgpu fixes pull, with lots of ongoing work on Vega10 > which is new in this kernel and is preliminary support so may have a > fair bit of movement. Note: I will *not* be taking these kinds of pull requests after rc1. If

[PATCH 3/3] coresight: etb10: Improve a size determination in etb_alloc_buffer()

From: Markus Elfring Date: Fri, 12 May 2017 20:36:03 +0200 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 3/3] coresight: etb10: Improve a size determination in etb_alloc_buffer()

From: Markus Elfring Date: Fri, 12 May 2017 20:36:03 +0200 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. Signed-off-by:

[PATCH 2/3] coresight: etb10: Fix a typo in a comment line

From: Markus Elfring Date: Fri, 12 May 2017 20:30:42 +0200 Delete a character in this description for a condition check. Signed-off-by: Markus Elfring --- drivers/hwtracing/coresight/coresight-etb10.c | 2 +- 1 file changed, 1

Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

On Fri, May 12, 2017 at 02:40:27PM -0400, Steven Rostedt wrote: > On Fri, 12 May 2017 11:35:59 -0700 > "Paul E. McKenney" wrote: > > > On Fri, May 12, 2017 at 01:15:46PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > >

[PATCH 2/3] coresight: etb10: Fix a typo in a comment line

From: Markus Elfring Date: Fri, 12 May 2017 20:30:42 +0200 Delete a character in this description for a condition check. Signed-off-by: Markus Elfring --- drivers/hwtracing/coresight/coresight-etb10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

On Fri, May 12, 2017 at 02:40:27PM -0400, Steven Rostedt wrote: > On Fri, 12 May 2017 11:35:59 -0700 > "Paul E. McKenney" wrote: > > > On Fri, May 12, 2017 at 01:15:46PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > > > > Allow get_online_cpus() to be recursive. If a

[PATCH 1/3] coresight: etb10: Delete an error message for a failed memory allocation in etb_probe()

From: Markus Elfring Date: Fri, 12 May 2017 20:23:43 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link:

[PATCH 1/3] coresight: etb10: Delete an error message for a failed memory allocation in etb_probe()

From: Markus Elfring Date: Fri, 12 May 2017 20:23:43 +0200 Omit an extra message for a memory allocation failure in this function. This issue was detected by using the Coccinelle software. Link: http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf

[PATCH 0/3] CoreSight-ETB10: Adjustments for three function implementations

From: Markus Elfring Date: Fri, 12 May 2017 20:46:54 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation in etb_probe() Fix a typo in a comment line

[PATCH 0/3] CoreSight-ETB10: Adjustments for three function implementations

From: Markus Elfring Date: Fri, 12 May 2017 20:46:54 +0200 Three update suggestions were taken into account from static source code analysis. Markus Elfring (3): Delete an error message for a failed memory allocation in etb_probe() Fix a typo in a comment line Improve a size determination

Re: [RFC][PATCH 1/5] tracing: Make sure RCU is watching before calling a stack trace

On Fri, May 12, 2017 at 02:36:19PM -0400, Steven Rostedt wrote: > On Fri, 12 May 2017 11:25:35 -0700 > "Paul E. McKenney" wrote: > > > On Fri, May 12, 2017 at 01:15:45PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > >

Re: [RFC][PATCH 1/5] tracing: Make sure RCU is watching before calling a stack trace

On Fri, May 12, 2017 at 02:36:19PM -0400, Steven Rostedt wrote: > On Fri, 12 May 2017 11:25:35 -0700 > "Paul E. McKenney" wrote: > > > On Fri, May 12, 2017 at 01:15:45PM -0400, Steven Rostedt wrote: > > > From: "Steven Rostedt (VMware)" > > > > > > As stack tracing now requires "rcu watching",

RE: [PATCH net-next] tools: hv: Add clean up for included files in Ubuntu net config

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Friday, May 12, 2017 12:20 PM > To: Haiyang Zhang ; Haiyang Zhang > > Cc: net...@vger.kernel.org; KY Srinivasan ; > o...@aepfle.de;

RE: [PATCH net-next] tools: hv: Add clean up for included files in Ubuntu net config

> -Original Message- > From: David Miller [mailto:da...@davemloft.net] > Sent: Friday, May 12, 2017 12:20 PM > To: Haiyang Zhang ; Haiyang Zhang > > Cc: net...@vger.kernel.org; KY Srinivasan ; > o...@aepfle.de; vkuzn...@redhat.com; linux-kernel@vger.kernel.org > Subject: Re: [PATCH

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, May 12, 2017 at 11:41:55AM -0700, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > > > Hello, Nicolas! > > > > > > >

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, May 12, 2017 at 11:41:55AM -0700, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > > > Hello, Nicolas! > > > > > > >

Re: [RFC][PATCH 3/5] kprobes: Take get_online_cpus() before taking jump_label_lock()

On Fri, 12 May 2017 11:39:11 -0700 "Paul E. McKenney" wrote: > On Fri, May 12, 2017 at 01:15:47PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > jump_label_lock() is taken under get_online_cpus(). Make sure that kprobes

Re: [RFC][PATCH 3/5] kprobes: Take get_online_cpus() before taking jump_label_lock()

On Fri, 12 May 2017 11:39:11 -0700 "Paul E. McKenney" wrote: > On Fri, May 12, 2017 at 01:15:47PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > jump_label_lock() is taken under get_online_cpus(). Make sure that kprobes > > follows suit. > > > > Signed-off-by: Steven

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > Hello, Nicolas! > > > > > > Saw the TTY write up LWN and figured I should send this your way. > > > It

Re: [PATCH RFC tip/core/rcu] Make SRCU be once again optional

On Fri, Apr 28, 2017 at 05:10:40PM -0700, Paul E. McKenney wrote: > On Fri, Apr 28, 2017 at 05:51:15PM -0400, Nicolas Pitre wrote: > > On Fri, 28 Apr 2017, Paul E. McKenney wrote: > > > > > Hello, Nicolas! > > > > > > Saw the TTY write up LWN and figured I should send this your way. > > > It

Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

On Fri, 12 May 2017 11:35:59 -0700 "Paul E. McKenney" wrote: > On Fri, May 12, 2017 at 01:15:46PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > Allow get_online_cpus() to be recursive. If a lock is taken while under >

Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

On Fri, 12 May 2017 11:35:59 -0700 "Paul E. McKenney" wrote: > On Fri, May 12, 2017 at 01:15:46PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > Allow get_online_cpus() to be recursive. If a lock is taken while under > > "get_online_cpus()", it can call

Re: [RFC][PATCH 3/5] kprobes: Take get_online_cpus() before taking jump_label_lock()

On Fri, May 12, 2017 at 01:15:47PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > jump_label_lock() is taken under get_online_cpus(). Make sure that kprobes > follows suit. > > Signed-off-by: Steven Rostedt (VMware) The remaining

Re: [RFC][PATCH 3/5] kprobes: Take get_online_cpus() before taking jump_label_lock()

On Fri, May 12, 2017 at 01:15:47PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > jump_label_lock() is taken under get_online_cpus(). Make sure that kprobes > follows suit. > > Signed-off-by: Steven Rostedt (VMware) The remaining three (3/5 through 5/5) look

RE: [PATCH v3 1/2] selinux: add brief info to policydb

> -Original Message- > From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux- > security-mod...@vger.kernel.org] On Behalf Of Casey Schaufler > Sent: Thursday, May 11, 2017 1:46 PM > To: Stephen Smalley ; Sebastien Buisson > ;

RE: [PATCH v3 1/2] selinux: add brief info to policydb

> -Original Message- > From: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux- > security-mod...@vger.kernel.org] On Behalf Of Casey Schaufler > Sent: Thursday, May 11, 2017 1:46 PM > To: Stephen Smalley ; Sebastien Buisson > ; linux-security-mod...@vger.kernel.org; linux-

Re: [RFC][PATCH 1/5] tracing: Make sure RCU is watching before calling a stack trace

On Fri, 12 May 2017 11:25:35 -0700 "Paul E. McKenney" wrote: > On Fri, May 12, 2017 at 01:15:45PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > As stack tracing now requires "rcu watching", force RCU to be watching

Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

On Fri, May 12, 2017 at 01:15:46PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Allow get_online_cpus() to be recursive. If a lock is taken while under > "get_online_cpus()", it can call get_online_cpus() as well, just as long as > it is never held

Re: [RFC][PATCH 1/5] tracing: Make sure RCU is watching before calling a stack trace

On Fri, 12 May 2017 11:25:35 -0700 "Paul E. McKenney" wrote: > On Fri, May 12, 2017 at 01:15:45PM -0400, Steven Rostedt wrote: > > From: "Steven Rostedt (VMware)" > > > > As stack tracing now requires "rcu watching", force RCU to be watching when > > recording a stack trace. > > > >

Re: [RFC][PATCH 2/5] cpu-hotplug: Allow get_online_cpus() to nest

On Fri, May 12, 2017 at 01:15:46PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > Allow get_online_cpus() to be recursive. If a lock is taken while under > "get_online_cpus()", it can call get_online_cpus() as well, just as long as > it is never held without being under

[PATCH] staging: rtl8712: use octal permissions

Using octal permissions instead of symbolic ones is preferred. Signed-off-by: Aleksey Kurbatov --- drivers/staging/rtl8712/os_intfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/os_intfs.c b/drivers/staging/rtl8712/os_intfs.c

[PATCH] staging: rtl8712: use octal permissions

Using octal permissions instead of symbolic ones is preferred. Signed-off-by: Aleksey Kurbatov --- drivers/staging/rtl8712/os_intfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/rtl8712/os_intfs.c b/drivers/staging/rtl8712/os_intfs.c index

Re: [RFC][PATCH 1/5] tracing: Make sure RCU is watching before calling a stack trace

On Fri, May 12, 2017 at 01:15:45PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > As stack tracing now requires "rcu watching", force RCU to be watching when > recording a stack trace. > > Signed-off-by: Steven Rostedt (VMware)

Re: [RFC][PATCH 1/5] tracing: Make sure RCU is watching before calling a stack trace

On Fri, May 12, 2017 at 01:15:45PM -0400, Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > As stack tracing now requires "rcu watching", force RCU to be watching when > recording a stack trace. > > Signed-off-by: Steven Rostedt (VMware) Assuming that you never get to

[RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD

CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago to allow a transition from the old vsyscall implementations to the new method (which simplified internal accounting and made timekeeping more precise). However, PPC and IA64 have yet to make the transition, despite in some cases me

[RFC][PATCH] time: Add warning about imminent deprecation of CONFIG_GENERIC_TIME_VSYSCALL_OLD

CONFIG_GENERIC_TIME_VSYSCALL_OLD was introduced five years ago to allow a transition from the old vsyscall implementations to the new method (which simplified internal accounting and made timekeeping more precise). However, PPC and IA64 have yet to make the transition, despite in some cases me

[PATCH v2] clockevents/tcb_clksrc: implement suspend/resume

On sama5d2, power to the core may be cut while entering suspend mode. It is necessary to save and restore the TCB registers. Signed-off-by: Alexandre Belloni --- Changes in v2: - use writel instead of __raw_writel - Document sequence - use

[PATCH v2] clockevents/tcb_clksrc: implement suspend/resume

On sama5d2, power to the core may be cut while entering suspend mode. It is necessary to save and restore the TCB registers. Signed-off-by: Alexandre Belloni --- Changes in v2: - use writel instead of __raw_writel - Document sequence - use ARRAY_SIZE(tcb_cache) instead of 3

Re: [RFC][PATCH 0/5] perf/tracing/cpuhotplug: Fix locking order

On Fri, May 12, 2017 at 01:15:44PM -0400, Steven Rostedt wrote: > NOTE: This was quickly written. The change logs and patches probably need > some loving. This is for discussion. These may become legitimate patches, > but for now, I'm seeing if this is an acceptable solution. > > Also note, I

Re: [RFC][PATCH 0/5] perf/tracing/cpuhotplug: Fix locking order

On Fri, May 12, 2017 at 01:15:44PM -0400, Steven Rostedt wrote: > NOTE: This was quickly written. The change logs and patches probably need > some loving. This is for discussion. These may become legitimate patches, > but for now, I'm seeing if this is an acceptable solution. > > Also note, I

[PATCH 0/2] Interrupt Aware Scheduler

This patch introduces Interrupt Aware Scheduler(IAS). The tests till now show an overall improvement in cases where the workload has some interrupt activity. The patch avoids CPUs which might be considered interrupt-heavy when trying to schedule threads (on the push side) in the system. Interrupt

[PATCH 2/2] tools/testing: Adding tests to showcase the efficacy of IAS

This is a simple OpenMP program which does a barrier sync at the end of each parallel for loop section. Signed-off-by: Rohit Jain --- tools/testing/selftests/openmp_barrier/Makefile | 6 + tools/testing/selftests/openmp_barrier/barrier.c | 29

[PATCH 1/2] sched: Interrupt Aware Scheduler

The patch avoids CPUs which might be considered interrupt-heavy when trying to schedule threads (on the push side) in the system. Interrupt Awareness has only been added into the fair scheduling class. It does so by, using the following algorithm:

[PATCH 0/2] Interrupt Aware Scheduler

This patch introduces Interrupt Aware Scheduler(IAS). The tests till now show an overall improvement in cases where the workload has some interrupt activity. The patch avoids CPUs which might be considered interrupt-heavy when trying to schedule threads (on the push side) in the system. Interrupt

[PATCH 2/2] tools/testing: Adding tests to showcase the efficacy of IAS

This is a simple OpenMP program which does a barrier sync at the end of each parallel for loop section. Signed-off-by: Rohit Jain --- tools/testing/selftests/openmp_barrier/Makefile | 6 + tools/testing/selftests/openmp_barrier/barrier.c | 29 2 files changed, 35

[PATCH 1/2] sched: Interrupt Aware Scheduler

The patch avoids CPUs which might be considered interrupt-heavy when trying to schedule threads (on the push side) in the system. Interrupt Awareness has only been added into the fair scheduling class. It does so by, using the following algorithm:

[REVIEW][PATCH] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes

Date: Thu, 11 May 2017 18:21:01 -0500 The code can potentially sleep for an indefinite amount of time in zap_pid_ns_processes triggering the hung task timeout, and increasing the system average. This is undesirable. Sleep with a task state of TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE

[REVIEW][PATCH] pid_ns: Sleep in TASK_INTERRUPTIBLE in zap_pid_ns_processes

Date: Thu, 11 May 2017 18:21:01 -0500 The code can potentially sleep for an indefinite amount of time in zap_pid_ns_processes triggering the hung task timeout, and increasing the system average. This is undesirable. Sleep with a task state of TASK_INTERRUPTIBLE instead of TASK_UNINTERRUPTIBLE

Re: [PATCH] x86/efi: Fix kexec kernel panic when efi=old_map is enabled

On Fri, 2017-05-12 at 17:56 +0800, joeyli wrote: > On Mon, May 08, 2017 at 12:25:23PM -0700, Sai Praneeth Prakhya wrote: > > From: Sai Praneeth > > > > Booting kexec kernel with "efi=old_map" in kernel command line hits > > kernel panic as shown below. > > > > [

Re: [PATCH] x86/efi: Fix kexec kernel panic when efi=old_map is enabled

On Fri, 2017-05-12 at 17:56 +0800, joeyli wrote: > On Mon, May 08, 2017 at 12:25:23PM -0700, Sai Praneeth Prakhya wrote: > > From: Sai Praneeth > > > > Booting kexec kernel with "efi=old_map" in kernel command line hits > > kernel panic as shown below. > > > > [0.001000] BUG: unable to

[PATCHv4] arm64/cpufeature: don't use mutex in bringup path

Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which must take the jump_label mutex. We call cpus_set_cap() in the secondary bringup path, from the idle thread where interrupts are disabled. Taking a mutex in this path "is a NONO" regardless of whether it's contended, and

[PATCHv4] arm64/cpufeature: don't use mutex in bringup path

Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which must take the jump_label mutex. We call cpus_set_cap() in the secondary bringup path, from the idle thread where interrupts are disabled. Taking a mutex in this path "is a NONO" regardless of whether it's contended, and

Re: [PATCH 3/3] f2fs: introduce io_list for serialize data/node IOs

On 05/12, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/5/12 2:36, Jaegeuk Kim wrote: > > Hi Chao, > > > > On 05/09, Chao Yu wrote: > >> From: Chao Yu > >> > >> Serialize data/node IOs by using fifo list instead of mutex lock, > >> it will help to enhance concurrency of f2fs,

Re: [PATCH 3/3] f2fs: introduce io_list for serialize data/node IOs

On 05/12, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/5/12 2:36, Jaegeuk Kim wrote: > > Hi Chao, > > > > On 05/09, Chao Yu wrote: > >> From: Chao Yu > >> > >> Serialize data/node IOs by using fifo list instead of mutex lock, > >> it will help to enhance concurrency of f2fs, meanwhile keeping LFS >

Re: Is there an recommended way to refer to bitkeepr commits?

On Mai 12 2017, Rob Landley wrote: > Last I checked I couldn't just "git push" the fullhist tree to > git.kernel.org because git graft didn't propagate right. Perhaps you could recreate them with git replace --graft. That creates replace objects that can be pushed and

Re: Is there an recommended way to refer to bitkeepr commits?

On Mai 12 2017, Rob Landley wrote: > Last I checked I couldn't just "git push" the fullhist tree to > git.kernel.org because git graft didn't propagate right. Perhaps you could recreate them with git replace --graft. That creates replace objects that can be pushed and fetched. (They are

Re: [PATCH v3] platform/x86: peaq-wmi: Add new peaq-wmi driver

On Fri, May 12, 2017 at 05:11:54PM +0200, Hans de Goede wrote: > PEAQ is a new European OEM, I've bought one of their 2-in-1 x86 > devices, which is actually quite a nice device. Under Windows it has > Dolby software for "better" sound and you can select different equalizer > presets using a

Re: [PATCH v3] platform/x86: peaq-wmi: Add new peaq-wmi driver

On Fri, May 12, 2017 at 05:11:54PM +0200, Hans de Goede wrote: > PEAQ is a new European OEM, I've bought one of their 2-in-1 x86 > devices, which is actually quite a nice device. Under Windows it has > Dolby software for "better" sound and you can select different equalizer > presets using a

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

* Bin Liu [170512 10:43]: > On Fri, May 12, 2017 at 10:21:35AM -0700, Tony Lindgren wrote: > > * Bin Liu [170512 08:24]: > > > On Fri, May 12, 2017 at 07:58:49AM -0700, Tony Lindgren wrote: > > > > OK. No better ideas except I think we should probably have a separate

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

* Bin Liu [170512 10:43]: > On Fri, May 12, 2017 at 10:21:35AM -0700, Tony Lindgren wrote: > > * Bin Liu [170512 08:24]: > > > On Fri, May 12, 2017 at 07:58:49AM -0700, Tony Lindgren wrote: > > > > OK. No better ideas except I think we should probably have a separate > > > > timer for keeping

Re: [f2fs-dev] [PATCH] f2fs: split bio cache

On 05/12, Chao Yu wrote: > On 2017/5/11 10:35, Jaegeuk Kim wrote: > > On 05/11, Chao Yu wrote: > >> On 2017/5/11 7:50, Jaegeuk Kim wrote: > >>> On 05/09, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/5/9 5:23, Jaegeuk Kim wrote: > > Hi Chao, > > > > I can't see a strong

Re: [f2fs-dev] [PATCH] f2fs: split bio cache

On 05/12, Chao Yu wrote: > On 2017/5/11 10:35, Jaegeuk Kim wrote: > > On 05/11, Chao Yu wrote: > >> On 2017/5/11 7:50, Jaegeuk Kim wrote: > >>> On 05/09, Chao Yu wrote: > Hi Jaegeuk, > > On 2017/5/9 5:23, Jaegeuk Kim wrote: > > Hi Chao, > > > > I can't see a strong

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

On Fri, May 12, 2017 at 10:21:35AM -0700, Tony Lindgren wrote: > * Bin Liu [170512 08:24]: > > On Fri, May 12, 2017 at 07:58:49AM -0700, Tony Lindgren wrote: > > > OK. No better ideas except I think we should probably have a separate > > > timer for keeping VBUS on after state

Re: [PATCH] usb-musb: keep VBUS on when device is disconnected

On Fri, May 12, 2017 at 10:21:35AM -0700, Tony Lindgren wrote: > * Bin Liu [170512 08:24]: > > On Fri, May 12, 2017 at 07:58:49AM -0700, Tony Lindgren wrote: > > > OK. No better ideas except I think we should probably have a separate > > > timer for keeping VBUS on after state changes eventually.

Re: Threads stuck in zap_pid_ns_processes()

Guenter Roeck writes: > Hi Eric, > > On Fri, May 12, 2017 at 08:26:27AM -0500, Eric W. Biederman wrote: >> Vovo Yang writes: >> >> > On Fri, May 12, 2017 at 7:19 AM, Eric W. Biederman >> > wrote: >> >> Guenter Roeck

Re: Threads stuck in zap_pid_ns_processes()

Guenter Roeck writes: > Hi Eric, > > On Fri, May 12, 2017 at 08:26:27AM -0500, Eric W. Biederman wrote: >> Vovo Yang writes: >> >> > On Fri, May 12, 2017 at 7:19 AM, Eric W. Biederman >> > wrote: >> >> Guenter Roeck writes: >> >> >> >>> What I know so far is >> >>> - We see this condition on

Re: [v3 0/9] parallelized "struct page" zeroing

From: Pasha Tatashin Date: Fri, 12 May 2017 13:24:52 -0400 > Right now it is larger, but what I suggested is to add a new optimized > routine just for this case, which would do STBI for 64-bytes but > without membar (do membar at the end of memmap_init_zone() and >

Re: [v3 0/9] parallelized "struct page" zeroing

From: Pasha Tatashin Date: Fri, 12 May 2017 13:24:52 -0400 > Right now it is larger, but what I suggested is to add a new optimized > routine just for this case, which would do STBI for 64-bytes but > without membar (do membar at the end of memmap_init_zone() and > deferred_init_memmap() > >

Support for advanced documentation around data type definitions

Hello, Some data type definitions are provided by Linux source files. How would you like to see them represented in the documentation formats which are generated by the Sphinx software? Regards, Markus

Support for advanced documentation around data type definitions

Hello, Some data type definitions are provided by Linux source files. How would you like to see them represented in the documentation formats which are generated by the Sphinx software? Regards, Markus

Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.

From: David Ahern Date: Fri, 12 May 2017 10:26:08 -0700 > On 5/12/17 8:24 AM, David Miller wrote: >> From: Jan Moskyto Matejka >> Date: Fri, 12 May 2017 13:15:10 +0200 >> >>> -int rt6_dump_route(struct rt6_info *rt, void *p_arg); >>> +int rt6_dump_route(struct

Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.

From: David Ahern Date: Fri, 12 May 2017 10:26:08 -0700 > On 5/12/17 8:24 AM, David Miller wrote: >> From: Jan Moskyto Matejka >> Date: Fri, 12 May 2017 13:15:10 +0200 >> >>> -int rt6_dump_route(struct rt6_info *rt, void *p_arg); >>> +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int

Re: [PATCHv3] arm64/cpufeature: don't use mutex in bringup path

On Fri, May 12, 2017 at 06:07:22PM +0100, Will Deacon wrote: > On Fri, May 12, 2017 at 11:15:20AM +0100, Mark Rutland wrote: > > Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which > > must take the jump_label mutex. > > > > We call cpus_set_cap() in the secondary bringup

Re: [PATCHv3] arm64/cpufeature: don't use mutex in bringup path

On Fri, May 12, 2017 at 06:07:22PM +0100, Will Deacon wrote: > On Fri, May 12, 2017 at 11:15:20AM +0100, Mark Rutland wrote: > > Currently, cpus_set_cap() calls static_branch_enable_cpuslocked(), which > > must take the jump_label mutex. > > > > We call cpus_set_cap() in the secondary bringup

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote: > On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote: >> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote: >> > I spent some time trying to figure out a workaround for the nanosecond >> > rounding, but I didn't

Re: [RFC 1/2] sched/fair: Fix load_balance() affinity redo path

On 5/12/2017 11:23 AM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:01:37AM -0600, Jeffrey Hugo wrote: Signed-off-by: Austin Christ Signed-off-by: Dietmar Eggemann Signed-off-by: Jeffrey Hugo So per that Chain

[RFC][PATCH 00/14] sched/fair: A bit of a cgroup/PELT overhaul (again)..

Hi all, So after staring at all that PELT stuff and working my way through it again: https://lkml.kernel.org/r/20170505154117.6zldxuki2fgyo...@hirez.programming.kicks-ass.net I started doing some patches to fix some of the identified broken. So here are a few too many patches that do: -

Re: [PATCH 0/3] timekeeping: Improved NOHZ frequency steering (v2)

On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote: > On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote: >> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote: >> > I spent some time trying to figure out a workaround for the nanosecond >> > rounding, but I didn't find anything that

Re: [RFC 1/2] sched/fair: Fix load_balance() affinity redo path

On 5/12/2017 11:23 AM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:01:37AM -0600, Jeffrey Hugo wrote: Signed-off-by: Austin Christ Signed-off-by: Dietmar Eggemann Signed-off-by: Jeffrey Hugo So per that Chain Austin wrote the patch, who handed it to Dietmar, who handed it to you.

[RFC][PATCH 00/14] sched/fair: A bit of a cgroup/PELT overhaul (again)..

Hi all, So after staring at all that PELT stuff and working my way through it again: https://lkml.kernel.org/r/20170505154117.6zldxuki2fgyo...@hirez.programming.kicks-ass.net I started doing some patches to fix some of the identified broken. So here are a few too many patches that do: -

[RFC][PATCH 03/14] sched/fair: Remove se->load.weight from se->avg.load_sum

Remove the load from the load_sum for sched_entities, basically turning load_sum into runnable_sum. This prepares for better reweighting of group entities. Since we now have different rules for computing load_avg, split ___update_load_avg() into two parts, ___update_load_sum() and

[RFC][PATCH 02/14] sched/fair: Add comment to calc_cfs_shares()

Explain the magic equation in calc_cfs_shares() a bit better. Signed-off-by: Peter Zijlstra (Intel) --- kernel/sched/fair.c | 61 1 file changed, 61 insertions(+) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@

[RFC][PATCH 03/14] sched/fair: Remove se->load.weight from se->avg.load_sum

Remove the load from the load_sum for sched_entities, basically turning load_sum into runnable_sum. This prepares for better reweighting of group entities. Since we now have different rules for computing load_avg, split ___update_load_avg() into two parts, ___update_load_sum() and

[RFC][PATCH 02/14] sched/fair: Add comment to calc_cfs_shares()

Explain the magic equation in calc_cfs_shares() a bit better. Signed-off-by: Peter Zijlstra (Intel) --- kernel/sched/fair.c | 61 1 file changed, 61 insertions(+) --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2633,6 +2633,67 @@

[RFC][PATCH 4/5] tracepoints: Grab get_online_cpus() before taking tracepoints_mutex

From: "Steven Rostedt (VMware)" There's places that take tracepoints_mutex while holding get_online_cpus(), and since tracepoints call jump_label code, which also takes get_online_cpus(), make sure that the tracepoints_mutex is always taken under get_online_cpus().

[RFC][PATCH 5/5] perf: Grab event_mutex before taking get_online_cpus()

From: "Steven Rostedt (VMware)" The event_mutex is a high level lock. It should never be taken under get_online_cpus() being held. Perf is the only user that does so. Move the taking of event_mutex outside of get_online_cpus() and this should solve the locking order.

Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.

On 5/12/17 8:24 AM, David Miller wrote: > From: Jan Moskyto Matejka > Date: Fri, 12 May 2017 13:15:10 +0200 > >> -int rt6_dump_route(struct rt6_info *rt, void *p_arg); >> +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int truncate); > > Please use "bool" and "true"/"false"

[RFC][PATCH 4/5] tracepoints: Grab get_online_cpus() before taking tracepoints_mutex

From: "Steven Rostedt (VMware)" There's places that take tracepoints_mutex while holding get_online_cpus(), and since tracepoints call jump_label code, which also takes get_online_cpus(), make sure that the tracepoints_mutex is always taken under get_online_cpus(). Signed-off-by: Steven Rostedt

[RFC][PATCH 5/5] perf: Grab event_mutex before taking get_online_cpus()

From: "Steven Rostedt (VMware)" The event_mutex is a high level lock. It should never be taken under get_online_cpus() being held. Perf is the only user that does so. Move the taking of event_mutex outside of get_online_cpus() and this should solve the locking order. Signed-off-by: Steven

Re: [PATCH] net: ipv6: Truncate single route when it doesn't fit into dump buffer.

On 5/12/17 8:24 AM, David Miller wrote: > From: Jan Moskyto Matejka > Date: Fri, 12 May 2017 13:15:10 +0200 > >> -int rt6_dump_route(struct rt6_info *rt, void *p_arg); >> +int rt6_dump_route(struct rt6_info *rt, void *p_arg, int truncate); > > Please use "bool" and "true"/"false" for boolean

Re: [v3 0/9] parallelized "struct page" zeroing

On 05/12/2017 12:57 PM, David Miller wrote: From: Pasha Tatashin Date: Thu, 11 May 2017 16:59:33 -0400 We should either keep memset() only for deferred struct pages as what I have in my patches. Another option is to add a new function struct_page_clear() which

Re: [PATCH v3 3/3] arm/arm64: signal SIBGUS and inject SEA Error

Hi gengdongjiu, On 05/05/17 13:31, gengdongjiu wrote: > when guest OS happen an SEA, My current solution is shown below: > > (1) host EL3 firmware firstly handle the SEA error and generate the CPER > record. > (2) EL3 firmware separately copy the esr_el3, elr_el3, SPSR_el3, > far_el3 to the

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