linux-kernel - Re: [PATCH] sched/deadline: Use bools for the state flags

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: <nycvar.YFH.7.76.1711211234090.11505@cbobk.fhfr.pm>
Date:   Tue, 21 Nov 2017 12:43:53 +0100 (CET)
From:   Jiri Kosina <jikos@...nel.org>
To:     Thomas Gleixner <tglx@...utronix.de>
cc:     luca abeni <luca.abeni@...tannapisa.it>,
        Peter Zijlstra <peterz@...radead.org>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        Juri Lelli <juri.lelli@....com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Mike Galbraith <efault@....de>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/deadline: Use bools for the state flags

On Tue, 21 Nov 2017, Thomas Gleixner wrote:

> > Commit
> > 
> > 	799ba82de01e ("sched/deadline: Use C bitfields for the state flags")
> > 
> > converted state flags into one-bit signed int. Signed one-bit type can be 
> > either 0 or -1, which is going to cause a problem once 1 is assigned to it 
> > and then the value later tested against 1.
> > 
> > The current code is okay, as all the checks are (non-)zero check, but I 
> > believe that we'd rather be safe than sorry here; remove the fragility by 
> > converting the state flags to bool.
> > 
> > This also silences annoying sparse complaints about this very issue when 
> > compiling any code that includes sched.h.
> 
> What's wrong with making these bitfields 'unsigned int' ?

Surely that works as well. I chose bool as that's in line with the actual 
semantics, but I can of course resend with unsigned type if that's 
preferred for one reason or another.

Thanks,

-- 
Jiri Kosina
SUSE Labs