[PATCH 4.4 08/16] perf/x86: Fix full width counter, counter overflow

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra (Intel) commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream. Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM. Both

[PATCH 4.4 15/16] hotplug: Make register and unregister notifier API symmetric

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Michal Hocko commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream. Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its notifiers when HOTPLUG_CPU=y

[PATCH 4.8 04/33] fuse: fix clearing suid, sgid for chown()

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Miklos Szeredi commit c01638f5d919728f565bf8b5e0a6a159642df0d9 upstream. Basically, the pjdfstests set the ownership of a file to 06555, and then chowns it (as root) to a

[PATCH 4.4 09/16] crypto: mcryptd - Check mcryptd algorithm compatibility

4.4-stable review patch. If anyone has any objections, please let me know. -- From: tim commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream. Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm

[PATCH 4.8 23/33] crypto: marvell - Dont corrupt state of an STD req for re-stepped ahash

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Romain Perier commit 9e5f7a149e00d211177f6de8be427ebc72a1c363 upstream. mv_cesa_hash_std_step() copies the creq->state into the SRAM at each step, but this is only required on the first one.

[PATCH 4.8 22/33] crypto: mcryptd - Check mcryptd algorithm compatibility

4.8-stable review patch. If anyone has any objections, please let me know. -- From: tim commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream. Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm invocation using a

[PATCH 4.4 08/16] perf/x86: Fix full width counter, counter overflow

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Peter Zijlstra (Intel) commit 7f612a7f0bc13a2361a152862435b7941156b6af upstream. Lukasz reported that perf stat counters overflow handling is broken on KNL/SLM. Both these parts have

[PATCH 4.4 15/16] hotplug: Make register and unregister notifier API symmetric

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Michal Hocko commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream. Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its notifiers when HOTPLUG_CPU=y while the

[PATCH 4.8 04/33] fuse: fix clearing suid, sgid for chown()

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Miklos Szeredi commit c01638f5d919728f565bf8b5e0a6a159642df0d9 upstream. Basically, the pjdfstests set the ownership of a file to 06555, and then chowns it (as root) to a new uid/gid. Prior to

[PATCH 4.4 09/16] crypto: mcryptd - Check mcryptd algorithm compatibility

4.4-stable review patch. If anyone has any objections, please let me know. -- From: tim commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream. Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm invocation using a

[PATCH 4.8 33/33] crypto: rsa - Add Makefile dependencies to fix parallel builds

4.8-stable review patch. If anyone has any objections, please let me know. -- From: David Michael commit 57891633eeef60e732e045731cf20e50ee80acb4 upstream. Both asn1 headers are included by rsa_helper.c, so rsa_helper.o should explicitly depend on

[PATCH 4.8 33/33] crypto: rsa - Add Makefile dependencies to fix parallel builds

4.8-stable review patch. If anyone has any objections, please let me know. -- From: David Michael commit 57891633eeef60e732e045731cf20e50ee80acb4 upstream. Both asn1 headers are included by rsa_helper.c, so rsa_helper.o should explicitly depend on them. Signed-off-by: David

Re: [PATCH v4 4/4] regulator: Prevent falling too fast

On Mon, Dec 12, 2016 at 01:15:02PM -0800, Matthias Kaehlcke wrote: > El Fri, Oct 28, 2016 at 07:15:21PM +0100 Mark Brown ha dit: > > On Mon, Sep 26, 2016 at 10:41:59AM -0700, Doug Anderson wrote: > > What you're describing to me is a discrete DCDC that has an input > > voltage that sets the

Re: [PATCH v4 4/4] regulator: Prevent falling too fast

On Mon, Dec 12, 2016 at 01:15:02PM -0800, Matthias Kaehlcke wrote: > El Fri, Oct 28, 2016 at 07:15:21PM +0100 Mark Brown ha dit: > > On Mon, Sep 26, 2016 at 10:41:59AM -0700, Doug Anderson wrote: > > What you're describing to me is a discrete DCDC that has an input > > voltage that sets the

[PATCH 4.8 26/33] Revert "ACPI: Execute _PTS before system reboot"

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Rafael J. Wysocki commit 9713adc2a1a5488f4889c657a0c0ce0c16056d3c upstream. Revert commit 2c85025c75df (ACPI: Execute _PTS before system reboot) as it is reported

