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... 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
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.4.275-rc1
Masami Hiramatsu mhiramat@kernel.org arm: kprobes: Allow to handle reentered kprobe on single-stepping
Juergen Gross jgross@suse.com xen/events: reset active flag for lateeoi events later
Christian König christian.koenig@amd.com drm/nouveau: fix dma_address check for CPU/GPU sync
ManYi Li limanyi@uniontech.com scsi: sr: Return appropriate error code when disk is ejected
-------------
Diffstat:
Makefile | 4 ++-- arch/arm/probes/kprobes/core.c | 6 ++++++ drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- drivers/scsi/sr.c | 2 ++ drivers/xen/events/events_base.c | 23 +++++++++++++++++++---- 5 files changed, 31 insertions(+), 8 deletions(-)
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; }
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-christia... 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 */
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)
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();
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...
Tested-by: Pavel Machek (CIP) pavel@denx.de
Best regards, Pavel
On Fri, 09 Jul 2021 15:18:12 +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.
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... 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
Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.4.275-rc1
Masami Hiramatsu mhiramat@kernel.org arm: kprobes: Allow to handle reentered kprobe on single-stepping
Juergen Gross jgross@suse.com xen/events: reset active flag for lateeoi events later
Christian König christian.koenig@amd.com drm/nouveau: fix dma_address check for CPU/GPU sync
ManYi Li limanyi@uniontech.com scsi: sr: Return appropriate error code when disk is ejected
Diffstat:
Makefile | 4 ++-- arch/arm/probes/kprobes/core.c | 6 ++++++ drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- drivers/scsi/sr.c | 2 ++ drivers/xen/events/events_base.c | 23 +++++++++++++++++++---- 5 files changed, 31 insertions(+), 8 deletions(-)
All tests passing for Tegra ...
Test results for stable-v4.4: 6 builds: 6 pass, 0 fail 12 boots: 12 pass, 0 fail 30 tests: 30 pass, 0 fail
Linux version: 4.4.275-rc1-gaaf5d64b8bc0 Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
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... 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
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
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... 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
linux-stable-mirror@lists.linaro.org
-
Greg Kroah-Hartman -
Guenter Roeck -
Jon Hunter -
Naresh Kamboju -
Pavel Machek -
Shuah Khan