[PATCH v9 2/7] mailbox: qcom: Populate APCS child platform devices

Register the child platform devices to probe their drivers. Signed-off-by: Georgi Djakov --- drivers/mailbox/qcom-apcs-ipc-mailbox.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/mailbox/qcom-apcs-ipc-mailbox.c b/drivers/mailbox/qcom-apcs-ipc-mailbox.c index

[PATCH v9 1/7] mailbox: qcom: Convert APCS IPC driver to use regmap

This hardware block provides more functionalities that just IPC. Convert it to regmap to allow other child platform devices to use the same regmap. Signed-off-by: Georgi Djakov --- drivers/mailbox/qcom-apcs-ipc-mailbox.c | 24 +++- 1 file changed, 19 insertions(+), 5

Re: [PATCH -next] spi: fix spi-sprd-adi build errors when COMPILE_TEST=y

On Thu, Sep 21, 2017 at 09:10:04AM -0700, Randy Dunlap wrote: > +++ linux-next-20170921/drivers/spi/Kconfig > @@ -625,6 +625,7 @@ config SPI_SIRF > config SPI_SPRD_ADI > tristate "Spreadtrum ADI controller" > depends on ARCH_SPRD || COMPILE_TEST >

Re: [PATCH -next] spi: fix spi-sprd-adi build errors when COMPILE_TEST=y

On Thu, Sep 21, 2017 at 09:10:04AM -0700, Randy Dunlap wrote: > +++ linux-next-20170921/drivers/spi/Kconfig > @@ -625,6 +625,7 @@ config SPI_SIRF > config SPI_SPRD_ADI > tristate "Spreadtrum ADI controller" > depends on ARCH_SPRD || COMPILE_TEST >

[PATCH v9 0/7] Add support for Qualcomm A53 CPU clock

