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] [day] [month] [year] [list]
Message-ID: <568CF422.5040801@lightnvm.io>
Date:	Wed, 6 Jan 2016 12:01:54 +0100
From:	Matias <mb@...htnvm.io>
To:	Wenwei Tao <ww.tao0320@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH] lightnvm: add full block direct to the gc list

On 01/05/2016 10:58 AM, Wenwei Tao wrote:
> You are right, a deadlock might occur if interrupt is not disabled.
>
> We might add the block to prio_list when we find the block is full in
> rrpc_alloc_addr and check whether all the writes are complete in
> rrpc_lun_gc, in this way we may avoid gcb allocation fail and irq
> disable issues.
>
> But this still has a problem. We allocate page from block before
> write, but the bio submission may fail, the bio never get execute and
> rrpc_end_io never get called on this bio, this may lead to a
> situation: a block's pages are all allocated, but not all of them are
> used. So this block is not fully used now, and will not get reclaimed
> for further use.
>
> I think we may need to put the page back when the page is not actually
> used/programmed.
You're right. It has to take multiple cases into account on failure, 
where if a write fails, it might mean the hole block must be written to 
a new block, the I/O it self must be remapped to another address, or 
something else depending on the error code. This logic is yet to be 
routed into rrpc.

Javier is working on write buffering, which will fix some of these issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