The premature free in the error path is blocked by V4L
refcounting, not USB refcounting. Thanks to
Ben Hutchings for review.
[v2] corrected attributions
Signed-off-by: Oliver Neukum <oneukum(a)suse.com>
Fixes: 50e704453553 ("media: usbtv: prevent double free in error case")
CC: stable(a)vger.kernel.org
Reported-by: Ben Hutchings <ben.hutchings(a)codethink.co.uk>
---
drivers/media/usb/usbtv/usbtv-core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/usbtv/usbtv-core.c b/drivers/media/usb/usbtv/usbtv-core.c
index ee9c656d121f..2308c0b4f5e7 100644
--- a/drivers/media/usb/usbtv/usbtv-core.c
+++ b/drivers/media/usb/usbtv/usbtv-core.c
@@ -113,7 +113,8 @@ static int usbtv_probe(struct usb_interface *intf,
usbtv_audio_fail:
/* we must not free at this point */
- usb_get_dev(usbtv->udev);
+ v4l2_device_get(&usbtv->v4l2_dev);
+ /* this will undo the v4l2_device_get() */
usbtv_video_free(usbtv);
usbtv_video_fail:
--
2.26.2
This series resolves various issues with ZLP handling and refactor handling of
TRBs. This series has too many changes comparing to the "[PATCH v3 0/4] usb:
dwc3: gadget: Fix TRB preparation" series so I created different series
instead.
Thinh Nguyen (10):
usb: dwc3: gadget: Check MPS of the request length
usb: dwc3: gadget: Reclaim extra TRBs after request completion
usb: dwc3: gadget: Refactor preparing extra TRB
usb: dwc3: gadget: Improve TRB ZLP setup
usb: dwc3: ep0: Fix ZLP for OUT ep0 requests
usb: dwc3: gadget: Return the number of prepared TRBs
usb: dwc3: gadget: Check for number of TRBs prepared
usb: dwc3: gadget: Set IOC if not enough for extra TRBs
usb: dwc3: gadget: Refactor preparing last TRBs
usb: dwc3: gadget: Rename misleading function names
drivers/usb/dwc3/ep0.c | 11 +-
drivers/usb/dwc3/gadget.c | 262 +++++++++++++++++---------------------
2 files changed, 124 insertions(+), 149 deletions(-)
base-commit: 2f45af92722ee6e78f12037af1870117bcae00d1
--
2.28.0
From: Raymond Tan <raymond.tan(a)intel.com>
Similar to some other IA platforms, Elkhart Lake too depends on the
PMU register write to request transition of Dx power state.
Thus, we add the PCI_DEVICE_ID_INTEL_EHLLP to the list of devices that
shall execute the ACPI _DSM method during D0/D3 sequence.
[heikki.krogerus(a)linux.intel.com: included Fixes tag]
Fixes: dbb0569de852 ("usb: dwc3: pci: Add Support for Intel Elkhart Lake Devices")
Cc: stable(a)vger.kernel.org
Signed-off-by: Raymond Tan <raymond.tan(a)intel.com>
Signed-off-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com>
---
drivers/usb/dwc3/dwc3-pci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index f5a61f57c74f0..242b6210380a4 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -147,7 +147,8 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
if (pdev->device == PCI_DEVICE_ID_INTEL_BXT ||
- pdev->device == PCI_DEVICE_ID_INTEL_BXT_M) {
+ pdev->device == PCI_DEVICE_ID_INTEL_BXT_M ||
+ pdev->device == PCI_DEVICE_ID_INTEL_EHLLP) {
guid_parse(PCI_INTEL_BXT_DSM_GUID, &dwc->guid);
dwc->has_dsm_for_pm = true;
}
--
2.28.0
A bug existed in the XFS reflink code between v5.1 and v5.5 in which
the mapping for a COW IO was not trimmed to the mapping of the COW
extent that was found. This resulted in a too-short copy, and
corruption of other files which shared the original extent.
(This happened only when extent size hints were set, which bypasses
delalloc and led to this code path.)
This was (inadvertently) fixed upstream with
36adcbace24e "xfs: fill out the srcmap in iomap_begin"
and related patches which moved lots of this functionality to
the iomap subsystem.
Hence, this is a -stable only patch, targeted to fix this
corruption vector without other major code changes.
Fixes: 78f0cc9d55cb ("xfs: don't use delalloc extents for COW on files with extsize hints")
Cc: <stable(a)vger.kernel.org> # 5.4.x
Signed-off-by: Eric Sandeen <sandeen(a)redhat.com>
---
I've tested this with a targeted reproducer (in next email) as well as
with xfstests.
Stable folk, not sure how to send a "stable only" patch, or if that's even
valid. Assuming you're willing to accept it, I would still like to have
some formal Reviewed-by's from the xfs developer community before it gets
merged.
Big thanks to Darrick & Dave for letting me whine about this bug and
offering suggestions for testing and ultimately, a patch to test.
diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
index 06b9e0aacf54..3289d0f4bb03 100644
--- a/fs/xfs/xfs_iomap.c
+++ b/fs/xfs/xfs_iomap.c
@@ -1002,9 +1002,15 @@ xfs_file_iomap_begin(
* I/O, which must be block aligned, we need to report the
* newly allocated address. If the data fork has a hole, copy
* the COW fork mapping to avoid allocating to the data fork.
+ *
+ * Otherwise, ensure that the imap range does not extend past
+ * the range allocated/found in cmap.
*/
if (directio || imap.br_startblock == HOLESTARTBLOCK)
imap = cmap;
+ else
+ xfs_trim_extent(&imap, cmap.br_startoff,
+ cmap.br_blockcount);
end_fsb = imap.br_startoff + imap.br_blockcount;
length = XFS_FSB_TO_B(mp, end_fsb) - offset;