linux-kernel - Re: [PATCH] lightnvm: fix memory leak when submit fails

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAJbgVnW40qrYBdsM6dC5uhDFZJJDc9kwvCWtK24Rg5GWCHpb2g@mail.gmail.com>
Date:   Thu, 21 Jan 2021 11:49:24 -0800
From:   Heiner Litz <hlitz@...c.edu>
To:     Matias Bjørling <mb@...htnvm.io>
Cc:     Jens Axboe <axboe@...nel.dk>, Pan Bian <bianpan2016@....com>,
        linux-block@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lightnvm: fix memory leak when submit fails

there are a couple more, but again I would understand if those are
deemed not important enough to keep it.

device emulation of (non-ZNS) SSD block device
die control: yes endurance groups would help but I am not aware of any
vendor supporting it
finer-grained control: 1000's of open blocks vs. a handful of
concurrently open zones
OOB area: helpful for L2P recovery

On Thu, Jan 21, 2021 at 10:25 AM Matias Bjørling <mb@...htnvm.io> wrote:
>
> On 21/01/2021 17.58, Heiner Litz wrote:
> > I don't think that ZNS supersedes OCSSD. OCSSDs provide much more
> > flexibility and device control and remain valuable for academia. For
> > us, PBLK is the most accurate "SSD Emulator" out there that, as
> > another benefit, enables real-time performance measurements.
> > That being said, I understand that this may not be a good enough
> > reason to keep it around, but I wouldn't mind if it stayed for another
> > while.
>
> The key difference between ZNS SSDs, and OCSSDs is that wear-leveling is
> done on the SSD, whereas it is on the host with OCSSD.
>
> While that is interesting in itself, the bulk of the research that is
> based upon OCSSD, is to control which dies are accessed. As that is
> already compatible with NVMe Endurance Groups/NVM Sets, there is really
> no reason to keep OCSSD around to have that flexibility.
>
> If we take it out of the kernel, it would still be maintained in the
> github repository and available for researchers. Given the few changes
> that have happened over the past year, it should be relatively easy to
> rebase for each kernel release for quite a while.
>
> Best, Matias
>
>
>
> >
> > On Thu, Jan 21, 2021 at 5:57 AM Matias Bjørling <mb@...htnvm.io> wrote:
> >> On 21/01/2021 13.47, Jens Axboe wrote:
> >>> On 1/21/21 12:22 AM, Pan Bian wrote:
> >>>> The allocated page is not released if error occurs in
> >>>> nvm_submit_io_sync_raw(). __free_page() is moved ealier to avoid
> >>>> possible memory leak issue.
> >>> Applied, thanks.
> >>>
> >>> General question for Matias - is lightnvm maintained anymore at all, or
> >>> should we remove it? The project seems dead from my pov, and I don't
> >>> even remember anyone even reviewing fixes from other people.
> >>>
> >> Hi Jens,
> >>
> >> ZNS has superseded OCSSD/lightnvm. As a result, the hardware and
> >> software development around OCSSD have also moved on to ZNS. To my
> >> knowledge, there is not anyone implementing OCSSD1.2/2.0 commercially at
> >> this point, and what has been deployed in production does not utilize
> >> the Linux kernel stack.
> >>
> >> I do not mind continuing to keep an eye on it, but on the other hand, it
> >> has served its purpose. It enabled the "Open-Channel SSD architectures"
> >> of the world to take hold in the market and thereby gained enough
> >> momentum to be standardized in NVMe as ZNS.
> >>
> >> Would you like me to send a PR to remove lightnvm immediately, or should
> >> we mark it as deprecated for a while before pulling it?
> >>
> >> Best, Matias
> >>
> >>
>