From: Minchan Kim <minchan@kernel.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: 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 22:33:21 +0900 [thread overview]
Message-ID: <20150908133303.GA2174@bbox> (raw)
In-Reply-To: <20150908095428.GA14220@swordfish>
On Tue, Sep 08, 2015 at 06:54:28PM +0900, Sergey Senozhatsky wrote:
> On (09/08/15 17:16), Minchan Kim wrote:
> > we should help them to *correct* it rather than keeping such weired
> > thing.
>
> A simple quiz
>
> A)
> echo zzz > /sys/block/zram0/comp_algorithm > /dev/null
> echo 1G > /sys/block/zram0/disksize
> -bash: echo: write error: Invalid argument
> echo $?
> 1
>
>
> B)
> echo zzz > /sys/block/zram0/comp_algorithm > /dev/null
> echo 1G > /sys/block/zram0/disksize
> echo $?
> 0
>
>
> which one *DOES* help finding and correcting an error and which one *DOES NOT*?
> a million dolla question.
Wrong quiz.
For the helping finding, user should do this.
echo zzz > /sys/block/zram0/comp_algorithm
echo $?
If he want to not show error message, he should do.
echo zzz > /sys/block/zram/comp_algorithm 2> /dev/null
echo $?
>
> the difference between comp_algorithm store and any other store function - is
> that comp_algorithm_store DOES ABSOLUTELY NOTHING. it does not allocate memory,
> free memory, register or unregister anything, change backends, etc., etc., etc.
> it does none of those. its only purpose is to strcpy() given data. this data
> will be used later by a completely different function as a result of additional
> actions taken by user space.
You are saying implementation of kernel, not interface itself.
Nothing different. It's a interface to say something from the user
to the kenrel. If user passes wrong input, normally, kernel should return
a error and user should check it.
It's a general rule for the programming for several decades.
>
> Returning back to our quiz. I do suspect that the answer is... "B"!
>
>
> So, I still NACK the patch. It introduces a goto label, etc. In fact all
> we need to do is to move zcomp_available_algorithm() up, before we grab
> the ->init_lock. zcomp_available_algorithm() does not depend on anything
> that requires a ->init_lock protection.
>
> Next, the patch lacks a reasoning/motivation in its commit message. What
> we do in fact here is we introduce compression algorithm fallback to a
> previously selected (knowingly supported, which has already passed
> zcomp_available_algorithm()) or the `default_compressor'.
>
> Summarizing, it's something like this:
>
> ---
>
> From: Sergey SENOZHATSKY <sergey.senozhatsky@gmail.com>
> Subject: [PATCH] zram: introduce comp algorithm fallback functionality
>
> When user supplies an unsupported compression algorithm, keep
> a previously selected one (knowingly supported) or the default
> one (in case if compression algorithm hasn't been changed before).
> ---
> drivers/block/zram/zram_drv.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> index 55e09db..255d68b 100644
> --- a/drivers/block/zram/zram_drv.c
> +++ b/drivers/block/zram/zram_drv.c
> @@ -365,6 +365,9 @@ static ssize_t comp_algorithm_store(struct device *dev,
> struct zram *zram = dev_to_zram(dev);
> size_t sz;
>
> + if (!zcomp_available_algorithm(buf))
> + return -EINVAL;
If you ignore tailling space, your change would make a bug.
If you fix it, it looks good to me.
I hope Luis can send it with his SOB and indication of
your credit about checking with avoiding unnecessary locking if you don't mind.
Thanks, Guys!
> +
> down_write(&zram->init_lock);
> if (init_done(zram)) {
> up_write(&zram->init_lock);
> @@ -378,9 +381,6 @@ static ssize_t comp_algorithm_store(struct device *dev,
> if (sz > 0 && zram->compressor[sz - 1] == '\n')
> zram->compressor[sz - 1] = 0x00;
>
> - if (!zcomp_available_algorithm(zram->compressor))
> - len = -EINVAL;
> -
> up_write(&zram->init_lock);
> return len;
> }
> --
> 2.5.1.454.g1616360
>
next prev parent reply other threads:[~2015-09-08 13:32 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
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 [this message]
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=20150908133303.GA2174@bbox \
--to=minchan@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luis.henriques@canonical.com \
--cc=sergey.senozhatsky.work@gmail.com \
--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).