linux-kernel - Re: [PATCH 2/3] fs: inode: Add API to retrieve global next ino using full ino

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: <CAOQ4uxhLVW3ck_xhXbYgY3xYVOHaKGTht_UYZ4Y9NWL7kXZ1rw@mail.gmail.com>
Date:   Fri, 27 Dec 2019 17:32:50 +0200
From:   Amir Goldstein <amir73il@...il.com>
To:     Chris Down <chris@...isdown.name>
Cc:     linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Al Viro <viro@...iv.linux.org.uk>,
        Matthew Wilcox <willy@...radead.org>,
        Jeff Layton <jlayton@...nel.org>,
        Johannes Weiner <hannes@...xchg.org>,
        Tejun Heo <tj@...nel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>, kernel-team@...com
Subject: Re: [PATCH 2/3] fs: inode: Add API to retrieve global next ino using
 full ino_t width

On Fri, Dec 27, 2019 at 4:30 PM Chris Down <chris@...isdown.name> wrote:
>
> We can't just wholesale replace get_next_ino to use ino_t and 64-bit
> atomics because of a few setbacks:
>
> 1. This may break some 32-bit userspace applications on a 64-bit kernel
>    which cannot handle a 64-bit ino_t -- see the comment above
>    get_next_ino;
> 2. Some applications inside the kernel already make use of the ino_t
>    high bits. For example, overlayfs' xino feature uses these to merge
>    inode numbers and fsid indexes to form a new identifier.
>
> As such we need to make using the full width of ino_t an option for
> users without being a requirement.
>
> This will later be used to power inode64 in tmpfs, and can be used
> elsewhere for other filesystems as desired.
>

Unless I am missing something, I think the fact that get_next_ino()
is a global counter was short sighted to begin with or it was never
intended to be used for massive usage fs.

So I think that introducing another global counter to be used
intentionally for massive usage is a mistake.

I think tmpfs should be converted to use a per-sb ino allocator.
When it's per-sb allocator, implementing the option if ino numbers
are 32bit or 64bit per instance won't be a problem.

Thanks,
Amir.