linux-kernel - Re: [PATCH blktests v3 3/3] nvme: introduce nvmet_target

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 29 Aug 2023 02:11:12 +0000
From:   Shinichiro Kawasaki <shinichiro.kawasaki@....com>
To:     Bart Van Assche <bvanassche@....org>
CC:     Daniel Wagner <dwagner@...e.de>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        Chaitanya Kulkarni <kch@...dia.com>,
        Hannes Reinecke <hare@...e.de>,
        Sagi Grimberg <sagi@...mberg.me>,
        Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: [PATCH blktests v3 3/3] nvme: introduce
 nvmet_target_{setup/cleanup} common code

Thanks Bart, I'm getting more understanding of your view. Still I have an
unclear point.

On Aug 28, 2023 / 11:55, Bart Van Assche wrote:
> On 8/28/23 10:02, Daniel Wagner wrote:
> > I am against adding code just to make ShellCheck happy.
> Hi Daniel,
> 
> That's not what my concern is about. My concern is about keeping
> the blktests source code maintainable and easy to read. My opinion
> is that the ability of bash to pass arguments from caller to callee
> implicitly (a) hurts readability, (b) is error prone and (c) hurts
> maintainability. This is why I think that this feature should not
> be used and hence that disabling SC2119 would be really wrong.
> 
> Regarding (a), I think this long e-mail thread is more than enough
> evidence that it is not clear what the intention is of the
> _nvmet_target_setup calls without arguments - not pass any arguments
> or pass the argument list of the caller.

This is the unclear point for me. Does bash really pass the arguments list of
the caller to the callee when functions are called without arguments?

Looking back the commit 852996fea4f1, you explained that bash does, and I
agreed. But now in my environment bash doesn't. I tried the script below in my
environment, and see nothing printed.

  funcA() { echo "$1" ; }
  funcB() { funcA; }
  funcB foo

Then the arguments of funcB is not passed to funcA. How does it run in your
environment?

Also, I checked bash document [*] and it says:

  "When a function is executed, the arguments to the function become the
  positional parameters during its execution".

It does not clearly state the case there is no argument, but I think this means
that the positional parameters in the function becomes a new, empty array. At
least, the document does not say that the positional parameters of caller is
passed to callee when there is no argument.

[*] https://www.gnu.org/software/bash/manual/html_node/Shell-Functions.html

So I think we can safely assume that bash doesn't pass the argument list of
caller to callee when functions are called without arguments.

> Regarding (c): if any
> _nvmet_target_setup calls would be added in a function that accepts
> arguments, how is _nvmet_target_setup() expected to process arguments
> of which it doesn't know how to interpret these?
> 
> Hence my proposal to change the _nvmet_target_setup calls with no
> arguments into "_nvmet_target_setup --" and also to ignore the double
> hyphen argument inside _nvmet_target_setup().