* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Greg Kroah-Hartman @ 2017-05-24 11:35 UTC (permalink / raw)
To: Thomas Voegtle
Cc: kernelci.org bot, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
In-Reply-To: <alpine.LSU.2.20.1705241122140.21307@er-systems.de>
On Wed, May 24, 2017 at 11:26:25AM +0200, Thomas Voegtle wrote:
> On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
>
> > On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> > > stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
> > >
> > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> > >
> > > Tree: stable-rc
> > > Branch: linux-4.4.y
> > > Git Describe: v4.4.69-104-g2ebff3b7590b
> > > Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
> >
> > 54 passed? I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...
> >
> > I've pushed out an update, can you all verify that it also works?
>
>
> I got this:
>
> CALL scripts/checksyscalls.sh
> CHK include/generated/compile.h
> CC kernel/fork.o
> kernel/fork.c: In function 'dup_task_struct':
> kernel/fork.c:371:2: error: implicit declaration of function
> 'get_random_long' [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
> make[1]: *** [kernel/fork.o] Error 1
> make: *** [kernel] Error 2
>
>
> This is stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
What arch/.config are you building for that causes this?
thanks,
greg k-h
^ permalink raw reply
* Re: stable-rc build: 0 warnings 4 failures (stable-rc/v4.9.29-165-g04accbb)
From: Arnd Bergmann @ 2017-05-24 10:36 UTC (permalink / raw)
To: Olof's autobuilder
Cc: Olof Johansson, Kernel Build Reports Mailman List, gregkh,
Marc Zyngier, Christoffer Dall, stable
In-Reply-To: <5924c767.4440630a.286c5.a55e@mx.google.com>
On Wed, May 24, 2017 at 1:36 AM, Olof's autobuilder <build@lixom.net> wrote:
>
> Errors:
>
> arm64.allmodconfig:
> /work/build/batch/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c:159:22: error: implicit declaration of function 'irq_is_pending' [-Werror=implicit-function-declaration]
> /work/build/batch/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:22: error: implicit declaration of function 'irq_is_pending' [-Werror=implicit-function-declaration]
Caused by the backport of 3d6e77ad1489 ("KVM: arm/arm64: vgic-v3: Do not
use Active+Pending state for a HW interrupt"), which Greg has apparently
dropped already from stable-rc.
Arnd
^ permalink raw reply
* Re: stable-rc build: 59 warnings 0 failures (stable-rc/v3.18.54-60-g35c7f23)
From: Arnd Bergmann @ 2017-05-24 10:31 UTC (permalink / raw)
To: Olof's autobuilder, gregkh
Cc: Olof Johansson, Kernel Build Reports Mailman List, stable
In-Reply-To: <5924af3d.c6c8620a.6511f.71b9@mx.google.com>
On Tue, May 23, 2017 at 11:53 PM, Olof's autobuilder <build@lixom.net> wrote:
> Here are the build results from automated periodic testing.
>
> The tree being built was stable-rc, found at:
>
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable-rc.git/
>
> 35c7f23 Linux 3.18.55-rc1
> Warnings:
>
> 2 include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void
> 57 drivers/of/fdt.c:384:10: warning: 'return' with a value, in function returning void
Caused by the backport of
0aa459efa045 ("of: fdt: add missing allocation-failure check")
which relies on another change from:
83262418b0ef ("drivers/of: Return allocated memory from
of_fdt_unflatten_tree()")
Possible fixes are
a) drop 0aa459efa045, as it won't be that important on 3.18: DT overlays
were added only in 3.19, so this won't ever be called at runtime, and
we don't normally worry about kmalloc failures during early boot.
b) backport 83262418b0ef, which is otherwise not needed on stable
c) apply or fold the trivial fixup:
8<--------
[stable 3.18] fix __unflatten_device_tree warning
A backported patch needs to be modified for a context change
drivers/of/fdt.c:384:10: warning: 'return' with a value, in function
returning void
Fixes: 0aa459efa045 ("of: fdt: add missing allocation-failure check")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 43bd69dceabf..ca352d3a7d7e 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -508,7 +508,7 @@ void *__unflatten_device_tree(const void *blob,
/* Allocate memory for the expanded device tree */
mem = dt_alloc(size + 4, __alignof__(struct device_node));
if (!mem)
- return NULL;
+ return;
memset(mem, 0, size);
^ permalink raw reply related
* Re: [PATCH 4.4 49/56] Bluetooth: hci_bcm: add missing tty-device sanity check
From: Johan Hovold @ 2017-05-24 10:19 UTC (permalink / raw)
To: Ben Hutchings
Cc: Johan Hovold, Marcel Holtmann, linux-kernel, stable,
Frederic Danis, Greg Kroah-Hartman
In-Reply-To: <1495589815.2083.7.camel@codethink.co.uk>
On Wed, May 24, 2017 at 02:36:55AM +0100, Ben Hutchings wrote:
> On Thu, 2017-05-18 at 12:49 +0200, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Johan Hovold <johan@kernel.org>
> >
> > commit 95065a61e9bf25fb85295127fba893200c2bbbd8 upstream.
> >
> > Make sure to check the tty-device pointer before looking up the sibling
> > platform device to avoid dereferencing a NULL-pointer when the tty is
> > one end of a Unix98 pty.
> >
> > Fixes: 0395ffc1ee05 ("Bluetooth: hci_bcm: Add PM for BCM devices")
> > Cc: Frederic Danis <frederic.danis@linux.intel.com>
> > Signed-off-by: Johan Hovold <johan@kernel.org>
> > Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >
> > ---
> > drivers/bluetooth/hci_bcm.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > --- a/drivers/bluetooth/hci_bcm.c
> > +++ b/drivers/bluetooth/hci_bcm.c
> > @@ -287,6 +287,9 @@ static int bcm_open(struct hci_uart *hu)
> >
> > hu->priv = bcm;
> >
> > + if (!hu->tty->dev)
> > + goto out;
> > +
> > mutex_lock(&bcm_device_lock);
> > list_for_each(p, &bcm_device_list) {
> > struct bcm_device *dev = list_entry(p, struct bcm_device, list);
> > @@ -307,7 +310,7 @@ static int bcm_open(struct hci_uart *hu)
> > }
> >
> > mutex_unlock(&bcm_device_lock);
> > -
> > +out:
> > return 0;
> > }
>
> I'm a bit sceptical that this is fixing a real bug,
Please take a look at bcm_open() where the tty device is being
dereferenced whenever there is bcm platform device registered:
list_for_each(p, &bcm_device_list) {
struct bcm_device *dev = list_entry(p, struct bcm_device, list);
...
if (hu->tty->dev->parent == dev->pdev->dev.parent) {
This can be used by an unprivileged user to trigger a NULL-dereference:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
...
[<bf0d5d74>] (bcm_open [hci_uart]) from [<bf0d1284>] (hci_uart_tty_ioctl+0x1b0/0x3c8 [hci_uart])
[<bf0d1284>] (hci_uart_tty_ioctl [hci_uart]) from [<c0465bcc>] (tty_ioctl+0x5bc/0xbc8)
[<c0465bcc>] (tty_ioctl) from [<c0258ad4>] (do_vfs_ioctl+0xac/0x9e8)
[<c0258ad4>] (do_vfs_ioctl) from [<c0259454>] (SyS_ioctl+0x44/0x6c)
[<c0259454>] (SyS_ioctl) from [<c01092e0>] (ret_fast_syscall+0x0/0x1c)
> but if it is -
> surely bcm_open() should fail if the tty device is not the right type?
> bcm_setup() would certainly fail after this.
The driver is written to be able to handle a non-existing platform
device (e.g. see use of bcm_device_exists() in the commit introducing
this issue), although since commit 6cc4396c8829 ("Bluetooth: hci_bcm:
Add wake-up capability") setup would indeed fail in this case (well at
least when firmware *is* available...).
Perhaps that is a separate issue that should be fixed (by failing early
in open as you suggest or by again allowing the driver to work without a
platform device), but I believe this patch is correct nonetheless. And
it does specifically fix the local DoS-attack.
Thanks,
Johan
^ permalink raw reply
* [PATCH v3.18.y] arm64: ensure extension of smp_store_release value
From: Mark Rutland @ 2017-05-24 9:58 UTC (permalink / raw)
To: stable
commit 994870bead4ab19087a79492400a5478e2906196 upstream.
When an inline assembly operand's type is narrower than the register it
is allocated to, the least significant bits of the register (up to the
operand type's width) are valid, and any other bits are permitted to
contain any arbitrary value. This aligns with the AAPCS64 parameter
passing rules.
Our __smp_store_release() implementation does not account for this, and
implicitly assumes that operands have been zero-extended to the width of
the type being stored to. Thus, we may store unknown values to memory
when the value type is narrower than the pointer type (e.g. when storing
a char to a long).
This patch fixes the issue by casting the value operand to the same
width as the pointer operand in all cases, which ensures that the value
is zero-extended as we expect. We use the same union trickery as
__smp_load_acquire and {READ,WRITE}_ONCE() to avoid GCC complaining that
pointers are potentially cast to narrower width integers in unreachable
paths.
A whitespace issue at the top of __smp_store_release() is also
corrected.
No changes are necessary for __smp_load_acquire(). Load instructions
implicitly clear any upper bits of the register, and the compiler will
only consider the least significant bits of the register as valid
regardless.
Fixes: 47933ad41a86 ("arch: Introduce smp_load_acquire(), smp_store_release()")
Fixes: 878a84d5a8a1 ("arm64: add missing data types in smp_load_acquire/smp_store_release")
Cc: <stable@vger.kernel.org> # 3.14.x-
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/barrier.h | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 6389d60..d3d4953 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -60,15 +60,21 @@ do { \
#define smp_store_release(p, v) \
do { \
+ union { typeof(*p) __val; char __c[1]; } __u = \
+ { .__val = (__force typeof(*p)) (v) }; \
compiletime_assert_atomic_type(*p); \
switch (sizeof(*p)) { \
case 4: \
asm volatile ("stlr %w1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u32 *)__u.__c) \
+ : "memory"); \
break; \
case 8: \
asm volatile ("stlr %1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u64 *)__u.__c) \
+ : "memory"); \
break; \
} \
} while (0)
--
1.9.1
^ permalink raw reply related
* [PATCH v4.4.y] arm64: armv8_deprecated: ensure extension of addr
From: Mark Rutland @ 2017-05-24 9:56 UTC (permalink / raw)
To: stable
commit 55de49f9aa17b0b2b144dd2af587177b9aadf429 upstream.
Our compat swp emulation holds the compat user address in an unsigned
int, which it passes to __user_swpX_asm(). When a 32-bit value is passed
in a register, the upper 32 bits of the register are unknown, and we
must extend the value to 64 bits before we can use it as a base address.
This patch casts the address to unsigned long to ensure it has been
suitably extended, avoiding the potential issue, and silencing a related
warning from clang.
Fixes: bd35a4adc413 ("arm64: Port SWP/SWPB emulation support from arm")
Cc: <stable@vger.kernel.org> # 3.19.x-
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/armv8_deprecated.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index 937f5e5..478a00b 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -305,7 +305,8 @@ static void register_insn_emulation_sysctl(struct ctl_table *table)
ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN, \
CONFIG_ARM64_PAN) \
: "=&r" (res), "+r" (data), "=&r" (temp) \
- : "r" (addr), "i" (-EAGAIN), "i" (-EFAULT) \
+ : "r" ((unsigned long)addr), "i" (-EAGAIN), \
+ "i" (-EFAULT) \
: "memory")
#define __user_swp_asm(data, addr, res, temp) \
--
1.9.1
^ permalink raw reply related
* [PATCH v4.4.y] arm64: ensure extension of smp_store_release value
From: Mark Rutland @ 2017-05-24 9:56 UTC (permalink / raw)
To: stable
commit 994870bead4ab19087a79492400a5478e2906196 upstream.
When an inline assembly operand's type is narrower than the register it
is allocated to, the least significant bits of the register (up to the
operand type's width) are valid, and any other bits are permitted to
contain any arbitrary value. This aligns with the AAPCS64 parameter
passing rules.
Our __smp_store_release() implementation does not account for this, and
implicitly assumes that operands have been zero-extended to the width of
the type being stored to. Thus, we may store unknown values to memory
when the value type is narrower than the pointer type (e.g. when storing
a char to a long).
This patch fixes the issue by casting the value operand to the same
width as the pointer operand in all cases, which ensures that the value
is zero-extended as we expect. We use the same union trickery as
__smp_load_acquire and {READ,WRITE}_ONCE() to avoid GCC complaining that
pointers are potentially cast to narrower width integers in unreachable
paths.
A whitespace issue at the top of __smp_store_release() is also
corrected.
No changes are necessary for __smp_load_acquire(). Load instructions
implicitly clear any upper bits of the register, and the compiler will
only consider the least significant bits of the register as valid
regardless.
Fixes: 47933ad41a86 ("arch: Introduce smp_load_acquire(), smp_store_release()")
Fixes: 878a84d5a8a1 ("arm64: add missing data types in smp_load_acquire/smp_store_release")
Cc: <stable@vger.kernel.org> # 3.14.x-
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/include/asm/barrier.h | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/barrier.h b/arch/arm64/include/asm/barrier.h
index 9622eb4..f2d2c0b 100644
--- a/arch/arm64/include/asm/barrier.h
+++ b/arch/arm64/include/asm/barrier.h
@@ -41,23 +41,33 @@
#define smp_store_release(p, v) \
do { \
+ union { typeof(*p) __val; char __c[1]; } __u = \
+ { .__val = (__force typeof(*p)) (v) }; \
compiletime_assert_atomic_type(*p); \
switch (sizeof(*p)) { \
case 1: \
asm volatile ("stlrb %w1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u8 *)__u.__c) \
+ : "memory"); \
break; \
case 2: \
asm volatile ("stlrh %w1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u16 *)__u.__c) \
+ : "memory"); \
break; \
case 4: \
asm volatile ("stlr %w1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u32 *)__u.__c) \
+ : "memory"); \
break; \
case 8: \
asm volatile ("stlr %1, %0" \
- : "=Q" (*p) : "r" (v) : "memory"); \
+ : "=Q" (*p) \
+ : "r" (*(__u64 *)__u.__c) \
+ : "memory"); \
break; \
} \
} while (0)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Thomas Voegtle @ 2017-05-24 9:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: kernelci.org bot, linux-kernel, torvalds, akpm, linux, shuahkh,
patches, ben.hutchings, stable
In-Reply-To: <20170524070353.GA5785@kroah.com>
On Wed, 24 May 2017, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
>> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>>
>> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>>
>> Tree: stable-rc
>> Branch: linux-4.4.y
>> Git Describe: v4.4.69-104-g2ebff3b7590b
>> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
>> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
>
> 54 passed? I had a bug here such that all x86 builds were crashing, in
> the core tty layer, which seems odd that anything would be able to boot
> with this tree...
>
> I've pushed out an update, can you all verify that it also works?
I got this:
CALL scripts/checksyscalls.sh
CHK include/generated/compile.h
CC kernel/fork.o
kernel/fork.c: In function 'dup_task_struct':
kernel/fork.c:371:2: error: implicit declaration of function
'get_random_long' [-Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[1]: *** [kernel/fork.o] Error 1
make: *** [kernel] Error 2
This is
stackprotector-increase-the-per-task-stack-canary-s-random-range-from-32-bits-to-64-bits-on-64-bit-platforms.patch
^ permalink raw reply
* [PATCH] powerpc: sysdev: simple_gpio: fix Oops in gpio save_regs function
From: Christophe Leroy @ 2017-05-24 8:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Scott Wood, Linus Walleij
Cc: linux-kernel, linuxppc-dev, linux-gpio, stable
of_mm_gpiochip_add_data() generates an Oops for NULL pointer dereference.
of_mm_gpiochip_add_data() calls mm_gc->save_regs() before
setting the data, therefore ->save_regs() cannot use gpiochip_get_data()
Fixes: 937daafca774b ("powerpc: simple-gpio: use gpiochip data pointer")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
arch/powerpc/sysdev/simple_gpio.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/sysdev/simple_gpio.c b/arch/powerpc/sysdev/simple_gpio.c
index ef470b470b04..6afddae2fb47 100644
--- a/arch/powerpc/sysdev/simple_gpio.c
+++ b/arch/powerpc/sysdev/simple_gpio.c
@@ -75,7 +75,8 @@ static int u8_gpio_dir_out(struct gpio_chip *gc, unsigned int gpio, int val)
static void u8_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
{
- struct u8_gpio_chip *u8_gc = gpiochip_get_data(&mm_gc->gc);
+ struct u8_gpio_chip *u8_gc =
+ container_of(mm_gc, struct u8_gpio_chip, mm_gc);
u8_gc->data = in_8(mm_gc->regs);
}
--
2.12.0
^ permalink raw reply related
* Re: Patch "KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt" has been added to the 4.9-stable tree
From: Marc Zyngier @ 2017-05-24 7:55 UTC (permalink / raw)
To: Greg KH, cdall; +Cc: stable, stable-commits
In-Reply-To: <20170524070916.GD5785@kroah.com>
On 24/05/17 08:09, Greg KH wrote:
> On Tue, May 23, 2017 at 04:48:26PM +0200, gregkh@linuxfoundation.org wrote:
>>
>> This is a note to let you know that I've just added the patch titled
>>
>> KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt
>>
>> to the 4.9-stable tree which can be found at:
>> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>>
>> The filename of the patch is:
>> kvm-arm-arm64-vgic-v2-do-not-use-active-pending-state-for-a-hw-interrupt.patch
>> and it can be found in the queue-4.9 subdirectory.
>>
>> If you, or anyone else, feels it should not be added to the stable tree,
>> please let <stable@vger.kernel.org> know about it.
>>
>>
>> >From ddf42d068f8802de122bb7efdfcb3179336053f1 Mon Sep 17 00:00:00 2001
>> From: Marc Zyngier <marc.zyngier@arm.com>
>> Date: Tue, 2 May 2017 14:30:39 +0100
>> Subject: KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt
>>
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> commit ddf42d068f8802de122bb7efdfcb3179336053f1 upstream.
>>
>> When an interrupt is injected with the HW bit set (indicating that
>> deactivation should be propagated to the physical distributor),
>> special care must be taken so that we never mark the corresponding
>> LR with the Active+Pending state (as the pending state is kept in
>> the physycal distributor).
>>
>> Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend")
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Reviewed-by: Christoffer Dall <cdall@linaro.org>
>> Signed-off-by: Christoffer Dall <cdall@linaro.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> ---
>> virt/kvm/arm/vgic/vgic-v2.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> --- a/virt/kvm/arm/vgic/vgic-v2.c
>> +++ b/virt/kvm/arm/vgic/vgic-v2.c
>> @@ -168,6 +168,13 @@ void vgic_v2_populate_lr(struct kvm_vcpu
>> if (irq->hw) {
>> val |= GICH_LR_HW;
>> val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
>> + /*
>> + * Never set pending+active on a HW interrupt, as the
>> + * pending state is kept at the physical distributor
>> + * level.
>> + */
>> + if (irq->active && irq_is_pending(irq))
>
> Same irq_is_pending() problem here for 4.9 as well, now dropped.
Updated patch:
>From 06cdeec05ff8f62e81bab5c03c679dc16b2be8a3 Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue, 2 May 2017 14:30:39 +0100
Subject: [PATCH 2/2] KVM: arm/arm64: vgic-v2: Do not use Active+Pending state
for a HW interrupt
commit ddf42d068f8802de122bb7efdfcb3179336053f1 upstream.
When an interrupt is injected with the HW bit set (indicating that
deactivation should be propagated to the physical distributor),
special care must be taken so that we never mark the corresponding
LR with the Active+Pending state (as the pending state is kept in
the physycal distributor).
Cc: stable@vger.kernel.org
Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
---
virt/kvm/arm/vgic/vgic-v2.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic-v2.c b/virt/kvm/arm/vgic/vgic-v2.c
index 834137e7b83f..1ab58f7b5d74 100644
--- a/virt/kvm/arm/vgic/vgic-v2.c
+++ b/virt/kvm/arm/vgic/vgic-v2.c
@@ -168,6 +168,13 @@ void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
if (irq->hw) {
val |= GICH_LR_HW;
val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
+ /*
+ * Never set pending+active on a HW interrupt, as the
+ * pending state is kept at the physical distributor
+ * level.
+ */
+ if (irq->active && irq->pending)
+ val &= ~GICH_LR_PENDING_BIT;
} else {
if (irq->config == VGIC_CONFIG_LEVEL)
val |= GICH_LR_EOI;
--
2.11.0
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* Re: Patch "KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt" has been added to the 4.9-stable tree
From: Marc Zyngier @ 2017-05-24 7:54 UTC (permalink / raw)
To: Greg KH, cdall; +Cc: stable, stable-commits
In-Reply-To: <20170524070845.GC5785@kroah.com>
On 24/05/17 08:08, Greg KH wrote:
> On Tue, May 23, 2017 at 04:48:28PM +0200, gregkh@linuxfoundation.org wrote:
>>
>> This is a note to let you know that I've just added the patch titled
>>
>> KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt
>>
>> to the 4.9-stable tree which can be found at:
>> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>>
>> The filename of the patch is:
>> kvm-arm-arm64-vgic-v3-do-not-use-active-pending-state-for-a-hw-interrupt.patch
>> and it can be found in the queue-4.9 subdirectory.
>>
>> If you, or anyone else, feels it should not be added to the stable tree,
>> please let <stable@vger.kernel.org> know about it.
>>
>>
>> >From 3d6e77ad1489650afa20da92bb589c8778baa8da Mon Sep 17 00:00:00 2001
>> From: Marc Zyngier <marc.zyngier@arm.com>
>> Date: Tue, 2 May 2017 14:30:40 +0100
>> Subject: KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt
>>
>> From: Marc Zyngier <marc.zyngier@arm.com>
>>
>> commit 3d6e77ad1489650afa20da92bb589c8778baa8da upstream.
>>
>> When an interrupt is injected with the HW bit set (indicating that
>> deactivation should be propagated to the physical distributor),
>> special care must be taken so that we never mark the corresponding
>> LR with the Active+Pending state (as the pending state is kept in
>> the physycal distributor).
>>
>> Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend")
>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>> Reviewed-by: Christoffer Dall <cdall@linaro.org>
>> Signed-off-by: Christoffer Dall <cdall@linaro.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> ---
>> virt/kvm/arm/vgic/vgic-v3.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> --- a/virt/kvm/arm/vgic/vgic-v3.c
>> +++ b/virt/kvm/arm/vgic/vgic-v3.c
>> @@ -151,6 +151,13 @@ void vgic_v3_populate_lr(struct kvm_vcpu
>> if (irq->hw) {
>> val |= ICH_LR_HW;
>> val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
>> + /*
>> + * Never set pending+active on a HW interrupt, as the
>> + * pending state is kept at the physical distributor
>> + * level.
>> + */
>> + if (irq->active && irq_is_pending(irq))
>
> irq_is_pending() isn't in 4.9, so can someone please send me a proper
> backported patch? I've dropped this from the tree now as it causes a
> build breakage.
Here's the amended patch:
>From b50e5df239df83ca4698f96bec6111f20a7634ed Mon Sep 17 00:00:00 2001
From: Marc Zyngier <marc.zyngier@arm.com>
Date: Tue, 2 May 2017 14:30:40 +0100
Subject: [PATCH 1/2] KVM: arm/arm64: vgic-v3: Do not use Active+Pending state
for a HW interrupt
commit 3d6e77ad1489650afa20da92bb589c8778baa8da upstream.
When an interrupt is injected with the HW bit set (indicating that
deactivation should be propagated to the physical distributor),
special care must be taken so that we never mark the corresponding
LR with the Active+Pending state (as the pending state is kept in
the physycal distributor).
Cc: stable@vger.kernel.org
Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend")
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Christoffer Dall <cdall@linaro.org>
Signed-off-by: Christoffer Dall <cdall@linaro.org>
---
virt/kvm/arm/vgic/vgic-v3.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
index e6b03fd8c374..f1320063db28 100644
--- a/virt/kvm/arm/vgic/vgic-v3.c
+++ b/virt/kvm/arm/vgic/vgic-v3.c
@@ -151,6 +151,13 @@ void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr)
if (irq->hw) {
val |= ICH_LR_HW;
val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
+ /*
+ * Never set pending+active on a HW interrupt, as the
+ * pending state is kept at the physical distributor
+ * level.
+ */
+ if (irq->active && irq->pending)
+ val &= ~ICH_LR_PENDING_BIT;
} else {
if (irq->config == VGIC_CONFIG_LEVEL)
val |= ICH_LR_EOI;
--
2.11.0
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related
* patch "usb: chipidea: udc: fix NULL pointer dereference if udc_start failed" added to usb-linus
From: gregkh @ 2017-05-24 7:22 UTC (permalink / raw)
To: jszhang, peter.chen, stable
This is a note to let you know that I've just added the patch titled
usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From aa1f058d7d9244423b8c5a75b9484b1115df7f02 Mon Sep 17 00:00:00 2001
From: Jisheng Zhang <jszhang@marvell.com>
Date: Mon, 24 Apr 2017 12:35:51 +0000
Subject: usb: chipidea: udc: fix NULL pointer dereference if udc_start failed
Fix below NULL pointer dereference. we set ci->roles[CI_ROLE_GADGET]
too early in ci_hdrc_gadget_init(), if udc_start() fails due to some
reason, the ci->roles[CI_ROLE_GADGET] check in ci_hdrc_gadget_destroy
can't protect us.
We fix this issue by only setting ci->roles[CI_ROLE_GADGET] if
udc_start() succeed.
[ 1.398550] Unable to handle kernel NULL pointer dereference at
virtual address 00000000
...
[ 1.448600] PC is at dma_pool_free+0xb8/0xf0
[ 1.453012] LR is at dma_pool_free+0x28/0xf0
[ 2.113369] [<ffffff80081817d8>] dma_pool_free+0xb8/0xf0
[ 2.118857] [<ffffff800841209c>] destroy_eps+0x4c/0x68
[ 2.124165] [<ffffff8008413770>] ci_hdrc_gadget_destroy+0x28/0x50
[ 2.130461] [<ffffff800840fa30>] ci_hdrc_probe+0x588/0x7e8
[ 2.136129] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
[ 2.142066] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
[ 2.148270] [<ffffff800837f68c>] __device_attach_driver+0x9c/0xf8
[ 2.154563] [<ffffff800837d570>] bus_for_each_drv+0x58/0x98
[ 2.160317] [<ffffff800837f174>] __device_attach+0xc4/0x138
[ 2.166072] [<ffffff800837f738>] device_initial_probe+0x10/0x18
[ 2.172185] [<ffffff800837e58c>] bus_probe_device+0x94/0xa0
[ 2.177940] [<ffffff800837c560>] device_add+0x3f0/0x560
[ 2.183337] [<ffffff8008380d20>] platform_device_add+0x180/0x240
[ 2.189541] [<ffffff800840f0e8>] ci_hdrc_add_device+0x440/0x4f8
[ 2.195654] [<ffffff8008414194>] ci_hdrc_usb2_probe+0x13c/0x2d8
[ 2.201769] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
[ 2.207705] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
[ 2.213910] [<ffffff800837f5ec>] __driver_attach+0xac/0xb0
[ 2.219575] [<ffffff800837d4b0>] bus_for_each_dev+0x60/0xa0
[ 2.225329] [<ffffff800837ec80>] driver_attach+0x20/0x28
[ 2.230816] [<ffffff800837e880>] bus_add_driver+0x1d0/0x238
[ 2.236571] [<ffffff800837fdb0>] driver_register+0x60/0xf8
[ 2.242237] [<ffffff8008380ef4>] __platform_driver_register+0x44/0x50
[ 2.248891] [<ffffff80086fd440>] ci_hdrc_usb2_driver_init+0x18/0x20
[ 2.255365] [<ffffff8008082950>] do_one_initcall+0x38/0x128
[ 2.261121] [<ffffff80086e0d00>] kernel_init_freeable+0x1ac/0x250
[ 2.267414] [<ffffff800852f0b8>] kernel_init+0x10/0x100
[ 2.272810] [<ffffff8008082680>] ret_from_fork+0x10/0x50
Cc: stable <stable@vger.kernel.org>
Fixes: 3f124d233e97 ("usb: chipidea: add role init and destroy APIs")
Signed-off-by: Jisheng Zhang <jszhang@marvell.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
drivers/usb/chipidea/udc.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 56d2d3213076..d68b125796f9 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1993,6 +1993,7 @@ static void udc_id_switch_for_host(struct ci_hdrc *ci)
int ci_hdrc_gadget_init(struct ci_hdrc *ci)
{
struct ci_role_driver *rdrv;
+ int ret;
if (!hw_read(ci, CAP_DCCPARAMS, DCCPARAMS_DC))
return -ENXIO;
@@ -2005,7 +2006,10 @@ int ci_hdrc_gadget_init(struct ci_hdrc *ci)
rdrv->stop = udc_id_switch_for_host;
rdrv->irq = udc_irq;
rdrv->name = "gadget";
- ci->roles[CI_ROLE_GADGET] = rdrv;
- return udc_start(ci);
+ ret = udc_start(ci);
+ if (!ret)
+ ci->roles[CI_ROLE_GADGET] = rdrv;
+
+ return ret;
}
--
2.13.0
^ permalink raw reply related
* patch "usb: chipidea: imx: Do not access CLKONOFF on i.MX51" added to usb-linus
From: gregkh @ 2017-05-24 7:22 UTC (permalink / raw)
To: andrew.smirnov, gregkh, peter.chen, stable
This is a note to let you know that I've just added the patch titled
usb: chipidea: imx: Do not access CLKONOFF on i.MX51
to my usb git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
in the usb-linus branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will hopefully also be merged in Linus's tree for the
next -rc kernel release.
If you have any questions about this process, please let me know.
>From 62b97d502bb76c6e8d589e42e02bfcb7bdff0453 Mon Sep 17 00:00:00 2001
From: Andrey Smirnov <andrew.smirnov@gmail.com>
Date: Mon, 15 May 2017 06:48:58 -0700
Subject: usb: chipidea: imx: Do not access CLKONOFF on i.MX51
Unlike i.MX53, i.MX51's USBOH3 register file does not implemenent
registers past offset 0x018, which includes
MX53_USB_CLKONOFF_CTRL_OFFSET and trying to access that register on
said platform results in external abort.
Fix it by enabling CLKONOFF accessing codepath only for i.MX53.
Cc: stable <stable@vger.kernel.org>
Fixes 3be3251db088 ("usb: chipidea: imx: Disable internal 60Mhz
clock with ULPI PHY")
Cc: cphealy@gmail.com
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
---
drivers/usb/chipidea/usbmisc_imx.c | 41 +++++++++++++++++++++++++++++---------
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/chipidea/usbmisc_imx.c b/drivers/usb/chipidea/usbmisc_imx.c
index e77a4ed4f021..9f4a0185dd60 100644
--- a/drivers/usb/chipidea/usbmisc_imx.c
+++ b/drivers/usb/chipidea/usbmisc_imx.c
@@ -108,6 +108,8 @@ struct imx_usbmisc {
const struct usbmisc_ops *ops;
};
+static inline bool is_imx53_usbmisc(struct imx_usbmisc_data *data);
+
static int usbmisc_imx25_init(struct imx_usbmisc_data *data)
{
struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
@@ -242,10 +244,15 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
val = readl(reg) | MX53_USB_UHx_CTRL_WAKE_UP_EN
| MX53_USB_UHx_CTRL_ULPI_INT_EN;
writel(val, reg);
- /* Disable internal 60Mhz clock */
- reg = usbmisc->base + MX53_USB_CLKONOFF_CTRL_OFFSET;
- val = readl(reg) | MX53_USB_CLKONOFF_CTRL_H2_INT60CKOFF;
- writel(val, reg);
+ if (is_imx53_usbmisc(data)) {
+ /* Disable internal 60Mhz clock */
+ reg = usbmisc->base +
+ MX53_USB_CLKONOFF_CTRL_OFFSET;
+ val = readl(reg) |
+ MX53_USB_CLKONOFF_CTRL_H2_INT60CKOFF;
+ writel(val, reg);
+ }
+
}
if (data->disable_oc) {
reg = usbmisc->base + MX53_USB_UH2_CTRL_OFFSET;
@@ -267,10 +274,15 @@ static int usbmisc_imx53_init(struct imx_usbmisc_data *data)
val = readl(reg) | MX53_USB_UHx_CTRL_WAKE_UP_EN
| MX53_USB_UHx_CTRL_ULPI_INT_EN;
writel(val, reg);
- /* Disable internal 60Mhz clock */
- reg = usbmisc->base + MX53_USB_CLKONOFF_CTRL_OFFSET;
- val = readl(reg) | MX53_USB_CLKONOFF_CTRL_H3_INT60CKOFF;
- writel(val, reg);
+
+ if (is_imx53_usbmisc(data)) {
+ /* Disable internal 60Mhz clock */
+ reg = usbmisc->base +
+ MX53_USB_CLKONOFF_CTRL_OFFSET;
+ val = readl(reg) |
+ MX53_USB_CLKONOFF_CTRL_H3_INT60CKOFF;
+ writel(val, reg);
+ }
}
if (data->disable_oc) {
reg = usbmisc->base + MX53_USB_UH3_CTRL_OFFSET;
@@ -456,6 +468,10 @@ static const struct usbmisc_ops imx27_usbmisc_ops = {
.init = usbmisc_imx27_init,
};
+static const struct usbmisc_ops imx51_usbmisc_ops = {
+ .init = usbmisc_imx53_init,
+};
+
static const struct usbmisc_ops imx53_usbmisc_ops = {
.init = usbmisc_imx53_init,
};
@@ -479,6 +495,13 @@ static const struct usbmisc_ops imx7d_usbmisc_ops = {
.set_wakeup = usbmisc_imx7d_set_wakeup,
};
+static inline bool is_imx53_usbmisc(struct imx_usbmisc_data *data)
+{
+ struct imx_usbmisc *usbmisc = dev_get_drvdata(data->dev);
+
+ return usbmisc->ops == &imx53_usbmisc_ops;
+}
+
int imx_usbmisc_init(struct imx_usbmisc_data *data)
{
struct imx_usbmisc *usbmisc;
@@ -536,7 +559,7 @@ static const struct of_device_id usbmisc_imx_dt_ids[] = {
},
{
.compatible = "fsl,imx51-usbmisc",
- .data = &imx53_usbmisc_ops,
+ .data = &imx51_usbmisc_ops,
},
{
.compatible = "fsl,imx53-usbmisc",
--
2.13.0
^ permalink raw reply related
* Re: [PATCH 0/2] nohz: Deal with clock reprogram skipping issues v3
From: Ingo Molnar @ 2017-05-24 7:16 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: LKML, Peter Zijlstra, Rik van Riel, James Hartsock,
Thomas Gleixner, stable, Tim Wright, Pavel Machek
In-Reply-To: <20170523131042.GA26103@lerouge>
* Frederic Weisbecker <fweisbec@gmail.com> wrote:
> On Tue, May 23, 2017 at 09:25:08AM +0200, Ingo Molnar wrote:
> >
> > * Frederic Weisbecker <fweisbec@gmail.com> wrote:
> >
> > > v2 had issues on -tip tree and triggered a warning. It seems to have
> > > disappeared. Perhaps it was due to another timer issue. Anyway this
> > > version brings more debugging informations, with a layout that is more
> > > bisection-friendly and it also handles ticks that fire outside IRQ
> > > context and thus carry NULL irq regs. This happen when
> > > hrtimer_interrupt() is called on hotplug cpu down for example.
> > >
> > > We'll see if the issue arises again.
> > >
> > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
> > > nohz/fixes
> > >
> > > HEAD: cd15f46b284f04dbedd065a9d99a4e0badae379a
> > >
> > > Thanks,
> > > Frederic
> > > ---
> > >
> > > Frederic Weisbecker (2):
> > > nohz: Add hrtimer sanity check
> > > nohz: Fix collision between tick and other hrtimers, again
> > >
> > >
> > > kernel/time/tick-sched.c | 48 +++++++++++++++++++++++++++++++++++++++++++-----
> > > kernel/time/tick-sched.h | 2 ++
> > > 2 files changed, 45 insertions(+), 5 deletions(-)
> >
> > So I think the 3 commits queued up right now:
> >
> > 99fa871820cf: nohz: Reset next_tick cache even when the timer has no regs
> > 411fe24e6b7c: nohz: Fix collision between tick and other hrtimers, again
> > ce6cf9a15d62: nohz: Add hrtimer sanity check
> >
> > are OK and I'd not rebase them unless there's some breakage.
> >
> > One thing I noticed: your second series does appear to have:
> >
> > 99fa871820cf: nohz: Reset next_tick cache even when the timer has no regs
> >
> > is that intentional? That is pretty much the only commit I'd love to rebase with a
> > proper description added.
>
> Yes in my latest series I melted "nohz: Reset next_tick cache even when the timer has no regs"
> into "nohz: Fix collision between tick and other hrtimers, again" because it's a fixup and
> keeping that patch separate may break bisection.
>
> So ideally, it would be nice if you could fixup 411fe24e6b7c with 99fa871820cf. That's roughly
> all I did in my latest series.
So the interdiff between your two patches and the 3 commits already queued up is:
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index e3043873fcdc..30253ed0380b 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -150,12 +150,6 @@ static void tick_sched_handle(struct tick_sched *ts, struct pt_regs *regs)
touch_softlockup_watchdog_sched();
if (is_idle_task(current))
ts->idle_jiffies++;
- /*
- * In case the current tick fired too early past its expected
- * expiration, make sure we don't bypass the next clock reprogramming
- * to the same deadline.
- */
- ts->next_tick = 0;
}
#endif
update_process_times(user_mode(regs));
@@ -1103,8 +1097,15 @@ static void tick_nohz_handler(struct clock_event_device *dev)
tick_sched_handle(ts, regs);
/* No need to reprogram if we are running tickless */
- if (unlikely(ts->tick_stopped))
+ if (unlikely(ts->tick_stopped)) {
+ /*
+ * In case the current tick fired too early past its expected
+ * expiration, make sure we don't bypass the next clock reprogramming
+ * to the same deadline.
+ */
+ ts->next_tick = 0;
return;
+ }
hrtimer_forward(&ts->sched_timer, now, tick_period);
tick_program_event(hrtimer_get_expires(&ts->sched_timer), 1);
@@ -1202,12 +1203,17 @@ static enum hrtimer_restart tick_sched_timer(struct hrtimer *timer)
*/
if (regs)
tick_sched_handle(ts, regs);
- else
- ts->next_tick = 0;
/* No need to reprogram if we are in idle or full dynticks mode */
- if (unlikely(ts->tick_stopped))
+ if (unlikely(ts->tick_stopped)) {
+ /*
+ * In case the current tick fired too early past its expected
+ * expiration, make sure we don't bypass the next clock reprogramming
+ * to the same deadline.
+ */
+ ts->next_tick = 0;
return HRTIMER_NORESTART;
+ }
hrtimer_forward(timer, now, tick_period);
... so the two are not the same - I'd rather not rebase it, I'd like to keep what
is working, we had problems with these changes before ...
If you'd like the changes in this interdiff to be applied as well, please add a
changelog to it and post it as a fourth patch.
Thanks,
Ingo
^ permalink raw reply related
* Re: [PATCH 4.9 000/164] 4.9.30-stable review
From: Greg Kroah-Hartman @ 2017-05-24 7:11 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <1affde0e-a9d5-98c4-5374-876333aad1e8@roeck-us.net>
On Tue, May 23, 2017 at 08:57:34PM -0700, Guenter Roeck wrote:
> On 05/23/2017 01:06 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.30 release.
> > There are 164 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu May 25 20:08:20 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Early feedback:
>
> Building arm:axm55xx_defconfig ... failed
> --------------
> Error log:
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c: In function 'vgic_v2_populate_lr':
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:3: error: implicit declaration of function 'irq_is_pending' [-Werror=implicit-function-declaration]
> if (irq->active && irq_is_pending(irq))
> ^
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c: In function 'vgic_v3_populate_lr':
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c:159:3: error: implicit declaration of function 'irq_is_pending'
>
> Building arm64:allmodconfig ... failed
> --------------
> Error log:
> arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
> arch/arm64/Makefile:36: LSE atomics not supported by binutils
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c: In function ‘vgic_v2_populate_lr’:
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:22: error: implicit declaration of function ‘irq_is_pending’ [-Werror=implicit-function-declaration]
> if (irq->active && irq_is_pending(irq))
> ^
> cc1: some warnings being treated as errors
> make[2]: *** [arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c: In function ‘vgic_v3_populate_lr’:
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c:159:22: error: implicit declaration of function ‘irq_is_pending’
Now found and dropped 2 patches that were causing this. Should be all
clean now, thanks for finding this.
greg k-h
^ permalink raw reply
* Re: Patch "KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt" has been added to the 4.9-stable tree
From: Greg KH @ 2017-05-24 7:09 UTC (permalink / raw)
To: marc.zyngier, cdall; +Cc: stable, stable-commits
In-Reply-To: <149555090678229@kroah.com>
On Tue, May 23, 2017 at 04:48:26PM +0200, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt
>
> to the 4.9-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> kvm-arm-arm64-vgic-v2-do-not-use-active-pending-state-for-a-hw-interrupt.patch
> and it can be found in the queue-4.9 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
>
>
> >From ddf42d068f8802de122bb7efdfcb3179336053f1 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <marc.zyngier@arm.com>
> Date: Tue, 2 May 2017 14:30:39 +0100
> Subject: KVM: arm/arm64: vgic-v2: Do not use Active+Pending state for a HW interrupt
>
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> commit ddf42d068f8802de122bb7efdfcb3179336053f1 upstream.
>
> When an interrupt is injected with the HW bit set (indicating that
> deactivation should be propagated to the physical distributor),
> special care must be taken so that we never mark the corresponding
> LR with the Active+Pending state (as the pending state is kept in
> the physycal distributor).
>
> Fixes: 140b086dd197 ("KVM: arm/arm64: vgic-new: Add GICv2 world switch backend")
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Reviewed-by: Christoffer Dall <cdall@linaro.org>
> Signed-off-by: Christoffer Dall <cdall@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> virt/kvm/arm/vgic/vgic-v2.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> --- a/virt/kvm/arm/vgic/vgic-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-v2.c
> @@ -168,6 +168,13 @@ void vgic_v2_populate_lr(struct kvm_vcpu
> if (irq->hw) {
> val |= GICH_LR_HW;
> val |= irq->hwintid << GICH_LR_PHYSID_CPUID_SHIFT;
> + /*
> + * Never set pending+active on a HW interrupt, as the
> + * pending state is kept at the physical distributor
> + * level.
> + */
> + if (irq->active && irq_is_pending(irq))
Same irq_is_pending() problem here for 4.9 as well, now dropped.
thanks,
greg k-h
^ permalink raw reply
* Re: Patch "KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt" has been added to the 4.9-stable tree
From: Greg KH @ 2017-05-24 7:08 UTC (permalink / raw)
To: marc.zyngier, cdall; +Cc: stable, stable-commits
In-Reply-To: <14955509086618@kroah.com>
On Tue, May 23, 2017 at 04:48:28PM +0200, gregkh@linuxfoundation.org wrote:
>
> This is a note to let you know that I've just added the patch titled
>
> KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt
>
> to the 4.9-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
>
> The filename of the patch is:
> kvm-arm-arm64-vgic-v3-do-not-use-active-pending-state-for-a-hw-interrupt.patch
> and it can be found in the queue-4.9 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable@vger.kernel.org> know about it.
>
>
> >From 3d6e77ad1489650afa20da92bb589c8778baa8da Mon Sep 17 00:00:00 2001
> From: Marc Zyngier <marc.zyngier@arm.com>
> Date: Tue, 2 May 2017 14:30:40 +0100
> Subject: KVM: arm/arm64: vgic-v3: Do not use Active+Pending state for a HW interrupt
>
> From: Marc Zyngier <marc.zyngier@arm.com>
>
> commit 3d6e77ad1489650afa20da92bb589c8778baa8da upstream.
>
> When an interrupt is injected with the HW bit set (indicating that
> deactivation should be propagated to the physical distributor),
> special care must be taken so that we never mark the corresponding
> LR with the Active+Pending state (as the pending state is kept in
> the physycal distributor).
>
> Fixes: 59529f69f504 ("KVM: arm/arm64: vgic-new: Add GICv3 world switch backend")
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> Reviewed-by: Christoffer Dall <cdall@linaro.org>
> Signed-off-by: Christoffer Dall <cdall@linaro.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> ---
> virt/kvm/arm/vgic/vgic-v3.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -151,6 +151,13 @@ void vgic_v3_populate_lr(struct kvm_vcpu
> if (irq->hw) {
> val |= ICH_LR_HW;
> val |= ((u64)irq->hwintid) << ICH_LR_PHYS_ID_SHIFT;
> + /*
> + * Never set pending+active on a HW interrupt, as the
> + * pending state is kept at the physical distributor
> + * level.
> + */
> + if (irq->active && irq_is_pending(irq))
irq_is_pending() isn't in 4.9, so can someone please send me a proper
backported patch? I've dropped this from the tree now as it causes a
build breakage.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 4.9 000/164] 4.9.30-stable review
From: Greg Kroah-Hartman @ 2017-05-24 7:07 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <1affde0e-a9d5-98c4-5374-876333aad1e8@roeck-us.net>
On Tue, May 23, 2017 at 08:57:34PM -0700, Guenter Roeck wrote:
> On 05/23/2017 01:06 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.30 release.
> > There are 164 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu May 25 20:08:20 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Early feedback:
>
> Building arm:axm55xx_defconfig ... failed
> --------------
> Error log:
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c: In function 'vgic_v2_populate_lr':
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:3: error: implicit declaration of function 'irq_is_pending' [-Werror=implicit-function-declaration]
> if (irq->active && irq_is_pending(irq))
> ^
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c: In function 'vgic_v3_populate_lr':
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm/kvm/../../../virt/kvm/arm/vgic/vgic-v3.c:159:3: error: implicit declaration of function 'irq_is_pending'
>
> Building arm64:allmodconfig ... failed
> --------------
> Error log:
> arch/arm64/Makefile:23: ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum
> arch/arm64/Makefile:36: LSE atomics not supported by binutils
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c: In function ‘vgic_v2_populate_lr’:
> /opt/buildbot/slave/stable-queue-4.9/build/arch/arm64/kvm/../../../virt/kvm/arm/vgic/vgic-v2.c:176:22: error: implicit declaration of function ‘irq_is_pending’ [-Werror=implicit-function-declaration]
> if (irq->active && irq_is_pending(irq))
> ^
Hm, looks like one of the kvm patches is calling this, let me dig...
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Greg Kroah-Hartman @ 2017-05-24 7:03 UTC (permalink / raw)
To: kernelci.org bot
Cc: linux-kernel, torvalds, akpm, linux, shuahkh, patches,
ben.hutchings, stable
In-Reply-To: <59252147.91471c0a.7a474.26e6@mx.google.com>
On Tue, May 23, 2017 at 10:59:35PM -0700, kernelci.org bot wrote:
> stable-rc/linux-4.4.y boot: 54 boots: 0 failed, 54 passed (v4.4.69-104-g2ebff3b7590b)
>
> Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
> Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.69-104-g2ebff3b7590b/
>
> Tree: stable-rc
> Branch: linux-4.4.y
> Git Describe: v4.4.69-104-g2ebff3b7590b
> Git Commit: 2ebff3b7590b0a73c6b383d04928cdfdf56d0b10
> Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 11 unique boards, 7 SoC families, 18 builds out of 199
54 passed? I had a bug here such that all x86 builds were crashing, in
the core tty layer, which seems odd that anything would be able to boot
with this tree...
I've pushed out an update, can you all verify that it also works?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Greg Kroah-Hartman @ 2017-05-24 6:55 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <20170524065039.GA22851@kroah.com>
On Wed, May 24, 2017 at 08:50:39AM +0200, Greg Kroah-Hartman wrote:
> On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote:
> > On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.4.70 release.
> > > There are 103 patches in this series, all will be posted as a response
> > > to this one. If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Thu May 25 20:08:25 UTC 2017.
> > > Anything received after that time might be too late.
> > >
> >
> > Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
> >
> > Guenter
> >
> > ---
> >
> > ...
> > EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
> > BUG: unable to handle kernel paging request at 0000000000002280
> > IP: [<ffffffff81451115>] process_echoes+0x15/0x70
> > PGD da68067 PUD d991067 PMD 0
> > Oops: 0000 [#1] PREEMPT SMP
> > Modules linked in:
> > CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
> > Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> > task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
> > RIP: 0010:[<ffffffff81451115>] [<ffffffff81451115>] process_echoes+0x15/0x70
> > RSP: 0018:ffff88000d233d50 EFLAGS: 00000202
> > RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
> > RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
> > RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
> > R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
> > R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
> > FS: 00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
> > Stack:
> > ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
> > ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
> > ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
> > Call Trace:
> > [<ffffffff814515b7>] n_tty_write+0x97/0x4e0
> > [<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
> > [<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
> > [<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
> > [<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
> > [<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
> > [<ffffffff81199abe>] ? __fd_install+0x5e/0x110
> > [<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
> > [<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
> > [<ffffffff8117df3a>] vfs_write+0x9a/0x170
> > [<ffffffff8117ea96>] SyS_write+0x46/0xb0
> > [<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
> > Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
> > RIP [<ffffffff81451115>] process_echoes+0x15/0x70
> > RSP <ffff88000d233d50>
> > CR2: 0000000000002280
> > ---[ end trace cec672c0d4b54e81 ]---
> > Kernel panic - not syncing: Fatal exception
> > Kernel Offset: disabled
> > ---[ end Kernel panic - not syncing: Fatal exception
>
> Yes, bisection would be great, if you can do it. I would blame the only
> tty patch in the release,
> tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that
> would be odd.
>
> Oops, nope, that would be it, the merge happened badly, I applied a
> chunk in the wrong place, ugh. Let me go fix that patch up now...
And that was because this patch was already merged in an older release,
my fault. I've dropped it now, and pushed out an update, this should
fix the problem.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Greg Kroah-Hartman @ 2017-05-24 6:50 UTC (permalink / raw)
To: Guenter Roeck
Cc: linux-kernel, torvalds, akpm, shuahkh, patches, ben.hutchings,
stable
In-Reply-To: <8a345fbb-f8e5-e707-b392-444539d585a4@roeck-us.net>
On Tue, May 23, 2017 at 09:01:05PM -0700, Guenter Roeck wrote:
> On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.70 release.
> > There are 103 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu May 25 20:08:25 UTC 2017.
> > Anything received after that time might be too late.
> >
>
> Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
>
> Guenter
>
> ---
>
> ...
> EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
> BUG: unable to handle kernel paging request at 0000000000002280
> IP: [<ffffffff81451115>] process_echoes+0x15/0x70
> PGD da68067 PUD d991067 PMD 0
> Oops: 0000 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
> task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
> RIP: 0010:[<ffffffff81451115>] [<ffffffff81451115>] process_echoes+0x15/0x70
> RSP: 0018:ffff88000d233d50 EFLAGS: 00000202
> RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
> RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
> RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
> R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
> R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
> FS: 00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
> Stack:
> ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
> ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
> ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
> Call Trace:
> [<ffffffff814515b7>] n_tty_write+0x97/0x4e0
> [<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
> [<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
> [<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
> [<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
> [<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
> [<ffffffff81199abe>] ? __fd_install+0x5e/0x110
> [<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
> [<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
> [<ffffffff8117df3a>] vfs_write+0x9a/0x170
> [<ffffffff8117ea96>] SyS_write+0x46/0xb0
> [<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
> Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
> RIP [<ffffffff81451115>] process_echoes+0x15/0x70
> RSP <ffff88000d233d50>
> CR2: 0000000000002280
> ---[ end trace cec672c0d4b54e81 ]---
> Kernel panic - not syncing: Fatal exception
> Kernel Offset: disabled
> ---[ end Kernel panic - not syncing: Fatal exception
Yes, bisection would be great, if you can do it. I would blame the only
tty patch in the release,
tty-prevent-ldisc-drivers-from-re-using-stale-tty-fields.patch, but that
would be odd.
Oops, nope, that would be it, the merge happened badly, I applied a
chunk in the wrong place, ugh. Let me go fix that patch up now...
greg k-h
^ permalink raw reply
* Re: [PATCH 10/31] Avoid that scsi_exit_rq() triggers a use-after-free
From: Hannes Reinecke @ 2017-05-24 5:58 UTC (permalink / raw)
To: Bart Van Assche, Martin K . Petersen, James Bottomley
Cc: linux-scsi, linux-block, Scott Bauer, Christoph Hellwig, Jan Kara,
Hannes Reinecke, stable
In-Reply-To: <20170524003420.5381-11-bart.vanassche@sandisk.com>
On 05/24/2017 02:33 AM, Bart Van Assche wrote:
> Dereferencing shost from scsi_exit_rq() is not safe because the
> SCSI host may already have been freed when scsi_exit_rq() is
> called. Increasing the shost reference count in scsi_init_rq()
> and dropping that reference in scsi_exit_rq() is nontrivial since
> scsi_host_dev_release() may sleep and since scsi_exit_rq() may
> be called from interrupt context. Since scsi_exit_rq() only needs
> a single bit from shost, copy that bit into struct scsi_cmnd.
>
> Reported-by: Scott Bauer <scott.bauer@intel.com>
> Fixes: e9c787e65c0c ("scsi: allocate scsi_cmnd structures as part of struct request")
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Cc: Scott Bauer <scott.bauer@intel.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Hannes Reinecke <hare@suse.com>
> Cc: <stable@vger.kernel.org>
> ---
> drivers/scsi/scsi_lib.c | 43 +++++++++++++++++++++++++------------------
> include/scsi/scsi_cmnd.h | 1 +
> 2 files changed, 26 insertions(+), 18 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 09/31] block: Avoid that blk_exit_rl() triggers a use-after-free
From: Hannes Reinecke @ 2017-05-24 5:55 UTC (permalink / raw)
To: Bart Van Assche, Martin K . Petersen, James Bottomley
Cc: linux-scsi, linux-block, Jens Axboe, Christoph Hellwig, Tejun Heo,
Jan Kara, Hannes Reinecke, stable
In-Reply-To: <20170524003420.5381-10-bart.vanassche@sandisk.com>
On 05/24/2017 02:33 AM, Bart Van Assche wrote:
> Since the introduction of the .init_rq_fn() and .exit_rq_fn() it
> is essential that the memory allocated for struct request_queue
> stays around until all blk_exit_rl() calls have finished. Hence
> make blk_init_rl() take a reference on struct request_queue.
>
> This patch fixes the following crash:
>
> general protection fault: 0000 [#2] SMP
> CPU: 3 PID: 28 Comm: ksoftirqd/3 Tainted: G D 4.12.0-rc2-dbg+ #2
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
> task: ffff88013a108040 task.stack: ffffc9000071c000
> RIP: 0010:free_request_size+0x1a/0x30
> RSP: 0018:ffffc9000071fd38 EFLAGS: 00010202
> RAX: 6b6b6b6b6b6b6b6b RBX: ffff880067362a88 RCX: 0000000000000003
> RDX: ffff880067464178 RSI: ffff880067362a88 RDI: ffff880135ea4418
> RBP: ffffc9000071fd40 R08: 0000000000000000 R09: 0000000100180009
> R10: ffffc9000071fd38 R11: ffffffff81110800 R12: ffff88006752d3d8
> R13: ffff88006752d3d8 R14: ffff88013a108040 R15: 000000000000000a
> FS: 0000000000000000(0000) GS:ffff88013fd80000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007fa8ec1edb00 CR3: 0000000138ee8000 CR4: 00000000001406e0
> Call Trace:
> mempool_destroy.part.10+0x21/0x40
> mempool_destroy+0xe/0x10
> blk_exit_rl+0x12/0x20
> blkg_free+0x4d/0xa0
> __blkg_release_rcu+0x59/0x170
> rcu_process_callbacks+0x260/0x4e0
> __do_softirq+0x116/0x250
> smpboot_thread_fn+0x123/0x1e0
> kthread+0x109/0x140
> ret_from_fork+0x31/0x40
>
> Fixes: commit e9c787e65c0c ("scsi: allocate scsi_cmnd structures as part of struct request")
> Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
> Cc: Jens Axboe <axboe@fb.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Jan Kara <jack@suse.cz>
> Cc: Hannes Reinecke <hare@suse.com>
> Cc: <stable@vger.kernel.org> # v4.11+
> ---
> block/blk-cgroup.c | 2 +-
> block/blk-core.c | 10 ++++++++--
> block/blk-sysfs.c | 2 +-
> block/blk.h | 2 +-
> 4 files changed, 11 insertions(+), 5 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* [PATCH 1/6] sched: fair: Call cpufreq update util handlers less frequently on UP
From: Viresh Kumar @ 2017-05-24 5:29 UTC (permalink / raw)
To: Ingo Molnar, Peter Zijlstra
Cc: Viresh Kumar, linaro-kernel, linux-kernel, Vincent Guittot,
4 . 6+
In-Reply-To: <cover.1495603536.git.viresh.kumar@linaro.org>
For SMP systems, update_load_avg() calls the cpufreq update util
handlers only for the top level cfs_rq (i.e. rq->cfs).
But that is not the case for UP systems. update_load_avg() calls util
handler for any cfs_rq for which it is called. This would result in way
too many calls from the scheduler to the cpufreq governors when
CONFIG_FAIR_GROUP_SCHED is enabled.
Reduce the frequency of these calls by copying the behavior from the SMP
case, i.e. Only call util handlers for the top level cfs_rq.
Fixes: 536bd00cdbb7 ("sched/fair: Fix !CONFIG_SMP kernel cpufreq governor breakage")
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
I wasn't sure if we would like to mark Stable for this or not.
Cc: 4.6+ <stable@vger.kernel.org> # 4.6+
---
kernel/sched/fair.c | 48 ++++++++++++++++++++++++------------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 47a0c552c77b..a0a97497c400 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2728,6 +2728,29 @@ static inline void update_cfs_shares(struct sched_entity *se)
}
#endif /* CONFIG_FAIR_GROUP_SCHED */
+static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
+{
+ if (&this_rq()->cfs == cfs_rq) {
+ /*
+ * There are a few boundary cases this might miss but it should
+ * get called often enough that that should (hopefully) not be
+ * a real problem -- added to that it only calls on the local
+ * CPU, so if we enqueue remotely we'll miss an update, but
+ * the next tick/schedule should update.
+ *
+ * It will not get called when we go idle, because the idle
+ * thread is a different class (!fair), nor will the utilization
+ * number include things like RT tasks.
+ *
+ * As is, the util number is not freq-invariant (we'd have to
+ * implement arch_scale_freq_capacity() for that).
+ *
+ * See cpu_util().
+ */
+ cpufreq_update_util(rq_of(cfs_rq), 0);
+ }
+}
+
#ifdef CONFIG_SMP
/*
* Approximate:
@@ -3215,29 +3238,6 @@ static inline void set_tg_cfs_propagate(struct cfs_rq *cfs_rq) {}
#endif /* CONFIG_FAIR_GROUP_SCHED */
-static inline void cfs_rq_util_change(struct cfs_rq *cfs_rq)
-{
- if (&this_rq()->cfs == cfs_rq) {
- /*
- * There are a few boundary cases this might miss but it should
- * get called often enough that that should (hopefully) not be
- * a real problem -- added to that it only calls on the local
- * CPU, so if we enqueue remotely we'll miss an update, but
- * the next tick/schedule should update.
- *
- * It will not get called when we go idle, because the idle
- * thread is a different class (!fair), nor will the utilization
- * number include things like RT tasks.
- *
- * As is, the util number is not freq-invariant (we'd have to
- * implement arch_scale_freq_capacity() for that).
- *
- * See cpu_util().
- */
- cpufreq_update_util(rq_of(cfs_rq), 0);
- }
-}
-
/*
* Unsigned subtract and clamp on underflow.
*
@@ -3483,7 +3483,7 @@ update_cfs_rq_load_avg(u64 now, struct cfs_rq *cfs_rq, bool update_freq)
static inline void update_load_avg(struct sched_entity *se, int not_used1)
{
- cpufreq_update_util(rq_of(cfs_rq_of(se)), 0);
+ cfs_rq_util_change(cfs_rq_of(se));
}
static inline void
--
2.13.0.70.g6367777092d9
^ permalink raw reply related
* Re: [PATCH 4.4 000/103] 4.4.70-stable review
From: Guenter Roeck @ 2017-05-24 4:01 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, shuahkh, patches, ben.hutchings, stable
In-Reply-To: <20170523200856.903752266@linuxfoundation.org>
On 05/23/2017 01:08 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.70 release.
> There are 103 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Thu May 25 20:08:25 UTC 2017.
> Anything received after that time might be too late.
>
Early feedback: All x86_64 images are crashing. Let me know if you need me to bisect.
Guenter
---
...
EXT4-fs (sda): re-mounted. Opts: errors=remount-ro,data=ordered
BUG: unable to handle kernel paging request at 0000000000002280
IP: [<ffffffff81451115>] process_echoes+0x15/0x70
PGD da68067 PUD d991067 PMD 0
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 400 Comm: bootlogd Not tainted 4.4.70-rc1-yocto-standard+ #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-prebuilt.qemu-project.org 04/01/2014
task: ffff88000d159bc0 ti: ffff88000d230000 task.ti: ffff88000d230000
RIP: 0010:[<ffffffff81451115>] [<ffffffff81451115>] process_echoes+0x15/0x70
RSP: 0018:ffff88000d233d50 EFLAGS: 00000202
RAX: ffff88000dd950d8 RBX: 0000000000000000 RCX: 0000000000000007
RDX: ffff88000dd4a400 RSI: ffff88000d91b700 RDI: ffff88000dd95000
RBP: ffff88000d233d68 R08: 00007ffffffff000 R09: ffff88000eeb91c8
R10: 00007fffc9dc3f70 R11: 0000000000000246 R12: 0000000000000007
R13: 0000000000603574 R14: 0000000000000007 R15: ffff88000d91b700
FS: 00007f973601b700(0000) GS:ffff88000fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000002280 CR3: 000000000d953000 CR4: 00000000003406f0
Stack:
ffff88000dd95000 0000000000000007 0000000000603574 ffff88000d233df0
ffffffff814515b7 0000004100000022 ffff88000d91b700 ffff88000dd950d8
ffff88000dd4a400 ffff88000d91b700 0000000000000000 ffff88000d159bc0
Call Trace:
[<ffffffff814515b7>] n_tty_write+0x97/0x4e0
[<ffffffff8108e710>] ? __wake_up_sync+0x20/0x20
[<ffffffff8144dae6>] tty_write+0x1a6/0x2d0
[<ffffffff81451520>] ? n_tty_open+0xe0/0xe0
[<ffffffff8117d6e8>] __vfs_write+0x28/0xe0
[<ffffffff81077145>] ? preempt_count_add+0x85/0xd0
[<ffffffff81199abe>] ? __fd_install+0x5e/0x110
[<ffffffff81199969>] ? __alloc_fd+0xc9/0x180
[<ffffffff8117dcff>] ? rw_verify_area+0x4f/0xe0
[<ffffffff8117df3a>] vfs_write+0x9a/0x170
[<ffffffff8117ea96>] SyS_write+0x46/0xb0
[<ffffffff8172db17>] entry_SYSCALL_64_fastpath+0x12/0x66
Code: 8b 40 48 48 85 c0 74 07 55 48 89 e5 ff d0 5d c3 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 53 48 8b 9f 80 02 00 00 <48> 8b 83 80 22 00 00 48 39 43 28 74 3a 4c 8d ab b0 22 00 00 49
RIP [<ffffffff81451115>] process_echoes+0x15/0x70
RSP <ffff88000d233d50>
CR2: 0000000000002280
---[ end trace cec672c0d4b54e81 ]---
Kernel panic - not syncing: Fatal exception
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox