From: Michal Hocko <mhocko@kernel.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
LKML <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
"David S. Miller" <davem@davemloft.net>,
Tony Luck <tony.luck@intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
Chris Zankel <chris@zankel.net>,
Max Filippov <jcmvbkbc@gmail.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Waiman Long <Waiman.Long@hpe.com>
Subject: Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable
Date: Wed, 11 May 2016 09:23:57 +0200 [thread overview]
Message-ID: <20160511072357.GC16677@dhcp22.suse.cz> (raw)
In-Reply-To: <20160510123806.GB3193@twins.programming.kicks-ass.net>
On Tue 10-05-16 14:38:06, Peter Zijlstra wrote:
> On Tue, May 10, 2016 at 01:53:20PM +0200, Michal Hocko wrote:
> > On Tue 10-05-16 19:43:20, Tetsuo Handa wrote:
> > > I hit "allowing the OOM killer to select the same thread again" problem
> > > ( http://lkml.kernel.org/r/20160408113425.GF29820@dhcp22.suse.cz ), but
> > > I think that there is a bug in down_write_killable() series (at least
> > > "locking, rwsem: introduce basis for down_write_killable" patch).
> > >
> > > Complete log is at http://I-love.SAKURA.ne.jp/tmp/serial-20160510-sem.txt.xz .
> > [...]
> > > 2 threads (PID: 1314 and 1443) are sleeping at rwsem_down_read_failed()
> > > but no thread is sleeping at rwsem_down_write_failed_killable().
> > > If there is no thread waiting for write lock, threads waiting for read
> > > lock must be able to run. This suggests that one of threads which was
> > > waiting for write lock forgot to wake up reader threads.
> >
> > Or that the write lock holder is still keeping the lock held. I do not
> > see such a process in your list though. Is it possible that the
> > debug_show_all_locks would just miss it as it is not sleeping?
> >
> > > Looking at rwsem_down_read_failed(), reader threads waiting for the
> > > writer thread to release the lock are waiting on sem->wait_list list.
> > > Looking at __rwsem_down_write_failed_common(), when the writer thread
> > > escaped the
> > >
> > > /* Block until there are no active lockers. */
> > > do {
> > > if (signal_pending_state(state, current)) {
> > > raw_spin_lock_irq(&sem->wait_lock);
> > > ret = ERR_PTR(-EINTR);
> > > goto out;
> > > }
> > > schedule();
> > > set_current_state(state);
> > > } while ((count = sem->count) & RWSEM_ACTIVE_MASK);
> > >
> > > loop due to SIGKILL, I think that the writer thread needs to check for
> > > remaining threads on sem->wait_list list and wake up reader threads
> > > before rwsem_down_write_failed_killable() returns -EINTR.
> >
> > I am not sure I understand. The rwsem counter is not write locked while
> > the thread is sleeping and when we fail on the signal pending so readers
> > should be able to proceed, no?
> >
> > Or are you suggesting that the failure path should call rwsem_wake? I
> > do not see __mutex_lock_common for killable wait doing something like
> > that and rwsem_wake is explicitly documented that it is called after the
> > lock state has been updated already. Now I might be missing something
> > subtle here but I guess the code is correct and it is more likely that
> > the holder of the lock wasn't killed but it is rather holding the lock
> > and doing something else.
>
> Mutex is much simpler; it doesn't have to do the reader-vs-writer
> fairness thing.
>
> However, at the time I was thinking that if we have:
>
> reader (owner)
> writer (pending)
> reader (blocked on writer)
>
> and writer would get cancelled, the up_read() would do a wakeup and kick
> the blocked reader.
>
> But yes, immediately kicking further pending waiters might be better.
OK, that makes sense. We shouldn't be waiting for the first reader to
do up_read.
> Also, looking at it again; I think we're forgetting to re-adjust the
> BIAS for the cancelled writer.
Hmm, __rwsem_down_write_failed_common does
/* undo write bias from down_write operation, stop active locking */
count = rwsem_atomic_update(-RWSEM_ACTIVE_WRITE_BIAS, sem);
which should remove the bias AFAIU. Later we do
if (waiting) {
count = READ_ONCE(sem->count);
/*
* If there were already threads queued before us and there are
* no active writers, the lock must be read owned; so we try to
* wake any read locks that were queued ahead of us.
*/
if (count > RWSEM_WAITING_BIAS)
sem = __rwsem_do_wake(sem, RWSEM_WAKE_READERS);
} else
count = rwsem_atomic_update(RWSEM_WAITING_BIAS, sem);
and that might set RWSEM_WAITING_BIAS but the current holder of the lock
should handle that correctly and wake the waiting tasks IIUC. I will go
and check the code closer. It is quite easy to get this subtle code
wrong...
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2016-05-11 7:24 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-01 11:04 [PATCH 0/11] introduce down_write_killable for rw_semaphore v2 Michal Hocko
2016-04-01 11:04 ` [PATCH 01/11] locking, rwsem: get rid of __down_write_nested Michal Hocko
2016-04-02 0:28 ` Davidlohr Bueso
2016-04-01 11:04 ` [PATCH 02/11] locking, rwsem: drop explicit memory barriers Michal Hocko
2016-04-02 1:17 ` Davidlohr Bueso
2016-04-04 9:03 ` Michal Hocko
2016-04-04 9:06 ` [PATCH 1/2] xtensa, rwsem: drop superfluous arch specific implementation Michal Hocko
2016-04-04 9:06 ` [PATCH 2/2] sh, " Michal Hocko
2016-04-06 9:26 ` Peter Zijlstra
2016-04-06 9:50 ` Geert Uytterhoeven
2016-04-06 10:27 ` Peter Zijlstra
2016-04-04 10:23 ` [PATCH 1/2] xtensa, " Max Filippov
2016-04-06 9:06 ` [PATCH] sparc, " Michal Hocko
2016-04-01 11:04 ` [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable Michal Hocko
2016-04-02 4:41 ` Davidlohr Bueso
2016-04-04 9:17 ` Michal Hocko
2016-04-04 9:21 ` Peter Zijlstra
2016-04-07 6:58 ` Davidlohr Bueso
2016-04-07 7:38 ` Michal Hocko
2016-05-10 10:43 ` Tetsuo Handa
2016-05-10 11:53 ` Michal Hocko
2016-05-10 12:38 ` Peter Zijlstra
2016-05-10 13:57 ` Tetsuo Handa
2016-05-11 7:23 ` Michal Hocko [this message]
2016-05-11 8:28 ` Michal Hocko
2016-05-11 8:44 ` Peter Zijlstra
2016-05-11 9:04 ` Michal Hocko
2016-05-11 9:17 ` Peter Zijlstra
2016-05-11 9:31 ` Michal Hocko
2016-05-11 9:41 ` Peter Zijlstra
2016-05-11 13:59 ` Michal Hocko
2016-05-11 18:03 ` Michal Hocko
2016-05-12 11:57 ` [PATCH] locking, rwsem: Fix down_write_killable() Peter Zijlstra
2016-05-12 12:15 ` [tip:locking/rwsem] locking/rwsem: " tip-bot for Peter Zijlstra
2016-05-12 16:59 ` [PATCH] locking, rwsem: " Michal Hocko
2016-05-15 20:57 ` [tip:locking/rwsem] locking/rwsem: " tip-bot for Peter Zijlstra
2016-05-12 12:12 ` [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable Peter Zijlstra
2016-05-12 12:19 ` Michal Hocko
2016-05-12 13:58 ` Peter Zijlstra
2016-05-12 19:42 ` Waiman Long
2016-05-11 8:35 ` Peter Zijlstra
2016-05-11 9:02 ` Michal Hocko
2016-04-01 11:04 ` [PATCH 04/11] alpha, rwsem: provide __down_write_killable Michal Hocko
2016-04-01 11:04 ` [PATCH 05/11] ia64, " Michal Hocko
2016-04-01 11:04 ` [PATCH 06/11] s390, " Michal Hocko
2016-04-01 11:04 ` [PATCH 07/11] sh, " Michal Hocko
2016-04-01 11:04 ` [PATCH 08/11] sparc, " Michal Hocko
2016-04-01 11:04 ` [PATCH 09/11] xtensa, " Michal Hocko
2016-04-01 11:04 ` [PATCH 10/11] x86, " Michal Hocko
2016-04-06 18:31 ` Peter Zijlstra
2016-04-01 11:04 ` [PATCH 11/11] locking, rwsem: provide down_write_killable Michal Hocko
-- strict thread matches above, loose matches on Subject: below --
2016-02-29 12:58 [PATCH 0/11] introduce down_write_killable for rw_semaphore Michal Hocko
2016-02-29 12:58 ` [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable Michal Hocko
2016-03-30 13:25 ` Peter Zijlstra
2016-03-31 8:33 ` Michal Hocko
2016-03-31 8:44 ` Peter Zijlstra
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=20160511072357.GC16677@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=Waiman.Long@hpe.com \
--cc=akpm@linux-foundation.org \
--cc=chris@zankel.net \
--cc=dave@stgolabs.net \
--cc=davem@davemloft.net \
--cc=hpa@zytor.com \
--cc=jcmvbkbc@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=penguin-kernel@I-love.SAKURA.ne.jp \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).