On Mon, Jan 04, 2021 at 06:47:38PM -0600, Eric W. Biederman wrote: > >> It is defined in the Ubuntu kernel configs I've got lurking: > >> Both 3.8.0-19_generic (Ubuntu 13.04) and 5.4.0-56_generic (probably 20.04). > >> Which is probably why it is in my test builds (I've just cut out > >> a lot of modules). > > Interesting. That sounds like something a gentle prod to the Ubuntu > kernel team might get them to disable. Especially if there are not any > x32 binaries in sight.
What for? > The core dump code is currently tied to what binary you exec. > The code in exec sets mm->binfmt, and the coredump code uses mm->binfmt > to pick the coredump handler. > > An x32 binary will make all kinds of 64bit calls where it doesn't need > the compat handling. And of course x32 binaries run in 64bit mode with > 32bit pointers so looking at the current execution mode doesn't help. > > Further fun compat_binfmt_elf is shared between x32 and ia32, because > except for a few stray places they do exactly the same thing. FWIW, there's a series cleaning that crap up nicely; as a side benefit, it converts both compats on mips (o32 and n32) to regular compat_binfmt_elf.c Yes, the current mainline is bloody awful in that area (PRSTATUS_SIZE and SET_PR_FPVALID are not for weak stomach), but that's really not hard to get into sane shape - -next had that done in last cycle and I'm currently testing (well, building the test kernel) of port of that to 5.11-rc1. I really don't see the point of getting rid of x32 - mips n32 is *not* going away, and that's an exact parallel. PS: if anything, I wonder if we would better off with binfmt_elf{64,32}.o, built from fs/binfmt_elf.c; it's not that hard to do. With arseloads of weirdness going away if we do that...