[PATCH 4.8 19/33] acpi, nfit: fix bus vs dimm confusion in xlat_status

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit d6eb270c57fef35798525004ddf2ac5dcdadd43b upstream. Given dimms and bus commands share the same command number space we need to be careful that we

[PATCH 4.8 26/33] Revert "ACPI: Execute _PTS before system reboot"

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Rafael J. Wysocki commit 9713adc2a1a5488f4889c657a0c0ce0c16056d3c upstream. Revert commit 2c85025c75df (ACPI: Execute _PTS before system reboot) as it is reported to cause poweroff and reboot

[PATCH 4.8 19/33] acpi, nfit: fix bus vs dimm confusion in xlat_status

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit d6eb270c57fef35798525004ddf2ac5dcdadd43b upstream. Given dimms and bus commands share the same command number space we need to be careful that we are translating status in

[PATCH 4.8 24/33] can: raw: raw_setsockopt: limit number of can_filter that can be set

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Marc Kleine-Budde commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream. This patch adds a check to limit the number of can_filters that can be set via setsockopt on

[PATCH 4.8 05/33] parisc: Purge TLB before setting PTE

4.8-stable review patch. If anyone has any objections, please let me know. -- From: John David Anglin commit c78e710c1c9fbeff43dddc0aa3d0ff458e70b0cc upstream. The attached change interchanges the order of purging the TLB and setting the corresponding

Re: [PATCH v2 5/5] staging: lustre: headers: use proper byteorder functions in lustre_idl.h

On Tue, Dec 13, 2016 at 11:14:26AM -0500, Oleg Drokin wrote: > > On Dec 13, 2016, at 3:31 AM, Dan Carpenter wrote: > > > It used to be that great swathes of Lustre were used in both user space > > and kernel space. We had huge unused modules in the kernel that were > > only used for user space.

[PATCH 4.8 11/33] device-dax: fix private mapping restriction, permit read-only

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit 325896ffdf90f7cbd59fb873b7ba20d60d1ddf3c upstream. Hugh notes in response to commit 4cb19355ea19 "device-dax: fail all private mapping attempts":

[PATCH 4.8 07/33] parisc: Fix TLB related boot crash on SMP machines

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Helge Deller commit 24d0492b7d5d321a9c5846c8c974eba9823ffaa0 upstream. At bootup we run measurements to calculate the best threshold for when we should be using full TLB flushes

[PATCH 4.8 08/33] zram: restrict add/remove attributes to root only

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Sergey Senozhatsky commit 5c7e9ccd91b90d87029261f8856294ee51934cab upstream. zram hot_add sysfs attribute is a very 'special' attribute - reading from it creates

[PATCH 4.8 10/33] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner()

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream. While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in

[PATCH 4.8 06/33] parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm

4.8-stable review patch. If anyone has any objections, please let me know. -- From: John David Anglin commit febe42964fe182281859b3d43d844bb25ca49367 upstream. We have four routines in pacache.S that use temporary alias pages: copy_user_page_asm(),

[PATCH 4.8 24/33] can: raw: raw_setsockopt: limit number of can_filter that can be set

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Marc Kleine-Budde commit 332b05ca7a438f857c61a3c21a88489a21532364 upstream. This patch adds a check to limit the number of can_filters that can be set via setsockopt on CAN_RAW sockets.

[PATCH 4.8 05/33] parisc: Purge TLB before setting PTE

4.8-stable review patch. If anyone has any objections, please let me know. -- From: John David Anglin commit c78e710c1c9fbeff43dddc0aa3d0ff458e70b0cc upstream. The attached change interchanges the order of purging the TLB and setting the corresponding page table entry. TLB

Re: [PATCH v2 5/5] staging: lustre: headers: use proper byteorder functions in lustre_idl.h

On Tue, Dec 13, 2016 at 11:14:26AM -0500, Oleg Drokin wrote: > > On Dec 13, 2016, at 3:31 AM, Dan Carpenter wrote: > > > It used to be that great swathes of Lustre were used in both user space > > and kernel space. We had huge unused modules in the kernel that were > > only used for user space.

[PATCH 4.8 11/33] device-dax: fix private mapping restriction, permit read-only

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit 325896ffdf90f7cbd59fb873b7ba20d60d1ddf3c upstream. Hugh notes in response to commit 4cb19355ea19 "device-dax: fail all private mapping attempts": "I think that is more

