[PATCH v5 7/9] test_sysctl: Add ctl_table registration failure test

Incorrect sysctl tables are constructed and fed to the register_sysctl_table() function in the test_sysctl kernel module. The function is supposed to fail the registration of those tables or an error will be printed if no failure is returned. The registration failures will cause other warning and

[PATCH v5 8/9] ipc: Allow boot time extension of IPCMNI from 32k to 2M

The maximum number of unique System V IPC identifiers was limited to 32k. That limit should be big enough for most use cases. However, there are some users out there requesting for more. To satisfy the need of those users, a new boot time kernel option "ipcmni_extend" is added to extend the

[PATCH v5 6/9] test_sysctl: Add range clamping test

Add a range clamping test to verify that the input value will be clamped if it exceeds the builtin maximum or minimum value. Below is the expected test run result: Running test: sysctl_test_0006 - run #0 Checking range minimum clamping ... ok Checking range maximum clamping ... ok Checking range

[PATCH v5 6/9] test_sysctl: Add range clamping test

Add a range clamping test to verify that the input value will be clamped if it exceeds the builtin maximum or minimum value. Below is the expected test run result: Running test: sysctl_test_0006 - run #0 Checking range minimum clamping ... ok Checking range maximum clamping ... ok Checking range

Re: [RESEND PATCH v2] sched/fair: Remove check in idle_balance against migration_cost

On 03/16/2018 10:42 AM, Peter Zijlstra wrote: You need to look at: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/ my queue.git is the sporadic push of my quilt tree on top of that. Thanks found it! I will re-test and send v3 as needed.

[PATCH v5 9/9] ipc: Conserve sequence numbers in extended IPCMNI mode

The mixing in of a sequence number into the IPC IDs is probably to avoid ID reuse in userspace as much as possible. With extended IPCMNI mode, the number of usable sequecne numbers is greatly reduced leading to higher chance of ID reuse. To address this issue, we need to conserve the sequence

Re: [RESEND PATCH v2] sched/fair: Remove check in idle_balance against migration_cost

On 03/16/2018 10:42 AM, Peter Zijlstra wrote: You need to look at: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/ my queue.git is the sporadic push of my quilt tree on top of that. Thanks found it! I will re-test and send v3 as needed.

[PATCH v5 9/9] ipc: Conserve sequence numbers in extended IPCMNI mode

The mixing in of a sequence number into the IPC IDs is probably to avoid ID reuse in userspace as much as possible. With extended IPCMNI mode, the number of usable sequecne numbers is greatly reduced leading to higher chance of ID reuse. To address this issue, we need to conserve the sequence

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 05:55:02PM +, Al Viro wrote: > On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: > >t.c: In function ‘test’: > >t.c:6:6: error: argument to variable-length array is too large > > [-Werror=vla-larger-than=] > > int array[(1,100)]; > > > > Gcc

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 05:55:02PM +, Al Viro wrote: > On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: > >t.c: In function ‘test’: > >t.c:6:6: error: argument to variable-length array is too large > > [-Werror=vla-larger-than=] > > int array[(1,100)]; > > > > Gcc

[PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

When minimum/maximum values are specified for a sysctl parameter in the ctl_table structure with proc_dointvec_minmax() handler, update to that parameter will fail with error if the given value is outside of the required range. There are use cases where it may be better to clamp the value of the

[PATCH v5 1/9] sysctl: Add flags to support min/max range clamping

When minimum/maximum values are specified for a sysctl parameter in the ctl_table structure with proc_dointvec_minmax() handler, update to that parameter will fail with error if the given value is outside of the required range. There are use cases where it may be better to clamp the value of the

[PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

Checking code is added to provide the following additional ctl_table.flags checks: 1) No unknown flag is allowed. 2) Minimum of a range cannot be larger than the maximum value. 3) The signed and unsigned flags are mutually exclusive. 4) The proc_handler should be consistent with the signed or

[PATCH v5 2/9] proc/sysctl: Provide additional ctl_table.flags checks

Checking code is added to provide the following additional ctl_table.flags checks: 1) No unknown flag is allowed. 2) Minimum of a range cannot be larger than the maximum value. 3) The signed and unsigned flags are mutually exclusive. 4) The proc_handler should be consistent with the signed or

