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] [day] [month] [year] [list]

Message-Id: <C51423EF-8C77-40E3-AD8F-0366EB4096E4@dilger.ca>
Date:	Tue, 14 Aug 2012 20:51:40 -0600
From:	Andreas Dilger <adilger@...ger.ca>
To:	"Theodore Ts'o" <tytso@....edu>
Cc:	Tao Ma <tm@....ma>,
	"linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH V5 00/23] ext4: Add inline data support.

On 2012-08-14, at 9:19, Theodore Ts'o <tytso@....edu> wrote:

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

Actually, NFS can submit lookups for ".." for path linkage IIRC, since we had to implement a patch to fix this for ext4 and Lustre at one time.

> 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).

Agreed, the "." and ".." lookups are already special cases in the lookup code.

Cheers, Andreas

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