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.
next prev parent 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