From: "Boqun Feng" <boqun.feng@gmail.com>
To: "Yuyang Du" <duyuyang@gmail.com>,
"Peter Zijlstra" <peterz@infradead.org>
Cc: "Will Deacon" <will.deacon@arm.com>,
"Ingo Molnar" <mingo@kernel.org>,
"Bart Van Assche" <bvanassche@acm.org>,
ming.lei@redhat.com, "Frederic Weisbecker" <frederic@kernel.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 24/28] locking/lockdep: Remove !dir in lock irq usage check
Date: Fri, 26 Apr 2019 03:25:50 -0400 [thread overview]
Message-ID: <b05c7236-1ce9-4a7e-b2bf-84ec4061b4ed@www.fastmail.com> (raw)
In-Reply-To: <CAHttsrbf30jTT3XidoeWV7j2xovCvJuM3=qy4u1z_GC3dXYp8A@mail.gmail.com>
On Fri, Apr 26, 2019, at 3:06 PM, Yuyang Du wrote:
> Thanks for review.
>
> On Fri, 26 Apr 2019 at 04:03, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Wed, Apr 24, 2019 at 06:19:30PM +0800, Yuyang Du wrote:
> > > In mark_lock_irq(), the following checks are performed:
> > >
> > > ----------------------------------
> > > | -> | unsafe | read unsafe |
> > > |----------------------------------|
> > > | safe | F B | F* B* |
> > > |----------------------------------|
> > > | read safe | F? B* | - |
> > > ----------------------------------
> > >
> > > Where:
> > > F: check_usage_forwards
> > > B: check_usage_backwards
> > > *: check enabled by STRICT_READ_CHECKS
> > > ?: check enabled by the !dir condition
> > >
> > > From checking point of view, the special F? case does not make sense,
> > > whereas it perhaps is made for peroformance concern. As later patch will
> > > address this issue, remove this exception, which makes the checks
> > > consistent later.
> > >
> > > With STRICT_READ_CHECKS = 1 which is default, there is no functional
> > > change.
> >
> > Oh man.. thinking required and it is way late.. anyway this whole read
> > stuff made me remember we had a patch set on readlocks last year.
> >
> > https://lkml.kernel.org/r/20180411135110.9217-1-boqun.feng@gmail.com
> >
> > I remember reviewing that a few times and then it dropped on the floor,
> > probably because Spectre crap or something sucked up all my time again :/
> >
> > Sorry Boqun!
>
That's all right. I was also too busy to send another spin...
> Oh man, I thought about the read-write lock stuff, but I didn't know
> Boqun's patch. Let me hurt my brain looking at that patch.
>
Yuyang, a few about the status, I've changed a little on the algorithm, the
latest code is at
git://git.kernel.org/pub/scm/linux/kernel/git/boqun/linux.git arr-rfc-wip
but unfortunately, I haven't got time to rework the comments and documents, so
be aware of this inconsistency.
Feel free to ask me any question, and I will try to send out a fresh spin in next month.
Regards,
Boqun
next prev parent reply other threads:[~2019-04-26 7:26 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-24 10:19 [PATCH 00/28] Optimize IRQ usage checks and other small bits Yuyang Du
2019-04-24 10:19 ` [PATCH 01/28] locking/lockdep: Change all print_*() return type to void Yuyang Du
2019-04-24 10:19 ` [PATCH 02/28] locking/lockdep: Add description and explanation in lockdep design doc Yuyang Du
2019-04-25 14:01 ` Peter Zijlstra
2019-04-26 5:41 ` Yuyang Du
2019-04-24 10:19 ` [PATCH 03/28] locking/lockdep: Adjust lock usage bit character checks Yuyang Du
2019-04-24 10:19 ` [PATCH 04/28] locking/lockdep: Remove useless conditional macro Yuyang Du
2019-04-24 10:19 ` [PATCH 05/28] locking/lockdep: Print the right depth for chain key colission Yuyang Du
2019-04-24 10:19 ` [PATCH 06/28] locking/lockdep: Update obsolete struct field description Yuyang Du
2019-04-24 10:19 ` [PATCH 07/28] locking/lockdep: Use lockdep_init_task for task initiation consistently Yuyang Du
2019-04-24 10:19 ` [PATCH 08/28] locking/lockdep: Define INITIAL_CHAIN_KEY for chain keys to start with Yuyang Du
2019-04-24 10:19 ` [PATCH 09/28] locking/lockdep: Change the range of class_idx in held_lock struct Yuyang Du
2019-04-24 10:19 ` [PATCH 10/28] locking/lockdep: Remove unused argument in validate_chain() and check_deadlock() Yuyang Du
2019-04-24 10:19 ` [PATCH 11/28] locking/lockdep: Update comment Yuyang Du
2019-04-24 10:19 ` [PATCH 12/28] locking/lockdep: Change type of the element field in circular_queue Yuyang Du
2019-04-24 10:19 ` [PATCH 13/28] locking/lockdep: Change the return type of __cq_dequeue() Yuyang Du
2019-04-24 10:19 ` [PATCH 14/28] locking/lockdep: Avoid constant checks in __bfs by using offset reference Yuyang Du
2019-04-24 10:19 ` [PATCH 15/28] locking/lockdep: Update comments on dependency search Yuyang Du
2019-04-24 10:19 ` [PATCH 16/28] locking/lockdep: Add explanation to lock usage rules in lockdep design doc Yuyang Du
2019-04-24 10:19 ` [PATCH 17/28] locking/lockdep: Remove redundant argument in check_deadlock Yuyang Du
2019-04-24 10:19 ` [PATCH 18/28] locking/lockdep: Remove unused argument in __lock_release Yuyang Du
2019-04-24 10:19 ` [PATCH 19/28] locking/lockdep: Optimize irq usage check when marking lock usage bit Yuyang Du
2019-04-25 19:32 ` Peter Zijlstra
2019-04-26 6:57 ` Yuyang Du
2019-04-30 12:11 ` Peter Zijlstra
2019-05-06 3:05 ` Yuyang Du
2019-05-06 3:42 ` Yuyang Du
2019-05-07 1:47 ` Frederic Weisbecker
2019-05-07 2:21 ` Yuyang Du
2019-04-24 10:19 ` [PATCH 20/28] locking/lockdep: Refactorize check_noncircular and check_redundant Yuyang Du
2019-04-25 19:48 ` Peter Zijlstra
2019-04-26 6:48 ` Yuyang Du
2019-04-24 10:19 ` [PATCH 21/28] locking/lockdep: Consolidate lock usage bit initialization Yuyang Du
2019-04-24 10:19 ` [PATCH 22/28] locking/lockdep: Adjust new bit cases in mark_lock Yuyang Du
2019-04-25 19:52 ` Peter Zijlstra
2019-04-26 6:47 ` Yuyang Du
2019-04-24 10:19 ` [PATCH 23/28] locking/lockdep: Update irqsafe lock bitmaps Yuyang Du
2019-04-25 19:55 ` Peter Zijlstra
2019-04-26 6:45 ` Yuyang Du
2019-04-24 10:19 ` [PATCH 24/28] locking/lockdep: Remove !dir in lock irq usage check Yuyang Du
2019-04-25 20:03 ` Peter Zijlstra
2019-04-26 7:06 ` Yuyang Du
2019-04-26 7:25 ` Boqun Feng [this message]
2019-04-30 15:35 ` Peter Zijlstra
2019-04-24 10:19 ` [PATCH 25/28] locking/lockdep: Implement new IRQ usage checking algorithm Yuyang Du
2019-04-24 10:19 ` [PATCH 26/28] locking/lockdep: Remove __bfs Yuyang Du
2019-04-25 20:06 ` Peter Zijlstra
2019-04-26 6:35 ` Yuyang Du
2019-04-24 10:19 ` [PATCH 27/28] locking/lockdep: Remove locks_before Yuyang Du
2019-04-24 10:19 ` [PATCH 28/28] locking/lockdep: Reduce lock_list_entries by half Yuyang Du
2019-04-25 18:56 ` [PATCH 00/28] Optimize IRQ usage checks and other small bits Peter Zijlstra
2019-04-26 6:59 ` Yuyang Du
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b05c7236-1ce9-4a7e-b2bf-84ec4061b4ed@www.fastmail.com \
--to=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--cc=duyuyang@gmail.com \
--cc=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.