ernel.org;
> linux...@kvack.org; iamjoonsoo@lge.com; a...@linux-foundation.org;
> wi...@infradead.org; npig...@gmail.com; kernel-t...@lge.com
> Subject: Re: [PATCH v6 05/15] lockdep: Implement crossrelease feature
>
> On Fri, May 19, 2017 at 05:07:08PM +0900, Byungchul Park wrote:
>
ernel.org;
> linux...@kvack.org; iamjoonsoo@lge.com; a...@linux-foundation.org;
> wi...@infradead.org; npig...@gmail.com; kernel-t...@lge.com
> Subject: Re: [PATCH v6 05/15] lockdep: Implement crossrelease feature
>
> On Fri, May 19, 2017 at 05:07:08PM +0900, Byungchul Park wrote:
>
On Fri, May 19, 2017 at 05:07:08PM +0900, Byungchul Park wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > Lockdep is a runtime locking correctness validator that detects and
> > reports a deadlock or its possibility by checking dependencies between
> > locks. It's
On Fri, May 19, 2017 at 05:07:08PM +0900, Byungchul Park wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > Lockdep is a runtime locking correctness validator that detects and
> > reports a deadlock or its possibility by checking dependencies between
> > locks. It's
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> Lockdep is a runtime locking correctness validator that detects and
> reports a deadlock or its possibility by checking dependencies between
> locks. It's useful since it does not report just an actual deadlock but
> also the
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> Lockdep is a runtime locking correctness validator that detects and
> reports a deadlock or its possibility by checking dependencies between
> locks. It's useful since it does not report just an actual deadlock but
> also the
On Tue, May 16, 2017 at 04:18:46PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 25, 2017 at 02:40:44PM +0900, Byungchul Park wrote:
> > On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote:
>
> > > My complaint is mostly about naming.. and "hist_gen_id" might be a
> > > better name.
> >
On Tue, May 16, 2017 at 04:18:46PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 25, 2017 at 02:40:44PM +0900, Byungchul Park wrote:
> > On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote:
>
> > > My complaint is mostly about naming.. and "hist_gen_id" might be a
> > > better name.
> >
On Tue, Apr 25, 2017 at 02:40:44PM +0900, Byungchul Park wrote:
> On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote:
> > My complaint is mostly about naming.. and "hist_gen_id" might be a
> > better name.
>
> Ah, I also think the name, 'work_id', is not good... and frankly I am
>
On Tue, Apr 25, 2017 at 02:40:44PM +0900, Byungchul Park wrote:
> On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote:
> > My complaint is mostly about naming.. and "hist_gen_id" might be a
> > better name.
>
> Ah, I also think the name, 'work_id', is not good... and frankly I am
>
On Mon, Apr 24, 2017 at 11:30:51AM +0200, Peter Zijlstra wrote:
> +static void add_xhlock(struct held_lock *hlock)
> +{
> + unsigned int idx = current->xhlock_idx++;
> + struct hist_lock *xhlock = (idx);
>
> Yes, I misread that. Then '0' has the oldest entry, which is slightly
>
On Mon, Apr 24, 2017 at 11:30:51AM +0200, Peter Zijlstra wrote:
> +static void add_xhlock(struct held_lock *hlock)
> +{
> + unsigned int idx = current->xhlock_idx++;
> + struct hist_lock *xhlock = (idx);
>
> Yes, I misread that. Then '0' has the oldest entry, which is slightly
>
On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 24, 2017 at 02:11:02PM +0900, Byungchul Park wrote:
> > On Wed, Apr 19, 2017 at 04:25:03PM +0200, Peter Zijlstra wrote:
>
> > > I still don't like work_id; it doesn't have anything to do with
> > > workqueues per se,
On Mon, Apr 24, 2017 at 12:17:47PM +0200, Peter Zijlstra wrote:
> On Mon, Apr 24, 2017 at 02:11:02PM +0900, Byungchul Park wrote:
> > On Wed, Apr 19, 2017 at 04:25:03PM +0200, Peter Zijlstra wrote:
>
> > > I still don't like work_id; it doesn't have anything to do with
> > > workqueues per se,
On Mon, Apr 24, 2017 at 02:11:02PM +0900, Byungchul Park wrote:
> On Wed, Apr 19, 2017 at 04:25:03PM +0200, Peter Zijlstra wrote:
> > I still don't like work_id; it doesn't have anything to do with
> > workqueues per se, other than the fact that they end up using it.
> >
> > It's a history
On Mon, Apr 24, 2017 at 02:11:02PM +0900, Byungchul Park wrote:
> On Wed, Apr 19, 2017 at 04:25:03PM +0200, Peter Zijlstra wrote:
> > I still don't like work_id; it doesn't have anything to do with
> > workqueues per se, other than the fact that they end up using it.
> >
> > It's a history
On Mon, Apr 24, 2017 at 12:04:12PM +0900, Byungchul Park wrote:
> On Wed, Apr 19, 2017 at 07:19:54PM +0200, Peter Zijlstra wrote:
> > > +/*
> > > + * For crosslock.
> > > + */
> > > +static int add_xlock(struct held_lock *hlock)
> > > +{
> > > + struct cross_lock *xlock;
> > > + unsigned int
On Mon, Apr 24, 2017 at 12:04:12PM +0900, Byungchul Park wrote:
> On Wed, Apr 19, 2017 at 07:19:54PM +0200, Peter Zijlstra wrote:
> > > +/*
> > > + * For crosslock.
> > > + */
> > > +static int add_xlock(struct held_lock *hlock)
> > > +{
> > > + struct cross_lock *xlock;
> > > + unsigned int
On Wed, Apr 19, 2017 at 04:25:03PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +struct hist_lock {
> > + /*
> > +* Each work of workqueue might run in a different context,
> > +* thanks to concurrency support of workqueue. So we have
On Wed, Apr 19, 2017 at 04:25:03PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +struct hist_lock {
> > + /*
> > +* Each work of workqueue might run in a different context,
> > +* thanks to concurrency support of workqueue. So we have
On Wed, Apr 19, 2017 at 05:08:35PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +/*
> > + * Only access local task's data, so irq disable is only required.
> > + */
> > +static int same_context_xhlock(struct hist_lock *xhlock)
> > +{
> > +
On Wed, Apr 19, 2017 at 05:08:35PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +/*
> > + * Only access local task's data, so irq disable is only required.
> > + */
> > +static int same_context_xhlock(struct hist_lock *xhlock)
> > +{
> > +
On Wed, Apr 19, 2017 at 07:20:19PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +config LOCKDEP_CROSSRELEASE
> > + bool "Lock debugging: make lockdep work for crosslocks"
> > + select PROVE_LOCKING
>
> depends PROVE_LOCKING
>
>
On Wed, Apr 19, 2017 at 07:20:19PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +config LOCKDEP_CROSSRELEASE
> > + bool "Lock debugging: make lockdep work for crosslocks"
> > + select PROVE_LOCKING
>
> depends PROVE_LOCKING
>
>
On Wed, Apr 19, 2017 at 07:19:54PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +/*
> > + * Only access local task's data, so irq disable is only required.
>
> A comment describing what it does; record a hist_lock entry; would be
> more
On Wed, Apr 19, 2017 at 07:19:54PM +0200, Peter Zijlstra wrote:
> On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> > +/*
> > + * Only access local task's data, so irq disable is only required.
>
> A comment describing what it does; record a hist_lock entry; would be
> more
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +config LOCKDEP_CROSSRELEASE
> + bool "Lock debugging: make lockdep work for crosslocks"
> + select PROVE_LOCKING
depends PROVE_LOCKING
instead ?
> + default n
> + help
> + This makes lockdep work for
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +config LOCKDEP_CROSSRELEASE
> + bool "Lock debugging: make lockdep work for crosslocks"
> + select PROVE_LOCKING
depends PROVE_LOCKING
instead ?
> + default n
> + help
> + This makes lockdep work for
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +/*
> + * Only access local task's data, so irq disable is only required.
A comment describing what it does; record a hist_lock entry; would be
more useful.
> + */
> +static void add_xhlock(struct held_lock *hlock)
> +{
> +
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +/*
> + * Only access local task's data, so irq disable is only required.
A comment describing what it does; record a hist_lock entry; would be
more useful.
> + */
> +static void add_xhlock(struct held_lock *hlock)
> +{
> +
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +/*
> + * Only access local task's data, so irq disable is only required.
> + */
> +static int same_context_xhlock(struct hist_lock *xhlock)
> +{
> + struct task_struct *curr = current;
> +
> + /* In the case of hardirq
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +/*
> + * Only access local task's data, so irq disable is only required.
> + */
> +static int same_context_xhlock(struct hist_lock *xhlock)
> +{
> + struct task_struct *curr = current;
> +
> + /* In the case of hardirq
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +struct hist_lock {
> + /*
> + * Each work of workqueue might run in a different context,
> + * thanks to concurrency support of workqueue. So we have to
> + * distinguish each work to avoid false positive.
> +
On Tue, Mar 14, 2017 at 05:18:52PM +0900, Byungchul Park wrote:
> +struct hist_lock {
> + /*
> + * Each work of workqueue might run in a different context,
> + * thanks to concurrency support of workqueue. So we have to
> + * distinguish each work to avoid false positive.
> +
Lockdep is a runtime locking correctness validator that detects and
reports a deadlock or its possibility by checking dependencies between
locks. It's useful since it does not report just an actual deadlock but
also the possibility of a deadlock that has not actually happened yet.
That enables
Lockdep is a runtime locking correctness validator that detects and
reports a deadlock or its possibility by checking dependencies between
locks. It's useful since it does not report just an actual deadlock but
also the possibility of a deadlock that has not actually happened yet.
That enables
36 matches
Mail list logo
