On Wed, Aug 17, 2016 at 08:31:20PM +0100, Al Viro wrote:
> On Wed, Aug 17, 2016 at 03:24:38PM -0400, Rob Clark wrote:
>
> > hmm, looks like, at least on arm (not sure about arm64),
> >
> > #define __copy_from_user_inatomic __copy_from_user
> >
> > ie. copy_from_user() minus the access_ok() and
On Wed, Aug 17, 2016 at 3:15 PM, Al Viro wrote:
> On Wed, Aug 17, 2016 at 02:49:32PM -0400, Rob Clark wrote:
>
>> I'm not saying that I shouldn't fix it (although not quite sure how
>> yet.. taking/dropping the spinlock inside the loop is not a good
>> option from a
On Wed, Aug 17, 2016 at 02:49:32PM -0400, Rob Clark wrote:
> I'm not saying that I shouldn't fix it (although not quite sure how
> yet.. taking/dropping the spinlock inside the loop is not a good
> option from a performance standpoint). What I am saying is that this
> is not something that can
On Wed, Aug 17, 2016 at 2:49 PM, Rob Clark wrote:
> On Wed, Aug 17, 2016 at 1:08 PM, Al Viro wrote:
>> On Wed, Aug 17, 2016 at 11:08:46AM -0400, Rob Clark wrote:
>>> On Wed, Aug 17, 2016 at 7:40 AM, Vaishali Thakkar
>>>
On Wed, Aug 17, 2016 at 11:08:46AM -0400, Rob Clark wrote:
> On Wed, Aug 17, 2016 at 7:40 AM, Vaishali Thakkar
> wrote:
> > Hello,
> >
> > I was wondering about the call to copy_from_user in function
> > submit_lookup_objects for drive
> >
On Wed, Aug 17, 2016 at 7:40 AM, Vaishali Thakkar
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
>
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