Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Sat, Jan 27, 2018 at 07:22:27AM +, Lihao Liang wrote: > On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney > wrote: > > On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote: > >> From: Lihao Liang > >> > >> Dear Paul, > >>

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Sat, Jan 27, 2018 at 07:22:27AM +, Lihao Liang wrote: > On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney > wrote: > > On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote: > >> From: Lihao Liang > >> > >> Dear Paul, > >> > >> This patch set implements a preemptive

Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE

On Fri 26-01-18 18:04:27, Anshuman Khandual wrote: [...] > I tried to instrument mmap_region() for a single instance of 'sed' > binary and traced all it's VMA creation. But there is no trace when > that 'anon' VMA got created which suddenly shows up during subsequent > elf_map() call eventually

Re: ppc elf_map breakage with MAP_FIXED_NOREPLACE

On Fri 26-01-18 18:04:27, Anshuman Khandual wrote: [...] > I tried to instrument mmap_region() for a single instance of 'sed' > binary and traced all it's VMA creation. But there is no trace when > that 'anon' VMA got created which suddenly shows up during subsequent > elf_map() call eventually

Re: [RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read

Hi Boris, On 30 October 2017 at 14:04, Boris Brezillon wrote: > Hi PrasannaKumar, > > On Sat, 28 Oct 2017 13:13:51 +0530 > PrasannaKumar Muralidharan wrote: > >> From: Lars-Peter Clausen >> >> Avoid sending

Re: [RFC] NAND: Optimize NAND_ECC_HW_OOB_FIRST read

Hi Boris, On 30 October 2017 at 14:04, Boris Brezillon wrote: > Hi PrasannaKumar, > > On Sat, 28 Oct 2017 13:13:51 +0530 > PrasannaKumar Muralidharan wrote: > >> From: Lars-Peter Clausen >> >> Avoid sending unnecessary READ commands to the chip. >> >> Signed-off-by: Lars-Peter Clausen >>

Re: [PATCH] ssb: Reenable PCI host on !MIPS

On Sat, Jan 27, 2018 at 06:29:18AM +0200, Kalle Valo wrote: > Krzysztof Mazur writes: > > > The commit 58eae1416b804d900014d84feadda7195007cc30 > > ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled > > CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRIDGE, which are >

Re: [PATCH] ssb: Reenable PCI host on !MIPS

On Sat, Jan 27, 2018 at 06:29:18AM +0200, Kalle Valo wrote: > Krzysztof Mazur writes: > > > The commit 58eae1416b804d900014d84feadda7195007cc30 > > ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled > > CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRIDGE, which are > > required for

Re: [PATCH RFC 01/16] prcu: Add PRCU implementation

On Thu, Jan 25, 2018 at 6:16 AM, Paul E. McKenney wrote: > On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote: >> From: Heng Zhang >> >> This RCU implementation (PRCU) is based on a fast consensus protocol >> published in the

Re: [PATCH RFC 01/16] prcu: Add PRCU implementation

On Thu, Jan 25, 2018 at 6:16 AM, Paul E. McKenney wrote: > On Tue, Jan 23, 2018 at 03:59:26PM +0800, liangli...@huawei.com wrote: >> From: Heng Zhang >> >> This RCU implementation (PRCU) is based on a fast consensus protocol >> published in the following paper: >> >> Fast Consensus Using Bounded

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney wrote: > On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote: >> From: Lihao Liang >> >> Dear Paul, >> >> This patch set implements a preemptive version of RCU (PRCU) based on

Re: [PATCH RFC 00/16] A new RCU implementation based on a fast consensus protocol

On Thu, Jan 25, 2018 at 5:53 AM, Paul E. McKenney wrote: > On Tue, Jan 23, 2018 at 03:59:25PM +0800, liangli...@huawei.com wrote: >> From: Lihao Liang >> >> Dear Paul, >> >> This patch set implements a preemptive version of RCU (PRCU) based on the >> following paper: >> >> Fast Consensus Using

[PATCH] x86: Mark hpa as a "Designated Reviewer" for the time being

Due to some unfortunate events, I have not been directly involved in the x86 kernel patch flow for a while now. I have also not been able to ramp back up by now like I had hoped to, and after reviewing what I will need to work on both internally at Intel and elsewhere in the near term, it is

[PATCH] x86: Mark hpa as a "Designated Reviewer" for the time being

Due to some unfortunate events, I have not been directly involved in the x86 kernel patch flow for a while now. I have also not been able to ramp back up by now like I had hoped to, and after reviewing what I will need to work on both internally at Intel and elsewhere in the near term, it is

Re: [PATCH v3] net: macb: Handle HRESP error

Hi David, On Sat, Jan 27, 2018 at 12:09 PM, wrote: > From: Harini Katakam > > Handle HRESP error by doing a SW reset of RX and TX and > re-initializing the descriptors, RX and TX queue pointers. > > Signed-off-by: Harini Katakam

Re: [PATCH v3] net: macb: Handle HRESP error

Hi David, On Sat, Jan 27, 2018 at 12:09 PM, wrote: > From: Harini Katakam > > Handle HRESP error by doing a SW reset of RX and TX and > re-initializing the descriptors, RX and TX queue pointers. > > Signed-off-by: Harini Katakam > Signed-off-by: Michal Simek > --- > v3 and v2 changes: >

Re: [Linaro-mm-sig] [PATCH v3] staging: android: ion: Zero CMA allocated memory

On 01/26/2018 06:04 PM, Chen Feng wrote: On 2018/1/27 1:48, Liam Mark wrote: Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly") the CMA API is now used directly and therefore the allocated memory is no longer automatically zeroed. Explicitly zero CMA allocated memory

Re: [Linaro-mm-sig] [PATCH v3] staging: android: ion: Zero CMA allocated memory

On 01/26/2018 06:04 PM, Chen Feng wrote: On 2018/1/27 1:48, Liam Mark wrote: Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly") the CMA API is now used directly and therefore the allocated memory is no longer automatically zeroed. Explicitly zero CMA allocated memory

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

Hi Jarkko, On 17 November 2017 at 19:27, Jarkko Sakkinen wrote: > On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko Sakkinen wrote: > > At least signed-off-by from PrassanaKumar is missing from the 2nd > commit. I'll add it. I had the impression that my

Re: [PATCH v2] tpm: Move Linux RNG connection to hwrng

Hi Jarkko, On 17 November 2017 at 19:27, Jarkko Sakkinen wrote: > On Fri, Nov 17, 2017 at 03:28:53PM +0200, Jarkko Sakkinen wrote: > > At least signed-off-by from PrassanaKumar is missing from the 2nd > commit. I'll add it. I had the impression that my signed-off-by will be present in this

[PATCH v3] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v3 and v2 changes:

[PATCH v3] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v3 and v2 changes: Fixed patch formatting errors Rebased on latest net-next and reinitialized

[PATCH v2] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v2: Rebased on top of

[PATCH v2] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v2: Rebased on top of

[PATCH v2] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v2: Rebased on top of latest net-next and reinitialized all rx queues.

[PATCH v2] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v2: Rebased on top of latest net-next and reinitialized all rx queues.

[PATCH v2] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v2: Rebased on top of

[PATCH v2] net: macb: Handle HRESP error

From: Harini Katakam Handle HRESP error by doing a SW reset of RX and TX and re-initializing the descriptors, RX and TX queue pointers. Signed-off-by: Harini Katakam Signed-off-by: Michal Simek --- v2: Rebased on top of latest net-next and reinitialized all rx queues.

Re: [PATCH] USB: wusbcore: remove redundant re-assignment to pointer 'dev'

On Fri, Jan 26, 2018 at 03:07:12PM +, Colin King wrote: > From: Colin Ian King > > Pointer dev is initialized and then re-assigned with the same value > a little later, hence the second assignment is redundant and can be > removed. > > Cleans up clang warning: >

Re: [PATCH] USB: wusbcore: remove redundant re-assignment to pointer 'dev'

On Fri, Jan 26, 2018 at 03:07:12PM +, Colin King wrote: > From: Colin Ian King > > Pointer dev is initialized and then re-assigned with the same value > a little later, hence the second assignment is redundant and can be > removed. > > Cleans up clang warning: >

[RFC PATCH V5 3/5] workqueue: rename unbound_attrs to attrs

Replace workqueue's unbound_attrs by attrs, so that both unbound or bound wq can use it. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo

[RFC PATCH V5 3/5] workqueue: rename unbound_attrs to attrs

Replace workqueue's unbound_attrs by attrs, so that both unbound or bound wq can use it. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo Cc: Lai Jiangshan Cc: kernel test robot Cc: linux-kernel@vger.kernel.org ---

[RFC PATCH V5 2/5] workqueue: expose attrs for system workqueues

Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo Cc: Lai Jiangshan Cc: kernel test robot

[RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

When pinning RT threads to specific cores using CPU affinity, the kworkers on the same CPU would starve, which may lead to some kind of priority inversion. In that case, the RT threads would also suffer high performance impact. The priority inversion looks like, CPU 0: libvirtd acquired

[RFC PATCH V5 2/5] workqueue: expose attrs for system workqueues

Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo Cc: Lai Jiangshan Cc: kernel test robot Cc: linux-kernel@vger.kernel.org --- kernel/workqueue.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[RFC PATCH V5 5/5] workqueue: introduce a way to set workqueue's scheduler

When pinning RT threads to specific cores using CPU affinity, the kworkers on the same CPU would starve, which may lead to some kind of priority inversion. In that case, the RT threads would also suffer high performance impact. The priority inversion looks like, CPU 0: libvirtd acquired

[RFC PATCH V5 4/5] workqueue: convert ->nice to ->sched_attr

The possibility of specifying more than just a nice for the wq may be useful for a wide variety of applications. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo

[RFC PATCH V5 4/5] workqueue: convert ->nice to ->sched_attr

The possibility of specifying more than just a nice for the wq may be useful for a wide variety of applications. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo Cc: Lai Jiangshan Cc: kernel test robot Cc:

[RFC PATCH V5 1/5] workqueue: rename system workqueues

Rename system_wq's wq->name from "events" to "system_percpu", and similarly for the similarly named workqueues. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo

[RFC PATCH V5 1/5] workqueue: rename system workqueues

Rename system_wq's wq->name from "events" to "system_percpu", and similarly for the similarly named workqueues. Signed-off-by: Wen Yang Signed-off-by: Jiang Biao Signed-off-by: Tan Hu Suggested-by: Tejun Heo Cc: Tejun Heo Cc: Lai Jiangshan Cc: linux-kernel@vger.kernel.org ---

RE: [patch v11 - re-ordered 03/12] FIXME platform/mellanox: Remove redundant dev_err messages on device_create

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Saturday, January 27, 2018 1:41 AM > To: Vadim Pasternak > Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org;

RE: [patch v11 - re-ordered 03/12] FIXME platform/mellanox: Remove redundant dev_err messages on device_create

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Saturday, January 27, 2018 1:41 AM > To: Vadim Pasternak > Cc: andy.shevche...@gmail.com; gre...@linuxfoundation.org; linux- > ker...@vger.kernel.org; platform-driver-...@vger.kernel.org; j...@resnulli.us >

Re: [PATCH v2] net: macb: Handle HRESP error

Hi David, On Fri, Jan 26, 2018 at 9:25 PM, David Miller wrote: > From: Harini Katakam > Date: Fri, 26 Jan 2018 16:12:11 +0530 > >> From: Harini Katakam >> >> Handle HRESP error by doing a SW reset of RX and TX and >>

Re: [PATCH v2] net: macb: Handle HRESP error

Hi David, On Fri, Jan 26, 2018 at 9:25 PM, David Miller wrote: > From: Harini Katakam > Date: Fri, 26 Jan 2018 16:12:11 +0530 > >> From: Harini Katakam >> >> Handle HRESP error by doing a SW reset of RX and TX and >> re-initializing the descriptors, RX and TX queue pointers. >> >>

[PATCH resend 2/6] cdrom: factor out common open_for_* code

The open_for_audio and open_for_data copies are bitrotten in different ways already and will need to update the autoclose logic in both. Signed-off-by: Michal Suchanek --- drivers/cdrom/cdrom.c | 100 ++ 1 file changed, 36

[PATCH resend 2/6] cdrom: factor out common open_for_* code

The open_for_audio and open_for_data copies are bitrotten in different ways already and will need to update the autoclose logic in both. Signed-off-by: Michal Suchanek --- drivers/cdrom/cdrom.c | 100 ++ 1 file changed, 36 insertions(+), 64

Re: crash binary for latest unreleased kernel

On Fri, 2018-01-26 at 20:38 -0800, Randy Dunlap wrote: > On 01/26/2018 08:32 PM, Mike Galbraith wrote: > > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: > >> Hi, > >> > >> I am doing development on the latest unreleased kernel on a system > >> running ubuntu 16.04. I can not get crash dump

Re: crash binary for latest unreleased kernel

On Fri, 2018-01-26 at 20:38 -0800, Randy Dunlap wrote: > On 01/26/2018 08:32 PM, Mike Galbraith wrote: > > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: > >> Hi, > >> > >> I am doing development on the latest unreleased kernel on a system > >> running ubuntu 16.04. I can not get crash dump

Re: crash binary for latest unreleased kernel

On 01/26/2018 08:32 PM, Mike Galbraith wrote: > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: >> Hi, >> >> I am doing development on the latest unreleased kernel on a system >> running ubuntu 16.04. I can not get crash dump to be saved or use >> crash on the live system. I have tried

Re: crash binary for latest unreleased kernel

On 01/26/2018 08:32 PM, Mike Galbraith wrote: > On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: >> Hi, >> >> I am doing development on the latest unreleased kernel on a system >> running ubuntu 16.04. I can not get crash dump to be saved or use >> crash on the live system. I have tried

Re: crash binary for latest unreleased kernel

On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: > Hi, > > I am doing development on the latest unreleased kernel on a system > running ubuntu 16.04. I can not get crash dump to be saved or use > crash on the live system. I have tried compiling crash on the system. > > What is the trick to do

Re: crash binary for latest unreleased kernel

On Fri, 2018-01-26 at 12:52 -0800, Joe Smith wrote: > Hi, > > I am doing development on the latest unreleased kernel on a system > running ubuntu 16.04. I can not get crash dump to be saved or use > crash on the live system. I have tried compiling crash on the system. > > What is the trick to do

Re: [linux-sunxi] [PATCH 10/16] iio: adc: sun4i-gpadc-iio: add support for A83T thermal sensor

On 26.01.2018 18:46, Ondřej Jirman wrote: Hi, On Fri, Jan 26, 2018 at 04:19:35PM +0100, Philipp Rossak wrote: This patch adds support for the A83T ths sensor. The A83T does not support interrupts. This seems to be broken. Though, you use support_irq = true below. And in my tests, IRQ for

Re: [linux-sunxi] [PATCH 10/16] iio: adc: sun4i-gpadc-iio: add support for A83T thermal sensor

On 26.01.2018 18:46, Ondřej Jirman wrote: Hi, On Fri, Jan 26, 2018 at 04:19:35PM +0100, Philipp Rossak wrote: This patch adds support for the A83T ths sensor. The A83T does not support interrupts. This seems to be broken. Though, you use support_irq = true below. And in my tests, IRQ for

Re: [PATCH] ssb: Reenable PCI host on !MIPS

Krzysztof Mazur writes: > The commit 58eae1416b804d900014d84feadda7195007cc30 > ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled > CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRIDGE, which are > required for SSB-based b43 PCI cards, on everything except MIPS > with

Re: [PATCH] ssb: Reenable PCI host on !MIPS

Krzysztof Mazur writes: > The commit 58eae1416b804d900014d84feadda7195007cc30 > ("ssb: Disable PCI host for PCI_DRIVERS_GENERIC") disabled > CONFIG_SSB_PCIHOST and CONFIG_SSB_B43_PCI_BRIDGE, which are > required for SSB-based b43 PCI cards, on everything except MIPS > with PCI_DRIVERS_LEGACY,

Re: [PATCH v2.1] x86/retpoline: Fill return stack buffer on vmexit

> Looks good to me. > > Another IRC discussion was that Boris may eventually add a feature to > the alternatives code to automatically insert such a jump if there are a > lot of nops. I vaguely recall that NOPs are skipped by the CPU so that it shouldn't matter as compared to say jumping over

Re: [PATCH v2.1] x86/retpoline: Fill return stack buffer on vmexit

> Looks good to me. > > Another IRC discussion was that Boris may eventually add a feature to > the alternatives code to automatically insert such a jump if there are a > lot of nops. I vaguely recall that NOPs are skipped by the CPU so that it shouldn't matter as compared to say jumping over

Re: [PATCH v2 1/2] x86/retpoline: Simplify vmexit_fill_RSB()

> + * Google experimented with loop-unrolling and this turned out to be > + * the optimal version — two calls, each with their own speculation > + * trap should their return address end up getting used, in a loop. > + */ > +.macro BOINK_RSB nr:req sp:req BOINK? Really?

Re: [PATCH v2 1/2] x86/retpoline: Simplify vmexit_fill_RSB()

> + * Google experimented with loop-unrolling and this turned out to be > + * the optimal version — two calls, each with their own speculation > + * trap should their return address end up getting used, in a loop. > + */ > +.macro BOINK_RSB nr:req sp:req BOINK? Really?

Re: [PATCH] block: paride: on26: Replace mdelay with msleep in on26_test_port

On 2018/1/27 1:31, Al Viro wrote: On Fri, Jan 26, 2018 at 11:42:25PM +0800, Jia-Ju Bai wrote: After checking all possible call chains to on26_test_port() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. And

Re: [PATCH] block: paride: on26: Replace mdelay with msleep in on26_test_port

On 2018/1/27 1:31, Al Viro wrote: On Fri, Jan 26, 2018 at 11:42:25PM +0800, Jia-Ju Bai wrote: After checking all possible call chains to on26_test_port() here, my tool finds that this function is never called in atomic context, namely never in an interrupt handler or holding a spinlock. And

[PATCH V2] print kdump kernel loaded status in stack dump

It is useful to print kdump kernel loaded status in dump_stack() especially when panic happens so that we can differenciate kdump kernel early hang and a normal panic in a bug report. Signed-off-by: Dave Young --- [v1 -> v2] merge the status in other line as Andi Kleen

[PATCH V2] print kdump kernel loaded status in stack dump

It is useful to print kdump kernel loaded status in dump_stack() especially when panic happens so that we can differenciate kdump kernel early hang and a normal panic in a bug report. Signed-off-by: Dave Young --- [v1 -> v2] merge the status in other line as Andi Kleen suggested

Re: [PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send

On 2018/1/27 1:08, Al Viro wrote: On Fri, Jan 26, 2018 at 11:07:39AM -0500, David Miller wrote: This is found by a static analysis tool named DCNS written by myself. The trouble is, places like net/atm/raw.c:65: vcc->send = atm_send_aal0; net/atm/raw.c:74: vcc->send =

Re: [PATCH] atm: firestream: Replace GFP_ATOMIC with GFP_KERNEL in fs_send

On 2018/1/27 1:08, Al Viro wrote: On Fri, Jan 26, 2018 at 11:07:39AM -0500, David Miller wrote: This is found by a static analysis tool named DCNS written by myself. The trouble is, places like net/atm/raw.c:65: vcc->send = atm_send_aal0; net/atm/raw.c:74: vcc->send =

[PATCH] Documentation/cdrom: update cdrom-standard.tex for kernel changes

her update those short descriptions or give me short descriptions that I can use there? Thanks. Documentation/cdrom/cdrom-standard.tex | 29 +++ 1 file changed, 20 insertions(+), 9 deletions(-) --- linux-next-20180126.orig/Documentation/cdrom/cdrom-standard.tex +++ linux-next-

[PATCH] Documentation/cdrom: update cdrom-standard.tex for kernel changes

ons that I can use there? Thanks. Documentation/cdrom/cdrom-standard.tex | 29 +++ 1 file changed, 20 insertions(+), 9 deletions(-) --- linux-next-20180126.orig/Documentation/cdrom/cdrom-standard.tex +++ linux-next-20180126/Documentation/cdrom/cdrom-standard.tex @@ -23

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/26/18 at 01:17pm, Petr Mladek wrote: > On Fri 2018-01-26 15:37:24, Dave Young wrote: > > On 01/19/18 at 12:47pm, Dave Young wrote: > > > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > > > On Thu, 18 Jan 2018 10:02:17 -0800 > > > > Andi Kleen wrote: > > > > > > > >

Re: [PATCH] print kdump kernel loaded status in stack dump

On 01/26/18 at 01:17pm, Petr Mladek wrote: > On Fri 2018-01-26 15:37:24, Dave Young wrote: > > On 01/19/18 at 12:47pm, Dave Young wrote: > > > On 01/18/18 at 01:57pm, Steven Rostedt wrote: > > > > On Thu, 18 Jan 2018 10:02:17 -0800 > > > > Andi Kleen wrote: > > > > > > > > > Dave Young writes:

Re: [PATCH-next] misc: mic: Use PTR_ERR_OR_ZERO

On Tue, Jan 23 2018 at 02:55:19 PM, Al Viro wrote: > On Tue, Jan 23, 2018 at 03:10:09PM -0500, Christopher Díaz Riveros wrote: >> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR >> >> This issue was detected by using the Coccinelle software. > > ... and that's

Re: [PATCH-next] misc: mic: Use PTR_ERR_OR_ZERO

On Tue, Jan 23 2018 at 02:55:19 PM, Al Viro wrote: > On Tue, Jan 23, 2018 at 03:10:09PM -0500, Christopher Díaz Riveros wrote: >> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR >> >> This issue was detected by using the Coccinelle software. > > ... and that's a wonderful demonstration

Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller

On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov wrote: > Hi Jassi, > > On 12/29/2017 08:14 AM, Jassi Brar wrote: >> Hi Bjorn, >> >> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson >> wrote: >>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote:

Re: [PATCH v11 2/6] mailbox: qcom: Create APCS child device for clock controller

On Thu, Jan 4, 2018 at 10:26 PM, Georgi Djakov wrote: > Hi Jassi, > > On 12/29/2017 08:14 AM, Jassi Brar wrote: >> Hi Bjorn, >> >> On Sun, Dec 24, 2017 at 10:36 AM, Bjorn Andersson >> wrote: >>> On Fri 22 Dec 20:57 PST 2017, Jassi Brar wrote: >>> On Tue, Dec 5, 2017 at 9:16 PM, Georgi

[PATCH v2] mm: Correct comments regarding do_fault_around()

mm: Correct comments regarding do_fault_around() There are multiple comments surrounding do_fault_around that memtion fault_around_pages() and fault_around_mask(), two routines that do not exist. These comments should be reworded to reference fault_around_bytes, the value which is used to

[PATCH v2] mm: Correct comments regarding do_fault_around()

mm: Correct comments regarding do_fault_around() There are multiple comments surrounding do_fault_around that memtion fault_around_pages() and fault_around_mask(), two routines that do not exist. These comments should be reworded to reference fault_around_bytes, the value which is used to

[PATCH v2] mm: Correct comments regarding do_fault_around()

[PATCH v2] mm: Correct comments regarding do_fault_around()

[RFC] apparent bogosity in unregister_ftrace_function_probe_func()

It contains something very odd: func_g.type = filter_parse_regex(glob, strlen(glob), _g.search, ); func_g.len = strlen(func_g.search); func_g.search = glob; /* we do not support '!'

[RFC] apparent bogosity in unregister_ftrace_function_probe_func()

It contains something very odd: func_g.type = filter_parse_regex(glob, strlen(glob), _g.search, ); func_g.len = strlen(func_g.search); func_g.search = glob; /* we do not support '!'

Re: [PATCH v2 3/4] openrisc: Use the new MULTI_IRQ_HANDLER

On Wed, Jan 24, 2018 at 11:46:19PM -0800, Christoph Hellwig wrote: > On Wed, Jan 24, 2018 at 07:07:55PM -0800, Palmer Dabbelt wrote: > > It appears that openrisc copied arm64's MULTI_IRQ_HANDLER code (which > > came from arm). I wanted to make this generic so I could use it in the > > RISC-V

Re: [PATCH v2 3/4] openrisc: Use the new MULTI_IRQ_HANDLER

On Wed, Jan 24, 2018 at 11:46:19PM -0800, Christoph Hellwig wrote: > On Wed, Jan 24, 2018 at 07:07:55PM -0800, Palmer Dabbelt wrote: > > It appears that openrisc copied arm64's MULTI_IRQ_HANDLER code (which > > came from arm). I wanted to make this generic so I could use it in the > > RISC-V

Re: [RFC PATCH] vsprintf: add flag ZEROPAD handling before crng is ready

Hi, Rasmus and Andy,   Thanks for your feedback. I add some information below. On Fri, 2018-01-26 at 10:43 +0100, Rasmus Villemoes wrote: > On 26 January 2018 at 10:17, Andy Shevchenko > wrote: > > > > +Rasmus > Thanks. > > > > > On Fri, 2018-01-26 at 15:39

Re: [RFC PATCH] vsprintf: add flag ZEROPAD handling before crng is ready

Hi, Rasmus and Andy,   Thanks for your feedback. I add some information below. On Fri, 2018-01-26 at 10:43 +0100, Rasmus Villemoes wrote: > On 26 January 2018 at 10:17, Andy Shevchenko > wrote: > > > > +Rasmus > Thanks. > > > > > On Fri, 2018-01-26 at 15:39 +0800, Yang Shunyong wrote: > > >

Re: [Linaro-mm-sig] [PATCH v3] staging: android: ion: Zero CMA allocated memory

On 2018/1/27 1:48, Liam Mark wrote: > Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly") > the CMA API is now used directly and therefore the allocated memory is no > longer automatically zeroed. > > Explicitly zero CMA allocated memory to ensure that no data is exposed

Re: [Linaro-mm-sig] [PATCH v3] staging: android: ion: Zero CMA allocated memory

On 2018/1/27 1:48, Liam Mark wrote: > Since commit 204f672255c2 ("staging: android: ion: Use CMA APIs directly") > the CMA API is now used directly and therefore the allocated memory is no > longer automatically zeroed. > > Explicitly zero CMA allocated memory to ensure that no data is exposed

Re: KASAN: stack-out-of-bounds Read in write_mmio

On Mon, Dec 11, 2017 at 07:00:03PM +0800, Wanpeng Li wrote: > 2017-12-09 19:39 GMT+08:00 Tianyu Lan : > > 2017-12-09 17:15 GMT+08:00 syzbot > > : > >> syzkaller has found reproducer for the following

Re: KASAN: stack-out-of-bounds Read in write_mmio

On Mon, Dec 11, 2017 at 07:00:03PM +0800, Wanpeng Li wrote: > 2017-12-09 19:39 GMT+08:00 Tianyu Lan : > > 2017-12-09 17:15 GMT+08:00 syzbot > > : > >> syzkaller has found reproducer for the following crash on > >> ad4dac17f9d563b9e34aab78a34293b10993e9b5 > >>

Re: [PATCH 0/5] Qualcomm SMD updates

On Tue, Dec 12, 2017 at 03:58:52PM -0800, Bjorn Andersson wrote: > A series of fixes for a few issues reported or seen with SMD. > > The first two fixes changes the trigger for creating devices for channels > found, which should cause the rpm-smd driver to probe on 8909 and 8994 > devices. >

Re: [PATCH 0/5] Qualcomm SMD updates

On Tue, Dec 12, 2017 at 03:58:52PM -0800, Bjorn Andersson wrote: > A series of fixes for a few issues reported or seen with SMD. > > The first two fixes changes the trigger for creating devices for channels > found, which should cause the rpm-smd driver to probe on 8909 and 8994 > devices. >

Re: [PATCH 1/5] rpmsg: smd: Perform handshake during open

On Tue, Dec 12, 2017 at 03:58:53PM -0800, Bjorn Andersson wrote: > Validate the the remote side is opening the channel that we've found by > performing a handshake when opening the channel. > > Signed-off-by: Bjorn Andersson > --- > drivers/rpmsg/qcom_smd.c | 30

Re: [PATCH 1/5] rpmsg: smd: Perform handshake during open

On Tue, Dec 12, 2017 at 03:58:53PM -0800, Bjorn Andersson wrote: > Validate the the remote side is opening the channel that we've found by > performing a handshake when opening the channel. > > Signed-off-by: Bjorn Andersson > --- > drivers/rpmsg/qcom_smd.c | 30 ++ >

Re: general protection fault in lockdep_invariant_state (2)

On Wed, Nov 08, 2017 at 12:16:00AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 5a3517e009e979f21977d362212b7729c5165d92 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: general protection fault in lockdep_invariant_state (2)

On Wed, Nov 08, 2017 at 12:16:00AM -0800, syzbot wrote: > Hello, > > syzkaller hit the following crash on > 5a3517e009e979f21977d362212b7729c5165d92 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: [PATCH bpf-next v7 3/5] libbpf: add error reporting in XDP

On 01/25/2018 01:05 AM, Eric Leblond wrote: > Parse netlink ext attribute to get the error message returned by > the card. Code is partially take from libnl. > > We add netlink.h to the uapi include of tools. And we need to > avoid include of userspace netlink header to have a successful > build

Re: [PATCH bpf-next v7 3/5] libbpf: add error reporting in XDP

On 01/25/2018 01:05 AM, Eric Leblond wrote: > Parse netlink ext attribute to get the error message returned by > the card. Code is partially take from libnl. > > We add netlink.h to the uapi include of tools. And we need to > avoid include of userspace netlink header to have a successful > build

Re: general protection fault in __lock_acquire (2)

On Thu, Nov 02, 2017 at 03:55:00AM -0700, syzbot wrote: > Hello, > > syzkaller hit the following crash on > fa8785e862ef644f742558f1a8c91eca6f3f0004 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

Re: [PATCH bpf-next v7 2/5] libbpf: add function to setup XDP

On 01/25/2018 01:05 AM, Eric Leblond wrote: > Most of the code is taken from set_link_xdp_fd() in bpf_load.c and > slightly modified to be library compliant. > > Signed-off-by: Eric Leblond > Acked-by: Alexei Starovoitov > --- > tools/lib/bpf/bpf.c| 127 >

Re: [PATCH bpf-next v7 2/5] libbpf: add function to setup XDP

On 01/25/2018 01:05 AM, Eric Leblond wrote: > Most of the code is taken from set_link_xdp_fd() in bpf_load.c and > slightly modified to be library compliant. > > Signed-off-by: Eric Leblond > Acked-by: Alexei Starovoitov > --- > tools/lib/bpf/bpf.c| 127 >

Re: general protection fault in __lock_acquire (2)

On Thu, Nov 02, 2017 at 03:55:00AM -0700, syzbot wrote: > Hello, > > syzkaller hit the following crash on > fa8785e862ef644f742558f1a8c91eca6f3f0004 > git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master > compiler: gcc (GCC) 7.1.1 20170620 > .config is attached > Raw console

  1   2   3   4   5   6   7   8   9   10   >