[PATCH] um: Fetch registers only for signals which need them

Anton Ivanov anton.ivanov at cambridgegreys.com
Tue Nov 10 06:46:54 EST 2020


On 10/11/2020 11:27, Johannes Berg wrote:
> On Tue, 2020-11-10 at 11:11 +0000, anton.ivanov at cambridgegreys.com
> wrote:
>> From: Anton Ivanov <anton.ivanov at cambridgegreys.com>
>>
>> UML userspace fetches siginfo and passes it to signal handlers
>> in UML. This is needed only for some of the signals, because
>> key handlers like SIGIO make no use of this variable.
> 
> It looks like even for SIGSEGV it depends on PTRACE_FULL_FAULTINFO,
> which is only set for 64-bit?
> 
> 
>> -			ptrace(PTRACE_GETSIGINFO, pid, 0, (struct siginfo *)&si);
>> +			switch (sig) {
>> +			case SIGSEGV:
>> +			case SIGTRAP:
>> +			case SIGILL:
>> +			case SIGBUS:
>> +			case SIGFPE:
>> +			case SIGWINCH:
>> +				ptrace(PTRACE_GETSIGINFO, pid, 0, (struct siginfo *)&si);
>> +				break;
>> +			}
>>   
>>   			switch (sig) {
>>   			case SIGSEGV:
> 
> So perhaps it might make sense to push it further down into that switch?
> It'd end up duplicating it to three places though.
> 
> In the SIGIO case you could write it as

This is predominantly to save some CPU cycles for SIGALRM and SIGIO. The 
other ones are not invoked that often.

The difference when doing

time find /usr -type f -exec cat {} > /dev/null \;

is ~ 1.5%, there is a similar gain in networking on iperf.

> 
> case SIGILL:
> case SIGBUS:
> case SIGFPE:
> case SIGWINCH:
> 	ptrace(...);
> 	fallthrough;
> case SIGIO:
> 	block_signals_trace();
> 	// etc
> 
> But I have no strong opinion either way really.
> 
> 
> I do think a comment is needed though, because we _do_ pass the pointer
> to the sigio handler ... or maybe separate that out just like
> handle_trap() etc.?


Ack.

> 
> johannes
> 
> 
> _______________________________________________
> linux-um mailing list
> linux-um at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-um
> 


-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/



More information about the linux-um mailing list