Re: [PATCH] zram: don't copy invalid compression algorithms

[Minchan Kim]

On Tue, Sep 08, 2015 at 10:58:31AM +0900, Sergey Senozhatsky wrote:
> 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!

The problem is caused by that user skipped check of whether his
action was successful or not. IOW, script should have chekcked
status of "echo llzo > xxxx". User shouldn't rely on dmesg.

So, I don't think it's good idea to paper over user's mistake.
And it's straightforward/consistent to change the thing's state
only if is successful.

For exmaple, disksize, max_comp_streams are changed only if
it is successful.
If your logic were right approach, we should change
max_comp_streams for *stupid* script although it doesn't check
return value of doing. It doesn't sound to make sense to me.


> 
> 	-ss
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/