Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)

On Sat, 2017-09-16 at 11:20 -0700, Linus Torvalds wrote: > On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar wrote: > > > > To resolve this locking problem, this patch defines a new > > ->integrity_read file operation method, which is equivalent to > > ->read_iter, except that

Re: [PATCH 3/3] ima: use fs method to read integrity data (updated patch description)

On Sat, 2017-09-16 at 11:20 -0700, Linus Torvalds wrote: > On Fri, Sep 15, 2017 at 1:25 PM, Mimi Zohar wrote: > > > > To resolve this locking problem, this patch defines a new > > ->integrity_read file operation method, which is equivalent to > > ->read_iter, except that it will not take the

Re: rcu kernel-doc issues (4.14-rc1)

On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: > On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: > > .. kernel-doc:: include/linux/rcupdate.h >:external: > ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" > directive: > unknown option:

Re: rcu kernel-doc issues (4.14-rc1)

On Sat, Sep 16, 2017 at 06:26:04PM -0700, Randy Dunlap wrote: > On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: > > .. kernel-doc:: include/linux/rcupdate.h >:external: > ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" > directive: > unknown option:

[PATCH 06/10] powerpc/vas: Reduce polling interval for busy state

A VAS window is normally in "busy" state for only a short duration. Reduce the time we wait for the window to go to "not-busy" state to speed-up vas_win_close() a bit. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 10 ++

[PATCH 06/10] powerpc/vas: Reduce polling interval for busy state

A VAS window is normally in "busy" state for only a short duration. Reduce the time we wait for the window to go to "not-busy" state to speed-up vas_win_close() a bit. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 10 ++ 1 file changed, 6

[PATCH 07/10] powerpc/vas: Save configured window credits

Save the configured max window credits for a window in the vas_window structure. We will need this when polling for return of window credits. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 6 --

[PATCH 00/10] powerpc/vas: cleanup and optimizations

Sanitize cpu/chip id to VAS id mapping, improve vas_win_close() performance and add a check for return of credits. Also, fix up couple of initializations/error checks and cleanup some comments and debug code. Sukadev Bhattiprolu (10): powerpc/vas: init missing fields from [rt]xattr

[PATCH 02/10] powerpc/vas: Validate window credits

NX-842, the only user of VAS, sets the window credits to default values but VAS should check the credits against the possible max values. The VAS_WCREDS_MIN is not needed and can be dropped. Signed-off-by: Sukadev Bhattiprolu ---

[PATCH 00/10] powerpc/vas: cleanup and optimizations

Sanitize cpu/chip id to VAS id mapping, improve vas_win_close() performance and add a check for return of credits. Also, fix up couple of initializations/error checks and cleanup some comments and debug code. Sukadev Bhattiprolu (10): powerpc/vas: init missing fields from [rt]xattr

[PATCH 02/10] powerpc/vas: Validate window credits

NX-842, the only user of VAS, sets the window credits to default values but VAS should check the credits against the possible max values. The VAS_WCREDS_MIN is not needed and can be dropped. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 6 ++

[PATCH 07/10] powerpc/vas: Save configured window credits

Save the configured max window credits for a window in the vas_window structure. We will need this when polling for return of window credits. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 6 -- arch/powerpc/platforms/powernv/vas.h| 1 + 2 files

[PATCH 05/10] powerpc/vas: Use helper to unpin/close window

Use a helper to have the hardware unpin and mark a window closed. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git

[PATCH 05/10] powerpc/vas: Use helper to unpin/close window

Use a helper to have the hardware unpin and mark a window closed. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 22 +++--- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/arch/powerpc/platforms/powernv/vas-window.c

[PATCH 03/10] powerpc/vas: Cleanup some debug code

Cleanuup vas.h and the debug code around ifdef vas_debug. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 8 +++-- arch/powerpc/platforms/powernv/vas.h| 56 +++-- 2 files changed, 18 insertions(+),

[PATCH 03/10] powerpc/vas: Cleanup some debug code

