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
| ||
|
Date: Tue, 21 Apr 2020 14:02:39 +0100 From: Peter Maydell <peter.maydell@...aro.org> To: Andreas Dilger <adilger@...ger.ca> Cc: Florian Weimer <fw@...eb.enyo.de>, Linus Walleij <linus.walleij@...aro.org>, "Theodore Ts'o" <tytso@....edu>, Ext4 Developers List <linux-ext4@...r.kernel.org>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, Linux API <linux-api@...r.kernel.org>, QEMU Developers <qemu-devel@...gnu.org>, Andy Lutomirski <luto@...nel.org> Subject: Re: [PATCH] fcntl: Add 32bit filesystem mode On Tue, 21 Apr 2020 at 00:51, Andreas Dilger <adilger@...ger.ca> wrote: > Another question I had here is whether the filesystem needs to provide > 32-bit values for other syscalls, such as stat() and statfs()? For > ext4, stat() is not going to return a 64-bit inode number, but other > filesystems might (e.g. Lustre has a mode to do this). Similarly, > should statfs() scale up f_bsize until it can return a 32-bit f_blocks > value? We also had to do this ages ago for Lustre when 32-bit clients > couldn't handle > 16TB filesystems, but that is a single disk today. > > Should that be added into F_SET_FILE_32BIT_FS also? Interesting question. The directory-offset is the thing that's got peoples' attention because it's what has actually been hit in real-world situations, but other syscalls have the same potential problem too. The closest I can think of to a 'general rule' (in terms of what QEMU would like) would be "behave the same way you would for a compat32 syscall if you had one, or how you would behave on an actual 32-bit host". thanks -- PMM
Powered by blists - more mailing lists