[uclibc-ng-devel] Re: [PATCH] setrlimit/getrlimit: fix prlimit64 syscall use for 32-bit CPUs

Hi Waldemar, No, I don't have a test to reproduce memory corruption. In my configuration for ARC CPU this issue prevented the shell start. The sell crashed while polling input (in poll() function). Actually, it was a fault in return from getdtablesize() function (called inside poll function). This function calls getlimit(), but prlimit64 syscall corrupted the stack and overwrote the return address. As a result I got: --- zebu_hs login: root # potentially unexpected fatal signal 11. Path: /bin/busybox CPU: 0 PID: 75 Comm: sh Not tainted 5.16.0 #11 Insn could not be fetched @No matching VMA found ECR: 0x00040000 EFA: 0x00001000 ERET: 0x00001000 STAT: 0x80081a82 [IE U ] BTA: 0x20021360 SP: 0x5fe0baf4 FP: 0x5fe0bb18 BLK: 0x1000 LPS: 0x20037500 LPE: 0x20037508 LPC: 0x00000000 r00: 0x00000400 r01: 0x00000007 r02: 0x00000000 r03: 0x5fe0bae8 r04: 0x01010101 r05: 0x00000020 r06: 0x20077380 r07: 0x01010101 r08: 0x00000105 r09: 0x00000a3b r10: 0x7f1c0300 r11: 0x01000415 r12: 0x2001f1fc r13: 0xffffffff r14: 0xffffffff r15: 0x5fe0bb68 r16: 0x00000001 r17: 0x00000001 r18: 0x5fe0bbc9 r19: 0xffffffff r20: 0x5fe0bb68 r21: 0x5fe0bc24 r22: 0x5fe0bbc8 r23: 0x200722c0 r24: 0x00000400 r25: 0x2000ab68 --- Any test that calls poll() function of can be used to verify this issue on ARC CPU. On other CPUs the consequences of stack corruption may vary. I just have a small test to ensure that getrlimit/setrlimit/prlimit are working as expected and can read/write limits with a patch, but in functionality it is something like ulimit. -Pavel