From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Minchan Kim <minchan@kernel.org>,
Luis Henriques <luis.henriques@canonical.com>,
linux-kernel@vger.kernel.org,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCH] zram: don't copy invalid compression algorithms
Date: Tue, 8 Sep 2015 10:58:31 +0900 [thread overview]
Message-ID: <20150908015831.GG6896@swordfish> (raw)
In-Reply-To: <20150908013338.GF6896@swordfish>
On (09/08/15 10:33), Sergey Senozhatsky wrote:
> > I don't understand your concern. To me, this patch makes sense to me.
> > Could you explain your point clearly, again?
>
> OK. suppose someone landed a typo in a 'zram device management' script
>
> echo llzo > /sys/block/zram0/comp_algorithm
> -bash: echo: write error: Invalid argument
>
>
> but the script ignores 'echo: write error'.
> Because we added compression algorithm name check recently.
>
> then the script does
>
> echo 200M > /sys/block/zram0/disksize
> -bash: echo: write error: Invalid argument
>
>
> doing a simple dmesg reveals the problem
>
> [ 7076.657184] zram: Cannot initialise llzo compressing backend
>
> note that zram provides 'llzo' here, which is convenient.
ah, forgot to mention. there is another misleading thing.
suppose the script checks the comp_algorithm() error code.
and it attempts to do somthing like
echo llzo > /sys/block/zram0/comp_algorithm
-bash: echo: write error: Device or resource busy
so user knows that comp_algorithm failed. so now
he/she goes and checks zram
cat /sys/block/zram0/comp_algorithm
[lzo] lz4
and finds out... that [lzo] is supported and selected for usage.
so what't the problem then? so user wrongly assumes now that the
script has provided 'lzo' as input to zram... false!
the existing scheme of things will provide additional hint.
#current implementation
cat /sys/block/zram0/comp_algorithm
lzo lz4
so, none of the supported compression algorithms is selected.
aha, that is obviously lead us to a conclusion that something
wrong was with the input that script provided to zram. correct!
-ss
next prev parent reply other threads:[~2015-09-08 1:57 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-07 20:48 [PATCH] zram: don't copy invalid compression algorithms Luis Henriques
2015-09-07 23:56 ` Sergey Senozhatsky
2015-09-08 1:14 ` Minchan Kim
2015-09-08 1:33 ` Sergey Senozhatsky
2015-09-08 1:58 ` Sergey Senozhatsky [this message]
2015-09-08 4:50 ` Minchan Kim
2015-09-08 5:04 ` Sergey Senozhatsky
2015-09-08 8:16 ` Minchan Kim
2015-09-08 9:54 ` Sergey Senozhatsky
2015-09-08 13:33 ` Minchan Kim
2015-09-08 13:44 ` Sergey Senozhatsky
2015-09-08 14:21 ` Minchan Kim
2015-09-08 15:35 ` Sergey Senozhatsky
2015-09-08 10:08 ` Luis Henriques
2015-09-08 12:20 ` Sergey Senozhatsky
2015-09-08 5:15 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150908015831.GG6896@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luis.henriques@canonical.com \
--cc=minchan@kernel.org \
--cc=sergey.senozhatsky@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).