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: <20160503061823.GA6062@blaptop>
Date:	Tue, 3 May 2016 15:19:14 +0900
From:	Minchan Kim <minchan@...nel.org>
To:	Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:	Minchan Kim <minchan@...nel.org>,
	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 Tue, May 03, 2016 at 02:57:15PM +0900, Sergey Senozhatsky wrote:
> On (05/03/16 14:40), Minchan Kim wrote:
> [..]
> > > At least, we need sanity check code, still?
> > > Otherwise, user can echo "garbage" > /sys/xxx/max_comp_stream" and then
> > > 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!
Could you update zram.txt to reflect it?

Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