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
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:
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
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
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
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,
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:
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
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
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:
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
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
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
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
---
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
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
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
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 ++--
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 -
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
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 -
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
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 -
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
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
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
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
[
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
[
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
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
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
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
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
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
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
>> >
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
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
>> ---
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
>> ---
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
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
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,
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
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
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
>>
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
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
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
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
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
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
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
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
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
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 <
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
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
---
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
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
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
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 &&
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
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
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]
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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()
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
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,
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
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
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:
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
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
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
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
---
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
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.
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
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
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
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
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
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
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
801 - 900 of 1958 matches
Mail list logo