Cleanuup vas.h and the debug code around ifdef vas_debug. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 8 +++-- arch/powerpc/platforms/powernv/vas.h| 56 +++-- 2 files changed, 18 insertions(+), 46 deletions(-) diff --git

[PATCH 09/10] powerpc/vas: Create cpu to vas id mapping

Create a cpu to vasid mapping so callers can specify -1 instead of trying to find a VAS id. Changelog[v2] [Michael Ellerman] Use per-cpu variables to simplify code. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas.c | 14

[PATCH 09/10] powerpc/vas: Create cpu to vas id mapping

Create a cpu to vasid mapping so callers can specify -1 instead of trying to find a VAS id. Changelog[v2] [Michael Ellerman] Use per-cpu variables to simplify code. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas.c | 14 +- 1 file changed, 13

[PATCH 08/10] powerpc/vas: poll for return of window credits

Normally, the NX driver waits for the CRBs to be processed before closing the window. But it is better to ensure that the credits are returned before the window gets reassigned later. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c

[PATCH 08/10] powerpc/vas: poll for return of window credits

Normally, the NX driver waits for the CRBs to be processed before closing the window. But it is better to ensure that the credits are returned before the window gets reassigned later. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 45

[PATCH 10/10] powerpc/vas, nx-842: Define and use chip_to_vas_id()

Define a helper, chip_to_vas_id() to map a given chip id to corresponding vas id. Normally, callers of vas_rx_win_open() and vas_tx_win_open() would need the VAS window to be on the same chip where the calling thread is executing. These callers can pass in -1 for the VAS id. This interface will

[PATCH 04/10] powerpc/vas: Drop poll_window_cast_out().

Polling for window cast out is listed in the spec, but turns out that it is not strictly necessary and slows down window close. Making it a stub for now. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 34

[PATCH 10/10] powerpc/vas, nx-842: Define and use chip_to_vas_id()

Define a helper, chip_to_vas_id() to map a given chip id to corresponding vas id. Normally, callers of vas_rx_win_open() and vas_tx_win_open() would need the VAS window to be on the same chip where the calling thread is executing. These callers can pass in -1 for the VAS id. This interface will

[PATCH 04/10] powerpc/vas: Drop poll_window_cast_out().

Polling for window cast out is listed in the spec, but turns out that it is not strictly necessary and slows down window close. Making it a stub for now. Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/platforms/powernv/vas-window.c | 34 ++--- 1 file changed, 17

[PATCH 01/10] powerpc/vas: init missing fields from [rt]xattr

Initialize a few missing window context fields from the window attributes specified by the caller. These fields are currently set to their default values by the caller (NX-842), but would be good to apply them anyway. Signed-off-by: Sukadev Bhattiprolu ---

[PATCH 01/10] powerpc/vas: init missing fields from [rt]xattr

Initialize a few missing window context fields from the window attributes specified by the caller. These fields are currently set to their default values by the caller (NX-842), but would be good to apply them anyway. Signed-off-by: Sukadev Bhattiprolu ---

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 09/14/2017 04:17 AM, Christophe LEROY wrote: > Le 14/09/2017 à 01:51, Rob Landley a écrit : >> From: Rob Landley >> >> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >> /dev/console open after devtmpfs mount. >> >> Add workaround for Debian bug that was copied by

Re: [PATCH v3] Make initramfs honor CONFIG_DEVTMPFS_MOUNT

On 09/14/2017 04:17 AM, Christophe LEROY wrote: > Le 14/09/2017 à 01:51, Rob Landley a écrit : >> From: Rob Landley >> >> Make initramfs honor CONFIG_DEVTMPFS_MOUNT, and move >> /dev/console open after devtmpfs mount. >> >> Add workaround for Debian bug that was copied by Ubuntu. > > Is that a

Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags

On Tue, Aug 15, 2017 at 5:27 AM, Jan Kara wrote: > On Mon 14-08-17 23:12:16, Dan Williams wrote: >> The mmap syscall suffers from the ABI anti-pattern of not validating >> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a >> mechanism to define new behavior that

Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags

