From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f50.google.com (mail-wr1-f50.google.com [209.85.221.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 04D98302152 for ; Thu, 20 Nov 2025 09:59:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763632793; cv=none; b=YVv6ZxT4H9pAuott1l7c7PbatqIxbBFiw8/iyekaGtCAW8ZW4yAGW1elRTLaSL/zNS9+/svJbWXA+RjJJjD+qInBewHV3xzWJ2My7T0xdOo4keNWAXMa9OcqtbnisOZa4q2VqVWvQhkujV+5vHFGnJ6hguE+g8h/CSNcG2RU62E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763632793; c=relaxed/simple; bh=JQ3dbdJcaslzlpWIv88Ans2DZ8nJsLv01H4PUnHDFC4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lyi5tj1nOCRVJv7MDLbwF/SyVQcvIWxZYh+160eWCza8rMn8FcNkGEKRW3iSvJV62FGB9ArDpZhQRj/5ePR14zhPkVfa5xZTnMer1CBrkrLuKdrUWJWVXYyULl7inth+MMkcoM/HI2QCllADXjgTKM8Nok+uGopU6vFjdbAm8w4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=W66DEFEN; arc=none smtp.client-ip=209.85.221.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="W66DEFEN" Received: by mail-wr1-f50.google.com with SMTP id ffacd0b85a97d-42b3c965ca9so378925f8f.1 for ; Thu, 20 Nov 2025 01:59:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763632790; x=1764237590; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=mIODWrR7kj2FgENfGTn8a1wuC0pEHeF2hG1nTUsyQa8=; b=W66DEFENV2ozE2i7Y9L2UMB9ryFW1JNAyNhkTkPxh4pr0F1S5R/ELSJgoLyrc0xA5h jWVdqDIgBheW4vCFwh082WBcQV5MiPfPoj+qeEsMKjVW8Res7EfJN1XxhLubsF8AKj3m HK3hnwqSG4qmSDJV+jCopc6N6pRIVlLGxzLfFZcC1RiNiHwaXKWSMtQnlau0Fzh0gVGY nMrGkq2chYgQEZYiYD7JZ9hhPkC/RHWs8MhLcQ6zK7JeSEfXQLbhnC7TtMcnTsevBv34 InVQleriGIO6N0jqF5cuj80lG/G43umz5tfbKQHP/BcVu2OgfnlzaEZ1OGeuSJM50f+F gCPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763632790; x=1764237590; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=mIODWrR7kj2FgENfGTn8a1wuC0pEHeF2hG1nTUsyQa8=; b=k2ZCNvr5SpWZvC0Qx1pX0JTXfOaJwyockfG+aoAid4so+H00S5xdtRFetijmYNMyhb Mf7eygy8Va9f6G+fBdYOjx6f0AGuYBBFd1GKg6ig61QAF+PhxVXis+ZoHyIOFE04SFZm Aq/JRyca6arLqqyKdDWxqRb5Wezjerdei5lMJ/j5ltwJbjuN+S7rbNoLhdjUvuN3Gwwd mnyty/z+JfNvcLiJwHUVk01u8rC/1MvJ4qZYfIl497eneZfWQzzhO+J5J72BN28jXsXl SUYpb0Mkq6oTMJYa7NU+BbjC+tmqb/S1UiI9jK3X3D8heCFTB+FNz1IGI2Esy0SxK3KP LmDg== X-Gm-Message-State: AOJu0YxCq8hoesVjYWQQCl41DFCCJ2uhTjE0ifxC0QmCan0ZNwAofdzn grxHK6E6vofQ0zFkOM6IWpAqObehvWPpLPQZ6JRtH0mAdZdD74xBTnNh X-Gm-Gg: ASbGncufrwYpjAQT0qtG1q5URaPlRzk9599A1JUozN15d5bS0i0qO4dBhNQBTXVQE0D 71wZXfifVIak/rhC2E1lpjqmFSwQr/52/AhEExdxrB3nZ3CbSLab+TtYbXoumeG+ONJq0A+PyRb 4y15/Jj2WNAMXfjbamMekFl2kJR6rdaD8Odyrf7O5OiryeuTvS8wE0GuRPbb7tVlDJF5h4XP5Sw 57i2BWTCG97LzuZbeIW7pAtbXMS5xi8ImKz15Ga6ON6Qk4CChjOc8fI5AlUioiXxq9vl/RJ+21I rFYslj92kzAdh2H/YVOo1rnzlnUU6p/RRjv9wBrX9PcpWsB7WaOGQQZUO+9o+yfNAPg6qNRX1OP ceLXGUyofxuiRuA3ejg2b1pn/7KPErgNnd2x6mVY/GepB3o0XP4PsRJgRe3IEKxmhKHPxZw9Al1 iEfvKOX+rY5/QjtFR/kUGsX9SiBtLXBDdsaRHuUlPU9mFOxzXifcwMx9KkoGyDzKw= X-Google-Smtp-Source: AGHT+IG37lZw7UpcsHmGZ/1ewOEV2psrqqY4t9wOw/ImHxPGIdO3yYJVfl/Q35dOCEa9SiO9Kt9qOQ== X-Received: by 2002:a05:6000:1787:b0:42b:5567:857f with SMTP id ffacd0b85a97d-42cbb2b1d24mr1644470f8f.50.1763632790127; Thu, 20 Nov 2025 01:59:50 -0800 (PST) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-42cb7f2e5b6sm4429203f8f.1.2025.11.20.01.59.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Nov 2025 01:59:49 -0800 (PST) Date: Thu, 20 Nov 2025 09:59:46 +0000 From: David Laight To: "David Hildenbrand (Red Hat)" Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Axel Rasmussen , Christoph Lameter , Dennis Zhou , Johannes Weiner , "Matthew Wilcox (Oracle)" , Mike Rapoport , Tejun Heo , Yuanchu Xie Subject: Re: [PATCH 39/44] mm: use min() instead of min_t() Message-ID: <20251120095946.2da34be9@pumpkin> In-Reply-To: <7430fd6f-ead2-4ff8-8329-0c0875a39611@kernel.org> References: <20251119224140.8616-1-david.laight.linux@gmail.com> <20251119224140.8616-40-david.laight.linux@gmail.com> <7430fd6f-ead2-4ff8-8329-0c0875a39611@kernel.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 20 Nov 2025 10:20:41 +0100 "David Hildenbrand (Red Hat)" wrote: > On 11/19/25 23:41, david.laight.linux@gmail.com wrote: > > From: David Laight > > > > min_t(unsigned int, a, b) casts an 'unsigned long' to 'unsigned int'. > > Use min(a, b) instead as it promotes any 'unsigned int' to 'unsigned long' > > and so cannot discard significant bits. > > I thought using min() was frowned upon and we were supposed to use > min_t() instead to make it clear which type we want to use. I'm not sure that was ever true. min_t() is just an accident waiting to happen. (and I found a few of them, the worst are in sched/fair.c) Most of the min_t() are there because of the rather overzealous type check that used to be in min(). But even then it would really be better to explicitly cast one of the parameters to min(), so min_t(T, a, b) => min(a, (T)b). Then it becomes rather more obvious that min_t(u8, x->m_u8, expr) is going mask off the high bits of 'expr'. > Do I misremember or have things changed? > > Wasn't there a checkpatch warning that states exactly that? There is one that suggests min_t() - it ought to be nuked. The real fix is to backtrack the types so there isn't an error. min_t() ought to be a 'last resort' and a single cast is better. With the relaxed checks in min() most of the min_t() can just be replaced by min(), even this is ok: int len = fun(); if (len < 0) return; count = min(len, sizeof(T)); I did look at the history of min() and min_t(). IIRC some of the networking code had a real function min() with 'unsigned int' arguments. This was moved to a common header, changed to a #define and had a type added - so min(T, a, b). Pretty much immediately that was renamed min_t() and min() added that accepted any type - but checked the types of 'a' and 'b' exactly matched. Code was then changed (over the years) to use min(), but in many cases the types didn't quite match - so min_t() was used a lot. I keep spotting new commits that pass too small a type to min_t(). So this is the start of a '5 year' campaign to nuke min_t() (et al). David