On Tue, Mar 17, 2020 at 12:58 PM Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > On Tue, 17 Mar 2020 at 11:31, Linus Walleij <linus.walleij@xxxxxxxxxx> 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
