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

On 5/12/2017 2:47 PM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:01:37AM -0600, Jeffrey Hugo wrote: diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d711093..8f783ba 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8219,8 +8219,19 @@ static int load_balance(int

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

On 5/12/2017 2:47 PM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:01:37AM -0600, Jeffrey Hugo wrote: diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index d711093..8f783ba 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8219,8 +8219,19 @@ static int load_balance(int

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 4-5-2017 4:28, Luis R. Rodriguez wrote: > On Wed, May 03, 2017 at 09:02:20PM +0200, Arend Van Spriel wrote: >> On 3-1-2017 18:59, Luis R. Rodriguez wrote: >>> On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote: Right question is "should we solve it without user-space help"?

Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data

On 4-5-2017 4:28, Luis R. Rodriguez wrote: > On Wed, May 03, 2017 at 09:02:20PM +0200, Arend Van Spriel wrote: >> On 3-1-2017 18:59, Luis R. Rodriguez wrote: >>> On Mon, Dec 26, 2016 at 05:35:59PM +0100, Pavel Machek wrote: Right question is "should we solve it without user-space help"?

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

On 5/12/2017 2:44 PM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:29:05AM -0600, Jeffrey Hugo wrote: 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

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

On 5/12/2017 2:44 PM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:29:05AM -0600, Jeffrey Hugo wrote: 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:

Re: [Resend][PATCH] cpufreq: intel_pstate: Document the current behavior and user interface

On Friday, May 05, 2017 11:38:42 PM Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Add a document describing the current behavior and user space > interface of the intel_pstate driver in the RST format and > drop the existing outdated intel_pstate.txt

Re: [Resend][PATCH] cpufreq: intel_pstate: Document the current behavior and user interface

On Friday, May 05, 2017 11:38:42 PM Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > Add a document describing the current behavior and user space > interface of the intel_pstate driver in the RST format and > drop the existing outdated intel_pstate.txt document. > > Also update

Re: [PATCH v2] perf/core: Avoid removing shared pmu_context on unregister

On Fri, May 12, 2017 at 01:40:37PM -0700, David Carrillo-Cisneros wrote: > On Fri, May 12, 2017 at 4:45 AM, Chris Wilson > wrote: > > In commit 1fd7e4169954 ("perf/core: Remove perf_cpu_context::unique_pmu"), > > the search for another user of the pmu_cpu_context was

Re: [PATCH v2] perf/core: Avoid removing shared pmu_context on unregister

On Fri, May 12, 2017 at 01:40:37PM -0700, David Carrillo-Cisneros wrote: > On Fri, May 12, 2017 at 4:45 AM, Chris Wilson > wrote: > > In commit 1fd7e4169954 ("perf/core: Remove perf_cpu_context::unique_pmu"), > > the search for another user of the pmu_cpu_context was removed, and so > > we

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

On Fri, May 12, 2017 at 11:01:37AM -0600, Jeffrey Hugo wrote: > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index d711093..8f783ba 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -8219,8 +8219,19 @@ static int load_balance(int this_cpu, struct rq > *this_rq, > >

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

On Fri, May 12, 2017 at 11:01:37AM -0600, Jeffrey Hugo wrote: > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index d711093..8f783ba 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -8219,8 +8219,19 @@ static int load_balance(int this_cpu, struct rq > *this_rq, > >

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > > I'm clearly not explaining things well enough. I shouldn't say > > > "corruption", I

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote: > On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > > I'm clearly not explaining things well enough. I shouldn't say > > > "corruption", I

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

On Fri, May 12, 2017 at 11:29:05AM -0600, Jeffrey Hugo wrote: > 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

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

On Fri, May 12, 2017 at 11:29:05AM -0600, Jeffrey Hugo wrote: > 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

Re: [PATCH v2] perf/core: Avoid removing shared pmu_context on unregister

> Shouldn't be cleaner to keep the check in find_pmu_context, just as it I meant in free_pmu_context

Re: [PATCH v2] perf/core: Avoid removing shared pmu_context on unregister

> Shouldn't be cleaner to keep the check in find_pmu_context, just as it I meant in free_pmu_context

Re: [PATCH v2] perf/core: Avoid removing shared pmu_context on unregister

On Fri, May 12, 2017 at 4:45 AM, Chris Wilson wrote: > In commit 1fd7e4169954 ("perf/core: Remove perf_cpu_context::unique_pmu"), > the search for another user of the pmu_cpu_context was removed, and so > we unconditionally free it during perf_pmu_unregister. This leads

Re: [PATCH v2] perf/core: Avoid removing shared pmu_context on unregister

On Fri, May 12, 2017 at 4:45 AM, Chris Wilson wrote: > In commit 1fd7e4169954 ("perf/core: Remove perf_cpu_context::unique_pmu"), > the search for another user of the pmu_cpu_context was removed, and so > we unconditionally free it during perf_pmu_unregister. This leads to > random corruption

[PATCH] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

From: Abel Vesa The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace operation to specify if registers need to saved/restored by the ftrace handler. This is needed by kgraft and possibly other ftrace-based tools, and the ARM architecture is currently

[PATCH] arm: ftrace: Adds support for CONFIG_DYNAMIC_FTRACE_WITH_REGS

From: Abel Vesa The DYNAMIC_FTRACE_WITH_REGS configuration makes it possible for a ftrace operation to specify if registers need to saved/restored by the ftrace handler. This is needed by kgraft and possibly other ftrace-based tools, and the ARM architecture is currently lacking this feature. It

[PATCH] IB/IPoIB: Delete an error message for a failed memory allocation in ipoib_dev_init_default()

From: Markus Elfring Date: Fri, 12 May 2017 22:22: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] IB/IPoIB: Delete an error message for a failed memory allocation in ipoib_dev_init_default()

From: Markus Elfring Date: Fri, 12 May 2017 22:22: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

Re: Implementing Dynamic Rerouting in Kernel

On Thu, May 11, 2017 at 6:22 PM, Florian Fainelli wrote: > What you are looking for can be done using ipset-dns from Jason: > > https://git.zx2c4.com/ipset-dns/about/ Funny to see this project coming up. I actually ported this functionality into dnsmasq directly a few weeks

Re: Implementing Dynamic Rerouting in Kernel

On Thu, May 11, 2017 at 6:22 PM, Florian Fainelli wrote: > What you are looking for can be done using ipset-dns from Jason: > > https://git.zx2c4.com/ipset-dns/about/ Funny to see this project coming up. I actually ported this functionality into dnsmasq directly a few weeks after writing

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

On Fri, May 12, 2017 at 04:05:32PM -0400, Steven Rostedt wrote: > On Fri, 12 May 2017 11:50:03 -0700 > "Paul E. McKenney" wrote: > > > 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"

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

On Fri, May 12, 2017 at 04:05:32PM -0400, Steven Rostedt wrote: > On Fri, 12 May 2017 11:50:03 -0700 > "Paul E. McKenney" wrote: > > > 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

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 09:21:06PM +0100, Russell King - ARM Linux wrote: > On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > > I'm clearly not explaining things well enough. I shouldn't say > > "corruption", I should say "malicious manipulation". The methodology > > of attacks against

**URGENT ALERT WARNING NOTIFICATION**

Dear Webmail User, Due to excess abandoned Webmail Account, Our Webmaster has decided to refresh the database and to delete inactive accounts to create space for fresh users. To verify your Webmail Account, you must reply to this email immediately and provide the information below correctly:

**URGENT ALERT WARNING NOTIFICATION**

Dear Webmail User, Due to excess abandoned Webmail Account, Our Webmaster has decided to refresh the database and to delete inactive accounts to create space for fresh users. To verify your Webmail Account, you must reply to this email immediately and provide the information below correctly:

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > I'm clearly not explaining things well enough. I shouldn't say > "corruption", I should say "malicious manipulation". The methodology > of attacks against the stack are quite different from the other kinds > of attacks like

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:30:02PM -0700, Kees Cook wrote: > I'm clearly not explaining things well enough. I shouldn't say > "corruption", I should say "malicious manipulation". The methodology > of attacks against the stack are quite different from the other kinds > of attacks like

Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

On Fri, 12 May 2017 20:35:18 +0100 Okash Khawaja wrote: > On Thu, May 11, 2017 at 02:33:14PM +0100, Alan Cox wrote: > > On Thu, 11 May 2017 09:29:14 +0100 > > Okash Khawaja wrote: > > > > > Hi Alan, > > > > > > On Wed, May 10, 2017 at

Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

On Fri, 12 May 2017 20:35:18 +0100 Okash Khawaja wrote: > On Thu, May 11, 2017 at 02:33:14PM +0100, Alan Cox wrote: > > On Thu, 11 May 2017 09:29:14 +0100 > > Okash Khawaja wrote: > > > > > Hi Alan, > > > > > > On Wed, May 10, 2017 at 08:41:51PM +0100, Alan Cox wrote: > > > > > + if

Re: [PATCH 1/2] sched: Interrupt Aware Scheduler

On 05/12/2017 12:46 PM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:04:26AM -0700, Rohit Jain wrote: 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

Re: [PATCH 1/2] sched: Interrupt Aware Scheduler

On 05/12/2017 12:46 PM, Peter Zijlstra wrote: On Fri, May 12, 2017 at 11:04:26AM -0700, Rohit Jain wrote: 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

Sie suchen ein sehr echtes Darlehen?

Suchen Sie für eine sehr echte Darlehen? Zu einem erschwinglichen Preis Rate? Verarbeitet innerhalb von 4 bis 6 Tagen. Haben Sie abgelehnt Ständig von Ihren Banken und andere Finanzinstitute? Die gute Nachricht ist, Hier !!! Wir bieten Darlehen von $ 5,000.00 Min. Bis zu $ 5.000.000,00 Max. Bei 3%

Sie suchen ein sehr echtes Darlehen?

Suchen Sie für eine sehr echte Darlehen? Zu einem erschwinglichen Preis Rate? Verarbeitet innerhalb von 4 bis 6 Tagen. Haben Sie abgelehnt Ständig von Ihren Banken und andere Finanzinstitute? Die gute Nachricht ist, Hier !!! Wir bieten Darlehen von $ 5,000.00 Min. Bis zu $ 5.000.000,00 Max. Bei 3%

Re: [PATCH V2] serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'

On Fri, May 12, 2017 at 04:35:45PM +0200, Christophe JAILLET wrote: > UARTn_FRAME_PARITY_ODD is 0x0300 > UARTn_FRAME_PARITY_EVEN is 0x0200 > So if the UART is configured for EVEN parity, it would be reported as ODD. > Fix it by correctly testing if the 2 bits are set. > > Fixes: 3afbd89c9639

Re: [PATCH V2] serial: efm32: Fix parity management in 'efm32_uart_console_get_options()'

On Fri, May 12, 2017 at 04:35:45PM +0200, Christophe JAILLET wrote: > UARTn_FRAME_PARITY_ODD is 0x0300 > UARTn_FRAME_PARITY_EVEN is 0x0200 > So if the UART is configured for EVEN parity, it would be reported as ODD. > Fix it by correctly testing if the 2 bits are set. > > Fixes: 3afbd89c9639

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

On Fri, 12 May 2017 21:49:56 +0200 Peter Zijlstra wrote: > On Fri, May 12, 2017 at 01:15:44PM -0400, Steven Rostedt wrote: > > 2) Allow for get_online_cpus() to nest > > So Thomas and me have been avoiding doing this. > > In general we avoid nested locking in the

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

On Fri, 12 May 2017 21:49:56 +0200 Peter Zijlstra wrote: > On Fri, May 12, 2017 at 01:15:44PM -0400, Steven Rostedt wrote: > > 2) Allow for get_online_cpus() to nest > > So Thomas and me have been avoiding doing this. > > In general we avoid nested locking in the kernel. Nested locking

Re: [PATCH 3/6] dt-bindings: serial: fsl-lpuart: add i.MX7ULP support

On Tue, May 09, 2017 at 03:50:45PM +0800, Dong Aisheng wrote: > The lpuart of imx7ulp is basically the same as ls1021a. It's also > 32 bit width register, but unlike ls1021a, it's little endian. > Besides that, imx7ulp lpuart has a minor different register layout > from ls1021a. > > Cc:

Re: [PATCH 3/6] dt-bindings: serial: fsl-lpuart: add i.MX7ULP support

On Tue, May 09, 2017 at 03:50:45PM +0800, Dong Aisheng wrote: > The lpuart of imx7ulp is basically the same as ls1021a. It's also > 32 bit width register, but unlike ls1021a, it's little endian. > Besides that, imx7ulp lpuart has a minor different register layout > from ls1021a. > > Cc:

Re: [PATCH v2] dt-bindings: power: New bindings for ltc3651-charger

On Tue, May 09, 2017 at 07:36:30AM +0200, Mike Looijmans wrote: > This adds the devicetree bindings documentation for the LTC3651 battery > charger. > > Signed-off-by: Mike Looijmans > --- > v2: Add "lltc," vendor prefix to gpios > Expand irq paragraph > >

Re: [PATCH v2] dt-bindings: power: New bindings for ltc3651-charger

On Tue, May 09, 2017 at 07:36:30AM +0200, Mike Looijmans wrote: > This adds the devicetree bindings documentation for the LTC3651 battery > charger. > > Signed-off-by: Mike Looijmans > --- > v2: Add "lltc," vendor prefix to gpios > Expand irq paragraph > >

Re: Threads stuck in zap_pid_ns_processes()

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

Re: Threads stuck in zap_pid_ns_processes()

Guenter Roeck writes: > Hi Eric, > > On Fri, May 12, 2017 at 12:33:01PM -0500, Eric W. Biederman wrote: >> 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

Re: [PATCH] staging: rtl8192u: Convert __le16 to cpu before casting to u32

> > Since there was no news for a while, I figured I'd ask what's the status > > of this patch. I hope that's OK. Has it simply been forgotten or is > > there something blocking/unacceptable? > > I don't see it in my queue, sorry. If you can't test this, or verify > that it is correct some other

Re: [PATCH] staging: rtl8192u: Convert __le16 to cpu before casting to u32

> > Since there was no news for a while, I figured I'd ask what's the status > > of this patch. I hope that's OK. Has it simply been forgotten or is > > there something blocking/unacceptable? > > I don't see it in my queue, sorry. If you can't test this, or verify > that it is correct some other

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

On Fri, 12 May 2017 11:50:03 -0700 "Paul E. McKenney" wrote: > 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

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

On Fri, 12 May 2017 11:50:03 -0700 "Paul E. McKenney" wrote: > 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:

[PATCH] IB/usnic: Delete an error message for a failed memory allocation in usnic_transport_init()

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

[PATCH] IB/usnic: Delete an error message for a failed memory allocation in usnic_transport_init()

From: Markus Elfring Date: Fri, 12 May 2017 21:53:51 +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

Re: [PATCH 4.11 00/28] 4.11.1-stable review

On Thu, May 11, 2017 at 04:12:17PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.1 release. > There are 28 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 4.11 00/28] 4.11.1-stable review

