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 C26D3C7EE23 for ; Tue, 23 May 2023 13:10:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E30196B0074; Tue, 23 May 2023 09:10:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DE07D6B0075; Tue, 23 May 2023 09:10:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA77F900002; Tue, 23 May 2023 09:10:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id B964D6B0074 for ; Tue, 23 May 2023 09:10:33 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 924A4C0546 for ; Tue, 23 May 2023 13:10:33 +0000 (UTC) X-FDA: 80821553946.11.EAD217F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf22.hostedemail.com (Postfix) with ESMTP id 2C4F5C02D2 for ; Tue, 23 May 2023 13:08:02 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf22.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684847283; a=rsa-sha256; cv=none; b=sW7yOH+PFXtizRJhA4oc+6qN4Zo26bXwKtfe8V0+S/mw5/elfDfZZ5IEc6xG/Qi7vBYsYC g/JvNP5q1B4boLDJ2kFytlWv4N7aWdM/r9ivHxxDwjK9tIQt7uK5f7m01z8Wk5Wwu1zD2m PKA2C7SW4eMtWdax6A+YnzbetksMn7Y= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none); spf=pass (imf22.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684847283; 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: in-reply-to:in-reply-to:references:references; bh=jL7/XByFM774I9rrb8eZqb+0SKwaIo2cZ+YkazPUvUw=; b=fycXToSpLImgs+sQWJ/MzInIrS4qpl/dyN/Y9gIGUH5uYRRqUN49KDzQzAUUPIdrMfzHdN K1tB7SnNoysdE8XCKNdW/zbeNTHfP9XOt/rqIS/S5CDCH991Xcb3VvSR4kzJdHR/q7UAnG K3bglr2CcUi9aceJEFn/uHMJ1P5RpBM= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id B00C363236; Tue, 23 May 2023 13:08:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63831C433D2; Tue, 23 May 2023 13:07:58 +0000 (UTC) Date: Tue, 23 May 2023 14:07:55 +0100 From: Catalin Marinas To: David Hildenbrand Cc: Alexey Izbyshev , Florent Revest , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, anshuman.khandual@arm.com, joey.gouly@arm.com, mhocko@suse.com, keescook@chromium.org, peterx@redhat.com, broonie@kernel.org, szabolcs.nagy@arm.com, kpsingh@kernel.org, gthelen@google.com, toiwoton@gmail.com Subject: Re: [PATCH v2 3/5] mm: Make PR_MDWE_REFUSE_EXEC_GAIN an unsigned long Message-ID: References: <20230517150321.2890206-1-revest@chromium.org> <20230517150321.2890206-4-revest@chromium.org> <884d131bbc28ebfa0b729176e6415269@ispras.ru> <3c2e210b75bd56909322e8a3e5086d91@ispras.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 2C4F5C02D2 X-Stat-Signature: 1diako4x87kk9hxn691eunjg4gg9hh8f X-Rspam-User: X-HE-Tag: 1684847282-455400 X-HE-Meta: U2FsdGVkX1/ul/ykqLpmBzf3FFI0LoxXbe8WJ3TsRBc4mFPLyfJWcLWwHs4LiF3qkBbPc0kvj0L4NCxpbV8GkbQY+tB5skdQawtYHXYlw/CuQWcVMoUd3aLUaQBuMzI7BkPeqVMJIegbIJVFmBApF0IGrTNx/ziYHPJtLVMX3LgSV5Fyh/fRQLo0eLAJkho/D3foPTD+l3lIG9/QlnVcrFMU0JWVfuq9lYTIpSAYO7IRcsdFuQ96fFUOUSjVNopgU44BN4Cki/9ARyf3x3gZCp5cC7UMGvYnPA9kccbMv5RE4R3aiGJ0gwLSod3s7Pvawoq8deC454lzsnoMkZfVTEg0OUrexlzOLCnzr1Ez8dxf/hn8O9h5tfkWKgG4zDy8XhoEqV/k45ACgKOh99wq0BkOqrTIc3v9ou7mqi6zqACk3QmEDt4jPPac/34Qi0entsnSGgWVTF59qovtvEK0KU6O5DmF6Yr1RKEuomMGLLhKP/RnPzubKKSe+hjKIzZhaR3kl9CMUH7NJIx+ug07Cp8A6Q3HbJBpZ3dTmvP7ZqE/R+pok5jJv6RYdp2in0asV9ajJBF+7OJsHjIFff4bce1johmeCvL2j8N2RKdga27ECVAiLIuMrLtpj+8HnY3x4FNhACNlb6nTt0Vb6ItR5vfwjDspAluCP76iz9NQKUyXYLUTiaWaYPkYpmlMOPKDKJ+98WOg3geqNTCE/zq7I+HSFxDfA915YwilgNZPQKZQ3Ky7NlvYiDrcShY90gU0Qg9lI6h5kVqNmMZdqg8xA9nEwuh4Ce0bJr92ex5lcACj0VPc1psVs9R0kGJPRe/9n2fmYEiZIlq99+TuuLuy1EkfVXsdV7gXYVK/RFFiCXTy0WcB/knL1BRuQtWQt/OEHS4pLYcHhJA7gnwQSSgybDaJPOcdRhf9e324jYONk1jWI6SC8kkGXQNHs+LyFSqEQIrWoxQ4nurbR/bqzA+ a1aJRHxC g9x2mQqMRReKT0gcboKbo9Bm4rnf0E4JiDpgT6j0qEMxubkSVzNdwyB/XdE7TTifsl3WbKWByXYEiBIbc3ewGZaNKmju+D6WZ+tYhl+FV7B39NUuf6ylbobd4Aa94/Eg5xyCUwcxB3qXRtqykpSTu9MnOz6H7wfW9T68aTlXN6bWkJsNWzJ5XeR5yVO57C5dsJpO6mgs7vM2u5Anj4JpQvXadeZzczhXK9+OL7CUCJ+5Do9LZXrhufHT/lJJQVSrdWPnJ5yENiIZqGeVL5lVYFpN6d+EGVmfOvNAe396rVM1UrsC6gAtIi4aXIwuB0Fy9x/LyqUqZBeEiSxC53AywbG0lWAtTTOnPPwnBSEy0s5V2sT1YveLwFzE7gv2v9ohFfcdIUJesFOeca9YO+T9g4+rYoYfL6b8eHMEdLks5pX4mql9XpiwJnPLRuWZ+jlZyq/oAfQ7vQJm1r/sPveqsX2dQcg== 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: On Tue, May 23, 2023 at 11:12:37AM +0200, David Hildenbrand wrote: > Also, how is passing "0"s to e.g., PR_GET_THP_DISABLE reliable? We need arg2 > -> arg5 to be 0. But wouldn't the following also just pass a 0 "int" ? > > prctl(PR_GET_THP_DISABLE, 0, 0, 0, 0) > > I'm easily confused by such (va_args) things, so sorry for the dummy > questions. Isn't the prctl() prototype in the user headers defined with the first argument as int while the rest as unsigned long? At least from the man page: int prctl(int option, unsigned long arg2, unsigned long arg3, unsigned long arg4, unsigned long arg5); So there are no va_args tricks (which confuse me as well). Any int passed to arg[2-5] would be converted by the compiler to an unsigned long before being passed to the kernel. So I think the change in this patch is harmless as the conversion is happening anyway. (well, unless I completely missed what the problem is) -- Catalin