All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Pecio" <michal.pecio@gmail.com>
To: Mathias Nyman <mathias.nyman@linux.intel.com>
Cc: Paul Menzel <pmenzel@molgen.mpg.de>,
	Mathias Nyman <mathias.nyman@intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-usb@vger.kernel.org,
	Niklas Neronin <niklas.neronin@linux.intel.com>
Subject: Re: xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1
Date: Wed, 10 Apr 2024 11:46:01 +0200	[thread overview]
Message-ID: <20240410114601.0e25a46d@foxbook> (raw)
In-Reply-To: <82113c7d-0405-ba11-94d9-5673593cec50@linux.intel.com>

> Driver can cope with these extra events, but if this is common we
> should probably handle it silently and not concern users with that
> ERROR message.

The error message in itself is harmless, it means the driver gets an
event it doesn't know how to handle and ignores it. Further events are
processed normally (in this specific case).

What's problematic is that the controller is apparently still working
on a TD which the driver considers to be finished already. The driver
can overwrite the TD and reuse its data buffer for other transfers,
while the hardware may still need the original TD for proper operation
and, if we are very unlucky, could attempt DMA to/from the data buffer,
causing data corruption or information leak to a malicious USB dongle.

For all we know, Paul's buggy chipset may not only be confirming the
transfer twice, but really performing it twice for some stupid reason.


> We are actually at the moment looking at improving handle_tx_event()
> with Niklas (cc), and will take this into consideration.

Given the number of bugs so far, maybe it would make sense to count
transfer ring slots of the last completed TD as still "in use" until
the next TD is known to at least begin executing.

Unfortunately, "quarantining" URB data buffers in similar manner would
be harder AFAIK.

I recently found one more bug of this kind: the Etron EJ168 controller
produces two events for failed single-TRB isochronous IN transfers -
one event indicating the failure, and then a "success". The full extent
of the bug (does it affect OUT or non-isoch, what happens on multi-TRB)
is unknown because the controller is very prone to crashing under my
workloads, which doesn't help debugging.

Regards,
Michal

      parent reply	other threads:[~2024-04-10  9:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-29 10:47 xhci_hcd 0000:00:14.0: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 1 comp_code 1 Paul Menzel
2024-04-05  9:32 ` Michał Pecio
2024-04-06 14:37   ` Paul Menzel
2024-04-06 16:36     ` Michał Pecio
2024-04-06 17:01       ` Paul Menzel
2024-04-07 12:25         ` Michał Pecio
2024-04-08  7:17           ` Mathias Nyman
2024-04-08 16:37             ` Paul Menzel
2024-04-08 16:42               ` Paul Menzel
2024-04-08 19:05             ` Michał Pecio
2024-04-09 11:22               ` Mathias Nyman
2024-04-10  7:59                 ` Paul Menzel
2024-04-11  7:18                   ` Mathias Nyman
2024-04-11 19:55                     ` Paul Menzel
2024-04-13  9:17                   ` Michał Pecio
2024-04-10  9:46                 ` Michał Pecio [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240410114601.0e25a46d@foxbook \
    --to=michal.pecio@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=mathias.nyman@linux.intel.com \
    --cc=niklas.neronin@linux.intel.com \
    --cc=pmenzel@molgen.mpg.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.