linux-ext4 - Re: [PATCH V5 00/23] ext4: Add inline data support.

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: <20120814151926.GA19364@thunk.org>
Date:	Tue, 14 Aug 2012 11:19:26 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Tao Ma <tm@....ma>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: [PATCH V5 00/23] ext4: Add inline data support.

On Tue, Aug 14, 2012 at 03:04:47PM +0800, Tao Ma wrote:
> As andreas said in another e-mail, that would make the codes a little
> complex. So in general, in my previous version, I just tried to refactor
> most of the codes so that they can work for both inline inode and dir
> blocks. But if these changes are merged, we have to re-write all of the
> codes that are currently shared, such as ext4_find_entry, empty_dir,
> ext4_add_entry etc.

Well, we may not need to rewrite as much as you think.  For one thing,
as I mentioned, I don't think the VFS passes '.' and '..' lookup
requests down to the file system anyway, and even if it did, you could
just have a function which checks for '.' and '..' and returns the
correct value if necessary.  So I think you wouldn't need to rewrite
all of these functions, since the fundamental layout of the directory
wouldn't be changing.  It's just that we're skipping the '.' and '..'
entries, and the "standard" directory layout would be starting 4 bytes
later (after the '..' inode number).

So it's probably worth taking a look to see how much of an increase in
complexity would actually be involved.

Regards,

					- Ted
--
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