From: Al Viro <viro@ZenIV.linux.org.uk>
To: Rob Clark <robdclark@gmail.com>
Cc: Vaishali Thakkar <vaishali.thakkar@oracle.com>,
David Airlie <airlied@linux.ie>,
linux-arm-msm <linux-arm-msm@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
freedreno@lists.freedesktop.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Julia Lawall <julia.lawall@lip6.fr>
Subject: Re: Use of copy_from_user in msm_gem_submit.c while holding a spin_lock
Date: Wed, 17 Aug 2016 18:08:27 +0100 [thread overview]
Message-ID: <20160817170827.GC2356@ZenIV.linux.org.uk> (raw)
In-Reply-To: <CAF6AEGs31L4R4XG_GxDU5u0kC9yCKYpq3k9998b6KH-OPq6CQA@mail.gmail.com>
On Wed, Aug 17, 2016 at 11:08:46AM -0400, Rob Clark wrote:
> On Wed, Aug 17, 2016 at 7:40 AM, Vaishali Thakkar
> <vaishali.thakkar@oracle.com> wrote:
> > Hello,
> >
> > I was wondering about the call to copy_from_user in function submit_lookup_objects for drive
> > /gpu/drm/msm/msm_gem_submit.c It calls copy_from_user[1] in a spin_lock, which is not normally
> > allowed, due to the possibility of a deadlock.
> >
> > Is there some reason that I am overlooking why it is OK in this case? Is there some code in the
> > same file which ensures that page fault will not occur when we are calling the function holding
> > spin_lock?
>
> hmm, probably just that it isn't typical to use a swap file on these
> devices (and that lockdep/etc doesn't warn about it).. I guess we
> probably need some sort of slow-path where we drop the lock and try
> again in case there would be a fault..
Sigh... Folks, you don't need swap *at* *all* for copy_from_user() to block.
/* get a zero-filled 64K buffer */
addr = mmap(NULL, 65536, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_SHARED, -1, 0);
if (addr < 0)
piss off
buffer = (void *)addr;
....
pass buf to a syscall
and copy_from_user() in that syscall will have to allocate pages (and possibly
page tables as well). Which can block just fine, no swap involved. Moreover,
if you modify some parts of the buffer first, you will get the pages containing
those modifications already present, but anything still untouched will
a) act as if it had been zeroed first and
b) possibly block on the first dereference, be it from kernel or from
userland. Worse yet, there's nothing to stop libc from using the above for
calloc() and its ilk, with your application having no way to tell. As far
as application is concerned, it has asked a library function to allocate and
zero a piece of memory, got one and yes, it does appear to be properly zeroed.
The bottom line is, copy_from_user() can realistically block, without
anything fishy going on in the userland setup.
next prev parent reply other threads:[~2016-08-17 17:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 11:40 Use of copy_from_user in msm_gem_submit.c while holding a spin_lock Vaishali Thakkar
2016-08-17 15:08 ` Rob Clark
2016-08-17 17:08 ` Al Viro [this message]
2016-08-17 18:49 ` Rob Clark
2016-08-17 18:58 ` Rob Clark
2016-08-17 19:15 ` Al Viro
2016-08-17 19:24 ` Rob Clark
2016-08-17 19:31 ` Al Viro
2016-08-18 8:31 ` Daniel Vetter
2016-08-17 21:29 ` Rob Clark
2016-08-18 8:36 ` Daniel Vetter
2016-08-18 10:55 ` Rob Clark
2016-08-18 13:08 ` Daniel Vetter
2016-08-18 13:14 ` Rob Clark
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=20160817170827.GC2356@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=airlied@linux.ie \
--cc=dri-devel@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=julia.lawall@lip6.fr \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robdclark@gmail.com \
--cc=vaishali.thakkar@oracle.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