linux-kernel - Re: [tip: locking/core] lockdep: Annotate irq

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sun, 22 Mar 2020 13:27:26 +0100
From:   Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:     Frederic Weisbecker <frederic@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        x86 <x86@...nel.org>
Subject: Re: [tip: locking/core] lockdep: Annotate irq_work

On 2020-03-22 03:33:30 [+0100], Frederic Weisbecker wrote:
> > > > @@ -245,6 +245,7 @@ static void nohz_full_kick_func(struct irq_work *work)
> > > >  
> > > >  static DEFINE_PER_CPU(struct irq_work, nohz_full_kick_work) = {
> > > >  	.func = nohz_full_kick_func,
> > > > +	.flags = ATOMIC_INIT(IRQ_WORK_HARD_IRQ),
> > > >  };
> > > 
> > > I get why these need to be in hardirq but some basic explanations for
> > > ordinary mortals as to why those two specifically and not all the others
> > > (and there are many) would have been nice.
> > 
> > Is the documentation patch in this series any good?
> 
> That describes the general rules but it doesn't tell anything about the
> details of this patch. Especially why RCU and nohz_full irq works in particular
> are special here and why it's fine for others to execute in softirq.

Hmm. You need to know the details of the code. RCU is used in hardirq
context, uses (carefully) raw_spinlock_t and so on.
If my memory serves me well in regard to the "nohz kick" part here
NOHZ_FULL needs to observe the CPU if it idle or a task is running. If
this is invoked as part of softirq, which is threaded, then it will
never observe an idle CPU because there is always a task RUNNING with
the softirq doing this callback.

> Thanks.

Sebastian