* [PATCH 4.4 1/4] scsi: sr: Return appropriate error code when disk is ejected
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
@ 2021-07-09 13:18 ` Greg Kroah-Hartman
2021-07-09 13:18 ` [PATCH 4.4 2/4] drm/nouveau: fix dma_address check for CPU/GPU sync Greg Kroah-Hartman
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Greg Kroah-Hartman @ 2021-07-09 13:18 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, ManYi Li, Martin K. Petersen, Sasha Levin
From: ManYi Li <limanyi@uniontech.com>
[ Upstream commit 7dd753ca59d6c8cc09aa1ed24f7657524803c7f3 ]
Handle a reported media event code of 3. This indicates that the media has
been removed from the drive and user intervention is required to proceed.
Return DISK_EVENT_EJECT_REQUEST in that case.
Link: https://lore.kernel.org/r/20210611094402.23884-1-limanyi@uniontech.com
Signed-off-by: ManYi Li <limanyi@uniontech.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/sr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 7dd4d9ded249..6e31cedf0b6c 100644
--- a/drivers/scsi/sr.c
+++ b/drivers/scsi/sr.c
@@ -216,6 +216,8 @@ static unsigned int sr_get_events(struct scsi_device *sdev)
return DISK_EVENT_EJECT_REQUEST;
else if (med->media_event_code == 2)
return DISK_EVENT_MEDIA_CHANGE;
+ else if (med->media_event_code == 3)
+ return DISK_EVENT_EJECT_REQUEST;
return 0;
}
--
2.30.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 4.4 2/4] drm/nouveau: fix dma_address check for CPU/GPU sync
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
2021-07-09 13:18 ` [PATCH 4.4 1/4] scsi: sr: Return appropriate error code when disk is ejected Greg Kroah-Hartman
@ 2021-07-09 13:18 ` Greg Kroah-Hartman
2021-07-09 13:18 ` [PATCH 4.4 3/4] xen/events: reset active flag for lateeoi events later Greg Kroah-Hartman
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Greg Kroah-Hartman @ 2021-07-09 13:18 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Christian König, Alex Deucher,
Sasha Levin
From: Christian König <christian.koenig@amd.com>
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210614110517.1624-1-christian.koenig@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 78f520d05de9..58c310930bf2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -458,7 +458,7 @@ nouveau_bo_sync_for_device(struct nouveau_bo *nvbo)
struct ttm_dma_tt *ttm_dma = (struct ttm_dma_tt *)nvbo->bo.ttm;
int i;
- if (!ttm_dma)
+ if (!ttm_dma || !ttm_dma->dma_address)
return;
/* Don't waste time looping if the object is coherent */
@@ -478,7 +478,7 @@ nouveau_bo_sync_for_cpu(struct nouveau_bo *nvbo)
struct ttm_dma_tt *ttm_dma = (struct ttm_dma_tt *)nvbo->bo.ttm;
int i;
- if (!ttm_dma)
+ if (!ttm_dma || !ttm_dma->dma_address)
return;
/* Don't waste time looping if the object is coherent */
--
2.30.2
^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 4.4 3/4] xen/events: reset active flag for lateeoi events later
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
2021-07-09 13:18 ` [PATCH 4.4 1/4] scsi: sr: Return appropriate error code when disk is ejected Greg Kroah-Hartman
2021-07-09 13:18 ` [PATCH 4.4 2/4] drm/nouveau: fix dma_address check for CPU/GPU sync Greg Kroah-Hartman
@ 2021-07-09 13:18 ` Greg Kroah-Hartman
2021-07-09 13:18 ` [PATCH 4.4 4/4] arm: kprobes: Allow to handle reentered kprobe on single-stepping Greg Kroah-Hartman
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Greg Kroah-Hartman @ 2021-07-09 13:18 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Julien Grall, Juergen Gross, Boris Ostrovsky
From: Juergen Gross <jgross@suse.com>
commit 3de218ff39b9e3f0d453fe3154f12a174de44b25 upstream.
In order to avoid a race condition for user events when changing
cpu affinity reset the active flag only when EOI-ing the event.
This is working fine as all user events are lateeoi events. Note that
lateeoi_ack_mask_dynirq() is not modified as there is no explicit call
to xen_irq_lateeoi() expected later.
Cc: stable@vger.kernel.org
Reported-by: Julien Grall <julien@xen.org>
Fixes: b6622798bc50b62 ("xen/events: avoid handling the same event on two cpus at the same time")
Tested-by: Julien Grall <julien@xen.org>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrvsky@oracle.com>
Link: https://lore.kernel.org/r/20210623130913.9405-1-jgross@suse.com
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/xen/events/events_base.c | 23 +++++++++++++++++++----
1 file changed, 19 insertions(+), 4 deletions(-)
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -533,6 +533,9 @@ static void xen_irq_lateeoi_locked(struc
}
info->eoi_time = 0;
+
+ /* is_active hasn't been reset yet, do it now. */
+ smp_store_release(&info->is_active, 0);
do_unmask(info, EVT_MASK_REASON_EOI_PENDING);
}
@@ -1777,10 +1780,22 @@ static void lateeoi_ack_dynirq(struct ir
struct irq_info *info = info_for_irq(data->irq);
evtchn_port_t evtchn = info ? info->evtchn : 0;
- if (VALID_EVTCHN(evtchn)) {
- do_mask(info, EVT_MASK_REASON_EOI_PENDING);
- ack_dynirq(data);
- }
+ if (!VALID_EVTCHN(evtchn))
+ return;
+
+ do_mask(info, EVT_MASK_REASON_EOI_PENDING);
+
+ if (unlikely(irqd_is_setaffinity_pending(data)) &&
+ likely(!irqd_irq_disabled(data))) {
+ do_mask(info, EVT_MASK_REASON_TEMPORARY);
+
+ clear_evtchn(evtchn);
+
+ irq_move_masked_irq(data);
+
+ do_unmask(info, EVT_MASK_REASON_TEMPORARY);
+ } else
+ clear_evtchn(evtchn);
}
static void lateeoi_mask_ack_dynirq(struct irq_data *data)
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH 4.4 4/4] arm: kprobes: Allow to handle reentered kprobe on single-stepping
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2021-07-09 13:18 ` [PATCH 4.4 3/4] xen/events: reset active flag for lateeoi events later Greg Kroah-Hartman
@ 2021-07-09 13:18 ` Greg Kroah-Hartman
2021-07-09 14:57 ` [PATCH 4.4 0/4] 4.4.275-rc1 review Pavel Machek
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Greg Kroah-Hartman @ 2021-07-09 13:18 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Masami Hiramatsu, Jon Medhurst, huangshaobo
From: Masami Hiramatsu <mhiramat@kernel.org>
commit f3fbd7ec62dec1528fb8044034e2885f2b257941 upstream.
This is arm port of commit 6a5022a56ac3 ("kprobes/x86: Allow to
handle reentered kprobe on single-stepping")
Since the FIQ handlers can interrupt in the single stepping
(or preparing the single stepping, do_debug etc.), we should
consider a kprobe is hit in the NMI handler. Even in that
case, the kprobe is allowed to be reentered as same as the
kprobes hit in kprobe handlers
(KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE).
The real issue will happen when a kprobe hit while another
reentered kprobe is processing (KPROBE_REENTER), because
we already consumed a saved-area for the previous kprobe.
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Fixes: 24ba613c9d6c ("ARM kprobes: core code")
Cc: stable@vger.kernel.org #v2.6.25~v4.11
Signed-off-by: huangshaobo <huangshaobo6@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/probes/kprobes/core.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/arch/arm/probes/kprobes/core.c
+++ b/arch/arm/probes/kprobes/core.c
@@ -270,6 +270,7 @@ void __kprobes kprobe_handler(struct pt_
switch (kcb->kprobe_status) {
case KPROBE_HIT_ACTIVE:
case KPROBE_HIT_SSDONE:
+ case KPROBE_HIT_SS:
/* A pre- or post-handler probe got us here. */
kprobes_inc_nmissed_count(p);
save_previous_kprobe(kcb);
@@ -278,6 +279,11 @@ void __kprobes kprobe_handler(struct pt_
singlestep(p, regs, kcb);
restore_previous_kprobe(kcb);
break;
+ case KPROBE_REENTER:
+ /* A nested probe was hit in FIQ, it is a BUG */
+ pr_warn("Unrecoverable kprobe detected at %p.\n",
+ p->addr);
+ /* fall through */
default:
/* impossible cases */
BUG();
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4.4 0/4] 4.4.275-rc1 review
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2021-07-09 13:18 ` [PATCH 4.4 4/4] arm: kprobes: Allow to handle reentered kprobe on single-stepping Greg Kroah-Hartman
@ 2021-07-09 14:57 ` Pavel Machek
2021-07-09 21:44 ` Shuah Khan
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: Pavel Machek @ 2021-07-09 14:57 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, linux, shuah, patches, lkft-triage,
pavel, jonathanh, f.fainelli, stable
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
Hi!
> This is the start of the stable review cycle for the 4.4.275 release.
> There are 4 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.4.y
Tested-by: Pavel Machek (CIP) <pavel@denx.de>
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4.4 0/4] 4.4.275-rc1 review
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
` (4 preceding siblings ...)
2021-07-09 14:57 ` [PATCH 4.4 0/4] 4.4.275-rc1 review Pavel Machek
@ 2021-07-09 21:44 ` Shuah Khan
2021-07-10 19:50 ` Guenter Roeck
2021-07-11 2:39 ` Naresh Kamboju
7 siblings, 0 replies; 9+ messages in thread
From: Shuah Khan @ 2021-07-09 21:44 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, linux, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable, Shuah Khan
On 7/9/21 7:18 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.275 release.
> There are 4 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 Sun, 11 Jul 2021 13:14:09 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.275-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
thanks,
-- Shuah
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4.4 0/4] 4.4.275-rc1 review
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
` (5 preceding siblings ...)
2021-07-09 21:44 ` Shuah Khan
@ 2021-07-10 19:50 ` Guenter Roeck
2021-07-11 2:39 ` Naresh Kamboju
7 siblings, 0 replies; 9+ messages in thread
From: Guenter Roeck @ 2021-07-10 19:50 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, torvalds, akpm, shuah, patches, lkft-triage, pavel,
jonathanh, f.fainelli, stable
On Fri, Jul 09, 2021 at 03:18:12PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.275 release.
> There are 4 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 Sun, 11 Jul 2021 13:14:09 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 160 pass: 160 fail: 0
Qemu test results:
total: 326 pass: 326 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 4.4 0/4] 4.4.275-rc1 review
2021-07-09 13:18 [PATCH 4.4 0/4] 4.4.275-rc1 review Greg Kroah-Hartman
` (6 preceding siblings ...)
2021-07-10 19:50 ` Guenter Roeck
@ 2021-07-11 2:39 ` Naresh Kamboju
7 siblings, 0 replies; 9+ messages in thread
From: Naresh Kamboju @ 2021-07-11 2:39 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: open list, Linus Torvalds, Andrew Morton, Guenter Roeck,
Shuah Khan, patches, lkft-triage, Pavel Machek, Jon Hunter,
Florian Fainelli, linux-stable
On Fri, 9 Jul 2021 at 18:48, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.4.275 release.
> There are 4 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 Sun, 11 Jul 2021 13:14:09 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.275-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
Regressions on arm64 noticed.
GOOD: v4.4.273
BAD: v4.4.274
Regressions found on arm64 juno-r2 and qemu_arm64 device.
ltp-containers-tests failed:
- netns_comm_ip_ipv6_ioctl
- netns_comm_ns_exec_ipv6_ioctl
- netns_comm_ip_ipv6_netlink
- netns_breakns_ns_exec_ipv6_netlink
- netns_breakns_ns_exec_ipv4_ioctl
- netns_netlink
- netns_comm_ip_ipv4_netlink
- netns_breakns_ns_exec_ipv4_netlink
- netns_breakns_ip_ipv6_netlink
- netns_breakns_ip_ipv4_ioctl
- netns_comm_ns_exec_ipv4_netlink
- netns_comm_ip_ipv4_ioctl
- netns_comm_ns_exec_ipv4_ioctl
- netns_comm_ns_exec_ipv6_netlink
- netns_breakns_ip_ipv6_ioctl
- netns_breakns_ip_ipv4_netlink
- netns_breakns_ns_exec_ipv6_ioctl
Test output log:
-----------------
module tun: overflow in relocation type 261 val fffffdfffc000654
open: No such device
netns_netlink.c:103: TBROK: adding interface failed
netns_breakns 1 TINFO: timeout per run is 0h 15m 0s
module veth: overflow in relocation type 261 val fffffdfffc040000
module veth: overflow in relocation type 261 val fffffdfffc080000
RTNETLINK answers: Operation not supported
netns_breakns 1 TBROK: unable to create veth pair devices
Cannot find device \"veth0\"
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
step to reproduce:
-------------------------
# boot qemu arm64 and run ltp netns_netlink test.
- cd /opt/ltp
- ./runltp -s netns_netlink
We have started the git bisection script to find the first bad commit
causing these LTP netns test failures.
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 9+ messages in thread