netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t
@ 2023-12-01 13:10 Daniel Borkmann
  2023-12-01 15:03 ` Willem de Bruijn
                   ` (3 more replies)
  0 siblings, 4 replies; 5+ messages in thread
From: Daniel Borkmann @ 2023-12-01 13:10 UTC (permalink / raw)
  To: netdev
  Cc: Daniel Borkmann,
	The UK's National Cyber Security Centre (NCSC),
	Greg Kroah-Hartman, Willem de Bruijn, Linus Torvalds, stable

In some potential instances the reference count on struct packet_sock
could be saturated and cause overflows which gets the kernel a bit
confused. To prevent this, move to a 64-bit atomic reference count on
64-bit architectures to prevent the possibility of this type to overflow.

Because we can not handle saturation, using refcount_t is not possible
in this place. Maybe someday in the future if it changes it could be
used. Also, instead of using plain atomic64_t, use atomic_long_t instead.
32-bit machines tend to be memory-limited (i.e. anything that increases
a reference uses so much memory that you can't actually get to 2**32
references). 32-bit architectures also tend to have serious problems
with 64-bit atomics. Hence, atomic_long_t is the more natural solution.

Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk>
Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@kernel.org
---
 [ No Fixes tag, needed for all currently maintained stable kernels. ]

 v1 -> v2:
   - Switch from atomic64_t to atomic_long_t (Linus)

 net/packet/af_packet.c | 16 ++++++++--------
 net/packet/internal.h  |  2 +-
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index a84e00b5904b..7adf48549a3b 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -4300,7 +4300,7 @@ static void packet_mm_open(struct vm_area_struct *vma)
 	struct sock *sk = sock->sk;
 
 	if (sk)
-		atomic_inc(&pkt_sk(sk)->mapped);
+		atomic_long_inc(&pkt_sk(sk)->mapped);
 }
 
 static void packet_mm_close(struct vm_area_struct *vma)
@@ -4310,7 +4310,7 @@ static void packet_mm_close(struct vm_area_struct *vma)
 	struct sock *sk = sock->sk;
 
 	if (sk)
