Hello,
I don't think you can update the loop index variable in
list_for_each_entry, because the mcro uses th index variable to get to the
next element. Perhaps list_for_each_entry_safe would be more suitable?
julia
---------- Forwarded message ----------
Date: Thu, 20 Sep 2018 04:30:13 +0800
From: kbuild test robot <lkp(a)intel.com>
To: kbuild(a)01.org
Cc: Julia Lawall <julia.lawall(a)lip6.fr>
Subject: Re: [PATCH 1/6] drm/dp_mst: Introduce
drm_dp_mst_connector_atomic_check()
CC: kbuild-all(a)01.org
In-Reply-To: <20180918230637.20700-2-lyude(a)redhat.com>
References: <20180918230637.20700-2-lyude(a)redhat.com>
TO: Lyude Paul <lyude(a)redhat.com>
CC: dri-devel(a)lists.freedesktop.org, nouveau(a)lists.freedesktop.org, intel-gfx(a)lists.freedesktop.org, amd-gfx(a)lists.freedesktop.org
CC: David Airlie <airlied(a)linux.ie>, linux-kernel(a)vger.kernel.org, stable(a)vger.kernel.org, Sean Paul <sean(a)poorly.run>
Hi Lyude,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.19-rc4 next-20180919]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Lyude-Paul/Fix-legacy-DPMS-changes…
base: git://anongit.freedesktop.org/drm-intel for-linux-next
:::::: branch date: 8 hours ago
:::::: commit date: 8 hours ago
>> drivers/gpu/drm/drm_dp_mst_topology.c:3144:1-20: iterator with update on line 3145
# https://github.com/0day-ci/linux/commit/f8df31d5221b9a6da6698d4a37e622253bb…
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout f8df31d5221b9a6da6698d4a37e622253bb17cdc
vim +3144 drivers/gpu/drm/drm_dp_mst_topology.c
3f3353b7 Pandiyan, Dhinakaran 2017-04-20 3131
f8df31d5 Lyude Paul 2018-09-18 3132 static bool
f8df31d5 Lyude Paul 2018-09-18 3133 drm_dp_mst_connector_still_exists(struct drm_connector *connector,
f8df31d5 Lyude Paul 2018-09-18 3134 struct drm_dp_mst_topology_mgr *mgr,
f8df31d5 Lyude Paul 2018-09-18 3135 struct drm_dp_mst_branch *mstb)
f8df31d5 Lyude Paul 2018-09-18 3136 {
f8df31d5 Lyude Paul 2018-09-18 3137 struct drm_dp_mst_port *port;
f8df31d5 Lyude Paul 2018-09-18 3138 bool exists = false;
f8df31d5 Lyude Paul 2018-09-18 3139
f8df31d5 Lyude Paul 2018-09-18 3140 mstb = drm_dp_get_validated_mstb_ref(mgr, mstb);
f8df31d5 Lyude Paul 2018-09-18 3141 if (!mstb)
f8df31d5 Lyude Paul 2018-09-18 3142 return false;
f8df31d5 Lyude Paul 2018-09-18 3143
f8df31d5 Lyude Paul 2018-09-18 @3144 list_for_each_entry(port, &mstb->ports, next) {
f8df31d5 Lyude Paul 2018-09-18 @3145 port = drm_dp_get_validated_port_ref(mgr, port);
f8df31d5 Lyude Paul 2018-09-18 3146 if (!port)
f8df31d5 Lyude Paul 2018-09-18 3147 continue;
f8df31d5 Lyude Paul 2018-09-18 3148
f8df31d5 Lyude Paul 2018-09-18 3149 exists = (port->connector == connector ||
f8df31d5 Lyude Paul 2018-09-18 3150 (port->mstb &&
f8df31d5 Lyude Paul 2018-09-18 3151 drm_dp_mst_connector_still_exists(connector, mgr,
f8df31d5 Lyude Paul 2018-09-18 3152 port->mstb)));
f8df31d5 Lyude Paul 2018-09-18 3153
f8df31d5 Lyude Paul 2018-09-18 3154 drm_dp_put_port(port);
f8df31d5 Lyude Paul 2018-09-18 3155 if (exists)
f8df31d5 Lyude Paul 2018-09-18 3156 break;
f8df31d5 Lyude Paul 2018-09-18 3157 }
f8df31d5 Lyude Paul 2018-09-18 3158
f8df31d5 Lyude Paul 2018-09-18 3159 drm_dp_put_mst_branch_device(mstb);
f8df31d5 Lyude Paul 2018-09-18 3160 return exists;
f8df31d5 Lyude Paul 2018-09-18 3161 }
f8df31d5 Lyude Paul 2018-09-18 3162
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Hello,
Niklas Cassle recently reported some regressions with his Qcom cpufreq
driver where he was getting some errors while creating the OPPs tables.
After looking into it I realized that the OPP core incorrectly creates
multiple OPP tables for the devices even if they are sharing the OPP
table in DT. This happens when the request comes using different CPU
devices. For example, dev_pm_opp_set_supported_hw() getting called using
CPU0 and dev_pm_opp_of_add_table() getting called using CPU1.
This series redesigns the internals of the OPP core to fix that. The
redesign has simplified the core itself though.
@Niklas: Can you please confirm that this series fixes the issues you
have reported ? I have already tested it on Hikey960.
--
viresh
Viresh Kumar (11):
OPP: Free OPP table properly on performance state irregularities
OPP: Protect dev_list with opp_table lock
OPP: Pass index to _of_init_opp_table()
OPP: Parse OPP table's DT properties from _of_init_opp_table()
OPP: Don't take OPP table's kref for static OPPs
OPP: Create separate kref for static OPPs list
cpufreq: mvebu: Remove OPPs using dev_pm_opp_remove()
OPP: Don't remove dynamic OPPs from _dev_pm_opp_remove_table()
OPP: Use a single mechanism to free the OPP table
OPP: Prevent creating multiple OPP tables for devices sharing OPP
nodes
OPP: Pass OPP table to _of_add_opp_table_v{1|2}()
drivers/cpufreq/mvebu-cpufreq.c | 9 +-
drivers/opp/core.c | 147 ++++++++++++++++---------
drivers/opp/cpu.c | 11 +-
drivers/opp/of.c | 186 +++++++++++++++++---------------
drivers/opp/opp.h | 19 ++--
include/linux/pm_opp.h | 6 ++
6 files changed, 221 insertions(+), 157 deletions(-)
--
2.18.0.rc1.242.g61856ae69a2c
[ Upstream commit 0f02cfbc3d9e413d450d8d0fd660077c23f67eff ]
When a system suffers from dcache aliasing a user program may observe
stale VDSO data from an aliased cache line. Notably this can break the
expectation that clock_gettime(CLOCK_MONOTONIC, ...) is, as its name
suggests, monotonic.
In order to ensure that users observe updates to the VDSO data page as
intended, align the user mappings of the VDSO data page such that their
cache colouring matches that of the virtual address range which the
kernel will use to update the data page - typically its unmapped address
within kseg0.
This ensures that we don't introduce aliasing cache lines for the VDSO
data page, and therefore that userland will observe updates without
requiring cache invalidation.
Signed-off-by: Paul Burton <paul.burton(a)mips.com>
Reported-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Reported-by: Rene Nielsen <rene.nielsen(a)microsemi.com>
Reported-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Fixes: ebb5e78cc634 ("MIPS: Initial implementation of a VDSO")
Patchwork: https://patchwork.linux-mips.org/patch/20344/
Tested-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Tested-by: Hauke Mehrtens <hauke(a)hauke-m.de>
Cc: James Hogan <jhogan(a)kernel.org>
Cc: linux-mips(a)linux-mips.org
Cc: stable(a)vger.kernel.org # v4.4+
---
arch/mips/kernel/vdso.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/mips/kernel/vdso.c b/arch/mips/kernel/vdso.c
index f9dbfb14af33..e88344e3d508 100644
--- a/arch/mips/kernel/vdso.c
+++ b/arch/mips/kernel/vdso.c
@@ -14,12 +14,14 @@
#include <linux/init.h>
#include <linux/ioport.h>
#include <linux/irqchip/mips-gic.h>
+#include <linux/kernel.h>
#include <linux/mm.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/timekeeper_internal.h>
#include <asm/abi.h>
+#include <asm/page.h>
#include <asm/vdso.h>
/* Kernel-provided data used by the VDSO. */
@@ -129,12 +131,30 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
vvar_size = gic_size + PAGE_SIZE;
size = vvar_size + image->size;
+ /*
+ * Find a region that's large enough for us to perform the
+ * colour-matching alignment below.
+ */
+ if (cpu_has_dc_aliases)
+ size += shm_align_mask + 1;
+
base = get_unmapped_area(NULL, 0, size, 0, 0);
if (IS_ERR_VALUE(base)) {
ret = base;
goto out;
}
+ /*
+ * If we suffer from dcache aliasing, ensure that the VDSO data page
+ * mapping is coloured the same as the kernel's mapping of that memory.
+ * This ensures that when the kernel updates the VDSO data userland
+ * will observe it without requiring cache invalidations.
+ */
+ if (cpu_has_dc_aliases) {
+ base = __ALIGN_MASK(base, shm_align_mask);
+ base += ((unsigned long)&vdso_data - gic_size) & shm_align_mask;
+ }
+
data_addr = base + gic_size;
vdso_addr = data_addr + PAGE_SIZE;
--
2.18.0
The patch below does not apply to the 4.14-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From b40b3e9358fbafff6a4ba0f4b9658f6617146f9c Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Wed, 11 Jul 2018 15:29:31 +0300
Subject: [PATCH] mei: bus: type promotion bug in mei_nfc_if_version()
We accidentally removed the check for negative returns
without considering the issue of type promotion.
The "if_version_length" variable is type size_t so if __mei_cl_recv()
returns a negative then "bytes_recv" is type promoted
to a high positive value and treated as success.
Cc: <stable(a)vger.kernel.org>
Fixes: 582ab27a063a ("mei: bus: fix received data size check in NFC fixup")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Signed-off-by: Tomas Winkler <tomas.winkler(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index e45fe826d87d..65e28be3c8cc 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -341,7 +341,7 @@ static int mei_nfc_if_version(struct mei_cl *cl,
ret = 0;
bytes_recv = __mei_cl_recv(cl, (u8 *)reply, if_version_length, 0, 0);
- if (bytes_recv < if_version_length) {
+ if (bytes_recv < 0 || bytes_recv < if_version_length) {
dev_err(bus->dev, "Could not read IF version\n");
ret = -EIO;
goto err;