[patch] mm: memcg: make sure memory.events is uptodate when waking pollers fix

On Fri, Apr 06, 2018 at 02:53:30PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > mm/memcontrol.c: In function 'memory_events_show': > mm/memcontrol.c:5453:23: warning: array

[patch] mm: memcg: make sure memory.events is uptodate when waking pollers fix

On Fri, Apr 06, 2018 at 02:53:30PM +1000, Stephen Rothwell wrote: > Hi Andrew, > > After merging the akpm-current tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > mm/memcontrol.c: In function 'memory_events_show': > mm/memcontrol.c:5453:23: warning: array

Re: [PATCH v3 3/4] backlight: pwm_bl: compute brightness of LED linearly to human eye.

On Thu, Feb 08, 2018 at 12:30:31PM +0100, Enric Balletbo i Serra wrote: > When you want to change the brightness using a PWM signal, one thing you > need to consider is how human perceive the brightness. Human perceive > the brightness change non-linearly, we have better sensitivity at low >

Re: [PATCH v3 3/4] backlight: pwm_bl: compute brightness of LED linearly to human eye.

On Thu, Feb 08, 2018 at 12:30:31PM +0100, Enric Balletbo i Serra wrote: > When you want to change the brightness using a PWM signal, one thing you > need to consider is how human perceive the brightness. Human perceive > the brightness change non-linearly, we have better sensitivity at low >

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

On Fri, Apr 06, 2018 at 04:27:45PM +0100, Will Deacon wrote: > Hi Andrea, > > On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > > I could say something like: > > > > > > "Pairs with dependency ordering from both

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

On Fri, Apr 06, 2018 at 04:27:45PM +0100, Will Deacon wrote: > Hi Andrea, > > On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > > I could say something like: > > > > > > "Pairs with dependency ordering from both

Re: AMD graphics performance regression in 4.15 and later

Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin: Hi Christian, Is there a way to turn off these huge pages at boot-time/run-time? Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE. Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the slow DMA path as well.

Re: AMD graphics performance regression in 4.15 and later

Am 06.04.2018 um 17:30 schrieb Jean-Marc Valin: Hi Christian, Is there a way to turn off these huge pages at boot-time/run-time? Only at compile time by not setting CONFIG_TRANSPARENT_HUGEPAGE. Alternatively you can avoid enabling CONFIG_SWIOTLB which will avoid the slow DMA path as well.

