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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240126001128.GC1987@fastly.com>
Date: Thu, 25 Jan 2024 16:11:28 -0800
From: Joe Damato <jdamato@...tly.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	chuck.lever@...cle.com, jlayton@...nel.org,
	linux-api@...r.kernel.org, brauner@...nel.org, edumazet@...gle.com,
	davem@...emloft.net, alexander.duyck@...il.com,
	sridhar.samudrala@...el.com, kuba@...nel.org,
	willemdebruijn.kernel@...il.com, weiwan@...gle.com,
	Jonathan Corbet <corbet@....net>,
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	Michael Ellerman <mpe@...erman.id.au>,
	Nathan Lynch <nathanl@...ux.ibm.com>,
	Steve French <stfrench@...rosoft.com>,
	Thomas Zimmermann <tzimmermann@...e.de>,
	Jiri Slaby <jirislaby@...nel.org>,
	Julien Panis <jpanis@...libre.com>, Arnd Bergmann <arnd@...db.de>,
	Andrew Waterman <waterman@...s.berkeley.edu>,
	Thomas Huth <thuth@...hat.com>, Palmer Dabbelt <palmer@...belt.com>,
	"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
	"open list:FILESYSTEMS (VFS and infrastructure)" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH net-next v3 3/3] eventpoll: Add epoll ioctl for
 epoll_params

On Thu, Jan 25, 2024 at 03:21:46PM -0800, Greg Kroah-Hartman wrote:
> On Thu, Jan 25, 2024 at 10:56:59PM +0000, Joe Damato wrote:
> > +struct epoll_params {
> > +	u64 busy_poll_usecs;
> > +	u16 busy_poll_budget;
> > +
> > +	/* for future fields */
> > +	u8 data[118];
> > +} EPOLL_PACKED;
> 
> variables that cross the user/kernel boundry need to be __u64, __u16,
> and __u8 here.

I'll make that change for the next version, thank you.

> And why 118?

I chose this arbitrarily. I figured that a 128 byte struct would support 16
u64s in the event that other fields needed to be added in the future. 118
is what was left after the existing fields. There's almost certainly a
better way to do this - or perhaps it is unnecessary as per your other
message.

I am not sure if leaving extra space in the struct is a recommended
practice for ioctls or not - I thought I noticed some code that did and
some that didn't in the kernel so I err'd on the side of leaving the space
and probably did it in the worst way possible.

Thanks,
Joe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