[PATCH v5 3/9] sysctl: Warn when a clamped sysctl parameter is set out of range

Even with clamped sysctl parameters, it is still not that straight forward to figure out the exact range of those parameters. One may try to write extreme parameter values to see if they get clamped. To make it easier, a warning with the expected range will now be printed into the kernel ring

[PATCH v5 3/9] sysctl: Warn when a clamped sysctl parameter is set out of range

Even with clamped sysctl parameters, it is still not that straight forward to figure out the exact range of those parameters. One may try to write extreme parameter values to see if they get clamped. To make it easier, a warning with the expected range will now be printed into the kernel ring

Re: arc_usr_cmpxchg and preemption

> On Thu, Mar 15, 2018 at 12:03 PM, Alexey Brodkin > wrote: > Here's a brief analysis: > ARM: Looks like they got rid of that stuff in v4.4, see > commit db695c0509d6 ("ARM: remove user cmpxchg syscall"). > > M68K: That's even uglier implementation which is

Re: arc_usr_cmpxchg and preemption

> On Thu, Mar 15, 2018 at 12:03 PM, Alexey Brodkin > wrote: > Here's a brief analysis: > ARM: Looks like they got rid of that stuff in v4.4, see > commit db695c0509d6 ("ARM: remove user cmpxchg syscall"). > > M68K: That's even uglier implementation which is really asking for > a

Re: [ANNOUNCE] Git v2.17.0-rc0

Junio C Hamano writes: > I haven't wordsmithed it fully, but it should say something along > the lines of ... > > Documentation/RelNotes/2.16.0.txt | 10 ++ > 1 file changed, 10 insertions(+) Eh, of course the addition should go to 2.17 release notes ;-) I just

Re: [ANNOUNCE] Git v2.17.0-rc0

Junio C Hamano writes: > I haven't wordsmithed it fully, but it should say something along > the lines of ... > > Documentation/RelNotes/2.16.0.txt | 10 ++ > 1 file changed, 10 insertions(+) Eh, of course the addition should go to 2.17 release notes ;-) I just happened to be

Re: [PATCH v9 08/61] page cache: Use xa_lock

On Tue, Mar 13, 2018 at 06:25:46AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Remove the address_space ->tree_lock and use the xa_lock newly added to > the radix_tree_root. Rename the address_space ->page_tree to ->i_pages, > since we don't really care that

Re: [PATCH v9 08/61] page cache: Use xa_lock

On Tue, Mar 13, 2018 at 06:25:46AM -0700, Matthew Wilcox wrote: > From: Matthew Wilcox > > Remove the address_space ->tree_lock and use the xa_lock newly added to > the radix_tree_root. Rename the address_space ->page_tree to ->i_pages, > since we don't really care that it's a tree. > >

Re: [PATCH 4.4 00/63] 4.4.122-stable review

On Fri, Mar 16, 2018 at 04:22:32PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.122 release. > There are 63 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [PATCH 4.4 00/63] 4.4.122-stable review

On Fri, Mar 16, 2018 at 04:22:32PM +0100, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.4.122 release. > There are 63 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me

Re: [ANNOUNCE] Git v2.17.0-rc0

Ævar Arnfjörð Bjarmason writes: > On Fri, Mar 16 2018, Junio C. Hamano jotted: > >> gitweb: hard-depend on the Digest::MD5 5.8 module > > I've just noticed this now, but while this module is in 5.8 RedHat's > butchered perl doesn't have it in the base system, thus this

Re: [ANNOUNCE] Git v2.17.0-rc0

Ævar Arnfjörð Bjarmason writes: > On Fri, Mar 16 2018, Junio C. Hamano jotted: > >> gitweb: hard-depend on the Digest::MD5 5.8 module > > I've just noticed this now, but while this module is in 5.8 RedHat's > butchered perl doesn't have it in the base system, thus this introduces > the

Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b

On 16.3.2018 16:18, Rob Herring wrote: > On Wed, Mar 14, 2018 at 10:04 AM, Michal Simek wrote: >> On 12.3.2018 11:21, Michal Simek wrote: >>> On 12.3.2018 08:52, Alvaro G. M. wrote: On Fri, Mar 09, 2018 at 01:05:11PM -0600, Rob Herring wrote: > On Fri, Mar 9, 2018 at

