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  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:   Mon, 6 May 2019 11:05:27 +0800
From:   Yuyang Du <>
To:     Peter Zijlstra <>
Cc:, Ingo Molnar <>,
        Bart Van Assche <>,,
        Frederic Weisbecker <>,,
        LKML <>
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 <> 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?

Powered by blists - more mailing lists