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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52701C27C4F for ; Fri, 21 Jun 2024 17:11:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6C4D8D0189; Fri, 21 Jun 2024 13:11:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1C098D017A; Fri, 21 Jun 2024 13:11:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE3298D0189; Fri, 21 Jun 2024 13:11:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A0D368D017A for ; Fri, 21 Jun 2024 13:11:02 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 50B1FC0F29 for ; Fri, 21 Jun 2024 17:11:02 +0000 (UTC) X-FDA: 82255535964.06.2B92482 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id 182DC12001D for ; Fri, 21 Jun 2024 17:10:59 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=K89Z1Stc; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718989849; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=JvaP3yUImKoEJB4PA2qjYp4jQe2QTVTiEvQRf0fiBM0=; b=ra/4aVWTimIXjR6qCOX3mQzm8tCATpiD5YAl746GF7OcJFrzCRM22VxkEDS3orPU4891nJ 0nkKROl8S5H4rH1eS5gICzTQDxd06gWopFSv/6mZ0EiuY7lT7zdKcsd0NOEhdNjJie6Wyy /bud+w9WnkBYrImsaQH0a5rCuEAHL+k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718989849; a=rsa-sha256; cv=none; b=v702nGDJlPQ8OgJ+W6z07WmiQLhHzs5kBNUJV+Vf+sknp/5wTOPVHupil0EN+2c/86m0hs sUMP8SvrAfrCGhvnUhlyy7XuPeFDpBJB+Gpfto7Aq70UVMeyFnKtUYbIex5TdD64EXDDcr 0X0t/QbDHce4YYwKZ/sKFYvCN0F4hkY= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=K89Z1Stc; spf=pass (imf29.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 32D3B6279C; Fri, 21 Jun 2024 17:10:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA1A5C2BBFC; Fri, 21 Jun 2024 17:10:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1718989858; bh=36XJikwAKK6KmWDfSywJ648SL2lg2Z9qjYfnPVDcV1c=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=K89Z1StcvmluPOeq5yneIeBLcDvRF6FVRbC9WdnFXiQB7ZfMRNchsla2N0b9Qtf/K MyQDA7nEDH0/QvL8RbxhkrSoohLVST+61fBB3LW/DgCAjm4unxkHBEDPWgrLZNS6iL tNv/eIIXPxwWtrqqqQ+PJR+ML6GY0bvVvRsKOUWM= Date: Fri, 21 Jun 2024 10:10:58 -0700 From: Andrew Morton To: Jan Kara Cc: , , Zach O'Keefe Subject: Re: [PATCH 2/2] mm: Avoid overflows in dirty throttling logic Message-Id: <20240621101058.afff9eb37e99fd48452599b7@linux-foundation.org> In-Reply-To: <20240621144246.11148-2-jack@suse.cz> References: <20240621144017.30993-1-jack@suse.cz> <20240621144246.11148-2-jack@suse.cz> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: rj53pbmbxpm5kxxui8i3h1h8up4db1bm X-Rspamd-Queue-Id: 182DC12001D X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1718989859-69610 X-HE-Meta: U2FsdGVkX1+njGO+G7OJKu9TJY5u8TVpwjPcnioyLDwUdJrsGHGXC9HLJix1oUwzfEW+fCPwp1yK9ED9DZScnmq1v+A010xxLZHRb1bmYAuBQf+8ArIajZrl6aXYmKJTSvo9rs91zNfdy94VCmlNleJhTevqHLmYCJ/H7hc4612sGogPSkKmRdhL5i/dHYmDW7gd9cTSGwIkhCeRqrMNqimTum5U55XiEJBrFrl34oPK5cJG6ZIcQWVjX5/O3LFJUK9m71AAuOSECPfQyJ+QWnzNUlIyfCc3ytxk5TjBqrOC5ccYNHh6wjgMGRwwUo6SqSpaALtfKRD1+mB4qLfTzs1CJwE49skortE6pfdPs/OdGI6m1EFb3xq/zKFO+G97SPNP5cxRTfX2qYJcmr+FI+z88XJGhkr6PLXcMGEutISgMfyflBoq6mdyoK6hQikcKV/dEB+XoKz4LllLzIm31lwv+uBgwZbN3YBqPve/obhvk5XJWgIYZXKqfmmQBQO5YcOnubpGn1SJy3nmyECpQUgs85fssEe//U1DGv9Hn1lOKyQKqe5SBfUh7YNLUjUAsxwYNe0z7JMKQYGkTsbRC6dBSATDCNIKUX0WEsAuvWoo77TX6K/vCOJUbSEjYF1mOIsWfFM9AqbWdoXVD928ALWnDO+hprHNhuvGSE11/G9zsrRqDmXxgNdihCda07bZL0WmWAYDMJ46LSyQyg/MmAPSgXBMsqeI6/EbOpD9mu3D3CiVS0pjVOUgVuMP7hXlaz4zV8TKZWa0WXl6vr66qZDExL/u7RTUC2hi6ZFIkOnw4YlXVYRfSRewT5S3H1/vQ7pAbW8ksQANGMDrOBOA7UxwxmAtygpL2FWJoqe2uwZsQOn1DirFEo4quEhZloaJf0xMUfBgGgGgAmGW1rg05mtw+DkTTqdpz2nlA8n565hX2SO2aR0plkNd/ay0BuP9ii5m2BYFscueBb6sQH2 PGhZf64a ybscvHsP+UYfXM9GUXwG1/KpHw0l9I/iSPEgvD1VD53ntHpnyIvJLTiKLfjBpltUpszxPgiHEGcy/C/T/UP+ddQga2kNHGSeXBX0/uh1ThJEnQlfdp7cEbsMkrhEvN0Q8Uf12fsUF9ZrOJl9b8ldclPbM9CEfFGqR1ZzNaYC8GO5ZOkwgIFMvXjVrtNb5pOO1y1AirAd7L+mc7735PzZbut28TUL9q8H5deMq X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, 21 Jun 2024 16:42:38 +0200 Jan Kara wrote: > The dirty throttling logic is interspersed with assumptions that dirty > limits in PAGE_SIZE units fit into 32-bit (so that various > multiplications fit into 64-bits). If limits end up being larger, we > will hit overflows, possible divisions by 0 etc. Fix these problems by > never allowing so large dirty limits as they have dubious practical > value anyway. For dirty_bytes / dirty_background_bytes interfaces we can > just refuse to set so large limits. For dirty_ratio / > dirty_background_ratio it isn't so simple as the dirty limit is computed > from the amount of available memory which can change due to memory > hotplug etc. So when converting dirty limits from ratios to numbers of > pages, we just don't allow the result to exceed UINT_MAX. > Shouldn't this also be cc:stable?