Re: Bug: Microblaze stopped booting after 0fa1c579349fdd90173381712ad78aa99c09d38b

On 16.3.2018 16:18, Rob Herring wrote: > On Wed, Mar 14, 2018 at 10:04 AM, Michal Simek wrote: >> On 12.3.2018 11:21, Michal Simek wrote: >>> On 12.3.2018 08:52, Alvaro G. M. wrote: On Fri, Mar 09, 2018 at 01:05:11PM -0600, Rob Herring wrote: > On Fri, Mar 9, 2018 at 6:51 AM, Alvaro G.

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > If a BAR supports 64-bit width or not depends on the hardware, > and should thus not depend on sizeof(dma_addr_t). > > Since this driver is generic, default to always using BAR width > of 32-bits. 64-bit BARs can easily be tested by

Re: [PATCH v4 1/5] PCI: endpoint: BAR width should not depend on sizeof dma_addr_t

On Thu, Mar 08, 2018 at 02:33:26PM +0100, Niklas Cassel wrote: > If a BAR supports 64-bit width or not depends on the hardware, > and should thus not depend on sizeof(dma_addr_t). > > Since this driver is generic, default to always using BAR width > of 32-bits. 64-bit BARs can easily be tested by

Re: arc_usr_cmpxchg and preemption

On Fri, Mar 16, 2018 at 10:54:52AM -0700, Vineet Gupta wrote: > I'd say just bite the bullet, write the patch and we can refine it there ! Just be glad its not futex.c proper ;-) I'll try and have a look later..

Re: arc_usr_cmpxchg and preemption

On Fri, Mar 16, 2018 at 10:54:52AM -0700, Vineet Gupta wrote: > I'd say just bite the bullet, write the patch and we can refine it there ! Just be glad its not futex.c proper ;-) I'll try and have a look later..

Re: [tip:perf/core 1/2] drivers//perf/qcom_l2_pmu.c:598:13: error: invalid storage class for function 'l2_cache_event_start'

On Sat, Mar 17, 2018 at 01:19:54AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core > head: bbb68468641547d56c83012670bcaf77f3dacd64 > commit: 7eb709f29593aced51901cb53565477762800722 [1/2] perf: Fix sibling > iteration ARGH.. the

Re: [tip:perf/core 1/2] drivers//perf/qcom_l2_pmu.c:598:13: error: invalid storage class for function 'l2_cache_event_start'

On Sat, Mar 17, 2018 at 01:19:54AM +0800, kbuild test robot wrote: > tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core > head: bbb68468641547d56c83012670bcaf77f3dacd64 > commit: 7eb709f29593aced51901cb53565477762800722 [1/2] perf: Fix sibling > iteration ARGH.. the

[PATCH 6/7] arm64: allwinner: a64: add simplefb for A64 SoC

The A64 SoC features two display pipelines, one has a LCD output, the other has a HDMI output. Add support for simplefb for these pipelines on A64 SoC. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 26 ++ 1 file

[PATCH 6/7] arm64: allwinner: a64: add simplefb for A64 SoC

The A64 SoC features two display pipelines, one has a LCD output, the other has a HDMI output. Add support for simplefb for these pipelines on A64 SoC. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 26 ++ 1 file changed, 26

[PATCH 5/7] arm64: allwinner: a64: add DE2 CCU related device tree nodes

As we have all necessary parts to enable the DE2 CCU on the Allwinner A64 SoC, add the needed device tree nodes, including the SRAM controller node, SRAM C node, DE2 bus node and DE2 CCU node. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 42

[PATCH 5/7] arm64: allwinner: a64: add DE2 CCU related device tree nodes

As we have all necessary parts to enable the DE2 CCU on the Allwinner A64 SoC, add the needed device tree nodes, including the SRAM controller node, SRAM C node, DE2 bus node and DE2 CCU node. Signed-off-by: Icenowy Zheng --- arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 42

[PATCH 7/7] arm64: allwinner: a64: add HDMI regulator to all DTs' simplefb_hdmi

On usual A64 board design the power of HDMI controller is connected to DLDO1 of the AXP803 PMIC. If this regulator is shut down, the HDMI output will be blank. Therefore the simplefb driver should keep this regulator on. Add the regulator to all currently available A64 boards' simplefb_hdmi

