From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752603AbcHUKcC (ORCPT ); Sun, 21 Aug 2016 06:32:02 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:61364 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751694AbcHUKcB (ORCPT ); Sun, 21 Aug 2016 06:32:01 -0400 X-IronPort-AV: E=Sophos;i="5.28,554,1464645600"; d="scan'208";a="190687164" Date: Sun, 21 Aug 2016 06:31:54 -0400 (EDT) From: Julia Lawall X-X-Sender: jll@hadrien To: Christophe JAILLET cc: kernel-janitors@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] staging/lustre/llite: Use memdup_user() rather than duplicating its implementation In-Reply-To: <66b32046-56ee-430e-e80e-1cdd5a8e68c4@wanadoo.fr> Message-ID: References: <566ABCD9.1060404@users.sourceforge.net> <73da135c-be81-e915-9b7a-6773e730b4e7@users.sourceforge.net> <66b32046-56ee-430e-e80e-1cdd5a8e68c4@wanadoo.fr> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-812358299-1471775517=:4152" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-812358299-1471775517=:4152 Content-Type: TEXT/PLAIN; charset=windows-1252 Content-Transfer-Encoding: 8BIT On Sun, 21 Aug 2016, Christophe JAILLET wrote: > Le 21/08/2016 à 11:45, SF Markus Elfring a écrit : > > From: Markus Elfring > > 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 > > --- > > 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. 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > --8323329-812358299-1471775517=:4152--