public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"mingo@kernel.org" <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>, Neil Brown <neilb@suse.de>,
	Michael Shaver <jmshaver@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] sched: Avoid that __wait_on_bit_lock() hangs
Date: Wed, 10 Aug 2016 18:27:19 +0200	[thread overview]
Message-ID: <20160810162719.GA6883@redhat.com> (raw)
In-Reply-To: <426a381f-b1d9-e1f1-773d-75ccdccfa832@sandisk.com>

On 08/10, Bart Van Assche wrote:
>
> On 08/10/2016 03:46 AM, Oleg Nesterov wrote:
> > OK. Could you  try another debugging patch below?
> >
> > Oleg.
> > ---
> >
> > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> > index e5a3244..9d5f892 100644
> > --- a/include/linux/page-flags.h
> > +++ b/include/linux/page-flags.h
> > @@ -711,6 +711,15 @@ static inline int page_has_private(struct page *page)
> >  	return !!(page->flags & PAGE_FLAGS_PRIVATE);
> >  }
> >
> > +void unlock_page(struct page *page);
> > +static inline void __ClearPageLocked_x(struct page *page)
> > +{
> > +	if (PageLocked(compound_head(page)))
> > +		unlock_page(page);
> > +}
> > +
> > +#define __ClearPageLocked(page)	__ClearPageLocked_x(page)
> > +
> >  #undef PF_ANY
> >  #undef PF_HEAD
> >  #undef PF_NO_TAIL
>
> Hi Oleg,
>
> Are you sure that all __ClearPageLocked() users pass the compound head
> to that macro?

Hmm. it obviously should... which kernel version do you use for testing?

>From include/linux/page-flags.h

	__PAGEFLAG(Locked, locked, PF_NO_TAIL)

and

	#define PF_NO_TAIL(page, enforce) ({                                    \
		VM_BUG_ON_PGFLAGS(enforce && PageTail(page), page);     \
	compound_head(page);})
	
and this matches compound_head() in lock/unlock_page().

> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -711,6 +711,17 @@ static inline int page_has_private(struct page *page)
>  	return !!(page->flags & PAGE_FLAGS_PRIVATE);
>  }
>
> +void unlock_page(struct page *page);
> +static inline void __ClearPageLocked_x(struct page *page)
> +{
> +	if (PageLocked(compound_head(page)))
> +		unlock_page(page);
> +	else
> +		__ClearPageLocked(page);
> +}

No, no. If you use an old kernel (which doesn't call compound_head() in
lock_page()), then just remove compound_head() from __ClearPageLocked_x()
above:

	static inline void __ClearPageLocked_x(struct page *page)
	{
		if (PageLocked(page))
			unlock_page(page);
	}

even if this shouldn't make any difference afaics, note the
VM_BUG_ON_PGFLAGS() above.

Oleg.

  reply	other threads:[~2016-08-10 18:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-03 16:35 [PATCH] sched: Avoid that __wait_on_bit_lock() hangs Bart Van Assche
2016-08-03 18:11 ` Peter Zijlstra
2016-08-03 18:56   ` Bart Van Assche
2016-08-03 21:30     ` Oleg Nesterov
2016-08-03 21:51       ` Bart Van Assche
2016-08-04 14:09         ` Peter Zijlstra
2016-08-04 14:31           ` Bart Van Assche
2016-08-05 17:41           ` Bart Van Assche
2016-08-08 10:22             ` Peter Zijlstra
2016-08-08 14:38               ` Bart Van Assche
2016-08-08 16:20                 ` Oleg Nesterov
2016-08-08 18:31                   ` Bart Van Assche
2016-08-09 17:14                     ` Oleg Nesterov
2016-08-09 18:48                       ` Bart Van Assche
2016-08-09 23:10                         ` Bart Van Assche
2016-08-10 10:45                         ` Oleg Nesterov
2016-08-10 16:01                           ` Bart Van Assche
2016-08-10 16:27                             ` Oleg Nesterov [this message]
2016-08-10 19:58                           ` Bart Van Assche
2016-08-11 17:36                             ` Oleg Nesterov
2016-08-12 16:16                               ` Oleg Nesterov
2016-08-12 16:27                                 ` Bart Van Assche
2016-08-12 22:47                                 ` Bart Van Assche
2016-08-13 16:32                                   ` Oleg Nesterov
2016-08-15 23:39                                     ` Bart Van Assche
2016-08-16 13:06                                       ` Oleg Nesterov
2016-08-16 16:54                                         ` Bart Van Assche
2016-08-17 17:30                                           ` Oleg Nesterov
2016-08-13 17:07                                   ` Oleg Nesterov
2016-08-09 23:56                   ` Bart Van Assche
2016-08-10 10:57                     ` Oleg Nesterov
2016-08-10 11:03                       ` Peter Zijlstra
2016-08-04  0:05       ` Bart Van Assche

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=20160810162719.GA6883@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bart.vanassche@sandisk.com \
    --cc=hannes@cmpxchg.org \
    --cc=jmshaver@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=neilb@suse.de \
    --cc=peterz@infradead.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox