linux-kernel - Re: [PATCH 2/2] zram: user per-cpu compression 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] [day] [month] [year] [list]

Message-ID: <20160503070108.GE25545@swordfish>
Date:	Tue, 3 May 2016 16:01:08 +0900
From:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To:	Minchan Kim <minchan@...nel.org>
Cc:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] zram: user per-cpu compression streams

On (05/03/16 15:19), Minchan Kim wrote:
> > > > cat /sys/xxx/max_comp_stream returns num_online_cpus.
> > > 
> > > One more thing,
> > > 
> > > User:
> > > echo 4 > /sys/xxx/max_comp_stream"
> > > cat /sys/xxx/max_comp_streams
> > > 8
> > 
> > sure, it can also be
> > 
> > cat /sys/xxx/max_comp_streams
> > 5
> > cat /sys/xxx/max_comp_streams
> > 6
> > cat /sys/xxx/max_comp_streams
> > 7
> > cat /sys/xxx/max_comp_streams
> > 3
> > 
> > depending on the availability of CPUs. but why would user space
> > constantly check max_comp_streams?
> > 
> > > which is rather weird?
> > > 
> > > We should keep user's value and return it to user although it's techically
> > > lying. IMO, it would be best way to prevent confusing for user until we
> > > removes max_comp_streams finally.
> > 
> > well, I preferred to show the actual state of the device. besides,
> > does anyone really do
> > 
> > 	write buffer to file
> > 	if (success)
> > 		read from file and compare with the buffer
> > 
> > ?
> > 
> 
> Okay, I want to go with your approach!

thanks. I mean that was my thinking when I decided to change the
max_comp_streams output. but no pressure, it does change the numbers
that user space will see. don't have any strong opinion, can keep it
as zcomp cleanup only -- w/o touching the _show()/_store() parts.

> Could you update zram.txt to reflect it?

will do later today. I think I'd prefer to keep it as independent
patch, since it does change the user visible behaviour after all (no
idea if it's true tho; can't easily think why would anyone keep track
of the values returned by cat /sys/xxx/max_comp_streams), so we can
revert it w/o reverting the per-cpu streams IF anyone/anything will
get upset with the change.

	-ss