All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthieu Baerts <matttbe@kernel.org>
To: Geliang Tang <geliang@kernel.org>, mptcp@lists.linux.dev
Cc: Geliang Tang <tanggeliang@kylinos.cn>
Subject: Re: [PATCH mptcp-next v1 5/6] sock: add sock_kmemdup helper
Date: Mon, 24 Feb 2025 09:54:30 +0100	[thread overview]
Message-ID: <f40a2f15-7735-4131-8087-e5e1f1382f69@kernel.org> (raw)
In-Reply-To: <0a3f7a31983f0587ace333f349f3e630c49d075d.1740384564.git.tanggeliang@kylinos.cn>

Hi Geliang,

On 24/02/2025 09:13, Geliang Tang wrote:
> From: Geliang Tang <tanggeliang@kylinos.cn>
> 
> This patch adds the sock version of kmemdup() helper, named sock_kmemdup(),
> to duplicate a memory block using the socket's option memory buffer.
> 
> Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn>
> ---
>  include/net/sock.h |  1 +
>  net/core/sock.c    | 23 +++++++++++++++++++++++
>  2 files changed, 24 insertions(+)
> 
> diff --git a/include/net/sock.h b/include/net/sock.h
> index edbb870e3f86..ffd757e7e329 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -1793,6 +1793,7 @@ static inline struct sk_buff *sock_alloc_send_skb(struct sock *sk,
>  }
>  
>  void *sock_kmalloc(struct sock *sk, int size, gfp_t priority);
> +void *sock_kmemdup(struct sock *sk, const void *src, int size, gfp_t priority);
>  void sock_kfree_s(struct sock *sk, void *mem, int size);
>  void sock_kzfree_s(struct sock *sk, void *mem, int size);
>  void sk_send_sigurg(struct sock *sk);
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 0d385bf27b38..d09bd697c120 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2805,6 +2805,29 @@ void *sock_kmalloc(struct sock *sk, int size, gfp_t priority)
>  }
>  EXPORT_SYMBOL(sock_kmalloc);
>  
> +/*
> + * Duplicate a memory block using the socket's option memory buffer.
> + */
> +void *sock_kmemdup(struct sock *sk, const void *src, int size, gfp_t priority)
> +{
> +	int optmem_max = READ_ONCE(sock_net(sk)->core.sysctl_optmem_max);
> +
> +	if ((unsigned int)size <= optmem_max &&
> +	    atomic_read(&sk->sk_omem_alloc) + size < optmem_max) {
> +		void *mem;
> +		/* First do the add, to avoid the race if kmalloc
> +		 * might sleep.
> +		 */
> +		atomic_add(size, &sk->sk_omem_alloc);
> +		mem = kmemdup(src, size, priority);
> +		if (mem)
> +			return mem;
> +		atomic_sub(size, &sk->sk_omem_alloc);

I'm not really convinced by this helper: it is a duplication of
sock_kmalloc(), and it is only used once in MPTCP code.

Calling sock_kmalloc() + memset, and using this new helper in different
places in the net code might help. But still, I don't know if this would
be accepted, it is only saving one line (plus memcpy() will be used when
it is not needed, same for the previous patch at the end).

If you still want to propose that, I suggest sending a dedicated series
to netdev, not to block MPTCP (only) patches. WDYT?

Cheers,
Matt
-- 
Sponsored by the NGI0 Core fund.


  reply	other threads:[~2025-02-24  8:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-24  8:13 [PATCH mptcp-next v1 0/6] BPF path manager, part 4 Geliang Tang
2025-02-24  8:13 ` [PATCH mptcp-next v1 1/6] mptcp: pm: in-kernel: avoid access entry without lock Geliang Tang
2025-02-24  8:31   ` Matthieu Baerts
2025-02-24 11:02     ` Matthieu Baerts
2025-02-24  8:13 ` [PATCH mptcp-next v1 2/6] mptcp: pm: in-kernel: reduce parameters of set_flags Geliang Tang
2025-02-24  8:13 ` [PATCH mptcp-next v1 3/6] mptcp: pm: use addr entry for get_local_id Geliang Tang
2025-02-24  8:13 ` [PATCH mptcp-next v1 4/6] mptcp: pm: in-kernel: use kmemdup helper Geliang Tang
2025-02-24  8:13 ` [PATCH mptcp-next v1 5/6] sock: add sock_kmemdup helper Geliang Tang
2025-02-24  8:54   ` Matthieu Baerts [this message]
2025-02-24 10:42     ` Geliang Tang
2025-02-24 10:59       ` Matthieu Baerts
2025-02-24  8:13 ` [PATCH mptcp-next v1 6/6] mptcp: pm: userspace: use " Geliang Tang
2025-02-24  9:22 ` [PATCH mptcp-next v1 0/6] BPF path manager, part 4 MPTCP CI
2025-02-24 11:05 ` Matthieu Baerts
2025-02-26 16:29   ` 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=f40a2f15-7735-4131-8087-e5e1f1382f69@kernel.org \
    --to=matttbe@kernel.org \
    --cc=geliang@kernel.org \
    --cc=mptcp@lists.linux.dev \
    --cc=tanggeliang@kylinos.cn \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.