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: <alpine.LFD.2.00.1003170720060.5960@localhost>
Date:	Wed, 17 Mar 2010 07:22:28 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...shcourse.ca>
To:	Roland Dreier <rdreier@...co.com>
cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: kfifo:  possible weird violation of what should be invariant

On Tue, 16 Mar 2010, Roland Dreier wrote:

>  >   sure, the code seems to work, but allowing the internal values of a
>  > kfifo to contain invalid values on a regular basis would seem to make
>  > a mess of, say, tracing or debugging.  making sure that offset values
>  > actually lie within their valid range would seem to be one of those
>  > ASSERT() things that should always be true, should it not?  is there a
>  > reason the design is like this?
>
> Actually I believe having the values be free-running without
> clamping them makes the code much simpler -- the reason being that
> you preserve the invariant of "in" always being ahead of "out".  If
> you reduce the pointers modulo the size, then you end up having a
> lot of code that has two cases: one to handle "in > out", and one to
> handle "in < out because in has wrapped and out hasn't yet".

  yes, i see your point.  so, as i read it, the internal kfifo "in"
and "out" pointers are *never* actually normalized modulo the buffer
size, which means that, at any time, you can easily check how much
*total* data has gone through the kfifo.  potentially useful.  perhaps
there should be a comment or note to that effect stuffed in there
somewhere as some kernel programmers might find that handy, who knows?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