Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

Hello, Bart. On Tue, Dec 12, 2017 at 09:37:11PM +, Bart Van Assche wrote: > Have you considered the following instead of introducing MQ_RQ_IDLE and > MQ_RQ_IN_FLIGHT? I think this could help to limit the number of new atomic > operations introduced in the hot path by this patch series. But

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

Hello, Bart. On Tue, Dec 12, 2017 at 09:37:11PM +, Bart Van Assche wrote: > Have you considered the following instead of introducing MQ_RQ_IDLE and > MQ_RQ_IN_FLIGHT? I think this could help to limit the number of new atomic > operations introduced in the hot path by this patch series. But

[PATCH 1/8] target/iscsi: Less function calls in chap_server_compute_md5() after error detection

From: Markus Elfring Date: Tue, 12 Dec 2017 18:00:41 +0100 The functions "crypto_free_shash", "kfree" and "kzfree" were called in a few cases by the chap_server_compute_md5() function during error handling even if the passed variable contained a null pointer. *

[PATCH 1/8] target/iscsi: Less function calls in chap_server_compute_md5() after error detection

From: Markus Elfring Date: Tue, 12 Dec 2017 18:00:41 +0100 The functions "crypto_free_shash", "kfree" and "kzfree" were called in a few cases by the chap_server_compute_md5() function during error handling even if the passed variable contained a null pointer. * Adjust jump targets according to

[PATCH 0/8] target-iSCSI: Adjustments for several function implementations

From: Markus Elfring Date: Tue, 12 Dec 2017 22:22:11 +0100 Some update suggestions were taken into account from static source code analysis. Markus Elfring (8): Less function calls in chap_server_compute_md5() after error detection Move resetting of seven

[PATCH 0/8] target-iSCSI: Adjustments for several function implementations

