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]
Date:   Wed, 18 Jan 2023 06:38:32 -1000
From:   Tejun Heo <tj@...nel.org>
To:     David Laight <David.Laight@...lab.com>
Cc:     'Arnd Bergmann' <arnd@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Richard Clark <richard.xnu.clark@...il.com>,
        Jonathan Neuschäfer <j.neuschaefer@....net>,
        Andrey Grodzovsky <andrey.grodzovsky@....com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] workqueue: fix enum type for gcc-13

Hello,

On Wed, Jan 18, 2023 at 09:31:18AM +0000, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 17 January 2023 16:41
> > 
> > In gcc-13, the WORK_STRUCT_WQ_DATA_MASK constant is a signed 64-bit
> > type on 32-bit architectures because the enum definition has both
> > negative numbers and numbers above LONG_MAX in it:
> > 
> ...
> >  	/* convenience constants */
> >  	WORK_STRUCT_FLAG_MASK	= (1UL << WORK_STRUCT_FLAG_BITS) - 1,
> > -	WORK_STRUCT_WQ_DATA_MASK = ~WORK_STRUCT_FLAG_MASK,
> > +	WORK_STRUCT_WQ_DATA_MASK = (unsigned long)~WORK_STRUCT_FLAG_MASK,
> >  	WORK_STRUCT_NO_POOL	= (unsigned long)WORK_OFFQ_POOL_NONE << WORK_OFFQ_POOL_SHIFT,
> 
> How can that make any difference?
> You aren't changing the value or type (which makes no difference)
> of WORK_STRUCT_WQ_DATA_MASK.
> Indeed you require it to have the high bit set.
> 
> So if the enum contains a -1 somewhere gcc-13 will promote
> everything to s64.
> 
> Either declare gcc-13 as 'BROKEN' or change the:

I have a hard time understanding why gcc would change its behavior so that
there's no way to compile the same code in a consistent manner across two
adjacent compiler versions. The new behavior is fine but it makes no sense
to introduce it like this. If at all possible, marking gcc13 broken sounds
about right to me.

Thanks.

-- 
tejun

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