-		atomic_dec(&pkt_sk(sk)->mapped);
+		atomic_long_dec(&pkt_sk(sk)->mapped);
 }
 
 static const struct vm_operations_struct packet_mmap_ops = {
@@ -4405,7 +4405,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
 
 	err = -EBUSY;
 	if (!closing) {
-		if (atomic_read(&po->mapped))
+		if (atomic_long_read(&po->mapped))
 			goto out;
 		if (packet_read_pending(rb))
 			goto out;
@@ -4508,7 +4508,7 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
 
 	err = -EBUSY;
 	mutex_lock(&po->pg_vec_lock);
-	if (closing || atomic_read(&po->mapped) == 0) {
+	if (closing || atomic_long_read(&po->mapped) == 0) {
 		err = 0;
 		spin_lock_bh(&rb_queue->lock);
 		swap(rb->pg_vec, pg_vec);
@@ -4526,9 +4526,9 @@ static int packet_set_ring(struct sock *sk, union tpacket_req_u *req_u,
 		po->prot_hook.func = (po->rx_ring.pg_vec) ?
 						tpacket_rcv : packet_rcv;
 		skb_queue_purge(rb_queue);
-		if (atomic_read(&po->mapped))
-			pr_err("packet_mmap: vma is busy: %d\n",
-			       atomic_read(&po->mapped));
+		if (atomic_long_read(&po->mapped))
+			pr_err("packet_mmap: vma is busy: %ld\n",
+			       atomic_long_read(&po->mapped));
 	}
 	mutex_unlock(&po->pg_vec_lock);
 
@@ -4606,7 +4606,7 @@ static int packet_mmap(struct file *file, struct socket *sock,
 		}
 	}
 
-	atomic_inc(&po->mapped);
+	atomic_long_inc(&po->mapped);
 	vma->vm_ops = &packet_mmap_ops;
 	err = 0;
 
diff --git a/net/packet/internal.h b/net/packet/internal.h
index d29c94c45159..d5d70712007a 100644
--- a/net/packet/internal.h
+++ b/net/packet/internal.h
@@ -122,7 +122,7 @@ struct packet_sock {
 	__be16			num;
 	struct packet_rollover	*rollover;
 	struct packet_mclist	*mclist;
-	atomic_t		mapped;
+	atomic_long_t		mapped;
 	enum tpacket_versions	tp_version;
 	unsigned int		tp_hdrlen;
 	unsigned int		tp_reserve;
-- 
2.34.1


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t
  2023-12-01 13:10 [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t Daniel Borkmann
@ 2023-12-01 15:03 ` Willem de Bruijn
  2023-12-01 15:12 ` Eric Dumazet
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 5+ messages in thread
From: Willem de Bruijn @ 2023-12-01 15:03 UTC (permalink / raw)
  To: Daniel Borkmann, netdev
  Cc: Daniel Borkmann,
	The UK's National Cyber Security Centre (NCSC),
	Greg Kroah-Hartman, Willem de Bruijn, Linus Torvalds, stable

Daniel Borkmann wrote:
> In some potential instances the reference count on struct packet_sock
> could be saturated and cause overflows which gets the kernel a bit
> confused. To prevent this, move to a 64-bit atomic reference count on
> 64-bit architectures to prevent the possibility of this type to overflow.
> 
> Because we can not handle saturation, using refcount_t is not possible
> in this place. Maybe someday in the future if it changes it could be
> used. Also, instead of using plain atomic64_t, use atomic_long_t instead.
> 32-bit machines tend to be memory-limited (i.e. anything that increases
> a reference uses so much memory that you can't actually get to 2**32
> references). 32-bit architectures also tend to have serious problems
> with 64-bit atomics. Hence, atomic_long_t is the more natural solution.
> 
> Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk>
> Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: stable@kernel.org
> ---
>  [ No Fixes tag, needed for all currently maintained stable kernels. ]
> 
>  v1 -> v2:
>    - Switch from atomic64_t to atomic_long_t (Linus)

Reviewed-by: Willem de Bruijn <willemb@google.com>


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t
  2023-12-01 13:10 [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t Daniel Borkmann
  2023-12-01 15:03 ` Willem de Bruijn
@ 2023-12-01 15:12 ` Eric Dumazet
  2023-12-01 23:02 ` Greg Kroah-Hartman
  2023-12-04 23:20 ` patchwork-bot+netdevbpf
  3 siblings, 0 replies; 5+ messages in thread
From: Eric Dumazet @ 2023-12-01 15:12 UTC (permalink / raw)
  To: Daniel Borkmann, netdev
  Cc: The UK's National Cyber Security Centre (NCSC),
	Greg Kroah-Hartman, Willem de Bruijn, Linus Torvalds, stable


On 12/1/23 14:10, Daniel Borkmann wrote:
> In some potential instances the reference count on struct packet_sock
> could be saturated and cause overflows which gets the kernel a bit
> confused. To prevent this, move to a 64-bit atomic reference count on
> 64-bit architectures to prevent the possibility of this type to overflow.
>
> Because we can not handle saturation, using refcount_t is not possible
> in this place. Maybe someday in the future if it changes it could be
> used. Also, instead of using plain atomic64_t, use atomic_long_t instead.
> 32-bit machines tend to be memory-limited (i.e. anything that increases
> a reference uses so much memory that you can't actually get to 2**32
> references). 32-bit architectures also tend to have serious problems
> with 64-bit atomics. Hence, atomic_long_t is the more natural solution.
>
> Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk>
> Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: stable@kernel.org
> ---
>   

Reviewed-by: Eric Dumazet <edumazet@google.com>



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t
  2023-12-01 13:10 [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t Daniel Borkmann
  2023-12-01 15:03 ` Willem de Bruijn
  2023-12-01 15:12 ` Eric Dumazet
@ 2023-12-01 23:02 ` Greg Kroah-Hartman
  2023-12-04 23:20 ` patchwork-bot+netdevbpf
  3 siblings, 0 replies; 5+ messages in thread
From: Greg Kroah-Hartman @ 2023-12-01 23:02 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: netdev, The UK's National Cyber Security Centre (NCSC),
	Willem de Bruijn, Linus Torvalds, stable

On Fri, Dec 01, 2023 at 02:10:21PM +0100, Daniel Borkmann wrote:
> In some potential instances the reference count on struct packet_sock
> could be saturated and cause overflows which gets the kernel a bit
> confused. To prevent this, move to a 64-bit atomic reference count on
> 64-bit architectures to prevent the possibility of this type to overflow.
> 
> Because we can not handle saturation, using refcount_t is not possible
> in this place. Maybe someday in the future if it changes it could be
> used. Also, instead of using plain atomic64_t, use atomic_long_t instead.
> 32-bit machines tend to be memory-limited (i.e. anything that increases
> a reference uses so much memory that you can't actually get to 2**32
> references). 32-bit architectures also tend to have serious problems
> with 64-bit atomics. Hence, atomic_long_t is the more natural solution.
> 
> Reported-by: "The UK's National Cyber Security Centre (NCSC)" <security@ncsc.gov.uk>
> Co-developed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: stable@kernel.org
> ---
>  [ No Fixes tag, needed for all currently maintained stable kernels. ]
> 
>  v1 -> v2:
>    - Switch from atomic64_t to atomic_long_t (Linus)

Thanks for changing this, looks good to me!

greg k-h

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t
  2023-12-01 13:10 [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t Daniel Borkmann
                   ` (2 preceding siblings ...)
  2023-12-01 23:02 ` Greg Kroah-Hartman
@ 2023-12-04 23:20 ` patchwork-bot+netdevbpf
  3 siblings, 0 replies; 5+ messages in thread
From: patchwork-bot+netdevbpf @ 2023-12-04 23:20 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: netdev, security, gregkh, willemdebruijn.kernel, torvalds, stable

Hello:

This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri,  1 Dec 2023 14:10:21 +0100 you wrote:
> In some potential instances the reference count on struct packet_sock
> could be saturated and cause overflows which gets the kernel a bit
> confused. To prevent this, move to a 64-bit atomic reference count on
> 64-bit architectures to prevent the possibility of this type to overflow.
> 
> Because we can not handle saturation, using refcount_t is not possible
> in this place. Maybe someday in the future if it changes it could be
> used. Also, instead of using plain atomic64_t, use atomic_long_t instead.
> 32-bit machines tend to be memory-limited (i.e. anything that increases
> a reference uses so much memory that you can't actually get to 2**32
> references). 32-bit architectures also tend to have serious problems
> with 64-bit atomics. Hence, atomic_long_t is the more natural solution.
> 
> [...]

Here is the summary with links:
  - [net,v2] packet: Move reference count in packet_sock to atomic_long_t
    https://git.kernel.org/netdev/net/c/db3fadacaf0c

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-12-04 23:20 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-12-01 13:10 [PATCH net v2] packet: Move reference count in packet_sock to atomic_long_t Daniel Borkmann
2023-12-01 15:03 ` Willem de Bruijn
2023-12-01 15:12 ` Eric Dumazet
2023-12-01 23:02 ` Greg Kroah-Hartman
2023-12-04 23:20 ` patchwork-bot+netdevbpf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).