[PATCH 7/7] arm64: allwinner: a64: add HDMI regulator to all DTs' simplefb_hdmi

On usual A64 board design the power of HDMI controller is connected to DLDO1 of the AXP803 PMIC. If this regulator is shut down, the HDMI output will be blank. Therefore the simplefb driver should keep this regulator on. Add the regulator to all currently available A64 boards' simplefb_hdmi

[PATCH 2/7] dt-bindings: add binding for the Allwinner A64 DE2 bus

All the sub-blocks of Allwinner A64 DE2 needs the SRAM C on A64 SoC to be claimed, otherwise the whole DE2 space is inaccessible. Add a device tree binding of the DE2 part as a sub-bus. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/bus/sun50i-de2-bus.txt | 37

[PATCH 4/7] clk: sunxi-ng: add A64 compatible string

As claiming Allwinner A64 SRAM C is a prerequisite for all sub-blocks of the A64 DE2, not only the CCU sub-block, a bus driver is then written for enabling the access to the whole DE2 part by claiming the SRAM. In this situation, the A64 compatible string will be just added with no other

[PATCH 3/7] bus: add bus driver for accessing Allwinner A64 DE2

The "Display Engine 2.0" (usually called DE2) on the Allwinner A64 SoC is different from the ones on other Allwinner SoCs. It requires a SRAM region to be claimed, otherwise all DE2 subblocks won't be accessible. Add a bus driver for the Allwinner A64 DE2 part which claims the SRAM region when

[PATCH 2/7] dt-bindings: add binding for the Allwinner A64 DE2 bus

All the sub-blocks of Allwinner A64 DE2 needs the SRAM C on A64 SoC to be claimed, otherwise the whole DE2 space is inaccessible. Add a device tree binding of the DE2 part as a sub-bus. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/bus/sun50i-de2-bus.txt | 37

[PATCH 4/7] clk: sunxi-ng: add A64 compatible string

As claiming Allwinner A64 SRAM C is a prerequisite for all sub-blocks of the A64 DE2, not only the CCU sub-block, a bus driver is then written for enabling the access to the whole DE2 part by claiming the SRAM. In this situation, the A64 compatible string will be just added with no other

[PATCH 3/7] bus: add bus driver for accessing Allwinner A64 DE2

The "Display Engine 2.0" (usually called DE2) on the Allwinner A64 SoC is different from the ones on other Allwinner SoCs. It requires a SRAM region to be claimed, otherwise all DE2 subblocks won't be accessible. Add a bus driver for the Allwinner A64 DE2 part which claims the SRAM region when

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: >t.c: In function ‘test’: >t.c:6:6: error: argument to variable-length array is too large > [-Werror=vla-larger-than=] > int array[(1,100)]; > > Gcc people are crazy. That's not them, that's C standard regarding ICE.

Re: [PATCH v5 0/2] Remove false-positive VLAs when using max()

On Fri, Mar 16, 2018 at 10:29:16AM -0700, Linus Torvalds wrote: >t.c: In function ‘test’: >t.c:6:6: error: argument to variable-length array is too large > [-Werror=vla-larger-than=] > int array[(1,100)]; > > Gcc people are crazy. That's not them, that's C standard regarding ICE.

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

Quoting Bartosz Golaszewski (2018-02-28 04:38:38) > 2018-02-19 21:21 GMT+01:00 David Lechner : > > I believe there to be two issues: one is with v7 - we need to increase > the clock reference count in davinci_psc_genpd_attach_dev(). > > Second is the error path in the clock

Re: [PATCH v7 10/42] clk: davinci: New driver for davinci PSC clocks

Quoting Bartosz Golaszewski (2018-02-28 04:38:38) > 2018-02-19 21:21 GMT+01:00 David Lechner : > > I believe there to be two issues: one is with v7 - we need to increase > the clock reference count in davinci_psc_genpd_attach_dev(). > > Second is the error path in the clock framework - we should

[PATCH 1/7] dt-bindings: add compatible string for the A64 DE2 CCU

