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]
Message-ID: <f51b5ea8-a9e7-8bb2-983f-b46b44eb3776@nvidia.com>
Date:   Tue, 22 Aug 2023 17:54:48 +0000
From:   Chaitanya Kulkarni <chaitanyak@...dia.com>
To:     Daniel Wagner <dwagner@...e.de>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
        Chaitanya Kulkarni <chaitanyak@...dia.com>,
        Shin'ichiro Kawasaki <shinichiro.kawasaki@....com>,
        Hannes Reinecke <hare@...e.de>,
        Sagi Grimberg <sagi@...mberg.me>,
        Jason Gunthorpe <jgg@...pe.ca>
Subject: Re: [PATCH blktests v3 0/3] Introduce nvmet target setup/cleanup
 helpers

On 8/22/23 01:38, Daniel Wagner wrote:
> Addressed Sagi's feedback and dropped the explicit --blkdev=device argument from
> the _nvmet_target_setup calls, as it is the default.
>
>
>
> original cover letter:
>
> Introduce helpers to setup nvmet targets. This is spin off from the refactoring
> patches and the allowed_host patches [1].
>
> Sagi suggested to record all resources allocated by nvmet_target_setup and then
> later clean them up in nvmet_target_cleanup. I opted to figure out in
> nvmet_target_cleanup what was allocated via the newly introdcuded _get_nvmet_ports
> helper. The reason being, Hannes told me offline that he would like to add ANA
> tests which will add some more ports to the subsystem. I hope with this
> the code is more future proof.
>
> BTW, while looking at this I saw that the passthru code is using the awkward
> return value port when calling nvmet_passthru_target_setup. It seems some
> more refactoring is in order...
>
> [1] https://lore.kernel.org/linux-nvme/5h333eqhtw252sjw6axjewlb5bbb5ze7awekczxe3kie2lnhw6@manyer42khct/
>
>
> changes
>
> v3:
>   - rebased/retested
>   - use the default with _nvmet_target_setup
>
> v2:
>   - drop local subsys variable in passthru tests
>   - do not use port as handle in passthru tests
>   - free port after unregistering from subsys
>   - https://lore.kernel.org/linux-nvme/20230818141537.22332-1-dwagner@suse.de/
>
> v1:
>   - https://lore.kernel.org/linux-nvme/20230818095744.24619-1-dwagner@suse.de/
>
> Daniel Wagner (3):
>    nvme/{033,034,035,036}: use default subsysnqn variable directly
>    nvme/{033,034,035,036,37}: drop port handle between passthru target
>      setup and cleanup
>    nvme: introduce nvmet_target_{setup/cleanup} common code
>
>

I really appreciate you doing this cleanup, it was long due.

Thanks a lot, for this series :-

Reviewed-by: Chaitanya Kulkarni <kch@...dia.com>

-ck


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