On Tue, Aug 15, 2017 at 5:27 AM, Jan Kara wrote: > On Mon 14-08-17 23:12:16, Dan Williams wrote: >> The mmap syscall suffers from the ABI anti-pattern of not validating >> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a >> mechanism to define new behavior that is known to

net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e commit: 8073e960a03bf7b5d5ebfc5ff18ac475e1688f46 netfilter: nat: use keyed locks date: 8 days ago config: x86_64-randconfig-s4-09170918 (attached as .config)

net//netfilter/nf_nat_core.c:810:2: note: in expansion of macro 'if'

tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e commit: 8073e960a03bf7b5d5ebfc5ff18ac475e1688f46 netfilter: nat: use keyed locks date: 8 days ago config: x86_64-randconfig-s4-09170918 (attached as .config)

[PATCH v2 03/10] dmaengine: sun6i: Restructure code to allow extension for new SoCs

The current code mixes three distinct operations when transforming the slave config to register settings: 1. special handling of DMA_SLAVE_BUSWIDTH_UNDEFINED, maxburst == 0 2. range checking 3. conversion of raw to register values As the range checks depend on the specific SoC, move these

[PATCH v2 03/10] dmaengine: sun6i: Restructure code to allow extension for new SoCs

The current code mixes three distinct operations when transforming the slave config to register settings: 1. special handling of DMA_SLAVE_BUSWIDTH_UNDEFINED, maxburst == 0 2. range checking 3. conversion of raw to register values As the range checks depend on the specific SoC, move these

[PATCH v2 04/10] dmaengine: sun6i: Enable additional burst lengths/widths on H3

The H3 supports bursts lengths of 1, 4, 8 and 16 transfers, each with a width of 1, 2, 4 or 8 bytes. The register value for the the width is log2-encoded, change the conversion function to provide the correct value for width == 8. Signed-off-by: Stefan Brüns ---

[PATCH v2 00/10] dmaengine: sun6i: Fixes for H3/A83T, enable A64

Commit 3a03ea763a67 ("dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant") and commit f008db8c00c1 ("dmaengine: sun6i: Add support for Allwinner H3 (sun8i) variant") added support for the A83T resp. H3, but missed some differences between the original A31 and A83T/H3. The first

[PATCH v2 04/10] dmaengine: sun6i: Enable additional burst lengths/widths on H3

The H3 supports bursts lengths of 1, 4, 8 and 16 transfers, each with a width of 1, 2, 4 or 8 bytes. The register value for the the width is log2-encoded, change the conversion function to provide the correct value for width == 8. Signed-off-by: Stefan Brüns --- drivers/dma/sun6i-dma.c | 54

[PATCH v2 00/10] dmaengine: sun6i: Fixes for H3/A83T, enable A64

Commit 3a03ea763a67 ("dmaengine: sun6i: Add support for Allwinner A83T (sun8i) variant") and commit f008db8c00c1 ("dmaengine: sun6i: Add support for Allwinner H3 (sun8i) variant") added support for the A83T resp. H3, but missed some differences between the original A31 and A83T/H3. The first

[PATCH v2 02/10] dmaengine: sun6i: Correct burst length field offsets for H3

For the H3, the burst lengths field offsets in the channel configuration register differs from earlier SoC generations. Using the A31 register macros actually configured the H3 controller do to bursts of length 1 always, which although working leads to higher bus utilisation. Signed-off-by:

[PATCH v2 02/10] dmaengine: sun6i: Correct burst length field offsets for H3

For the H3, the burst lengths field offsets in the channel configuration register differs from earlier SoC generations. Using the A31 register macros actually configured the H3 controller do to bursts of length 1 always, which although working leads to higher bus utilisation. Signed-off-by:

[PATCH v2 01/10] dmaengine: sun6i: Correct setting of clock autogating register for A83T/H3

The H83T uses a compatible string different from the A23, but requires the same clock autogating register setting. The H3 also requires setting the clock autogating register, but has the register at a different offset. Add three suitable callbacks for the existing controller generations and set

[PATCH v2 09/10] arm64: allwinner: a64: Add device node for DMA controller