On Thu, May 11, 2017 at 04:12:17PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.11.1 release. > There are 28 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 4.10 000/129] 4.10.16-stable review

On Thu, May 11, 2017 at 04:10:48PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.16 release. > There are 129 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 4.10 000/129] 4.10.16-stable review

On Thu, May 11, 2017 at 04:10:48PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.10.16 release. > There are 129 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: [RFC][PATCH 0/5] perf/tracing/cpuhotplug: Fix locking order

On Fri, May 12, 2017 at 01:15:44PM -0400, Steven Rostedt wrote: > 2) Allow for get_online_cpus() to nest So Thomas and me have been avoiding doing this. In general we avoid nested locking in the kernel. Nested locking makes an absolute mockery of locking rules and what all gets protected. Yes,

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

On Fri, May 12, 2017 at 01:15:44PM -0400, Steven Rostedt wrote: > 2) Allow for get_online_cpus() to nest So Thomas and me have been avoiding doing this. In general we avoid nested locking in the kernel. Nested locking makes an absolute mockery of locking rules and what all gets protected. Yes,

Re: [PATCH 4.4 00/60] 4.4.68-stable review

On Thu, May 11, 2017 at 04:12:23PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.68 release. > There are 60 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 4.4 00/60] 4.4.68-stable review

On Thu, May 11, 2017 at 04:12:23PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.68 release. > There are 60 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/39] 3.18.53-stable review

