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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <SJ0PR18MB40090035998F6AA20C3058CAB28F9@SJ0PR18MB4009.namprd18.prod.outlook.com>
Date:   Sat, 6 Nov 2021 13:03:28 +0000
From:   "Volodymyr Mytnyk [C]" <vmytnyk@...vell.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Networking <netdev@...r.kernel.org>,
        Taras Chornyi <taras.chornyi@...ision.eu>,
        Mickey Rachamim <mickeyr@...vell.com>,
        Serhiy Pshyk <serhiy.pshyk@...ision.eu>,
        Andrew Lunn <andrew@...n.ch>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Denis Kirjanov <dkirjanov@...e.de>,
        "Taras Chornyi [C]" <tchornyi@...vell.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        "Vadym Kochan [C]" <vkochan@...vell.com>,
        Yevhen Orlov <yevhen.orlov@...ision.eu>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net v3] net: marvell: prestera: fix hw structure laid out

>
> > >
> > > However, there is still this structure that lacks explicit padding:
> > >
> > > struct prestera_msg_acl_match {
> > >         __le32 type;
> > >         /* there is a four-byte hole on most architectures, but not on
> > > x86-32 or m68k */
> >
> > Checked holes on x86_64 with pahole, and there is no holes. Maybe on some
> > other there will be. Will add 4byte member here to make sure. Thx.
> 
> That is very strange, as the union has an __le64 member that should be
> 64-bit aligned on x86_64.

This is what I get on x86_64 with pahole:
---
struct prestera_msg_acl_match {
        __le32                     type;                 /*     0     4 */
        union {
                struct {
                        u8         key;                  /*     4     1 */
                        u8         mask;                 /*     5     1 */
                } u8;                                    /*     4     2 */
                struct {
                        __le16     key;                  /*     4     2 */
                        __le16     mask;                 /*     6     2 */
                } u16;                                   /*     4     4 */
---
seems like the packed is added implicitly here. 

> > >
> > > struct prestera_msg_event_port_param {
> > >         union {
> > >                 struct {
> > >                         __le32 mode;
> > >                         __le32 speed;
> > >                         u8 oper;
> > >                         u8 duplex;
> > >                         u8 fc;
> > >                         u8 fec;
> > >                 } mac;
> > >                 struct {
> > >                         __le64 lmode_bmap;
> > >                         u8 mdix;
> > >                         u8 fc;
> > >                         u8 __pad[2];
> > >                 } __packed phy;
> > >         } __packed;
> > > } __packed;
> > >
> > > There is no need to make the outer aggregates __packed, I would
> > > mark only the innermost ones here: mode, speed and lmode_bmap.
> > > Same for prestera_msg_port_cap_param and prestera_msg_port_param.
> > >
> >
> > Will add __packed only to innermost ones. Looks like only phy is required to have __packed.
> 
> I think you need it on both lmode_bmap and mode/speed
> to get a completely unaligned structure. If you mark phy as __packed,
> that will implicitly mark lmode_bmap as packed but leave the
> four-byte alignment on mode and speed, so the entire structure
> is still four-byte aligned.
> 
>        Arnd

Makes sence. Looks like I've updated the v4 too quickly. Do you want me to update the v5 now with the changes ?

Thanks and Regards,
Volodymyr

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