Message ID | acce3a38-9930-349d-5299-95d2aa5c47e4@cybernetics.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id DA1AF13BF for <patchwork-linux-mm@patchwork.kernel.org>; Mon, 12 Nov 2018 15:41:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C81EE2A07E for <patchwork-linux-mm@patchwork.kernel.org>; Mon, 12 Nov 2018 15:41:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BC7BB2A0A2; Mon, 12 Nov 2018 15:41:38 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 468AD2A098 for <patchwork-linux-mm@patchwork.kernel.org>; Mon, 12 Nov 2018 15:41:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 49ADD6B0292; Mon, 12 Nov 2018 10:41:37 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 44A136B0294; Mon, 12 Nov 2018 10:41:37 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 33A8F6B0295; Mon, 12 Nov 2018 10:41:37 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by kanga.kvack.org (Postfix) with ESMTP id 03C756B0292 for <linux-mm@kvack.org>; Mon, 12 Nov 2018 10:41:37 -0500 (EST) Received: by mail-qk1-f199.google.com with SMTP id s19so24637431qke.20 for <linux-mm@kvack.org>; Mon, 12 Nov 2018 07:41:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:subject :to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=nMfZ9RiIK02lAYL+37T5dlgwkmxWF9Yw93NdTM8F2A8=; b=epJQYFGzu/wW/RRa8oHj7HMsb6jfVKYKRx0uADcKfbbd8didF7ij20aQmYbN/C+kjJ 9IyVPV83Tm2mevGUv9UqsQni2lWOw21lkJJN9ypzPF5ehgHjJVvAkCV9kU2PbmV9P3m0 8HGb8fwT6jpQ8edICMARGbgWevz1x5BEBQqvmeUqJLc58fWlUhMyWy0DqW3t3Dr4SVpT 0ytUwrRNfbIK1ZzDo7MfZmhUqwylyZDl5lP7dQfXKv6zsS2Dj5HHjwxscvn531yTEL6j KwIeiwCehVK+f+FKO+54e7gDalIMRlKKW/zQuWWkWRnL+yyAHrVQmDqM9F/5SXPfI42c JxVQ== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of btv1==854ac0a7dab==tonyb@cybernetics.com designates 173.71.130.66 as permitted sender) smtp.mailfrom="btv1==854ac0a7dab==tonyb@cybernetics.com" X-Gm-Message-State: AGRZ1gKGWB8JP2uSPG6eaZWvh6ws+vcLDQIdcg+GFVHhf7rlHDJ+jCkw r8UHy2GoZPF0y0fBwZurOVpMStxV62tI0bpi2uYuymSECPnGstyrckq9tkH6LfA01UAJ76I6rsr ta8sOyrAe/SyGyZdPvEyMgl9gdpH6YheenRG4BStvSBSKrAW0y/Jwo1adyWfOSfCsEw== X-Received: by 2002:ac8:7950:: with SMTP id r16mr1410850qtt.12.1542037296782; Mon, 12 Nov 2018 07:41:36 -0800 (PST) X-Google-Smtp-Source: AJdET5fHNHoz+14SwPHj3WE70vX/vCKYLg2SMNfyu8gqbdN7uqh/7spxPGcRTAc5AOkUY31KjH6+ X-Received: by 2002:ac8:7950:: with SMTP id r16mr1410806qtt.12.1542037296174; Mon, 12 Nov 2018 07:41:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542037296; cv=none; d=google.com; s=arc-20160816; b=tTu04XhKwUsKSTOmOooburUXaEKDANCFDoreTBK/EjSjnDFo9VbnMkUcBL5r+4bslV GoLDojzKXlFXY1VOi5MnWIWkU0fqZJ+2z+C8XEywVu0WUnodmWU8fAqUTdtFOPkVRZ7S uqlSIXt66tIgS2F227MzSLIomDxbWwxpbpmLHMR9+ILUyUORgZUomT77ZzLNoCax3To2 rgMhsAmO59eKULGQy5o/4xPjFtuyboiLF+0buCQopX1vzqv/2saCOrhv3UwDGSLiGuKt Px9BNWRkiLBGg49EcOcW2jTHh6j/pl5YK+BKSBUIDfJd81opFSc40v1QVlmFqcmFWjIG HwTg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:content-transfer-encoding:mime-version:user-agent :date:message-id:cc:to:subject:from; bh=nMfZ9RiIK02lAYL+37T5dlgwkmxWF9Yw93NdTM8F2A8=; b=L1JI5TJqqoPOt9ongFNe6MbpPMVh7q/PyVBPwIHHxxpe83mIAMFBf85cq4Gg+hJuFm Cx+F3vnYfEXh3YQflJX3gPUVFjkDhMT8CLl+aIi4kXrakLsbIP/5oGCPBVF4lon59Tli 8RmHkvm7U7WAHe9uzMntnBg/+iGhue34VWEAdswPJi1GiUrhzjnB6Ty1L3pLPMeK3ZMZ L6Agu83xvYjZZ4ued5d3Y1MDn/g633+mpRfY0tTufrpkZmlMQ30l20cHqNvIgY2Htv0y JfgICj2BbjgTj6FYIkkU1enlp3iq3tMPeCo60K3pJSkQhzvTawQjsK1Goc4dFElvmOBj 3amw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of btv1==854ac0a7dab==tonyb@cybernetics.com designates 173.71.130.66 as permitted sender) smtp.mailfrom="btv1==854ac0a7dab==tonyb@cybernetics.com" Received: from mail.cybernetics.com (mail.cybernetics.com. [173.71.130.66]) by mx.google.com with ESMTPS id f196si1428932qka.61.2018.11.12.07.41.36 for <linux-mm@kvack.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 07:41:36 -0800 (PST) Received-SPF: pass (google.com: domain of btv1==854ac0a7dab==tonyb@cybernetics.com designates 173.71.130.66 as permitted sender) client-ip=173.71.130.66; Authentication-Results: mx.google.com; spf=pass (google.com: domain of btv1==854ac0a7dab==tonyb@cybernetics.com designates 173.71.130.66 as permitted sender) smtp.mailfrom="btv1==854ac0a7dab==tonyb@cybernetics.com" X-ASG-Debug-ID: 1542037294-0fb3b01fb3add4a0001-v9ZeMO Received: from cybernetics.com ([10.157.1.126]) by mail.cybernetics.com with ESMTP id x0wO1xpBp7wEfKEO (version=SSLv3 cipher=DES-CBC3-SHA bits=112 verify=NO); Mon, 12 Nov 2018 10:41:34 -0500 (EST) X-Barracuda-Envelope-From: tonyb@cybernetics.com X-ASG-Whitelist: Client Received: from [10.157.2.224] (account tonyb HELO [192.168.200.1]) by cybernetics.com (CommuniGate Pro SMTP 5.1.14) with ESMTPSA id 8529337; Mon, 12 Nov 2018 10:41:34 -0500 From: Tony Battersby <tonyb@cybernetics.com> Subject: [PATCH v4 1/9] dmapool: fix boundary comparison To: Matthew Wilcox <willy@infradead.org>, Christoph Hellwig <hch@lst.de>, Marek Szyprowski <m.szyprowski@samsung.com>, "iommu@lists.linux-foundation.org" <iommu@lists.linux-foundation.org>, linux-mm@kvack.org X-ASG-Orig-Subj: [PATCH v4 1/9] dmapool: fix boundary comparison Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org> Message-ID: <acce3a38-9930-349d-5299-95d2aa5c47e4@cybernetics.com> Date: Mon, 12 Nov 2018 10:41:34 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Barracuda-Connect: UNKNOWN[10.157.1.126] X-Barracuda-Start-Time: 1542037294 X-Barracuda-Encrypted: DES-CBC3-SHA X-Barracuda-URL: https://10.157.1.122:443/cgi-mod/mark.cgi X-Barracuda-Scan-Msg-Size: 1451 X-Virus-Scanned: by bsmtpd at cybernetics.com X-Barracuda-BRTS-Status: 1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: <linux-mm.kvack.org> X-Virus-Scanned: ClamAV using ClamSMTP |
Series |
mpt3sas and dmapool scalability
|
expand
|
On Mon, Nov 12, 2018 at 10:41:34AM -0500, Tony Battersby wrote: > Fixes: e34f44b3517f ("pool: Improve memory usage for devices which can't cross boundaries") > Signed-off-by: Tony Battersby <tonyb@cybernetics.com> Acked-by: Matthew Wilcox <willy@infradead.org>
--- linux/mm/dmapool.c.orig 2018-08-01 17:57:04.000000000 -0400 +++ linux/mm/dmapool.c 2018-08-01 17:57:16.000000000 -0400 @@ -210,7 +210,7 @@ static void pool_initialise_page(struct do { unsigned int next = offset + pool->size; - if (unlikely((next + pool->size) >= next_boundary)) { + if (unlikely((next + pool->size) > next_boundary)) { next = next_boundary; next_boundary += pool->boundary; }
Fix the boundary comparison when constructing the list of free blocks for the case that 'size' is a power of two. Since 'boundary' is also a power of two, that would make 'boundary' a multiple of 'size', in which case a single block would never cross the boundary. This bug would cause some of the allocated memory to be wasted (but not leaked). Example: size = 512 boundary = 2048 allocation = 4096 Address range 0 - 511 512 - 1023 1024 - 1535 1536 - 2047 * 2048 - 2559 2560 - 3071 3072 - 3583 3584 - 4095 * Prior to this fix, the address ranges marked with "*" would not have been used even though they didn't cross the given boundary. Fixes: e34f44b3517f ("pool: Improve memory usage for devices which can't cross boundaries") Signed-off-by: Tony Battersby <tonyb@cybernetics.com> --- Even though I described this as a "fix", it does not seem important enough to Cc: stable from a strict reading of the stable kernel rules. IOW, it is not "bothering" anyone.