Re: [PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode

On 04/06/2018 10:34 AM, Maxime Ripard wrote: On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote: On 04/05/2018 04:17 PM, Mark Brown wrote: On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote: On 04/05/2018 12:19 PM, Maxime Ripard wrote: The point of that patch was

Re: [PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode

On 04/06/2018 10:34 AM, Maxime Ripard wrote: On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote: On 04/05/2018 04:17 PM, Mark Brown wrote: On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote: On 04/05/2018 12:19 PM, Maxime Ripard wrote: The point of that patch was

Re: [PATCH v3 1/4] backlight: pwm_bl: linear interpolation between brightness-levels

On Thu, Feb 08, 2018 at 12:30:29PM +0100, Enric Balletbo i Serra wrote: > Setting num-interpolated-steps in the dts will allow you to have linear > interpolation between values of brightness-levels. This way a high > resolution pwm duty cycle can be used without having to list out every > possible

Re: [PATCH v3 1/4] backlight: pwm_bl: linear interpolation between brightness-levels

On Thu, Feb 08, 2018 at 12:30:29PM +0100, Enric Balletbo i Serra wrote: > Setting num-interpolated-steps in the dts will allow you to have linear > interpolation between values of brightness-levels. This way a high > resolution pwm duty cycle can be used without having to list out every > possible

Re: INFO: task hung in lo_ioctl

On Fri, Apr 06, 2018 at 10:55:03PM +0900, Tetsuo Handa wrote: > Peter Zijlstra wrote: > > On Fri, Apr 06, 2018 at 09:04:18PM +0900, Tetsuo Handa wrote: > > > + /* Temporary hack for handling lock imbalance. */ > > > + if (__mutex_owner(>lo_ctl_mutex) == current) > > > +

Re: INFO: task hung in lo_ioctl

On Fri, Apr 06, 2018 at 10:55:03PM +0900, Tetsuo Handa wrote: > Peter Zijlstra wrote: > > On Fri, Apr 06, 2018 at 09:04:18PM +0900, Tetsuo Handa wrote: > > > + /* Temporary hack for handling lock imbalance. */ > > > + if (__mutex_owner(>lo_ctl_mutex) == current) > > > +

Re: KASAN: alloca-out-of-bounds Read in unwind_next_frame

On Fri, Apr 6, 2018 at 5:36 PM, Josh Poimboeuf wrote: > On Thu, Apr 05, 2018 at 05:02:02PM -0700, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on upstream commit >> 06dd3dfeea60e2a6457a6aedf97afc8e6d2ba497 (Thu Apr 5 03:07:20 2018 +) >> Merge tag

Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Hi Jacopo, (CC'ing Mark Brown) On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote: > On Fri, Apr 06, 2018 at 04:15:35PM +0300, Laurent Pinchart wrote: > > On Friday, 6 April 2018 15:41:56 EEST Jacopo Mondi wrote: > >> Document Thine THC63LVD1024 LVDS decoder device tree bindings. > >> >

Re: KASAN: alloca-out-of-bounds Read in unwind_next_frame

On Fri, Apr 6, 2018 at 5:36 PM, Josh Poimboeuf wrote: > On Thu, Apr 05, 2018 at 05:02:02PM -0700, syzbot wrote: >> Hello, >> >> syzbot hit the following crash on upstream commit >> 06dd3dfeea60e2a6457a6aedf97afc8e6d2ba497 (Thu Apr 5 03:07:20 2018 +) >> Merge tag 'char-misc-4.17-rc1' of >>

Re: [PATCH v7 1/2] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

Hi Jacopo, (CC'ing Mark Brown) On Friday, 6 April 2018 17:25:58 EEST jacopo mondi wrote: > On Fri, Apr 06, 2018 at 04:15:35PM +0300, Laurent Pinchart wrote: > > On Friday, 6 April 2018 15:41:56 EEST Jacopo Mondi wrote: > >> Document Thine THC63LVD1024 LVDS decoder device tree bindings. > >> >

[RFC PATCH v2 1/6] sched/fair: Create util_fits_capacity()

The functionality that a given utilization fits into a given capacity is factored out into a separate function. Currently it is only used in wake_cap() but will be re-used to figure out if a cpu or a scheduler group is over-utilized. Cc: Ingo Molnar Cc: Peter Zijlstra

[RFC PATCH v2 1/6] sched/fair: Create util_fits_capacity()

The functionality that a given utilization fits into a given capacity is factored out into a separate function. Currently it is only used in wake_cap() but will be re-used to figure out if a cpu or a scheduler group is over-utilized. Cc: Ingo Molnar Cc: Peter Zijlstra Signed-off-by: Dietmar

[RFC PATCH v2 2/6] sched: Introduce energy models of CPUs

From: Quentin Perret The energy consumption of each CPU in the system is modeled with a list of values representing its dissipated power and compute capacity at each available Operating Performance Point (OPP). These values are derived from existing information in the

[RFC PATCH v2 2/6] sched: Introduce energy models of CPUs

From: Quentin Perret The energy consumption of each CPU in the system is modeled with a list of values representing its dissipated power and compute capacity at each available Operating Performance Point (OPP). These values are derived from existing information in the kernel (currently used by

[RFC PATCH v2 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

From: Quentin Perret In case an energy model is available, waking tasks are re-routed into a new energy-aware placement algorithm. The eligible CPUs to be used in the energy-aware wakeup path are restricted to the highest non-overutilized sched_domain containing prev_cpu

[RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function

From: Quentin Perret In preparation for the definition of an energy-aware wakeup path, a helper function is provided to estimate the consequence on system energy when a specific task wakes-up on a specific CPU. compute_energy() estimates the OPPs to be reached by all

[RFC PATCH v2 5/6] sched/fair: Select an energy-efficient CPU on task wake-up

From: Quentin Perret In case an energy model is available, waking tasks are re-routed into a new energy-aware placement algorithm. The eligible CPUs to be used in the energy-aware wakeup path are restricted to the highest non-overutilized sched_domain containing prev_cpu and this_cpu. If no such

[RFC PATCH v2 4/6] sched/fair: Introduce an energy estimation helper function

From: Quentin Perret In preparation for the definition of an energy-aware wakeup path, a helper function is provided to estimate the consequence on system energy when a specific task wakes-up on a specific CPU. compute_energy() estimates the OPPs to be reached by all frequency domains and

[RFC PATCH v2 3/6] sched: Add over-utilization/tipping point indicator

From: Thara Gopinath Energy-aware scheduling should only operate when the system is not overutilized. There must be cpu time available to place tasks based on utilization in an energy-aware fashion, i.e. to pack tasks on energy-efficient cpus without harming the

[RFC PATCH v2 6/6] drivers: base: arch_topology.c: Enable EAS for arm/arm64 platforms

From: Quentin Perret Energy Aware Scheduling (EAS) has to be started from the arch code. This commit enables it from the arch topology driver for arm/arm64 systems, hence enabling a better support for Arm big.LITTLE and future DynamIQ architectures. Cc: Greg

[RFC PATCH v2 3/6] sched: Add over-utilization/tipping point indicator

From: Thara Gopinath Energy-aware scheduling should only operate when the system is not overutilized. There must be cpu time available to place tasks based on utilization in an energy-aware fashion, i.e. to pack tasks on energy-efficient cpus without harming the overall throughput. In case the

[RFC PATCH v2 6/6] drivers: base: arch_topology.c: Enable EAS for arm/arm64 platforms

From: Quentin Perret Energy Aware Scheduling (EAS) has to be started from the arch code. This commit enables it from the arch topology driver for arm/arm64 systems, hence enabling a better support for Arm big.LITTLE and future DynamIQ architectures. Cc: Greg Kroah-Hartman Signed-off-by:

[RFC PATCH v2 0/6] Energy Aware Scheduling

1. Overview The Energy Aware Scheduler (EAS) based on Morten Rasmussen's posting on LKML [1] is currently part of the AOSP Common Kernel and runs on today's smartphones with Arm's big.LITTLE CPUs. Based on the experience gained over the last two and a half years in product development, we propose

Re: KASAN: alloca-out-of-bounds Read in unwind_next_frame

On Thu, Apr 05, 2018 at 05:02:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 06dd3dfeea60e2a6457a6aedf97afc8e6d2ba497 (Thu Apr 5 03:07:20 2018 +) > Merge tag 'char-misc-4.17-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc >

[RFC PATCH v2 0/6] Energy Aware Scheduling

1. Overview The Energy Aware Scheduler (EAS) based on Morten Rasmussen's posting on LKML [1] is currently part of the AOSP Common Kernel and runs on today's smartphones with Arm's big.LITTLE CPUs. Based on the experience gained over the last two and a half years in product development, we propose

Re: KASAN: alloca-out-of-bounds Read in unwind_next_frame

On Thu, Apr 05, 2018 at 05:02:02PM -0700, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 06dd3dfeea60e2a6457a6aedf97afc8e6d2ba497 (Thu Apr 5 03:07:20 2018 +) > Merge tag 'char-misc-4.17-rc1' of > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc >

[PATCH 3.18 10/93] libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hans de Goede commit 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f upstream. Commit b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB drive"), introduced a

[PATCH 3.18 10/93] libata: Make Crucial BX100 500GB LPM quirk apply to all firmware versions

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hans de Goede commit 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f upstream. Commit b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB drive"), introduced a ATA_HORKAGE_NOLPM quirk for

[PATCH 3.18 11/93] libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hans de Goede commit d418ff56b8f2d2b296daafa8da151fe27689b757 upstream. When commit 9c7be59fc519af ("libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs") was added it

[PATCH 3.18 11/93] libata: Modify quirks for MX100 to limit NCQ_TRIM quirk to MU01 version

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hans de Goede commit d418ff56b8f2d2b296daafa8da151fe27689b757 upstream. When commit 9c7be59fc519af ("libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs") was added it inherited the

[PATCH 3.18 04/93] libata: fix length validation of ATAPI-relayed SCSI commands

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Biggers commit 058f58e235cbe03e923b30ea7c49995a46a8725f upstream. syzkaller reported a crash in ata_bmdma_fill_sg() when writing to /dev/sg1. The immediate cause

[PATCH 3.18 04/93] libata: fix length validation of ATAPI-relayed SCSI commands

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Biggers commit 058f58e235cbe03e923b30ea7c49995a46a8725f upstream. syzkaller reported a crash in ata_bmdma_fill_sg() when writing to /dev/sg1. The immediate cause was that the ATA

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

Mathieu Malaterre a écrit : Add gcc attribute unused for `l` variable, replace `path` variable directly with prom_scratch. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:607:6: error: variable ‘l’ set but not used

Re: [PATCH v4 03/19] powerpc: Mark variable `l` as unused, remove `path`

Mathieu Malaterre a écrit : Add gcc attribute unused for `l` variable, replace `path` variable directly with prom_scratch. Fix warnings treated as errors with W=1: arch/powerpc/kernel/prom_init.c:607:6: error: variable ‘l’ set but not used [-Werror=unused-but-set-variable]

Re: [PATCH 3/3] iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R support

On Fri, 30 Mar 2018 16:56:49 +0300 Stefan Popa wrote: > The AD5694/AD5694R/AD5695R/AD5696/AD5696R are a family of 4 channel DAC > s with 12-bit, 14-bit and 16-bit precision respectively. The devices have > either no built-in reference, or built-in 2.5V reference. > > The

Re: [PATCH 3/3] iio:dac:ad5686: Add AD5671R/75R/94/94R/95R/96/96R support

On Fri, 30 Mar 2018 16:56:49 +0300 Stefan Popa wrote: > The AD5694/AD5694R/AD5695R/AD5696/AD5696R are a family of 4 channel DAC > s with 12-bit, 14-bit and 16-bit precision respectively. The devices have > either no built-in reference, or built-in 2.5V reference. > > The AD5671R/AD5675R are

[PATCH 3.18 03/93] ALSA: aloop: Fix access to not-yet-ready substream via cable

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 8e6b1a72a75bb5067ccb6b56d8ca4aa3a300a64e upstream. In loopback_open() and loopback_close(), we assign and release the substream object to the corresponding

[PATCH 3.18 03/93] ALSA: aloop: Fix access to not-yet-ready substream via cable

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Takashi Iwai commit 8e6b1a72a75bb5067ccb6b56d8ca4aa3a300a64e upstream. In loopback_open() and loopback_close(), we assign and release the substream object to the corresponding cable in a racy

Re: [PATCH] qla2xxx: correctly shift host byte

On Fri, 2018-04-06 at 09:52 +0200, Johannes Thumshirn wrote: > The host byte has to be shifted by 16 not 6. > > Signed-off-by: Johannes Thumshirn > --- > drivers/scsi/qla2xxx/qla_isr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

[PATCH 3.18 05/93] libata: remove WARN() for DMA or PIO command without data

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Biggers commit 9173e5e80729c8434b8d27531527c5245f4a5594 upstream. syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0. This happened because it issued

Re: [PATCH] qla2xxx: correctly shift host byte

On Fri, 2018-04-06 at 09:52 +0200, Johannes Thumshirn wrote: > The host byte has to be shifted by 16 not 6. > > Signed-off-by: Johannes Thumshirn > --- > drivers/scsi/qla2xxx/qla_isr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/qla2xxx/qla_isr.c

[PATCH 3.18 05/93] libata: remove WARN() for DMA or PIO command without data

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Biggers commit 9173e5e80729c8434b8d27531527c5245f4a5594 upstream. syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0. This happened because it issued a READ_6 command

Re: [PATCH] arm: kgdb: fix NUMREGBYTES so that gdb_regs[] is the correct size

On Thu, Apr 05, 2018 at 04:09:16PM -0400, David Rivshin wrote: > From: David Rivshin > > NUMREGBYTES (which is used as the size for gdb_regs[]) is incorrectly based > on DBG_MAX_REG_NUM instead of GDB_MAX_REGS. DBG_MAX_REG_NUM is the number > of total registers, while

Re: [PATCH] arm: kgdb: fix NUMREGBYTES so that gdb_regs[] is the correct size

On Thu, Apr 05, 2018 at 04:09:16PM -0400, David Rivshin wrote: > From: David Rivshin > > NUMREGBYTES (which is used as the size for gdb_regs[]) is incorrectly based > on DBG_MAX_REG_NUM instead of GDB_MAX_REGS. DBG_MAX_REG_NUM is the number > of total registers, while GDB_MAX_REGS is the number

[PATCH 3.18 08/93] libata: Enable queued TRIM for Samsung SSD 860

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Ju Hyung Park commit ca6bfcb2f6d9deab3924bf901e73622a94900473 upstream. Samsung explicitly states that queued TRIM is supported for Linux with 860 PRO and 860 EVO.

[PATCH 3.18 08/93] libata: Enable queued TRIM for Samsung SSD 860

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Ju Hyung Park commit ca6bfcb2f6d9deab3924bf901e73622a94900473 upstream. Samsung explicitly states that queued TRIM is supported for Linux with 860 PRO and 860 EVO. Make the previous

Re: [PATCH v1]: perf/x86: store user space frame-pointer value on a sample

> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c > index e47b2dbbdef3..9284048cf5b0 100644 > --- a/arch/x86/kernel/perf_regs.c > +++ b/arch/x86/kernel/perf_regs.c > @@ -157,6 +157,15 @@ void perf_get_regs_user(struct perf_regs *regs_user, >*/ >

Re: [PATCH v1]: perf/x86: store user space frame-pointer value on a sample

> diff --git a/arch/x86/kernel/perf_regs.c b/arch/x86/kernel/perf_regs.c > index e47b2dbbdef3..9284048cf5b0 100644 > --- a/arch/x86/kernel/perf_regs.c > +++ b/arch/x86/kernel/perf_regs.c > @@ -157,6 +157,15 @@ void perf_get_regs_user(struct perf_regs *regs_user, >*/ >

[PATCH 3.18 06/93] libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hans de Goede commit 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 upstream. Various people have reported the Crucial MX100 512GB model not working with LPM set to min_power.

[PATCH 3.18 06/93] libata: Apply NOLPM quirk to Crucial MX100 512GB SSDs

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Hans de Goede commit 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 upstream. Various people have reported the Crucial MX100 512GB model not working with LPM set to min_power. I've now received a

[PATCH 3.18 13/93] brcmfmac: fix P2P_DEVICE ethernet address generation

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Arend Van Spriel commit 455f3e76cfc0d893585a5f358b9ddbe9c1e1e53b upstream. The firmware has a requirement that the P2P_DEVICE address should be different from

[PATCH 3.18 13/93] brcmfmac: fix P2P_DEVICE ethernet address generation

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Arend Van Spriel commit 455f3e76cfc0d893585a5f358b9ddbe9c1e1e53b upstream. The firmware has a requirement that the P2P_DEVICE address should be different from the address of the primary

[PATCH 3.18 22/93] [PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs"

3.18-stable review patch. If anyone has any objections, please let me know. -- This reverts commit 093c265afffb0a91a7611c3bb74d0883731a807b which is commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 upstream. It causes too many problems with the stable tree, and would require too

[PATCH 3.18 22/93] [PATCH] Revert "genirq: Use irqd_get_trigger_type to compare the trigger type for shared IRQs"

3.18-stable review patch. If anyone has any objections, please let me know. -- This reverts commit 093c265afffb0a91a7611c3bb74d0883731a807b which is commit 382bd4de61827dbaaf5fb4fb7b1f4be4a86505e7 upstream. It causes too many problems with the stable tree, and would require too

[PATCH 3.18 25/93] l2tp: do not accept arbitrary sockets

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 17cfe79a65f98abe535261856c5aef14f306dff7 ] syzkaller found an issue caused by lack of sufficient checks in l2tp_tunnel_create() RAW

[PATCH 3.18 25/93] l2tp: do not accept arbitrary sockets

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Eric Dumazet [ Upstream commit 17cfe79a65f98abe535261856c5aef14f306dff7 ] syzkaller found an issue caused by lack of sufficient checks in l2tp_tunnel_create() RAW sockets can not be

[PATCH] hwmon: (scmi) handle absence of few types of sensors

Currently the loop checks for non-zero count of sensors for each type of sensors which is completely wrong. It also results in aborting the registration of sensors if one or more types of sensors are completely not supported by the platform SCMI firmware. This patch fixes the issue by continue to

[PATCH] hwmon: (scmi) handle absence of few types of sensors

Currently the loop checks for non-zero count of sensors for each type of sensors which is completely wrong. It also results in aborting the registration of sensors if one or more types of sensors are completely not supported by the platform SCMI firmware. This patch fixes the issue by continue to

[PATCH 3.18 23/93] dccp: check sk for closed state in dccp_sendmsg()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Kodanev [ Upstream commit 67f93df79aeefc3add4e4b31a752600f834236e2 ] dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL, therefore if DCCP

[PATCH 3.18 23/93] dccp: check sk for closed state in dccp_sendmsg()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Alexey Kodanev [ Upstream commit 67f93df79aeefc3add4e4b31a752600f834236e2 ] dccp_disconnect() sets 'dp->dccps_hc_tx_ccid' tx handler to NULL, therefore if DCCP socket is disconnected and

[PATCH 3.18 26/93] net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Christophe JAILLET [ Upstream commit 00777fac28ba3e126b9e63e789a613e8bd2cab25 ] If the optional regulator is deferred, we must release some resources. They

[PATCH 3.18 26/93] net: ethernet: arc: Fix a potential memory leak if an optional regulator is deferred

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Christophe JAILLET [ Upstream commit 00777fac28ba3e126b9e63e789a613e8bd2cab25 ] If the optional regulator is deferred, we must release some resources. They will be re-allocated when the

Re: AMD graphics performance regression in 4.15 and later

Hi Christian, Is there a way to turn off these huge pages at boot-time/run-time? Right now the recent kernels are making Firefox pretty much unusable for me. I've been able to revert the patch from 4.15 but it's not really a long-term solution. You mention that the purpose of the patch is to

Re: AMD graphics performance regression in 4.15 and later

Hi Christian, Is there a way to turn off these huge pages at boot-time/run-time? Right now the recent kernels are making Firefox pretty much unusable for me. I've been able to revert the patch from 4.15 but it's not really a long-term solution. You mention that the purpose of the patch is to

[PATCH 3.18 28/93] netlink: avoid a double skb free in genlmsg_mcast()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Nicolas Dichtel [ Upstream commit 02a2385f37a7c6594c9d89b64c4a1451276f08eb ] nlmsg_multicast() consumes always the skb, thus the original skb must be freed only

[PATCH 3.18 28/93] netlink: avoid a double skb free in genlmsg_mcast()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Nicolas Dichtel [ Upstream commit 02a2385f37a7c6594c9d89b64c4a1451276f08eb ] nlmsg_multicast() consumes always the skb, thus the original skb must be freed only when this function is called

[PATCH 3.18 27/93] net/iucv: Free memory obtained by kzalloc

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Arvind Yadav [ Upstream commit fa6a91e9b907231d2e38ea5ed89c537b3525df3d ] Free memory by calling put_device(), if afiucv_iucv_init is not successful.

[PATCH 3.18 27/93] net/iucv: Free memory obtained by kzalloc

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Arvind Yadav [ Upstream commit fa6a91e9b907231d2e38ea5ed89c537b3525df3d ] Free memory by calling put_device(), if afiucv_iucv_init is not successful. Signed-off-by: Arvind Yadav

[PATCH 3.18 29/93] net: Only honor ifindex in IP_PKTINFO if non-0

3.18-stable review patch. If anyone has any objections, please let me know. -- From: David Ahern [ Upstream commit 2cbb4ea7de167b02ffa63e9cdfdb07a7e7094615 ] Only allow ifindex from IP_PKTINFO to override SO_BINDTODEVICE settings if the index is actually

[PATCH 3.18 30/93] skbuff: Fix not waking applications when errors are enqueued

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Vinicius Costa Gomes [ Upstream commit 6e5d58fdc9bedd0255a8781b258f10bbdc63e975 ] When errors are enqueued to the error queue via sock_queue_err_skb() function, it

[PATCH 3.18 29/93] net: Only honor ifindex in IP_PKTINFO if non-0

3.18-stable review patch. If anyone has any objections, please let me know. -- From: David Ahern [ Upstream commit 2cbb4ea7de167b02ffa63e9cdfdb07a7e7094615 ] Only allow ifindex from IP_PKTINFO to override SO_BINDTODEVICE settings if the index is actually set in the message.

[PATCH 3.18 30/93] skbuff: Fix not waking applications when errors are enqueued

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Vinicius Costa Gomes [ Upstream commit 6e5d58fdc9bedd0255a8781b258f10bbdc63e975 ] When errors are enqueued to the error queue via sock_queue_err_skb() function, it is possible that the

Re: [PATCH v9 05/10] cpuidle: Return nohz hint from cpuidle_select()

On Fri, Apr 06, 2018 at 02:56:36PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: [PATCH] nohz: Avoid duplication of code related to got_idle_tick > > Move the code setting ts->got_idle_tick into tick_sched_do_timer() to > avoid code duplication.

Re: [PATCH v9 05/10] cpuidle: Return nohz hint from cpuidle_select()

On Fri, Apr 06, 2018 at 02:56:36PM +0200, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > Subject: [PATCH] nohz: Avoid duplication of code related to got_idle_tick > > Move the code setting ts->got_idle_tick into tick_sched_do_timer() to > avoid code duplication. > > No intentional changes

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

Hi Laurent, On 04/06/2018 04:53 PM, Laurent Pinchart wrote: > Hi Philippe, > > Thank you for the patch. > > On Monday, 26 February 2018 14:16:04 EEST Philippe Cornu wrote: >> This patch clarifies the adjusted_mode documentation >> for a bridge directly connected to a crtc. >> >> Signed-off-by:

Re: [PATCH] drm: clarify adjusted_mode for a bridge connected to a crtc

Hi Laurent, On 04/06/2018 04:53 PM, Laurent Pinchart wrote: > Hi Philippe, > > Thank you for the patch. > > On Monday, 26 February 2018 14:16:04 EEST Philippe Cornu wrote: >> This patch clarifies the adjusted_mode documentation >> for a bridge directly connected to a crtc. >> >> Signed-off-by:

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

Hi Kishon, On 02/04/2018 14:29, Kishon Vijay Abraham I wrote: > In order to be able to provide correct driver_data for pci_epf device, > a separate configfs entry for each pci_epf_device_id table entry in > pci_epf_driver is required. > > Add support to create configfs entry for each

Re: [PATCH] PCI: endpoint: Create configfs entry for each pci_epf_device_id table entry

Hi Kishon, On 02/04/2018 14:29, Kishon Vijay Abraham I wrote: > In order to be able to provide correct driver_data for pci_epf device, > a separate configfs entry for each pci_epf_device_id table entry in > pci_epf_driver is required. > > Add support to create configfs entry for each

[PATCH 3.18 33/93] s390/qeth: when thread completes, wake up all waiters

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 1063e432bb45be209427ed3f1ca3908e4aa3c7d7 ] qeth_wait_for_threads() is potentially called by multiple users, make sure to notify all

[PATCH 3.18 34/93] s390/qeth: lock read device while queueing next buffer

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 17bf8c9b3d499d5168537c98b61eb7a1fcbca6c2 ] For calling ccw_device_start(), issue_next_read() needs to hold the device's ccwlock.

[PATCH 3.18 34/93] s390/qeth: lock read device while queueing next buffer

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 17bf8c9b3d499d5168537c98b61eb7a1fcbca6c2 ] For calling ccw_device_start(), issue_next_read() needs to hold the device's ccwlock. This is satisfied for the

[PATCH 3.18 33/93] s390/qeth: when thread completes, wake up all waiters

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 1063e432bb45be209427ed3f1ca3908e4aa3c7d7 ] qeth_wait_for_threads() is potentially called by multiple users, make sure to notify all of them after

[PATCH 3.18 31/93] team: Fix double free in error path

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Arkadi Sharshevsky [ Upstream commit cbcc607e18422555db569b593608aec26111cb0b ] The __send_and_alloc_skb() receives a skb ptr as a parameter but in case it fails the

[PATCH 3.18 31/93] team: Fix double free in error path

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Arkadi Sharshevsky [ Upstream commit cbcc607e18422555db569b593608aec26111cb0b ] The __send_and_alloc_skb() receives a skb ptr as a parameter but in case it fails the skb is not valid: - Send

[PATCH 3.18 32/93] s390/qeth: free netdevice when removing a card

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 6be687395b3124f002a653c1a50b3260222b3cd7 ] On removal, a qeth card's netdevice is currently not properly freed because the call

[PATCH 3.18 32/93] s390/qeth: free netdevice when removing a card

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Julian Wiedmann [ Upstream commit 6be687395b3124f002a653c1a50b3260222b3cd7 ] On removal, a qeth card's netdevice is currently not properly freed because the call chain looks as follows:

[PATCH 3.18 36/93] net: fec: Fix unbalanced PM runtime calls

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Florian Fainelli [ Upstream commit a069215cf5985f3aa1bba550264907d6bd05c5f7 ] When unbinding/removing the driver, we will run into the following warnings: [

[PATCH 3.18 36/93] net: fec: Fix unbalanced PM runtime calls

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Florian Fainelli [ Upstream commit a069215cf5985f3aa1bba550264907d6bd05c5f7 ] When unbinding/removing the driver, we will run into the following warnings: [ 259.655198] fec

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

Hi Andrea, On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > I could say something like: > > > > "Pairs with dependency ordering from both xchg_tail and explicit > >dereferences of node->next" > > > > but it's

Re: [PATCH 10/10] locking/qspinlock: Elide back-to-back RELEASE operations with smp_wmb()

Hi Andrea, On Fri, Apr 06, 2018 at 03:05:12PM +0200, Andrea Parri wrote: > On Fri, Apr 06, 2018 at 12:34:36PM +0100, Will Deacon wrote: > > I could say something like: > > > > "Pairs with dependency ordering from both xchg_tail and explicit > >dereferences of node->next" > > > > but it's

[PATCH 3.18 37/93] mtd: jedec_probe: Fix crash in jedec_read_mfr()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Linus Walleij commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream. It turns out that the loop where we read manufacturer jedec_read_mfd() can under some

[PATCH 3.18 37/93] mtd: jedec_probe: Fix crash in jedec_read_mfr()

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Linus Walleij commit 87a73eb5b56fd6e07c8e499fe8608ef2d8912b82 upstream. It turns out that the loop where we read manufacturer jedec_read_mfd() can under some circumstances get a

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