linux-kernel - Re: [PATCH] lightnvm: pblk: Introduce hot-cold data separation

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]

Date:   Thu, 2 May 2019 10:27:36 +0200
From:   Javier González <javier@...igon.com>
To:     Heiner Litz <hlitz@...c.edu>
Cc:     "Konopko, Igor J" <igor.j.konopko@...el.com>,
        Matias Bjørling <mb@...htnvm.io>,
        Hans Holmberg <hans.holmberg@...xlabs.com>,
        linux-block@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lightnvm: pblk: Introduce hot-cold data separation

> On 1 May 2019, at 22.20, Heiner Litz <hlitz@...c.edu> wrote:
> 
> Javier, Igor,
> you are correct. The problem exists if we have a power loss and we
> have an open gc and an open user line and both contain the same LBA.
> In that case, I think we need to care about the 4 scenarios:
> 
> 1. user_seq_id > gc_seq_id and user_write after gc_write: No issue
> 2. user_seq_id > gc_seq_id and gc_write > user_write: Cannot happen,
> open user lines are not gc'ed
> 3. gc_seq_id > user_seq_id and user_write after gc_write: RACE
> 4. gc_seq_id > user_seq_id and gc_write after user_write: No issue
> 
> To address 3.) we can do the following:
> Whenever a gc line is opened, determine all open user lines and store
> them in a field of pblk_line. When choosing a victim for GC, ignore
> those lines.

What if the following happens:
  - LBA0 is mapped to line 3
  - GC kicks in
  - Open user line 5
  - Open GC line 6
  - Choose line 3 for GC
  - GC LBA0
  - LBA 0 updated and mapped to line 5
  - Power loss

In this case, recovering in order will make that the last mapped LBA is
the one on the GC line. Note that even when the mapping has been
invalidated, scan recovery does not know this and it will just update
the L2P as new lines are being recovered.

I think we need to enforce that no use line is open prior a new open GC
line. This is, when creating a GC line, we wait until the next user line
is to be allocated, and then we assign first the GC line and then the
user line. This can be extended for several open user and GC lines. This
way, the case above (3) cannot occur. In the example above we would
have:

  - LBA0 is mapped to line 3
  - GC kicks in
  - Open GC line 5.        \\ enforced
  - Open user line 6.      \\ enforced
  - Choose line 3 for GC
  - GC LBA0
  - LBA 0 updated and mapped to line 6
  - Power loss

Javier

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)