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: <20260127173938.314d922c@pumpkin>
Date: Tue, 27 Jan 2026 17:39:38 +0000
From: David Laight <david.laight.linux@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>, Cristian Ciocaltea
 <cristian.ciocaltea@...labora.com>, Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Sandy Huang <hjc@...k-chips.com>, Heiko
 Stübner <heiko@...ech.de>, Andy Yan
 <andy.yan@...k-chips.com>, Louis Chauvet <louis.chauvet@...tlin.com>,
 Haneen Mohammed <hamohammed.sa@...il.com>, Melissa Wen
 <melissa.srw@...il.com>, Robert Mader <robert.mader@...labora.com>,
 kernel@...labora.com, dri-devel@...ts.freedesktop.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, "Nícolas F. R. A.
 Prado" <nfraprado@...labora.com>, Diederik de Haas
 <diederik@...ow-tech.com>
Subject: Re: [PATCH v5 1/4] uapi: Provide DIV_ROUND_CLOSEST()

On Tue, 27 Jan 2026 16:38:00 +0200
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Tue, Jan 27, 2026 at 03:58:13PM +0200, Jani Nikula wrote:
> > On Tue, 27 Jan 2026, Cristian Ciocaltea <cristian.ciocaltea@...labora.com> wrote:  
> > > Currently DIV_ROUND_CLOSEST() is only available for the kernel via
> > > include/linux/math.h.
> > >
> > > Expose it to userland as well by adding __KERNEL_DIV_ROUND_CLOSEST() as
> > > a common definition in uapi.
> > >
> > > Additionally, ensure it allows building ISO C applications by switching
> > > from the 'typeof' GNU extension to the ISO-friendly __typeof__.  
> > 
> > I am not convinced that it's a good idea to make the implementation of
> > kernel DIV_ROUND_CLOSEST() part of the kernel UAPI, which is what this
> > change effectively does.
> > 
> > I'd at least like to get an ack from Andy Shevchenko first (Cc'd).  
> 
> Thanks for Cc'ing me!
> 
> So, the history of the DIV_ROUND_UP() to appear in UAPI is a response to
> the ethtool change that missed the fact that this was a kernel internal macro.
> Giving a precedent there is no technical issues to add DIV_ROUND_CLOSEST()
> to UAPI as proposed. Main question here is: Does DRM headers in question
> (that are going to use it) really need this?

My 2c...

And is it actually going to 'clean compile' in userspace?
The tests for x < 0 are very likely to generate warnings when x
is unsigned.
It is hard to avoid those in the kernel build, never mind some 'random'
userspace build.

I'd have thought that the only reason for any of the kernel defines 'leaking'
into the uapi headers is that they are used in other uapi headers for
constants that programs need to use.

It isn't as though it isn't hard to write something that will 'do the job'
and in a place where the definition will be found while reading the sources.
Even just 'hiding' the definitions the kernel itself uses in the uapi
headers doesn't really help anyone.

	David




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