On Sat, Feb 20, 2021 at 1:51 AM Dmitry V. Levin <ldv@xxxxxxxxxxxx> wrote: > > On sparc, fork and clone syscalls have an unusual semantics of > returning the pid of the parent process to the child process. > > Apparently, the implementation did not honor pid namespaces at all, > so the child used to get the pid of its parent in the init namespace. > > Fortunately, most users of these syscalls are not affected by this bug > because they use another register to distinguish the parent process > from its child, and the pid of the parent process is often discarded. > > Reproducer: tested on my sparc64 ldom: 1. non-patched kernel (kernel 5.11.0-03615-g55f62bc87347), reproducer/test run: $ gcc -Wall -O2 sparc-fork-namespace2.c $ ./a.out current: 72544, parent: 69045, fork returned: 72545 current: 72545, parent: 72544, fork returned: 72544 current: 72544, parent: 69045, fork returned: 72546 current: 1, parent: 0, fork returned: 72544 2. kernel patch applied, test run: $ uname -a Linux ttip 5.11.0-09279-g7c70f3a7488d-dirty #185 SMP Tue Feb 23 00:50:11 MSK 2021 sparc64 GNU/Linux $ ./a.out current: 939, parent: 918, fork returned: 940 current: 940, parent: 939, fork returned: 939 current: 939, parent: 918, fork returned: 941 a.out: wait: 0x9 and console/kernel logs: [ 72.204212] Kernel unaligned access at TPC[4060c8] ret_from_fork+0x1c/0x2c [ 72.204254] Unsupported unaligned load/store trap for kernel at <00000000004060c8>. [ 72.204267] \|/ ____ \|/ [ 72.204267] "@'/ .. \`@" [ 72.204267] /_| \__/ |_\ [ 72.204267] \__U_/ [ 72.204284] a.out(941): Kernel does fpu/atomic unaligned load/store. [#3] [ 72.204298] CPU: 6 PID: 941 Comm: a.out Tainted: G D E 5.11.0-09279-g7c70f3a7488d-dirty #185 [ 72.204315] TSTATE: 0000004411001600 TPC: 00000000004060c8 TNPC: 00000000004060cc Y: 000000cf Tainted: G D E [ 72.204330] TPC: <ret_from_fork+0x1c/0x2c> [ 72.204340] g0: 0000000000000000 g1: ffffffffffffffff g2: 0000000000000006 g3: 0000000000000000 [ 72.204349] g4: fff8000041482700 g5: fff80021a9890000 g6: fff8000041038000 g7: 0308000108000004 [ 72.204359] o0: 0000000000000000 o1: 000000001fffffff o2: fff8000041482780 o3: 0000000000000000 [ 72.204369] o4: 0000000000000001 o5: 0000000000000000 sp: fff800004103b6a1 ret_pc: 00000000004060b0 [ 72.204378] RPC: <ret_from_fork+0x4/0x2c> [ 72.204387] l0: 0308000108000000 l1: 0000000000000002 l2: 0000000000450cf4 l3: 0000000000000000 [ 72.204396] l4: 0000000000000264 l5: 00000100001eb9f0 l6: fff8000045018000 l7: 00000000006c7840 [ 72.204406] i0: 0000000000efcd60 i1: 0000000000450df4 i2: 00000000000003dc i3: 00000000000003dc [ 72.204415] i4: 0000000000eebc78 i5: 0000000000000000 i6: 000007feffa56811 i7: 0000010000000ad8 [ 72.204424] I7: <0x10000000ad8> [ 72.204432] Call Trace: [ 72.204439] Caller[0000010000000ad8]: 0x10000000ad8 [ 72.204446] Instruction DUMP: [ 72.204449] 0aca0072 [ 72.204456] e059a008 [ 72.204461] e25ba8c7 [ 72.204467] <9fc44000> [ 72.204472] d05ba8cf [ 72.204477] 1068006d [ 72.204483] 90102000 [ 72.204488] 0f0011a9 [ 72.204493] 10680004 [ 72.204499] So something is actually wrong with the patch. Thanks.