From: Markus Elfring Date: Tue, 12 Dec 2017 22:22:11 +0100 Some update suggestions were taken into account from static source code analysis. Markus Elfring (8): Less function calls in chap_server_compute_md5() after error detection Move resetting of seven variables in

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Andy Lutomirski wrote: > On Tue, Dec 12, 2017 at 12:37 PM, Thomas Gleixner wrote: > > On Tue, 12 Dec 2017, Dave Hansen wrote: > > > >> On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > >> > The only critical interaction is the return to user path (user

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Andy Lutomirski wrote: > On Tue, Dec 12, 2017 at 12:37 PM, Thomas Gleixner wrote: > > On Tue, 12 Dec 2017, Dave Hansen wrote: > > > >> On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > >> > The only critical interaction is the return to user path (user CS/SS) and > >> > we

Re: [PATCH v3 net-next] net: ethernet: ti: cpdma: correct error handling for chan create

On 12/12/2017 03:06 PM, Ivan Khoronzhuk wrote: It's not correct to return NULL when that is actually an error and function returns errors in any other wrong case. In the same time, the cpsw driver and davinci emac doesn't check error case while creating channel and it can miss actual error.

Re: [PATCH v3 net-next] net: ethernet: ti: cpdma: correct error handling for chan create

On 12/12/2017 03:06 PM, Ivan Khoronzhuk wrote: It's not correct to return NULL when that is actually an error and function returns errors in any other wrong case. In the same time, the cpsw driver and davinci emac doesn't check error case while creating channel and it can miss actual error.

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Thomas Gleixner wrote: > On Tue, 12 Dec 2017, Dave Hansen wrote: > > > On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > > > The only critical interaction is the return to user path (user CS/SS) and > > > we made sure with the LAR touching that these are precached in the CPU >

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Thomas Gleixner wrote: > On Tue, 12 Dec 2017, Dave Hansen wrote: > > > On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > > > The only critical interaction is the return to user path (user CS/SS) and > > > we made sure with the LAR touching that these are precached in the CPU >

Re: [PATCHSET v2] blk-mq: reimplement timeout handling

Hello, Jens. On Tue, Dec 12, 2017 at 01:23:01PM -0700, Jens Axboe wrote: > I like this a lot, it's a lot less fragile and more intuitive/readable > than what we have now. And apparently less error prone... I'll do > some testing with this. Great. > BTW, since youadd a few more BLK_MQ_F_BLOCKING

Re: [PATCHSET v2] blk-mq: reimplement timeout handling

Hello, Jens. On Tue, Dec 12, 2017 at 01:23:01PM -0700, Jens Axboe wrote: > I like this a lot, it's a lot less fragile and more intuitive/readable > than what we have now. And apparently less error prone... I'll do > some testing with this. Great. > BTW, since youadd a few more BLK_MQ_F_BLOCKING

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

On Tue, 2017-12-12 at 11:01 -0800, Tejun Heo wrote: > +/* > + * Bits for request->gstate. The lower two bits carry MQ_RQ_* state value > + * and the upper bits the generation number. > + */ > +enum mq_rq_state { > + MQ_RQ_IDLE = 0, > + MQ_RQ_IN_FLIGHT = 1, > + > +

Re: [PATCH 2/6] blk-mq: replace timeout synchronization with a RCU and generation based scheme

On Tue, 2017-12-12 at 11:01 -0800, Tejun Heo wrote: > +/* > + * Bits for request->gstate. The lower two bits carry MQ_RQ_* state value > + * and the upper bits the generation number. > + */ > +enum mq_rq_state { > + MQ_RQ_IDLE = 0, > + MQ_RQ_IN_FLIGHT = 1, > + > +

Re: [PATCH v1] clk: tegra20: Add 216 MHz entry for PLL_X

On 12.12.2017 18:17, Peter De Schrijver wrote: > On Tue, Dec 12, 2017 at 03:08:08PM +0300, Dmitry Osipenko wrote: >> On 12.12.2017 13:02, Peter De Schrijver wrote: >>> On Mon, Dec 11, 2017 at 09:50:09PM +0300, Dmitry Osipenko wrote: The cpufreq driver uses 216 MHz as the lowest CPU clock

Re: [PATCH v1] clk: tegra20: Add 216 MHz entry for PLL_X

On 12.12.2017 18:17, Peter De Schrijver wrote: > On Tue, Dec 12, 2017 at 03:08:08PM +0300, Dmitry Osipenko wrote: >> On 12.12.2017 13:02, Peter De Schrijver wrote: >>> On Mon, Dec 11, 2017 at 09:50:09PM +0300, Dmitry Osipenko wrote: The cpufreq driver uses 216 MHz as the lowest CPU clock

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, Dec 12, 2017 at 12:37 PM, Thomas Gleixner wrote: > On Tue, 12 Dec 2017, Dave Hansen wrote: > >> On 12/12/2017 11:21 AM, Thomas Gleixner wrote: >> > The only critical interaction is the return to user path (user CS/SS) and >> > we made sure with the LAR touching that

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, Dec 12, 2017 at 12:37 PM, Thomas Gleixner wrote: > On Tue, 12 Dec 2017, Dave Hansen wrote: > >> On 12/12/2017 11:21 AM, Thomas Gleixner wrote: >> > The only critical interaction is the return to user path (user CS/SS) and >> > we made sure with the LAR touching that these are precached in

Re: [intel-sgx-kernel-dev] [PATCH v7 4/8] intel_sgx: driver for Intel Software Guard Extensions

On Thu, 2017-12-07 at 18:05 +0200, Jarkko Sakkinen wrote: > On Thu, Dec 07, 2017 at 02:46:39PM +, Christopherson, Sean J wrote: > > > > > > > > + for (i = 0; i < 2; i++) { > > > + va_page = list_first_entry(>va_pages, > > > +    struct sgx_va_page,

Re: [intel-sgx-kernel-dev] [PATCH v7 4/8] intel_sgx: driver for Intel Software Guard Extensions

On Thu, 2017-12-07 at 18:05 +0200, Jarkko Sakkinen wrote: > On Thu, Dec 07, 2017 at 02:46:39PM +, Christopherson, Sean J wrote: > > > > > > > > + for (i = 0; i < 2; i++) { > > > + va_page = list_first_entry(>va_pages, > > > +    struct sgx_va_page,

[PATCH] ARM: exynos_defconfig - enable CONFIG_EXYNOS_IOMMU

EXYNOS_IOMMU is disabled in exynos_defconfig since it is known to cause boot failures on Exynos Chrome-books. The recommendation is for IOMMU to be enabled manually on systems as needed. A recent exynos_drm change added a warning message when EXYNOS_IOMMU is disabled. It is necessary to enable it

[PATCH] ARM: exynos_defconfig - enable CONFIG_EXYNOS_IOMMU

EXYNOS_IOMMU is disabled in exynos_defconfig since it is known to cause boot failures on Exynos Chrome-books. The recommendation is for IOMMU to be enabled manually on systems as needed. A recent exynos_drm change added a warning message when EXYNOS_IOMMU is disabled. It is necessary to enable it

Re: [PATCH v5] ASoC: TSCS42xx: Add support for Tempo Semiconductor's TSCS42xx audio CODEC

On Tue, Dec 12, 2017 at 04:32:54PM +, Mark Brown wrote: > On Mon, Dec 11, 2017 at 01:54:25PM -0600, Steven Eckhoff wrote: > > Currently there is no support for the TSCS42xx audio CODEC. > > > > Add support for it. > > > > v5 attempts to address all issues raised in the previous reviews. > >

Re: [PATCH v5] ASoC: TSCS42xx: Add support for Tempo Semiconductor's TSCS42xx audio CODEC

On Tue, Dec 12, 2017 at 04:32:54PM +, Mark Brown wrote: > On Mon, Dec 11, 2017 at 01:54:25PM -0600, Steven Eckhoff wrote: > > Currently there is no support for the TSCS42xx audio CODEC. > > > > Add support for it. > > > > v5 attempts to address all issues raised in the previous reviews. > >

Re: possible deadlock in lock_trace

On Thu, Nov 30, 2017 at 10:39:02AM -0800, syzbot wrote: > > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

Re: possible deadlock in lock_trace

On Thu, Nov 30, 2017 at 10:39:02AM -0800, syzbot wrote: > > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

Re: [PATCH v3 3/6] leds: lp8860: Update the dt parsing for LED labeling

Jacek On 12/12/2017 03:13 PM, Jacek Anaszewski wrote: > Hi Dan, > > Thanks for the patch set. > > On 12/12/2017 07:58 PM, Dan Murphy wrote: >> Update the DT parsing for the label node so that >> the label is retrieved from the device child as >> opposed to being part of the parent. >> >> This

Re: [PATCH v3 3/6] leds: lp8860: Update the dt parsing for LED labeling

Jacek On 12/12/2017 03:13 PM, Jacek Anaszewski wrote: > Hi Dan, > > Thanks for the patch set. > > On 12/12/2017 07:58 PM, Dan Murphy wrote: >> Update the DT parsing for the label node so that >> the label is retrieved from the device child as >> opposed to being part of the parent. >> >> This

Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

On Tue, 12 Dec 2017, Dimitri Sivanich wrote: > > --- a/drivers/misc/sgi-gru/grutlbpurge.c > > +++ b/drivers/misc/sgi-gru/grutlbpurge.c > > @@ -298,6 +298,7 @@ struct gru_mm_struct *gru_register_mmu_notifier(void) > > return ERR_PTR(-ENOMEM); > > STAT(gms_alloc); >

Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks

On Tue, 12 Dec 2017, Dimitri Sivanich wrote: > > --- a/drivers/misc/sgi-gru/grutlbpurge.c > > +++ b/drivers/misc/sgi-gru/grutlbpurge.c > > @@ -298,6 +298,7 @@ struct gru_mm_struct *gru_register_mmu_notifier(void) > > return ERR_PTR(-ENOMEM); > > STAT(gms_alloc); >

Re: possible deadlock in do_io_accounting

On Mon, Dec 04, 2017 at 10:41:01AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

Re: possible deadlock in do_io_accounting

On Mon, Dec 04, 2017 at 10:41:01AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

Re: [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU

On Tue, Dec 12, 2017 at 9:26 AM, Priit Laes wrote: > On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote: >> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes wrote: >> > Convert sun4i-a10.dtsi to new CCU driver. >> > >> > Signed-off-by: Priit Laes

Re: [linux-sunxi] [PATCH v2 3/6] ARM: sun4i: Convert to CCU

On Tue, Dec 12, 2017 at 9:26 AM, Priit Laes wrote: > On Mon, Dec 11, 2017 at 02:22:30PM -0800, Kevin Hilman wrote: >> On Sun, Mar 26, 2017 at 10:20 AM, Priit Laes wrote: >> > Convert sun4i-a10.dtsi to new CCU driver. >> > >> > Signed-off-by: Priit Laes >> >> I finally got around to bisecting a

Re: possible deadlock in fifo_open

On Fri, Dec 01, 2017 at 04:53:01AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

Re: possible deadlock in fifo_open

On Fri, Dec 01, 2017 at 04:53:01AM -0800, syzbot wrote: > syzbot will keep track of this bug report. > Once a fix for this bug is committed, please reply to this email with: > #syz fix: exact-commit-title > To mark this as a duplicate of another syzbot report, please reply with: > #syz dup:

Re: linux-next: error while fetching the spi-nor tree

Hi Stephen, I've just added 2 commits about 8 hours ago, nothing special. Could the issue be explained by an unlikely bad timing? I don't see anything wrong when fetching the tree or when browsing the web server: http://git.infradead.org/l2-mtd.git/shortlog/refs/heads/spi-nor/next Please, let

Re: linux-next: error while fetching the spi-nor tree

Hi Stephen, I've just added 2 commits about 8 hours ago, nothing special. Could the issue be explained by an unlikely bad timing? I don't see anything wrong when fetching the tree or when browsing the web server: http://git.infradead.org/l2-mtd.git/shortlog/refs/heads/spi-nor/next Please, let

Re: WARNING in kmalloc_slab (3)

On Mon, Dec 04, 2017 at 12:26:32PM +0300, Dan Carpenter wrote: > On Mon, Dec 04, 2017 at 09:18:05AM +0100, Dmitry Vyukov wrote: > > On Mon, Dec 4, 2017 at 9:14 AM, Dan Carpenter > > wrote: > > > On Sun, Dec 03, 2017 at 12:16:08PM -0800, Eric Biggers wrote: > > >> Looks

Re: WARNING in kmalloc_slab (3)

On Mon, Dec 04, 2017 at 12:26:32PM +0300, Dan Carpenter wrote: > On Mon, Dec 04, 2017 at 09:18:05AM +0100, Dmitry Vyukov wrote: > > On Mon, Dec 4, 2017 at 9:14 AM, Dan Carpenter > > wrote: > > > On Sun, Dec 03, 2017 at 12:16:08PM -0800, Eric Biggers wrote: > > >> Looks like BLKTRACESETUP doesn't

Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce skb_warn_bad_offload() noise

On Tue, Dec 12, 2017 at 09:10:11AM -0500, David Miller wrote: > From: Willem de Bruijn > Date: Mon, 11 Dec 2017 16:56:56 -0500 > > > On Mon, Dec 11, 2017 at 4:44 PM, Greg Kroah-Hartman > > wrote: > >> On Mon, Dec 11, 2017 at

Re: [REGRESSION][4.13.y][4.14.y][v4.15.y] net: reduce skb_warn_bad_offload() noise

On Tue, Dec 12, 2017 at 09:10:11AM -0500, David Miller wrote: > From: Willem de Bruijn > Date: Mon, 11 Dec 2017 16:56:56 -0500 > > > On Mon, Dec 11, 2017 at 4:44 PM, Greg Kroah-Hartman > > wrote: > >> On Mon, Dec 11, 2017 at 04:25:26PM -0500, Willem de Bruijn wrote: > >>> Note that UFO was

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

OK, I built a kernel 4.14.5 from vanilla kernel.org sources using the Fedora .config (couldn't get the Fedora package to build). I see no difference with both [0, 1] patches applied and the tpm modules loaded -- no keyboard or touchpad. [Note: I'm not *consciously* using the TPM for anything,

Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system

OK, I built a kernel 4.14.5 from vanilla kernel.org sources using the Fedora .config (couldn't get the Fedora package to build). I see no difference with both [0, 1] patches applied and the tpm modules loaded -- no keyboard or touchpad. [Note: I'm not *consciously* using the TPM for anything,

Re: linux-next: Signed-off-by missing for commit in the usb.current tree

On Wed, Dec 13, 2017 at 07:50:57AM +1100, Stephen Rothwell wrote: > Hi Greg, > > Commit > > 32fd87b3bbf5 ("USB: core: only clean up what we allocated") > > is missing a Signed-off-by from its author. Yeah, due to how it got to me, that makes sense, thanks for the notice. I really gotta go

Re: linux-next: Signed-off-by missing for commit in the usb.current tree

On Wed, Dec 13, 2017 at 07:50:57AM +1100, Stephen Rothwell wrote: > Hi Greg, > > Commit > > 32fd87b3bbf5 ("USB: core: only clean up what we allocated") > > is missing a Signed-off-by from its author. Yeah, due to how it got to me, that makes sense, thanks for the notice. I really gotta go

Re: [PATCH v3 3/6] leds: lp8860: Update the dt parsing for LED labeling

Hi Dan, Thanks for the patch set. On 12/12/2017 07:58 PM, Dan Murphy wrote: > Update the DT parsing for the label node so that > the label is retrieved from the device child as > opposed to being part of the parent. > > This will align this driver with the LED > binding documentation > >

Re: [PATCH v3 3/6] leds: lp8860: Update the dt parsing for LED labeling

Hi Dan, Thanks for the patch set. On 12/12/2017 07:58 PM, Dan Murphy wrote: > Update the DT parsing for the label node so that > the label is retrieved from the device child as > opposed to being part of the parent. > > This will align this driver with the LED > binding documentation > >

Re: [PATCH v3 1/8] SOC: brcmstb: add memory API

[+cc Lorenzo] On Tue, Dec 12, 2017 at 03:53:28PM -0500, Jim Quinlan wrote: > On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas wrote: > > On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote: > >> From: Florian Fainelli > >> > >> This commit adds a

Re: [PATCH v3 1/8] SOC: brcmstb: add memory API

[+cc Lorenzo] On Tue, Dec 12, 2017 at 03:53:28PM -0500, Jim Quinlan wrote: > On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas wrote: > > On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote: > >> From: Florian Fainelli > >> > >> This commit adds a memory API suitable for ascertaining the

Re: UDL's fbdev doesn't work for user-space apps

On Tue 2017-12-12 19:48:05, Alexey Brodkin wrote: > Hi Pavel, > > On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote: > > On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > > > > > > Hi Alexey, > > > > > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > > > > > > > My first [probably incorrect]

Re: UDL's fbdev doesn't work for user-space apps

On Tue 2017-12-12 19:48:05, Alexey Brodkin wrote: > Hi Pavel, > > On Sat, 2017-12-09 at 18:20 +0100, Pavel Machek wrote: > > On Mon 2017-12-04 11:50:40, Jose Abreu wrote: > > > > > > Hi Alexey, > > > > > > On 04-12-2017 11:32, Alexey Brodkin wrote: > > > > > > > > My first [probably incorrect]

[PATCH v3 net-next] net: ethernet: ti: cpdma: correct error handling for chan create

It's not correct to return NULL when that is actually an error and function returns errors in any other wrong case. In the same time, the cpsw driver and davinci emac doesn't check error case while creating channel and it can miss actual error. Also remove WARNs replacing them on dev_err msgs.

[PATCH v3 net-next] net: ethernet: ti: cpdma: correct error handling for chan create

It's not correct to return NULL when that is actually an error and function returns errors in any other wrong case. In the same time, the cpsw driver and davinci emac doesn't check error case while creating channel and it can miss actual error. Also remove WARNs replacing them on dev_err msgs.

Re: [PATCH 1/1] dt-bindings: arm: document supported STM32 SoC family

On Fri, Dec 08, 2017 at 02:56:34PM +0100, Ludovic Barre wrote: > From: Ludovic Barre > > This adds a list of supported STM32 SoC bindings. > > Signed-off-by: Gwenael Treuveur > Signed-off-by: Ludovic Barre > --- >

Re: [PATCH 1/1] dt-bindings: arm: document supported STM32 SoC family

On Fri, Dec 08, 2017 at 02:56:34PM +0100, Ludovic Barre wrote: > From: Ludovic Barre > > This adds a list of supported STM32 SoC bindings. > > Signed-off-by: Gwenael Treuveur > Signed-off-by: Ludovic Barre > --- > Documentation/devicetree/bindings/arm/stm32.txt | 9 + > 1 file

linux-next: the drivers-x86 tree has moved?

Hi Darren, I noticed commit 960652046899 ("MAINTAINERS: Update tree for platform-drivers-x86") Should I also change linu-next to use the new tree? -- Cheers, Stephen Rothwell

linux-next: the drivers-x86 tree has moved?

Hi Darren, I noticed commit 960652046899 ("MAINTAINERS: Update tree for platform-drivers-x86") Should I also change linu-next to use the new tree? -- Cheers, Stephen Rothwell

Re: linux-next: Signed-off-by missing for commit in the usb.current tree

On Tue, Dec 12, 2017 at 9:50 PM, Stephen Rothwell wrote: > Hi Greg, > > Commit > > 32fd87b3bbf5 ("USB: core: only clean up what we allocated") > > is missing a Signed-off-by from its author. AFAIU, Alan has a better patch ("USB: core: prevent malicious bNumInterfaces

Re: linux-next: Signed-off-by missing for commit in the usb.current tree

On Tue, Dec 12, 2017 at 9:50 PM, Stephen Rothwell wrote: > Hi Greg, > > Commit > > 32fd87b3bbf5 ("USB: core: only clean up what we allocated") > > is missing a Signed-off-by from its author. AFAIU, Alan has a better patch ("USB: core: prevent malicious bNumInterfaces overflow") so this one

Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3)

Hi Steffen, On Fri, Dec 01, 2017 at 08:27:43AM +0100, Steffen Klassert wrote: > On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote: > > syzkaller has found reproducer for the following crash on > > 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c > >

Re: KASAN: stack-out-of-bounds Read in xfrm_state_find (3)

Hi Steffen, On Fri, Dec 01, 2017 at 08:27:43AM +0100, Steffen Klassert wrote: > On Wed, Nov 22, 2017 at 08:05:00AM -0800, syzbot wrote: > > syzkaller has found reproducer for the following crash on > > 0c86a6bd85ff0629cd2c5141027fc1c8bb6cde9c > >

Re: [PATCH v11 2/2] leds: lm3692x: Introduce LM3692x dual string driver

Hi Dan, Thanks for the updated patch set. I found two minor issues but fixed them by myself and applied both patches to the for-next branch of linux-leds.git. Please refer below and let me know if you have any objections to my amendments. On 12/12/2017 07:15 PM, Dan Murphy wrote: > Introducing

Re: [PATCH v11 2/2] leds: lm3692x: Introduce LM3692x dual string driver

Hi Dan, Thanks for the updated patch set. I found two minor issues but fixed them by myself and applied both patches to the for-next branch of linux-leds.git. Please refer below and let me know if you have any objections to my amendments. On 12/12/2017 07:15 PM, Dan Murphy wrote: > Introducing

Re: [PATCH net-next] net: dsa: lan9303: Introduce lan9303_read_wait

Hi Vivien. Den 12. des. 2017 19:08, skrev Vivien Didelot: Hi Egil, Egil Hjelmeland writes: Simplify lan9303_indirect_phy_wait_for_completion() and lan9303_switch_wait_for_completion() by using a new function lan9303_read_wait() Signed-off-by: Egil Hjelmeland

Re: [PATCH net-next] net: dsa: lan9303: Introduce lan9303_read_wait

Hi Vivien. Den 12. des. 2017 19:08, skrev Vivien Didelot: Hi Egil, Egil Hjelmeland writes: Simplify lan9303_indirect_phy_wait_for_completion() and lan9303_switch_wait_for_completion() by using a new function lan9303_read_wait() Signed-off-by: Egil Hjelmeland ---

linux-next: error while fetching the spi-nor tree

Hi Cyrille, Fetching the spi-nor tree (git://git.infradead.org/l2-mtd.git#spi-nor/next) this morning, I get theses errors: remote: error: Could not read 6e408e3aa1643624ea7da50ad5b27a226a16a654 remote: fatal: bad tree object 6e408e3aa1643624ea7da50ad5b27a226a16a654 remote: aborting due to

linux-next: error while fetching the spi-nor tree

Hi Cyrille, Fetching the spi-nor tree (git://git.infradead.org/l2-mtd.git#spi-nor/next) this morning, I get theses errors: remote: error: Could not read 6e408e3aa1643624ea7da50ad5b27a226a16a654 remote: fatal: bad tree object 6e408e3aa1643624ea7da50ad5b27a226a16a654 remote: aborting due to

Re: WARNING in mark_buffer_dirty

On Wed, Nov 15, 2017 at 11:46:00PM -0800, syzbot wrote: > WARNING: CPU: 3 PID: 13366 at fs/buffer.c:1108 > mark_buffer_dirty+0x48b/0x5d0 fs/buffer.c:1108 > Kernel panic - not syncing: panic_on_warn set ... > > hub 1-0:1.0: activate --> -22 > CPU: 3 PID: 13366 Comm: syzkaller183798 Not tainted >

Re: WARNING in mark_buffer_dirty

On Wed, Nov 15, 2017 at 11:46:00PM -0800, syzbot wrote: > WARNING: CPU: 3 PID: 13366 at fs/buffer.c:1108 > mark_buffer_dirty+0x48b/0x5d0 fs/buffer.c:1108 > Kernel panic - not syncing: panic_on_warn set ... > > hub 1-0:1.0: activate --> -22 > CPU: 3 PID: 13366 Comm: syzkaller183798 Not tainted >

Re: [PATCH] drm/i915/gvt/fb_decoder: Fix out-of-bounds read

Hi Zhenyu, Quoting Zhenyu Wang : On 2017.12.09 00:37:59 -0600, Gustavo A. R. Silva wrote: In case function skl_format_to_drm returns -EINVAL, fmt turns into a huge number as fmt is of type u32, hence there is an out-of-bounds read when using fmt as an index for array

Re: [PATCH] drm/i915/gvt/fb_decoder: Fix out-of-bounds read

Hi Zhenyu, Quoting Zhenyu Wang : On 2017.12.09 00:37:59 -0600, Gustavo A. R. Silva wrote: In case function skl_format_to_drm returns -EINVAL, fmt turns into a huge number as fmt is of type u32, hence there is an out-of-bounds read when using fmt as an index for array skl_pixel_formats at line

Re: [PATCH] au0828: fix use-after-free at USB probing

Hey Andrey, Quoting Andrey Konovalov : On Thu, Nov 23, 2017 at 2:31 AM, Gustavo A. R. Silva wrote: Hi Andrey, I have successfully installed and tested syzkaller with QEMU. Can you please tell me how to reproduce this bug or share with me the

Re: [PATCH] au0828: fix use-after-free at USB probing

Hey Andrey, Quoting Andrey Konovalov : On Thu, Nov 23, 2017 at 2:31 AM, Gustavo A. R. Silva wrote: Hi Andrey, I have successfully installed and tested syzkaller with QEMU. Can you please tell me how to reproduce this bug or share with me the full crash report? Also, can you point me out to

Re: [PATCH v2] eeprom: at25: Add DT support for EEPROMs with odd address bits

On Fri, Dec 08, 2017 at 02:46:41PM +0100, Geert Uytterhoeven wrote: > Certain EEPROMS have a size that is larger than the number of address > bytes would allow, and store the MSB of the address in bit 3 of the > instruction byte. > > This can be described in platform data using

Re: [PATCH v2] eeprom: at25: Add DT support for EEPROMs with odd address bits

On Fri, Dec 08, 2017 at 02:46:41PM +0100, Geert Uytterhoeven wrote: > Certain EEPROMS have a size that is larger than the number of address > bytes would allow, and store the MSB of the address in bit 3 of the > instruction byte. > > This can be described in platform data using

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Mon, 2017-11-20 at 12:57 +0100, Peter Zijlstra wrote: > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote: > > + mutex_lock(_counter_mutex); > > + for (i = 0; i < BM_MAX_COUNTERS; i++) { > > + if (bm_counter_owner[i] == NULL) { > > + counter_to_use = i; >

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Mon, 2017-11-20 at 12:57 +0100, Peter Zijlstra wrote: > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote: > > + mutex_lock(_counter_mutex); > > + for (i = 0; i < BM_MAX_COUNTERS; i++) { > > + if (bm_counter_owner[i] == NULL) { > > + counter_to_use = i; >

Re: arm64: unhandled level 0 translation fault

Hi Will, On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon wrote: > On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote: >> On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven >> wrote: >> > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon

Re: arm64: unhandled level 0 translation fault

Hi Will, On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon wrote: > On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote: >> On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven >> wrote: >> > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon wrote: >> >> On Tue, Dec 12, 2017 at 11:20:09AM

Re: WARNING in lock_release

On Mon, Nov 20, 2017 at 05:24:00AM -0800, syzbot wrote: > Hello, > > syzbot has tested the proposed patch and the reproducer did not > trigger crash: > > Tested-by: syzbot > > Once the fix is committed, please reply to this email with: > #syz fix: exact-commit-title

Re: [PATCH v3 1/8] SOC: brcmstb: add memory API

On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas wrote: > On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote: >> From: Florian Fainelli >> >> This commit adds a memory API suitable for ascertaining the sizes of >> each of the N memory controllers

Re: WARNING in lock_release

On Mon, Nov 20, 2017 at 05:24:00AM -0800, syzbot wrote: > Hello, > > syzbot has tested the proposed patch and the reproducer did not > trigger crash: > > Tested-by: syzbot > > Once the fix is committed, please reply to this email with: > #syz fix: exact-commit-title > > Tested on commit

Re: [PATCH v3 1/8] SOC: brcmstb: add memory API

On Tue, Dec 5, 2017 at 3:59 PM, Bjorn Helgaas wrote: > On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote: >> From: Florian Fainelli >> >> This commit adds a memory API suitable for ascertaining the sizes of >> each of the N memory controllers in a Broadcom STB chip. Its first >> user

Re: [PATCH v4 09/12] clk: qcom: Add Krait clock controller driver

On Fri, Dec 08, 2017 at 03:12:27PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The Krait CPU clocks are made up of a primary mux and secondary > mux for each CPU and the L2, controlled via cp15 accessors. For > Kraits within KPSSv1 each secondary mux accepts a

Re: [PATCH v4 09/12] clk: qcom: Add Krait clock controller driver

On Fri, Dec 08, 2017 at 03:12:27PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The Krait CPU clocks are made up of a primary mux and secondary > mux for each CPU and the L2, controlled via cp15 accessors. For > Kraits within KPSSv1 each secondary mux accepts a different aux > source, but

Re: [PATCH v1] scripts/decodecode: Make it take multiline Code line

On Tue, 12 Dec 2017 12:03:23 +0200 Andy Shevchenko wrote: > In case of running scripts/decodecode without any parameters in order to give > a > copy'n'pasted Code line from, for example, email it would parse only first > line > of it, while in emails it's

Re: [PATCH v1] scripts/decodecode: Make it take multiline Code line

On Tue, 12 Dec 2017 12:03:23 +0200 Andy Shevchenko wrote: > In case of running scripts/decodecode without any parameters in order to give > a > copy'n'pasted Code line from, for example, email it would parse only first > line > of it, while in emails it's split to few. > > So, add a logic to

linux-next: Signed-off-by missing for commit in the usb.current tree

Hi Greg, Commit 32fd87b3bbf5 ("USB: core: only clean up what we allocated") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell

linux-next: Signed-off-by missing for commit in the usb.current tree

Hi Greg, Commit 32fd87b3bbf5 ("USB: core: only clean up what we allocated") is missing a Signed-off-by from its author. -- Cheers, Stephen Rothwell

Re: [PATCH V2 3/3] x86, bm: Add documentation on Intel Branch Monitoring

On Mon, 2017-11-20 at 15:07 +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 05:54:06PM -0800, Megha Dey wrote: > > SNIP > > > +IV. User-configurable inputs > > + > > + > > +Several sysfs entries are provided in /sys/devices/intel_bm/ to configure > > +controls for

Re: [PATCH V2 3/3] x86, bm: Add documentation on Intel Branch Monitoring

On Mon, 2017-11-20 at 15:07 +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 05:54:06PM -0800, Megha Dey wrote: > > SNIP > > > +IV. User-configurable inputs > > + > > + > > +Several sysfs entries are provided in /sys/devices/intel_bm/ to configure > > +controls for

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Mon, 2017-11-20 at 15:10 +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote: > > SNIP > > > +/* Branch Monitoring default and mask values */ > > +#define BM_MAX_WINDOW_SIZE 0x3ff > > +#define BM_MAX_THRESHOLD 0x7f > > +#define BM_MAX_EVENTS

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Mon, 2017-11-20 at 15:10 +0100, Jiri Olsa wrote: > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote: > > SNIP > > > +/* Branch Monitoring default and mask values */ > > +#define BM_MAX_WINDOW_SIZE 0x3ff > > +#define BM_MAX_THRESHOLD 0x7f > > +#define BM_MAX_EVENTS

Re: [PATCH v4 05/12] clk: qcom: Add MSM8960/APQ8064's HFPLLs

On Fri, Dec 08, 2017 at 03:12:23PM +0530, Sricharan R wrote: > From: Stephen Boyd > > Describe the HFPLLs present on MSM8960 and APQ8064 devices. > > Signed-off-by: Stephen Boyd > --- > drivers/clk/qcom/gcc-msm8960.c | 172 >

Re: [PATCH v4 05/12] clk: qcom: Add MSM8960/APQ8064's HFPLLs

On Fri, Dec 08, 2017 at 03:12:23PM +0530, Sricharan R wrote: > From: Stephen Boyd > > Describe the HFPLLs present on MSM8960 and APQ8064 devices. > > Signed-off-by: Stephen Boyd > --- > drivers/clk/qcom/gcc-msm8960.c | 172 > +++ >

Re: [patch 13/16] x86/ldt: Introduce LDT write fault handler

On Tue, 12 Dec 2017, Dave Hansen wrote: > On 12/12/2017 11:21 AM, Thomas Gleixner wrote: > > The only critical interaction is the return to user path (user CS/SS) and > > we made sure with the LAR touching that these are precached in the CPU > > before we go into fragile exit code. > > How do we

Re: [PATCH v4 08/12] clk: qcom: Add KPSS ACC/GCC driver

On Fri, Dec 08, 2017 at 03:12:26PM +0530, Sricharan R wrote: > From: Stephen Boyd > > The ACC and GCC regions present in KPSSv1 contain registers to > control clocks and power to each Krait CPU and L2. For CPUfreq > purposes probe these devices and expose a mux clock that

<    7   8   9   10   11   12   13   14   15   16   >