net/iucv: serialize the HiperSockets receive path with the socket lock

v2 of stage 1 of the socket-locking rework [1], answering the reviews of v1 [2]: Jakub's three points [3] (no forward declarations, a trimmed commit message, and the AI review's items answered, here in the changelog), the list's AI review [4] and Hidayath's test rounds on z/VM [5], including his KCSAN report [6].

Changes in v2:

- a SYN|ACK, SYN|FIN or FIN that arrives while a task owns the socket is recorded in the socket, as bits (one SYN reply, the first to arrive, and a FIN), and applied in that order by the owner from release_cb(), not queued: v1's backlog path dropped a pfmemalloc skb, which qeth hands us under memory pressure, and nothing resends a control frame, so one queued there could be lost for good. The backlog still takes data frames in three cases: while the reply to our SYN is pending, behind frames already waiting, and a listener's SYNs, trimmed to their header. v1 charged deferred control frames to a budget; a stray control frame, a repeated SYN from a conforming peer or junk, can no longer push a FIN out of it (AI review)
- the data budget, the msg_recv check in recvmsg() and the window-update threshold read the window advertised in the SYN, kept in a new msglimit_adv, not the live SO_MSGLIMIT: lowering it in IUCV_BOUND no longer loses data (AI review, Hidayath's reproducer)
- a SYN|ACK or SYN|FIN that no socket state accepts is freed in afiucv_hs_rcv(), and a SYN to a socket that does not listen is refused there; a deferred SYN is refused when applied if the listener closed or its accept queue filled meanwhile
- iucv_sock_shutdown() sets sk_shutdown and purges under sk_lock.slock on
HiperSockets: the data frame that bypasses the backlog tests RCV_SHUTDOWN under that lock (Hidayath, KCSAN)
- a reader parked when the peer closed gets EOF, not -ENOTCONN, and poll() reports EPOLLRDHUP: 1/2's wait loop returns EOF on IUCV_DISCONN with nothing left, which also covers the z/VM sever; 2/2, new in v2, sets RCV_SHUTDOWN at the FIN (Hidayath, AI review)
- no forward declaration for afiucv_hs_dispatch(); two remain, for the backlog and release_cb handlers referenced from the proto and iucv_sock_alloc(). They sit in the file's existing block of them, which aa5ec571b93f added to in September; if the IUCV maintainers would rather see the handlers moved below their users, that is fine by me (Jakub)
- the SHT accounting and the hs_dev ordering went to net as fixes of their own [7]; commit message trimmed (Jakub)

Applies on top of [7].

Tested like v1, on s390x under QEMU TCG, net-next 8df0638138d3, KASAN + PROVE_LOCKING + DEBUG_ATOMIC_SLEEP, this time against an emulated HiperSockets adapter under the real qeth and qdio drivers, tx completion included, and an emulated CP for the z/VM transport. Of the 53 default tests bare net-next fails 8 (7 with [7] applied; its 2/2 fixes one), v1 fails one (the parked reader) and this series fails none, with no KASAN or lockdep report. Of 10 kernels each missing
one piece of it, 9 fail a test this series passes; the shutdown spinlock's piece shows only under a probe that widens the window with udelay(), and the one without the filter that frees stray control frames in afiucv_hs_rcv() passes every test, told apart only by the probe's frame count. The opt-in sets (window, strays, shutdown under the probe, z/VM, MTTCG at HZ=100) and the details are below the --- of 1/2.

QEMU is patched too. Hidayath's table, compared with the code, showed that TCG's s390x CPU emulation lacked things this needs; besides the adapter, the QEMU here carries my patches for that, a large set too specific to this setup to go to QEMU as it is. Where this setup and Hidayath's z/VM runs disagree, the hardware is the reference.

Still open, as in v1: afiucv_hs_callback_txnotify() and the z/VM callbacks change sk_state without checking whether a task owns the socket, and so does afiucv_netdev_event(), whose fix Nagamani is holding for this series [8]. backlog_skb_q stays unbounded for a peer that ignores its window, on net-next as here; release_cb() exists now, and Hidayath's proposal to reset the socket on an overrun from it goes on top. The child socket leaked on afiucv_hs_callback_syn()'s refusal paths is pre-existing; Hidayath flagged it in August [9] and his fix for it is pending.

[1] https://lore.kernel.org/all/[email protected]/
[2] https://lore.kernel.org/netdev/[email protected]/
[3] https://lore.kernel.org/netdev/[email protected]/
[4] https://lore.kernel.org/netdev/[email protected]/
[5] https://lore.kernel.org/netdev/[email protected]/
[6] https://lore.kernel.org/netdev/[email protected]/
[7] https://lore.kernel.org/netdev/[email protected]/
[8] https://lore.kernel.org/netdev/[email protected]/
[9] https://lore.kernel.org/netdev/[email protected]/

---
Bryam Vargas (2):
net/iucv: serialize HiperSockets receive with the socket lock net/iucv: return EOF to a reader parked at the HiperSockets peer's FIN

 include/net/iucv/af_iucv.h |   5 +
 net/iucv/af_iucv.c         | 564 +++++++++++++++++++++++++++++++++++----------
 2 files changed, 444 insertions(+), 125 deletions(-)

---
base-commit: 8df0638138d3e0344fd1fb36cf2d1ca1cf5028f0
change-id: 20261022-b4-disp-1d26b87a-747c9d4b1953
prerequisite-message-id: <[email protected]>
prerequisite-patch-id: 5ef9b0bd1d5842e07b00218ef6ab3f8dd53431fe
prerequisite-patch-id: ff94c57f1b7a45e7bf1d178b252018fac71c6190

Best regards,

Bryam Vargas <[email protected]>

The HiperSockets receive callbacks change sk_state under bh_lock_sock() without checking sock_owned_by_user(), so a FIN or SYN|ACK is applied while a task owns the socket and acts on the state it read. recvmsg() takes no socket lock and sends a due window update in any state, even after the FIN; one that fails keeps its credit.

Take bh_lock_sock() once in afiucv_hs_rcv(). While a task owns the socket, a SYN|ACK, SYN|FIN or FIN is recorded in the socket and applied by the owner from proto->release_cb: nothing resends a control frame, so none may be dropped, as the socket backlog drops a pfmemalloc skb. Data, SHT and WIN frames do not change sk_state, so they go through under sk_lock.slock, reading a state the owner may be changing: a data frame queues or is dropped, a WIN credits the sender, and iucv_sock_destruct() now purges backlog_skb_q for one that queued after close(). They wait in the socket backlog while the reply to our SYN is pending, and behind frames already waiting, counted in frames rather than bytes, up to the window we gave the peer plus one, which a conforming peer does not exceed; the reply is applied before them. A listener's SYNs wait the same way, cut to their header, up to its accept queue plus one; past that, or when the backlog cannot take the skb, they are refused at once, without a child, and so is one the listener cannot take when it is applied: closed, or its accept queue full, meanwhile. A SYN|ACK or SYN|FIN no socket state can use is freed in afiucv_hs_rcv(), a SYN for a socket that does not listen refused there.

The window given to the peer is kept in msglimit_adv: the SYN carries msglimit, and SO_MSGLIMIT may lower msglimit while the reply is awaited. The backlog budget, the receive check in recvmsg() and the window-update threshold read the window advertised, which a conforming peer keeps to. recvmsg() runs under lock_sock() on both transports and sleeps without it; a reader parked when the connection goes sees EOF once nothing is left, as a fresh call does. A due window update goes out only while connected, else the credit is dropped. shutdown() sets RCV_SHUTDOWN and purges under the socket spinlock, where the data path tests it. sendmsg() waits for memory without the lock and fails with EPIPE once sending is shut down. Control frames go out after shutdown(SHUT_WR) without clearing SEND_SHUTDOWN around their allocation; the FIN and the first SHT go out past sk_sndbuf, as qeth keeps sent skbs charged until TX completion.

---
v2:
- control frames that arrive while a task owns the socket (SYN|ACK, SYN|FIN, FIN) are recorded in iucv_sock (hs_pending, the SYN|ACK's
window with it) and applied from iucv_proto.release_cb; the first
reply to our SYN decides, a FIN applies after it. The backlog keeps
data, SHT and WIN frames while the reply to our SYN is pending or
behind frames already waiting, and a listener's SYNs; a SYN that
waits is cut to its header and holds its device for the reply, and
is refused without a child if the listener closed, or its accept
queue filled, meanwhile.
afiucv_hs_backlog_rcv() applies a pending reply before the frame it
runs; a socket closed meanwhile applies nothing (__iucv_sock_close() leaves IUCV_BOUND as it is). The refusal test there repeats the one in afiucv_hs_callback_syn(), which still allocates the child before it tests; moving that allocation, and freeing the child on the refusal
and transmit-failure paths, is the pre-existing leak Hidayath's fix covers, and this patch does not touch that path.
- the rework stays one patch: the lock in afiucv_hs_rcv(), the
record/apply pair and the backlog budget each close a window the
others open; msglimit_adv is the budget's window; recvmsg() under lock_sock() is what makes release_cb() the owner's point.
- iucv_sock_destruct() purges backlog_skb_q: a data frame that races __iucv_sock_close()'s purge under sk_lock.slock is freed with the
socket instead of leaking (pre-existing; the bypass path makes it a question this patch has to answer)
- msglimit_adv records the window advertised in the SYN (on the
listener's child, in the SYN|ACK); the data budget, the msg_recv
check in recvmsg() and the window-update threshold read it. The WRITE_ONCE() on msglimit in setsockopt() is gone with it. (The AI review's item on v1; Hidayath's reproducer, SO_MSGLIMIT lowered in IUCV_BOUND, lost data on v1.)
- afiucv_hs_stray(): unknown flags, and a SYN|ACK or SYN|FIN for a
socket not in IUCV_BOUND, are freed in afiucv_hs_rcv() as NO_SOCKET;
a SYN for a socket that does not listen is refused there without allocating a child
- iucv_sock_shutdown() takes sk_lock.slock around the sk_shutdown set
and the purge on HiperSockets; the z/VM branch is unchanged
- iucv_sock_recv_skb() returns EOF when the socket is IUCV_DISCONN with nothing queued, as the shortcut at the top of recvmsg() does
- afiucv_hs_dispatch() is defined before its callers; the declarations
of afiucv_hs_backlog_rcv() and afiucv_hs_release_cb() stay, with the file's four: iucv_proto and iucv_sock_alloc() point at them, and they dispatch to the SYN handler, which allocates sockets. The old block comment on the no-socket case went with the move; the dispatcher's comment says what a NULL socket means
- the SHT accounting, the WARN_ON on the overrun path and the hs_dev ordering are fixes in net now; the commit message is shorter
v1: https://lore.kernel.org/netdev/[email protected]/

Tested on s390x under QEMU TCG (no Z here), net-next 8df0638138d3, KASAN + PROVE_LOCKING + DEBUG_ATOMIC_SLEEP, as v1 was, with one change in the setup: instead of lo and injected SYN|ACKs, the guest now has two emulated HiperSockets adapters on one LAN under the real qeth and qdio drivers, so every SYN, SYN|ACK, FIN and window update is a frame af_iucv itself sent and received, and tx completion is the adapter's: at once, late (QAOB), or parked while the peer has no receive buffer. The z/VM transport runs against an emulated CP (IUCV CONNECT, SEND, SEVER as the CP Programming Services book describes them). Two vCPUs under -icount for all but one test, MTTCG at HZ=100 for that one. The emulation does what the drivers expect; where they leave a choice, the choice is mine.

The default set is 53 tests. net-next fails 8 of them: data sent after the socket's own SHT by a writer parked on the window, and a writer that waits out SO_SNDTIMEO after that shutdown; -EFAULT instead of EOF when the SHT's empty frame is counted past the window; a SHT and the FIN of a device going down lost to a full send buffer; a window update after the peer's FIN; -ECONNRESET for a stream the socket shut down itself; a reader parked at the FIN woken to -ENOTCONN. v1 fails the last one only. This series fails none, with no KASAN or lockdep report. The opt-in tests: SO_MSGLIMIT lowered in IUCV_BOUND (three forms: before the SYN|ACK, with the reader holding the socket, with the minimum SO_RCVBUF), a stray SYN|ACK and junk ahead of the FIN, a repeated SYN ahead of it, the SHT past the window, the leaked child of a refused SYN, a reader blocked at the FIN and poll() after it, shutdown(SHUT_RD) against a frame in flight under a probe that widens the gap (udelay(50) on both sides), the z/VM group, and two readers at once under MTTCG. With this series: all 8 messages arrive in the three forms (v1 delivers 3 of 8 in two of them; net-next delivers 8 and closes the socket with -EFAULT in the third); the FIN is applied in both stray tests where v1 loses it; EOF for the SHT past the window where net-next gives WARN and -EFAULT; the parked reader gets EOF and poll() reports EPOLLRDHUP, -ENOTCONN and no RDHUP on net-next and v1; 0 reads of data after SHUT_RD in 200 under the probe over three seeds, 17 to 21 without the spinlock; the z/VM sever wakes the sleeping reader with EOF, -ENOTCONN on net-next; net-next fails the two-reader test in all three MTTCG runs, this series passes them. The refused SYN leaks its child on every kernel, as Hidayath reported: 1056 refused leave 1056 sockets behind, and the control that accepts its 17 frees all 17.

10 kernels each remove or weaken one piece of this series. Nine fail a test this series passes: the budget on the live SO_MSGLIMIT loses data (3 of 8); release_cb() applying nothing leaves connect() waiting for a SYN|ACK the socket recorded; the SYN reply applied only after the backlog dispatches data in IUCV_BOUND and loses it; the SHT counted gives -EFAULT where this series gives EOF; shutdown without the spinlock gives the 17 to 21 late reads above, under the probe only; the wait loop without EOF on IUCV_DISCONN gives -ENOTCONN at the z/VM sever; 1/2 without 2/2 gives EOF without RDHUP; the fixes of [3] alone fail net-next's set minus the window refusal; and the kernel that defers nothing (every frame dispatched under the owner, net-next's race) shows data to poll() on a socket a task owns, in the window tests, and three default tests log it as applying where this series defers. One passes every test: the kernel without the stray filter in afiucv_hs_rcv() records a stray control frame and applies it as a no-op on release instead of freeing it, which only the probe sees. Two pre-existing z/VM findings show on every kernel and are read as such.

Not covered: real hardware, KCSAN (your run is the witness for the sk_shutdown race), and the z/VM callbacks' sk_state writes, which this series does not touch. Logs on request.

---
 include/net/iucv/af_iucv.h |   5 +
 net/iucv/af_iucv.c         | 560 +++++++++++++++++++++++++++++++++++----------
 2 files changed, 440 insertions(+), 125 deletions(-)

index df85d19fbf84..85b35cc88f0b 100644
@@ -130,11 +130,16 @@ struct iucv_sock {
 	u8			flags;
 	u16			msglimit;
 	u16			msglimit_peer;
+	u16			msglimit_adv;	/* the window given to the peer */
+	u8			hs_pending;	/* control frames recorded for the owner */
+	u16			hs_pending_window;
 	atomic_t		skbs_in_xmit;
 	atomic_t		msg_sent;
 	atomic_t		msg_recv;
 	atomic_t		pendings;
 	int			transport;
+	unsigned int		hs_backlog_data;	/* frames waiting in sk_backlog */
+	unsigned int		hs_backlog_syn;
 	void			(*sk_txnotify)(struct sock *sk,
 					       enum iucv_tx_notify n);
 };

2.56.0

Hi Bryam,
thank you very much for this.
To me this is the most urgent of the open fixes. I'd like to focus on getting this upstream. My hope is that the other open issues can then be more easily be written on top of this one. Also it should then be easier to clarify the impact of the remeining issues, right now many of them suffer from the incomplete socket lock.
I may be wrong with this assesment.

To me this patch looks very good right now.
Can we reduce the scope even more?
Can you polish the style (comments, commit message) some more? The design is not trivial, so future readers, editors and debuggers will be thankful for the effort.

For stable team to evaluate, the commit message should include symptoms, conditions and consequences.

Let us know, if you want Hidayath or myself to take on any of this.

what follows is alist of 3(?) problems in current code, may format it as a list?

What are possible consequences? UAF? Can you give 1 example, maybe even with
KASAN(?) output?

Is that a problem? Or only bad style?

You mean, when sending out a WIN fails?
What are the consequences? Overrun scenario? But isn't that covered by your other patch [1] ?

It took me a while to understand this.
I guess you are saying: Don't queue the SYN|ACK, SYN|FIN or FIN, because they must not be dropped, not even unde rmemory pressure?

I wonder, if you can split the msglimit_adv vs msglimit into a separate patch?

[...]

^^ This comment sounds important, but I don't get what it is trying to point out. (After reading the code changes, I think I have an idea what it is referring to)

It ma ybe helpful to mention why we need to count frames: Because msglimit for iucv is defined in frames (?).

Data, SHT and WIN frames get the window we gave

Alexandra,

[...]

Yes. v3 [1] is on net, with nothing under it, and split so that the lock patch, 5/7, has only the softirq side:

  1/7  msglimit_adv, on its own
  2/7  sendmsg() fails with -EPIPE when sending is shut down under it
  3/7  recvmsg() under lock_sock()
  4/7  code moved for 5/7, no functional change
  5/7  the HiperSockets rx path under the socket lock
  6/7  RCV_SHUTDOWN set under sk_lock.slock
  7/7  EOF for a reader parked when the peer closes (was 2/2)

v3 drops the iucv_send_ctrl() rewrite, the window update only while connected and the credit reset. With them out, v3 fails five of my 53 default tests, the way net fails them; the cover letter lists them so nobody reads them as regressions.

Every function 4/7 and 5/7 add has a kernel-doc header that says who holds what (softirq under bh_lock_sock(), or the owner under sk_lock.slock) and what the function decides; the comments inside are in net style and short.

Each of the six that fix something says what is seen, under which conditions and what it costs, and has its Fixes: tag. 4/7 only moves code.

One thing, and it's the part I can't do: the run on z/VM. Hidayath's numbers on v1 [2] are what I calibrated my setup against, and v3 moves enough code that I'd like the same run on it before the RFC tag goes:
the scenarios at 120 s each with net as the baseline, the blocked reader and SO_MSGLIMIT in IUCV_BOUND, and the KCSAN build. Here it's QEMU TCG with an emulated adapter and CP: rates, KCSAN and real SMP only come from the hardware. The cover letter says what I expect from each scenario, patch by patch, so a miss is easy to spot.

3/7 lists the three that are recvmsg()'s own. 5/7 has the softirq's two in its first paragraph, and a list for what happens to each kind of frame. The window update and the credit are out.

No UAF AFAICT, and no KASAN splat: the KASAN runs here and Hidayath's are clean on net-next for these paths. What's measured is wrong behaviour and leaks, not memory corruption. On his guest, 120 s per scenario on net-next: 3917 reads that go backwards with two readers on one socket, the sk_shutdown bit lost in 565 of 7281 cycles, data read after shutdown(SHUT_RD) in 32 of 212, and 29 KCSAN reports with af_iucv on both sides, 19 of them recvmsg() against shutdown().

The example in the commit message of 5/7 is a listener. A SYN that arrives while close() is emptying the accept queue is answered under the closing task, and its child is queued on a socket that is freed a moment later. Nothing can accept or close that child: it is never freed, and since it carries the listener's name, the next bind() to that name fails with -EADDRINUSE. I reproduced it on net with an mdelay() in iucv_sock_cleanup_listen() to hold the window open, which is otherwise a few instructions wide; with 5/7 and the same delay the SYN waits for the close and is refused. KASAN stayed quiet: the child's pointer to the freed listener is never followed.

The one that comes with kernel output is the third item of 3/7, which I found while reviewing v3: a MSG_PEEK read that a second reader overtakes never frees its skb, and iucv_sock_destruct() takes its WARN_ON() on sk_rmem_alloc when the socket goes. On net main:

  WARNING: net/iucv/af_iucv.c:292 at iucv_sock_destruct+0xb8/0xe0, CPU#1: init/1
  Call Trace:
   iucv_sock_destruct+0xbc/0xe0
   __sk_destruct+0x5a/0x430
   iucv_sock_release+0xbc/0xd0
   __sock_release+0x74/0x140
   sock_close+0x2a/0x40

It's gone with 3/7.

On its own, close to style: a window update for a peer that has sent its FIN is a frame nobody uses. It's the IUCV_CONNECTED test you suggested in July. v2 had it because the credit reset needed it (next point); v3 leaves that code as net has it. The test is in [3] 2/2, where you asked whether it can be false the next cycle without the socket lock. On top of v3 a FIN can no longer change sk_state under recvmsg() (5/7). afiucv_hs_callback_txnotify() and the netdev notifier still can; the cover letter lists both as open.

Yes, when iucv_send_ctrl() has no room in sk_sndbuf for the WIN:
recvmsg() sets IUCV_DISCONN and keeps msg_recv. The next frame read is the peer's SHT, counted one past the window: WARN_ON() and -EFAULT where EOF was due. And yes, your [1], which is [3] 2/2 below, covers it: with the SHT not counted, the credit that was kept cannot pass the window. So the reset is gone from v3. On net without [3] that case still ends in the WARN_ON(); one of my tests shows it on v3 as on net.

Yes. Nothing resends them, and the socket backlog can refuse an skb under memory pressure. The commit message and the comment on afiucv_hs_record() say so now.

1/7. It goes first because the backlog of 5/7 counts against that window; on the live msglimit it would drop data without a trace, which is what Hidayath's SO_MSGLIMIT scenario found on v1. On its own it fixes two things on net, both after SO_MSGLIMIT is changed with the SYN
out: lowered, the socket is closed on a peer that kept to its window (WARN_ON() and -EFAULT); raised far enough, the peer never gets a window update.

(the iucv_send_ctrl() rewrite) It isn't related to the lock, and it's out of v3. I wouldn't put it in [3] 2/2 either: that one is the receiver not counting an SHT, this is the sender finding no room in sk_sndbuf for its own FIN or SHT. What v3 keeps from that area is 2/7, which is sendmsg() only.

Done for everything the series adds.

v3 is on net main (8373c4e8863a) with nothing under it. Of [3], 1/2 applies on top of it as it is; 2/2 needs a rebase, since it touches the lines 1/7 changes.

(the atomic_set() of msg_recv) No, and it's out; see the credit above.

The two 3/7 adds to recvmsg() are unlock and err_unlock: they release the socket and return. 5/7 has one more, refuse, in afiucv_hs_backlog_add(), for a frame that cannot wait. done and err_out are the file's own; I left them so the diff stays on the locking.

It was wrong. "a reader holding the lock would otherwise wait for its own window" was the reason in an earlier draft, before recvmsg() slept without the lock. The kernel-doc on
afiucv_hs_defer() now gives the two cases in which a data, SHT or WIN frame waits: the reply to our SYN is recorded and not applied yet, so the socket is still IUCV_BOUND and would free the data; or frames wait already, and a later one must not overtake them.

[...]

Both taken. And yes, that's why: the window is in frames, and sk_add_backlog() counts bytes, the receive queue's included, so it can refuse a frame the peer was entitled to send.

Its shape is the same in v3. The filter at its top changed: the AI review of v2 [4] found that a FIN reaching a socket still in IUCV_BOUND was recorded and disconnected it once the SYN|ACK arrived, and that frames behind a recorded FIN were still taken. Both repro here on v2 and are fixed in 5/7.

Thanks for the review.

Bryam

[1] https://lore.kernel.org/netdev/[email protected]/
[2] https://lore.kernel.org/netdev/[email protected]/
[3] https://lore.kernel.org/netdev/[email protected]/
[4] https://lore.kernel.org/all/[email protected]/

After the peer's FIN only sk_state says the receive side is done. Before the previous patch a reader parked at the FIN returned -ENOTCONN (Hidayath Khan: 14151 of 14151 cycles between two z/VM guests); it now returns 0 by the IUCV_DISCONN test, while poll() still reports no EPOLLRDHUP for the peer's close.

Set RCV_SHUTDOWN where the FIN is applied, as TCP does: poll() reports EPOLLRDHUP, and recvmsg() ends the stream by the test it already uses for the peer's SHT.

---
On its own this covers the HiperSockets FIN; the z/VM sever reaches the sleeping reader through 1/2's wait loop. After 1/2 the write is under sk_lock.slock in every path (the owner's release_cb, or the softirq with no owner), where shutdown() writes the same field.

Measured in the emulated setup: poll() on the parked reader reports EPOLLRDHUP at the FIN with this patch, not without it (1/2 alone gives the reader EOF but no RDHUP; net-next and v1 give -ENOTCONN).

---
 net/iucv/af_iucv.c | 4 ++++
 1 file changed, 4 insertions(+)

index 15ce99e90c5b..f1a7bfa5a4b5 100644
@@ -2074,6 +2074,10 @@ static void afiucv_hs_synfin(struct sock *sk)
 static void afiucv_hs_fin(struct sock *sk)
 {
 	sk->sk_state = IUCV_DISCONN;
+	/* as TCP's FIN: a reader asleep here wakes to EOF, not -ENOTCONN,
+	 * and poll() reports EPOLLRDHUP
+	 */
+	WRITE_ONCE(sk->sk_shutdown, sk->sk_shutdown | RCV_SHUTDOWN);
 	sk->sk_state_change(sk);
 }
 

2.56.0