lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31fe5dced5d6423b92914c8c6dae7bc3@EX13D11EUB003.ant.amazon.com>
Date:   Thu, 23 Jul 2020 13:51:06 +0000
From:   "Jubran, Samih" <sameehj@...zon.com>
To:     Lorenzo Bianconi <lorenzo@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
CC:     "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "ast@...nel.org" <ast@...nel.org>,
        "brouer@...hat.com" <brouer@...hat.com>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        "lorenzo.bianconi@...hat.com" <lorenzo.bianconi@...hat.com>,
        "echaudro@...hat.com" <echaudro@...hat.com>,
        "kuba@...nel.org" <kuba@...nel.org>
Subject: RE: [RFC net-next 01/22] xdp: introduce mb in xdp_buff/xdp_frame

> -----Original Message-----
> From: Lorenzo Bianconi <lorenzo@...nel.org>
> Sent: Thursday, July 23, 2020 2:42 PM
> To: netdev@...r.kernel.org
> Cc: bpf@...r.kernel.org; davem@...emloft.net; ast@...nel.org;
> brouer@...hat.com; daniel@...earbox.net; lorenzo.bianconi@...hat.com;
> echaudro@...hat.com; Jubran, Samih <sameehj@...zon.com>;
> kuba@...nel.org
> Subject: [EXTERNAL] [RFC net-next 01/22] xdp: introduce mb in
> xdp_buff/xdp_frame
> 
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
> 
> 
> 
> Introduce multi-buffer bit (mb) in xdp_frame/xdp_buffer to specify if
> shared_info area has been properly initialized for non-linear xdp buffers
> 
> Signed-off-by: Lorenzo Bianconi <lorenzo@...nel.org>
> ---
>  include/net/xdp.h | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/xdp.h b/include/net/xdp.h index
> dbe9c60797e1..2ef6935c5646 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -72,7 +72,8 @@ struct xdp_buff {
>         void *data_hard_start;
>         struct xdp_rxq_info *rxq;
>         struct xdp_txq_info *txq;
> -       u32 frame_sz; /* frame size to deduce data_hard_end/reserved
> tailroom*/
> +       u32 frame_sz:31; /* frame size to deduce data_hard_end/reserved
> tailroom*/
It seems strange that you assign a 32 sized field to a 24 sized field.
Wouldn't it be better if we used the same size in all places?
> +       u32 mb:1; /* xdp non-linear buffer */
>  };
> 
>  /* Reserve memory area at end-of data area.
> @@ -96,7 +97,8 @@ struct xdp_frame {
>         u16 len;
>         u16 headroom;
>         u32 metasize:8;
> -       u32 frame_sz:24;
> +       u32 frame_sz:23;
> +       u32 mb:1; /* xdp non-linear frame */
>         /* Lifetime of xdp_rxq_info is limited to NAPI/enqueue time,
>          * while mem info is valid on remote CPU.
>          */
> @@ -141,6 +143,7 @@ void xdp_convert_frame_to_buff(struct xdp_frame
> *frame, struct xdp_buff *xdp)
>         xdp->data_end = frame->data + frame->len;
>         xdp->data_meta = frame->data - frame->metasize;
>         xdp->frame_sz = frame->frame_sz;
> +       xdp->mb = frame->mb;
>  }
> 
>  static inline
> @@ -167,6 +170,7 @@ int xdp_update_frame_from_buff(struct xdp_buff
> *xdp,
>         xdp_frame->headroom = headroom - sizeof(*xdp_frame);
>         xdp_frame->metasize = metasize;
>         xdp_frame->frame_sz = xdp->frame_sz;
> +       xdp_frame->mb = xdp->mb;
> 
>         return 0;
>  }
> --
> 2.26.2

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