The Allwinner A64 SoC has a DE2 CCU like the one in the DE2 of Allwinner H5 SoC. Add a compatible string for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/clock/sun8i-de2.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 0/7] Allwinner A64 DE2 CCU support with dedicated DE2 bus driver

This patchset tries to implement the Allwinner A64 DE2 as a bus driver, in order to model the fact that the SRAM claim controls the access to the whole DE2 memory space. PATCH 1 and PATCH 4 are for the CCU part. PATCH 2 is the device tree binding for the A64 DE2 bus, and PATCH 3 implements the

[PATCH 1/7] dt-bindings: add compatible string for the A64 DE2 CCU

The Allwinner A64 SoC has a DE2 CCU like the one in the DE2 of Allwinner H5 SoC. Add a compatible string for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/clock/sun8i-de2.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 0/7] Allwinner A64 DE2 CCU support with dedicated DE2 bus driver

This patchset tries to implement the Allwinner A64 DE2 as a bus driver, in order to model the fact that the SRAM claim controls the access to the whole DE2 memory space. PATCH 1 and PATCH 4 are for the CCU part. PATCH 2 is the device tree binding for the A64 DE2 bus, and PATCH 3 implements the

Re: arc_usr_cmpxchg and preemption

On 03/16/2018 10:33 AM, Alexey Brodkin wrote: Hi Peter, Vineet, On Wed, 2018-03-14 at 18:53 +0100, Peter Zijlstra wrote: On Wed, Mar 14, 2018 at 09:58:19AM -0700, Vineet Gupta wrote: Well it is broken wrt the semantics the syscall is supposed to provide. Preemption disabling is what prevents

Re: arc_usr_cmpxchg and preemption

On 03/16/2018 10:33 AM, Alexey Brodkin wrote: Hi Peter, Vineet, On Wed, 2018-03-14 at 18:53 +0100, Peter Zijlstra wrote: On Wed, Mar 14, 2018 at 09:58:19AM -0700, Vineet Gupta wrote: Well it is broken wrt the semantics the syscall is supposed to provide. Preemption disabling is what prevents

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

- On Mar 16, 2018, at 12:48 PM, rostedt rost...@goodmis.org wrote: > On Fri, 16 Mar 2018 12:41:34 -0400 > Steven Rostedt wrote: > >> Yes, kprobes are dangerous. I'm not saying it shouldn't be fixed, I'm >> saying that I don't have time to fix it now, but would be happy

Re: [PATCH 2/2] kprobe: fix: Add ftrace_ops_assist_func to kprobe blacklist

- On Mar 16, 2018, at 12:48 PM, rostedt rost...@goodmis.org wrote: > On Fri, 16 Mar 2018 12:41:34 -0400 > Steven Rostedt wrote: > >> Yes, kprobes are dangerous. I'm not saying it shouldn't be fixed, I'm >> saying that I don't have time to fix it now, but would be happy to >> accept patches

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Hi, On Fri, Mar 16, 2018 at 12:07:53PM +0530, afzal mohammed wrote: > Received only patch 4 & 5 in my inbox, receive path was via > linux-kernel rather than linux-arm-kernel, but in both archives all > patches are seen (though threading seems not right), probably missing > patches are due to

Re: [PATCHv2 5/5] arm64: allwinner: a64: Add support for TERES-I laptop

Hi, On Fri, Mar 16, 2018 at 12:07:53PM +0530, afzal mohammed wrote: > Received only patch 4 & 5 in my inbox, receive path was via > linux-kernel rather than linux-arm-kernel, but in both archives all > patches are seen (though threading seems not right), probably missing > patches are due to

Re: [PATCH 6/8] trace_uprobe/sdt: Fix multiple update of same reference counter

On 03/16, Ravi Bangoria wrote: > > On 03/15/2018 08:19 PM, Oleg Nesterov wrote: > > On 03/13, Ravi Bangoria wrote: > >> For tiny binaries/libraries, different mmap regions points to the > >> same file portion. In such cases, we may increment reference counter > >> multiple times. > > Yes, > > > >>

Re: [PATCH 6/8] trace_uprobe/sdt: Fix multiple update of same reference counter

On 03/16, Ravi Bangoria wrote: > > On 03/15/2018 08:19 PM, Oleg Nesterov wrote: > > On 03/13, Ravi Bangoria wrote: > >> For tiny binaries/libraries, different mmap regions points to the > >> same file portion. In such cases, we may increment reference counter > >> multiple times. > > Yes, > > > >>

