linux-kernel - Re: [PATCH] cramfs: generate unique inode number for better inode cache usage

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: <20101215173116.15775s4i0bx8j8es@mail.your-server.de>
Date:	Wed, 15 Dec 2010 17:31:16 +0100
From:	stefani@...bold.net
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Pekka Enberg <penberg@...nel.org>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH] cramfs: generate unique inode number for better inode
 cache usage

Zitat von Linus Torvalds <torvalds@...ux-foundation.org>:

> On Wed, Dec 15, 2010 at 12:15 AM, Pekka Enberg <penberg@...nel.org> wrote:
>>
>> I think Linus is after something like this:
>
> That works for me, but I hate the double "switch()" statement checking
> the same thing.
>
> Why is the camino() function not just doing something like
>
>  static unsigned int cramino(struct cramfs_inode *ino, unsigned int
> dirent_offset)
>  {
>      unsigned int data_offset = ino->offset;
>      return data_offset ? data_offset << 2 : dirent_offset+1;
>  }
>
> and we can get rid of all the cruddy CRAMINO_UNIQ() and testing of the
> mode entirely for that path.
>
> That, together with Pekka's approach seems nice, simple and clean.
>
>                             Linus
>

Pekka's approach is not problem. But the "cruddy" CRAMINO_UNIQ() is  
exact what is needed. In your orginal design of cramfs there is no way  
to give entries with no data an unique inode number.

So for not to waste the inode cache and do useless lookups it it  
necessary to distinguish between entries with data and entries with no  
data. The later one need a special handling to create a unique inode  
number depending on the index of the directory entry inside the cramfs  
image.

I try my best to make best out of of the old cramfs design and fix the  
issues of this filesystem.

- Stefani

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