Please drop 'drm/sun4i: rgb: Fix potential division by zero' from
4.9.y/4.14.y.
CC [M] drivers/gpu/drm/sun4i/sun4i_rgb.o
../drivers/gpu/drm/sun4i/sun4i_rgb.c: In function ‘sun4i_rgb_mode_valid’:
../drivers/gpu/drm/sun4i/sun4i_rgb.c:96:6: error: ‘struct sun4i_tcon’ has no member named ‘dclk_min_div’
tcon->dclk_min_div = 6;
^~
../drivers/gpu/drm/sun4i/sun4i_rgb.c:97:6: error: ‘struct sun4i_tcon’ has no member named ‘dclk_max_div’
tcon->dclk_max_div = 127;
^~
make[5]: *** [../scripts/Makefile.build:294: drivers/gpu/drm/sun4i/sun4i_rgb.o] Error 1
make[4]: *** [../scripts/Makefile.build:544: drivers/gpu/drm/sun4i] Error 2
make[3]: *** [../scripts/Makefile.build:544: drivers/gpu/drm] Error 2
make[2]: *** [../scripts/Makefile.build:544: drivers/gpu] Error 2
make[1]: *** [/home/drue/src/linux/4.9-rc/Makefile:1006: drivers] Error 2
make[1]: Leaving directory '/home/drue/src/linux/4.9-rc/build-arm'
make: *** [Makefile:152: sub-make] Error 2
Greg - is there a way that I can tell which build and boot problems
0-day is reporting so that I don't duplicate work on either of our
sides?
Thanks,
Dan
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Clear the old_state and new_state pointers for every object in
drm_atomic_state_default_clear(). Otherwise
drm_atomic_get_{new,old}_*_state() will hand out stale pointers to
anyone who hasn't first confirmed that the object is in fact part of
the current atomic transcation, if they are called after we've done
the ww backoff dance while hanging on to the same drm_atomic_state.
For example, handle_conflicting_encoders() looks like it could hit
this since it iterates the full connector list and just calls
drm_atomic_get_new_connector_state() for each.
And I believe we have now witnessed this happening at least once in
i915 check_digital_port_conflicts(). Commit 8b69449d2663 ("drm/i915:
Remove last references to drm_atomic_get_existing* macros") changed
the safe drm_atomic_get_existing_connector_state() to the unsafe
drm_atomic_get_new_connector_state(), which opened the doors for
this particular bug there as well.
Cc: stable(a)vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com>
Cc: Abhay Kumar <abhay.kumar(a)intel.com>
Fixes: 581e49fe6b41 ("drm/atomic: Add new iterators over all state, v3.")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/drm_atomic.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7d25c42f22db..c825c76edc1d 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -155,6 +155,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->connectors[i].state);
state->connectors[i].ptr = NULL;
state->connectors[i].state = NULL;
+ state->connectors[i].old_state = NULL;
+ state->connectors[i].new_state = NULL;
drm_connector_put(connector);
}
@@ -169,6 +171,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->crtcs[i].ptr = NULL;
state->crtcs[i].state = NULL;
+ state->crtcs[i].old_state = NULL;
+ state->crtcs[i].new_state = NULL;
}
for (i = 0; i < config->num_total_plane; i++) {
@@ -181,6 +185,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->planes[i].state);
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
+ state->planes[i].old_state = NULL;
+ state->planes[i].new_state = NULL;
}
for (i = 0; i < state->num_private_objs; i++) {
@@ -190,6 +196,8 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state)
state->private_objs[i].state);
state->private_objs[i].ptr = NULL;
state->private_objs[i].state = NULL;
+ state->private_objs[i].old_state = NULL;
+ state->private_objs[i].new_state = NULL;
}
state->num_private_objs = 0;
--
2.16.1
KASAN found a use-after-free in xhci_free_virt_device+0x33b/0x38e
where xhci_free_virt_device() sets slot id to 0 if udev exists:
if (dev->udev && dev->udev->slot_id)
dev->udev->slot_id = 0;
dev->udev will be true even if udev is freed because dev->udev is
not set to NULL.
set dev->udev pointer to NULL in xhci_free_dev()
The original patch went to stable so this fix needs to be applied
there as well.
Fixes: a400efe455f7 ("xhci: zero usb device slot_id member when disabling and freeing a xhci slot")
Cc: <stable(a)vger.kernel.org>
Reported-by: Guenter Roeck <linux(a)roeck-us.net>
Reviewed-by: Guenter Roeck <linux(a)roeck-us.net>
Tested-by: Guenter Roeck <linux(a)roeck-us.net>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
---
drivers/usb/host/xhci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9b27798..711da33 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3621,6 +3621,7 @@ static void xhci_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
del_timer_sync(&virt_dev->eps[i].stop_cmd_timer);
}
xhci_debugfs_remove_slot(xhci, udev->slot_id);
+ virt_dev->udev = NULL;
ret = xhci_disable_slot(xhci, udev->slot_id);
if (ret)
xhci_free_virt_device(xhci, udev->slot_id);
--
2.7.4
From: Hector Martin <marcan(a)marcan.st>
[ Upstream commit 188775181bc05f29372b305ef96485840e351fde ]
At least some JMicron controllers issue buggy oversized DMA reads when
fetching context descriptors, always fetching 0x20 bytes at once for
descriptors which are only 0x10 bytes long. This is often harmless, but
can cause page faults on modern systems with IOMMUs:
DMAR: [DMA Read] Request device [05:00.0] fault addr fff56000 [fault reason 06] PTE Read access is not set
firewire_ohci 0000:05:00.0: DMA context IT0 has stopped, error code: evt_descriptor_read
This works around the problem by always leaving 0x10 padding bytes at
the end of descriptor buffer pages, which should be harmless to do
unconditionally for controllers in case others have the same behavior.
Signed-off-by: Hector Martin <marcan(a)marcan.st>
Reviewed-by: Clemens Ladisch <clemens(a)ladisch.de>
Signed-off-by: Stefan Richter <stefanr(a)s5r6.in-berlin.de>
Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com>
---
drivers/firewire/ohci.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c
index 8bf89267dc25..d731b413cb2c 100644
--- a/drivers/firewire/ohci.c
+++ b/drivers/firewire/ohci.c
@@ -1130,7 +1130,13 @@ static int context_add_buffer(struct context *ctx)
return -ENOMEM;
offset = (void *)&desc->buffer - (void *)desc;
- desc->buffer_size = PAGE_SIZE - offset;
+ /*
+ * Some controllers, like JMicron ones, always issue 0x20-byte DMA reads
+ * for descriptors, even 0x10-byte ones. This can cause page faults when
+ * an IOMMU is in use and the oversized read crosses a page boundary.
+ * Work around this by always leaving at least 0x10 bytes of padding.
+ */
+ desc->buffer_size = PAGE_SIZE - offset - 0x10;
desc->buffer_bus = bus_addr + offset;
desc->used = 0;
--
2.15.1
Hi,
On stable v4.14.40-rc1, commit below breaks kernel boot on ARMv7 board
(Odroid XU3 with Samsung Exynos5422, exynos_defconfig). The kernel
hangs on "Starting kernel ...". Full log:
http://www.krzk.eu/#/builders/1/builds/1897
The board boots from TFTP with NFS root (NFSv4).
commit 449a8040a3b68a58131453b8f3dcfb411e85b1f5
Author: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com>
Date: Mon Jan 8 14:35:52 2018 -0800
rcu: Create RCU-specific workqueues with rescuers
[ Upstream commit ad7c946b35ad455417fdd4bc0e17deda4011841b ]
Bisect log:
git bisect start
# good: [7d6240f0fb85430ae4f490824fdf8d0a078dfcd2] Linux 4.14.39
git bisect good 7d6240f0fb85430ae4f490824fdf8d0a078dfcd2
# bad: [c8cd674cefa12376b3f7f993ddb5b262f9c64dbf] Linux 4.14.40-rc1
git bisect bad c8cd674cefa12376b3f7f993ddb5b262f9c64dbf
# good: [f122a2d150d85721e1c48561ed9073154a9afcc8] bonding: fix the
err path for dev hwaddr sync in bond_enslave
git bisect good f122a2d150d85721e1c48561ed9073154a9afcc8
# good: [e353b1ee991a8aa64103db2b8dba975f1c7f1f0f] usb: dwc2: hcd: Fix
host channel halt flow
git bisect good e353b1ee991a8aa64103db2b8dba975f1c7f1f0f
# good: [95bcea0185094ba218ab24261658993a9af29d9f] serial: xuartps:
Fix out-of-bounds access through DT alias
git bisect good 95bcea0185094ba218ab24261658993a9af29d9f
# good: [58d6d43c0d69602b9325bbc6194188711d1132cd] crypto:
inside-secure - fix the extra cache computation
git bisect good 58d6d43c0d69602b9325bbc6194188711d1132cd
# good: [e1c90fdb0fd515dabb4e56a0cf5ebc276e16c3c7] drm: rcar-du: lvds:
Fix LVDS startup on R-Car Gen3
git bisect good e1c90fdb0fd515dabb4e56a0cf5ebc276e16c3c7
# good: [d3ab1eddcbca4b4eb8ba43451e04df07d2ca5c99] ARM: dts: imx7d:
cl-som-imx7: fix pinctrl_enet
git bisect good d3ab1eddcbca4b4eb8ba43451e04df07d2ca5c99
# good: [6a4469c29bddd0e7c646b2534787d47c77729720] ASoC: samsung: i2s:
Ensure the RCLK rate is properly determined
git bisect good 6a4469c29bddd0e7c646b2534787d47c77729720
# good: [60f7a71df26eca547c542d7d80895257ba10fda6] kdb: make "mdr"
command repeat
git bisect good 60f7a71df26eca547c542d7d80895257ba10fda6
# bad: [449a8040a3b68a58131453b8f3dcfb411e85b1f5] rcu: Create
RCU-specific workqueues with rescuers
git bisect bad 449a8040a3b68a58131453b8f3dcfb411e85b1f5
# good: [b5e56644256a462033f6b52212b9dd135e5fed10] xhci: Show what USB
release number the xHC supports from protocol capablity
git bisect good b5e56644256a462033f6b52212b9dd135e5fed10
# first bad commit: [449a8040a3b68a58131453b8f3dcfb411e85b1f5] rcu:
Create RCU-specific workqueues with rescuers
Let me know if you need any more information.
Best regards,
Krzysztof