The A64 SoC has a DMA controller that supports 8 DMA channels to and from various peripherals. The last used DRQ port is 27. Add a device node for it. Signed-off-by: Stefan Brüns --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++ 1 file changed,

[PATCH v2 01/10] dmaengine: sun6i: Correct setting of clock autogating register for A83T/H3

The H83T uses a compatible string different from the A23, but requires the same clock autogating register setting. The H3 also requires setting the clock autogating register, but has the register at a different offset. Add three suitable callbacks for the existing controller generations and set

[PATCH v2 09/10] arm64: allwinner: a64: Add device node for DMA controller

The A64 SoC has a DMA controller that supports 8 DMA channels to and from various peripherals. The last used DRQ port is 27. Add a device node for it. Signed-off-by: Stefan Brüns --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 11 +++ 1 file changed, 11 insertions(+) diff --git

[PATCH v2 05/10] dmaengine: sun6i: Move number of pchans/vchans/request to device struct

Preparatory patch: If the same compatible is used for different SoCs which have a common register layout, but different number of channels, the channel count can no longer be stored in the config. Store it in the device structure instead. Signed-off-by: Stefan Brüns

[PATCH v2 05/10] dmaengine: sun6i: Move number of pchans/vchans/request to device struct

Preparatory patch: If the same compatible is used for different SoCs which have a common register layout, but different number of channels, the channel count can no longer be stored in the config. Store it in the device structure instead. Signed-off-by: Stefan Brüns --- drivers/dma/sun6i-dma.c

[PATCH v2 10/10] arm64: allwinner: a64: add dma controller references to spi nodes

The spi controller nodes omit the dma controller/channel references, add it. This does not yet enable DMA for SPI transfers, as the spi-sun6i driver lacks support for DMA, but always uses PIO to the FIFO. Signed-off-by: Stefan Brüns ---

[PATCH v2 10/10] arm64: allwinner: a64: add dma controller references to spi nodes

The spi controller nodes omit the dma controller/channel references, add it. This does not yet enable DMA for SPI transfers, as the spi-sun6i driver lacks support for DMA, but always uses PIO to the FIFO. Signed-off-by: Stefan Brüns --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 1

