<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net/qrtr, branch v6.18.22</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.22</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.22'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-11T12:26:20+00:00</updated>
<entry>
<title>net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak</title>
<updated>2026-04-11T12:26:20+00:00</updated>
<author>
<name>Jiayuan Chen</name>
<email>jiayuan.chen@shopee.com</email>
</author>
<published>2026-03-24T08:06:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f2664bc4f0f356f17c2094587a2b3665e3867e44'/>
<id>urn:sha1:f2664bc4f0f356f17c2094587a2b3665e3867e44</id>
<content type='text'>
[ Upstream commit 2428083101f6883f979cceffa76cd8440751ffe6 ]

__radix_tree_create() allocates and links intermediate nodes into the
tree one by one. If a subsequent allocation fails, the already-linked
nodes remain in the tree with no corresponding leaf entry. These orphaned
internal nodes are never reclaimed because radix_tree_for_each_slot()
only visits slots containing leaf values.

The radix_tree API is deprecated in favor of xarray. As suggested by
Matthew Wilcox, migrate qrtr_tx_flow from radix_tree to xarray instead
of fixing the radix_tree itself [1]. xarray properly handles cleanup of
internal nodes — xa_destroy() frees all internal xarray nodes when the
qrtr_node is released, preventing the leak.

[1] https://lore.kernel.org/all/20260225071623.41275-1-jiayuan.chen@linux.dev/T/
Reported-by: syzbot+006987d1be3586e13555@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/000000000000bfba3a060bf4ffcf@google.com/T/
Fixes: 5fdeb0d372ab ("net: qrtr: Implement outgoing flow control")
Signed-off-by: Jiayuan Chen &lt;jiayuan.chen@shopee.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://patch.msgid.link/20260324080645.290197-1-jiayuan.chen@linux.dev
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: qrtr: Drop the MHI auto_queue feature for IPCR DL channels</title>
<updated>2026-03-12T11:09:25+00:00</updated>
<author>
<name>Manivannan Sadhasivam</name>
<email>manivannan.sadhasivam@oss.qualcomm.com</email>
</author>
<published>2025-12-18T16:51:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7bdff9b9b0c65ac7105416fe3a40686832515e20'/>
<id>urn:sha1:7bdff9b9b0c65ac7105416fe3a40686832515e20</id>
<content type='text'>
[ Upstream commit 51731792a25cb312ca94cdccfa139eb46de1b2ef ]

MHI stack offers the 'auto_queue' feature, which allows the MHI stack to
auto queue the buffers for the RX path (DL channel). Though this feature
simplifies the client driver design, it introduces race between the client
drivers and the MHI stack. For instance, with auto_queue, the 'dl_callback'
for the DL channel may get called before the client driver is fully probed.
This means, by the time the dl_callback gets called, the client driver's
structures might not be initialized, leading to NULL ptr dereference.

Currently, the drivers have to workaround this issue by initializing the
internal structures before calling mhi_prepare_for_transfer_autoqueue().
But even so, there is a chance that the client driver's internal code path
may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is
called, leading to similar NULL ptr dereference. This issue has been
reported on the Qcom X1E80100 CRD machines affecting boot.

So to properly fix all these races, drop the MHI 'auto_queue' feature
altogether and let the client driver (QRTR) manage the RX buffers manually.
In the QRTR driver, queue the RX buffers based on the ring length during
probe and recycle the buffers in 'dl_callback' once they are consumed. This
also warrants removing the setting of 'auto_queue' flag from controller
drivers.

Currently, this 'auto_queue' feature is only enabled for IPCR DL channel.
So only the QRTR client driver requires the modification.

Fixes: 227fee5fc99e ("bus: mhi: core: Add an API for auto queueing buffers for DL channel")
Fixes: 68a838b84eff ("net: qrtr: start MHI channel after endpoit creation")
Reported-by: Johan Hovold &lt;johan@kernel.org&gt;
Closes: https://lore.kernel.org/linux-arm-msm/ZyTtVdkCCES0lkl4@hovoldconsulting.com
Suggested-by: Chris Lew &lt;quic_clew@quicinc.com&gt;
Signed-off-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@oss.qualcomm.com&gt;
Reviewed-by: Jeff Hugo &lt;jeff.hugo@oss.qualcomm.com&gt;
Reviewed-by: Loic Poulain &lt;loic.poulain@oss.qualcomm.com&gt;
Acked-by: Jeff Johnson &lt;jjohnson@kernel.org&gt; # drivers/net/wireless/ath/...
Acked-by: Jeff Hugo &lt;jeff.hugo@oss.qualcomm.com&gt;
Acked-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20251218-qrtr-fix-v2-1-c7499bfcfbe0@oss.qualcomm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: qrtr: Update packets cloning when broadcasting</title>
<updated>2024-09-24T08:48:16+00:00</updated>
<author>
<name>Youssef Samir</name>
<email>quic_yabdulra@quicinc.com</email>
</author>
<published>2024-09-16T17:08:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f011b313e8ebd5b7abd8521b5119aecef403de45'/>
<id>urn:sha1:f011b313e8ebd5b7abd8521b5119aecef403de45</id>
<content type='text'>
When broadcasting data to multiple nodes via MHI, using skb_clone()
causes all nodes to receive the same header data. This can result in
packets being discarded by endpoints, leading to lost data.

