linux-kernel - Re: Re: [PATCH,RESEND] softirq: Introduce SOFTIRQ_FORCED

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:   Mon, 23 Aug 2021 09:43:58 +0200
From:   Mike Galbraith <efault@....de>
To:     王擎 <wangqing@...o.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Frederic Weisbecker <frederic@...nel.org>,
        Michal Hocko <mhocko@...nel.org>,
        Davidlohr Bueso <dave@...olabs.net>,
        Will Deacon <will@...nel.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Dirk Behme <dirk.behme@...bosch.com>,
        linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH,RESEND] softirq: Introduce SOFTIRQ_FORCED_THREADING

On Mon, 2021-08-23 at 14:33 +0800, 王擎 wrote:
>
> > On Mon, 2021-08-23 at 11:33 +0800, Wang Qing wrote:
> > > At present, whether the softirq is executed when the interrupt exits
> > > is controlled by IRQ_FORCED_THREADING. This is unreasonable. It should
> > > be split and allowed to take effect separately.
> >
> > Decades long practice suddenly became "unreasonable"?  I think not.  
>
> "unreasonable" may be my misnomer, but it is really necessary to separate
> softirq from IRQ_FORCED_THREADING, which can be effective separately.

Well, no, it's not necessary, but would be damn convenient to you,
which is of course a perfectly fine motivation to post a patch :)

> >
> > Trying to carve out bits and pieces of RT to merge immediately isn't
> > likely to make the ongoing merge effort go anyfaster or smoother.
>
> I am not trying to carve out bits and pieces of RT, but I encountered actual
> problems in my project. For example, in Android, we will not enable
> IRQ_FORCED_THREADING, Android is not a high real-time requirements,
> but in some scenariossome, RT processes cannot be scheduled in time
> and the frame is dropped due to the execution time of softirq is too long,
> also some softirq cannot be executed in time in ksoftirqs, and delays occur,
> such as IO.

That didn't parse well here.  What you seem to be saying is that you
have a hard constraint that can't be meet, yet are unwilling to use an
existing facility to resolve that issue because the kernel you're using
is not _intended_ to support hard realtime... therefore you want this
other facility to enable it to support your hard realtime requirement.

That can't be right, but it doesn't really matter, because...

> Therefore, why not give the user a choice to balance the execution of softirq
> while not enable IRQ_FORCED_THREADING, so as to meet the inconsistent
> scenes and needs

...it's not my call, I just found the language rather odd.  It still
looks to me like you're carving out a slice of RT.

	-Mike