* [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).