This issue occurs when a socket is closed, and a QRTR_TYPE_DEL_CLIENT
packet is broadcasted. All nodes receive the same destination node ID,
causing the node connected to the client to discard the packet and
remain unaware of the client's deletion.

Replace skb_clone() with pskb_copy(), to create a separate copy of
the header for each sk_buff.

Fixes: bdabad3e363d ("net: Add Qualcomm IPC router")
Signed-off-by: Youssef Samir &lt;quic_yabdulra@quicinc.com&gt;
Reviewed-by: Jeffery Hugo &lt;quic_jhugo@quicinc.com&gt;
Reviewed-by: Carl Vanderlip &lt;quic_carlv@quicinc.com&gt;
Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;
Link: https://patch.msgid.link/20240916170858.2382247-1-quic_yabdulra@quicinc.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
<entry>
<title>net: qrtr: ns: Ignore ENODEV failures in ns</title>
<updated>2024-06-14T11:17:21+00:00</updated>
<author>
<name>Chris Lew</name>
<email>quic_clew@quicinc.com</email>
</author>
<published>2024-06-12T06:31:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=404dbd26322f50c8123bf5bff9a409356889035f'/>
<id>urn:sha1:404dbd26322f50c8123bf5bff9a409356889035f</id>
<content type='text'>
Ignore the ENODEV failures returned by kernel_sendmsg(). These errors
indicate that either the local port has been closed or the remote has
gone down. Neither of these scenarios are fatal and will eventually be
handled through packets that are later queued on the control port.

Signed-off-by: Chris Lew &lt;quic_clew@quicinc.com&gt;
Signed-off-by: Sarannya Sasikumar &lt;quic_sarannya@quicinc.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Link: https://lore.kernel.org/r/20240612063156.1377210-1-quic_sarannya@quicinc.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;

</content>
</entry>
<entry>
<title>net: qrtr: ns: Fix module refcnt</title>
<updated>2024-05-16T08:47:45+00:00</updated>
<author>
<name>Chris Lew</name>
<email>quic_clew@quicinc.com</email>
</author>
<published>2024-05-13T17:31:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fd76e5ccc48f9f54eb44909dd7c0b924005f1582'/>
<id>urn:sha1:fd76e5ccc48f9f54eb44909dd7c0b924005f1582</id>
<content type='text'>
The qrtr protocol core logic and the qrtr nameservice are combined into
a single module. Neither the core logic or nameservice provide much
functionality by themselves; combining the two into a single module also
prevents any possible issues that may stem from client modules loading
inbetween qrtr and the ns.

Creating a socket takes two references to the module that owns the
socket protocol. Since the ns needs to create the control socket, this
creates a scenario where there are always two references to the qrtr
module. This prevents the execution of 'rmmod' for qrtr.

To resolve this, forcefully put the module refcount for the socket
opened by the nameservice.

Fixes: a365023a76f2 ("net: qrtr: combine nameservice into main module")
Reported-by: Jeffrey Hugo &lt;quic_jhugo@quicinc.com&gt;
Tested-by: Jeffrey Hugo &lt;quic_jhugo@quicinc.com&gt;
Signed-off-by: Chris Lew &lt;quic_clew@quicinc.com&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Reviewed-by: Jeffrey Hugo &lt;quic_jhugo@quicinc.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: qrtr: support suspend/hibernation</title>
<updated>2024-04-09T11:43:28+00:00</updated>
<author>
<name>Baochen Qiang</name>
<email>quic_bqiang@quicinc.com</email>
</author>
<published>2024-04-08T14:41:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e0cd1185900e638d41d9cccb4c259051e05f69e9'/>
<id>urn:sha1:e0cd1185900e638d41d9cccb4c259051e05f69e9</id>
<content type='text'>
MHI devices may not be destroyed during suspend/hibernation, so need
to unprepare/prepare MHI channels throughout the transition, this is
done by adding suspend/resume callbacks.

