From: Guenter Roeck <linux@roeck-us.net>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Intel graphics driver community testing & development
<intel-gfx@lists.freedesktop.org>
Subject: Re: [CI, v3, 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set
Date: Thu, 28 Feb 2019 14:11:51 -0800 [thread overview]
Message-ID: <20190228221151.GA17424@roeck-us.net> (raw)
In-Reply-To: <155139130531.5847.10912664209750394419@skylake-alporthouse-com>
On Thu, Feb 28, 2019 at 10:01:45PM +0000, Chris Wilson wrote:
> Quoting Guenter Roeck (2019-02-28 21:57:03)
> > On Thu, Feb 28, 2019 at 01:32:41PM -0800, Guenter Roeck wrote:
> > > On Thu, Feb 28, 2019 at 11:12:49AM -0800, Guenter Roeck wrote:
> > > > Hi,
> > > >
> > > > On Thu, Feb 07, 2019 at 10:54:53AM +0200, Joonas Lahtinen wrote:
> > > > > Make sure the underlying VMA in the process address space is the
> > > > > same as it was during vm_mmap to avoid applying WC to wrong VMA.
> > > > >
> > > > > A more long-term solution would be to have vm_mmap_locked variant
> > > > > in linux/mmap.h for when caller wants to hold mmap_sem for an
> > > > > extended duration.
> > > > >
> > > >
> > > > It seems like we may have a regression due to this patch. I am still
> > > > debugging, but I have a question; please see below.
> > > >
> > > > Thanks,
> > > > Guenter
> > > >
> > > > > v2:
> > > > > - Refactor the compare function
> > > > >
> > > > > Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings for objects")
> > > > > Reported-by: Adam Zabrocki <adamza@microsoft.com>
> > > > > Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
> > > > > Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> > > > > Cc: <stable@vger.kernel.org> # v4.0+
> > > > > Cc: Akash Goel <akash.goel@intel.com>
> > > > > Cc: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> > > > > Cc: Adam Zabrocki <adamza@microsoft.com>
> > > > > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> #v1
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_gem.c | 12 +++++++++++-
> > > > > 1 file changed, 11 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > > > > index 05ce9176ac4e..52639f749908 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > > @@ -1681,6 +1681,16 @@ i915_gem_sw_finish_ioctl(struct drm_device *dev, void *data,
> > > > > return 0;
> > > > > }
> > > > >
> > > > > +static inline bool
> > > > > +__vma_matches(struct vm_area_struct *vma, struct file *filp,
> > > > > + unsigned long addr, unsigned long size)
> > > > > +{
> > > > > + if (vma->vm_file != filp)
> > > > > + return false;
> > > > > +
> > > > > + return vma->vm_start == addr && (vma->vm_end - vma->vm_start) == size;
> > > >
> > > > Shouldn't this be:
> > > > return vma->vm_start == addr && (vma->vm_end - vma->vm_start + 1) == size;
> > > > instead ?
> > > >
> > >
> > > Answer is no .. because vm_end points to the first byte after the
> > > end address.
> > >
> > > The actual values are:
> > >
> > > start=7d288f7f9000 end=7d288f84d000 end-start=54000 size=53400
> > >
> > > meaning the size field passed in the ioctl is smaller than the total length
> > > of the area.
> > >
> > > Question is now: Is the request/ioctl indeed invalid, ie does the requested
> > > size have to match the vma size ? This used to work until this patch was
> > > applied, and the change causes our test code to fail (and possibly minigbm,
> > > which is used by the test code). That doesn't mean that our code is correct
> > > (I see some related local changes in our version of minigbm), but it is
> > > annoying, and I am being asked to revert this patch as regression
> > > from our kernel releases.
> > >
> >
> > In i915_gem_create():
> >
> > size = roundup(size, PAGE_SIZE);
> > if (size == 0)
> > return -EINVAL;
> >
> > This suggests to me that the requested size can be smaller than the
>
> Not really, the ABI has never handled less than page-sized requests.
> It's a mistake from the very beginning that it was not rejected as being
> the invalid size it was.
>
> > allocated size, which in turn suggests that the check
> > (vma->vm_end - vma->vm_start) == size;
> > is wrong. Either it should be
> > (vma->vm_end - vma->vm_start) >= size;
> > or possibly
> > (vma->vm_end - vma->vm_start) == roundup(size, PAGE_SIZE);
> >
> > Any comments/feedback/thoughts ?
>
> It's a violation of mmap(2).
>
> Is probably what we will have to do if you ring the regression bell loud
> enough, and do not see the folly of your ways. :-p
I won't ring any bells; I don't play such games. I'll make a local change
in our kernel to fix the problem, quoting your statement that less than
page-sized requests were never supposed to be supported, and add a note
that we'll have to handle this with a local patch going forward.
Guenter
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2019-02-28 22:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-07 8:54 [CI v3 1/2] drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set Joonas Lahtinen
2019-02-07 8:54 ` [CI v3 2/2] drm/i915: Handle vm_mmap error " Joonas Lahtinen
2019-02-07 9:29 ` ✓ Fi.CI.BAT: success for series starting with [CI,v3,1/2] drm/i915: Prevent a race " Patchwork
2019-02-07 11:52 ` ✓ Fi.CI.IGT: " Patchwork
2019-02-28 19:12 ` [CI, v3, 1/2] " Guenter Roeck
2019-02-28 21:32 ` Guenter Roeck
2019-02-28 21:48 ` Chris Wilson
2019-02-28 21:57 ` Guenter Roeck
2019-02-28 22:01 ` Chris Wilson
2019-02-28 22:11 ` Guenter Roeck [this message]
2019-02-28 22:18 ` Chris Wilson
2019-02-28 22:27 ` Guenter Roeck
2019-02-28 22:34 ` Chris Wilson
2019-03-01 0:15 ` Guenter Roeck
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=20190228221151.GA17424@roeck-us.net \
--to=linux@roeck-us.net \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.