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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160503015333.GA9987@swordfish>
Date:	Tue, 3 May 2016 10:53:33 +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

Hello Minchan,

On (05/03/16 10:40), Minchan Kim wrote:
> > 
> > ...hm...  inc ->failed_writes?
[..]
> Okay, let's add the knob to the existing sysfs(There is no different
> between sysfs and debugfs with point of userspace once they start to
> use it) because no need to add new code to avoid such mess.
> 
> Any thoughts?

so you don't want to account failed fast-path writes in failed_writes?
it sort of kind of fits, to some extent. re-compression is, basically,
a new write operation -- allocate handle, map the page again, compress,
etc., etc. so in a sense failed fast-path write is _almost_ a failed write,
except that we took extra care of handling it and retried the op inside
of zram, not from bio or fs layer.

	-ss