The suspend callback is called in the late suspend stage, this means
MHI channels are still alive at suspend stage, and that makes it
possible for an MHI controller driver to communicate with others over
those channels at suspend stage. While the resume callback is called
in the early resume stage, for a similar reason.

Also note that we won't do unprepare/prepare when MHI device is in
suspend state because it's pointless if MHI is only meant to go through
a suspend/resume transition, instead of a complete power cycle.

Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Signed-off-by: Baochen Qiang &lt;quic_bqiang@quicinc.com&gt;
Reviewed-by: Manivannan Sadhasivam &lt;manivannan.sadhasivam@linaro.org&gt;
Reviewed-by: Jeff Johnson &lt;quic_jjohnson@quicinc.com&gt;
Signed-off-by: Kalle Valo &lt;quic_kvalo@quicinc.com&gt;
Link: https://msgid.link/20240305021320.3367-3-quic_bqiang@quicinc.com
</content>
</entry>
<entry>
<title>net: qrtr: ns: Return 0 if server port is not present</title>
<updated>2024-01-01T18:41:29+00:00</updated>
<author>
<name>Sarannya S</name>
<email>quic_sarannya@quicinc.com</email>
</author>
<published>2023-12-21T10:06:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9bf2e9165f90dc9f416af53c902be7e33930f728'/>
<id>urn:sha1:9bf2e9165f90dc9f416af53c902be7e33930f728</id>
<content type='text'>
When a 'DEL_CLIENT' message is received from the remote, the corresponding
server port gets deleted. A DEL_SERVER message is then announced for this
server. As part of handling the subsequent DEL_SERVER message, the name-
server attempts to delete the server port which results in a '-ENOENT' error.
The return value from server_del() is then propagated back to qrtr_ns_worker,
causing excessive error prints.
To address this, return 0 from control_cmd_del_server() without checking the
return value of server_del(), since the above scenario is not an error case
and hence server_del() doesn't have any other error return value.

Signed-off-by: Sarannya Sasikumar &lt;quic_sarannya@quicinc.com&gt;
Reviewed-by: Simon Horman &lt;horms@kernel.org&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: qrtr: Handle IPCR control port format of older targets</title>
<updated>2023-07-17T08:02:30+00:00</updated>
<author>
<name>Vignesh Viswanathan</name>
<email>quic_viswanat@quicinc.com</email>
</author>
<published>2023-07-14T05:58:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=69940b888e3502868efd1acf3719fd1af810c123'/>
<id>urn:sha1:69940b888e3502868efd1acf3719fd1af810c123</id>
<content type='text'>
The destination port value in the IPCR control buffer on older
targets is 0xFFFF. Handle the same by updating the dst_port to
QRTR_PORT_CTRL.

Signed-off-by: Vignesh Viswanathan &lt;quic_viswanat@quicinc.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: qrtr: ns: Change nodes radix tree to xarray</title>
<updated>2023-07-17T08:02:30+00:00</updated>
<author>
<name>Vignesh Viswanathan</name>
<email>quic_viswanat@quicinc.com</email>
</author>
<published>2023-07-14T05:58:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f26b32ef2fe6f7ae0ba56854e666339e105610ad'/>
<id>urn:sha1:f26b32ef2fe6f7ae0ba56854e666339e105610ad</id>
<content type='text'>
There is a use after free scenario while iterating through the nodes
radix tree despite the ns being a single threaded process. This can
happen when the radix tree APIs are not synchronized with the
rcu_read_lock() APIs.

Convert the radix tree for nodes to xarray to take advantage of the
built in rcu lock usage provided by xarray.

Signed-off-by: Chris Lew &lt;quic_clew@quicinc.com&gt;
Signed-off-by: Vignesh Viswanathan &lt;quic_viswanat@quicinc.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>net: qrtr: ns: Change servers radix tree to xarray</title>
<updated>2023-07-17T08:02:30+00:00</updated>
<author>
<name>Vignesh Viswanathan</name>
<email>quic_viswanat@quicinc.com</email>
</author>
<published>2023-07-14T05:58:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=608a147a88728f84bbd2efdde3d4984339f1d872'/>
<id>urn:sha1:608a147a88728f84bbd2efdde3d4984339f1d872</id>
<content type='text'>
There is a use after free scenario while iterating through the servers
radix tree despite the ns being a single threaded process. This can
happen when the radix tree APIs are not synchronized with the
rcu_read_lock() APIs.

Convert the radix tree for servers to xarray to take advantage of the
built in rcu lock usage provided by xarray.

Signed-off-by: Chris Lew &lt;quic_clew@quicinc.com&gt;
Signed-off-by: Vignesh Viswanathan &lt;quic_viswanat@quicinc.com&gt;
Reviewed-by: Simon Horman &lt;simon.horman@corigine.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
