4.4.275-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainercover 4.4.275-rc1 review
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
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <[email protected]>
Linux 4.4.275-rc1
Masami Hiramatsu <[email protected]>
arm: kprobes: Allow to handle reentered kprobe on single-stepping
Juergen Gross <[email protected]>
xen/events: reset active flag for lateeoi events later
Christian König <[email protected]>
drm/nouveau: fix dma_address check for CPU/GPU sync
ManYi Li <[email protected]>
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(-)
Greg Kroah-Hartman
maintainerPATCH 1/4 scsi: sr: Return appropriate error code when disk is ejected
From: ManYi Li <[email protected]>
[ 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.
--- drivers/scsi/sr.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/scsi/sr.c +2 -0
@@ -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 ; }
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 2/4 drm/nouveau: fix dma_address check for CPU/GPU sync
In reply to Greg Kroah-HartmanFrom: Christian König <[email protected]>
[ Upstream commit d330099115597bbc238d6758a4930e72b49ea9ba ]
AGP for example doesn't have a dma_address array.
--- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/gpu/drm/nouveau/nouveau_bo.c +2 -2
@@ -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 */
Signature · 1 line
2.30.2
Greg Kroah-Hartman
maintainerPATCH 3/4 xen/events: reset active flag for lateeoi events later
In reply to Greg Kroah-HartmanFrom: Juergen Gross <[email protected]>
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.
--- drivers/xen/events/events_base.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
drivers/xen/events/events_base.c +19 -4
@@ -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 irstruct 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)
Greg Kroah-Hartman
maintainerPATCH 4/4 arm: kprobes: Allow to handle reentered kprobe on single-stepping
In reply to Greg Kroah-HartmanFrom: Masami Hiramatsu <[email protected]>
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.
--- arch/arm/probes/kprobes/core.c | 6 ++++++ 1 file changed, 6 insertions(+)
arch/arm/probes/kprobes/core.c +6 -0
@@ -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!
Quoted 4 lines
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
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Quoted 39 lines · Greg Kroah-Hartman
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.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:Greg Kroah-Hartman <[email protected]>
Linux 4.4.275-rc1Masami Hiramatsu <[email protected]>
arm: kprobes: Allow to handle reentered kprobe on single-steppingJuergen Gross <[email protected]>
xen/events: reset active flag for lateeoi events laterChristian König <[email protected]>
drm/nouveau: fixdma_addresscheck for CPU/GPU syncManYi Li <[email protected]>
scsi: sr: Return appropriate error code when disk is ejected-------------
Quoted 11 lines
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 failLinux version: 4.4.275-rc1-gaaf5d64b8bc0
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra30-cardhu-a04
Jon
Quoted 9 lines · Greg Kroah-Hartman
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:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.275-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.4.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
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
Guenter
Quoted 10 lines · Greg Kroah-Hartman
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:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.275-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-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\"
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