[PATCH review for 3.18 12/12] [media] bt8xx: fix memory leak

From: Sudip Mukherjee [ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by: Sudip Mukherjee

[PATCH review for 4.4 14/24] dmaengine: sun6i: allow build on ARM64 platforms (sun50i)

From: Icenowy Zheng [ Upstream commit c429ceb1e18252122ba96b52e689dcf87103c186 ] As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA driver should be allowed to be built for ARM64, in order to make it work on H5. Signed-off-by: Icenowy Zheng Acked-by: Maxime Ripard Acked-by:

[PATCH review for 4.4 17/24] platform/x86: intel_mid_thermal: Fix module autoload

From: Javier Martinez Canillas [ Upstream commit a93151a72061e944a4915458b1b1d6d505c03bbf ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the

[PATCH review for 3.18 12/12] [media] bt8xx: fix memory leak

From: Sudip Mukherjee [ Upstream commit 6792eb0cf9310ec240b7e7c9bfa86dff4c758c68 ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by: Sudip Mukherjee Signed-off-by: Hans Verkuil Signed-off-by: Mauro

[PATCH review for 4.4 19/24] staging: lustre: hsm: stack overrun in hai_dump_data_field

From: frank zago [ Upstream commit 22aadb91c0a0055935109c175f5446abfb130702 ] The function hai_dump_data_field will do a stack buffer overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has some data in it. hai_dump_data_field uses snprintf. But there is no check

[PATCH review for 4.4 19/24] staging: lustre: hsm: stack overrun in hai_dump_data_field

From: frank zago [ Upstream commit 22aadb91c0a0055935109c175f5446abfb130702 ] The function hai_dump_data_field will do a stack buffer overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has some data in it. hai_dump_data_field uses snprintf. But there is no check for truncation,

[PATCH review for 4.9 34/50] staging: lustre: llite: don't invoke direct_IO for the EOF case

From: Yang Sheng [ Upstream commit 77759771fb95420d23876cb104ab65c022613325 ] The function generic_file_read_iter() does not check EOF before invoke direct_IO callback. So we have to check it ourselves. Signed-off-by: Yang Sheng Intel-bug-id:

[PATCH review for 4.9 32/50] scsi: aacraid: Process Error for response I/O

From: Raghava Aditya Renukunta [ Upstream commit 4ec57fb4edaec523f0f78a0449a3b063749ac58b ] Make sure that the driver processes error conditions even in the fast response path for response from the adapter. Signed-off-by: Raghava Aditya Renukunta

[PATCH review for 4.9 34/50] staging: lustre: llite: don't invoke direct_IO for the EOF case

From: Yang Sheng [ Upstream commit 77759771fb95420d23876cb104ab65c022613325 ] The function generic_file_read_iter() does not check EOF before invoke direct_IO callback. So we have to check it ourselves. Signed-off-by: Yang Sheng Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969

[PATCH review for 4.9 32/50] scsi: aacraid: Process Error for response I/O

From: Raghava Aditya Renukunta [ Upstream commit 4ec57fb4edaec523f0f78a0449a3b063749ac58b ] Make sure that the driver processes error conditions even in the fast response path for response from the adapter. Signed-off-by: Raghava Aditya Renukunta Signed-off-by: Dave Carroll Reviewed-by:

[PATCH review for 4.9 26/50] clk: sunxi-ng: Check kzalloc() for errors and cleanup error path

From: Stephen Boyd [ Upstream commit 5d806f9fc8e63d7a44e0fd1ef26a7c27efae0e51 ] This kzalloc() could fail. Let's bail out with -ENOMEM here instead of NULL dereferencing. That silences static checkers. We should also cleanup on the error path even though this function

[PATCH review for 4.9 26/50] clk: sunxi-ng: Check kzalloc() for errors and cleanup error path

From: Stephen Boyd [ Upstream commit 5d806f9fc8e63d7a44e0fd1ef26a7c27efae0e51 ] This kzalloc() could fail. Let's bail out with -ENOMEM here instead of NULL dereferencing. That silences static checkers. We should also cleanup on the error path even though this function returning an error

[PATCH review for 4.9 15/50] ext4: do not use stripe_width if it is not set

From: Jan Kara [ Upstream commit 5469d7c3087ecaf760f54b447f11af6061b7c897 ] Avoid using stripe_width for sbi->s_stripe value if it is not actually set. It prevents using the stride for sbi->s_stripe. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o

[PATCH review for 4.9 15/50] ext4: do not use stripe_width if it is not set

From: Jan Kara [ Upstream commit 5469d7c3087ecaf760f54b447f11af6061b7c897 ] Avoid using stripe_width for sbi->s_stripe value if it is not actually set. It prevents using the stride for sbi->s_stripe. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin ---

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote: >Hi Greg, > >On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote: >> 4.9-stable review patch. If anyone has any objections, please let me know. > >I'm a little confused as to why this is being backported, given it

Re: [PATCH 4.9 086/104] arm64: kasan: avoid bad virt_to_pfn()

On Fri, Oct 06, 2017 at 07:13:22PM +0100, Mark Rutland wrote: >Hi Greg, > >On Fri, Oct 06, 2017 at 10:52:04AM +0200, Greg Kroah-Hartman wrote: >> 4.9-stable review patch. If anyone has any objections, please let me know. > >I'm a little confused as to why this is being backported, given it

[PATCH v2 2/4] kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK

Convert all allocations that used a NOTRACK flag to stop using it. Signed-off-by: Sasha Levin --- arch/arm/include/asm/pgalloc.h | 2 +- arch/arm64/include/asm/pgalloc.h | 2 +- arch/powerpc/include/asm/pgalloc.h | 2 +- arch/sh/kernel/dwarf.c

[PATCH v2 2/4] kmemcheck: stop using GFP_NOTRACK and SLAB_NOTRACK

Convert all allocations that used a NOTRACK flag to stop using it. Signed-off-by: Sasha Levin --- arch/arm/include/asm/pgalloc.h | 2 +- arch/arm64/include/asm/pgalloc.h | 2 +- arch/powerpc/include/asm/pgalloc.h | 2 +- arch/sh/kernel/dwarf.c | 4 ++--

[PATCH v2 1/4] kmemcheck: remove annotations

Remove kmemcheck annotations, and calls to kmemcheck from the kernel. Signed-off-by: Sasha Levin --- arch/arm/include/asm/dma-iommu.h| 1 - arch/openrisc/include/asm/dma-mapping.h | 1 - arch/x86/Makefile | 5 -

[PATCH v2 3/4] kmemcheck: rip it out

Fix up makefiles, remove references, and git rm kmemcheck. Signed-off-by: Sasha Levin --- Documentation/admin-guide/kernel-parameters.txt | 7 - Documentation/dev-tools/index.rst | 1 - Documentation/dev-tools/kmemcheck.rst | 733

[PATCH v2 1/4] kmemcheck: remove annotations

Remove kmemcheck annotations, and calls to kmemcheck from the kernel. Signed-off-by: Sasha Levin --- arch/arm/include/asm/dma-iommu.h| 1 - arch/openrisc/include/asm/dma-mapping.h | 1 - arch/x86/Makefile | 5 - arch/x86/include/asm/dma-mapping.h | 1 -

[PATCH v2 3/4] kmemcheck: rip it out

Fix up makefiles, remove references, and git rm kmemcheck. Signed-off-by: Sasha Levin --- Documentation/admin-guide/kernel-parameters.txt | 7 - Documentation/dev-tools/index.rst | 1 - Documentation/dev-tools/kmemcheck.rst | 733 MAINTAINERS

[PATCH v2 4/4] kmemcheck: remove whats left of NOTRACK flags

Now that kmemcheck is gone, we don't need the NOTRACK flags. Signed-off-by: Sasha Levin --- arch/x86/include/asm/pgtable.h | 5 - arch/x86/include/asm/pgtable_types.h | 13 - include/linux/gfp.h | 9 -

[PATCH v2 0/4] kmemcheck: kill kmemcheck

2 Years ago I proposed to kill kmemcheck: > As discussed on LSF/MM, kill kmemcheck. > > KASan is a replacement that is able to work without the limitation of > kmemcheck (single CPU, slow). KASan is already upstream. > > We are also not aware of any users of kmemcheck (or users who don't consider

[PATCH v2 4/4] kmemcheck: remove whats left of NOTRACK flags

Now that kmemcheck is gone, we don't need the NOTRACK flags. Signed-off-by: Sasha Levin --- arch/x86/include/asm/pgtable.h | 5 - arch/x86/include/asm/pgtable_types.h | 13 - include/linux/gfp.h | 9 - include/linux/slab.h | 6

[PATCH v2 0/4] kmemcheck: kill kmemcheck

2 Years ago I proposed to kill kmemcheck: > As discussed on LSF/MM, kill kmemcheck. > > KASan is a replacement that is able to work without the limitation of > kmemcheck (single CPU, slow). KASan is already upstream. > > We are also not aware of any users of kmemcheck (or users who don't consider

Re: [PATCH 3/4] sched: WARN when migrating to an offline CPU

On Fri, Sep 29, 2017 at 01:11:26PM +0200, Peter Zijlstra wrote: >I can't seem to trigger :-( > >Can you please run with the below patch and: > > # echo 1 > /proc/sys/kernel/traceoff_on_warning The call stack trace looks like so: [ 2073.492089] Unregister pv shared memory for cpu 2 [

Re: [PATCH 3/4] sched: WARN when migrating to an offline CPU

On Fri, Sep 29, 2017 at 01:11:26PM +0200, Peter Zijlstra wrote: >I can't seem to trigger :-( > >Can you please run with the below patch and: > > # echo 1 > /proc/sys/kernel/traceoff_on_warning The call stack trace looks like so: [ 2073.492089] Unregister pv shared memory for cpu 2 [

Re: [PATCH 4.4 22/50] pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()

On Fri, Oct 06, 2017 at 11:20:11AM +0200, Greg Kroah-Hartman wrote: >On Fri, Oct 06, 2017 at 02:09:14AM -0700, Joe Perches wrote: >> On Fri, 2017-10-06 at 10:53 +0200, Greg Kroah-Hartman wrote: >> > 4.4-stable review patch. If anyone has any objections, please let me know. >> >> I hope this patch

Re: [PATCH 4.4 22/50] pinctrl: mvebu: Use seq_puts() in mvebu_pinconf_group_dbg_show()

On Fri, Oct 06, 2017 at 11:20:11AM +0200, Greg Kroah-Hartman wrote: >On Fri, Oct 06, 2017 at 02:09:14AM -0700, Joe Perches wrote: >> On Fri, 2017-10-06 at 10:53 +0200, Greg Kroah-Hartman wrote: >> > 4.4-stable review patch. If anyone has any objections, please let me know. >> >> I hope this patch

Re: [PATCH] mm: kill kmemcheck again

On Sat, Sep 30, 2017 at 03:57:27PM +0200, Vegard Nossum wrote: >On 30 September 2017 at 11:48, Steven Rostedt wrote: >> On Wed, 27 Sep 2017 17:02:07 +0200 >> Michal Hocko wrote: >> >>> > Now that 2 years have passed, and all distros provide gcc that

Re: [PATCH] mm: kill kmemcheck again

On Sat, Sep 30, 2017 at 03:57:27PM +0200, Vegard Nossum wrote: >On 30 September 2017 at 11:48, Steven Rostedt wrote: >> On Wed, 27 Sep 2017 17:02:07 +0200 >> Michal Hocko wrote: >> >>> > Now that 2 years have passed, and all distros provide gcc that supports >>> > KASAN, kill kmemcheck again for

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Thu, Sep 28, 2017 at 06:08:56PM +0200, Peter Zijlstra wrote: >On Thu, Sep 28, 2017 at 03:38:16PM +0000, Levin, Alexander (Sasha Levin) wrote: >> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote: > >> >Hmmm... kernel/rcu/tree_plugin.h:329 thinks that some

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Thu, Sep 28, 2017 at 06:08:56PM +0200, Peter Zijlstra wrote: >On Thu, Sep 28, 2017 at 03:38:16PM +0000, Levin, Alexander (Sasha Levin) wrote: >> On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote: > >> >Hmmm... kernel/rcu/tree_plugin.h:329 thinks that some

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote: >On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote: >> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney >> wrote: >> > Currently, a call to schedule() acts as a Tasks RCU quiescent state >> >

Re: [PATCH v3 tip/core/rcu 40/40] rcu: Make non-preemptive schedule be Tasks RCU quiescent state

On Thu, Sep 28, 2017 at 05:30:55AM -0700, Paul E. McKenney wrote: >On Thu, Sep 28, 2017 at 02:37:20AM -0700, Sasha Levin wrote: >> On Wed, Apr 19, 2017 at 9:58 AM, Paul E. McKenney >> wrote: >> > Currently, a call to schedule() acts as a Tasks RCU quiescent state >> > only if a context switch

Re: sched: serial port lockdep warning when offlining CPUs

On Thu, Sep 28, 2017 at 08:36:07PM +0900, Sergey Senozhatsky wrote: >On (09/28/17 19:30), Sergey Senozhatsky wrote: >> lib/ratelimit.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/lib/ratelimit.c b/lib/ratelimit.c >> index 08f8043cac61..bddc55834c2e 100644 >> ---

Re: sched: serial port lockdep warning when offlining CPUs

On Thu, Sep 28, 2017 at 08:36:07PM +0900, Sergey Senozhatsky wrote: >On (09/28/17 19:30), Sergey Senozhatsky wrote: >> lib/ratelimit.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/lib/ratelimit.c b/lib/ratelimit.c >> index 08f8043cac61..bddc55834c2e 100644 >> ---

Re: sched: serial port lockdep warning when offlining CPUs

On Thu, Sep 28, 2017 at 11:38:47AM +0200, Peter Zijlstra wrote: >On Thu, Sep 28, 2017 at 02:19:46AM -0700, Sasha Levin wrote: >> Hi all, >> >> I seem to be hitting the following warning when offlining CPUs on the >> latest -next kernel: >> >> [289683102.607076] Unregister pv shared memory for cpu

Re: sched: serial port lockdep warning when offlining CPUs

On Thu, Sep 28, 2017 at 11:38:47AM +0200, Peter Zijlstra wrote: >On Thu, Sep 28, 2017 at 02:19:46AM -0700, Sasha Levin wrote: >> Hi all, >> >> I seem to be hitting the following warning when offlining CPUs on the >> latest -next kernel: >> >> [289683102.607076] Unregister pv shared memory for cpu

Re: [PATCH 3/4] sched: WARN when migrating to an offline CPU

On Thu, Sep 28, 2017 at 12:35:41PM +0200, Peter Zijlstra wrote: >On Thu, Sep 28, 2017 at 02:14:15AM -0700, Sasha Levin wrote: >> On Thu, Sep 7, 2017 at 8:03 AM, Peter Zijlstra wrote: >> > Migrating tasks to offline CPUs is a pretty big fail, warn about it. >> >> Hey Peter,

Re: [PATCH 3/4] sched: WARN when migrating to an offline CPU

On Thu, Sep 28, 2017 at 12:35:41PM +0200, Peter Zijlstra wrote: >On Thu, Sep 28, 2017 at 02:14:15AM -0700, Sasha Levin wrote: >> On Thu, Sep 7, 2017 at 8:03 AM, Peter Zijlstra wrote: >> > Migrating tasks to offline CPUs is a pretty big fail, warn about it. >> >> Hey Peter, >> >> This seems to get

Re: [PATCH] mm: kill kmemcheck again

On Wed, Sep 27, 2017 at 12:36:27PM -0500, Eric W. Biederman wrote: >"Levin, Alexander (Sasha Levin)" <alexander.le...@verizon.com> writes: > >> On Wed, Sep 27, 2017 at 05:02:07PM +0200, Michal Hocko wrote: >>>This is just too large to review manually

Re: [PATCH] mm: kill kmemcheck again

On Wed, Sep 27, 2017 at 12:36:27PM -0500, Eric W. Biederman wrote: >"Levin, Alexander (Sasha Levin)" writes: > >> On Wed, Sep 27, 2017 at 05:02:07PM +0200, Michal Hocko wrote: >>>This is just too large to review manually. How have you generated the >>

Re: [PATCH] mm: kill kmemcheck again

On Wed, Sep 27, 2017 at 05:02:07PM +0200, Michal Hocko wrote: >This is just too large to review manually. How have you generated the >patch? Manualy. Note that most of it (~95%) is the result of 'rm arch/x86/mm/kmemcheck'. Otherwise, I just removed all uses of __GFP_NOWARN/SLAB_NOWARN, and

Re: [PATCH] mm: kill kmemcheck again

On Wed, Sep 27, 2017 at 05:02:07PM +0200, Michal Hocko wrote: >This is just too large to review manually. How have you generated the >patch? Manualy. Note that most of it (~95%) is the result of 'rm arch/x86/mm/kmemcheck'. Otherwise, I just removed all uses of __GFP_NOWARN/SLAB_NOWARN, and

Re: [PATCH] mm: kill kmemcheck again

I stupidly forgot to Cc Pekka and Vegard, now Cc'ed. On Wed, Sep 27, 2017 at 11:27:40AM +, Levin, Alexander (Sasha Levin) wrote: >2 Years ago I proposed to kill kmemcheck: > >> As discussed on LSF/MM, kill kmemcheck. >> >> KASan is a replacement that is able to wor

Re: [PATCH] mm: kill kmemcheck again

I stupidly forgot to Cc Pekka and Vegard, now Cc'ed. On Wed, Sep 27, 2017 at 11:27:40AM +, Levin, Alexander (Sasha Levin) wrote: >2 Years ago I proposed to kill kmemcheck: > >> As discussed on LSF/MM, kill kmemcheck. >> >> KASan is a replacement that is able to wor

[PATCH] mm: kill kmemcheck again

2 Years ago I proposed to kill kmemcheck: > As discussed on LSF/MM, kill kmemcheck. > > KASan is a replacement that is able to work without the limitation of > kmemcheck (single CPU, slow). KASan is already upstream. > > We are also not aware of any users of kmemcheck (or users who don't consider

[PATCH] mm: kill kmemcheck again

2 Years ago I proposed to kill kmemcheck: > As discussed on LSF/MM, kill kmemcheck. > > KASan is a replacement that is able to work without the limitation of > kmemcheck (single CPU, slow). KASan is already upstream. > > We are also not aware of any users of kmemcheck (or users who don't consider

Re: [PATCH review for 4.4 19/26] i2c: at91: ensure state is restored after suspending

On Mon, Sep 25, 2017 at 09:22:34AM +0200, Alexandre Belloni wrote: >Hi, > >I don't think it is worth backporting this patch to 4.4. Cutting VDD >core will only happen after mainline v4.12 or v4.9 for the vendor kernel. I'll drop it, thanks Alexandre! -- Thanks, Sasha

Re: [PATCH review for 4.4 19/26] i2c: at91: ensure state is restored after suspending

On Mon, Sep 25, 2017 at 09:22:34AM +0200, Alexandre Belloni wrote: >Hi, > >I don't think it is worth backporting this patch to 4.4. Cutting VDD >core will only happen after mainline v4.12 or v4.9 for the vendor kernel. I'll drop it, thanks Alexandre! -- Thanks, Sasha

[PATCH review for 4.9 15/50] sched/fair: Update rq clock before changing a task's CPU affinity

From: Wanpeng Li [ Upstream commit a499c3ead88ccf147fc50689e85a530ad923ce36 ] This is triggered during boot when CONFIG_SCHED_DEBUG is enabled: [ cut here ] WARNING: CPU: 6 PID: 81 at kernel/sched/sched.h:812 set_next_entity+0x11d/0x380

[PATCH review for 4.9 15/50] sched/fair: Update rq clock before changing a task's CPU affinity

From: Wanpeng Li [ Upstream commit a499c3ead88ccf147fc50689e85a530ad923ce36 ] This is triggered during boot when CONFIG_SCHED_DEBUG is enabled: [ cut here ] WARNING: CPU: 6 PID: 81 at kernel/sched/sched.h:812 set_next_entity+0x11d/0x380 rq->clock_update_flags <

[PATCH review for 4.9 29/50] qede: Prevent index problems in loopback test

From: Sudarsana Reddy Kalluru [ Upstream commit afe981d664aeeebc8d1bcbd7d2070b5432edaecb ] Driver currently utilizes the same loop variable in two nested loops. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Yuval Mintz

[PATCH review for 4.9 29/50] qede: Prevent index problems in loopback test

From: Sudarsana Reddy Kalluru [ Upstream commit afe981d664aeeebc8d1bcbd7d2070b5432edaecb ] Driver currently utilizes the same loop variable in two nested loops. Signed-off-by: Sudarsana Reddy Kalluru Signed-off-by: Yuval Mintz Signed-off-by: David S. Miller Signed-off-by: Sasha Levin ---

[PATCH review for 4.9 14/50] f2fs: do SSR for data when there is enough free space

From: Yunlong Song [ Upstream commit 035e97adab26c1121cedaeb9bd04cf48a8e8cf51 ] In allocate_segment_by_default(), need_SSR() already detected it's time to do SSR. So, let's try to find victims for data segments more aggressively in time. Signed-off-by: Yunlong Song

[PATCH review for 4.9 26/50] ASoC: mediatek: add I2C dependency for CS42XX8

From: Arnd Bergmann [ Upstream commit 72cedf599fcebfd6cd2550274d7855838068d28c ] We should not select drivers that depend on I2C when that is disabled, as it results in a build error: warning: (SND_SOC_MT2701_CS42448) selects SND_SOC_CS42XX8_I2C which has unmet direct

[PATCH review for 4.9 14/50] f2fs: do SSR for data when there is enough free space

From: Yunlong Song [ Upstream commit 035e97adab26c1121cedaeb9bd04cf48a8e8cf51 ] In allocate_segment_by_default(), need_SSR() already detected it's time to do SSR. So, let's try to find victims for data segments more aggressively in time. Signed-off-by: Yunlong Song Signed-off-by: Jaegeuk Kim

[PATCH review for 4.9 26/50] ASoC: mediatek: add I2C dependency for CS42XX8

From: Arnd Bergmann [ Upstream commit 72cedf599fcebfd6cd2550274d7855838068d28c ] We should not select drivers that depend on I2C when that is disabled, as it results in a build error: warning: (SND_SOC_MT2701_CS42448) selects SND_SOC_CS42XX8_I2C which has unmet direct dependencies (SOUND &&

[PATCH review for 4.9 24/50] slub: do not merge cache if slub_debug contains a never-merge flag

From: Grygorii Maistrenko [ Upstream commit c6e28895a4372992961888ffaadc9efc643b5bfe ] In case CONFIG_SLUB_DEBUG_ON=n, find_mergeable() gets debug features from commandline but never checks if there are features from the SLAB_NEVER_MERGE set. As a result selected by

[PATCH review for 4.9 07/50] ALSA: hda: Add Geminilake HDMI codec ID

From: Vinod Koul [ Upstream commit 126cfa2f5e15ae2ca7f70be71b07e6cd8d2b44d1 ] Geminilake HDMI codec 0x280d is similar to previous platforms, so add it with similar ops as previous. Signed-off-by: Senthilnathan Veppur Signed-off-by: Vinod

[PATCH review for 4.9 17/50] f2fs: do not wait for writeback in write_begin

From: Jaegeuk Kim [ Upstream commit 86d54795c94532075d862aa0a79f0c981dab4bdd ] Otherwise we can get livelock like below. [79880.428136] dbench D0 18405 18404 0x [79880.428139] Call Trace: [79880.428142] __schedule+0x219/0x6b0 [79880.428144]

[PATCH review for 4.9 18/50] md/linear: shutup lockdep warnning

From: Shaohua Li [ Upstream commit d939cdfde34f50b95254b375f498447c82190b3e ] Commit 03a9e24(md linear: fix a race between linear_add() and linear_congested()) introduces the warnning. Acked-by: Coly Li Signed-off-by: Shaohua Li Signed-off-by: Sasha

[PATCH review for 4.9 24/50] slub: do not merge cache if slub_debug contains a never-merge flag

From: Grygorii Maistrenko [ Upstream commit c6e28895a4372992961888ffaadc9efc643b5bfe ] In case CONFIG_SLUB_DEBUG_ON=n, find_mergeable() gets debug features from commandline but never checks if there are features from the SLAB_NEVER_MERGE set. As a result selected by slub_debug caches are

[PATCH review for 4.9 07/50] ALSA: hda: Add Geminilake HDMI codec ID

From: Vinod Koul [ Upstream commit 126cfa2f5e15ae2ca7f70be71b07e6cd8d2b44d1 ] Geminilake HDMI codec 0x280d is similar to previous platforms, so add it with similar ops as previous. Signed-off-by: Senthilnathan Veppur Signed-off-by: Vinod Koul Signed-off-by: Takashi Iwai Signed-off-by: Sasha

[PATCH review for 4.9 17/50] f2fs: do not wait for writeback in write_begin

From: Jaegeuk Kim [ Upstream commit 86d54795c94532075d862aa0a79f0c981dab4bdd ] Otherwise we can get livelock like below. [79880.428136] dbench D0 18405 18404 0x [79880.428139] Call Trace: [79880.428142] __schedule+0x219/0x6b0 [79880.428144] schedule+0x36/0x80

[PATCH review for 4.9 18/50] md/linear: shutup lockdep warnning

From: Shaohua Li [ Upstream commit d939cdfde34f50b95254b375f498447c82190b3e ] Commit 03a9e24(md linear: fix a race between linear_add() and linear_congested()) introduces the warnning. Acked-by: Coly Li Signed-off-by: Shaohua Li Signed-off-by: Sasha Levin --- drivers/md/linear.c | 3 ++- 1

[PATCH review for 4.9 03/50] watchdog: kempld: fix gcc-4.3 build

From: Arnd Bergmann [ Upstream commit 3736d4eb6af37492aeded7fec0072dedd959c842 ] gcc-4.3 can't decide whether the constant value in kempld_prescaler[PRESCALER_21] is built-time constant or not, and gets confused by the logic in do_div(): drivers/watchdog/kempld_wdt.o: In

[PATCH review for 4.9 10/50] net/mlx4_en: fix overflow in mlx4_en_init_timestamp()

From: Eric Dumazet [ Upstream commit 47d3a07528ecbbccf53bc4390d70b4e3d1c04fcf ] The cited commit makes a great job of finding optimal shift/multiplier values assuming a 10 seconds wrap around, but forgot to change the overflow_period computation. It overflows in

[PATCH review for 4.9 04/50] irqchip/crossbar: Fix incorrect type of local variables

From: Franck Demathieu [ Upstream commit b28ace12661fbcfd90959c1e84ff5a85113a82a1 ] The max and entry variables are unsigned according to the dt-bindings. Fix following 3 sparse issues (-Wtypesign): drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in

[PATCH review for 4.9 02/50] locking/lockdep: Add nest_lock integrity test

From: Peter Zijlstra [ Upstream commit 7fb4a2cea6b18dab56d609530d077f168169ed6b ] Boqun reported that hlock->references can overflow. Add a debug test for that to generate a clear error when this happens. Without this, lockdep is likely to report a mysterious failure on

[PATCH review for 4.9 03/50] watchdog: kempld: fix gcc-4.3 build

From: Arnd Bergmann [ Upstream commit 3736d4eb6af37492aeded7fec0072dedd959c842 ] gcc-4.3 can't decide whether the constant value in kempld_prescaler[PRESCALER_21] is built-time constant or not, and gets confused by the logic in do_div(): drivers/watchdog/kempld_wdt.o: In function

[PATCH review for 4.9 10/50] net/mlx4_en: fix overflow in mlx4_en_init_timestamp()

From: Eric Dumazet [ Upstream commit 47d3a07528ecbbccf53bc4390d70b4e3d1c04fcf ] The cited commit makes a great job of finding optimal shift/multiplier values assuming a 10 seconds wrap around, but forgot to change the overflow_period computation. It overflows in cyclecounter_cyc2ns(), and the

[PATCH review for 4.9 04/50] irqchip/crossbar: Fix incorrect type of local variables

From: Franck Demathieu [ Upstream commit b28ace12661fbcfd90959c1e84ff5a85113a82a1 ] The max and entry variables are unsigned according to the dt-bindings. Fix following 3 sparse issues (-Wtypesign): drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in argument 3 (different

[PATCH review for 4.9 02/50] locking/lockdep: Add nest_lock integrity test

From: Peter Zijlstra [ Upstream commit 7fb4a2cea6b18dab56d609530d077f168169ed6b ] Boqun reported that hlock->references can overflow. Add a debug test for that to generate a clear error when this happens. Without this, lockdep is likely to report a mysterious failure on unlock. Reported-by:

[PATCH review for 4.9 05/50] initramfs: finish fput() before accessing any binary from initramfs

From: Lokesh Vutla [ Upstream commit 08865514805d2de8e7002fa8149c5de3e391f412 ] Commit 4a9d4b024a31 ("switch fput to task_work_add") implements a schedule_work() for completing fput(), but did not guarantee calling __fput() after unpacking initramfs. Because of this, there

[PATCH review for 4.9 12/50] netfilter: nf_ct_expect: Change __nf_ct_expect_check() return value.

From: Jarno Rajahalme [ Upstream commit 4b86c459c7bee3acaf92f0e2b4c6ac803eaa1a58 ] Commit 4dee62b1b9b4 ("netfilter: nf_ct_expect: nf_ct_expect_insert() returns void") inadvertently changed the successful return value of nf_ct_expect_related_report() from 0 to 1 due to

[PATCH review for 4.9 01/50] xen-netback: Use GFP_ATOMIC to allocate hash

From: Anoob Soman [ Upstream commit 9f674e48c13dcbc31ac903433727837795b81efe ] Allocation of new_hash, inside xenvif_new_hash(), always happen in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new hash allocation. Signed-off-by: Anoob Soman

[PATCH review for 4.9 06/50] mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length

From: Johannes Berg [ Upstream commit ff4dd73dd2b4806419f8ff65cbce11d5019548d0 ] Unfortunately, the nla policy was defined to have HWSIM_ATTR_RADIO_NAME as an NLA_STRING, rather than NLA_NUL_STRING, so we can't use it as a NUL-terminated string in the kernel. Rather

[PATCH review for 4.9 05/50] initramfs: finish fput() before accessing any binary from initramfs

From: Lokesh Vutla [ Upstream commit 08865514805d2de8e7002fa8149c5de3e391f412 ] Commit 4a9d4b024a31 ("switch fput to task_work_add") implements a schedule_work() for completing fput(), but did not guarantee calling __fput() after unpacking initramfs. Because of this, there is a possibility

[PATCH review for 4.9 12/50] netfilter: nf_ct_expect: Change __nf_ct_expect_check() return value.

From: Jarno Rajahalme [ Upstream commit 4b86c459c7bee3acaf92f0e2b4c6ac803eaa1a58 ] Commit 4dee62b1b9b4 ("netfilter: nf_ct_expect: nf_ct_expect_insert() returns void") inadvertently changed the successful return value of nf_ct_expect_related_report() from 0 to 1 due to __nf_ct_expect_check()

[PATCH review for 4.9 01/50] xen-netback: Use GFP_ATOMIC to allocate hash

From: Anoob Soman [ Upstream commit 9f674e48c13dcbc31ac903433727837795b81efe ] Allocation of new_hash, inside xenvif_new_hash(), always happen in softirq context, so use GFP_ATOMIC instead of GFP_KERNEL for new hash allocation. Signed-off-by: Anoob Soman Signed-off-by: David S. Miller

[PATCH review for 4.9 06/50] mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length

From: Johannes Berg [ Upstream commit ff4dd73dd2b4806419f8ff65cbce11d5019548d0 ] Unfortunately, the nla policy was defined to have HWSIM_ATTR_RADIO_NAME as an NLA_STRING, rather than NLA_NUL_STRING, so we can't use it as a NUL-terminated string in the kernel. Rather than break the API,

[PATCH review for 4.9 16/50] Btrfs: send, fix failure to rename top level inode due to name collision

From: Robbie Ko [ Upstream commit 4dd9920d991745c4a16f53a8f615f706fbe4b3f7 ] Under certain situations, an incremental send operation can fail due to a premature attempt to create a new top level inode (a direct child of the subvolume/snapshot root) whose name collides

[PATCH review for 4.9 32/50] i2c: at91: ensure state is restored after suspending

From: Alexandre Belloni [ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ] When going to suspend, the I2C registers may be lost because the power to VDDcore is cut. Restore them when resuming. Signed-off-by: Alexandre Belloni

[PATCH review for 4.9 33/50] ceph: don't update_dentry_lease unless we actually got one

From: Jeff Layton [ Upstream commit 80d025ffede88969f6adf7266fbdedfd5641148a ] This if block updates the dentry lease even in the case where the MDS didn't grant one. Signed-off-by: Jeff Layton Reviewed-by: Yan, Zheng Signed-off-by:

[PATCH review for 4.9 08/50] qed: Don't use attention PTT for configuring BW

From: "Mintz, Yuval" [ Upstream commit 6f437d431930ff86e4a971d29321951faadb97c7 ] Commit 653d2ffd6405 ("qed*: Fix link indication race") introduced another race - one of the inner functions called from the link-change flow is explicitly using the slowpath context

[PATCH review for 4.9 16/50] Btrfs: send, fix failure to rename top level inode due to name collision

From: Robbie Ko [ Upstream commit 4dd9920d991745c4a16f53a8f615f706fbe4b3f7 ] Under certain situations, an incremental send operation can fail due to a premature attempt to create a new top level inode (a direct child of the subvolume/snapshot root) whose name collides with another inode that

[PATCH review for 4.9 32/50] i2c: at91: ensure state is restored after suspending

From: Alexandre Belloni [ Upstream commit e3ccc921b7d8fd1fcd10a00720e09823d8078666 ] When going to suspend, the I2C registers may be lost because the power to VDDcore is cut. Restore them when resuming. Signed-off-by: Alexandre Belloni Acked-by: Ludovic Desroches Signed-off-by: Wolfram Sang

[PATCH review for 4.9 33/50] ceph: don't update_dentry_lease unless we actually got one

From: Jeff Layton [ Upstream commit 80d025ffede88969f6adf7266fbdedfd5641148a ] This if block updates the dentry lease even in the case where the MDS didn't grant one. Signed-off-by: Jeff Layton Reviewed-by: Yan, Zheng Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin ---

[PATCH review for 4.9 08/50] qed: Don't use attention PTT for configuring BW

From: "Mintz, Yuval" [ Upstream commit 6f437d431930ff86e4a971d29321951faadb97c7 ] Commit 653d2ffd6405 ("qed*: Fix link indication race") introduced another race - one of the inner functions called from the link-change flow is explicitly using the slowpath context dedicated PTT instead of

[PATCH review for 4.9 20/50] net/mlx4_core: Fix VF overwrite of module param which disables DMFS on new probed PFs

From: Majd Dibbiny [ Upstream commit 95f1ba9a24af9769f6e20dfe9a77c863f253f311 ] In the VF driver, module parameter mlx4_log_num_mgm_entry_size was mistakenly overwritten -- and in a manner which overrode the device-managed flow steering option encoded in the parameter.

[PATCH review for 4.9 42/50] hrtimer: Catch invalid clockids again

From: Marc Zyngier [ Upstream commit 336a9cde10d641e70bac67d90ae91b3190c3edca ] commit 82e88ff1ea94 ("hrtimer: Revert CLOCK_MONOTONIC_RAW support") removed unfortunately a sanity check in the hrtimer code which was part of that MONOTONIC_RAW patch series. It would have

[PATCH review for 4.9 20/50] net/mlx4_core: Fix VF overwrite of module param which disables DMFS on new probed PFs

From: Majd Dibbiny [ Upstream commit 95f1ba9a24af9769f6e20dfe9a77c863f253f311 ] In the VF driver, module parameter mlx4_log_num_mgm_entry_size was mistakenly overwritten -- and in a manner which overrode the device-managed flow steering option encoded in the parameter. log_num_mgm_entry_size

[PATCH review for 4.9 42/50] hrtimer: Catch invalid clockids again

From: Marc Zyngier [ Upstream commit 336a9cde10d641e70bac67d90ae91b3190c3edca ] commit 82e88ff1ea94 ("hrtimer: Revert CLOCK_MONOTONIC_RAW support") removed unfortunately a sanity check in the hrtimer code which was part of that MONOTONIC_RAW patch series. It would have caught the bogus usage

[PATCH review for 4.9 19/50] sparc64: Migrate hvcons irq to panicked cpu

From: Vijay Kumar [ Upstream commit 7dd4fcf5b70694dc961eb6b954673e4fc9730dbd ] On panic, all other CPUs are stopped except the one which had hit panic. To keep console alive, we need to migrate hvcons irq to panicked CPU. Signed-off-by: Vijay Kumar

[PATCH review for 4.9 19/50] sparc64: Migrate hvcons irq to panicked cpu

From: Vijay Kumar [ Upstream commit 7dd4fcf5b70694dc961eb6b954673e4fc9730dbd ] On panic, all other CPUs are stopped except the one which had hit panic. To keep console alive, we need to migrate hvcons irq to panicked CPU. Signed-off-by: Vijay Kumar Signed-off-by: David S. Miller

[PATCH review for 4.9 09/50] mac80211: fix power saving clients handling in iwlwifi

From: Emmanuel Grumbach [ Upstream commit d98937f4ea713d21e0fcc345919f86c877dd8d6f ] iwlwifi now supports RSS and can't let mac80211 track the PS state based on the Rx frames since they can come out of order. iwlwifi is now advertising AP_LINK_PS, and uses explicit

[PATCH review for 4.9 13/50] iio: adc: xilinx: Fix error handling

From: Christophe JAILLET [ Upstream commit ca1c39ef76376b67303d01f94fe98bb68bb3861a ] Reorder error handling labels in order to match the way resources have been allocated. Signed-off-by: Christophe JAILLET Acked-by: Lars-Peter

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