[PATCH 4.8 07/33] parisc: Fix TLB related boot crash on SMP machines

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Helge Deller commit 24d0492b7d5d321a9c5846c8c974eba9823ffaa0 upstream. At bootup we run measurements to calculate the best threshold for when we should be using full TLB flushes instead of

[PATCH 4.8 08/33] zram: restrict add/remove attributes to root only

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Sergey Senozhatsky commit 5c7e9ccd91b90d87029261f8856294ee51934cab upstream. zram hot_add sysfs attribute is a very 'special' attribute - reading from it creates a new uninitialized zram

[PATCH 4.8 10/33] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner()

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream. While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in rt_mutex_owner() as it might

[PATCH 4.8 06/33] parisc: Remove unnecessary TLB purges from flush_dcache_page_asm and flush_icache_page_asm

4.8-stable review patch. If anyone has any objections, please let me know. -- From: John David Anglin commit febe42964fe182281859b3d43d844bb25ca49367 upstream. We have four routines in pacache.S that use temporary alias pages: copy_user_page_asm(), clear_user_page_asm(),

Re: WARNING: kernel stack frame pointer at ffffffff82e03f40 in swapper:0 has bad value (null)

On Tue, Dec 13, 2016 at 08:55:53AM -0800, Andy Lutomirski wrote: > I want to file a GCC bug, though. This code sucks. Looks like it started doing that with gcc-5. gcc-4.9 output looks fine here: .globl x86_64_start_kernel .type x86_64_start_kernel, @function

[PATCH 4.8 18/33] acpi, nfit: validate ars_status output buffer size

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit 82aa37cf09867c5e2c0326649d570e5b25c1189a upstream. If an ARS Status command returns truncated output, do not process partial records or otherwise

[PATCH 4.8 09/33] locking/rtmutex: Prevent dequeue vs. unlock race

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream. David reported a futex/rtmutex state corruption. It's caused by the following problem: CPU0

Re: WARNING: kernel stack frame pointer at ffffffff82e03f40 in swapper:0 has bad value (null)

On Tue, Dec 13, 2016 at 08:55:53AM -0800, Andy Lutomirski wrote: > I want to file a GCC bug, though. This code sucks. Looks like it started doing that with gcc-5. gcc-4.9 output looks fine here: .globl x86_64_start_kernel .type x86_64_start_kernel, @function

[PATCH 4.8 18/33] acpi, nfit: validate ars_status output buffer size

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit 82aa37cf09867c5e2c0326649d570e5b25c1189a upstream. If an ARS Status command returns truncated output, do not process partial records or otherwise consume non-status fields.

[PATCH 4.8 09/33] locking/rtmutex: Prevent dequeue vs. unlock race

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream. David reported a futex/rtmutex state corruption. It's caused by the following problem: CPU0CPU1

fs/namespace: inconsistent lock state

4.9.0-next-20161213-6-g733bb9f77ddb #244 Not tainted - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/4/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (mnt_id_lock){+.?...}, at: [] mnt_free_id.isra.7+0x2c/0x70 {SOFTIRQ-ON-W} state was registered at: mark_loc

fs/namespace: inconsistent lock state

4.9.0-next-20161213-6-g733bb9f77ddb #244 Not tainted - inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. swapper/4/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (mnt_id_lock){+.?...}, at: [] mnt_free_id.isra.7+0x2c/0x70 {SOFTIRQ-ON-W} state was registered at: mark_loc

[PATCH 4.8 32/33] hotplug: Make register and unregister notifier API symmetric

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Michal Hocko commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream. Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its notifiers when HOTPLUG_CPU=y

[PATCH 4.8 02/33] powerpc/mm: Fix lazy icache flush on pre-POWER5

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Benjamin Herrenschmidt commit dd7b2f035ec41a409f7a7cec7aabc0ec0eacf476 upstream. On 64-bit CPUs with no-execute support and non-snooping icache, such as 970 or

[PATCH 4.8 32/33] hotplug: Make register and unregister notifier API symmetric

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Michal Hocko commit 777c6e0daebb3fcefbbd6f620410a946b07ef6d0 upstream. Yu Zhao has noticed that __unregister_cpu_notifier only unregisters its notifiers when HOTPLUG_CPU=y while the

