On Wed, 2009-02-25 at 00:15 -0800, Eric Anholt wrote:
> > Or you could get_user_pages() to fault the user pages and pin them, and
> > then do pagefault_disable() and use copy_from_user_inatomic or such, and
> > release the pages again.
>
> I started poking at this today, since the get_user_pages s
Eric Anholt wrote:
> On Fri, 2009-02-20 at 08:36 +0100, Peter Zijlstra wrote:
>
>> On Thu, 2009-02-19 at 18:04 -0800, Eric Anholt wrote:
>>
>>> On Thu, 2009-02-19 at 23:26 +0100, Peter Zijlstra wrote:
>>>
On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
>
On Fri, 2009-02-20 at 08:36 +0100, Peter Zijlstra wrote:
> On Thu, 2009-02-19 at 18:04 -0800, Eric Anholt wrote:
> > On Thu, 2009-02-19 at 23:26 +0100, Peter Zijlstra wrote:
> > > On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
> > > >
> > > > It looks to me like the driver preferred l
On Fri, 2009-02-20 at 09:31 +0100, Thomas Hellstrom wrote:
> Peter Zijlstra wrote:
> > On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
> >
> >>
> >> It looks to me like the driver preferred locking order is
> >>
> >> object_mutex (which happens to be the device global struct_mutex)
Peter Zijlstra wrote:
> On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
>
>>
>> It looks to me like the driver preferred locking order is
>>
>> object_mutex (which happens to be the device global struct_mutex)
>> mmap_sem
>> offset_mutex.
>>
>> So if one could avoid using the
On Thu, 2009-02-19 at 18:04 -0800, Eric Anholt wrote:
> On Thu, 2009-02-19 at 23:26 +0100, Peter Zijlstra wrote:
> > On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
> > >
> > > It looks to me like the driver preferred locking order is
> > >
> > > object_mutex (which happens to be the
On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
>
> It looks to me like the driver preferred locking order is
>
> object_mutex (which happens to be the device global struct_mutex)
> mmap_sem
> offset_mutex.
>
> So if one could avoid using the struct_mutex for object bookkeepin
On Thu, 2009-02-19 at 23:26 +0100, Peter Zijlstra wrote:
> On Thu, 2009-02-19 at 22:02 +0100, Thomas Hellstrom wrote:
> >
> > It looks to me like the driver preferred locking order is
> >
> > object_mutex (which happens to be the device global struct_mutex)
> > mmap_sem
> > offset_mutex.
Peter Zijlstra wrote:
> On Tue, 2009-02-17 at 16:59 -0800, Eric Anholt wrote:
>
>> The basic problem was
>> mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap(), i915_gem_fault())
>> struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
>>
>
> That's not the only problem, t
On Tue, 2009-02-17 at 16:59 -0800, Eric Anholt wrote:
> The basic problem was
> mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap(), i915_gem_fault())
> struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
That's not the only problem, there's also:
dup_mmap()
down_write(mmap_
Eric Anholt said the following on 2009-2-18 8:59:
> The basic problem was
> mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap(), i915_gem_fault())
> struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
>
> We have plenty of places where we want to hold device state the same
> (s
The basic problem was
mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap(), i915_gem_fault())
struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
We have plenty of places where we want to hold device state the same
(struct_mutex) while we move a non-trivial amount of data
(copy_
On Tue, 2009-02-03 at 22:33 -0800, Eric Anholt wrote:
> The basic problem was
> mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap())
> struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
>
> We have plenty of places where we want to hold device state the same
> (struct_mutex) w
The basic problem was
mmap_sem (do_mmap()) -> struct_mutex (drm_gem_mmap())
struct_mutex (i915_gem_execbuffer()) -> mmap_sem (copy_from/to_user())
We have plenty of places where we want to hold device state the same
(struct_mutex) while we move a non-trivial amount of data
(copy_from/to_user()), s
14 matches
Mail list logo