From: Joel Fernandes <joel@joelfernandes.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"Todd Kjos" <tkjos@google.com>,
syzbot+a76129f18c89f3e2ddd4@syzkaller.appspotmail.com,
ak@linux.intel.com, "Johannes Weiner" <hannes@cmpxchg.org>,
jack@suse.cz, jrdr.linux@gmail.com,
LKML <linux-kernel@vger.kernel.org>,
linux-mm@kvack.org, mawilcox@microsoft.com,
mgorman@techsingularity.net, syzkaller-bugs@googlegroups.com,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Subject: Re: possible deadlock in __do_page_fault
Date: Thu, 24 Jan 2019 08:46:46 -0500 [thread overview]
Message-ID: <20190124134646.GA53008@google.com> (raw)
In-Reply-To: <201901240152.x0O1qUUU069046@www262.sakura.ne.jp>
On Thu, Jan 24, 2019 at 10:52:30AM +0900, Tetsuo Handa wrote:
> Joel Fernandes wrote:
> > > Anyway, I need your checks regarding whether this approach is waiting for
> > > completion at all locations which need to wait for completion.
> >
> > I think you are waiting in unwanted locations. The only location you need to
> > wait in is ashmem_pin_unpin.
> >
> > So, to my eyes all that is needed to fix this bug is:
> >
> > 1. Delete the range from the ashmem_lru_list
> > 2. Release the ashmem_mutex
> > 3. fallocate the range.
> > 4. Do the completion so that any waiting pin/unpin can proceed.
> >
> > Could you clarify why you feel you need to wait for completion at those other
> > locations?
>
> Because I don't know how ashmem works.
You sound like you're almost there though.
> > Note that once a range is unpinned, it is open sesame and userspace cannot
> > really expect consistent data from such range till it is pinned again.
>
> Then, I'm tempted to eliminate shrinker and LRU list (like a draft patch shown
> below). I think this is not equivalent to current code because this shrinks
> upon only range_alloc() time and I don't know whether it is OK to temporarily
> release ashmem_mutex during range_alloc() at "Case #4" of ashmem_pin(), but
> can't we go this direction?
No, the point of the shrinker is to do a lazy free. We cannot free things
during unpin since it can be pinned again and we need to find that range by
going through the list. We also cannot get rid of any lists. Since if
something is re-pinned, we need to find it and find out if it was purged. We
also need the list for knowing what was unpinned so the shrinker works.
By the way, all this may be going away quite soon (the whole driver) as I
said, so just give it a little bit of time.
I am happy to fix it soon if that's not the case (which I should know soon -
like a couple of weeks) but I'd like to hold off till then.
> By the way, why not to check range_alloc() failure before calling range_shrink() ?
That would be a nice thing to do. Send a patch?
thanks,
- Joel
next prev parent reply other threads:[~2019-01-24 13:46 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-20 21:04 possible deadlock in __do_page_fault syzbot
2018-09-20 21:10 ` Andrew Morton
2018-09-20 21:12 ` Todd Kjos
2018-09-20 23:33 ` Joel Fernandes
2018-09-21 6:37 ` Dmitry Vyukov
2018-09-21 23:21 ` Andrew Morton
2019-01-22 10:02 ` Tetsuo Handa
2019-01-22 10:12 ` Dmitry Vyukov
2019-01-22 10:32 ` Tetsuo Handa
2019-01-22 13:52 ` Dmitry Vyukov
2019-01-22 13:54 ` Dmitry Vyukov
2019-01-22 14:08 ` syzbot
2019-01-22 14:08 ` syzbot
2019-01-22 15:32 ` Joel Fernandes
2019-01-23 2:01 ` Tetsuo Handa
2019-01-23 15:57 ` Joel Fernandes
2019-01-24 1:52 ` Tetsuo Handa
2019-01-24 13:46 ` Joel Fernandes [this message]
2019-01-25 16:02 ` Tetsuo Handa
2019-01-25 16:02 ` Tetsuo Handa
2019-01-28 16:45 ` Joel Fernandes
2019-01-28 16:45 ` Joel Fernandes
2019-01-29 10:44 ` Tetsuo Handa
2019-01-26 1:57 ` Tetsuo Handa
2019-01-26 1:57 ` Tetsuo Handa
2018-10-01 5:23 ` syzbot
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=20190124134646.GA53008@google.com \
--to=joel@joelfernandes.org \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arve@android.com \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=jrdr.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maco@android.com \
--cc=mawilcox@microsoft.com \
--cc=mgorman@techsingularity.net \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=syzbot+a76129f18c89f3e2ddd4@syzkaller.appspotmail.com \
--cc=syzkaller-bugs@googlegroups.com \
--cc=tkjos@android.com \
--cc=tkjos@google.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).