Linux-Next discussions
 help / color / mirror / Atom feed
From: Allison Henderson <achender@kernel.org>
To: Matthieu Baerts <matttbe@kernel.org>, Breno Leitao <leitao@debian.org>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	 linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com,
	 linux-kselftest@vger.kernel.org, kernel-team@meta.com,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>, Shuah Khan <shuah@kernel.org>,
	Andy Grover <andy.grover@oracle.com>,
	Mark Brown <broonie@kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>
Subject: Re: [PATCH net-next v3 2/2] rds: convert to getsockopt_iter: manual merge
Date: Thu, 11 Jun 2026 11:35:28 -0700	[thread overview]
Message-ID: <1101d5bd0bb23a07f5184f9f448d71e5649fdf75.camel@kernel.org> (raw)
In-Reply-To: <2e1b0534-a1a0-4eb1-a5e2-d42fcf991188@kernel.org>

On Thu, 2026-06-11 at 14:52 +0200, Matthieu Baerts wrote:
> Hi Breno, Allison,
> 
> On 08/06/2026 11:44, Breno Leitao wrote:
> > Convert RDS socket's getsockopt implementation to use the new
> > getsockopt_iter callback with sockopt_t.
> > 
> > Key changes:
> > - Replace (char __user *optval, int __user *optlen) with sockopt_t *opt
> > - Use opt->optlen for buffer length (input) and returned size (output)
> > - Use copy_to_iter() instead of put_user()/copy_to_user()
> > 
> > The RDS_INFO_* snapshot path in rds_info_getsockopt() used to pin the
> > userspace buffer with pin_user_pages_fast() on the raw optval address;
> > the info producers then memcpy into those pages under a spinlock via
> > kmap_atomic() and so must not fault. Obtain the same page array and
> > starting offset from opt->iter_out with iov_iter_extract_pages(), which
> > pins for write because iter_out is ITER_DEST.
> > 
> > The page array is preallocated here (sized with iov_iter_npages()) and
> > passed in, so iov_iter_extract_pages() fills it in place rather than
> > allocating one for us; RDS therefore keeps ownership of the array on
> > every return path and frees it itself. The rds_info_iterator /
> > rds_info_copy machinery and all producer callbacks are unchanged.
> > 
> > Kernel buffers (ITER_KVEC) are not page-backed in a way the info
> > producers can use, so the RDS_INFO path returns -EOPNOTSUPP for them;
> > this matches the previous behaviour, where a kernel-buffer getsockopt
> > hit the WARN_ONCE() path in do_sock_getsockopt() and returned
> > -EOPNOTSUPP. The simple RDS_RECVERR and SO_RDS_TRANSPORT options keep
> > working for kernel buffers via copy_to_iter().
> 
> (...)
> 
> > diff --git a/net/rds/info.c b/net/rds/info.c
> > index f1b29994934a..499b3774860e 100644
> > --- a/net/rds/info.c
> > +++ b/net/rds/info.c
> 
> (...)
> 
> > @@ -230,13 +239,16 @@ int rds_info_getsockopt(struct socket *sock, int optname, char __user *optval,
> >  		ret = lens.each;
> >  	}
> >  
> > -	if (put_user(len, optlen))
> > -		ret = -EFAULT;
> > +	opt->optlen = len;
> >  
> >  out:
> > -	if (pages)
> > +	/*
> > +	 * iov_iter_extract_pages() pins only user-backed (ubuf) iters;
> > +	 * iov_iter_extract_will_pin() reports whether an unpin is owed here.
> > +	 */
> > +	if (pages && iov_iter_extract_will_pin(&opt->iter_out))
> >  		unpin_user_pages(pages, nr_pages);
> 
> FYI, we got a small conflict when merging 'net' in 'net-next' in the
> MPTCP tree due to this patch applied in 'net':
> 
>   f512db8267b73 ("rds: mark snapshot pages dirty in rds_info_getsockopt()")
> 
> and this one from 'net-next':
> 
>   6e94eeb2a2a6 ("rds: convert to getsockopt_iter")
> 
> ----- Generic Message -----
> The best is to avoid conflicts between 'net' and 'net-next' trees but if
> they cannot be avoided when preparing patches, a note about how to fix
> them is much appreciated.
> 
> The conflict has been resolved on our side [1] and the resolution we
> suggest is attached to this email. Please report any issues linked to
> this conflict resolution as it might be used by others. If you worked on
> the mentioned patches, don't hesitate to ACK this conflict resolution.
> ---------------------------
> 
> Regarding this conflict, I took the modification from net-next, but
> using unpin_user_pages_dirty_lock() from net.

Hi Matt,

Yes, the conflict resolution looks correct to me.  
Thank you for fixing this.

Allison

> 
> Rerere cache is available in [2].
> 
> Cheers,
> Matt
> 
> 1: https://github.com/multipath-tcp/mptcp_net-next/commit/a8d41e018cc6
> 2: https://github.com/multipath-tcp/mptcp-upstream-rr-cache/commit/88eeb
> 
> Cheers,
> Matt


  reply	other threads:[~2026-06-11 18:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260608-getsock_more-v3-0-706ecf2ea332@debian.org>
     [not found] ` <20260608-getsock_more-v3-2-706ecf2ea332@debian.org>
2026-06-11 12:52   ` [PATCH net-next v3 2/2] rds: convert to getsockopt_iter: manual merge Matthieu Baerts
2026-06-11 18:35     ` Allison Henderson [this message]
2026-06-12  8:19     ` Breno Leitao
2026-06-12 11:41       ` Matthieu Baerts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1101d5bd0bb23a07f5184f9f448d71e5649fdf75.camel@kernel.org \
    --to=achender@kernel.org \
    --cc=andy.grover@oracle.com \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kernel-team@meta.com \
    --cc=kuba@kernel.org \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=matttbe@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rds-devel@oss.oracle.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox