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=-9.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 BF6EBC4363A for ; Tue, 27 Oct 2020 18:01:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7BE5E21556 for ; Tue, 27 Oct 2020 18:01:42 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bgdev-pl.20150623.gappssmtp.com header.i=@bgdev-pl.20150623.gappssmtp.com header.b="UoiZn2ej" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1824025AbgJ0SBk (ORCPT ); Tue, 27 Oct 2020 14:01:40 -0400 Received: from mail-io1-f65.google.com ([209.85.166.65]:45011 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1823710AbgJ0SBA (ORCPT ); Tue, 27 Oct 2020 14:01:00 -0400 Received: by mail-io1-f65.google.com with SMTP id z17so2505285iog.11 for ; Tue, 27 Oct 2020 11:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ed3AIF7qFllVghkuMSpgY+e4IbkAvQfdceeKpQaUdxk=; b=UoiZn2ejgC7wXGBMzC5P1HZYY0nl6Wa3KE0/4S9Ciuieo7WYMXpDS0Iaqpc4XiAPdO qMSPbldaS4qotDJxt10RTbnG9MLtwWkVWivTQZrOtp1ibfKEiirPfM/hcYKscWcE5G9+ hdA0OqGIyHCG+6wpH2Tcj5TcpWPTkljgGKnbGOzRrgHXz7X+jipA9gLH6g8zN/Jx0l4s /OKkLzKstGxFD2CYIuU1B33wI1K0Ml8+qKW5x8c0LoZzpt+1zSKoX87G79JYtOSZ/rG6 gJ+d5QJ1DFf7m/UdqRG6MK7XEwKpEIVQ7cBBbC41y7jJlAMtCPK8jhzSkqrf6tO37h92 JCSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ed3AIF7qFllVghkuMSpgY+e4IbkAvQfdceeKpQaUdxk=; b=U4GkDQU7S03kZAr30ZcIfcEuVSB0OIgzhCMRdh/VNVm2NDeud7AmfGZWV08lO26Y+m IKj/j7MIfYDzd6J6D3RW3L+tBTWgFklQfUsmwlWWKvE0ppCSwsCfdgp4FPzxZSP8DDG+ 6rYWjYLfxBDo7vKNF89OKurlXzH9y1ALf1PcGx3mN7RSgdJvNfzZ/9NDJBVzaUBBHrsh W4H6q8BL95WF0sHBUqQmkNYhIXJoNhdXq69Qk4YjMWHwLiuM5DG3PF/EIB7ReuLtEsKs lwZK/R/r7lP1YxK2Y+TJunkdCC4miLPCAt/0kXI5DWqVoOgSFnMltIdTB9XnDq9MrmRN l8Ig== X-Gm-Message-State: AOAM533RoZEkBKVHt1fd7U+YyuMU3HAve3/PgU9nihWbGa0lJESYmJVi SfuL+DQKPuiGvghApFUNnZ/C5hqSbIBb/z9YNZK0Ng== X-Google-Smtp-Source: ABdhPJwN08N0ZyzhoITVdnvB4ryeaKood+3vq0iIUYgCE2JJfuXumCj2bIDB2qD60OdiaWwDhRbGH3iAIo+DCc+ziro= X-Received: by 2002:a6b:f401:: with SMTP id i1mr3323522iog.130.1603821657825; Tue, 27 Oct 2020 11:00:57 -0700 (PDT) MIME-Version: 1.0 References: <20201027121725.24660-1-brgl@bgdev.pl> <20201027121725.24660-4-brgl@bgdev.pl> <20201027112607-mutt-send-email-mst@kernel.org> <685d850347a1191bba8ba7766fc409b140d18f03.camel@perches.com> <2767969b94fd66db1fb0fc13b5783ae65b7deb2f.camel@perches.com> In-Reply-To: <2767969b94fd66db1fb0fc13b5783ae65b7deb2f.camel@perches.com> From: Bartosz Golaszewski Date: Tue, 27 Oct 2020 19:00:46 +0100 Message-ID: Subject: Re: [PATCH 3/8] vhost: vringh: use krealloc_array() To: Joe Perches Cc: Bartosz Golaszewski , "Michael S. Tsirkin" , Andy Shevchenko , Sumit Semwal , Gustavo Padovan , =?UTF-8?Q?Christian_K=C3=B6nig?= , Mauro Carvalho Chehab , Borislav Petkov , Tony Luck , James Morse , Robert Richter , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , Alexander Shishkin , Linus Walleij , Jason Wang , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Jaroslav Kysela , Takashi Iwai , linux-media , linux-drm , linaro-mm-sig@lists.linaro.org, LKML , linux-edac@vger.kernel.org, linux-gpio , kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, netdev , linux-mm@kvack.org, Linux-ALSA Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 27, 2020 at 6:08 PM Joe Perches wrote: > > On Tue, 2020-10-27 at 17:58 +0100, Bartosz Golaszewski wrote: > > On Tue, Oct 27, 2020 at 5:50 PM Joe Perches wrote: > > > > > > On Tue, 2020-10-27 at 11:28 -0400, Michael S. Tsirkin wrote: > > > > On Tue, Oct 27, 2020 at 01:17:20PM +0100, Bartosz Golaszewski wrote: > > > > > From: Bartosz Golaszewski > > > > > > > > > > Use the helper that checks for overflows internally instead of manually > > > > > calculating the size of the new array. > > > > > > > > > > Signed-off-by: Bartosz Golaszewski > > > > > > > > No problem with the patch, it does introduce some symmetry in the code. > > > > > > Perhaps more symmetry by using kmemdup > > > --- > > > drivers/vhost/vringh.c | 23 ++++++++++------------- > > > 1 file changed, 10 insertions(+), 13 deletions(-) > > > > > > diff --git a/drivers/vhost/vringh.c b/drivers/vhost/vringh.c > > > index 8bd8b403f087..99222a3651cd 100644 > > > --- a/drivers/vhost/vringh.c > > > +++ b/drivers/vhost/vringh.c > > > @@ -191,26 +191,23 @@ static int move_to_indirect(const struct vringh *vrh, > > > static int resize_iovec(struct vringh_kiov *iov, gfp_t gfp) > > > { > > > struct kvec *new; > > > - unsigned int flag, new_num = (iov->max_num & ~VRINGH_IOV_ALLOCATED) * 2; > > > + size_t new_num = (iov->max_num & ~VRINGH_IOV_ALLOCATED) * 2; > > > + size_t size; > > > > > > if (new_num < 8) > > > new_num = 8; > > > > > > - flag = (iov->max_num & VRINGH_IOV_ALLOCATED); > > > - if (flag) > > > - new = krealloc(iov->iov, new_num * sizeof(struct iovec), gfp); > > > - else { > > > - new = kmalloc_array(new_num, sizeof(struct iovec), gfp); > > > - if (new) { > > > - memcpy(new, iov->iov, > > > - iov->max_num * sizeof(struct iovec)); > > > - flag = VRINGH_IOV_ALLOCATED; > > > - } > > > - } > > > + if (unlikely(check_mul_overflow(new_num, sizeof(struct iovec), &size))) > > > + return -ENOMEM; > > > + > > > > The whole point of using helpers such as kmalloc_array() is not doing > > these checks manually. > > Tradeoffs for in readability for overflow and not mistyping or doing > the multiplication of iov->max_num * sizeof(struct iovec) twice. > It's out of scope for this series - I want to add users for krealloc_array(), not refactor code I don't really know. If the maintainer of this bit objects, it can be dropped. > Just fyi: > > the realloc doesn't do a multiplication overflow test as written so the > suggestion is slightly more resistant to defect. > I'm not sure what your point is. I used krealloc_array() exactly for this reason - to add the overflow test. BTW I suppose kmalloc_array() here can be replaced with krealloc_array() if the original pointer is NULL the first time it's called. Bartosz