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: <1f45be856eae43a5bca0af524f5b02b9@AcuMS.aculab.com>
Date:   Fri, 6 May 2022 08:09:44 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Maxim Mikityanskiy' <maximmi@...dia.com>
CC:     Jakub Kicinski <kuba@...nel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Paolo Abeni <pabeni@...hat.com>,
        Boris Pismenny <borisp@...dia.com>,
        Tariq Toukan <tariqt@...dia.com>,
        "Saeed Mahameed" <saeedm@...dia.com>,
        Gal Pressman <gal@...dia.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] tls: Add opt-in zerocopy mode of sendfile()

From: Maxim Mikityanskiy
> Sent: 05 May 2022 19:28
> 
> On 2022-05-05 16:48, David Laight wrote:
> > From: Maxim Mikityanskiy
> >> Sent: 05 May 2022 13:40
> >>
> >> On 2022-05-04 12:49, David Laight wrote:
> >>>>> If you declare the union on the stack in the callers, and pass by value
> >>>>> - is the compiler not going to be clever enough to still DDRT?
> >>>>
> >>>> Ah, OK, it should do the thing. I thought you wanted me to ditch the
> >>>> union altogether.
> >>>
> >>> Some architectures always pass struct/union by address.
> >>> Which is probably not what you had in mind.
> >>
> >> Do you have any specific architecture in mind? I couldn't find any
> >> information that it happens anywhere, x86_64 ABI [1] (pages 20-21)
> >> aligns with my expectations, and my common sense can't explain why would
> >> some architectures do what you say.
> >>
> >> In C, when the caller passes a struct as a parameter, the callee can
> >> freely modify it. If the compiler silently replaced it with a pointer,
> >> the callee would corrupt the caller's local variable, so such approach
> >> requires the caller to make an extra copy.
> >
> > Yes, that is what happens.
> 
> I did a quick experiment with gcc 9 on m68k and i386, and it doesn't
> confirm what you claim.
> 
> #include <stdint.h>
> #include <stdio.h>
> 
> union test {
>          uint32_t x;
>          uint32_t *y;
> };
> 
> void func1(void *ptr, union test t)
> {
>          if (ptr) {
>                  printf("%p %u\n", ptr, t.x);
>          } else {
>                  printf("%u\n", *t.y);
>          }
> }
> 
> void func2(void *ptr, uint32_t *y)
> {
>          if (ptr) {
>                  printf("%p %u\n", ptr, (uint32_t)y);
>          } else {
>                  printf("%u\n", *y);
>          }
> }
> 
> gcc -S test.c -fno-strict-aliasing -o -
> 
> I believe this minimal example reflects well enough what happens in my
> code. The assembly generated for func1 and func2 are identical. In both
> cases the second parameter is passed on the stack by value, not by pointer.

Hmmm, perhaps it is/was only sparc32 that passed all structures by reference.
godbolt doesn't seem to have a sparc compiler and I don't have a
working sparc system any more.

It is also possible that the calling conventions are slightly
different than the ones I remember using years ago.

Certainly on i386 even 4 byte structures are returned by reference.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