[PATCH] tpm: TPM 2.0 selftest performance improvement

For selftest being run in the background, the TCG 2.0 Specification provides the command TPM2_GetTestResult to check the status of selftest completion. When the partial selftest command is sent just after TPM initialization, it is observed that it returns RC_COMMAND_CODE error, which as per TPM

[PATCH] tpm: TPM 2.0 selftest performance improvement

For selftest being run in the background, the TCG 2.0 Specification provides the command TPM2_GetTestResult to check the status of selftest completion. When the partial selftest command is sent just after TPM initialization, it is observed that it returns RC_COMMAND_CODE error, which as per TPM

Re: [PATCH] staging: typec: rt1711h typec chip driver

Hi Heikki, 2018-03-16 23:05 GMT+08:00 Heikki Krogerus : > Hi ShuFan, > > On Fri, Mar 16, 2018 at 05:12:49PM +0800, ShuFan Lee wrote: >> +static int rt1711h_init_gpio(struct rt1711h_chip *chip) >> +{ >> + int ret; >> + struct device_node *np =

Re: [PATCH] staging: typec: rt1711h typec chip driver

Hi Heikki, 2018-03-16 23:05 GMT+08:00 Heikki Krogerus : > Hi ShuFan, > > On Fri, Mar 16, 2018 at 05:12:49PM +0800, ShuFan Lee wrote: >> +static int rt1711h_init_gpio(struct rt1711h_chip *chip) >> +{ >> + int ret; >> + struct device_node *np = chip->dev->of_node; >> + >> + ret =

Re: [PATCH 8/9] x86/dumpstack: Save first regs set for the executive summary

On Fri, Mar 16, 2018 at 10:22:29AM -0700, Linus Torvalds wrote: > The reason we do that > > printk(KERN_DEFAULT "CR2: %016lx\n", address); > > is because WE ARE NOT PRINTING OUT THE CURRENT CR2 REGISTER! Whoopsie! Doh, __show_regs() reads CR2 again and there's a big fat window

Re: [PATCH 8/9] x86/dumpstack: Save first regs set for the executive summary

On Fri, Mar 16, 2018 at 10:22:29AM -0700, Linus Torvalds wrote: > The reason we do that > > printk(KERN_DEFAULT "CR2: %016lx\n", address); > > is because WE ARE NOT PRINTING OUT THE CURRENT CR2 REGISTER! Whoopsie! Doh, __show_regs() reads CR2 again and there's a big fat window

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

From: Linus Torvalds > Sent: 16 March 2018 17:29 > On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer wrote: > > > > If you want to catch stack frames which have unbounded size, > > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant > > adjusted as

RE: [PATCH v5 0/2] Remove false-positive VLAs when using max()

From: Linus Torvalds > Sent: 16 March 2018 17:29 > On Fri, Mar 16, 2018 at 4:47 AM, Florian Weimer wrote: > > > > If you want to catch stack frames which have unbounded size, > > -Werror=stack-usage=1000 or -Werror=vla-larger-than=1000 (with the constant > > adjusted as needed) might be the

Re: [RESEND PATCH v2] sched/fair: Remove check in idle_balance against migration_cost

On Fri, Mar 16, 2018 at 10:21:54AM -0700, Rohit Jain wrote: > Hi Peter, > > On 03/16/2018 07:35 AM, Peter Zijlstra wrote: > > On Wed, Mar 14, 2018 at 11:36:47AM -0700, Rohit Jain wrote: > > > Signed-off-by: Rohit Jain > > > > > > Signed-off-by: Rohit Jain

Re: [RESEND PATCH v2] sched/fair: Remove check in idle_balance against migration_cost

On Fri, Mar 16, 2018 at 10:21:54AM -0700, Rohit Jain wrote: > Hi Peter, > > On 03/16/2018 07:35 AM, Peter Zijlstra wrote: > > On Wed, Mar 14, 2018 at 11:36:47AM -0700, Rohit Jain wrote: > > > Signed-off-by: Rohit Jain > > > > > > Signed-off-by: Rohit Jain > > Surely you only need a single on

RE: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

> From: Lorenzo Pieralisi > Sent: Friday, March 16, 2018 03:54 > ... > Dexuan, > while applying/updating these patches I notice this one may be squashed > into: https://patchwork.ozlabs.org/patch/886266/ > > since they logically belong in the same patch. Are you OK

RE: [PATCH v4 3/4] PCI: hv: Remove hbus->enum_sem

> From: Lorenzo Pieralisi > Sent: Friday, March 16, 2018 03:54 > ... > Dexuan, > while applying/updating these patches I notice this one may be squashed > into: https://patchwork.ozlabs.org/patch/886266/ > > since they logically belong in the same patch. Are you OK with me doing > that ? Is my

[PATCH v2] staging: typec: rt1711h typec chip driver

From: ShuFan Lee Richtek RT1711H Type-C chip driver that works with Type-C Port Controller Manager to provide USB PD and USB Type-C functionalities. Add definition of TCPC_CC_STATUS_TOGGLING. Signed-off-by: ShuFan Lee ---

[PATCH v2] staging: typec: rt1711h typec chip driver

From: ShuFan Lee Richtek RT1711H Type-C chip driver that works with Type-C Port Controller Manager to provide USB PD and USB Type-C functionalities. Add definition of TCPC_CC_STATUS_TOGGLING. Signed-off-by: ShuFan Lee --- drivers/staging/typec/Kconfig | 8 +

Re: [PATCH 8/9] x86/dumpstack: Save first regs set for the executive summary

On Fri, Mar 16, 2018 at 10:22:29AM -0700, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 4:48 AM, Borislav Petkov wrote: > > On Thu, Mar 15, 2018 at 02:01:32PM -0500, Josh Poimboeuf wrote: > >> no_context() has the following line, right before it calls oops_end(): > >> > >>

Re: [PATCH 8/9] x86/dumpstack: Save first regs set for the executive summary

On Fri, Mar 16, 2018 at 10:22:29AM -0700, Linus Torvalds wrote: > On Fri, Mar 16, 2018 at 4:48 AM, Borislav Petkov wrote: > > On Thu, Mar 15, 2018 at 02:01:32PM -0500, Josh Poimboeuf wrote: > >> no_context() has the following line, right before it calls oops_end(): > >> > >> /* Executive

[PATCH 3.18 03/25] Input: matrix_keypad - fix race when disabling interrupts

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Zhang Bo commit ea4f7bd2aca9f68470e9aac0fc9432fd180b1fe7 upstream. If matrix_keypad_stop() is executing and the keypad interrupt is triggered, disable_row_irqs() may be called

[PATCH 3.18 03/25] Input: matrix_keypad - fix race when disabling interrupts

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Zhang Bo commit ea4f7bd2aca9f68470e9aac0fc9432fd180b1fe7 upstream. If matrix_keypad_stop() is executing and the keypad interrupt is triggered, disable_row_irqs() may be called by both

[PATCH 3.18 04/25] x86/MCE: Serialize sysfs changes

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Seunghun Han commit b3b7c4795ccab5be71f080774c45bbbcc75c2aaf upstream. The check_interval file in /sys/devices/system/machinecheck/machinecheck directory is a global

[PATCH 3.18 04/25] x86/MCE: Serialize sysfs changes

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Seunghun Han commit b3b7c4795ccab5be71f080774c45bbbcc75c2aaf upstream. The check_interval file in /sys/devices/system/machinecheck/machinecheck directory is a global timer value for MCE

[PATCH 3.18 25/25] fixup: sctp: verify size of a new chunk in _sctp_make_chunk()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Greg Kroah-Hartman Ben writes: > > + int chunklen; > > + > > + chunklen = sizeof(*chunk_hdr) + paylen; > > I think this length still needs to be rounded up

[PATCH 3.18 25/25] fixup: sctp: verify size of a new chunk in _sctp_make_chunk()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Greg Kroah-Hartman Ben writes: > > + int chunklen; > > + > > + chunklen = sizeof(*chunk_hdr) + paylen; > > I think this length still needs to be rounded up (with WORD_ROUND here, >

[PATCH 3.18 12/25] netfilter: ipv6: fix use-after-free Write in nf_nat_ipv6_manip_pkt

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit b078556aecd791b0e5cb3a59f4c3a14273b52121 upstream. l4proto->manip_pkt() can cause reallocation of skb head so pointer to the ipv6 header must be

[PATCH 3.18 11/25] netfilter: bridge: ebt_among: add missing match size checks

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit c4585a2823edf4d1326da44d1524ecbfda26bb37 upstream. ebt_among is special, it has a dynamic match size and is exempt from the central size checks.

[PATCH 3.18 12/25] netfilter: ipv6: fix use-after-free Write in nf_nat_ipv6_manip_pkt

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit b078556aecd791b0e5cb3a59f4c3a14273b52121 upstream. l4proto->manip_pkt() can cause reallocation of skb head so pointer to the ipv6 header must be reloaded.

[PATCH 3.18 11/25] netfilter: bridge: ebt_among: add missing match size checks

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Florian Westphal commit c4585a2823edf4d1326da44d1524ecbfda26bb37 upstream. ebt_among is special, it has a dynamic match size and is exempt from the central size checks. Therefore it must

[PATCH 3.18 13/25] ubi: Fix race condition between ubi volume creation and udev

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Clay McClure commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream. Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi device creation and udev"), we

[PATCH 3.18 13/25] ubi: Fix race condition between ubi volume creation and udev

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Clay McClure commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 upstream. Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi device creation and udev"), we should make the

[PATCH 3.18 14/25] scripts: recordmcount: break hardlinks

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Russell King commit dd39a26538e37f6c6131e829a4a510787e43c783 upstream. recordmcount edits the file in-place, which can cause problems when using ccache in

[PATCH 3.18 14/25] scripts: recordmcount: break hardlinks

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Russell King commit dd39a26538e37f6c6131e829a4a510787e43c783 upstream. recordmcount edits the file in-place, which can cause problems when using ccache in hardlink mode. Arrange for

[PATCH 3.18 15/25] x86/module: Detect and skip invalid relocations

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Josh Poimboeuf commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream. There have been some cases where external tooling (e.g., kpatch-build) creates a corrupt

[PATCH 3.18 15/25] x86/module: Detect and skip invalid relocations

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Josh Poimboeuf commit eda9cec4c9a12208a6f69fbe68f72a6311d50032 upstream. There have been some cases where external tooling (e.g., kpatch-build) creates a corrupt relocation which targets the

[PATCH 3.18 17/25] serial: sh-sci: prevent lockup on full TTY buffers

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Ulrich Hecht commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream. When the TTY buffers fill up to the configured maximum, a system lockup occurs: [

[PATCH 3.18 17/25] serial: sh-sci: prevent lockup on full TTY buffers

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Ulrich Hecht commit 7842055bfce4bf0170d0f61df8b2add8399697be upstream. When the TTY buffers fill up to the configured maximum, a system lockup occurs: [ 598.820128] INFO: rcu_preempt

[PATCH 4.4 01/63] RDMA/ucma: Limit possible option size

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Leon Romanovsky commit 6a21dfc0d0db7b7e0acedce67ca533a6eb19283c upstream. Users of ucma are supposed to provide size of option level, in most paths it is supposed to be

[PATCH 4.4 01/63] RDMA/ucma: Limit possible option size

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Leon Romanovsky commit 6a21dfc0d0db7b7e0acedce67ca533a6eb19283c upstream. Users of ucma are supposed to provide size of option level, in most paths it is supposed to be equal to u8 or u16, but

[PATCH 4.4 04/63] scsi: qla2xxx: Fix NULL pointer crash due to active timer for ABTS

4.4-stable review patch. If anyone has any objections, please let me know. -- From: himanshu.madh...@cavium.com commit 1514839b366417934e2f1328edb50ed1e8a719f5 upstream. This patch fixes NULL pointer crash due to active timer running for abort

[PATCH 4.4 04/63] scsi: qla2xxx: Fix NULL pointer crash due to active timer for ABTS

4.4-stable review patch. If anyone has any objections, please let me know. -- From: himanshu.madh...@cavium.com commit 1514839b366417934e2f1328edb50ed1e8a719f5 upstream. This patch fixes NULL pointer crash due to active timer running for abort IOCB. >From crash dump analysis

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