From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752229AbbIHEt6 (ORCPT ); Tue, 8 Sep 2015 00:49:58 -0400 Received: from mail-pa0-f50.google.com ([209.85.220.50]:33643 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751094AbbIHEtz (ORCPT ); Tue, 8 Sep 2015 00:49:55 -0400 Date: Tue, 8 Sep 2015 13:50:35 +0900 From: Minchan Kim To: Sergey Senozhatsky Cc: Luis Henriques , linux-kernel@vger.kernel.org, Sergey Senozhatsky Subject: Re: [PATCH] zram: don't copy invalid compression algorithms Message-ID: <20150908045017.GA30100@bbox> References: <1441658910-10226-1-git-send-email-luis.henriques@canonical.com> <20150907235635.GA6896@swordfish> <20150908011443.GB19776@bbox> <20150908013338.GF6896@swordfish> <20150908015831.GG6896@swordfish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150908015831.GG6896@swordfish> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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