linux-kernel - Re: [PATCH v32 01/32] usb: host: xhci: Repurpose event handler for skipping interrupter events

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250113143632.63c52d74@foxbook>
Date: Mon, 13 Jan 2025 14:36:32 +0100
From: Michał Pecio <michal.pecio@...il.com>
To: quic_wcheng@...cinc.com
Cc: Thinh.Nguyen@...opsys.com, broonie@...nel.org, conor+dt@...nel.org,
 corbet@....net, devicetree@...r.kernel.org, dmitry.torokhov@...il.com,
 gregkh@...uxfoundation.org, krzk+dt@...nel.org, lgirdwood@...il.com,
 linux-arm-msm@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-sound@...r.kernel.org, linux-usb@...r.kernel.org,
 mathias.nyman@...el.com, perex@...ex.cz,
 pierre-louis.bossart@...ux.intel.com, robh@...nel.org,
 srinivas.kandagatla@...aro.org, tiwai@...e.com
Subject: Re: [PATCH v32 01/32] usb: host: xhci: Repurpose event handler for
 skipping interrupter events

Hi,

> Depending on the interrupter use case, the OS may only be used to
> handle the interrupter event ring clean up.

What do you mean by "cleanup"? Because I see that this patch ends up
acknowledging events to the xHC and I don't know why it would do so?

> In these scenarios, event TRBs don't need to be handled by the OS,
> so introduce an xhci interrupter flag to tag if the events from an
> interrupter needs to be handled or not.

Right, and if the OS isn't handling those events because they are owned
by a coprocessor then it shouldn't be acknowledging them either, which
has the effect that the xHC considers their memory free for reuse.

Also, what happens when Linux goes to sleep and this IRQ stops running?
I expected that the coprocessor itself should be updating the xHC about
its own progress.

Is it a bug? How is this stuff supposed to work?

How are future developers supposed to know how it is supposed to work?
I imagine that few of them will have Qualcomm hardware for testing.

> static int xhci_handle_event_trb(struct xhci_hcd *xhci, struct xhci_interrupter *ir,
> 				 union xhci_trb *event)
> {
> 	u32 trb_type;
> 
> +	/*
> +	 * Some interrupters do not need to handle event TRBs, as they may be
> +	 * managed by another entity, but rely on the OS to clean up.
> +	 */
> +	if (ir->skip_events)
> +		return 0;

This function is only called from one place so the caller could perform
this check and don't waste time calling it.

Regards,
Michalal