Re: [PATCH net-next 3/6] af_iucv: convert to getsockopt_iter

[Breno Leitao <leitao@debian.org>]

On Thu, May 14, 2026 at 12:45:01PM +0000, sashiko-bot@kernel.org wrote:
> If iucv->hs_dev is cleared concurrently by another thread holding the lock
> (such as during iucv_sock_close), could the compiler emit two separate
> memory loads for hs_dev since READ_ONCE() isn't used?

It is unclear  if there is another concurrent user here, honestly.

iucv_sock_close() is the only writer of iucv->hs_dev and only runs from the
protocol release callback, which the socket layer invokes after the last file
reference drops. 

The getsockopt() syscall holds an fd reference for its entire duration via
fdget()/fdput(), so iucv_sock_close() cannot run concurrently with the
SO_MSGSIZE read on the same socket. There is no other writer of hs_dev, and the
aligned pointer load cannot tear on any architecture Linux supports, so the
existing code cannot observe a NULL dereference or use-after-free in practice.

At the same time, SO_MSGLIMIT has the lock:

          case SO_MSGLIMIT:
                  lock_sock(sk);
                  val = (iucv->path != NULL) ? iucv->path->msglim /* connected */
                                             : iucv->msglimit;    /* default */
                  release_sock(sk);
                  break;

So, although this is not an issue per-se, it is an extra safe to get a lock
around iucv->hs_dev in SO_MSGSIZE as well, more as a defensive programming than
a bug fix.

That said, my plan is to include this lock protection in my series, but not as
a fix (thus, not sending to 'net')