Re: [PATCH net v2] net/smc: don't spin in smc_rx_recvmsg() while a pipe holds spliced data

[Dust Li]

On 2026-11-03 15:18:36, Paolo Abeni wrote:
>On 10/29/26 09:03, Bryam Vargas wrote:
>> While bytes spliced off the RMB are still in a pipe, recvmsg() waits
>> for the pipe to release them before it copies the data behind them.
>> The path to that wait skips the timeout and signal checks, and
>> smc_rx_wait() returns at once on RCV_SHUTDOWN. With a signal pending,
>> after SHUT_RD, or once the peer closes or shuts down writing,
>> recvmsg() spins on a CPU until the pipe is drained, and SIGKILL cannot
>> stop it. MSG_DONTWAIT and an expired SO_RCVTIMEO wait there too
>> instead of returning -EAGAIN.
>> 
>> Check the timeout and signals before that wait, and end it when the
>> pipe releases the data or the connection is killed, not on RCV_SHUTDOWN.
>> A zero-length read returns 0 without waiting for the pipe; a
>> non-blocking one returns -EAGAIN while poll() still reports the socket
>> readable (splice() can still take those bytes).
>
>@SMC experts, please review. IMHO the above trade-off sounds like a better
>solution is needed.

Hi Bryam, Paolo,

Yes, I agree this is a trade-off. But I think this was not introduced by
this patch; rather, it is a pre-existing bug. And sadly, I don't have a
good solution to solve it yet.

So for now, I prefer to accept this as a stable fix.

As for the long-term fix: the follow-up I have in mind is to remove the
zero-copy mode for splice in SMC, which will simplify things a lot.
Since splice doesn't map easily to a ring buffer like SMC's, and this is
not a very common path as we have seen, falling back to copy is
acceptable IMO.

Happy to hear if anyone has better ideas.

Best regards,
Dust