linux-ext4 - Re: [Ext4 Secure Delete 7/7v4] ext4/jbd2: Secure Delete: Secure delete journal blocks

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:	Mon, 10 Oct 2011 14:00:46 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Allison Henderson <achender@...ux.vnet.ibm.com>
Cc:	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [Ext4 Secure Delete 7/7v4] ext4/jbd2: Secure Delete: Secure
 delete journal blocks

On Fri,  7 Oct 2011 00:11:05 -0700
Allison Henderson <achender@...ux.vnet.ibm.com> wrote:

> +	/*
> +	 * If the journal block was not found in the list,
> +	 * add a new pair to the list
> +	 */
> +	if (!b_pair) {
> +		b_pair = kzalloc(sizeof(struct jbd2_blk_pair), GFP_NOFS);
> +		if (!b_pair) {
> +			spin_unlock(&journal->j_pair_lock);
> +			return -ENOMEM;
> +		}

Here too...  that really needs to be GFP_ATOMIC.

I'm wondering, though...it looks like, over a short period of time, you
will create an unordered linked list containing one entry for every
physical block in the journal.  You'll take a lock and search the whole
list for every block that is committed.  Wouldn't it be better just to
have an array indexed by the journal logical block offset?  Less memory,
faster access...?  Or am I missing something fundamental here?

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html