Inode numbers on 32 Bit Linux

Inode numbers on 32 Bit Linux

[Amon Ott]

Hi all,

we need to run 32 Bit Linux kernels, but file identification of our RSBAC 
access control system relies on unique inode numbers. Plain Ceph uses inode 
number 1 for all filesystem objects, leading to id problems. To check 
yourself, make a "find" and see that it complains about file system loops 
because of this. ls -i shows number 1 for all items.

I changed the inode number generation as follows to get unique numbers and now 
everything works fine without collisions.

diff --git a/fs/ceph/super.h b/fs/ceph/super.h
index 35dc965..bb73b49 100644
--- a/fs/ceph/super.h
+++ b/fs/ceph/super.h
@@ -344,9 +344,10 @@ static inline struct ceph_vino ceph_vino(struct inode 
*inode)
  * x86_64+ino32  64                     32
  * x86_64        64                     64
  */
-static inline u32 ceph_ino_to_ino32(ino_t ino)
+static inline u32 ceph_ino_to_ino32(__u64 vino)
 {
-       ino ^= ino >> (sizeof(ino) * 8 - 32);
+       u32 ino = vino & 0xffffffff;
+       ino ^= vino >> 32;
        if (!ino)
                ino = 1;
        return ino;
@@ -359,9 +360,10 @@ static inline ino_t ceph_vino_to_ino(struct ceph_vino 
vino)
 {
        ino_t ino = (ino_t)vino.ino;  /* ^ (vino.snap << 20); */
 #if BITS_PER_LONG == 32
-       ino = ceph_ino_to_ino32(ino);
+       return ceph_ino_to_ino32(vino.ino);
+#else
+       return (ino_t)vino.ino;
 #endif
-       return ino;
 }



Amon Ott
-- 
Dr. Amon Ott
m-privacy GmbH           Tel: +49 30 24342334
Am Köllnischen Park 1    Fax: +49 30 24342336
10179 Berlin             http://www.m-privacy.de

Amtsgericht Charlottenburg, HRB 84946

Geschäftsführer:
 Dipl.-Kfm. Holger Maczkowsky,
 Roman Maczkowsky

GnuPG-Key-ID: 0x2DD3A649
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Inode numbers on 32 Bit Linux

[Sage Weil]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2158 bytes --]

Queueing this for 3.2-rc1, thanks!

sage


On Thu, 20 Oct 2011, Amon Ott wrote:

> Hi all,
> 
> we need to run 32 Bit Linux kernels, but file identification of our RSBAC 
> access control system relies on unique inode numbers. Plain Ceph uses inode 
> number 1 for all filesystem objects, leading to id problems. To check 
> yourself, make a "find" and see that it complains about file system loops 
> because of this. ls -i shows number 1 for all items.
> 
> I changed the inode number generation as follows to get unique numbers and now 
> everything works fine without collisions.
> 
> diff --git a/fs/ceph/super.h b/fs/ceph/super.h
> index 35dc965..bb73b49 100644
> --- a/fs/ceph/super.h
> +++ b/fs/ceph/super.h
> @@ -344,9 +344,10 @@ static inline struct ceph_vino ceph_vino(struct inode 
> *inode)
>   * x86_64+ino32  64                     32
>   * x86_64        64                     64
>   */
> -static inline u32 ceph_ino_to_ino32(ino_t ino)
> +static inline u32 ceph_ino_to_ino32(__u64 vino)
>  {
> -       ino ^= ino >> (sizeof(ino) * 8 - 32);
> +       u32 ino = vino & 0xffffffff;
> +       ino ^= vino >> 32;
>         if (!ino)
>                 ino = 1;
>         return ino;
> @@ -359,9 +360,10 @@ static inline ino_t ceph_vino_to_ino(struct ceph_vino 
> vino)
>  {
>         ino_t ino = (ino_t)vino.ino;  /* ^ (vino.snap << 20); */
>  #if BITS_PER_LONG == 32
> -       ino = ceph_ino_to_ino32(ino);
> +       return ceph_ino_to_ino32(vino.ino);
> +#else
> +       return (ino_t)vino.ino;
>  #endif
> -       return ino;
>  }
> 
> 
> 
> Amon Ott
> -- 
> Dr. Amon Ott
> m-privacy GmbH           Tel: +49 30 24342334
> Am Köllnischen Park 1    Fax: +49 30 24342336
> 10179 Berlin             http://www.m-privacy.de
> 
> Amtsgericht Charlottenburg, HRB 84946
> 
> Geschäftsführer:
>  Dipl.-Kfm. Holger Maczkowsky,
>  Roman Maczkowsky
> 
> GnuPG-Key-ID: 0x2DD3A649
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>