[PATCH v2 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree

To avoid introduction of a new compatible for each small SoC/DMA controller variation, move the definition of the channel count to the devicetree. The number of vchans is no longer explicit, but limited by the highest port/DMA request number. The result is a slight overallocation for SoCs with a

[PATCH v2 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree

To avoid introduction of a new compatible for each small SoC/DMA controller variation, move the definition of the channel count to the devicetree. The number of vchans is no longer explicit, but limited by the highest port/DMA request number. The result is a slight overallocation for SoCs with a

[PATCH v2 08/10] dmaengine: sun6i: Add support for Allwinner A64 and compatibles

The A64 SoC has the same dma engine as the H3 (sun8i), with a reduced amount of physical channels. To allow future reuse of the compatible, leave the channel count etc. in the config data blank and retrieve it from the devicetree. Signed-off-by: Stefan Brüns ---

[PATCH v2 08/10] dmaengine: sun6i: Add support for Allwinner A64 and compatibles

The A64 SoC has the same dma engine as the H3 (sun8i), with a reduced amount of physical channels. To allow future reuse of the compatible, leave the channel count etc. in the config data blank and retrieve it from the devicetree. Signed-off-by: Stefan Brüns --- drivers/dma/sun6i-dma.c | 23

[PATCH v2 06/10] arm64: allwinner: a64: Add devicetree binding for DMA controller

The A64 is register compatible with the H3, but has a different number of dma channels and request ports. Attach additional properties to the node to allow future reuse of the compatible for controllers with different number of channels/requests. If dma-requests is not specified, the register

[PATCH v2 06/10] arm64: allwinner: a64: Add devicetree binding for DMA controller

The A64 is register compatible with the H3, but has a different number of dma channels and request ports. Attach additional properties to the node to allow future reuse of the compatible for controllers with different number of channels/requests. If dma-requests is not specified, the register

[PATCH v5] blktrace: Fix potentail deadlock between delete & sysfs ops

The lockdep code had reported the following unsafe locking scenario: CPU0CPU1 lock(s_active#228); lock(>bd_mutex/1); lock(s_active#228); lock(>bd_mutex); *** DEADLOCK

[PATCH v5] blktrace: Fix potentail deadlock between delete & sysfs ops

The lockdep code had reported the following unsafe locking scenario: CPU0CPU1 lock(s_active#228); lock(>bd_mutex/1); lock(s_active#228); lock(>bd_mutex); *** DEADLOCK

Re: [lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

On Sat, Sep 16, 2017 at 6:40 PM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an > incorrect warning with CONFIG_DEBUG_VM=y, !PCID") >

Re: [lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

On Sat, Sep 16, 2017 at 6:40 PM, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an > incorrect warning with CONFIG_DEBUG_VM=y, !PCID") > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git

Re: [linux-sunxi] [PATCH 3/4] arm64: allwinner: h5: add compatible string for DE2 CCU

Hi Icenowy, On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng wrote: > The DE2 CCU on Allwinner H5 SoC has a slightly different behavior than > the one on H3, so the compatible string is not set in the common DTSI > file. > > Add the compatible string of H5 DE2 CCU in H5 DTSI file.

Re: [linux-sunxi] [PATCH 3/4] arm64: allwinner: h5: add compatible string for DE2 CCU

Hi Icenowy, On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng wrote: > The DE2 CCU on Allwinner H5 SoC has a slightly different behavior than > the one on H3, so the compatible string is not set in the common DTSI > file. > > Add the compatible string of H5 DE2 CCU in H5 DTSI file. > >

Re: [linux-sunxi] [PATCH 2/4] ARM: sun8i: h3/h5: add DE2 CCU device node for H3

Hi Icenowy, On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng wrote: > The DE2 in H3/H5 has a clock control unit in it, and the behavior is > slightly different between H3 and H5. > > Add the common parts in H3/H5 DTSI, and add the compatible string in H3 > DTSI. > > The compatible

Re: [linux-sunxi] [PATCH 2/4] ARM: sun8i: h3/h5: add DE2 CCU device node for H3

Hi Icenowy, On Tue, Sep 12, 2017 at 1:55 AM, Icenowy Zheng wrote: > The DE2 in H3/H5 has a clock control unit in it, and the behavior is > slightly different between H3 and H5. > > Add the common parts in H3/H5 DTSI, and add the compatible string in H3 > DTSI. > > The compatible string of H5 DE2

arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'

Hi Felix, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e commit: 70539bd79500245cbb4c7af00572fcce540d0105 drm/amd: Update MEC HQD loading code for KFD date: 5 weeks ago

arch/alpha/include/asm/mmu_context.h:160:2: error: implicit declaration of function 'task_thread_info'

Hi Felix, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e commit: 70539bd79500245cbb4c7af00572fcce540d0105 drm/amd: Update MEC HQD loading code for KFD date: 5 weeks ago

[lkp-robot] [ipmi_si] d830f6514c: WARNING:at_drivers/base/driver.c:#driver_unregister

FYI, we noticed the following commit: commit: d830f6514cdf359bcd7201306ac792ffa27f7966 ("ipmi_si: Move platform device handling to another file") https://github.com/cminyard/linux-ipmi master-ipmi-rebase in testcase: trinity with following parameters: runtime: 300s test-description:

[lkp-robot] [ipmi_si] d830f6514c: WARNING:at_drivers/base/driver.c:#driver_unregister

FYI, we noticed the following commit: commit: d830f6514cdf359bcd7201306ac792ffa27f7966 ("ipmi_si: Move platform device handling to another file") https://github.com/cminyard/linux-ipmi master-ipmi-rebase in testcase: trinity with following parameters: runtime: 300s test-description:

[lkp-robot] [kernfs, sysfs, cgroup, intel_rdt] 89e689f267: kernel_BUG_at_fs/super.c

FYI, we noticed the following commit: commit: 89e689f267b2c144d7b071443e01fa718727b962 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context") https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context in testcase: trinity with following parameters: runtime:

[lkp-robot] [kernfs, sysfs, cgroup, intel_rdt] 89e689f267: kernel_BUG_at_fs/super.c

FYI, we noticed the following commit: commit: 89e689f267b2c144d7b071443e01fa718727b962 ("kernfs, sysfs, cgroup, intel_rdt: Support fs_context") https://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git mount-context in testcase: trinity with following parameters: runtime:

[lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

FYI, we noticed the following commit: commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an incorrect warning with CONFIG_DEBUG_VM=y, !PCID") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: boot on test machine: qemu-system-i386 -enable-kvm

[lkp-robot] [x86/mm/64] 7898f79654: WARNING:at_arch/x86/mm/tlb.c:#initialize_tlbstate_and_flush

FYI, we noticed the following commit: commit: 7898f79654698dcea5a0876785796de67d527ee7 ("x86/mm/64: Fix an incorrect warning with CONFIG_DEBUG_VM=y, !PCID") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: boot on test machine: qemu-system-i386 -enable-kvm

kernel-doc: handle DECLARE_KFIFO() ?

scripts/kernel-doc handles DECLARE_BITMAP() and DECLARE_HASHTABLE(). Recently drivers/gpio/gpiolib.c has been changed to use DECLARE_KFIFO() *and* that is inside kernel-doc notation, but scripts/kernel-doc doesn't know about DECLARE_KFIFO(), so it causes these warnings:

kernel-doc: handle DECLARE_KFIFO() ?

scripts/kernel-doc handles DECLARE_BITMAP() and DECLARE_HASHTABLE(). Recently drivers/gpio/gpiolib.c has been changed to use DECLARE_KFIFO() *and* that is inside kernel-doc notation, but scripts/kernel-doc doesn't know about DECLARE_KFIFO(), so it causes these warnings:

rcu kernel-doc issues (4.14-rc1)

On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: .. kernel-doc:: include/linux/rcupdate.h :external: ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" directive: unknown option: "external". .. kernel-doc:: include/linux/rcupdate_wait.h :external:

rcu kernel-doc issues (4.14-rc1)

On 4.14-rc1, I am seeing lots of warnings on rcu kernel-doc: .. kernel-doc:: include/linux/rcupdate.h :external: ./Documentation/core-api/kernel-api.rst:357: ERROR: Error in "kernel-doc" directive: unknown option: "external". .. kernel-doc:: include/linux/rcupdate_wait.h :external:

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Fri, Sep 15, 2017 at 04:44:38PM +0530, Neeraj Upadhyay wrote: > Hi, > > We have one query regarding the behavior of RCU expedited grace period, > for scenario where resched_cpu() in sync_sched_exp_handler() fails to > acquire the rq lock and returns w/o setting the need_resched. In this >

Re: Query regarding synchronize_sched_expedited and resched_cpu

On Fri, Sep 15, 2017 at 04:44:38PM +0530, Neeraj Upadhyay wrote: > Hi, > > We have one query regarding the behavior of RCU expedited grace period, > for scenario where resched_cpu() in sync_sched_exp_handler() fails to > acquire the rq lock and returns w/o setting the need_resched. In this >

Linux 4.14-rc1

Yes, I realize this is a day early, and yes, I realize that if I had waited until tomorrow, I would also have hit the 26th anniversary of the Linux-0.01 release, but neither of those undeniable facts made me want to wait with closing the mege window. This has been an "interesting" merge window.

Linux 4.14-rc1

Yes, I realize this is a day early, and yes, I realize that if I had waited until tomorrow, I would also have hit the 26th anniversary of the Linux-0.01 release, but neither of those undeniable facts made me want to wait with closing the mege window. This has been an "interesting" merge window.

Re: Regression in virtio block driver with 4.13.2

On 09/15/2017 10:37 AM, Christoph Hellwig wrote: On Fri, Sep 15, 2017 at 09:54:08AM -0700, Laura Abbott wrote: Hi, Fedora got a bug report on an early version of 4.13.2 https://paste.fedoraproject.org/paste/t-Yx23LN5QwJ7oPZLj3zrg Can you check if the issue goes away when you disable

Re: Regression in virtio block driver with 4.13.2

On 09/15/2017 10:37 AM, Christoph Hellwig wrote: On Fri, Sep 15, 2017 at 09:54:08AM -0700, Laura Abbott wrote: Hi, Fedora got a bug report on an early version of 4.13.2 https://paste.fedoraproject.org/paste/t-Yx23LN5QwJ7oPZLj3zrg Can you check if the issue goes away when you disable

Re: [PATCH] irqchip/gicv3: Add support for Range Selector (RS) feature

Hi Marc, On 09/16/2017 01:14 PM, Marc Zyngier wrote: > On Fri, Sep 15 2017 at 10:08:56 am BST, Shanker Donthineni > wrote: > > Hi Shanker, > >> A new feature Range Selector (RS) has been added to GIC specification >> in order to support more than 16 CPUs at affinity

Re: [PATCH] irqchip/gicv3: Add support for Range Selector (RS) feature

Hi Marc, On 09/16/2017 01:14 PM, Marc Zyngier wrote: > On Fri, Sep 15 2017 at 10:08:56 am BST, Shanker Donthineni > wrote: > > Hi Shanker, > >> A new feature Range Selector (RS) has been added to GIC specification >> in order to support more than 16 CPUs at affinity level 0. New fields >> are

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

On Sat, 16 Sep 2017 15:22:23 -0700 Jonathan Cameron wrote: > On Thu, 14 Sep 2017 16:31:06 +0200 > Michael Hennerich wrote: > > > On 14.09.2017 15:50, Stefan Popa wrote: > > > SPI host drivers can use DMA to transfer data, so the buffer should

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

On Sat, 16 Sep 2017 15:22:23 -0700 Jonathan Cameron wrote: > On Thu, 14 Sep 2017 16:31:06 +0200 > Michael Hennerich wrote: > > > On 14.09.2017 15:50, Stefan Popa wrote: > > > SPI host drivers can use DMA to transfer data, so the buffer should be > > > properly allocated. > > > Keeping it on

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

On Thu, 14 Sep 2017 16:31:06 +0200 Michael Hennerich wrote: > On 14.09.2017 15:50, Stefan Popa wrote: > > SPI host drivers can use DMA to transfer data, so the buffer should be > > properly allocated. > > Keeping it on the stack could cause an undefined behavior. >

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On 09/16/2017 02:29 AM, Josh Poimboeuf wrote: > On Fri, Sep 15, 2017 at 11:01:19AM -0700, Linus Torvalds wrote: >> On Fri, Sep 15, 2017 at 9:53 AM, Andrey Ryabinin >> wrote: >>> >>> I'm not so sure that this is disabled optimization. I assume that global >>> rsp makes

Re: [PATCH] staging: iio: ad7192: Use the dedicated reset function

On Thu, 14 Sep 2017 16:31:06 +0200 Michael Hennerich wrote: > On 14.09.2017 15:50, Stefan Popa wrote: > > SPI host drivers can use DMA to transfer data, so the buffer should be > > properly allocated. > > Keeping it on the stack could cause an undefined behavior. > > > > The dedicated reset

Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent

On 09/16/2017 02:29 AM, Josh Poimboeuf wrote: > On Fri, Sep 15, 2017 at 11:01:19AM -0700, Linus Torvalds wrote: >> On Fri, Sep 15, 2017 at 9:53 AM, Andrey Ryabinin >> wrote: >>> >>> I'm not so sure that this is disabled optimization. I assume that global >>> rsp makes >>> changes something in

Re: [PATCH] iio: cros_ec: Remove unused variable

On Thu, 14 Sep 2017 23:19:22 +0200 Paolo Cretaro wrote: > Fix gcc warning: > cros_ec_baro.c:130:25: warning: variable ‘ec_device’ set but not used > > Signed-off-by: Paolo Cretaro Applied to the togreg branch of iio.git and pushed out as testing

Re: [PATCH] iio: cros_ec: Remove unused variable

On Thu, 14 Sep 2017 23:19:22 +0200 Paolo Cretaro wrote: > Fix gcc warning: > cros_ec_baro.c:130:25: warning: variable ‘ec_device’ set but not used > > Signed-off-by: Paolo Cretaro Applied to the togreg branch of iio.git and pushed out as testing for the autobuilders to play with it. Thanks,

Re: [PATCH v4 6/6] ARM: sun8i: h3: add partial CPU thermal zone

On Sat, 16 Sep 2017 12:05:49 +0200 Quentin Schulz wrote: > Hi Icenowy, > > On 14/09/2017 16:52, Icenowy Zheng wrote: > > Because of the restriction of the OF thermal framework, the thermal > > sensor will fail to probe if the thermal zone doesn't exist. > >

Re: [PATCH v4 6/6] ARM: sun8i: h3: add partial CPU thermal zone

On Sat, 16 Sep 2017 12:05:49 +0200 Quentin Schulz wrote: > Hi Icenowy, > > On 14/09/2017 16:52, Icenowy Zheng wrote: > > Because of the restriction of the OF thermal framework, the thermal > > sensor will fail to probe if the thermal zone doesn't exist. > > > > Oh no, that's not good. > >

Re: [PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

On Sat, 16 Sep 2017 11:45:47 +0200 Quentin Schulz wrote: > Hi Icenowy, > > On 14/09/2017 16:52, Icenowy Zheng wrote: > > This adds support for the Allwinner H3 thermal sensor. > > > > Allwinner H3 has a thermal sensor like the one in A33, but have its > >

Re: [PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

On Sat, 16 Sep 2017 11:45:47 +0200 Quentin Schulz wrote: > Hi Icenowy, > > On 14/09/2017 16:52, Icenowy Zheng wrote: > > This adds support for the Allwinner H3 thermal sensor. > > > > Allwinner H3 has a thermal sensor like the one in A33, but have its > > registers nearly all re-arranged,

Re: [PATCH v4 1/6] dt-bindings: update the Allwinner GPADC device tree binding for H3

On Thu, 14 Sep 2017 22:52:46 +0800 Icenowy Zheng wrote: > Allwinner H3 features a thermal sensor like the one in A33, but has its > register re-arranged, the clock divider moved to CCU (originally the > clock divider is in ADC) and added a pair of bus clock and reset. > >

Re: [PATCH v4 1/6] dt-bindings: update the Allwinner GPADC device tree binding for H3

On Thu, 14 Sep 2017 22:52:46 +0800 Icenowy Zheng wrote: > Allwinner H3 features a thermal sensor like the one in A33, but has its > register re-arranged, the clock divider moved to CCU (originally the > clock divider is in ADC) and added a pair of bus clock and reset. > > Update the binding

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

On Sat, Sep 16, 2017 at 2:47 PM, Thomas Gleixner wrote: > > Yes and no. We get more code which uses cpumasks to store state, just like > I did, and while a lot of the cpumask functions just work as expected a > subset including for_each_cpu does not. That's confusing at best

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

On Sat, Sep 16, 2017 at 2:47 PM, Thomas Gleixner wrote: > > Yes and no. We get more code which uses cpumasks to store state, just like > I did, and while a lot of the cpumask functions just work as expected a > subset including for_each_cpu does not. That's confusing at best and I > rather avoid

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

On Sat, 16 Sep 2017, Linus Torvalds wrote: > On Sat, Sep 16, 2017 at 11:12 AM, Thomas Gleixner wrote: > >> > >> So I suspect your perf fix is the right one, and maybe we could/should > >> just make people more aware of the empty cpumask issue with UP. > > > > Right, I just got

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

On Sat, 16 Sep 2017, Linus Torvalds wrote: > On Sat, Sep 16, 2017 at 11:12 AM, Thomas Gleixner wrote: > >> > >> So I suspect your perf fix is the right one, and maybe we could/should > >> just make people more aware of the empty cpumask issue with UP. > > > > Right, I just got a bit frightened as

  1   2   3   4   5   >