Re: [PATCH] staging/lustre/llite: Use memdup_user() rather than duplicating its implementation

[Vaishali Thakkar]

On Sunday 21 August 2016 04:31 PM, Julia Lawall wrote:
> 
> 
> On Sun, 21 Aug 2016, Vaishali Thakkar wrote:
> 
>>
>>
>> On Sunday 21 August 2016 04:01 PM, Julia Lawall wrote:
>>>
>>>
>>> On Sun, 21 Aug 2016, Christophe JAILLET wrote:
>>>
>>>> Le 21/08/2016 à 11:45, SF Markus Elfring a écrit :
>>>>> From: Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
>>>>> Date: Sun, 21 Aug 2016 11:30:57 +0200
>>>>>
>>>>> Reuse existing functionality from memdup_user() instead of keeping
>>>>> duplicate source code.
>>>>>
>>>>> This issue was detected by using the Coccinelle software.
>>>>>
>>>>> Signed-off-by: Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx>
>>>>> ---
>>>>>   drivers/staging/lustre/lustre/llite/dir.c | 12 +++---------
>>>>>   1 file changed, 3 insertions(+), 9 deletions(-)
>>>>>
>>>>> diff --git a/drivers/staging/lustre/lustre/llite/dir.c
>>>>> b/drivers/staging/lustre/lustre/llite/dir.c
>>>>> index 031c9e4..8b70e42 100644
>>>>> --- a/drivers/staging/lustre/lustre/llite/dir.c
>>>>> +++ b/drivers/staging/lustre/lustre/llite/dir.c
>>>>> @@ -1676,14 +1676,9 @@ out_poll:
>>>>>   	case LL_IOC_QUOTACTL: {
>>>>>   		struct if_quotactl *qctl;
>>>>>   -		qctl = kzalloc(sizeof(*qctl), GFP_NOFS);
>>>> Same as previously reported in another patch, GFP_NOFS has not the same
>>>> meaning than GPF_KERNEL.
>>>> So your proposed clean-up is not 100% equivalent.
>>>>
>>>> Are your sure that GPF_KERNEL instead of GFP_NOFS is right in this code?
>>>>
>>>> Maybe, the coccinelle check should be tweak to only spot "kzalloc(...,
>>>> GFP_KERNEL)" allocation?
>>>
>>> To my dim recollection, GFP_NOFS is not actually allowed in a place where
>>> copy_from_user is being used.  copy_from_user can block due to page
>>> faults, and GFP_NOFS is used when a certain kind of blocking is not
>>> allowed.  So if the code really needs GFP_NOFS, then something else is
>>> wrong.
>>>
>>> The semantic patch intentionally does not specify GFP_KERNEL for this
>>> reason, ie so that these issues will come up and be discussed.  On the
>>> ther hand I agree about the GFP_DMA case, since that doesn't relate to
>>> blocking, as far as I know.  The semantic patch should be updated to not
>>> make/propose the change in that case.
>>
>> I think semantic patch should be updated for all possible flags except
>> GFP_NOFS and GFP_ATOMIC. Because only using these 2 flags with
>> copy_from_user can cause blocking.
> 
> They don't cause blocking, but rather prevent it.

Yes, sorry. I meant blocking functions which may sleep in between.

> But people could use variables as well.  Since other things are rare, it
> seems like it could be better to only block reports on what is known to
> be safe, and not to block reports on unknown things.  A warning could be
> given in some cases.

Sounds reasonable. Warning will work I guess.

> julia
> 
>>
>>> julia
>>>
>>>>
>>>>> -		if (!qctl)
>>>>> -			return -ENOMEM;
>>>>> -
>>>>> -		if (copy_from_user(qctl, (void __user *)arg, sizeof(*qctl))) {
>>>>> -			rc = -EFAULT;
>>>>> -			goto out_quotactl;
>>>>> -		}
>>>>> +		qctl = memdup_user((void __user *)arg, sizeof(*qctl));
>>>>> +		if (IS_ERR(qctl))
>>>>> +			return PTR_ERR(qctl);
>>>>>     		rc = quotactl_ioctl(sbi, qctl);
>>>>>   @@ -1691,7 +1686,6 @@ out_poll:
>>>>>   					    sizeof(*qctl)))
>>>>>   			rc = -EFAULT;
>>>>>   -out_quotactl:
>>>>>   		kfree(qctl);
>>>>>   		return rc;
>>>>>   	}
>>>>
>>>>
>>>>
>>>> ---
>>>> L'absence de virus dans ce courrier électronique a été vérifiée par le
>>>> logiciel antivirus Avast.
>>>> https://www.avast.com/antivirus
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>> --
>> Vaishali
>>
> 

-- 
Vaishali