net/xdp/xsk.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
The remap of fill and completion rings was frowned upon as they
control the usage of UMEM which does not support concurrent use.
At the same time this would disallow the remap of this rings
into another process.
A possible use case is that the user wants to transfer the socket/
UMEM ownerwhip to another process (via SYS_pidfd_getfd) and so
would need to also remap this rings.
This will have no impact on current usages and just relaxes the
remap limitation.
Signed-off-by: Nuno Gonçalves <nunog@fr24.com>
---
net/xdp/xsk.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
index 2ac58b282b5eb..2af4ff64b22bd 100644
--- a/net/xdp/xsk.c
+++ b/net/xdp/xsk.c
@@ -1300,10 +1300,11 @@ static int xsk_mmap(struct file *file, struct socket *sock,
{
loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
unsigned long size = vma->vm_end - vma->vm_start;
+ int state = READ_ONCE(xs->state);
struct xdp_sock *xs = xdp_sk(sock->sk);
struct xsk_queue *q = NULL;
- if (READ_ONCE(xs->state) != XSK_READY)
+ if (!(state == XSK_READY || state == XSK_BOUND))
return -EBUSY;
if (offset == XDP_PGOFF_RX_RING) {
@@ -1314,9 +1315,11 @@ static int xsk_mmap(struct file *file, struct socket *sock,
/* Matches the smp_wmb() in XDP_UMEM_REG */
smp_rmb();
if (offset == XDP_UMEM_PGOFF_FILL_RING)
- q = READ_ONCE(xs->fq_tmp);
+ q = READ_ONCE(state == XSK_READY ? xs->fq_tmp :
+ xs->pool->fq);
else if (offset == XDP_UMEM_PGOFF_COMPLETION_RING)
- q = READ_ONCE(xs->cq_tmp);
+ q = READ_ONCE(state == XSK_READY ? xs->cq_tmp :
+ xs->pool->cq);
}
if (!q)
--
2.40.0
Hi Nuno,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Nuno-Gon-alves/xsk-allow-remap-of-fill-and-or-completion-rings/20230320-190022
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link: https://lore.kernel.org/r/20230320105323.187307-1-nunog%40fr24.com
patch subject: [PATCH bpf-next] xsk: allow remap of fill and/or completion rings
config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20230321/202303210446.mO2yxOwo-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/56f6a0c68dd5f4419fd7685cc83ceee2c70f3f2e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Nuno-Gon-alves/xsk-allow-remap-of-fill-and-or-completion-rings/20230320-190022
git checkout 56f6a0c68dd5f4419fd7685cc83ceee2c70f3f2e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash net/xdp/
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303210446.mO2yxOwo-lkp@intel.com/
All errors (new ones prefixed by >>):
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
int state = READ_ONCE(xs->state);
^
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:6: error: initializing 'int' with an expression of incompatible type 'void'
int state = READ_ONCE(xs->state);
^ ~~~~~~~~~~~~~~~~~~~~
>> net/xdp/xsk.c:1318:8: error: cannot take the address of an rvalue of type 'struct xsk_queue *'
q = READ_ONCE(state == XSK_READY ? xs->fq_tmp :
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:50:2: note: expanded from macro 'READ_ONCE'
__READ_ONCE(x); \
^ ~
include/asm-generic/rwonce.h:44:70: note: expanded from macro '__READ_ONCE'
#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
^ ~
net/xdp/xsk.c:1321:8: error: cannot take the address of an rvalue of type 'struct xsk_queue *'
q = READ_ONCE(state == XSK_READY ? xs->cq_tmp :
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:50:2: note: expanded from macro 'READ_ONCE'
__READ_ONCE(x); \
^ ~
include/asm-generic/rwonce.h:44:70: note: expanded from macro '__READ_ONCE'
#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
^ ~
10 errors generated.
vim +/xs +1303 net/xdp/xsk.c
1297
1298 static int xsk_mmap(struct file *file, struct socket *sock,
1299 struct vm_area_struct *vma)
1300 {
1301 loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
1302 unsigned long size = vma->vm_end - vma->vm_start;
> 1303 int state = READ_ONCE(xs->state);
1304 struct xdp_sock *xs = xdp_sk(sock->sk);
1305 struct xsk_queue *q = NULL;
1306
1307 if (!(state == XSK_READY || state == XSK_BOUND))
1308 return -EBUSY;
1309
1310 if (offset == XDP_PGOFF_RX_RING) {
1311 q = READ_ONCE(xs->rx);
1312 } else if (offset == XDP_PGOFF_TX_RING) {
1313 q = READ_ONCE(xs->tx);
1314 } else {
1315 /* Matches the smp_wmb() in XDP_UMEM_REG */
1316 smp_rmb();
1317 if (offset == XDP_UMEM_PGOFF_FILL_RING)
> 1318 q = READ_ONCE(state == XSK_READY ? xs->fq_tmp :
1319 xs->pool->fq);
1320 else if (offset == XDP_UMEM_PGOFF_COMPLETION_RING)
1321 q = READ_ONCE(state == XSK_READY ? xs->cq_tmp :
1322 xs->pool->cq);
1323 }
1324
1325 if (!q)
1326 return -EINVAL;
1327
1328 /* Matches the smp_wmb() in xsk_init_queue */
1329 smp_rmb();
1330 if (size > q->ring_vmalloc_size)
1331 return -EINVAL;
1332
1333 return remap_vmalloc_range(vma, q->ring, 0);
1334 }
1335
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
Hi Nuno,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on bpf-next/master]
url: https://github.com/intel-lab-lkp/linux/commits/Nuno-Gon-alves/xsk-allow-remap-of-fill-and-or-completion-rings/20230320-190022
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
patch link: https://lore.kernel.org/r/20230320105323.187307-1-nunog%40fr24.com
patch subject: [PATCH bpf-next] xsk: allow remap of fill and/or completion rings
config: i386-randconfig-a004 (https://download.01.org/0day-ci/archive/20230321/202303210417.mv8mDIaV-lkp@intel.com/config)
compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/intel-lab-lkp/linux/commit/56f6a0c68dd5f4419fd7685cc83ceee2c70f3f2e
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review Nuno-Gon-alves/xsk-allow-remap-of-fill-and-or-completion-rings/20230320-190022
git checkout 56f6a0c68dd5f4419fd7685cc83ceee2c70f3f2e
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag where applicable
| Reported-by: kernel test robot <lkp@intel.com>
| Link: https://lore.kernel.org/oe-kbuild-all/202303210417.mv8mDIaV-lkp@intel.com/
All errors (new ones prefixed by >>):
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
int state = READ_ONCE(xs->state);
^
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:24: error: use of undeclared identifier 'xs'
>> net/xdp/xsk.c:1303:6: error: initializing 'int' with an expression of incompatible type 'void'
int state = READ_ONCE(xs->state);
^ ~~~~~~~~~~~~~~~~~~~~
>> net/xdp/xsk.c:1318:8: error: cannot take the address of an rvalue of type 'struct xsk_queue *'
q = READ_ONCE(state == XSK_READY ? xs->fq_tmp :
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:50:2: note: expanded from macro 'READ_ONCE'
__READ_ONCE(x); \
^ ~
include/asm-generic/rwonce.h:44:70: note: expanded from macro '__READ_ONCE'
#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
^ ~
net/xdp/xsk.c:1321:8: error: cannot take the address of an rvalue of type 'struct xsk_queue *'
q = READ_ONCE(state == XSK_READY ? xs->cq_tmp :
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/asm-generic/rwonce.h:50:2: note: expanded from macro 'READ_ONCE'
__READ_ONCE(x); \
^ ~
include/asm-generic/rwonce.h:44:70: note: expanded from macro '__READ_ONCE'
#define __READ_ONCE(x) (*(const volatile __unqual_scalar_typeof(x) *)&(x))
^ ~
10 errors generated.
vim +/xs +1303 net/xdp/xsk.c
1297
1298 static int xsk_mmap(struct file *file, struct socket *sock,
1299 struct vm_area_struct *vma)
1300 {
1301 loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
1302 unsigned long size = vma->vm_end - vma->vm_start;
> 1303 int state = READ_ONCE(xs->state);
1304 struct xdp_sock *xs = xdp_sk(sock->sk);
1305 struct xsk_queue *q = NULL;
1306
1307 if (!(state == XSK_READY || state == XSK_BOUND))
1308 return -EBUSY;
1309
1310 if (offset == XDP_PGOFF_RX_RING) {
1311 q = READ_ONCE(xs->rx);
1312 } else if (offset == XDP_PGOFF_TX_RING) {
1313 q = READ_ONCE(xs->tx);
1314 } else {
1315 /* Matches the smp_wmb() in XDP_UMEM_REG */
1316 smp_rmb();
1317 if (offset == XDP_UMEM_PGOFF_FILL_RING)
> 1318 q = READ_ONCE(state == XSK_READY ? xs->fq_tmp :
1319 xs->pool->fq);
1320 else if (offset == XDP_UMEM_PGOFF_COMPLETION_RING)
1321 q = READ_ONCE(state == XSK_READY ? xs->cq_tmp :
1322 xs->pool->cq);
1323 }
1324
1325 if (!q)
1326 return -EINVAL;
1327
1328 /* Matches the smp_wmb() in xsk_init_queue */
1329 smp_rmb();
1330 if (size > q->ring_vmalloc_size)
1331 return -EINVAL;
1332
1333 return remap_vmalloc_range(vma, q->ring, 0);
1334 }
1335
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
On Mon, Mar 20, 2023 at 10:53:23AM +0000, Nuno Gonçalves wrote:
> The remap of fill and completion rings was frowned upon as they
> control the usage of UMEM which does not support concurrent use.
> At the same time this would disallow the remap of this rings
> into another process.
>
> A possible use case is that the user wants to transfer the socket/
> UMEM ownerwhip to another process (via SYS_pidfd_getfd) and so
> would need to also remap this rings.
>
> This will have no impact on current usages and just relaxes the
> remap limitation.
>
> Signed-off-by: Nuno Gonçalves <nunog@fr24.com>
> ---
> net/xdp/xsk.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 2ac58b282b5eb..2af4ff64b22bd 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -1300,10 +1300,11 @@ static int xsk_mmap(struct file *file, struct socket *sock,
> {
> loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
> unsigned long size = vma->vm_end - vma->vm_start;
> + int state = READ_ONCE(xs->state);
> struct xdp_sock *xs = xdp_sk(sock->sk);
> struct xsk_queue *q = NULL;
>
> - if (READ_ONCE(xs->state) != XSK_READY)
> + if (!(state == XSK_READY || state == XSK_BOUND))
This if(..) is actually:
if (state != XSK_READY && state != XSK_BOUND)
Thanks
On Mon, 20 Mar 2023 at 12:09, Leon Romanovsky <leon@kernel.org> wrote:
>
> On Mon, Mar 20, 2023 at 10:53:23AM +0000, Nuno Gonçalves wrote:
> > The remap of fill and completion rings was frowned upon as they
> > control the usage of UMEM which does not support concurrent use.
> > At the same time this would disallow the remap of this rings
> > into another process.
> >
> > A possible use case is that the user wants to transfer the socket/
> > UMEM ownerwhip to another process (via SYS_pidfd_getfd) and so
nit: ownership
> > would need to also remap this rings.
> >
> > This will have no impact on current usages and just relaxes the
> > remap limitation.
> >
> > Signed-off-by: Nuno Gonçalves <nunog@fr24.com>
> > ---
> > net/xdp/xsk.c | 9 ++++++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > index 2ac58b282b5eb..2af4ff64b22bd 100644
> > --- a/net/xdp/xsk.c
> > +++ b/net/xdp/xsk.c
> > @@ -1300,10 +1300,11 @@ static int xsk_mmap(struct file *file, struct socket *sock,
> > {
> > loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
> > unsigned long size = vma->vm_end - vma->vm_start;
> > + int state = READ_ONCE(xs->state);
Reverse Christmas Tree notation here please. Move it one line down to
after the *xs declaration.
> > struct xdp_sock *xs = xdp_sk(sock->sk);
> > struct xsk_queue *q = NULL;
> >
> > - if (READ_ONCE(xs->state) != XSK_READY)
> > + if (!(state == XSK_READY || state == XSK_BOUND))
>
> This if(..) is actually:
> if (state != XSK_READY && state != XSK_BOUND)
Nuno had it like that to start with when he sent the patch privately
to me, but I responded that I prefered the current one. It is easier
to understand if read out aloud IMO. Do not have any strong feelings
either way since the statements are equivalent.
> Thanks
On Mon, Mar 20, 2023 at 01:27:18PM +0100, Magnus Karlsson wrote:
> On Mon, 20 Mar 2023 at 12:09, Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Mon, Mar 20, 2023 at 10:53:23AM +0000, Nuno Gonçalves wrote:
> > > The remap of fill and completion rings was frowned upon as they
> > > control the usage of UMEM which does not support concurrent use.
> > > At the same time this would disallow the remap of this rings
> > > into another process.
> > >
> > > A possible use case is that the user wants to transfer the socket/
> > > UMEM ownerwhip to another process (via SYS_pidfd_getfd) and so
>
> nit: ownership
>
> > > would need to also remap this rings.
> > >
> > > This will have no impact on current usages and just relaxes the
> > > remap limitation.
> > >
> > > Signed-off-by: Nuno Gonçalves <nunog@fr24.com>
> > > ---
> > > net/xdp/xsk.c | 9 ++++++---
> > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > index 2ac58b282b5eb..2af4ff64b22bd 100644
> > > --- a/net/xdp/xsk.c
> > > +++ b/net/xdp/xsk.c
> > > @@ -1300,10 +1300,11 @@ static int xsk_mmap(struct file *file, struct socket *sock,
> > > {
> > > loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
> > > unsigned long size = vma->vm_end - vma->vm_start;
> > > + int state = READ_ONCE(xs->state);
>
> Reverse Christmas Tree notation here please. Move it one line down to
> after the *xs declaration.
>
> > > struct xdp_sock *xs = xdp_sk(sock->sk);
> > > struct xsk_queue *q = NULL;
> > >
> > > - if (READ_ONCE(xs->state) != XSK_READY)
> > > + if (!(state == XSK_READY || state == XSK_BOUND))
> >
> > This if(..) is actually:
> > if (state != XSK_READY && state != XSK_BOUND)
>
> Nuno had it like that to start with when he sent the patch privately
> to me, but I responded that I prefered the current one. It is easier
> to understand if read out aloud IMO.
"Not equal" is much easier to understand than "not" of whole expression.
> Do not have any strong feelings either way since the statements are equivalent.
>
> > Thanks
On Mon, 20 Mar 2023 at 14:41, Leon Romanovsky <leon@kernel.org> wrote:
>
> On Mon, Mar 20, 2023 at 01:27:18PM +0100, Magnus Karlsson wrote:
> > On Mon, 20 Mar 2023 at 12:09, Leon Romanovsky <leon@kernel.org> wrote:
> > >
> > > On Mon, Mar 20, 2023 at 10:53:23AM +0000, Nuno Gonçalves wrote:
> > > > The remap of fill and completion rings was frowned upon as they
> > > > control the usage of UMEM which does not support concurrent use.
> > > > At the same time this would disallow the remap of this rings
> > > > into another process.
> > > >
> > > > A possible use case is that the user wants to transfer the socket/
> > > > UMEM ownerwhip to another process (via SYS_pidfd_getfd) and so
> >
> > nit: ownership
> >
> > > > would need to also remap this rings.
> > > >
> > > > This will have no impact on current usages and just relaxes the
> > > > remap limitation.
> > > >
> > > > Signed-off-by: Nuno Gonçalves <nunog@fr24.com>
> > > > ---
> > > > net/xdp/xsk.c | 9 ++++++---
> > > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > > index 2ac58b282b5eb..2af4ff64b22bd 100644
> > > > --- a/net/xdp/xsk.c
> > > > +++ b/net/xdp/xsk.c
> > > > @@ -1300,10 +1300,11 @@ static int xsk_mmap(struct file *file, struct socket *sock,
> > > > {
> > > > loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
> > > > unsigned long size = vma->vm_end - vma->vm_start;
> > > > + int state = READ_ONCE(xs->state);
> >
> > Reverse Christmas Tree notation here please. Move it one line down to
> > after the *xs declaration.
> >
> > > > struct xdp_sock *xs = xdp_sk(sock->sk);
> > > > struct xsk_queue *q = NULL;
> > > >
> > > > - if (READ_ONCE(xs->state) != XSK_READY)
> > > > + if (!(state == XSK_READY || state == XSK_BOUND))
> > >
> > > This if(..) is actually:
> > > if (state != XSK_READY && state != XSK_BOUND)
> >
> > Nuno had it like that to start with when he sent the patch privately
> > to me, but I responded that I prefered the current one. It is easier
> > to understand if read out aloud IMO.
>
> "Not equal" is much easier to understand than "not" of whole expression.
Then my brain is wired differently ;-).
> > Do not have any strong feelings either way since the statements are equivalent.
> >
> > > Thanks
On Mon, 20 Mar 2023 at 14:45, Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
>
> On Mon, 20 Mar 2023 at 14:41, Leon Romanovsky <leon@kernel.org> wrote:
> >
> > On Mon, Mar 20, 2023 at 01:27:18PM +0100, Magnus Karlsson wrote:
> > > On Mon, 20 Mar 2023 at 12:09, Leon Romanovsky <leon@kernel.org> wrote:
> > > >
> > > > On Mon, Mar 20, 2023 at 10:53:23AM +0000, Nuno Gonçalves wrote:
> > > > > The remap of fill and completion rings was frowned upon as they
> > > > > control the usage of UMEM which does not support concurrent use.
> > > > > At the same time this would disallow the remap of this rings
these rings
> > > > > into another process.
> > > > >
> > > > > A possible use case is that the user wants to transfer the socket/
> > > > > UMEM ownerwhip to another process (via SYS_pidfd_getfd) and so
> > >
> > > nit: ownership
> > >
> > > > > would need to also remap this rings.
these rings
> > > > >
> > > > > This will have no impact on current usages and just relaxes the
> > > > > remap limitation.
> > > > >
> > > > > Signed-off-by: Nuno Gonçalves <nunog@fr24.com>
> > > > > ---
> > > > > net/xdp/xsk.c | 9 ++++++---
> > > > > 1 file changed, 6 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> > > > > index 2ac58b282b5eb..2af4ff64b22bd 100644
> > > > > --- a/net/xdp/xsk.c
> > > > > +++ b/net/xdp/xsk.c
> > > > > @@ -1300,10 +1300,11 @@ static int xsk_mmap(struct file *file, struct socket *sock,
> > > > > {
> > > > > loff_t offset = (loff_t)vma->vm_pgoff << PAGE_SHIFT;
> > > > > unsigned long size = vma->vm_end - vma->vm_start;
> > > > > + int state = READ_ONCE(xs->state);
> > >
> > > Reverse Christmas Tree notation here please. Move it one line down to
> > > after the *xs declaration.
> > >
> > > > > struct xdp_sock *xs = xdp_sk(sock->sk);
> > > > > struct xsk_queue *q = NULL;
> > > > >
> > > > > - if (READ_ONCE(xs->state) != XSK_READY)
> > > > > + if (!(state == XSK_READY || state == XSK_BOUND))
> > > >
> > > > This if(..) is actually:
> > > > if (state != XSK_READY && state != XSK_BOUND)
> > >
> > > Nuno had it like that to start with when he sent the patch privately
> > > to me, but I responded that I prefered the current one. It is easier
> > > to understand if read out aloud IMO.
> >
> > "Not equal" is much easier to understand than "not" of whole expression.
>
> Then my brain is wired differently ;-).
Nuno, please prepare a v2 by fixing the now four things above and
reverting this if-expression to what you had before. It is two against
one, so I yield. After that, it is good to go from my point of view.
Thanks!
> > > Do not have any strong feelings either way since the statements are equivalent.
> > >
> > > > Thanks
© 2016 - 2026 Red Hat, Inc.