This patchset adds support for the A53 CPU clock on MSM8916 platforms and allows scaling of the CPU frequency on msm8916 based platforms. Changes since v8 (https://lkml.org/lkml/2017/6/23/476) * Converted APCS mailbox driver to use regmap and to populate child platform devices that will handle

[PATCH v9 4/7] clk: qcom: Add A53 PLL support

The CPUs on Qualcomm MSM8916-based platforms are clocked by two PLLs, a primary (A53) CPU PLL and a secondary fixed-rate GPLL0. These sources are connected to a mux and half-integer divider, which is feeding the CPU cores. This patch adds support for the primary CPU PLL which generates the higher

[PATCH v9 0/7] Add support for Qualcomm A53 CPU clock

This patchset adds support for the A53 CPU clock on MSM8916 platforms and allows scaling of the CPU frequency on msm8916 based platforms. Changes since v8 (https://lkml.org/lkml/2017/6/23/476) * Converted APCS mailbox driver to use regmap and to populate child platform devices that will handle

[PATCH v9 4/7] clk: qcom: Add A53 PLL support

The CPUs on Qualcomm MSM8916-based platforms are clocked by two PLLs, a primary (A53) CPU PLL and a secondary fixed-rate GPLL0. These sources are connected to a mux and half-integer divider, which is feeding the CPU cores. This patch adds support for the primary CPU PLL which generates the higher

[PATCH v9 6/7] dt-bindings: clock: Document qcom,apcs binding

Add device-tree binding documentation for the Qualcom APCS clock controller. This clock controller is a mux and half-integer divider and provides the clock for the application CPU. Signed-off-by: Georgi Djakov --- .../devicetree/bindings/clock/qcom,apcs.txt| 27

[PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header

Move the structure shared by the APCS IPC device and its subdevices into a separate header file. Signed-off-by: Georgi Djakov --- drivers/mailbox/qcom-apcs-ipc-mailbox.c | 11 +-- include/linux/mailbox/qcom-apcs.h | 34 + 2

[PATCH v9 6/7] dt-bindings: clock: Document qcom,apcs binding

Add device-tree binding documentation for the Qualcom APCS clock controller. This clock controller is a mux and half-integer divider and provides the clock for the application CPU. Signed-off-by: Georgi Djakov --- .../devicetree/bindings/clock/qcom,apcs.txt| 27 ++ 1

[PATCH v9 3/7] mailbox: qcom: Move the apcs struct into a separate header

Move the structure shared by the APCS IPC device and its subdevices into a separate header file. Signed-off-by: Georgi Djakov --- drivers/mailbox/qcom-apcs-ipc-mailbox.c | 11 +-- include/linux/mailbox/qcom-apcs.h | 34 + 2 files changed, 35

Re: [PATCH RT] locking/rtmutex: don't drop the wait_lock twice

On Thu, 21 Sep 2017 18:43:02 +0200 Sebastian Andrzej Siewior wrote: > On 2017-09-21 12:31:05 [-0400], Steven Rostedt wrote: > > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > > > index f03876322d4a..79f49d73e4d0 100644 > > > ---

Re: [PATCH RT] locking/rtmutex: don't drop the wait_lock twice

On Thu, 21 Sep 2017 18:43:02 +0200 Sebastian Andrzej Siewior wrote: > On 2017-09-21 12:31:05 [-0400], Steven Rostedt wrote: > > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > > > index f03876322d4a..79f49d73e4d0 100644 > > > --- a/kernel/locking/rtmutex.c > > > +++

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

On Thu, 21 Sep 2017, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > The issue occurs when we iterate over interface altsettings, but I > don't see the driver doing

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

On Thu, 21 Sep 2017, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > The issue occurs when we iterate over interface altsettings, but I > don't see the driver doing

[PATCH v9 7/7] clk: qcom: Add APCS clock controller support

Add a driver for the APCS clock controller. It is part of the APCS hardware block, which among other things implements also a combined mux and half integer divider functionality. It can choose between a fixed-rate clock or the dedicated APCS (A53) PLL. The source and the divider can be set both at

[PATCH v9 7/7] clk: qcom: Add APCS clock controller support

Add a driver for the APCS clock controller. It is part of the APCS hardware block, which among other things implements also a combined mux and half integer divider functionality. It can choose between a fixed-rate clock or the dedicated APCS (A53) PLL. The source and the divider can be set both at

[PATCH v9 5/7] clk: qcom: Add regmap mux-div clocks support

Add support for hardware that can switch both parent clock and divider at the same time. This avoids generating intermediate frequencies from either the old parent clock and new divider or new parent clock and old divider combinations. Signed-off-by: Georgi Djakov ---

[PATCH v9 5/7] clk: qcom: Add regmap mux-div clocks support

Add support for hardware that can switch both parent clock and divider at the same time. This avoids generating intermediate frequencies from either the old parent clock and new divider or new parent clock and old divider combinations. Signed-off-by: Georgi Djakov --- drivers/clk/qcom/Makefile

Re: [PATCH] debugfs: Add check for module parameter name

Hi, On Thursday 21 September 2017 06:14 PM, Al Viro wrote: On Thu, Sep 21, 2017 at 05:46:54PM +0530, Arvind Yadav wrote: Here, start_creating() is calling by debugfs_create_dir() and debugfs_create_automount(). driver can pass name as NULL in debugfs_create_dir and debugfs_create_automount. So

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 06:30:12PM +0200, Peter Zijlstra wrote: > On Thu, Sep 21, 2017 at 09:00:48AM -0700, Paul E. McKenney wrote: > > commit c21c9b78182e35eb0e72ef4e3bba3054f26eaaea [ . . . ] > Inconsistent spacing after your bullet 'o', first two points have a > space the last two a tab or

Re: [PATCH] debugfs: Add check for module parameter name

Hi, On Thursday 21 September 2017 06:14 PM, Al Viro wrote: On Thu, Sep 21, 2017 at 05:46:54PM +0530, Arvind Yadav wrote: Here, start_creating() is calling by debugfs_create_dir() and debugfs_create_automount(). driver can pass name as NULL in debugfs_create_dir and debugfs_create_automount. So

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 06:30:12PM +0200, Peter Zijlstra wrote: > On Thu, Sep 21, 2017 at 09:00:48AM -0700, Paul E. McKenney wrote: > > commit c21c9b78182e35eb0e72ef4e3bba3054f26eaaea [ . . . ] > Inconsistent spacing after your bullet 'o', first two points have a > space the last two a tab or

Re: [PATCH 09/12] platform/x86: wmi: create character devices when requested by drivers

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello wrote: > For WMI operations that are only Set or Query read or write sysfs > attributes created by WMI vendor drivers make sense. > > For other WMI operations that are run on Method, there needs to be a > way to

Re: [PATCH 09/12] platform/x86: wmi: create character devices when requested by drivers

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello wrote: > For WMI operations that are only Set or Query read or write sysfs > attributes created by WMI vendor drivers make sense. > > For other WMI operations that are run on Method, there needs to be a > way to guarantee to userspace that the

Re: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello wrote: > The Dell WMI descriptor check is used as an indication that WMI > calls are safe to run both when used with the notification > ASL/GUID pair as well as the SMBIOS calling ASL/GUID pair. > > As some code in

Re: [PATCH 07/12] platform/x86: dell-wmi-smbios: Use Dell WMI descriptor check

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello wrote: > The Dell WMI descriptor check is used as an indication that WMI > calls are safe to run both when used with the notification > ASL/GUID pair as well as the SMBIOS calling ASL/GUID pair. > > As some code in dell-wmi-smbios is already a

usb/gadget: copy_to_user called with spinlock held

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). Line numbers might be a little off, due to some local changes to gadgetfs code but the issue is AFAIU with calling copy_to_user() with spinlock held in

usb/gadget: copy_to_user called with spinlock held

Hi! I've got the following report while fuzzing the kernel with syzkaller. On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). Line numbers might be a little off, due to some local changes to gadgetfs code but the issue is AFAIU with calling copy_to_user() with spinlock held in

Re: [PATCH RT] locking/rtmutex: don't drop the wait_lock twice

On 2017-09-21 12:31:05 [-0400], Steven Rostedt wrote: > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > > index f03876322d4a..79f49d73e4d0 100644 > > --- a/kernel/locking/rtmutex.c > > +++ b/kernel/locking/rtmutex.c > > @@ -2281,7 +2281,6 @@ int

Re: [PATCH RT] locking/rtmutex: don't drop the wait_lock twice

On 2017-09-21 12:31:05 [-0400], Steven Rostedt wrote: > > diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c > > index f03876322d4a..79f49d73e4d0 100644 > > --- a/kernel/locking/rtmutex.c > > +++ b/kernel/locking/rtmutex.c > > @@ -2281,7 +2281,6 @@ int

Re: Memory-ordering recipes

On Thu, Sep 21, 2017 at 06:15:47PM +0200, Peter Zijlstra wrote: > On Thu, Sep 21, 2017 at 08:26:42AM -0700, Paul E. McKenney wrote: > > ISA2 is the first one on page 2, and has this pattern of reads and > > writes: > > > > CPU 0 CPU 1 CPU 2 > > > >

Re: Memory-ordering recipes

On Thu, Sep 21, 2017 at 06:15:47PM +0200, Peter Zijlstra wrote: > On Thu, Sep 21, 2017 at 08:26:42AM -0700, Paul E. McKenney wrote: > > ISA2 is the first one on page 2, and has this pattern of reads and > > writes: > > > > CPU 0 CPU 1 CPU 2 > > > >

Re: [git pull][vfs.git] a couple of fixes

On Thu, Sep 21, 2017 at 05:59:57AM -1000, Linus Torvalds wrote: > On Wed, Sep 20, 2017 at 6:13 PM, Al Viro wrote: > > A couple of regression fixes, one for this merge window, one for > > the previous cycle. > > That older fix for 4.13 doesn't seem to be marked

Re: [git pull][vfs.git] a couple of fixes

On Thu, Sep 21, 2017 at 05:59:57AM -1000, Linus Torvalds wrote: > On Wed, Sep 20, 2017 at 6:13 PM, Al Viro wrote: > > A couple of regression fixes, one for this merge window, one for > > the previous cycle. > > That older fix for 4.13 doesn't seem to be marked for stable. > > Can you

Re: [PATCH RT] locking/rtmutex: don't drop the wait_lock twice

On Thu, 21 Sep 2017 17:48:43 +0200 Sebastian Andrzej Siewior wrote: > Since the futex rework, __rt_mutex_start_proxy_lock() does no longer > acquire the wait_lock so it must not drop it. Otherwise the lock is not > only unlocked twice but also the preemption counter is

Re: [PATCH RT] locking/rtmutex: don't drop the wait_lock twice

On Thu, 21 Sep 2017 17:48:43 +0200 Sebastian Andrzej Siewior wrote: > Since the futex rework, __rt_mutex_start_proxy_lock() does no longer > acquire the wait_lock so it must not drop it. Otherwise the lock is not > only unlocked twice but also the preemption counter is underflown. > > Cc:

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 09:00:48AM -0700, Paul E. McKenney wrote: > commit c21c9b78182e35eb0e72ef4e3bba3054f26eaaea > Author: Paul E. McKenney > Date: Mon Sep 18 08:54:40 2017 -0700 > > sched: Make resched_cpu() unconditional > > The current

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 09:00:48AM -0700, Paul E. McKenney wrote: > commit c21c9b78182e35eb0e72ef4e3bba3054f26eaaea > Author: Paul E. McKenney > Date: Mon Sep 18 08:54:40 2017 -0700 > > sched: Make resched_cpu() unconditional > > The current implementation of

Re: [PATCH 8/9 v2] usb: usb251xb: Add max power/current dts property support

On Wed, Sep 20, 2017 at 4:27 PM, Serge Semin wrote: > On Wed, Sep 20, 2017 at 03:52:55PM -0500, Rob Herring wrote: >> On Sat, Sep 16, 2017 at 01:42:19PM +0300, Serge Semin wrote: >> > This parameters may be varied in accordance with hardware specifics.

Re: [PATCH 8/9 v2] usb: usb251xb: Add max power/current dts property support

On Wed, Sep 20, 2017 at 4:27 PM, Serge Semin wrote: > On Wed, Sep 20, 2017 at 03:52:55PM -0500, Rob Herring wrote: >> On Sat, Sep 16, 2017 at 01:42:19PM +0300, Serge Semin wrote: >> > This parameters may be varied in accordance with hardware specifics. >> > So lets add the corresponding settings

Re: [PATCH 03/12] platform/x86: dell-smbios: Add pr_fmt definition to driver

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello wrote: We need a (formal) commit message even for simple patches. > Signed-off-by: Mario Limonciello -- With Best Regards, Andy Shevchenko

Re: [PATCH 03/12] platform/x86: dell-smbios: Add pr_fmt definition to driver

On Thu, Sep 21, 2017 at 4:57 PM, Mario Limonciello wrote: We need a (formal) commit message even for simple patches. > Signed-off-by: Mario Limonciello -- With Best Regards, Andy Shevchenko

[PATCH v3 1/6] serial: imx: remove CTSC and CTS handling from imx_disable_dma

From: Nandor Han The CTSC and CTS bits affect operation of the CTS/RTS hardware flow control signal (depending on whether the device is in DCE or DTE mode) and are not related to DMA. When in RS-232 mode, the driver is using the automatic CTSC control based on a rxFIFO fill

[PATCH v3 1/6] serial: imx: remove CTSC and CTS handling from imx_disable_dma

From: Nandor Han The CTSC and CTS bits affect operation of the CTS/RTS hardware flow control signal (depending on whether the device is in DCE or DTE mode) and are not related to DMA. When in RS-232 mode, the driver is using the automatic CTSC control based on a rxFIFO fill level unless the

[PATCH v3 0/6] serial: imx: various improvements

During shutdown when a userspace service is disabled (which generates an uart close), we got kernel crashes in the imx serial driver : [ 1257.657423] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0938000 [ 1257.665122] pgd = ecf2 [ 1257.667838] [f0938000] *pgd=de819811,

[PATCH v3 0/6] serial: imx: various improvements

During shutdown when a userspace service is disabled (which generates an uart close), we got kernel crashes in the imx serial driver : [ 1257.657423] Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0938000 [ 1257.665122] pgd = ecf2 [ 1257.667838] [f0938000] *pgd=de819811,

[PATCH v3 4/6] serial: imx: unmap sg buffers when DMA channel is released

From: Nandor Han This commits unmaps sg buffers when the DMA channel is released. It also sets to zero `dma_is_rxing` and `dma_is_txing` to state that the corresponding channels cannot transmit/receive data, as these are disabled. Signed-off-by: Nandor Han

[PATCH v3 3/6] serial: imx: Simplify DMA disablement

From: Nandor Han This commits simplify the function imx_disable_dma() by moving the code for disabling RX and TX DMAs to dedicated functions. This is a preparation for the next commit. Signed-off-by: Nandor Han Signed-off-by: Romain Perier

[PATCH v3 4/6] serial: imx: unmap sg buffers when DMA channel is released

From: Nandor Han This commits unmaps sg buffers when the DMA channel is released. It also sets to zero `dma_is_rxing` and `dma_is_txing` to state that the corresponding channels cannot transmit/receive data, as these are disabled. Signed-off-by: Nandor Han Signed-off-by: Romain Perier

[PATCH v3 3/6] serial: imx: Simplify DMA disablement

From: Nandor Han This commits simplify the function imx_disable_dma() by moving the code for disabling RX and TX DMAs to dedicated functions. This is a preparation for the next commit. Signed-off-by: Nandor Han Signed-off-by: Romain Perier Signed-off-by: Martyn Welch ---

[PATCH v3 2/6] serial: imx: only set dma_is_rxing when DMA starts

From: Romain Perier The variable dma_is_rxing is currently set to 1 in imx_disable_rx_int(). This is problematic as: - whilst imx_disable_rx_int() is currently always called before start_rx_dma() this dependency isn't obvious. - start_rx_dma() does error checking

[PATCH v3 2/6] serial: imx: only set dma_is_rxing when DMA starts

From: Romain Perier The variable dma_is_rxing is currently set to 1 in imx_disable_rx_int(). This is problematic as: - whilst imx_disable_rx_int() is currently always called before start_rx_dma() this dependency isn't obvious. - start_rx_dma() does error checking and might exit without

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 08:31:34AM -0700, Paul E. McKenney wrote: > > And given RCU is the only user of that thing, I suppose we can indeed > > change it to a full lock. > > Thank you! May I have your ack? Last version I saw still had a Changelog that looked like whitespace damage.

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 08:31:34AM -0700, Paul E. McKenney wrote: > > And given RCU is the only user of that thing, I suppose we can indeed > > change it to a full lock. > > Thank you! May I have your ack? Last version I saw still had a Changelog that looked like whitespace damage.

[PATCH v3 5/6] serial: imx: update the stop rx,tx procedures

From: Nandor Han According to "Documentation/serial/driver" both procedures should stop receiving or sending data. Based on this the procedures should stop the activity regardless if DMA is enabled or not. This commit updates both imx_stop_{rx|tx} procedures to stop the

[PATCH v3 6/6] serial: imx: Fix imx_shutdown procedure

From: Nandor Han In some cases, it looks that interrupts can happen after the dma was disabled and port was not yet shutdown. This will result in interrupts handled by imx_rxint. This commits updates the shutdown function to ensure that underlying components are disabled in

[PATCH v3 5/6] serial: imx: update the stop rx,tx procedures

From: Nandor Han According to "Documentation/serial/driver" both procedures should stop receiving or sending data. Based on this the procedures should stop the activity regardless if DMA is enabled or not. This commit updates both imx_stop_{rx|tx} procedures to stop the activity and disable the

[PATCH v3 6/6] serial: imx: Fix imx_shutdown procedure

From: Nandor Han In some cases, it looks that interrupts can happen after the dma was disabled and port was not yet shutdown. This will result in interrupts handled by imx_rxint. This commits updates the shutdown function to ensure that underlying components are disabled in the right order.

Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang

On Thu, Sep 21, 2017 at 05:35:11PM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Sep 20, 2017 at 10:32:43AM -0700, H. Peter Anvin wrote: > > > On 09/19/17 11:45, Josh Poimboeuf wrote: > > > > For inline asm statements which have a CALL instruction, we

Re: [PATCH 2/2] x86/asm: Fix inline asm call constraints for clang

On Thu, Sep 21, 2017 at 05:35:11PM +0200, Ingo Molnar wrote: > > * Josh Poimboeuf wrote: > > > On Wed, Sep 20, 2017 at 10:32:43AM -0700, H. Peter Anvin wrote: > > > On 09/19/17 11:45, Josh Poimboeuf wrote: > > > > For inline asm statements which have a CALL instruction, we list the > > > >

RE: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

Hi Joonas: Thanks for the introduction. I have been thinking about the possibility of introducing GEM_BUG_ON into GVT-g recently and investigating on it. I'm just a bit confused about the usage between GEM_BUG_ON and WARN_ON. GEM_BUG_ON is only enabled when kernel debug is enabled, which

RE: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

Hi Joonas: Thanks for the introduction. I have been thinking about the possibility of introducing GEM_BUG_ON into GVT-g recently and investigating on it. I'm just a bit confused about the usage between GEM_BUG_ON and WARN_ON. GEM_BUG_ON is only enabled when kernel debug is enabled, which

Re: Memory-ordering recipes

On Thu, Sep 21, 2017 at 08:26:42AM -0700, Paul E. McKenney wrote: > ISA2 is the first one on page 2, and has this pattern of reads and > writes: > > CPU 0 CPU 1 CPU 2 > > WRITE_ONCE(x, 1); r1 = READ_ONCE(y); r2 = READ_ONCE(z); >

Re: [Xen-devel] [PATCH] xen: support 52 bit physical addresses in pv guests

On 21/09/17 17:00, Boris Ostrovsky wrote: Signed-off-by: Juergen Gross ---    arch/x86/include/asm/xen/page.h | 11 ++-    arch/x86/xen/mmu_pv.c   |  4 ++--    2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h

Re: Memory-ordering recipes

On Thu, Sep 21, 2017 at 08:26:42AM -0700, Paul E. McKenney wrote: > ISA2 is the first one on page 2, and has this pattern of reads and > writes: > > CPU 0 CPU 1 CPU 2 > > WRITE_ONCE(x, 1); r1 = READ_ONCE(y); r2 = READ_ONCE(z); >

Re: [Xen-devel] [PATCH] xen: support 52 bit physical addresses in pv guests

On 21/09/17 17:00, Boris Ostrovsky wrote: Signed-off-by: Juergen Gross ---    arch/x86/include/asm/xen/page.h | 11 ++-    arch/x86/xen/mmu_pv.c   |  4 ++--    2 files changed, 12 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/xen/page.h

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

On Thu, Sep 21, 2017 at 05:39:05PM +0200, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > The issue occurs when we iterate over interface altsettings, but I > don't see

Re: usb/storage/uas: slab-out-of-bounds in uas_probe

On Thu, Sep 21, 2017 at 05:39:05PM +0200, Andrey Konovalov wrote: > Hi! > > I've got the following report while fuzzing the kernel with syzkaller. > > On commit ebb2c2437d8008d46796902ff390653822af6cc4 (Sep 18). > > The issue occurs when we iterate over interface altsettings, but I > don't see

[PATCH -next] spi: fix spi-sprd-adi build errors when COMPILE_TEST=y

nel.org --- drivers/spi/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20170921.orig/drivers/spi/Kconfig +++ linux-next-20170921/drivers/spi/Kconfig @@ -625,6 +625,7 @@ config SPI_SIRF config SPI_SPRD_ADI tristate "Spreadtrum ADI controller" de

[PATCH -next] spi: fix spi-sprd-adi build errors when COMPILE_TEST=y

to `__hwspin_lock_timeout' spi-sprd-adi.c:(.text+0x3ee): undefined reference to `__hwspin_unlock' Signed-off-by: Randy Dunlap Cc: Baolin Wang Cc: Mark Brown Cc: linux-...@vger.kernel.org --- drivers/spi/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20170921.orig/drivers/spi

Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

On Thu, 21 Sep 2017, Kees Cook wrote: > > So what is the point of this patch? > > The DMA kmalloc caches are not whitelisted: The DMA kmalloc caches are pretty obsolete and mostly there for obscure drivers. ?? > >> kmalloc_dma_caches[i] = create_kmalloc_cache(n, > >> -

Re: [kernel-hardening] Re: [PATCH v3 03/31] usercopy: Mark kmalloc caches as usercopy caches

On Thu, 21 Sep 2017, Kees Cook wrote: > > So what is the point of this patch? > > The DMA kmalloc caches are not whitelisted: The DMA kmalloc caches are pretty obsolete and mostly there for obscure drivers. ?? > >> kmalloc_dma_caches[i] = create_kmalloc_cache(n, > >> -

Re: [PATCH] xen: support 52 bit physical addresses in pv guests

On 09/21/2017 10:41 AM, Juergen Gross wrote: On 21/09/17 16:14, Boris Ostrovsky wrote: On 09/21/2017 04:01 AM, Juergen Gross wrote: Physical addresses on processors supporting 5 level paging can be up to 52 bits wide. For a Xen pv guest running on such a machine those physical addresses

Re: [PATCH] xen: support 52 bit physical addresses in pv guests

On 09/21/2017 10:41 AM, Juergen Gross wrote: On 21/09/17 16:14, Boris Ostrovsky wrote: On 09/21/2017 04:01 AM, Juergen Gross wrote: Physical addresses on processors supporting 5 level paging can be up to 52 bits wide. For a Xen pv guest running on such a machine those physical addresses

[PATCH] jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path

If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode() can get called twice in the error handling path, the first call in jffs2_iget() itself and the second through iget_failed(). This can result to a use-after-free error in the second jffs2_do_clear_inode() call, such as shown

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 03:59:46PM +0200, Peter Zijlstra wrote: > On Tue, Sep 19, 2017 at 08:31:26AM -0700, Paul E. McKenney wrote: > > So I have this one queued. Objections? > > Changelog reads like its whitespace damaged. It does, now that you mention it. How about the updated version below?

[PATCH] jffs2: Fix use-after-free bug in jffs2_iget()'s error handling path

If jffs2_iget() fails for a newly-allocated inode, jffs2_do_clear_inode() can get called twice in the error handling path, the first call in jffs2_iget() itself and the second through iget_failed(). This can result to a use-after-free error in the second jffs2_do_clear_inode() call, such as shown

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Thu, Sep 21, 2017 at 03:59:46PM +0200, Peter Zijlstra wrote: > On Tue, Sep 19, 2017 at 08:31:26AM -0700, Paul E. McKenney wrote: > > So I have this one queued. Objections? > > Changelog reads like its whitespace damaged. It does, now that you mention it. How about the updated version below?

Re: [PATCH 7/7] fs-writeback: only allow one inflight and pending full flush

On 09/21/2017 09:36 AM, Jens Axboe wrote: >> But more importantly once we are not guaranteed that we only have >> a single global wb_writeback_work per bdi_writeback we should just >> embedd that into struct bdi_writeback instead of dynamically >> allocating it. > > We could do this as a followup.

Re: [PATCH 7/7] fs-writeback: only allow one inflight and pending full flush

On 09/21/2017 09:36 AM, Jens Axboe wrote: >> But more importantly once we are not guaranteed that we only have >> a single global wb_writeback_work per bdi_writeback we should just >> embedd that into struct bdi_writeback instead of dynamically >> allocating it. > > We could do this as a followup.

Re: [git pull][vfs.git] a couple of fixes

On Wed, Sep 20, 2017 at 6:13 PM, Al Viro wrote: > A couple of regression fixes, one for this merge window, one for > the previous cycle. That older fix for 4.13 doesn't seem to be marked for stable. Can you make sure it gets to Greg? Linus

Re: [git pull][vfs.git] a couple of fixes

On Wed, Sep 20, 2017 at 6:13 PM, Al Viro wrote: > A couple of regression fixes, one for this merge window, one for > the previous cycle. That older fix for 4.13 doesn't seem to be marked for stable. Can you make sure it gets to Greg? Linus

Applied "ASoC: davinci-mcasp: Handle return value of devm_kasprintf" to the asoc tree

The patch ASoC: davinci-mcasp: Handle return value of devm_kasprintf has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: davinci-mcasp: Handle return value of devm_kasprintf" to the asoc tree

The patch ASoC: davinci-mcasp: Handle return value of devm_kasprintf has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: fsl-asoc-card: Handle return value of devm_kasprintf" to the asoc tree

The patch ASoC: fsl-asoc-card: Handle return value of devm_kasprintf has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

Applied "ASoC: fsl-asoc-card: Handle return value of devm_kasprintf" to the asoc tree

The patch ASoC: fsl-asoc-card: Handle return value of devm_kasprintf has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours)

[PATCH] Drop unlikely with IS_ERR

As we know IS_ERR (and its similar instances) uses unlikely in definition so we don't have to mark unlikely second time. Signed-off-by: xNombre --- block/blk-cgroup.c| 2 +- drivers/crypto/caam/caamalg_qi.c

[PATCH] Drop unlikely with IS_ERR

As we know IS_ERR (and its similar instances) uses unlikely in definition so we don't have to mark unlikely second time. Signed-off-by: xNombre --- block/blk-cgroup.c| 2 +- drivers/crypto/caam/caamalg_qi.c | 6 +++---

Applied "ASoC: omap-hdmi-audio: Handle return value of devm_kasprintf" to the asoc tree

The patch ASoC: omap-hdmi-audio: Handle return value of devm_kasprintf has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

Applied "ASoC: omap-hdmi-audio: Handle return value of devm_kasprintf" to the asoc tree

The patch ASoC: omap-hdmi-audio: Handle return value of devm_kasprintf has been applied to the asoc tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

[PATCH v5 3/6] iommu/iova: Extend rbtree node caching

The cached node mechanism provides a significant performance benefit for allocations using a 32-bit DMA mask, but in the case of non-PCI devices or where the 32-bit space is full, the loss of this benefit can be significant - on large systems there can be many thousands of entries in the tree,

[PATCH v5 3/6] iommu/iova: Extend rbtree node caching

The cached node mechanism provides a significant performance benefit for allocations using a 32-bit DMA mask, but in the case of non-PCI devices or where the 32-bit space is full, the loss of this benefit can be significant - on large systems there can be many thousands of entries in the tree,

[PATCH v5 4/6] iommu/iova: Make dma_32bit_pfn implicit

From: Zhen Lei Now that the cached node optimisation can apply to all allocations, the couple of users which were playing tricks with dma_32bit_pfn in order to benefit from it can stop doing so. Conversely, there is also no need for all the other users to explicitly

[PATCH v5 5/6] iommu/iova: Add rbtree anchor node

Add a permanent dummy IOVA reservation to the rbtree, such that we can always access the top of the address space instantly. The immediate benefit is that we remove the overhead of the rb_last() traversal when not using the cached node, but it also paves the way for further simplifications.

[PATCH v5 4/6] iommu/iova: Make dma_32bit_pfn implicit

From: Zhen Lei Now that the cached node optimisation can apply to all allocations, the couple of users which were playing tricks with dma_32bit_pfn in order to benefit from it can stop doing so. Conversely, there is also no need for all the other users to explicitly calculate a 'real' 32-bit

[PATCH v5 5/6] iommu/iova: Add rbtree anchor node

Add a permanent dummy IOVA reservation to the rbtree, such that we can always access the top of the address space instantly. The immediate benefit is that we remove the overhead of the rb_last() traversal when not using the cached node, but it also paves the way for further simplifications.

[PATCH v5 0/6] Optimise 64-bit IOVA allocations

v4: https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1493704.html Right, this is hopefully the last version - I've put things back in a sensible order with the new additions at the end, so if they prove contentious the first 4 previously-tested patches can still get their time in

[PATCH v5 1/6] iommu/iova: Optimise rbtree searching

From: Zhen Lei Checking the IOVA bounds separately before deciding which direction to continue the search (if necessary) results in redundantly comparing both pfns twice each. GCC can already determine that the final comparison op is redundant and optimise it down to

<    3   4   5   6   7   8   9   10   11   12   >