Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp368004ybi; Sat, 29 Jun 2019 12:47:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqyAKZpEqeWUPZrUO14n6jp/w8Nh+pOGFJFFZujbx7JIeA1u0WfhrsOj0yi2exgrx+esF38w X-Received: by 2002:a63:f510:: with SMTP id w16mr16283216pgh.0.1561837635914; Sat, 29 Jun 2019 12:47:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561837635; cv=none; d=google.com; s=arc-20160816; b=xWVFG2X7opeRYaCsiEd8/FPZzMH+j7j1Jd6nX+/C4AV/xKBz0bjfxy26/T70CHGsW+ euav1UawDIAdGEiJ2pXaIBhLX+nVlYudDACHeN6lgM0KeLIBEFXrBNljAyUcxCHuyWwB QXl5CoMy6ggaM0RB0yrXVkEnC9qfsvJ3KB1kjcNawDtiqaauuChbg92z7EG4ZyesvbCw zsJS9uu8gDyQvMcFEqgfe7XU8uSigCbCsF95ZunLIsZysxijq7IltMlATHScgtXiNLQ3 zifgneQLDCw+t7qDksM0aERqovgqgAO3MV3FvkzwNxsjLCC1MDHVuMv+4EC1P2Wiz/e7 zByg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=IszoZW8+STGKuV7dA8MAhosnAgpfnqXp0bbYacLhTjg=; b=LzwTBT+NVwtB6CtaWYez04CTV8mxUPjoM5sB6nNUFxf1y+mgPNi+VRBXpmTX+YFtpv tZSwJH4pgjwExPHHXMErjOsgRqWdn45cc0tmpXjcyedAvJle6piilcv+8b3rnoqZzJ5q Ph2NTajPU0Q04j6K9Mxh8lUgXrAF3osTnfSJZ3lwr/1AeEmmDk+q9NnuuSGS54FodZIc a7CCAokFltiICyny108CwyFg3SlVeHUZycUjM53xveLh6zXKiFek8bDJuPbKNbZkmdrY HUYCvZGiF6GR1BuVGeaiSn1iRdl5vM0Ok/uh1Eme+E9VXCNK8DQM50fTjkocrCLy8rOH sa4Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v189si5442219pgd.289.2019.06.29.12.46.59; Sat, 29 Jun 2019 12:47:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726957AbfF2TqI (ORCPT + 99 others); Sat, 29 Jun 2019 15:46:08 -0400 Received: from mailout2n.rrzn.uni-hannover.de ([130.75.2.113]:46469 "EHLO mailout2n.rrzn.uni-hannover.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726901AbfF2TqI (ORCPT ); Sat, 29 Jun 2019 15:46:08 -0400 Received: from [192.168.32.100] (p5DCCE4B4.dip0.t-ipconnect.de [93.204.228.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout2n.rrzn.uni-hannover.de (Postfix) with ESMTPSA id 1289F1F453; Sat, 29 Jun 2019 21:46:04 +0200 (CEST) Subject: Re: [PATCH v2] drivers/block/loop: Replace deprecated function in option parsing code To: Chaitanya Kulkarni Cc: "linux-kernel@i4.cs.fau.de" , Jens Axboe , "linux-block@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Christian Ewert References: <20190625175517.31133-1-florian.knauf@stud.uni-hannover.de> From: Florian Knauf Message-ID: Date: Sat, 29 Jun 2019 21:46:03 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------696AF862470C2DEF88101BCF" Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a multi-part message in MIME format. --------------696AF862470C2DEF88101BCF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I have now, on the latest staging master (test log attached, everything green), and also learned a lesson about looking more thoroughly for automated test cases. That's a mea culpa, I suppose. :P Before this I'd only found the Linux Test Project, which (if I'm not mistaken) contains tests that use loopback devices but no tests that specifically test the loopback driver itself. Given the small scope of the change, we then considered it sufficient to test manually that the loop device still worked and that the max_loop parameter was handled correctly. Of course, the blktests way is better. Thanks for taking the time to answer and review. Am 25.06.19 um 21:24 schrieb Chaitanya Kulkarni: > I believe you have tested this patch with loop testcases present in the > :- https://github.com/osandov/blktests/tree/master/tests/loop. > > With that, looks good. > > Reviewed-by: Chaitanya Kulkarni . > > On 06/25/2019 10:55 AM, Florian Knauf wrote: >> This patch removes the deprecated simple_strtol function from the option >> parsing logic in the loopback device driver. Instead kstrtoint is used to >> parse int max_loop, to ensure that input values it cannot represent are >> ignored. >> >> Signed-off-by: Florian Knauf >> Signed-off-by: Christian Ewert >> --- >> Thank you for your feedback. >> >> There's no specific reason to use kstrtol, other than the fact that we >> weren't yet aware that kstrtoint exists. (We're new at this, I'm afraid.) >> >> We've amended the patch to make use of kstrtoint, which is of course much >> more straightforward. >> >> drivers/block/loop.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/block/loop.c b/drivers/block/loop.c >> index 102d79575895..adfaf4ad37d1 100644 >> --- a/drivers/block/loop.c >> +++ b/drivers/block/loop.c >> @@ -2289,7 +2289,7 @@ module_exit(loop_exit); >> #ifndef MODULE >> static int __init max_loop_setup(char *str) >> { >> - max_loop = simple_strtol(str, NULL, 0); >> + kstrtoint(str, 0, &max_loop); >> return 1; >> } >> >> > --------------696AF862470C2DEF88101BCF Content-Type: text/x-log; name="check.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="check.log" loop/001 (scan loop device partitions) runtime 0,401s ... loop/001 (scan loop device partitions) [passed] runtime 0,401s ... 0,269s loop/002 (try various loop device block sizes) runtime 0,142s ... loop/002 (try various loop device block sizes) [passed] runtime 0,142s ... 0,148s loop/003 (time opening and closing an unbound loop device) runtime 0,047s ... loop/003 (time opening and closing an unbound loop device) [passed] runtime 0,047s ... 0,052s loop/004 (combine loop direct I/O mode and a custom block size) runtime 0,382s ... loop/004 (combine loop direct I/O mode and a custom block size) [passed] runtime 0,382s ... 0,383s loop/005 (call LOOP_GET_STATUS{,64} with a NULL arg) runtime 0,024s ... loop/005 (call LOOP_GET_STATUS{,64} with a NULL arg) [passed] runtime 0,024s ... 0,025s loop/006 (change loop backing file while creating/removing another loop device) runtime 31,071s ... loop/006 (change loop backing file while creating/removing another loop device) [passed] runtime 31,071s ... 31,050s loop/007 (update loop device capacity with filesystem) runtime 0,417s ... loop/007 (update loop device capacity with filesystem) [passed] runtime 0,417s ... 0,351s --------------696AF862470C2DEF88101BCF--