linux-kernel - Re: [PATCH] locking: type cleanup when accessing fast_read

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]

Date:	Mon, 25 May 2015 07:46:56 +0200
From:	Nicholas Mc Guire <der.herr@...r.at>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>,
	Nicholas Mc Guire <hofrat@...dl.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] locking: type cleanup when accessing fast_read_ctr

On Sun, 24 May 2015, Oleg Nesterov wrote:

> On 05/23, Nicholas Mc Guire wrote:
> >
> > On Wed, 20 May 2015, Oleg Nesterov wrote:
> >
> > > On 05/19, Nicholas Mc Guire wrote:
> > > >
> > > > I assumed it would not matter but did not see a simple way of getting it
> > > > type clean with unsigned either mainly due to the atomic_t being int and
> > > > val in update_fast_ctr() being passed as -1.
> > >
> > > Perhaps clear_fast_ctr() should have a comment to explain why it returns
> > > "int"... even if "unsigned" should work too.
> > >
> > Might not be into c99 standard far enough but from reviewing 6.5/J.2
> > I do not see this argument here.
> >
> > The "well defined modulo 2**n" behavior for unsigned int can be
> > found stated in a few places - but not in the c99 standard for
> > arithmetic overflow.
> >
> > The "well defined overflow behavior" as far as I understand c99,
> > *only* applies to left shift operations when overflowing - see 6.5.7 "
> > Bitwise shift operators" -> Semantics -> 4) -  further for the counter
> > problem this well defined behavior is of little help as the sum would
> > be wrong in both cases.
> >
> > I still do not see the point in the implicit/automatic type conversion
> > here and why that should be an advantage - could somone point me to
> > the right c99 clauses ?
> 
> Sorry, I don't really understand your question...
>
> Once again. Signed overflow is undefined behaviour according to C standard.
> That is why ->fast_read_ctr is "unsigned long", this counter can actually
> over/underflow if down/up happens on different CPU's.

that signed overflow is undefind is clear - just that unsigned overflow is
well defined is not clear - simply did not find this defined behavior for
unsigned int/long in c99 except for the bitshift operators. So my question
simply was where is the behavior on arithmetic overflow defined ? 

> 
> clear_fast_ctr() returns "signed int" just because this looks better to me,
> it can actually return the negative number. If you make it return "unsigned"
> you will simply shift this implicit/automatic type conversion to atomic_add()
> which accepts "int i".

yup - that is clear - which is one of the reasons why the conversion was 
towards int.

> 
> Let me also quote Linus:
> 
> 	Now, I doubt you'll find an architecture or C compiler where this will
> 	actually ever make a difference,
> 
> Yes. So this all is actually cosmetic.
>
If there is no simple way of getting it out - and there are sound reasons 
to do it this way then I'll just mark it as false positive. 
The intent of the patch was just to cleanup type conversions that did not 
really look necessary and simplify automatic code checking.

thanks for the clarification !

thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/