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] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2503291345580.47733@angie.orcam.me.uk>
Date: Sat, 29 Mar 2025 14:02:28 +0000 (GMT)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: "Dmitry V. Levin" <ldv@...ace.io>
cc: Shuah Khan <skhan@...uxfoundation.org>, Shuah Khan <shuah@...nel.org>, 
    Oleg Nesterov <oleg@...hat.com>, strace-devel@...ts.strace.io, 
    linux-kselftest@...r.kernel.org, linux-mips@...r.kernel.org, 
    linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] selftests/ptrace/get_syscall_info: fix for MIPS n32

On Sat, 29 Mar 2025, Dmitry V. Levin wrote:

> > > +#if defined(_MIPS_SIM) && _MIPS_SIM == _MIPS_SIM_NABI32
> > > +/*
> > > + * MIPS N32 is the only architecture where __kernel_ulong_t
> > > + * does not match the bitness of syscall arguments.
> > > + */
> > > +typedef unsigned long long kernel_ulong_t;
> > > +#else
> > > +typedef __kernel_ulong_t kernel_ulong_t;
> > > +#endif
> > > +
> > 
> > What's the reason for adding these typedefs? checkpatch should
> > have warned you about adding new typedefs.
> > 
> > Also this introduces kernel_ulong_t in user-space test code.
> > Something to avoid.
> 
> There has to be a new type for this test, and the natural way to do this
> is to use typedef.  The alternative would be to #define kernel_ulong_t
> which is ugly.  By the way, there are quite a few typedefs in selftests,
> and there seems to be given no rationale why adding new types in selftests
> is a bad idea.

 FWIW I agree, and I fail to see a reason why this would be a problem in a 
standalone test program where the typedef does not propagate anywhere.  

 The only potential issue I can identify would be a namespace clash, so 
perhaps the new type could have a name prefix specific to the test, but it 
doesn't appear to me a widespread practice across our selftests and then
`kernel_' ought to be pretty safe against ISO C or POSIX, so perhaps let's 
leave the things alone?

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