Re: [Qemu-devel] [BUG] Inappropriate size of target_sigset_t

[Laurent Vivier]

Le 03/07/2019 à 21:46, Aleksandar Markovic a écrit :
> Hello, Peter, Laurent,
> 
> While working on another problem yesterday, I think I discovered a 
> long-standing bug in QEMU Linux user mode: our target_sigset_t structure is 
> eight times smaller as it should be!
> 
> In this code segment from syscalls_def.h:
> 
> #ifdef TARGET_MIPS
> #define TARGET_NSIG      128
> #else
> #define TARGET_NSIG      64
> #endif
> #define TARGET_NSIG_BPW          TARGET_ABI_BITS
> #define TARGET_NSIG_WORDS  (TARGET_NSIG / TARGET_NSIG_BPW)
> 
> typedef struct {
>     abi_ulong sig[TARGET_NSIG_WORDS];
> } target_sigset_t;
> 
> ... TARGET_ABI_BITS should be replaced by eight times smaller constant (in 
> fact, semantically, we need TARGET_ABI_BYTES, but it is not defined) (what is 
> needed is actually "a byte per signal" in target_sigset_t, and we allow "a 
> bit per signal").

TARGET_NSIG is divided by TARGET_ABI_BITS which gives you the number of
abi_ulong words we need in target_sigset_t.

> All this probably sounds to you like something impossible, since this code is 
> in QEMU "since forever", but I checked everything, and the bug seems real. I 
> wish you can prove me wrong.
> 
> I just wanted to let you know about this, given the sensitive timing of 
> current softfreeze, and the fact that I won't be able to do more 
> investigation on this in coming weeks, since I am busy with other tasks, but 
> perhaps you can analyze and do something which you consider appropriate.

If I compare with kernel, it looks good:

In Linux:

  arch/mips/include/uapi/asm/signal.h

  #define _NSIG           128
  #define _NSIG_BPW       (sizeof(unsigned long) * 8)
  #define _NSIG_WORDS     (_NSIG / _NSIG_BPW)

  typedef struct {
          unsigned long sig[_NSIG_WORDS];
  } sigset_t;

_NSIG_BPW is 8 * 8 = 64 on MIPS64 or 4 * 8 = 32 on MIPS

In QEMU:

TARGET_NSIG_BPW is TARGET_ABI_BITS which is  TARGET_LONG_BITS which is
64 on MIPS64 and 32 on MIPS.

I think there is no problem.

Thanks,
Laurent