[PATCH 4.8 02/33] powerpc/mm: Fix lazy icache flush on pre-POWER5

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Benjamin Herrenschmidt commit dd7b2f035ec41a409f7a7cec7aabc0ec0eacf476 upstream. On 64-bit CPUs with no-execute support and non-snooping icache, such as 970 or POWER4, we have a software

[PATCH 4.8 29/33] ceph: dont set req->r_locked_dir in ceph_d_revalidate

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Jeff Layton commit c3f4688a08fd86f1bf8e055724c84b7a40a09733 upstream. This function sets req->r_locked_dir which is supposed to indicate to ceph_fill_trace that the

[PATCH 4.8 31/33] batman-adv: Check for alloc errors when preparing TT local data

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Sven Eckelmann commit c2d0f48a13e53b4747704c9e692f5e765e52041a upstream. batadv_tt_prepare_tvlv_local_data can fail to allocate the memory for the new TVLV block. The

Re: [PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

On 12/13/2016 8:49 AM, John Stultz wrote: > On Tue, Dec 13, 2016 at 8:39 AM, Casey Schaufler > wrote: >> On 12/13/2016 1:47 AM, Michael Kerrisk (man-pages) wrote: >>> Hi John, >>> >>> On 13 December 2016 at 02:39, John Stultz wrote: This

[PATCH 4.8 30/33] m68k: Fix ndelay() macro

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Boris Brezillon commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream. The current ndelay() macro definition has an extra semi-colon at the end of the

[PATCH 4.8 29/33] ceph: dont set req->r_locked_dir in ceph_d_revalidate

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Jeff Layton commit c3f4688a08fd86f1bf8e055724c84b7a40a09733 upstream. This function sets req->r_locked_dir which is supposed to indicate to ceph_fill_trace that the parent's i_rwsem is locked

[PATCH 4.8 31/33] batman-adv: Check for alloc errors when preparing TT local data

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Sven Eckelmann commit c2d0f48a13e53b4747704c9e692f5e765e52041a upstream. batadv_tt_prepare_tvlv_local_data can fail to allocate the memory for the new TVLV block. The caller is informed about

Re: [PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

On 12/13/2016 8:49 AM, John Stultz wrote: > On Tue, Dec 13, 2016 at 8:39 AM, Casey Schaufler > wrote: >> On 12/13/2016 1:47 AM, Michael Kerrisk (man-pages) wrote: >>> Hi John, >>> >>> On 13 December 2016 at 02:39, John Stultz wrote: This patch adds CAP_GROUP_MIGRATE and logic to allows a

[PATCH 4.8 30/33] m68k: Fix ndelay() macro

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Boris Brezillon commit 7e251bb21ae08ca2e4fb28cc0981fac2685a8efa upstream. The current ndelay() macro definition has an extra semi-colon at the end of the line thus leading to a compilation

Re: [PATCH] rcu: shift by 1UL rather than 1 to fix sign extension error

Hi, On Tue, Dec 13, 2016 at 10:56:46AM +, Colin King wrote: > From: Colin Ian King > > mask and bit are unsigned longs, so if bit is 31 we end up sign > extending the 1 and mask ends up as 0x8000. Fix this > by explicitly adding integer suffix UL ensure

[PATCH 4.8 28/33] ARM: dts: imx7d: fix LCDIF clock assignment

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Stefan Agner commit 4b707fa00a80b19b80bc8df6f1cbf4bdd9c91402 upstream. The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them separately: Clock Clock Root

[PATCH 4.8 27/33] ARM: dts: orion5x: fix number of sata port for linkstation ls-gl

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Roger Shimizu commit 038ccb3e8cee52e07dc118ff99f47eaebc1d0746 upstream. Bug report from Debian [0] shows there's minor changed model of Linkstation LS-GL that uses the

Re: [PATCH] rcu: shift by 1UL rather than 1 to fix sign extension error

Hi, On Tue, Dec 13, 2016 at 10:56:46AM +, Colin King wrote: > From: Colin Ian King > > mask and bit are unsigned longs, so if bit is 31 we end up sign > extending the 1 and mask ends up as 0x8000. Fix this > by explicitly adding integer suffix UL ensure 1 is a unsigned long >

[PATCH 4.8 28/33] ARM: dts: imx7d: fix LCDIF clock assignment

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Stefan Agner commit 4b707fa00a80b19b80bc8df6f1cbf4bdd9c91402 upstream. The eLCDIF IP of the i.MX 7 SoC knows multiple clocks and lists them separately: Clock Clock Root

[PATCH 4.8 27/33] ARM: dts: orion5x: fix number of sata port for linkstation ls-gl

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Roger Shimizu commit 038ccb3e8cee52e07dc118ff99f47eaebc1d0746 upstream. Bug report from Debian [0] shows there's minor changed model of Linkstation LS-GL that uses the 2nd SATA port of the

[PATCH 4.8 17/33] acpi, nfit, libnvdimm: fix / harden ars_status output length handling

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit efda1b5d87cbc3d8816f94a3815b413f1868e10d upstream. Given ambiguities in the ACPI 6.1 definition of the "Output (Size)" field of the ARS (Address

[PATCH 4.8 20/33] crypto: marvell - Dont copy hash operation twice into the SRAM

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Romain Perier commit 68c7f8c1c4e9b06e6b153fa3e9e0cda2ef5aaed8 upstream. No need to copy the template of an hash operation twice into the SRAM from the step

[PATCH 4.8 20/33] crypto: marvell - Dont copy hash operation twice into the SRAM

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Romain Perier commit 68c7f8c1c4e9b06e6b153fa3e9e0cda2ef5aaed8 upstream. No need to copy the template of an hash operation twice into the SRAM from the step function. Fixes: commit

[PATCH 4.8 17/33] acpi, nfit, libnvdimm: fix / harden ars_status output length handling

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams commit efda1b5d87cbc3d8816f94a3815b413f1868e10d upstream. Given ambiguities in the ACPI 6.1 definition of the "Output (Size)" field of the ARS (Address Range Scrub) Status

[PATCH 4.8 01/33] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Andrew Donnellan commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream. In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after after we

[PATCH 4.8 01/33] powerpc/eeh: Fix deadlock when PE frozen state cant be cleared

4.8-stable review patch. If anyone has any objections, please let me know. -- From: Andrew Donnellan commit 409bf7f8a02ef88db5a0f2cdcf9489914f4b8508 upstream. In eeh_reset_device(), we take the pci_rescan_remove_lock immediately after after we call eeh_reset_pe() to reset the

[PATCH 4.8 00/33] 4.8.15-stable review

This is the start of the stable review cycle for the 4.8.15 release. There are 33 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 know. Responses should be made by Thu Dec 15 17:15:24 UTC 2016. Anything

[PATCH 4.4 06/16] locking/rtmutex: Prevent dequeue vs. unlock race

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream. David reported a futex/rtmutex state corruption. It's caused by the following problem: CPU0

[PATCH 4.8 00/33] 4.8.15-stable review

This is the start of the stable review cycle for the 4.8.15 release. There are 33 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 know. Responses should be made by Thu Dec 15 17:15:24 UTC 2016. Anything

[PATCH 4.4 06/16] locking/rtmutex: Prevent dequeue vs. unlock race

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit dbb26055defd03d59f678cb5f2c992abe05b064a upstream. David reported a futex/rtmutex state corruption. It's caused by the following problem: CPU0CPU1

[PATCH 4.4 07/16] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream. While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in

[PATCH 4.4 07/16] locking/rtmutex: Use READ_ONCE() in rt_mutex_owner()

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Thomas Gleixner commit 1be5d4fa0af34fb7bafa205aeb59f5c7cc7a089d upstream. While debugging the rtmutex unlock vs. dequeue race Will suggested to use READ_ONCE() in rt_mutex_owner() as it might

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 12/12/2016 18:51, Brijesh Singh wrote: > As per the AMD BKDG [1] Section 2.7.1, we should not be using any of > these instruction for MMIO access, the behavior is undefined. > > The question is, do we really need to add logic to detect the cross-page > MMIO accesses and push/pop mem

Re: [PATCH] vfio/pci: Support error recovery

On Tue, 13 Dec 2016 18:12:34 +0200 "Michael S. Tsirkin" wrote: > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote: > > On Tue, 13 Dec 2016 05:15:13 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex

Re: [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk

On 12/12/2016 18:51, Brijesh Singh wrote: > As per the AMD BKDG [1] Section 2.7.1, we should not be using any of > these instruction for MMIO access, the behavior is undefined. > > The question is, do we really need to add logic to detect the cross-page > MMIO accesses and push/pop mem

Re: [PATCH] vfio/pci: Support error recovery

On Tue, 13 Dec 2016 18:12:34 +0200 "Michael S. Tsirkin" wrote: > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote: > > On Tue, 13 Dec 2016 05:15:13 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson wrote: > > > > > So

Re: [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings

On Tue, Dec 13, 2016 at 10:28 AM, Benjamin Gaignard wrote: > 2016-12-13 16:57 GMT+01:00 Rob Herring : >> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones wrote: >>> On Mon, 12 Dec 2016, Rob Herring wrote: >>> On Fri, Dec 09,

Re: [PATCHSET/RFC v2] blk-mq scheduling framework

On 12/13/2016 09:15 AM, Paolo Valente wrote: > >> Il giorno 13 dic 2016, alle ore 16:17, Jens Axboe ha scritto: >> >> On Tue, Dec 13 2016, Paolo Valente wrote: >>> Il giorno 08 dic 2016, alle ore 21:13, Jens Axboe ha scritto: As a followup to

Re: [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings

On Tue, Dec 13, 2016 at 10:28 AM, Benjamin Gaignard wrote: > 2016-12-13 16:57 GMT+01:00 Rob Herring : >> On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones wrote: >>> On Mon, 12 Dec 2016, Rob Herring wrote: >>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote: > Define

Re: [PATCHSET/RFC v2] blk-mq scheduling framework

On 12/13/2016 09:15 AM, Paolo Valente wrote: > >> Il giorno 13 dic 2016, alle ore 16:17, Jens Axboe ha scritto: >> >> On Tue, Dec 13 2016, Paolo Valente wrote: >>> Il giorno 08 dic 2016, alle ore 21:13, Jens Axboe ha scritto: As a followup to this posting from yesterday:

Re: [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings

2016-12-13 16:57 GMT+01:00 Rob Herring : > On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones wrote: >> On Mon, 12 Dec 2016, Rob Herring wrote: >> >>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote: >>> > Define bindings for pwm-stm32 >>> > >>> >

Re: [PATCH v8 3/3] perf annotate: Fix jump target outside of function address range

Em Mon, Dec 05, 2016 at 09:26:47PM +0530, Ravi Bangoria escreveu: > If jump target is outside of function range, perf is not handling it > correctly. Especially when target address is lesser than function start > address, target offset will be negative. But, target address declared > to be

Re: [PATCH 1/1] mtd: spi-nor: improve macronix_quad_enable()

Le 06/12/2016 à 20:01, Marek Vasut a écrit : > On 12/06/2016 05:01 PM, Cyrille Pitchen wrote: >> The patch checks whether the Quad Enable bit is already set in the Status >> Register. If so, the function exits immediately with a successful return >> code. > > Performance optimization I presume ?

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Mon, Dec 12, 2016 at 7:39 PM, Herbert Xu wrote: > On Mon, Dec 12, 2016 at 10:34:10AM -0800, Andy Lutomirski wrote: >> >> Here's my status. >> >> > drivers/crypto/bfin_crc.c:351 >> > drivers/crypto/qce/sha.c:299 >> >

Re: [PATCH v6 3/8] PWM: add pwm-stm32 DT bindings

2016-12-13 16:57 GMT+01:00 Rob Herring : > On Tue, Dec 13, 2016 at 5:11 AM, Lee Jones wrote: >> On Mon, 12 Dec 2016, Rob Herring wrote: >> >>> On Fri, Dec 09, 2016 at 03:15:14PM +0100, Benjamin Gaignard wrote: >>> > Define bindings for pwm-stm32 >>> > >>> > version 6: >>> > - change st,breakinput

Re: [PATCH v8 3/3] perf annotate: Fix jump target outside of function address range

Em Mon, Dec 05, 2016 at 09:26:47PM +0530, Ravi Bangoria escreveu: > If jump target is outside of function range, perf is not handling it > correctly. Especially when target address is lesser than function start > address, target offset will be negative. But, target address declared > to be

Re: [PATCH 1/1] mtd: spi-nor: improve macronix_quad_enable()

Le 06/12/2016 à 20:01, Marek Vasut a écrit : > On 12/06/2016 05:01 PM, Cyrille Pitchen wrote: >> The patch checks whether the Quad Enable bit is already set in the Status >> Register. If so, the function exits immediately with a successful return >> code. > > Performance optimization I presume ?

Re: Remaining crypto API regressions with CONFIG_VMAP_STACK

On Mon, Dec 12, 2016 at 7:39 PM, Herbert Xu wrote: > On Mon, Dec 12, 2016 at 10:34:10AM -0800, Andy Lutomirski wrote: >> >> Here's my status. >> >> > drivers/crypto/bfin_crc.c:351 >> > drivers/crypto/qce/sha.c:299 >> > drivers/crypto/sahara.c:973,988 >> >

[PATCH v2] ath9k: do not return early to fix rcu unlocking

Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls and suspicious RCU usage: === [

[PATCH] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx

If we don't disable the transmitter in atmel_stop_tx, the DMA buffer continues to send data until it is emptied. This cause problems with the flow control (CTS is asserted and data are still sent). So, disabling the transmitter in atmel_stop_tx is a sane thing to do. Tested on

[PATCH v2] ath9k: do not return early to fix rcu unlocking

Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on returning early in ath_tx_edma_tasklet() the unlock is missing leading to stalls and suspicious RCU usage: === [

[PATCH] tty/serial: atmel_serial: BUG: stop DMA from transmitting in stop_tx

If we don't disable the transmitter in atmel_stop_tx, the DMA buffer continues to send data until it is emptied. This cause problems with the flow control (CTS is asserted and data are still sent). So, disabling the transmitter in atmel_stop_tx is a sane thing to do. Tested on

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

On Tue, Dec 13, 2016 at 8:45 AM, David Howells wrote: > Andy Lutomirski wrote: > >> After all, rodata is ordinary memory, is backed by struct page, etc. > > Is that actually true? I thought some arches excluded the kernel image from > the page struct

Re: [PATCH] keys/encrypted: Fix two crypto-on-the-stack bugs

On Tue, Dec 13, 2016 at 8:45 AM, David Howells wrote: > Andy Lutomirski wrote: > >> After all, rodata is ordinary memory, is backed by struct page, etc. > > Is that actually true? I thought some arches excluded the kernel image from > the page struct array to make the array consume less memory.

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

Andy Lutomirski writes: > On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo wrote: >> Andy Lutomirski writes: >> >>> Eric Biggers pointed out that the orinoco driver pointed scatterlists >>> at the stack. >>> >>> Fix it by switching from

Re: [PATCH] orinoco: Use shash instead of ahash for MIC calculations

Andy Lutomirski writes: > On Tue, Dec 13, 2016 at 3:35 AM, Kalle Valo wrote: >> Andy Lutomirski writes: >> >>> Eric Biggers pointed out that the orinoco driver pointed scatterlists >>> at the stack. >>> >>> Fix it by switching from ahash to shash. The result should be >>> simpler, faster, and

Re: [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write()

Le 08/12/2016 à 16:31, Boris Brezillon a écrit : > On Tue, 6 Dec 2016 18:14:24 +0100 > Cyrille Pitchen wrote: > >> This patch removes the WARN_ONCE() test in spi_nor_write(). >> This macro triggers the display of a warning message almost every time we >> use a UBI

Re: [PATCH 1/1] mtd: spi-nor: remove WARN_ONCE() message in spi_nor_write()

Le 08/12/2016 à 16:31, Boris Brezillon a écrit : > On Tue, 6 Dec 2016 18:14:24 +0100 > Cyrille Pitchen wrote: > >> This patch removes the WARN_ONCE() test in spi_nor_write(). >> This macro triggers the display of a warning message almost every time we >> use a UBI file-system because a write

[PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal cooling maps to account for new OPPs. Since new OPPs are not available on all Exynos5422/5800 boards modify dts files for Odroid-XU3 Lite (limited to 1.8 GHz /

[PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

Add missing 2000MHz & 1900MHz OPPs (for A15 cores) and 1400MHz OPP (for A7 cores). Also update common Odroid-XU3 Lite/XU3/XU4 thermal cooling maps to account for new OPPs. Since new OPPs are not available on all Exynos5422/5800 boards modify dts files for Odroid-XU3 Lite (limited to 1.8 GHz /

<    5   6   7   8   9   10   11   12   13   14   >