linux-kernel - Re: [RFC PATCH 1/1] Softirq:avoid large sched delay from the pending softirqs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 18 Jul 2020 00:07:35 +0200
From:   Uladzislau Rezki <urezki@...il.com>
To:     qianjun.kernel@...il.com
Cc:     tglx@...utronix.de, peterz@...radead.org, will@...nel.org,
        luto@...nel.org, linux-kernel@...r.kernel.org,
        shaoyafang@...iglobal.com
Subject: Re: [RFC PATCH 1/1] Softirq:avoid large sched delay from the pending
 softirqs

> From: jun qian <qianjun.kernel@...il.com>
> 
> When get the pending softirqs, it need to process all the pending
> softirqs in the while loop. If the processing time of each pending
> softirq is need more than 2 msec in this loop, or one of the softirq
> will running a long time, according to the original code logic, it
> will process all the pending softirqs without wakeuping ksoftirqd,
> which will cause a relatively large scheduling delay on the
> corresponding CPU, which we do not wish to see. The patch will check
> the total time to process pending softirq, if the time exceeds 2 ms
> we need to wakeup the ksofirqd to aviod large sched delay.
> 
> Signed-off-by: jun qian <qianjun.kernel@...il.com>
> ---
>  kernel/softirq.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/softirq.c b/kernel/softirq.c
> index c4201b7f..602d9fa 100644
> --- a/kernel/softirq.c
> +++ b/kernel/softirq.c
> @@ -299,6 +299,9 @@ asmlinkage __visible void __softirq_entry __do_softirq(void)
>  		}
>  		h++;
>  		pending >>= softirq_bit;
> +
> +		if (time_after(jiffies, end) && need_resched())
> +			break;
>  	}
>  
>  	if (__this_cpu_read(ksoftirqd) == current)
> 
I have a small concern about MAX_SOFTIRQ_TIME. The problem is that
an "end" time is based on jiffies/tick update, so it depends on CONFIG_HZ
value of your kernel.

For example if we have CONFIG_HZ=100, msecs_to_jiffies(2) will return 1.
For HZ=100 one jiffie is 10 milliseconds. So we can not rely on it,
because of low resolution.

Maybe it make sense to fix it first in order to be at least aligned with
"2 milliseconds time limit" documentation?

<snip>
 * We restart softirq processing for at most MAX_SOFTIRQ_RESTART times,
 * but break the loop if need_resched() is set or after 2 ms.
<snip>

ktime_get()/ktime_before()...?

--
Vlad Rezki