From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8233BC06513 for ; Wed, 3 Jul 2019 16:33:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 51E80218AD for ; Wed, 3 Jul 2019 16:33:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562171628; bh=ktNAerFGbQZn3KVT3pQ8NIyte4UTPdVi/RkhIoUEYeo=; h=Subject:From:To:Cc:Date:In-Reply-To:References:List-ID:From; b=bGTGMZAtkTqSSA92jgOemtGNh96wZhQfBK1yw+JKQmYB4YSaZ3MVq2bvMngUv1c2T cMXU6E9bz5RM9wajkvYEQelAkjfhRyNmOz+mruikuDtauDwQCUS50FZiD40ekqkhfr LIVeCDoSpIWXUttVjVFca6V+Gh0P24i2j+DJoon8= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727248AbfGCQdr (ORCPT ); Wed, 3 Jul 2019 12:33:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:44226 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726928AbfGCQdq (ORCPT ); Wed, 3 Jul 2019 12:33:46 -0400 Received: from tleilax.poochiereds.net (cpe-71-70-156-158.nc.res.rr.com [71.70.156.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 052E9218A0; Wed, 3 Jul 2019 16:33:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1562171625; bh=ktNAerFGbQZn3KVT3pQ8NIyte4UTPdVi/RkhIoUEYeo=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=JH3JQyp8x3l/vUTh+Hsf30HbLDYNfC9EAhVTElQ4ll0liaA/by7Sh4APCpGyEcQ/t PSD3lSxHAkdxXpj+yG15iQj7UOByHbCY+erwZKC33eyPZKUNdedP2WQFo8PZvPwn6u tJkf3P9G7cByKDDWdT2FkLxcLyIzz30vyM0qQ0Do= Message-ID: Subject: Re: [PATCH v2 04/35] block: Use kmemdup rather than duplicating its implementation From: Jeff Layton To: Fuqian Huang Cc: Ilya Dryomov , Sage Weil , Alex Elder , Jens Axboe , ceph-devel@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Date: Wed, 03 Jul 2019 12:33:43 -0400 In-Reply-To: <20190703162650.32045-1-huangfq.daxian@gmail.com> References: <20190703162650.32045-1-huangfq.daxian@gmail.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.32.3 (3.32.3-1.fc30) MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2019-07-04 at 00:26 +0800, Fuqian Huang wrote: > kmemdup is introduced to duplicate a region of memory in a neat way. > Rather than kmalloc/kzalloc + memcpy, which the programmer needs to > write the size twice (sometimes lead to mistakes), kmemdup improves > readability, leads to smaller code and also reduce the chances of mistakes. > Suggestion to use kmemdup rather than using kmalloc/kzalloc + memcpy. > > Signed-off-by: Fuqian Huang > --- > Changes in v2: > - Fix a typo in commit message (memset -> memcpy) > > drivers/block/rbd.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c > index e5009a34f9c2..47ad3772dc58 100644 > --- a/drivers/block/rbd.c > +++ b/drivers/block/rbd.c > @@ -1068,7 +1068,7 @@ static int rbd_header_from_disk(struct rbd_device *rbd_dev, > > if (snap_names_len > (u64)SIZE_MAX) > goto out_2big; > - snap_names = kmalloc(snap_names_len, GFP_KERNEL); > + snap_names = kmemdup(&ondisk->snaps[snap_count], snap_names_len, GFP_KERNEL); > if (!snap_names) > goto out_err; > > @@ -1088,7 +1088,6 @@ static int rbd_header_from_disk(struct rbd_device *rbd_dev, > * snap_names_len bytes beyond the end of the > * snapshot id array, this memcpy() is safe. > */ > - memcpy(snap_names, &ondisk->snaps[snap_count], snap_names_len); > snaps = ondisk->snaps; > for (i = 0; i < snap_count; i++) { > snapc->snaps[i] = le64_to_cpu(snaps[i].id); Reviewed-by: Jeff Layton