From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"Suzuki K. Poulose" <suzuki.poulose@arm.com>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Ext4 Developers List <linux-ext4@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Florian Weimer <fw@deneb.enyo.de>,
Andy Lutomirski <luto@kernel.org>,
stable <stable@vger.kernel.org>
Subject: Re: [PATCH] ext4: Give 32bit personalities 32bit hashes
Date: Mon, 23 Mar 2020 22:34:31 -0400 [thread overview]
Message-ID: <20200324023431.GD53396@mit.edu> (raw)
In-Reply-To: <CACRpkdYuZgZUznVxt1AHCSJa_GAXy8N0SduE5OrjDnE1s_L7Zg@mail.gmail.com>
On Thu, Mar 19, 2020 at 11:23:33PM +0100, Linus Walleij wrote:
> OK I guess we can at least take this opportunity to add
> some kerneldoc to the include file.
>
> > As a concrete example, should "give me 32-bit semantics
> > via PER_LINUX32" mean "mmap should always return addresses
> > within 4GB" ? That would seem like it would make sense --
>
> Incidentally that thing in particular has its own personality
> flag (personalities are additive, it's a bit schizophrenic)
> so PER_LINUX_32BIT is defined as:
> PER_LINUX_32BIT = 0x0000 | ADDR_LIMIT_32BIT,
> and that is specifically for limiting the address space to
> 32bit.
>
> There is also PER_LINUX32_3GB for a 3GB lowmem
> limit.
>
> Since the personality is kind of additive, if
> we want a flag *specifically* for indicating that we want
> 32bit hashes from the file system, there are bits left so we
> can provide that.
>
> Is this what we want to do? I just think we shouldn't
> decide on that lightly as we will be using up personality
> bug bits, but sometimes you have to use them.
I've been looking at the personality bug bits more detailed, and it
looks... messy. Do we pick a new personality, or do we grab another
unique flag?
Another possibility, which would be messier for qemu, would be use a
flag set via fcntl. That would require qemu from noticing when the
guest is calling open, openat, or openat2, and then inserting a fcntl
system call to set the 32-bit readdir mode. That's cleaner from the
kernel interface complexity perspective, but it's messier for qemu.
- Ted
WARNING: multiple messages have this Message-ID (diff)
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Peter Maydell <peter.maydell@linaro.org>,
"Suzuki K. Poulose" <suzuki.poulose@arm.com>,
Linux API <linux-api@vger.kernel.org>,
QEMU Developers <qemu-devel@nongnu.org>,
stable <stable@vger.kernel.org>,
Florian Weimer <fw@deneb.enyo.de>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Andy Lutomirski <luto@kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: Give 32bit personalities 32bit hashes
Date: Mon, 23 Mar 2020 22:34:31 -0400 [thread overview]
Message-ID: <20200324023431.GD53396@mit.edu> (raw)
In-Reply-To: <CACRpkdYuZgZUznVxt1AHCSJa_GAXy8N0SduE5OrjDnE1s_L7Zg@mail.gmail.com>
On Thu, Mar 19, 2020 at 11:23:33PM +0100, Linus Walleij wrote:
> OK I guess we can at least take this opportunity to add
> some kerneldoc to the include file.
>
> > As a concrete example, should "give me 32-bit semantics
> > via PER_LINUX32" mean "mmap should always return addresses
> > within 4GB" ? That would seem like it would make sense --
>
> Incidentally that thing in particular has its own personality
> flag (personalities are additive, it's a bit schizophrenic)
> so PER_LINUX_32BIT is defined as:
> PER_LINUX_32BIT = 0x0000 | ADDR_LIMIT_32BIT,
> and that is specifically for limiting the address space to
> 32bit.
>
> There is also PER_LINUX32_3GB for a 3GB lowmem
> limit.
>
> Since the personality is kind of additive, if
> we want a flag *specifically* for indicating that we want
> 32bit hashes from the file system, there are bits left so we
> can provide that.
>
> Is this what we want to do? I just think we shouldn't
> decide on that lightly as we will be using up personality
> bug bits, but sometimes you have to use them.
I've been looking at the personality bug bits more detailed, and it
looks... messy. Do we pick a new personality, or do we grab another
unique flag?
Another possibility, which would be messier for qemu, would be use a
flag set via fcntl. That would require qemu from noticing when the
guest is calling open, openat, or openat2, and then inserting a fcntl
system call to set the 32-bit readdir mode. That's cleaner from the
kernel interface complexity perspective, but it's messier for qemu.
- Ted
next prev parent reply other threads:[~2020-03-24 2:34 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-17 11:31 [PATCH] ext4: Give 32bit personalities 32bit hashes Linus Walleij
2020-03-17 11:31 ` Linus Walleij
2020-03-17 11:52 ` Florian Weimer
2020-03-17 11:52 ` Florian Weimer
2020-03-17 12:38 ` Linus Walleij
2020-03-17 12:38 ` Linus Walleij
2020-03-17 11:58 ` Peter Maydell
2020-03-17 11:58 ` Peter Maydell
2020-03-19 15:13 ` Linus Walleij
2020-03-19 15:13 ` Linus Walleij
2020-03-19 15:25 ` Peter Maydell
2020-03-19 15:25 ` Peter Maydell
2020-03-19 22:23 ` Linus Walleij
2020-03-19 22:23 ` Linus Walleij
2020-03-24 2:34 ` Theodore Y. Ts'o [this message]
2020-03-24 2:34 ` Theodore Y. Ts'o
2020-03-24 9:29 ` Peter Maydell
2020-03-24 9:29 ` Peter Maydell
2020-03-24 18:47 ` Theodore Y. Ts'o
2020-03-24 18:47 ` Theodore Y. Ts'o
2020-03-24 21:17 ` Linus Walleij
2020-03-24 21:17 ` Linus Walleij
2020-03-17 22:28 ` Andreas Dilger
2020-03-17 22:28 ` Andreas Dilger
2020-03-19 15:18 ` Linus Walleij
2020-03-19 15:18 ` Linus Walleij
2020-03-17 22:30 ` Sasha Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200324023431.GD53396@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=fw@deneb.enyo.de \
--cc=linus.walleij@linaro.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stable@vger.kernel.org \
--cc=suzuki.poulose@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.