public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Luis Henriques <luis.henriques@canonical.com>
Cc: Minchan Kim <minchan@kernel.org>,
	Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Subject: Re: [PATCH v2] zram: introduce comp algorithm fallback functionality
Date: Wed, 9 Sep 2015 09:45:18 +0900	[thread overview]
Message-ID: <20150909004518.GA1883@swordfish> (raw)
In-Reply-To: <1441737776-25280-1-git-send-email-luis.henriques@canonical.com>

On (09/08/15 19:42), Luis Henriques wrote:
> 
> Note that previously this operation (i.e. setting an invalid algorithm)
> would result in no algorithm being selected, which means that this
> represents a small change in the default behaviour.
> 

previously it would result in guaranteed to fail
	echo xxx > /sys/block/zram<id>/disksize
and thus in no device, not just "in no algorithm being selected".

comp_algorithm historically wasn't returning anything back to user space
and it always copied in its input (what later would have been used as a
compression algorithm name). yes, "wasn't returning anything back" is not
entirely correct, there was (and still is) a chance to receive -EBUSY, but
that was (and still is) is absolutely equivalent to
	/sys/block/zram<id>/initstate != 0

(well, I never had a clear understanding of why comp_algorithm and other
attrs return -EBUSY instead of simply silently ignoring the input; is it
really an error? there is a initstate attr for that, but I never had enough
reasons to change it either). anyway, believe me or not, that's what my toy
scripts were doing for years (and hopefully it's not because of the fact that
I'm completely unaware of the trivial basics of software development, as we
found out yesterday, but because zram ABI was letting me to do so).

# head -17 create-zram
---
#!/bin/sh

rmmod zram
modprobe zram

if [ -e /sys/block/zram0/initstate ]; then
	initdone=`cat /sys/block/zram0/initstate`
	if [ $initdone = 1 ]; then
		echo "init done"
		exit 1
	fi
fi

echo 8 > /sys/block/zram0/max_comp_streams

echo $1 > /sys/block/zram0/comp_algorithm
cat /sys/block/zram0/comp_algorithm

---

So, "./create-zram LLZZOO 2G" will have different result now.


Other than that

Acked-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>

	-ss

> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
> ---
> Changes since v1:
>  * Moved the algorithm check further up, before mutex lock
>  * Dropped error path refactoring
>  * Updated commit text to explicitly refer to the ABI change
>  (changes suggested by Sergey and Minchan)
> 
> 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 9c01f5bfa33f..1caa8f793e51 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;
> +
>  	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;
>  }
> 

  reply	other threads:[~2015-09-09  0:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-08 18:42 [PATCH v2] zram: introduce comp algorithm fallback functionality Luis Henriques
2015-09-09  0:45 ` Sergey Senozhatsky [this message]
2015-09-10  5:03 ` Minchan Kim
2015-09-10  5:33   ` Sergey Senozhatsky
2015-09-10  5:58     ` Minchan Kim
2015-09-15 23:07   ` Andrew Morton
2015-09-15 23:29     ` Minchan Kim

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=20150909004518.GA1883@swordfish \
    --to=sergey.senozhatsky.work@gmail.com \
    --cc=akpm@linux-foundation.org \
    --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