On Tue, Mar 17, 2020 at 12:58 PM Peter Maydell peter.maydell@linaro.org wrote:
On Tue, 17 Mar 2020 at 11:31, Linus Walleij linus.walleij@linaro.org wrote:
It was brought to my attention that this bug from 2018 was still unresolved: 32 bit emulators like QEMU were given 64 bit hashes when running 32 bit emulation on 64 bit systems.
The personality(2) system call supports to let processes indicate that they are 32 bit Linux to the kernel. This was suggested by Teo in the original thread, so I just wired it up and it solves the problem.
Thanks for having a look at this. I'm not sure this is what QEMU needs, though. When QEMU runs, it is not a 32-bit process, it's a 64-bit process. Some of the syscalls it makes are on behalf of the guest and would need 32-bit semantics (including this one of wanting 32-bit hash sizes in directory reads). But some syscalls it makes for itself (either directly, or via libraries it's linked against including glibc and glib) -- those would still want the usual 64-bit semantics, I would have thought.
The "personality" thing is a largely unused facility that a process can use to say it has this generic behaviour. In this case we say we have the PER_LINUX32 personality so it will make the process evoke 32bit behaviours inside the kernel when dealing with this process.
Which I (loosely) appreciate that we want to achieve.
Programs that need the 32 bit hash only need to issue the personality(PER_LINUX32) call and things start working.
What in particular does this personality setting affect? My copy of the personality(2) manpage just says:
PER_LINUX32 (since Linux 2.2) [To be documented.]
which isn't very informative.
It's not a POSIX thing (not part of the Single Unix Specification) so as with most Linux things it has some fuzzy semantics defined by the community...
I usually just go to the source.
If you grep the kernel what turns up is a bunch of architecture-specific behaviors on arm64, ia64, mips, parisc, powerpc, s390, sparc. They are very minor.
On x86_64 the semantic effect is none so this would work for any kind of 32bit userspace on x86_64. It would be the first time this flag has any effect at all on x86_64, but arguably a useful one.
I would not be surprised if running say i586 on x86_64 has the same problem, just that noone has reported it yet. But what do I know. If they have the same problem they can use the same solution. Hm QEMU supports emulating i586 or even i386 ... maybe you could test? Or tell me how to test? We might be solving a bigger issue here.
Yours, Linus Walleij