linux-kernel - Re: [PATCH 19/28] locking/lockdep: Optimize irq usage check when marking lock usage bit

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]

Message-ID: <CAHttsrYfCdpNwQ81ppFQ9b_57tuLYOb=xi=CbRBysnB+LgjGGg@mail.gmail.com>
Date:   Mon, 6 May 2019 11:05:27 +0800
From:   Yuyang Du <duyuyang@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     will.deacon@....com, Ingo Molnar <mingo@...nel.org>,
        Bart Van Assche <bvanassche@....org>, ming.lei@...hat.com,
        Frederic Weisbecker <frederic@...nel.org>, tglx@...utronix.de,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 19/28] locking/lockdep: Optimize irq usage check when
 marking lock usage bit

On Tue, 30 Apr 2019 at 20:12, Peter Zijlstra <peterz@...radead.org> wrote:
> > > IOW he's going to massively explode this storage.
> >
> > If I understand correctly, he is not going to.
> >
> > First of all, we can divide the whole usage thing into tracking and checking.
> >
> > Frederic's fine-grained soft vector state is applied to usage
> > tracking, i.e., which specific vectors a lock is used or enabled.
> >
> > But for usage checking, which vectors are does not really matter. So,
> > the current size of the arrays and bitmaps are good enough. Right?
>
> Frederic? My understanding was that he really was going to split the
> whole thing. The moment you allow masking individual soft vectors, you
> get per-vector dependency chains.

It seems so. What I understand is: for IRQ usage, the difference is:

Each lock has a new usage mask:

        softirq10, ..., softirq1, hardirq

where softirq1 | softirq2 | ... | softirq10 = softirq

where softirq, exactly what was, virtually is used in the checking.
This is mainly because, any irq vector has any usage, the lock has
that usage, be it hard or soft.

If that is right, hardirq can be split too (why not if softirq does
:)). So, maybe a bitmap to do them all for tracking, and optionally
maintain aggregate softirq and hardirq for checking as before.
Regardless, may irq-safe reachability thing is not affected.

And for the chain, which is mainly for caching does not really matter
split or not (either way, the outcome will be the same?), because
there will be a hash for a chain anyway, which is the same. Right?