On Thu, May 11, 2017 at 03:02:35PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.53 release. > There are 39 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 1/2] sched: Interrupt Aware Scheduler

On Fri, May 12, 2017 at 11:04:26AM -0700, Rohit Jain wrote: > 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

Re: [PATCH 3.18 00/39] 3.18.53-stable review

On Thu, May 11, 2017 at 03:02:35PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.53 release. > There are 39 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 1/2] sched: Interrupt Aware Scheduler

On Fri, May 12, 2017 at 11:04:26AM -0700, Rohit Jain wrote: > 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

[patch v2 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

This patch fixes the issue where TTY-migrated synths would take a while to shut up after hitting numpad enter key. When calling synth_flush, even though XOFF character is sent as high priority, data buffered in TTY layer is still sent to the synth. This patch flushes that buffered data when

[patch v2 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

This patch fixes the issue where TTY-migrated synths would take a while to shut up after hitting numpad enter key. When calling synth_flush, even though XOFF character is sent as high priority, data buffered in TTY layer is still sent to the synth. This patch flushes that buffered data when

Re: Threads stuck in zap_pid_ns_processes()

Hi Eric, On Fri, May 12, 2017 at 12:33:01PM -0500, Eric W. Biederman wrote: > 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

Re: Threads stuck in zap_pid_ns_processes()

Hi Eric, On Fri, May 12, 2017 at 12:33:01PM -0500, Eric W. Biederman wrote: > 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: >

Re: [PATCH] [media] cec: improve MEDIA_CEC_RC dependencies

On Fri, May 12, 2017 at 12:00 PM, Hans Verkuil wrote: > On 05/12/17 11:49, Arnd Bergmann wrote: >> I can probably come up with a workaround, but haven't completely thought >> through all the combinations yet. Also, I assume the same fix will be needed >> for exynos, though

Re: [PATCH] [media] cec: improve MEDIA_CEC_RC dependencies

On Fri, May 12, 2017 at 12:00 PM, Hans Verkuil wrote: > On 05/12/17 11:49, Arnd Bergmann wrote: >> I can probably come up with a workaround, but haven't completely thought >> through all the combinations yet. Also, I assume the same fix will be needed >> for exynos, though that has not come up

Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

On Thu, May 11, 2017 at 02:33:14PM +0100, Alan Cox wrote: > On Thu, 11 May 2017 09:29:14 +0100 > Okash Khawaja wrote: > > > Hi Alan, > > > > On Wed, May 10, 2017 at 08:41:51PM +0100, Alan Cox wrote: > > > > + if (!(tmp_termios.c_cflag & CRTSCTS)) { > > > > +

Re: [patch 1/1] staging: speakup: flush tty buffers and ensure hardware flow control

On Thu, May 11, 2017 at 02:33:14PM +0100, Alan Cox wrote: > On Thu, 11 May 2017 09:29:14 +0100 > Okash Khawaja wrote: > > > Hi Alan, > > > > On Wed, May 10, 2017 at 08:41:51PM +0100, Alan Cox wrote: > > > > + if (!(tmp_termios.c_cflag & CRTSCTS)) { > > > > +

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

On Fri, May 12, 2017 at 12:55:22PM -0500, Eric W. Biederman wrote: > 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.

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

On Fri, May 12, 2017 at 12:55:22PM -0500, Eric W. Biederman wrote: > 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.

Re: [GIT PULL] liblockdep for 4.12

Hey Ingo, Here it is, with all the headers required. The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12: Linux 4.11 (2017-04-30 19:47:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git liblockdep-fixes

Re: [GIT PULL] liblockdep for 4.12

Hey Ingo, Here it is, with all the headers required. The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12: Linux 4.11 (2017-04-30 19:47:48 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git liblockdep-fixes

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:08 PM, Linus Torvalds wrote: > On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: >> Yeah, the risk for "corrupted addr_limit" is mainly a concern for >> archs with addr_limit on the kernel stack. If I'm reading

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:08 PM, Linus Torvalds wrote: > On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: >> Yeah, the risk for "corrupted addr_limit" is mainly a concern for >> archs with addr_limit on the kernel stack. If I'm reading things >> correctly, that means, from the archs I've been

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

From: Haiyang Zhang The clean up function is updated to cover duplicate config info in files included by "source" key word in Ubuntu network config. Signed-off-by: Haiyang Zhang --- tools/hv/bondvf.sh | 21 ++--- 1 files

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

From: Haiyang Zhang The clean up function is updated to cover duplicate config info in files included by "source" key word in Ubuntu network config. Signed-off-by: Haiyang Zhang --- tools/hv/bondvf.sh | 21 ++--- 1 files changed, 18 insertions(+), 3 deletions(-) diff --git

[PATCH v2 1/2] staging: ccree: switch spaces to tabs

ssi_fips.c: fixing checkpatch.pl errors: ERROR: code indent should use tabs where possible +int rc = 0;$ ERROR: code indent should use tabs where possible +int rc = 0;$ Signed-off-by: Connor Kelleher --- drivers/staging/ccree/ssi_fips.c | 4 ++--

[PATCH v2 2/2] staging: ccree: remove trailing whitespace

ssi_fips.c: fixing checkpatch.pl errors: ERROR: trailing whitespace + * $ ERROR: trailing whitespace + * $ ERROR: trailing whitespace + * $ ERROR: trailing whitespace +This function returns the REE FIPS state. $ ERROR: trailing whitespace +It should be called by kernel module. $ ERROR:

[PATCH v2 1/2] staging: ccree: switch spaces to tabs

ssi_fips.c: fixing checkpatch.pl errors: ERROR: code indent should use tabs where possible +int rc = 0;$ ERROR: code indent should use tabs where possible +int rc = 0;$ Signed-off-by: Connor Kelleher --- drivers/staging/ccree/ssi_fips.c | 4 ++-- 1 file changed, 2

[PATCH v2 2/2] staging: ccree: remove trailing whitespace

ssi_fips.c: fixing checkpatch.pl errors: ERROR: trailing whitespace + * $ ERROR: trailing whitespace + * $ ERROR: trailing whitespace + * $ ERROR: trailing whitespace +This function returns the REE FIPS state. $ ERROR: trailing whitespace +It should be called by kernel module. $ ERROR:

[PATCH] MAINTAINERS: Update SPI NOR subsystem git repositories

SPI NOR branches are now hosted on MTD repos, spi-nor/next is on l2-mtd and spi-nor/fixes will be on linux-mtd. Signed-off-by: Cyrille Pitchen --- Hi all, this is the same patch as for the NAND subsystem migration. Hence same question: how de we specify the branches?

[PATCH] MAINTAINERS: Update SPI NOR subsystem git repositories

SPI NOR branches are now hosted on MTD repos, spi-nor/next is on l2-mtd and spi-nor/fixes will be on linux-mtd. Signed-off-by: Cyrille Pitchen --- Hi all, this is the same patch as for the NAND subsystem migration. Hence same question: how de we specify the branches? I don't see any entry for

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

On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > 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

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01:59PM -0700, Kees Cook wrote: > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's an issue for arm,

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

On Fri, May 12, 2017 at 02:59:48PM -0400, Nicolas Pitre wrote: > 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

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01:59PM -0700, Kees Cook wrote: > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's an issue for arm,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: > > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Fri, May 12, 2017 at 12:01 PM, Kees Cook wrote: > > Yeah, the risk for "corrupted addr_limit" is mainly a concern for > archs with addr_limit on the kernel stack. If I'm reading things > correctly, that means, from the archs I've been paying closer > attention to, it's an issue for arm, mips,

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:54 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 22:34:31 -0700 > Kees Cook wrote: > >> On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky >> wrote: >> > On Thu, 11 May 2017 16:44:07 -0700

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

On Thu, May 11, 2017 at 10:54 PM, Martin Schwidefsky wrote: > On Thu, 11 May 2017 22:34:31 -0700 > Kees Cook wrote: > >> On Thu, May 11, 2017 at 10:28 PM, Martin Schwidefsky >> wrote: >> > On Thu, 11 May 2017 16:44:07 -0700 >> > Linus Torvalds wrote: >> > >> >> On Thu, May 11, 2017 at 4:17 PM,

Re: [PATCH] MAINTAINERS: remove self from GPIO maintainers

On Fri, May 12, 2017 at 8:01 PM, Alexandre Courbot wrote: > From: Alexandre Courbot > > I have not been able to dedicate time to the GPIO subsystem since quite > some time, and I don't see the situation improving in the near future. > Update the maintainers

Re: [PATCH] MAINTAINERS: remove self from GPIO maintainers

On Fri, May 12, 2017 at 8:01 PM, Alexandre Courbot wrote: > From: Alexandre Courbot > > I have not been able to dedicate time to the GPIO subsystem since quite > some time, and I don't see the situation improving in the near future. > Update the maintainers list to reflect this unfortunate fact.

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