Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp2688883pxu; Sun, 18 Oct 2020 11:31:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJywVUx5G5l/oDOA9qcpkyNGtTQCCdJhISlSaKSHU1kVDaDP8tz1o7cTsJqDOdMwv7wNDPS2 X-Received: by 2002:a17:906:4048:: with SMTP id y8mr13726730ejj.466.1603045892633; Sun, 18 Oct 2020 11:31:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603045892; cv=none; d=google.com; s=arc-20160816; b=vdeVSuSV3dOnCMDW69u0Gga6naVKjxfCsQF826BosALa+/UfCECrDP15L86q+SQ3NS oJgRucL9ERObY1xlngtt2wa3bVChG3Zx/wXZwyzvqlUsatjGCaiZupF0tDFSlOYkqNxw r0LsvBnVLBhm7I1q8NjH0tCb01CsTxgUOMn6/3rDf5JwMSqr8yP7SBXHhi/paMk+eaMW db+XY1HvPYK7h3ZYqu/WQ8i7KINAflKgOD9bZaFDqeAm6JvqdjwaO27T1KXpesLKq6qa mpTpkpoUTZ3aY+wMtyQhP9aSRadWPVvLlwaLyQRrR4LVCAip+mLJ4b/G9O1k+B7rsgZq o+/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=PGP8moKoM94y9o8EEkWwKvUggV3UY84qiSoK4Rt7AEA=; b=tXvYW5T5WJflBAk7sMA3FKx9yWE16ELTrVMpWcFGj62uAjftPmwZ3v7nAm4MC1V+rO BKeqNN8W8WYFafZGydNQ7G/ZUoHMuXolLRPw9ZM6mgJElVaOoqN9hvfkqLPTVM8HYOFm dGnPygOz/f3vG9C3KcN9TSlmU6n4+XBF76yZ3DxNbdSrqq3xD+Sa6aRghqjagvnKwfnM wXT8D3SjS8Xs5jAPPOk4xiCK2C1gfqAo7m41gAJU/XQzwDYec7cb0QYKyhTme1c6dteg fKrJ5iK1nbBMjHFQxCR1YyWjGVZ+hGRrmt63rN8IB+jjWWuuo5EnNji6Bv6deaHFozih APWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u19si6149835eds.502.2020.10.18.11.30.53; Sun, 18 Oct 2020 11:31:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727130AbgJRRNt (ORCPT + 99 others); Sun, 18 Oct 2020 13:13:49 -0400 Received: from smtp.infotech.no ([82.134.31.41]:52020 "EHLO smtp.infotech.no" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726689AbgJRRNt (ORCPT ); Sun, 18 Oct 2020 13:13:49 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp.infotech.no (Postfix) with ESMTP id 849A220425B; Sun, 18 Oct 2020 19:13:46 +0200 (CEST) X-Virus-Scanned: by amavisd-new-2.6.6 (20110518) (Debian) at infotech.no Received: from smtp.infotech.no ([127.0.0.1]) by localhost (smtp.infotech.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5SUJaaRNZ+X; Sun, 18 Oct 2020 19:13:43 +0200 (CEST) Received: from xtwo70.bingwo.ca (host-104-157-204-209.dyn.295.ca [104.157.204.209]) by smtp.infotech.no (Postfix) with ESMTPA id 8AB1520424C; Sun, 18 Oct 2020 19:13:41 +0200 (CEST) From: Douglas Gilbert To: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org Cc: martin.petersen@oracle.com, axboe@kernel.dk, bvanassche@acm.org, bostroesser@gmail.com Subject: [PATCH v2 1/4] sgl_alloc_order: remove 4 GiB limit, sgl_free() warning Date: Sun, 18 Oct 2020 13:13:33 -0400 Message-Id: <20201018171336.63839-2-dgilbert@interlog.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20201018171336.63839-1-dgilbert@interlog.com> References: <20201018171336.63839-1-dgilbert@interlog.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This patch removes a check done by sgl_alloc_order() before it starts any allocations. The comment before the removed code says: "Check for integer overflow" arguably gives a false sense of security. The right hand side of the expression in the condition is resolved as u32 so cannot exceed UINT32_MAX (4 GiB) which means 'length' cannot exceed that amount. If that was the intention then the comment above it could be dropped and the condition rewritten more clearly as: if (length > UINT32_MAX) <>; The author's intention is to use sgl_alloc_order() to replace vmalloc(unsigned long) for a large allocation (debug ramdisk). vmalloc has no limit at 4 GiB so its seems unreasonable that: sgl_alloc_order(unsigned long long length, ....) does. sgl_s made with sgl_alloc_order(chainable=false) have equally sized segments placed in a scatter gather array. That allows O(1) navigation around a big sgl using some simple integer maths. Having previously sent a patch to fix a memory leak in sg_alloc_order() take the opportunity to put a one line comment above sgl_free()'s declaration that it is not suitable when order > 0 . The mis-use of sgl_free() when order > 0 was the reason for the memory leak. The other users of sgl_alloc_order() in the kernel where checked and found to handle free-ing properly. Signed-off-by: Douglas Gilbert --- include/linux/scatterlist.h | 1 + lib/scatterlist.c | 3 --- 2 files changed, 1 insertion(+), 3 deletions(-) diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h index 45cf7b69d852..80178afc2a4a 100644 --- a/include/linux/scatterlist.h +++ b/include/linux/scatterlist.h @@ -302,6 +302,7 @@ struct scatterlist *sgl_alloc(unsigned long long length, gfp_t gfp, unsigned int *nent_p); void sgl_free_n_order(struct scatterlist *sgl, int nents, int order); void sgl_free_order(struct scatterlist *sgl, int order); +/* Only use sgl_free() when order is 0 */ void sgl_free(struct scatterlist *sgl); #endif /* CONFIG_SGL_ALLOC */ diff --git a/lib/scatterlist.c b/lib/scatterlist.c index c448642e0f78..d5770e7f1030 100644 --- a/lib/scatterlist.c +++ b/lib/scatterlist.c @@ -493,9 +493,6 @@ struct scatterlist *sgl_alloc_order(unsigned long long length, u32 elem_len; nent = round_up(length, PAGE_SIZE << order) >> (PAGE_SHIFT + order); - /* Check for integer overflow */ - if (length > (nent << (PAGE_SHIFT + order))) - return NULL; nalloc = nent; if (chainable) { /* Check for integer overflow */ -- 2.25.1