This is a note to let you know that I've just added the patch titled
media: ov13858: Select V4L2_FWNODE
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
media-ov13858-select-v4l2_fwnode.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Date: Sun, 5 Nov 2017 17:51:00 -0500
Subject: media: ov13858: Select V4L2_FWNODE
From: Sakari Ailus <sakari.ailus(a)linux.intel.com>
[ Upstream commit fce8ba670b7418319da14a6fc6668db1f1a96267 ]
The ov13858 driver depends on the V4L2 fwnode, thus add that to Kconfig.
Fixes: 5fcf092e0c9f ("[media] ov13858: add support for OV13858 sensor")
Signed-off-by: Sakari Ailus <sakari.ailus(a)linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/media/i2c/Kconfig | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -660,6 +660,7 @@ config VIDEO_OV13858
tristate "OmniVision OV13858 sensor support"
depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
depends on MEDIA_CAMERA_SUPPORT
+ select V4L2_FWNODE
---help---
This is a Video4Linux2 sensor-level driver for the OmniVision
OV13858 camera.
Patches currently in stable-queue which might be from sakari.ailus(a)linux.intel.com are
queue-4.14/media-ov13858-select-v4l2_fwnode.patch
This is a note to let you know that I've just added the patch titled
md/raid5: correct degraded calculation in raid5_error
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-raid5-correct-degraded-calculation-in-raid5_error.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: bingjingc <bingjingc(a)synology.com>
Date: Fri, 17 Nov 2017 10:57:44 +0800
Subject: md/raid5: correct degraded calculation in raid5_error
From: bingjingc <bingjingc(a)synology.com>
[ Upstream commit aff69d89bdebc39235cddb4445371eb979b49685 ]
When disk failure occurs on new disks for reshape, mddev->degraded
is not calculated correctly. Faulty bit of the failure device is not
set before raid5_calc_degraded(conf).
mdadm --create /dev/md0 --level=5 --raid-devices=3 /dev/loop[012]
mdadm /dev/md0 -a /dev/loop3
mdadm /dev/md0 --grow -n4
mdadm /dev/md0 -f /dev/loop3 # simulating disk failure
cat /sys/block/md0/md/degraded # it outputs 0, but it should be 1.
However, mdadm -D /dev/md0 will show that it is degraded. It's a bug.
It can be fixed by moving the resources raid5_calc_degraded() depends
on before it.
Reported-by: Roy Chung <roychung(a)synology.com>
Reviewed-by: Alex Wu <alexwu(a)synology.com>
Signed-off-by: BingJing Chang <bingjingc(a)synology.com>
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/raid5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/md/raid5.c
+++ b/drivers/md/raid5.c
@@ -2678,13 +2678,13 @@ static void raid5_error(struct mddev *md
pr_debug("raid456: error called\n");
spin_lock_irqsave(&conf->device_lock, flags);
+ set_bit(Faulty, &rdev->flags);
clear_bit(In_sync, &rdev->flags);
mddev->degraded = raid5_calc_degraded(conf);
spin_unlock_irqrestore(&conf->device_lock, flags);
set_bit(MD_RECOVERY_INTR, &mddev->recovery);
set_bit(Blocked, &rdev->flags);
- set_bit(Faulty, &rdev->flags);
set_mask_bits(&mddev->sb_flags, 0,
BIT(MD_SB_CHANGE_DEVS) | BIT(MD_SB_CHANGE_PENDING));
pr_crit("md/raid:%s: Disk failure on %s, disabling device.\n"
Patches currently in stable-queue which might be from bingjingc(a)synology.com are
queue-4.14/md-raid5-correct-degraded-calculation-in-raid5_error.patch
This is a note to let you know that I've just added the patch titled
md/raid1/10: add missed blk plug
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
md-raid1-10-add-missed-blk-plug.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Shaohua Li <shli(a)fb.com>
Date: Fri, 1 Dec 2017 12:12:34 -0800
Subject: md/raid1/10: add missed blk plug
From: Shaohua Li <shli(a)fb.com>
[ Upstream commit 18022a1bd3709b74ca31ef0b28fccd52bcd6c504 ]
flush_pending_writes isn't always called with block plug, so add it, and plug
works in nested way.
Signed-off-by: Shaohua Li <shli(a)fb.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/md/raid1.c | 4 ++++
drivers/md/raid10.c | 4 ++++
2 files changed, 8 insertions(+)
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -810,11 +810,15 @@ static void flush_pending_writes(struct
spin_lock_irq(&conf->device_lock);
if (conf->pending_bio_list.head) {
+ struct blk_plug plug;
struct bio *bio;
+
bio = bio_list_get(&conf->pending_bio_list);
conf->pending_count = 0;
spin_unlock_irq(&conf->device_lock);
+ blk_start_plug(&plug);
flush_bio_list(conf, bio);
+ blk_finish_plug(&plug);
} else
spin_unlock_irq(&conf->device_lock);
}
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -890,10 +890,13 @@ static void flush_pending_writes(struct
spin_lock_irq(&conf->device_lock);
if (conf->pending_bio_list.head) {
+ struct blk_plug plug;
struct bio *bio;
+
bio = bio_list_get(&conf->pending_bio_list);
conf->pending_count = 0;
spin_unlock_irq(&conf->device_lock);
+ blk_start_plug(&plug);
/* flush any pending bitmap writes to disk
* before proceeding w/ I/O */
bitmap_unplug(conf->mddev->bitmap);
@@ -914,6 +917,7 @@ static void flush_pending_writes(struct
generic_make_request(bio);
bio = next;
}
+ blk_finish_plug(&plug);
} else
spin_unlock_irq(&conf->device_lock);
}
Patches currently in stable-queue which might be from shli(a)fb.com are
queue-4.14/md-raid5-correct-degraded-calculation-in-raid5_error.patch
queue-4.14/md-raid1-10-add-missed-blk-plug.patch
This is a note to let you know that I've just added the patch titled
m68k: add missing SOFTIRQENTRY_TEXT linker section
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
m68k-add-missing-softirqentry_text-linker-section.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Greg Ungerer <gerg(a)linux-m68k.org>
Date: Tue, 14 Nov 2017 11:50:07 +1000
Subject: m68k: add missing SOFTIRQENTRY_TEXT linker section
From: Greg Ungerer <gerg(a)linux-m68k.org>
[ Upstream commit 969de0988b77e5a57aac2f7270191a3c50540c52 ]
Commit be7635e7287e ("arch, ftrace: for KASAN put hard/soft IRQ entries
into separate sections") added a new linker section, SOFTIRQENTRY_TEXT,
to the linker scripts for most architectures. It didn't add it to any of
the linker scripts for the m68k architecture. This was not really a problem
because it is only defined if either of CONFIG_FUNCTION_GRAPH_TRACER or
CONFIG_KASAN are enabled - which can never be true for m68k.
However commit 229a71860547 ("irq: Make the irqentry text section
unconditional") means that SOFTIRQENTRY_TEXT is now always defined. So on
m68k we now end up with a separate ELF section for .softirqentry.text
instead of it being part of the .text section. On some m68k targets in some
configurations this can also cause a fatal link error:
LD vmlinux
/usr/local/bin/../m68k-uclinux/bin/ld.real: section .softirqentry.text loaded at [0000000010de10c0,0000000010de12dd] overlaps section .rodata loaded at [0000000010de10c0,0000000010e0fd67]
To fix add in the missing SOFTIRQENTRY_TEXT section into the m68k linker
scripts. I noticed that m68k is also missing the IRQENTRY_TEXT section,
so this patch also adds an entry for that too.
Signed-off-by: Greg Ungerer <gerg(a)linux-m68k.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/m68k/kernel/vmlinux-nommu.lds | 2 ++
arch/m68k/kernel/vmlinux-std.lds | 2 ++
arch/m68k/kernel/vmlinux-sun3.lds | 2 ++
3 files changed, 6 insertions(+)
--- a/arch/m68k/kernel/vmlinux-nommu.lds
+++ b/arch/m68k/kernel/vmlinux-nommu.lds
@@ -45,6 +45,8 @@ SECTIONS {
.text : {
HEAD_TEXT
TEXT_TEXT
+ IRQENTRY_TEXT
+ SOFTIRQENTRY_TEXT
SCHED_TEXT
CPUIDLE_TEXT
LOCK_TEXT
--- a/arch/m68k/kernel/vmlinux-std.lds
+++ b/arch/m68k/kernel/vmlinux-std.lds
@@ -16,6 +16,8 @@ SECTIONS
.text : {
HEAD_TEXT
TEXT_TEXT
+ IRQENTRY_TEXT
+ SOFTIRQENTRY_TEXT
SCHED_TEXT
CPUIDLE_TEXT
LOCK_TEXT
--- a/arch/m68k/kernel/vmlinux-sun3.lds
+++ b/arch/m68k/kernel/vmlinux-sun3.lds
@@ -16,6 +16,8 @@ SECTIONS
.text : {
HEAD_TEXT
TEXT_TEXT
+ IRQENTRY_TEXT
+ SOFTIRQENTRY_TEXT
SCHED_TEXT
CPUIDLE_TEXT
LOCK_TEXT
Patches currently in stable-queue which might be from gerg(a)linux-m68k.org are
queue-4.14/m68k-add-missing-softirqentry_text-linker-section.patch
This is a note to let you know that I've just added the patch titled
locking/lockdep: Fix possible NULL deref
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
locking-lockdep-fix-possible-null-deref.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Peter Zijlstra <peterz(a)infradead.org>
Date: Wed, 6 Dec 2017 17:32:47 +0100
Subject: locking/lockdep: Fix possible NULL deref
From: Peter Zijlstra <peterz(a)infradead.org>
[ Upstream commit 5e351ad106997e06b2dc3da9c6b939b95f67fb88 ]
We can't invalidate xhlocks when we've not yet allocated any.
Reported-by: Dmitry Vyukov <dvyukov(a)google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-kernel(a)vger.kernel.org
Fixes: f52be5708076 ("locking/lockdep: Untangle xhlock history save/restore from task independence")
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
kernel/locking/lockdep.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4777,7 +4777,8 @@ void lockdep_invariant_state(bool force)
* Verify the former, enforce the latter.
*/
WARN_ON_ONCE(!force && current->lockdep_depth);
- invalidate_xhlock(&xhlock(current->xhlock_idx));
+ if (current->xhlocks)
+ invalidate_xhlock(&xhlock(current->xhlock_idx));
}
static int cross_lock(struct lockdep_map *lock)
Patches currently in stable-queue which might be from peterz(a)infradead.org are
queue-4.14/locking-lockdep-fix-possible-null-deref.patch
queue-4.14/mm-early_ioremap-fix-boot-hang-with-earlyprintk-efi-keep.patch
queue-4.14/perf-fix-header.size-for-namespace-events.patch
queue-4.14/perf-annotate-do-not-truncate-instruction-names-at-6-chars.patch
queue-4.14/x86-mm-kmmio-fix-mmiotrace-for-page-unaligned-addresses.patch
This is a note to let you know that I've just added the patch titled
KVM: VMX: fix page leak in hardware_setup()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-vmx-fix-page-leak-in-hardware_setup.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Jim Mattson <jmattson(a)google.com>
Date: Fri, 1 Dec 2017 09:57:56 -0800
Subject: KVM: VMX: fix page leak in hardware_setup()
From: Jim Mattson <jmattson(a)google.com>
[ Upstream commit 2895db67b01cb875457c9c3f30a14723b6b5dfd5 ]
vmx_io_bitmap_b should not be allocated twice.
Fixes: 23611332938d ("KVM: VMX: refactor setup of global page-sized bitmaps")
Signed-off-by: Jim Mattson <jmattson(a)google.com>
Reviewed-by: Krish Sadhukhan <krish.sadhukhan(a)oracle.com>
Reviewed-by: David Hildenbrand <david(a)redhat.com>
Signed-off-by: Radim Krčmář <rkrcmar(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kvm/vmx.c | 1 -
1 file changed, 1 deletion(-)
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -6950,7 +6950,6 @@ static __init int hardware_setup(void)
goto out;
}
- vmx_io_bitmap_b = (unsigned long *)__get_free_page(GFP_KERNEL);
memset(vmx_vmread_bitmap, 0xff, PAGE_SIZE);
memset(vmx_vmwrite_bitmap, 0xff, PAGE_SIZE);
Patches currently in stable-queue which might be from jmattson(a)google.com are
queue-4.14/kvm-x86-check-input-paging-mode-when-cs.l-is-set.patch
queue-4.14/kvm-vmx-fix-page-leak-in-hardware_setup.patch
This is a note to let you know that I've just added the patch titled
kvm: arm: don't treat unavailable HYP mode as an error
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-arm-don-t-treat-unavailable-hyp-mode-as-an-error.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Date: Tue, 28 Nov 2017 15:18:19 +0000
Subject: kvm: arm: don't treat unavailable HYP mode as an error
From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
[ Upstream commit 58d0d19a204604ca0da26058828a53558b265da3 ]
Since it is perfectly legal to run the kernel at EL1, it is not
actually an error if HYP mode is not available when attempting to
initialize KVM, given that KVM support cannot be built as a module.
So demote the kvm_err() to kvm_info(), which prevents the error from
appearing on an otherwise 'quiet' console.
Acked-by: Marc Zyngier <marc.zyngier(a)arm.com>
Acked-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
virt/kvm/arm/arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/virt/kvm/arm/arm.c
+++ b/virt/kvm/arm/arm.c
@@ -1453,7 +1453,7 @@ int kvm_arch_init(void *opaque)
bool in_hyp_mode;
if (!is_hyp_mode_available()) {
- kvm_err("HYP mode not available\n");
+ kvm_info("HYP mode not available\n");
return -ENODEV;
}
Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are
queue-4.14/kvm-arm-don-t-treat-unavailable-hyp-mode-as-an-error.patch
This is a note to let you know that I've just added the patch titled
KVM: arm/arm64: Fix spinlock acquisition in vgic_set_owner
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
kvm-arm-arm64-fix-spinlock-acquisition-in-vgic_set_owner.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Marc Zyngier <marc.zyngier(a)arm.com>
Date: Thu, 30 Nov 2017 17:00:30 +0000
Subject: KVM: arm/arm64: Fix spinlock acquisition in vgic_set_owner
From: Marc Zyngier <marc.zyngier(a)arm.com>
[ Upstream commit 7465894e90e5a47e0e52aa5f1f708653fc40020f ]
vgic_set_owner acquires the irq lock without disabling interrupts,
resulting in a lockdep splat (an interrupt could fire and result
in the same lock being taken if the same virtual irq is to be
injected).
In practice, it is almost impossible to trigger this bug, but
better safe than sorry. Convert the lock acquisition to a
spin_lock_irqsave() and keep lockdep happy.
Reported-by: James Morse <james.morse(a)arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
virt/kvm/arm/vgic/vgic.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -454,6 +454,7 @@ int kvm_vgic_unmap_phys_irq(struct kvm_v
int kvm_vgic_set_owner(struct kvm_vcpu *vcpu, unsigned int intid, void *owner)
{
struct vgic_irq *irq;
+ unsigned long flags;
int ret = 0;
if (!vgic_initialized(vcpu->kvm))
@@ -464,12 +465,12 @@ int kvm_vgic_set_owner(struct kvm_vcpu *
return -EINVAL;
irq = vgic_get_irq(vcpu->kvm, vcpu, intid);
- spin_lock(&irq->irq_lock);
+ spin_lock_irqsave(&irq->irq_lock, flags);
if (irq->owner && irq->owner != owner)
ret = -EEXIST;
else
irq->owner = owner;
- spin_unlock(&irq->irq_lock);
+ spin_unlock_irqrestore(&irq->irq_lock, flags);
return ret;
}
Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are
queue-4.14/arm-dts-fix-omap4-hang-with-gps-connected-to-usb-by-using-wakeupgen.patch
queue-4.14/kvm-arm-don-t-treat-unavailable-hyp-mode-as-an-error.patch
queue-4.14/kvm-arm-arm64-fix-spinlock-acquisition-in-vgic_set_owner.patch
This is a note to let you know that I've just added the patch titled
ipvlan: Add the skb->mark as flow4's member to lookup route
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ipvlan-add-the-skb-mark-as-flow4-s-member-to-lookup-route.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Gao Feng <gfree.wind(a)vip.163.com>
Date: Fri, 1 Dec 2017 09:58:42 +0800
Subject: ipvlan: Add the skb->mark as flow4's member to lookup route
From: Gao Feng <gfree.wind(a)vip.163.com>
[ Upstream commit a98a4ebc8c61d20f0150d6be66e0e65223a347af ]
Current codes don't use skb->mark to assign flowi4_mark, it would
make the policy route rule with fwmark doesn't work as expected.
Signed-off-by: Gao Feng <gfree.wind(a)vip.163.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ipvlan/ipvlan_core.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/net/ipvlan/ipvlan_core.c
+++ b/drivers/net/ipvlan/ipvlan_core.c
@@ -375,6 +375,7 @@ static int ipvlan_process_v4_outbound(st
.flowi4_oif = dev->ifindex,
.flowi4_tos = RT_TOS(ip4h->tos),
.flowi4_flags = FLOWI_FLAG_ANYSRC,
+ .flowi4_mark = skb->mark,
.daddr = ip4h->daddr,
.saddr = ip4h->saddr,
};
Patches currently in stable-queue which might be from gfree.wind(a)vip.163.com are
queue-4.14/ipvlan-add-the-skb-mark-as-flow4-s-member-to-lookup-route.patch
This is a note to let you know that I've just added the patch titled
iio: proximity: sx9500: Assign interrupt from GpioIo()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-proximity-sx9500-assign-interrupt-from-gpioio.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Date: Fri, 3 Nov 2017 15:03:36 +0200
Subject: iio: proximity: sx9500: Assign interrupt from GpioIo()
From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
[ Upstream commit e53111ad5deaef98d8c18a9933ef1f5624c5979d ]
The commit 0f0796509c07
("iio: remove gpio interrupt probing from drivers that use a single interrupt")
removed custom IRQ assignment for the drivers which are enumerated via
ACPI or OF. Unfortunately, some ACPI tables have IRQ line defined as
GpioIo() resource and thus automatic IRQ allocation will fail.
Partially revert the commit 0f0796509c07 to restore original behaviour.
Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg(a)linux.intel.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/proximity/sx9500.c | 9 +++++++++
1 file changed, 9 insertions(+)
--- a/drivers/iio/proximity/sx9500.c
+++ b/drivers/iio/proximity/sx9500.c
@@ -871,6 +871,7 @@ static int sx9500_init_device(struct iio
static void sx9500_gpio_probe(struct i2c_client *client,
struct sx9500_data *data)
{
+ struct gpio_desc *gpiod_int;
struct device *dev;
if (!client)
@@ -878,6 +879,14 @@ static void sx9500_gpio_probe(struct i2c
dev = &client->dev;
+ if (client->irq <= 0) {
+ gpiod_int = devm_gpiod_get(dev, SX9500_GPIO_INT, GPIOD_IN);
+ if (IS_ERR(gpiod_int))
+ dev_err(dev, "gpio get irq failed\n");
+ else
+ client->irq = gpiod_to_irq(gpiod_int);
+ }
+
data->gpiod_rst = devm_gpiod_get(dev, SX9500_GPIO_RESET, GPIOD_OUT_HIGH);
if (IS_ERR(data->gpiod_rst)) {
dev_warn(dev, "gpio get reset pin failed\n");
Patches currently in stable-queue which might be from andriy.shevchenko(a)linux.intel.com are
queue-4.14/pinctrl-denverton-fix-uart2-rts-pin-mode.patch
queue-4.14/iio-proximity-sx9500-assign-interrupt-from-gpioio.patch
queue-4.14/brcmfmac-avoid-build-error-with-make-w-1.patch
This is a note to let you know that I've just added the patch titled
iio: fix kernel-doc build errors
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-fix-kernel-doc-build-errors.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Randy Dunlap <rdunlap(a)infradead.org>
Date: Sun, 29 Oct 2017 17:06:01 -0700
Subject: iio: fix kernel-doc build errors
From: Randy Dunlap <rdunlap(a)infradead.org>
[ Upstream commit c175cb7cd953782bbf4e8bdf088ad61440d6dde5 ]
Fix build errors in kernel-doc notation. Symbols that end in '_'
have a special meaning, but adding a '*' makes them OK.
../drivers/iio/industrialio-core.c:635: ERROR: Unknown target name: "iio_val".
../drivers/iio/industrialio-core.c:642: ERROR: Unknown target name: "iio_val".
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/industrialio-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/iio/industrialio-core.c
+++ b/drivers/iio/industrialio-core.c
@@ -631,7 +631,7 @@ static ssize_t __iio_format_value(char *
* iio_format_value() - Formats a IIO value into its string representation
* @buf: The buffer to which the formatted value gets written
* which is assumed to be big enough (i.e. PAGE_SIZE).
- * @type: One of the IIO_VAL_... constants. This decides how the val
+ * @type: One of the IIO_VAL_* constants. This decides how the val
* and val2 parameters are formatted.
* @size: Number of IIO value entries contained in vals
* @vals: Pointer to the values, exact meaning depends on the
@@ -639,7 +639,7 @@ static ssize_t __iio_format_value(char *
*
* Return: 0 by default, a negative number on failure or the
* total number of characters written for a type that belongs
- * to the IIO_VAL_... constant.
+ * to the IIO_VAL_* constant.
*/
ssize_t iio_format_value(char *buf, unsigned int type, int size, int *vals)
{
Patches currently in stable-queue which might be from rdunlap(a)infradead.org are
queue-4.14/usb-build-drivers-usb-common-when-usb_support-is-set.patch
queue-4.14/iio-fix-kernel-doc-build-errors.patch
This is a note to let you know that I've just added the patch titled
IB/mlx4: Fix RSS hash fields restrictions
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-mlx4-fix-rss-hash-fields-restrictions.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Guy Levi <guyle(a)mellanox.com>
Date: Tue, 5 Dec 2017 22:30:03 +0200
Subject: IB/mlx4: Fix RSS hash fields restrictions
From: Guy Levi <guyle(a)mellanox.com>
[ Upstream commit 4d02ebd9bbbdde1d524e62b540b0402cee7bbcdf ]
Mistakenly the driver didn't allow RSS hash fields combinations which
involve both IPv4 and IPv6 protocols. This bug caused to failures for
user's use cases for RSS.
Consequently, this patch fixes this bug and allows any combination that
the HW can support.
Additionally, the patch fixes the driver to return an error in case the
user provides an unsupported mask for RSS hash fields.
Fixes: 3078f5f1bd8b ("IB/mlx4: Add support for RSS QP")
Signed-off-by: Guy Levi <guyle(a)mellanox.com>
Reviewed-by: Yishai Hadas <yishaih(a)mellanox.com>
Signed-off-by: Leon Romanovsky <leon(a)kernel.org>
Signed-off-by: Doug Ledford <dledford(a)redhat.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/mlx4/qp.c | 26 +++++++++++++++++++-------
1 file changed, 19 insertions(+), 7 deletions(-)
--- a/drivers/infiniband/hw/mlx4/qp.c
+++ b/drivers/infiniband/hw/mlx4/qp.c
@@ -666,6 +666,19 @@ static int set_qp_rss(struct mlx4_ib_dev
return (-EOPNOTSUPP);
}
+ if (ucmd->rx_hash_fields_mask & ~(MLX4_IB_RX_HASH_SRC_IPV4 |
+ MLX4_IB_RX_HASH_DST_IPV4 |
+ MLX4_IB_RX_HASH_SRC_IPV6 |
+ MLX4_IB_RX_HASH_DST_IPV6 |
+ MLX4_IB_RX_HASH_SRC_PORT_TCP |
+ MLX4_IB_RX_HASH_DST_PORT_TCP |
+ MLX4_IB_RX_HASH_SRC_PORT_UDP |
+ MLX4_IB_RX_HASH_DST_PORT_UDP)) {
+ pr_debug("RX Hash fields_mask has unsupported mask (0x%llx)\n",
+ ucmd->rx_hash_fields_mask);
+ return (-EOPNOTSUPP);
+ }
+
if ((ucmd->rx_hash_fields_mask & MLX4_IB_RX_HASH_SRC_IPV4) &&
(ucmd->rx_hash_fields_mask & MLX4_IB_RX_HASH_DST_IPV4)) {
rss_ctx->flags = MLX4_RSS_IPV4;
@@ -691,11 +704,11 @@ static int set_qp_rss(struct mlx4_ib_dev
return (-EOPNOTSUPP);
}
- if (rss_ctx->flags & MLX4_RSS_IPV4) {
+ if (rss_ctx->flags & MLX4_RSS_IPV4)
rss_ctx->flags |= MLX4_RSS_UDP_IPV4;
- } else if (rss_ctx->flags & MLX4_RSS_IPV6) {
+ if (rss_ctx->flags & MLX4_RSS_IPV6)
rss_ctx->flags |= MLX4_RSS_UDP_IPV6;
- } else {
+ if (!(rss_ctx->flags & (MLX4_RSS_IPV6 | MLX4_RSS_IPV4))) {
pr_debug("RX Hash fields_mask is not supported - UDP must be set with IPv4 or IPv6\n");
return (-EOPNOTSUPP);
}
@@ -707,15 +720,14 @@ static int set_qp_rss(struct mlx4_ib_dev
if ((ucmd->rx_hash_fields_mask & MLX4_IB_RX_HASH_SRC_PORT_TCP) &&
(ucmd->rx_hash_fields_mask & MLX4_IB_RX_HASH_DST_PORT_TCP)) {
- if (rss_ctx->flags & MLX4_RSS_IPV4) {
+ if (rss_ctx->flags & MLX4_RSS_IPV4)
rss_ctx->flags |= MLX4_RSS_TCP_IPV4;
- } else if (rss_ctx->flags & MLX4_RSS_IPV6) {
+ if (rss_ctx->flags & MLX4_RSS_IPV6)
rss_ctx->flags |= MLX4_RSS_TCP_IPV6;
- } else {
+ if (!(rss_ctx->flags & (MLX4_RSS_IPV6 | MLX4_RSS_IPV4))) {
pr_debug("RX Hash fields_mask is not supported - TCP must be set with IPv4 or IPv6\n");
return (-EOPNOTSUPP);
}
-
} else if ((ucmd->rx_hash_fields_mask & MLX4_IB_RX_HASH_SRC_PORT_TCP) ||
(ucmd->rx_hash_fields_mask & MLX4_IB_RX_HASH_DST_PORT_TCP)) {
pr_debug("RX Hash fields_mask is not supported - both TCP SRC and DST must be set\n");
Patches currently in stable-queue which might be from guyle(a)mellanox.com are
queue-4.14/ib-mlx4-fix-rss-hash-fields-restrictions.patch
This is a note to let you know that I've just added the patch titled
IB/hfi1: Initialize bth1 in 16B rc ack builder
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-hfi1-initialize-bth1-in-16b-rc-ack-builder.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Date: Tue, 14 Nov 2017 04:34:23 -0800
Subject: IB/hfi1: Initialize bth1 in 16B rc ack builder
From: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
[ Upstream commit 8935780b9f7bbad0f2eb5dd43f61ba7b509a1575 ]
It is possible the bth1 variable could be used uninitialized so going
ahead and giving it a default value.
Otherwise we leak stack memory to the network.
Fixes: 5b6cabb0db77 ("IB/hfi1: Add 16B RC/UC support")
Reviewed-by: Don Hiatt <don.hiatt(a)intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/hfi1/rc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/hfi1/rc.c
+++ b/drivers/infiniband/hw/hfi1/rc.c
@@ -815,7 +815,7 @@ static inline void hfi1_make_rc_ack_16B(
struct hfi1_pportdata *ppd = ppd_from_ibp(ibp);
struct hfi1_16b_header *hdr = &opa_hdr->opah;
struct ib_other_headers *ohdr;
- u32 bth0, bth1;
+ u32 bth0, bth1 = 0;
u16 len, pkey;
u8 becn = !!is_fecn;
u8 l4 = OPA_16B_L4_IB_LOCAL;
Patches currently in stable-queue which might be from dennis.dalessandro(a)intel.com are
queue-4.14/ib-hfi1-initialize-bth1-in-16b-rc-ack-builder.patch
This is a note to let you know that I've just added the patch titled
IB/core: Init subsys if compiled to vmlinuz-core
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
ib-core-init-subsys-if-compiled-to-vmlinuz-core.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Dmitry Monakhov <dmonakhov(a)openvz.org>
Date: Mon, 27 Nov 2017 13:39:05 +0000
Subject: IB/core: Init subsys if compiled to vmlinuz-core
From: Dmitry Monakhov <dmonakhov(a)openvz.org>
[ Upstream commit a9cd1a673737dd81332fce1145801bfacfb90d90 ]
Once infiniband is compiled as a core component its subsystem must be
enabled before device initialization. Otherwise there is a NULL pointer
dereference during mlx4_core init, calltrace:
->device_add
if (dev->class) {
deref dev->class->p =>NULLPTR
#Config
CONFIG_NET_DEVLINK=y
CONFIG_MAY_USE_DEVLINK=y
CONFIG_MLX4_EN=y
Signed-off-by: Dmitry Monakhov <dmonakhov(a)openvz.org>
Reviewed-by: Leon Romanovsky <leonro(a)mellanox.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/core/device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/core/device.c
+++ b/drivers/infiniband/core/device.c
@@ -1261,5 +1261,5 @@ static void __exit ib_core_cleanup(void)
MODULE_ALIAS_RDMA_NETLINK(RDMA_NL_LS, 4);
-module_init(ib_core_init);
+subsys_initcall(ib_core_init);
module_exit(ib_core_cleanup);
Patches currently in stable-queue which might be from dmonakhov(a)openvz.org are
queue-4.14/ib-core-init-subsys-if-compiled-to-vmlinuz-core.patch
This is a note to let you know that I've just added the patch titled
i40iw: Do not free sqbuf when event is I40IW_TIMER_TYPE_CLOSE
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40iw-do-not-free-sqbuf-when-event-is-i40iw_timer_type_close.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Mustafa Ismail <mustafa.ismail(a)intel.com>
Date: Tue, 21 Nov 2017 16:18:31 -0600
Subject: i40iw: Do not free sqbuf when event is I40IW_TIMER_TYPE_CLOSE
From: Mustafa Ismail <mustafa.ismail(a)intel.com>
[ Upstream commit 10499986dbd8778e1acf9f9d2e166800dfee44b4 ]
When the event type is I40IW_TIMER_TYPE_CLOSE, there is no sqbuf and
it should not be freed as one in i40iw_schedule_cm_timer().
Fixes: f27b4746f378 ("i40iw: add connection management code")
Signed-off-by: Mustafa Ismail <mustafa.ismail(a)intel.com>
Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/i40iw/i40iw_cm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/infiniband/hw/i40iw/i40iw_cm.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_cm.c
@@ -1043,7 +1043,7 @@ negotiate_done:
* i40iw_schedule_cm_timer
* @@cm_node: connection's node
* @sqbuf: buffer to send
- * @type: if it es send ot close
+ * @type: if it is send or close
* @send_retrans: if rexmits to be done
* @close_when_complete: is cm_node to be removed
*
@@ -1067,7 +1067,8 @@ int i40iw_schedule_cm_timer(struct i40iw
new_send = kzalloc(sizeof(*new_send), GFP_ATOMIC);
if (!new_send) {
- i40iw_free_sqbuf(vsi, (void *)sqbuf);
+ if (type != I40IW_TIMER_TYPE_CLOSE)
+ i40iw_free_sqbuf(vsi, (void *)sqbuf);
return -ENOMEM;
}
new_send->retrycount = I40IW_DEFAULT_RETRYS;
@@ -1082,7 +1083,6 @@ int i40iw_schedule_cm_timer(struct i40iw
new_send->timetosend += (HZ / 10);
if (cm_node->close_entry) {
kfree(new_send);
- i40iw_free_sqbuf(vsi, (void *)sqbuf);
i40iw_pr_err("already close entry\n");
return -EINVAL;
}
Patches currently in stable-queue which might be from mustafa.ismail(a)intel.com are
queue-4.14/i40iw-correct-arp-index-mask.patch
queue-4.14/i40iw-do-not-free-sqbuf-when-event-is-i40iw_timer_type_close.patch
This is a note to let you know that I've just added the patch titled
i40iw: Correct ARP index mask
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40iw-correct-arp-index-mask.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Mustafa Ismail <mustafa.ismail(a)intel.com>
Date: Tue, 21 Nov 2017 16:18:32 -0600
Subject: i40iw: Correct ARP index mask
From: Mustafa Ismail <mustafa.ismail(a)intel.com>
[ Upstream commit a283cdc4d3670700182c820b59078387f9a01a30 ]
The ARP table entry indexes are aliased to 12bits
instead of the intended 16bits when uploaded to
the QP Context. This will present an issue when the
number of connections exceeds 4096 as ARP entries are
reused. Fix this by adjusting the mask to account for
the full 16bits.
Fixes: 4e9042e647ff ("i40iw: add hw and utils files")
Signed-off-by: Mustafa Ismail <mustafa.ismail(a)intel.com>
Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/i40iw/i40iw_d.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/infiniband/hw/i40iw/i40iw_d.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_d.h
@@ -1109,7 +1109,7 @@
#define I40IWQPC_VLANTAG_MASK (0xffffULL << I40IWQPC_VLANTAG_SHIFT)
#define I40IWQPC_ARPIDX_SHIFT 48
-#define I40IWQPC_ARPIDX_MASK (0xfffULL << I40IWQPC_ARPIDX_SHIFT)
+#define I40IWQPC_ARPIDX_MASK (0xffffULL << I40IWQPC_ARPIDX_SHIFT)
#define I40IWQPC_FLOWLABEL_SHIFT 0
#define I40IWQPC_FLOWLABEL_MASK (0xfffffUL << I40IWQPC_FLOWLABEL_SHIFT)
Patches currently in stable-queue which might be from mustafa.ismail(a)intel.com are
queue-4.14/i40iw-correct-arp-index-mask.patch
queue-4.14/i40iw-do-not-free-sqbuf-when-event-is-i40iw_timer_type_close.patch
This is a note to let you know that I've just added the patch titled
i40iw: Allocate a sdbuf per CQP WQE
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
i40iw-allocate-a-sdbuf-per-cqp-wqe.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Chien Tin Tung <chien.tin.tung(a)intel.com>
Date: Tue, 21 Nov 2017 16:18:30 -0600
Subject: i40iw: Allocate a sdbuf per CQP WQE
From: Chien Tin Tung <chien.tin.tung(a)intel.com>
[ Upstream commit 100d6de2ced538c539d923dc14a1b5cbae234503 ]
Currently there is only one sdbuf per Control QP (CQP) for
programming Segment Descriptor (SD). If multiple SD work
requests are posted simultaneously, the sdbuf is reused
by all WQEs and new WQEs can corrupt previous WQEs sdbuf
leading to incorrect SD programming.
Fix this by allocating one sdbuf per CQP SQ WQE. When an
SD command is posted, it will use the corresponding sdbuf
for the WQE.
Fixes: 86dbcd0f12e9 ("i40iw: add file to handle cqp calls")
Signed-off-by: Chien Tin Tung <chien.tin.tung(a)intel.com>
Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com>
Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 43 +++++++++++++++++++++----------
drivers/infiniband/hw/i40iw/i40iw_d.h | 4 ++
2 files changed, 33 insertions(+), 14 deletions(-)
--- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
@@ -506,7 +506,7 @@ static enum i40iw_status_code i40iw_sc_c
ret_code = i40iw_allocate_dma_mem(cqp->dev->hw,
&cqp->sdbuf,
- 128,
+ I40IW_UPDATE_SD_BUF_SIZE * cqp->sq_size,
I40IW_SD_BUF_ALIGNMENT);
if (ret_code)
@@ -589,14 +589,15 @@ void i40iw_sc_cqp_post_sq(struct i40iw_s
}
/**
- * i40iw_sc_cqp_get_next_send_wqe - get next wqe on cqp sq
- * @cqp: struct for cqp hw
- * @wqe_idx: we index of cqp ring
+ * i40iw_sc_cqp_get_next_send_wqe_idx - get next WQE on CQP SQ and pass back the index
+ * @cqp: pointer to CQP structure
+ * @scratch: private data for CQP WQE
+ * @wqe_idx: WQE index for next WQE on CQP SQ
*/
-u64 *i40iw_sc_cqp_get_next_send_wqe(struct i40iw_sc_cqp *cqp, u64 scratch)
+static u64 *i40iw_sc_cqp_get_next_send_wqe_idx(struct i40iw_sc_cqp *cqp,
+ u64 scratch, u32 *wqe_idx)
{
u64 *wqe = NULL;
- u32 wqe_idx;
enum i40iw_status_code ret_code;
if (I40IW_RING_FULL_ERR(cqp->sq_ring)) {
@@ -609,21 +610,33 @@ u64 *i40iw_sc_cqp_get_next_send_wqe(stru
cqp->sq_ring.size);
return NULL;
}
- I40IW_ATOMIC_RING_MOVE_HEAD(cqp->sq_ring, wqe_idx, ret_code);
+ I40IW_ATOMIC_RING_MOVE_HEAD(cqp->sq_ring, *wqe_idx, ret_code);
cqp->dev->cqp_cmd_stats[OP_REQUESTED_COMMANDS]++;
if (ret_code)
return NULL;
- if (!wqe_idx)
+ if (!*wqe_idx)
cqp->polarity = !cqp->polarity;
- wqe = cqp->sq_base[wqe_idx].elem;
- cqp->scratch_array[wqe_idx] = scratch;
+ wqe = cqp->sq_base[*wqe_idx].elem;
+ cqp->scratch_array[*wqe_idx] = scratch;
I40IW_CQP_INIT_WQE(wqe);
return wqe;
}
/**
+ * i40iw_sc_cqp_get_next_send_wqe - get next wqe on cqp sq
+ * @cqp: struct for cqp hw
+ * @scratch: private data for CQP WQE
+ */
+u64 *i40iw_sc_cqp_get_next_send_wqe(struct i40iw_sc_cqp *cqp, u64 scratch)
+{
+ u32 wqe_idx;
+
+ return i40iw_sc_cqp_get_next_send_wqe_idx(cqp, scratch, &wqe_idx);
+}
+
+/**
* i40iw_sc_cqp_destroy - destroy cqp during close
* @cqp: struct for cqp hw
*/
@@ -3534,8 +3547,10 @@ static enum i40iw_status_code cqp_sds_wq
u64 *wqe;
int mem_entries, wqe_entries;
struct i40iw_dma_mem *sdbuf = &cqp->sdbuf;
+ u64 offset;
+ u32 wqe_idx;
- wqe = i40iw_sc_cqp_get_next_send_wqe(cqp, scratch);
+ wqe = i40iw_sc_cqp_get_next_send_wqe_idx(cqp, scratch, &wqe_idx);
if (!wqe)
return I40IW_ERR_RING_FULL;
@@ -3548,8 +3563,10 @@ static enum i40iw_status_code cqp_sds_wq
LS_64(mem_entries, I40IW_CQPSQ_UPESD_ENTRY_COUNT);
if (mem_entries) {
- memcpy(sdbuf->va, &info->entry[3], (mem_entries << 4));
- data = sdbuf->pa;
+ offset = wqe_idx * I40IW_UPDATE_SD_BUF_SIZE;
+ memcpy((char *)sdbuf->va + offset, &info->entry[3],
+ mem_entries << 4);
+ data = (u64)sdbuf->pa + offset;
} else {
data = 0;
}
--- a/drivers/infiniband/hw/i40iw/i40iw_d.h
+++ b/drivers/infiniband/hw/i40iw/i40iw_d.h
@@ -1516,7 +1516,7 @@ enum i40iw_alignment {
I40IW_AEQ_ALIGNMENT = 0x100,
I40IW_CEQ_ALIGNMENT = 0x100,
I40IW_CQ0_ALIGNMENT = 0x100,
- I40IW_SD_BUF_ALIGNMENT = 0x100
+ I40IW_SD_BUF_ALIGNMENT = 0x80
};
#define I40IW_WQE_SIZE_64 64
@@ -1524,6 +1524,8 @@ enum i40iw_alignment {
#define I40IW_QP_WQE_MIN_SIZE 32
#define I40IW_QP_WQE_MAX_SIZE 128
+#define I40IW_UPDATE_SD_BUF_SIZE 128
+
#define I40IW_CQE_QTYPE_RQ 0
#define I40IW_CQE_QTYPE_SQ 1
Patches currently in stable-queue which might be from chien.tin.tung(a)intel.com are
queue-4.14/i40iw-allocate-a-sdbuf-per-cqp-wqe.patch
This is a note to let you know that I've just added the patch titled
hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hippi-fix-a-fix-a-possible-sleep-in-atomic-bug-in-rr_close.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Jia-Ju Bai <baijiaju1990(a)163.com>
Date: Tue, 12 Dec 2017 16:49:52 +0800
Subject: hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
From: Jia-Ju Bai <baijiaju1990(a)163.com>
[ Upstream commit 6e266610eb6553cfb7e7eb5d11914bd01509c406 ]
The driver may sleep under a spinlock.
The function call path is:
rr_close (acquire the spinlock)
free_irq --> may sleep
To fix it, free_irq is moved to the place without holding the spinlock.
This bug is found by my static analysis tool(DSAC) and checked by my code review.
Signed-off-by: Jia-Ju Bai <baijiaju1990(a)163.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/hippi/rrunner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -1381,8 +1381,8 @@ static int rr_close(struct net_device *d
rrpriv->info_dma);
rrpriv->info = NULL;
- free_irq(pdev->irq, dev);
spin_unlock_irqrestore(&rrpriv->lock, flags);
+ free_irq(pdev->irq, dev);
return 0;
}
Patches currently in stable-queue which might be from baijiaju1990(a)163.com are
queue-4.14/hippi-fix-a-fix-a-possible-sleep-in-atomic-bug-in-rr_close.patch
This is a note to let you know that I've just added the patch titled
gpio: davinci: Assign first bank regs for unbanked case
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
gpio-davinci-assign-first-bank-regs-for-unbanked-case.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Keerthy <j-keerthy(a)ti.com>
Date: Fri, 10 Nov 2017 16:43:17 +0530
Subject: gpio: davinci: Assign first bank regs for unbanked case
From: Keerthy <j-keerthy(a)ti.com>
[ Upstream commit 7f8e2a85c1b0bd440ffe87be82c79fdc319e8291 ]
As per the re-design assign the first bank regs for unbanked
irq case. This was missed out in the original patch.
Signed-off-by: Keerthy <j-keerthy(a)ti.com>
Fixes: b5cf3fd827d2e1 ("gpio: davinci: Redesign driver to accommodate ngpios in one gpio chip")
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-davinci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -383,7 +383,7 @@ static int gpio_irq_type_unbanked(struct
u32 mask;
d = (struct davinci_gpio_controller *)irq_data_get_irq_handler_data(data);
- g = (struct davinci_gpio_regs __iomem *)d->regs;
+ g = (struct davinci_gpio_regs __iomem *)d->regs[0];
mask = __gpio_mask(data->irq - d->base_irq);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
Patches currently in stable-queue which might be from j-keerthy(a)ti.com are
queue-4.14/gpio-davinci-assign-first-bank-regs-for-unbanked-case.patch
queue-4.14/arm-am33xx-prm-remove-am33xx_pwrdm_read_prev_pwrst-function.patch
This is a note to let you know that I've just added the patch titled
gpio: 74x164: Fix crash during .remove()
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
gpio-74x164-fix-crash-during-.remove.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
Date: Tue, 21 Nov 2017 15:18:10 +0100
Subject: gpio: 74x164: Fix crash during .remove()
From: Geert Uytterhoeven <geert+renesas(a)glider.be>
[ Upstream commit a158531f3c92467df0e93e000d58185acae78a6e ]
Commit 7ebc194d0fd4bb0f ("gpio: 74x164: Introduce 'enable-gpios'
property") added a new member gpiod_oe to the end of the struct
gen_74x164_chip, after the zero-length buffer array.
However, this buffer is a flexible array, allocated together with the
structure during .probe(). As the buffer is no longer the last member,
writing to it corrupts the newly added member after it.
During device removal, the corrupted member will be used as a pointer,
leading to a crash.
This went unnoticed, as the flexible array was declared as "buffer[0]"
instead of "buffer[]", and thus did not trigger a "flexible array member
not at end of struct" error from gcc.
Move the gpiod_oe field up to fix this, and drop the zero from the array
size to prevent future similar bugs.
Fixes: 7ebc194d0fd4bb0f ("gpio: 74x164: Introduce 'enable-gpios' property")
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
Reviewed-by: Fabio Estevam <fabio.estevam(a)nxp.com>
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpio/gpio-74x164.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/gpio/gpio-74x164.c
+++ b/drivers/gpio/gpio-74x164.c
@@ -23,6 +23,7 @@
struct gen_74x164_chip {
struct gpio_chip gpio_chip;
struct mutex lock;
+ struct gpio_desc *gpiod_oe;
u32 registers;
/*
* Since the registers are chained, every byte sent will make
@@ -31,8 +32,7 @@ struct gen_74x164_chip {
* register at the end of the transfer. So, to have a logical
* numbering, store the bytes in reverse order.
*/
- u8 buffer[0];
- struct gpio_desc *gpiod_oe;
+ u8 buffer[];
};
static int __gen_74x164_write_config(struct gen_74x164_chip *chip)
Patches currently in stable-queue which might be from geert+renesas(a)glider.be are
queue-4.14/gpio-74x164-fix-crash-during-.remove.patch
queue-4.14/pci-rcar-fix-use-after-free-in-probe-error-path.patch
This is a note to let you know that I've just added the patch titled
gianfar: fix a flooded alignment reports because of padding issue.
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
gianfar-fix-a-flooded-alignment-reports-because-of-padding-issue.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Zumeng Chen <zumeng.chen(a)gmail.com>
Date: Mon, 4 Dec 2017 11:22:02 +0800
Subject: gianfar: fix a flooded alignment reports because of padding issue.
From: Zumeng Chen <zumeng.chen(a)gmail.com>
[ Upstream commit 58117672943734715bbe7565ac9f062effa524f0 ]
According to LS1021A RM, the value of PAL can be set so that the start of the
IP header in the receive data buffer is aligned to a 32-bit boundary. Normally,
setting PAL = 2 provides minimal padding to ensure such alignment of the IP
header.
However every incoming packet's 8-byte time stamp will be inserted into the
packet data buffer as padding alignment bytes when hardware time stamping is
enabled.
So we set the padding 8+2 here to avoid the flooded alignment faults:
root@128:~# cat /proc/cpu/alignment
User: 0
System: 17539 (inet_gro_receive+0x114/0x2c0)
Skipped: 0
Half: 0
Word: 0
DWord: 0
Multi: 17539
User faults: 2 (fixup)
Also shown when exception report enablement
CPU: 0 PID: 161 Comm: irq/66-eth1_g0_ Not tainted 4.1.21-rt13-WR8.0.0.0_preempt-rt #16
Hardware name: Freescale LS1021A
[<8001b420>] (unwind_backtrace) from [<8001476c>] (show_stack+0x20/0x24)
[<8001476c>] (show_stack) from [<807cfb48>] (dump_stack+0x94/0xac)
[<807cfb48>] (dump_stack) from [<80025d70>] (do_alignment+0x720/0x958)
[<80025d70>] (do_alignment) from [<80009224>] (do_DataAbort+0x40/0xbc)
[<80009224>] (do_DataAbort) from [<80015398>] (__dabt_svc+0x38/0x60)
Exception stack(0x86ad1cc0 to 0x86ad1d08)
1cc0: f9b3e080 86b3d072 2d78d287 00000000 866816c0 86b3d05e 86e785d0 00000000
1ce0: 00000011 0000000e 80840ab0 86ad1d3c 86ad1d08 86ad1d08 806d7fc0 806d806c
1d00: 40070013 ffffffff
[<80015398>] (__dabt_svc) from [<806d806c>] (inet_gro_receive+0x114/0x2c0)
[<806d806c>] (inet_gro_receive) from [<80660eec>] (dev_gro_receive+0x21c/0x3c0)
[<80660eec>] (dev_gro_receive) from [<8066133c>] (napi_gro_receive+0x44/0x17c)
[<8066133c>] (napi_gro_receive) from [<804f0538>] (gfar_clean_rx_ring+0x39c/0x7d4)
[<804f0538>] (gfar_clean_rx_ring) from [<804f0bf4>] (gfar_poll_rx_sq+0x58/0xe0)
[<804f0bf4>] (gfar_poll_rx_sq) from [<80660b10>] (net_rx_action+0x27c/0x43c)
[<80660b10>] (net_rx_action) from [<80033638>] (do_current_softirqs+0x1e0/0x3dc)
[<80033638>] (do_current_softirqs) from [<800338c4>] (__local_bh_enable+0x90/0xa8)
[<800338c4>] (__local_bh_enable) from [<8008025c>] (irq_forced_thread_fn+0x70/0x84)
[<8008025c>] (irq_forced_thread_fn) from [<800805e8>] (irq_thread+0x16c/0x244)
[<800805e8>] (irq_thread) from [<8004e490>] (kthread+0xe8/0x104)
[<8004e490>] (kthread) from [<8000fda8>] (ret_from_fork+0x14/0x2c)
Signed-off-by: Zumeng Chen <zumeng.chen(a)gmail.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/gianfar.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1378,9 +1378,11 @@ static int gfar_probe(struct platform_de
gfar_init_addr_hash_table(priv);
- /* Insert receive time stamps into padding alignment bytes */
+ /* Insert receive time stamps into padding alignment bytes, and
+ * plus 2 bytes padding to ensure the cpu alignment.
+ */
if (priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
- priv->padding = 8;
+ priv->padding = 8 + DEFAULT_PADDING;
if (dev->features & NETIF_F_IP_CSUM ||
priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
Patches currently in stable-queue which might be from zumeng.chen(a)gmail.com are
queue-4.14/gianfar-fix-a-flooded-alignment-reports-because-of-padding-issue.patch
This is a note to let you know that I've just added the patch titled
gianfar: Disable EEE autoneg by default
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
gianfar-disable-eee-autoneg-by-default.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Claudiu Manoil <claudiu.manoil(a)nxp.com>
Date: Thu, 7 Dec 2017 18:44:23 +0200
Subject: gianfar: Disable EEE autoneg by default
From: Claudiu Manoil <claudiu.manoil(a)nxp.com>
[ Upstream commit b6b5e8a691185606dfffff3198c89e3b4fd9d4f6 ]
This controller does not support EEE, but it may connect to a PHY
which supports EEE and advertises EEE by default, while its link
partner also advertises EEE. If this happens, the PHY enters low
power mode when the traffic rate is low and causes packet loss.
This patch disables EEE advertisement by default for any PHY that
gianfar connects to, to prevent the above unwanted outcome.
Signed-off-by: Shaohui Xie <Shaohui.Xie(a)nxp.com>
Tested-by: Yangbo Lu <Yangbo.lu(a)nxp.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil(a)nxp.com>
Reviewed-by: Andrew Lunn <andrew(a)lunn.ch>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/net/ethernet/freescale/gianfar.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1792,6 +1792,7 @@ static int init_phy(struct net_device *d
GFAR_SUPPORTED_GBIT : 0;
phy_interface_t interface;
struct phy_device *phydev;
+ struct ethtool_eee edata;
priv->oldlink = 0;
priv->oldspeed = 0;
@@ -1816,6 +1817,10 @@ static int init_phy(struct net_device *d
/* Add support for flow control, but don't advertise it by default */
phydev->supported |= (SUPPORTED_Pause | SUPPORTED_Asym_Pause);
+ /* disable EEE autoneg, EEE not supported by eTSEC */
+ memset(&edata, 0, sizeof(struct ethtool_eee));
+ phy_ethtool_set_eee(phydev, &edata);
+
return 0;
}
Patches currently in stable-queue which might be from claudiu.manoil(a)nxp.com are
queue-4.14/gianfar-disable-eee-autoneg-by-default.patch
This is a note to let you know that I've just added the patch titled
drm/vc4: Release fence after signalling
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-vc4-release-fence-after-signalling.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Stefan Schake <stschake(a)gmail.com>
Date: Sat, 2 Dec 2017 18:40:39 +0100
Subject: drm/vc4: Release fence after signalling
From: Stefan Schake <stschake(a)gmail.com>
[ Upstream commit babc8110057cb9ca542c3c1666cbda4e8ccf9250 ]
We were never releasing the initial fence reference that is obtained
through dma_fence_init.
Link: https://github.com/anholt/linux/issues/122
Fixes: cdec4d361323 ("drm/vc4: Expose dma-buf fences for V3D rendering.")
Signed-off-by: Stefan Schake <stschake(a)gmail.com>
Signed-off-by: Eric Anholt <eric(a)anholt.net>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Link: https://patchwork.freedesktop.org/patch/msgid/1512236444-301-1-git-send-ema…
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/vc4/vc4_gem.c | 4 +++-
drivers/gpu/drm/vc4/vc4_irq.c | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/vc4/vc4_gem.c
+++ b/drivers/gpu/drm/vc4/vc4_gem.c
@@ -829,8 +829,10 @@ vc4_complete_exec(struct drm_device *dev
/* If we got force-completed because of GPU reset rather than
* through our IRQ handler, signal the fence now.
*/
- if (exec->fence)
+ if (exec->fence) {
dma_fence_signal(exec->fence);
+ dma_fence_put(exec->fence);
+ }
if (exec->bo) {
for (i = 0; i < exec->bo_count; i++)
--- a/drivers/gpu/drm/vc4/vc4_irq.c
+++ b/drivers/gpu/drm/vc4/vc4_irq.c
@@ -139,6 +139,7 @@ vc4_irq_finish_render_job(struct drm_dev
list_move_tail(&exec->head, &vc4->job_done_list);
if (exec->fence) {
dma_fence_signal_locked(exec->fence);
+ dma_fence_put(exec->fence);
exec->fence = NULL;
}
vc4_submit_next_render_job(dev);
Patches currently in stable-queue which might be from stschake(a)gmail.com are
queue-4.14/drm-vc4-release-fence-after-signalling.patch
This is a note to let you know that I've just added the patch titled
drm/armada: fix leak of crtc structure
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-armada-fix-leak-of-crtc-structure.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From foo@baz Fri Feb 23 11:45:09 CET 2018
From: Russell King <rmk+kernel(a)armlinux.org.uk>
Date: Fri, 8 Dec 2017 12:16:22 +0000
Subject: drm/armada: fix leak of crtc structure
From: Russell King <rmk+kernel(a)armlinux.org.uk>
[ Upstream commit 33cd3c07a976e11c3c4cc6b0b3db6760ad1590c5 ]
Fix the leak of the CRTC structure in the failure paths of
armada_drm_crtc_create().
Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk>
Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/armada/armada_crtc.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -1225,17 +1225,13 @@ static int armada_drm_crtc_create(struct
ret = devm_request_irq(dev, irq, armada_drm_irq, 0, "armada_drm_crtc",
dcrtc);
- if (ret < 0) {
- kfree(dcrtc);
- return ret;
- }
+ if (ret < 0)
+ goto err_crtc;
if (dcrtc->variant->init) {
ret = dcrtc->variant->init(dcrtc, dev);
- if (ret) {
- kfree(dcrtc);
- return ret;
- }
+ if (ret)
+ goto err_crtc;
}
/* Ensure AXI pipeline is enabled */
@@ -1246,13 +1242,15 @@ static int armada_drm_crtc_create(struct
dcrtc->crtc.port = port;
primary = kzalloc(sizeof(*primary), GFP_KERNEL);
- if (!primary)
- return -ENOMEM;
+ if (!primary) {
+ ret = -ENOMEM;
+ goto err_crtc;
+ }
ret = armada_drm_plane_init(primary);
if (ret) {
kfree(primary);
- return ret;
+ goto err_crtc;
}
ret = drm_universal_plane_init(drm, &primary->base, 0,
@@ -1263,7 +1261,7 @@ static int armada_drm_crtc_create(struct
DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
kfree(primary);
- return ret;
+ goto err_crtc;
}
ret = drm_crtc_init_with_planes(drm, &dcrtc->crtc, &primary->base, NULL,
@@ -1282,6 +1280,9 @@ static int armada_drm_crtc_create(struct
err_crtc_init:
primary->base.funcs->destroy(&primary->base);
+err_crtc:
+ kfree(dcrtc);
+
return ret;
}
Patches currently in stable-queue which might be from rmk+kernel(a)armlinux.org.uk are
queue-4.14/sfp-fix-rx_los-signal-handling.patch
queue-4.14/drm-armada-fix-leak-of-crtc-structure.patch
queue-4.14/arm-8743-1-bl_switcher-add-module_license-tag.patch
queue-4.14/phylink-ensure-we-take-the-link-down-when-phylink_stop-is-called.patch