| Message ID | 20231201131021.19999-1-daniel@iogearbox.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | db3fadacaf0c817b222090290d06ca2a338422d0 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [net,v2] packet: Move reference count in packet_sock to atomic_long_t | expand |
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>
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>
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
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!
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;