The GC860 has one GPU device which has a 2d and 3d core. In this case
we want to expose perfmon information for both cores.
The driver has one array which contains all possible perfmon domains
with some meta data - doms_meta. Here we can see that for the GC860
two elements of that array are relevant:
doms_3d: is at index 0 in the doms_meta array with 8 perfmon domains
doms_2d: is at index 1 in the doms_meta array with 1 perfmon domain
The userspace driver wants to get a list of all perfmon domains and
their perfmon signals. This is done by iterating over all domains and
their signals. If the userspace driver wants to access the domain with
id 8 the kernel driver fails and returns invalid data from doms_3d with
and invalid offset.
This results in:
Unable to handle kernel paging request at virtual address 00000000
On such a device it is not possible to use the userspace driver at all.
The fix for this off-by-one error is quite simple.
Reported-by: Paul Cercueil <paul(a)crapouillou.net>
Tested-by: Paul Cercueil <paul(a)crapouillou.net>
Fixes: ed1dd899baa3 ("drm/etnaviv: rework perfmon query infrastructure")
Cc: stable(a)vger.kernel.org
Signed-off-by: Christian Gmeiner <christian.gmeiner(a)gmail.com>
---
drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
index e6795bafcbb9..35f7171e779a 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_perfmon.c
@@ -453,7 +453,7 @@ static const struct etnaviv_pm_domain *pm_domain(const struct etnaviv_gpu *gpu,
if (!(gpu->identity.features & meta->feature))
continue;
- if (meta->nr_domains < (index - offset)) {
+ if ((meta->nr_domains - 1) < (index - offset)) {
offset += meta->nr_domains;
continue;
}
--
2.26.2
From: Wu Bo <wubo40(a)huawei.com>
[ Upstream commit 83c6f2390040f188cc25b270b4befeb5628c1aee ]
If the __copy_from_user function failed we need to call sg_remove_request
in sg_write.
Link: https://lore.kernel.org/r/610618d9-e983-fd56-ed0f-639428343af7@huawei.com
Acked-by: Douglas Gilbert <dgilbert(a)interlog.com>
Signed-off-by: Wu Bo <wubo40(a)huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
[groeck: Backport to v5.4.y and older kernels]
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
---
This patch fixes CVE-2020-12770, and the problem it fixes looks like a valid bug.
Please apply to v5.4.y and older kernel branches.
drivers/scsi/sg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 94af30f768f7..9c6bf13daaee 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -689,8 +689,10 @@ sg_write(struct file *filp, const char __user *buf, size_t count, loff_t * ppos)
hp->flags = input_size; /* structure abuse ... */
hp->pack_id = old_hdr.pack_id;
hp->usr_ptr = NULL;
- if (__copy_from_user(cmnd, buf, cmd_size))
+ if (__copy_from_user(cmnd, buf, cmd_size)) {
+ sg_remove_request(sfp, srp);
return -EFAULT;
+ }
/*
* SG_DXFER_TO_FROM_DEV is functionally equivalent to SG_DXFER_FROM_DEV,
* but is is possible that the app intended SG_DXFER_TO_DEV, because there
--
2.17.1
Please see the bisection report below about a boot failure.
Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.
It appears to be due to the fact that the network interface is
failing to get brought up:
[ 114.385000] Waiting up to 10 more seconds for network.
[ 124.355000] Sending DHCP requests ...#
..#
.#
timed out!
[ 212.355000] IP-Config: Reopening network devices...
[ 212.365000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
#
I guess the board would boot fine without network if it didn't
have ip=dhcp in the command line, so it's not strictly a kernel
boot failure but still an ethernet issue.
There wasn't any failure reported by kernelci on linux-4.9.y so
maybe this patch was applied by mistake on linux-4.4.y but I
haven't investigated enough to prove this.
Thanks,
Guillaume
On 10/05/2020 18:27, kernelci.org bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis *
> * that you may be involved with the breaking commit it has *
> * found. No manual investigation has been done to verify it, *
> * and the root cause of the problem may be somewhere else. *
> * *
> * If you do send a fix, please include this trailer: *
> * Reported-by: "kernelci.org bot" <bot(a)kernelci.org> *
> * *
> * Hope this helps! *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
>
> stable/linux-4.4.y bisection: baseline.login on at91-sama5d4_xplained
>
> Summary:
> Start: e157447efd85b Linux 4.4.223
> Plain log: https://storage.kernelci.org/stable/linux-4.4.y/v4.4.223/arm/multi_v7_defco…
> HTML log: https://storage.kernelci.org/stable/linux-4.4.y/v4.4.223/arm/multi_v7_defco…
> Result: 0d1951fa23ba0 net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS
>
> Checks:
> revert: PASS
> verify: PASS
>
> Parameters:
> Tree: stable
> URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> Branch: linux-4.4.y
> Target: at91-sama5d4_xplained
> CPU arch: arm
> Lab: lab-baylibre
> Compiler: gcc-8
> Config: multi_v7_defconfig
> Test case: baseline.login
>
> Breaking commit found:
>
> -------------------------------------------------------------------------------
> commit 0d1951fa23ba0d35a4c5498ff28d1c5206d6fcdd
> Author: Florian Fainelli <f.fainelli(a)gmail.com>
> Date: Mon Jan 18 19:33:06 2016 -0800
>
> net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS
>
> commit d5c3d84657db57bd23ecd58b97f1c99dd42a7b80 upstream.
>
> Commit 2c7b49212a86 ("phy: fix the use of PHY_IGNORE_INTERRUPT") changed
> a hunk in phy_state_machine() in the PHY_RUNNING case which was not
> needed. The change essentially makes the PHY library treat PHY devices
> with PHY_IGNORE_INTERRUPT to keep polling for the PHY device, even
> though the intent is not to do it.
>
> Fix this by reverting that specific hunk, which makes the PHY state
> machine wait for state changes, and stay in the PHY_RUNNING state for as
> long as needed.
>
> Fixes: 2c7b49212a86 ("phy: fix the use of PHY_IGNORE_INTERRUPT")
> Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com>
> Signed-off-by: David S. Miller <davem(a)davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 7d2cf015c5e76..b242bec834f4b 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -912,10 +912,10 @@ void phy_state_machine(struct work_struct *work)
> phydev->adjust_link(phydev->attached_dev);
> break;
> case PHY_RUNNING:
> - /* Only register a CHANGE if we are polling or ignoring
> - * interrupts and link changed since latest checking.
> + /* Only register a CHANGE if we are polling and link changed
> + * since latest checking.
> */
> - if (!phy_interrupt_is_valid(phydev)) {
> + if (phydev->irq == PHY_POLL) {
> old_link = phydev->link;
> err = phy_read_status(phydev);
> if (err)
> @@ -1015,8 +1015,13 @@ void phy_state_machine(struct work_struct *work)
> dev_dbg(&phydev->dev, "PHY state change %s -> %s\n",
> phy_state_to_str(old_state), phy_state_to_str(phydev->state));
>
> - queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
> - PHY_STATE_TIME * HZ);
> + /* Only re-schedule a PHY state machine change if we are polling the
> + * PHY, if PHY_IGNORE_INTERRUPT is set, then we will be moving
> + * between states from phy_mac_interrupt()
> + */
> + if (phydev->irq == PHY_POLL)
> + queue_delayed_work(system_power_efficient_wq, &phydev->state_queue,
> + PHY_STATE_TIME * HZ);
> }
>
> void phy_mac_interrupt(struct phy_device *phydev, int new_link)
> -------------------------------------------------------------------------------
>
>
> Git bisection log:
>
> -------------------------------------------------------------------------------
> git bisect start
> # good: [b63f449e18b130fdc372b9717e72c19b83fc4876] Linux 4.4.222
> git bisect good b63f449e18b130fdc372b9717e72c19b83fc4876
> # bad: [e157447efd85bb2e6f8deaabbb62663bccd9bad2] Linux 4.4.223
> git bisect bad e157447efd85bb2e6f8deaabbb62663bccd9bad2
> # bad: [5733a9f4a3df384097c92c532aed34bc698a9acd] net: dsa: slave: fix of-node leak and phy priority
> git bisect bad 5733a9f4a3df384097c92c532aed34bc698a9acd
> # good: [1ce6993b857318a4b8c674b1bbaaf79aced34136] net/mlx5e: Fix blue flame quota logic
> git bisect good 1ce6993b857318a4b8c674b1bbaaf79aced34136
> # good: [c32532162f8ea4beed50a20cf4f9b205c75fe1b1] serial: samsung: Fix possible out of bounds access on non-DT platform
> git bisect good c32532162f8ea4beed50a20cf4f9b205c75fe1b1
> # good: [25e8aad6f491da6ae330148da09585371a3790f2] Revert "ACPI / LPSS: allow to use specific PM domain during ->probe()"
> git bisect good 25e8aad6f491da6ae330148da09585371a3790f2
> # good: [2f3e56e4b6020812350190f1cada230d790ce0e8] powerpc/tm: Fix stack pointer corruption in __tm_recheckpoint()
> git bisect good 2f3e56e4b6020812350190f1cada230d790ce0e8
> # bad: [0d1951fa23ba0d35a4c5498ff28d1c5206d6fcdd] net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS
> git bisect bad 0d1951fa23ba0d35a4c5498ff28d1c5206d6fcdd
> # good: [4ebef63e925e37f5de2f9da8fc86a545e4e0b945] sctp: fix the transports round robin issue when init is retransmitted
> git bisect good 4ebef63e925e37f5de2f9da8fc86a545e4e0b945
> # good: [c175435fdf50c81ca2b6576f090cba31c3489209] NFC: nci: memory leak in nci_core_conn_create()
> git bisect good c175435fdf50c81ca2b6576f090cba31c3489209
> # first bad commit: [0d1951fa23ba0d35a4c5498ff28d1c5206d6fcdd] net: phy: Avoid polling PHY with PHY_IGNORE_INTERRUPTS
> -------------------------------------------------------------------------------
>
kernel test robot found a warning when build bpf selftest for 5.4.y stable
tree:
prog_tests/stacktrace_build_id_nmi.c:55:3: error: label ‘cleanup’ used but not defined
goto cleanup;
^~~~
This is because we are lacking upstream commit dde53c1b763b
("selftests/bpf: Convert few more selftest to skeletons"). But this
commit is too large and need more backports. To fix it, the
easiest way is just use the current goto label 'close_prog'.
Reported-by: kernel test robot <rong.a.chen(a)intel.com>
Fixes: da43712a7262 ("selftests/bpf: Skip perf hw events test if the setup disabled it")
Signed-off-by: Hangbin Liu <liuhangbin(a)gmail.com>
---
.../testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c b/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c
index 1735faf17536..437cb93e72ac 100644
--- a/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c
+++ b/tools/testing/selftests/bpf/prog_tests/stacktrace_build_id_nmi.c
@@ -52,7 +52,7 @@ void test_stacktrace_build_id_nmi(void)
if (pmu_fd < 0 && errno == ENOENT) {
printf("%s:SKIP:no PERF_COUNT_HW_CPU_CYCLES\n", __func__);
test__skip();
- goto cleanup;
+ goto close_prog;
}
if (CHECK(pmu_fd < 0, "perf_event_open", "err %d errno %d\n",
pmu_fd, errno))
--
2.25.4
Testing with Loopback I found, that after a Loopback LUN
has executed a TMR, I can no longer unlink the LUN.
The rm command hangs in transport_clear_lun_ref() at
wait_for_completion(&lun->lun_shutdown_comp)
The reason is, that transport_lun_remove_cmd() is not
called at the end of target_tmr_work().
It seems, that in other fabrics this call happens implicitly
when the fabric drivers call transport_generic_free_cmd()
during their ->queue_tm_rsp().
Unfortunately Loopback seems to not comply to the common way
of calling transport_generic_free_cmd() from ->queue_*().
Instead it calls transport_generic_free_cmd() from its
->check_stop_free() only.
But the ->check_stop_free() is called by
transport_cmd_check_stop_to_fabric() after it has reset the
se_cmd->se_lun pointer.
Therefore the following transport_generic_free_cmd() skips the
transport_lun_remove_cmd().
So this patch re-adds the transport_lun_remove_cmd() at the end
of target_tmr_work(), which was removed during commit
2c9fa49e100f962af988f1c0529231bf14905cda
"scsi: target/core: Make ABORT and LUN RESET handling synchronous"
For fabrics using transport_generic_free_cmd() in the usual way
the double call to transport_lun_remove_cmd() doesn't harm, as
transport_lun_remove_cmd() checks for this situation and does
not release lun_ref twice.
Fixes: 2c9fa49e100f ("scsi: target/core: Make ABORT and LUN RESET handling synchronous")
Cc: stable(a)vger.kernel.org
Signed-off-by: Bodo Stroesser <bstroesser(a)ts.fujitsu.com>
Tested-by: Bryant G. Ly <bryangly(a)gmail.com>
Reviewed-by: Bart van Assche <bvanassche(a)acm.org>
---
v2:
- Resend of the same patch with added tags "Fixes:",
"Cc: stable@.." and "Reviewed-by:"
drivers/target/target_core_transport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 594b724bbf79..264a822c0bfa 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -3350,6 +3350,7 @@ static void target_tmr_work(struct work_struct *work)
cmd->se_tfo->queue_tm_rsp(cmd);
+ transport_lun_remove_cmd(cmd);
transport_cmd_check_stop_to_fabric(cmd);
return;
--
2.12.3