linux-kernel - Re: [PATCH] zram: export the number of available comp streams

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: <20160127003456.GA1612@swordfish>
Date:	Wed, 27 Jan 2016 09:34:56 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Minchan Kim <minchan@...nel.org>, linux-kernel@...r.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Subject: Re: [PATCH] zram: export the number of available comp streams

On (01/26/16 13:13), Andrew Morton wrote:
[..]
> > +`avail_streams' column shows the current number of available compression
> > +streams, which is not necessarily equal to the number of max compression
> > +streams. The number of max compression streams can be set too high and be
> > +unreachable (depending on the load and the usage pattern, of course).
> > +`avail_streams' let to find out the real 'level of concurrency' that
> > +a particular zram device saw and to calculate the real memory consumption
> > +by allocated compression streams, not the theoretical maximum value.
> >
> 
> "number of max compression streams" doesn't make a lot of sense.  It
> should be "max number of compression streams", yes"

Thank you! much better this way.

[..]
> > +static int zcomp_strm_multi_num_avail_streams(struct zcomp *comp)
> > +{
> > +	int avail;
> > +	struct zcomp_strm_multi *zs = comp->stream;
> > +
> > +	spin_lock(&zs->strm_lock);
> > +	avail = zs->avail_strm;
> > +	spin_unlock(&zs->strm_lock);
> > +
> > +	return avail;
> > +}
> 
> The spin_lock() doesn't do anything very useful here - we're simply
> reading an `int' and it could be omitted.  I guess it's OK for
> documentary reasons (and perhaps for the memory barrier).

yes, agree, that was exactly my thinking. it's fine to have it here
for barrier, but at the same it can be scratched and replaced with
a "yes, this is racy. don't send a patch. `avail_streams' is not so
important" comment.

let's hear from Minchan, if he hates it then I'll just send a v2.

	-ss