From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=79.135.106.121 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1793261062; b=BbdCHS80GG5LiSiX9AFJpEojIwH73exIBdEzFxVYlS2WVXGyg5kFgicC4rkjHGrrAIPM 8AcztI9DvQVU3seB1x44cAC+LcEu6qQSLXxm8+oM8PavspetYOrZU8zFyIhF2jb1FVlph ripC+3/agNX/YvoL8TSEK38cU8nRJG1ApFoNDTCzqvc8/Y9coC1Q3cdLV4QT/r6PXIoem TDPKbIHwzH1wG+qzuC6hXjuc3HIYw2v+r82UxXhGqwtvzqOfl4lWcWLMG5JROCNVn0ONX EQq3vPwWAvl8h36dJn27J8VVnLzt2WLcghYHB8AR3xx3Hm94CYL1c8UpX5wekMlV6qA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1793261062; h=DMARC-Filter:DKIM-Signature:Date:To:From:Cc:Subject:Message-ID: In-Reply-To:References:Feedback-ID:X-Pm-Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=3mi8pbVMw8BvzgIqDR4pQfsZ3+QylVo6OT08+KoiPrM=; b=xBXGJ+TPg1t1wWn8a6zYEoEKi1yFN9L7AFCFmBBakid785nQtTXfhwrVc2plBxAW9+Nu ojBzBF38UBijHf19gYqpCsDJIvVDVo5f+HnjsI2qwNCwFxTEqcuft+eWtSc5Wz/TSPPFN NPYBFSe9IqBXlJ8FSO2K532Ltv2L46C/6cT4RWQXosahqox4HAQta6Wqr7OkT6bYlbL1Q EXRQS8fL/mJ0tARgmzBp/TtTSs2pNFgh9s0wA+/9oV2UWIfj9OgA4yciz7NB75tA+o1CO ZPN81VFHiAHLgOB5DxPxuB7CWdXOBYUo7fhHThVkKSXSiOQtX3k/MlHDrz07GsUNDHA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=proton.me; spf=pass smtp.mailfrom=proton.me; arc=none smtp.remote-ip=79.135.106.121 Received: from mail-106121.protonmail.ch (mail-106121.protonmail.ch [79.135.106.121]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1EE63606A31D; Thu, 29 Oct 2026 08:04:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 1EE63606A31D Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=proton.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail2; t=1793261057; x=1793520257; bh=3mi8pbVMw8BvzgIqDR4pQfsZ3+QylVo6OT08+KoiPrM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=IiWd7e3S+ETRMNGTnFKt60Hk2tsXc98Iro5IAQsKUoXxI3y/ZWytkooEsMcO3ZxVm WfHs1gJjZrjVBN83/9638VdvmOwX8HRJTc1iEoshMET4bfm+fZw4LcIGh89UC1sLwF xE5CD61F8sDwjpzemkVxdCBpjT0H5sTUVXTn3tSGMx59YEeeb9IKbmSCiOQd1cW/Rl uauLFtbcQYt/1GOFkdxxepZJZCd6Lgyvl4A8+Yq48A9J+dZIipGTETvkBQsDv4HlEi Fioa8urpvZMqN5Y17YAlton7PAl8HJrokHTRyR30GLIAFkeATqScA/eIGkGjfSOQMN xtLdhRTRKRd8w== Date: Thu, 29 Oct 2026 08:04:08 +0000 To: netdev-bot+sashiko@kernel.org, "D . Wythe" , Dust Li , Sidraya Jayagond , Mahanta Jambigi , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S . Miller" From: Bryam Vargas Cc: Simon Horman , Tony Lu , Wen Gu , Wenjia Zhang , Hidayath Khan , Ursula Braun , Stefan Raspl , linux-s390@vger.kernel.org, linux-rdma@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net] net/smc: don't spin in smc_rx_recvmsg() while a pipe holds spliced data Message-ID: <20261029080359.961295-1-hexlabsecurity@proton.me> In-Reply-To: <179209723095.434549.11206499945190748009@kernel.org> References: <20261013-b4-disp-193a2a59-v1-1-ed88ac10a41c@proton.me> <179209723095.434549.11206499945190748009@kernel.org> Feedback-ID: 199661219:user:proton X-Pm-Message-ID: f58622c7d2ed4f0b82b621aff97d67460d027f59 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 15 Oct 2026 20:47:10 +0000, netdev-bot+sashiko@kernel.org wrote: > [Severity: Medium] > Can this wait miss the final wakeup on weakly ordered architectures? Yes. Between the entry's store in add_wait_queue() and the read of splice_pending the sleeper only has an unlock and a lock acquire, not a full barrier; the release side reads the list after its own smp_mb(), so the gap is the sleeper's. v2 puts an smp_mb() after add_wait_queue(). Checked with herd7 against LKMM: the lost wake is allowed without it, forbidden with it. smc_rx_wait() has the same gap, but every CDC message that brings data wakes it again; this wait has only the pipe release to wake it, so the barrier matters here. Moving the decrement under lock_sock() is the change Hidayath Khan announced in [1]; the barrier closes the window on its own and doesn't depend on it. > [Severity: Low] > Should smc_rx_wait_splice() do the same? Yes, v2 sets and clears SOCKWQ_ASYNC_WAITDATA around the sleep. Measured on the v1 setup with one more case, an O_ASYNC reader owned by the reading thread, blocked behind the pipe while the peer sends one more byte: v1 returns -EINTR within 1 ms of the byte, v2 sleeps on and reads the next 4096 bytes once the pipe is drained, as the unpatched kernel does. > [Severity: Medium] > This is a pre-existing issue that this patch didn't introduce: can the > splice path read a stale splbytes here? It can; the fix is Hidayath's change in [1]. This patch doesn't touch that path. > [Severity: Medium] > This is a pre-existing issue rather than one added by this patch, but > smc_poll() still disagrees with this -EAGAIN: The commit message of v2 now says so: a non-blocking read behind the pipe returns -EAGAIN while poll() reports the socket readable, since bytes_to_rcv counts the data behind the pipe. A level-triggered loop that keeps the spliced bytes in a pipe gets EPOLLIN and -EAGAIN until it drains that pipe; before the patch the same read didn't return until the drain, asleep, one pass per tick, not spinning (measured). Looking at splice_pending in smc_poll() would hide data splice() can still take (a second splice with the first undrained returns the next 4096 bytes at once, measured), so v2 leaves poll() alone; the pipe release wakes the socket. [1] https://lore.kernel.org/all/7a174d1f-80d8-4294-ae66-829c9dacd662@linux.= ibm.com/ pw-bot: cr