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 00474C3ABDD for ; Sat, 17 May 2025 20:25:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8458F6B0085; Sat, 17 May 2025 16:25:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7CD066B0088; Sat, 17 May 2025 16:25:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66EF06B0089; Sat, 17 May 2025 16:25:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 45A726B0085 for ; Sat, 17 May 2025 16:25:30 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CCEE3121210 for ; Sat, 17 May 2025 20:25:31 +0000 (UTC) X-FDA: 83453530062.10.E28369E Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf06.hostedemail.com (Postfix) with ESMTP id 3C3F5180003 for ; Sat, 17 May 2025 20:25:30 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FHN5K+e3; spf=pass (imf06.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747513530; a=rsa-sha256; cv=none; b=LynJA3ZmSJVlO9FTcYxHsX71hL+t9K75C/dL4nTI26axlO0tvZ/9YEoVZUQ9uD3exLMGIW WB5mPpQV37iqfsUaqaua8KY83Go7uzzCyfsxhaapUxAjRPmQ/qaxRRkKzF5hN7e2o0XW4U pp+NHv56OiG9B8OcXOeS5VXQ9xJACo4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FHN5K+e3; spf=pass (imf06.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747513530; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=2jUG574Da1Wt2i6F/T2he7oKOzkeDZ8Y9dUX/RlMo6M=; b=C4sYSRyv0Z84wD02RWvftprxc92s9NOuxa8PPgXKSVdQD+R2u33qetTsNtf8leZ2YJtnaG sYx6RXeTbA2tk+J61BEZn96WRZtocq1TZWW/AWf9RCHSyysE2YudalrgjB7msJyg0M5NkR nXETeVs3VGO8Awf+Qdvz9Z+iTwyFkzo= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 6ED2CA4E91E; Sat, 17 May 2025 20:25:29 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E201EC4CEE3; Sat, 17 May 2025 20:25:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1747513529; bh=q/+LJzWV//jJOpKwrMia7KlW4iMjaB4bjxmcmW7qiw0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FHN5K+e3zuEN/BDoe9RC8m3AEMhJKFPcFc2TF8QUouNHFZ4jPXTmHB6dJM0nw7zN+ HdS9ZZGfCiaFPrf1rbHbkiIxPuDkhWD1UQ8xUNt4djb2gZiPhge0uT/cwP8wCz0sfE K1oTJGXqfprP2UU229Nl6tSNYxvlPfCkiApc1AxuPJvi1eBp47dAKzKiP7E5rjiefW lqe4sXol5lzO+WnM7FJW+KkVUy+rNrBzpZTZ1Gjcp1nD2MiNK+eWam0Z+rZYyMoZdn fjnhkwL7azFvIlqNg2Ckke0W10sOi8dIJGlPB9Gi5uqCQUI21nSuA6r8waTyjyoeeG VOYL0e5stpqMw== From: SeongJae Park To: Lorenzo Stoakes Cc: SeongJae Park , David Hildenbrand , Usama Arif , Andrew Morton , linux-mm@kvack.org, hannes@cmpxchg.org, shakeel.butt@linux.dev, riel@surriel.com, ziy@nvidia.com, laoar.shao@gmail.com, baolin.wang@linux.alibaba.com, Liam.Howlett@oracle.com, npache@redhat.com, ryan.roberts@arm.com, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, kernel-team@meta.com Subject: Re: Is number of process_madvise()-able ranges limited to 8? (was Re: [PATCH 1/6] prctl: introduce PR_THP_POLICY_DEFAULT_HUGE for the process) Date: Sat, 17 May 2025 13:25:26 -0700 Message-Id: <20250517202526.39730-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <005161f7-d849-41a9-8350-f56e52c49e7e@lucifer.local> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 3C3F5180003 X-Stat-Signature: fyq7sxq16nsetpiwoardqsnjnzsaxtn9 X-HE-Tag: 1747513530-589888 X-HE-Meta: U2FsdGVkX19ErYEzDcpnHOlCXujjRJAVg7JX9PPgYOAfdYmC/MJfEX01yvAr9rK1GLvlYa3k4FsYJkH+ffDQlAMblG1g7IOLhNTFWJTfsrMNPTHLLwfj0BSydPfUjBMWnjxA6lsi4xdWkGCTTnbzShwvt+b2hPnZQU2KqZauvH6H0aJ/McZSwCld3qB3Vc2qan+MZTMZNouMZORex3jI51sPe7BBOPCI04akY6wrYVAaQDkBK2ejg1WO0XbZZT/9hkI3vgGMDjixd+jtIPWSIKxohxzsm70agF1LHHyDaIiydbGKVhb6Iiy5h5MIUZYjGb88l+9x156723ZPYn+DNDPnaB58iQExT5Sd2KHeJ74CN6GavZx7oqzxN2N5/tIzF80nTMT1gWtw4J5soD4+zwmEeWLj7ee8QUwEzo08Twr176OsmHg4pXbyQS3y9cjcUNFRDtLjkBemeh1KFSiDVetDRgJArPWHXNFjyfVUHLfsp9UNoIWUIA58DGoMc20/auM/xZbTI8C67fKGb8kTJcjWtLMvUD8MXhU5cISgqL5DNVbacEd5AyuTuTIUiG8OigqbzEPt3zGZ4ufddJ8jRXGFNBL3XfoymftGzzO5F3s+nJhpkEIRZWtHY2Pgc3SIpt1VmkX+VBUezGymZiho56zx5eYqzvqA83E7syYFTzwir813ft8i4I4PRwiOYgPKEzwxKHM8Y+9+vhky+/yy9pA0q+HFeNAc7YirECVAF9as5zSOT9hZOAzYv1jXw/XWao9VqJ/br/Vwp35Wr076uU5BYib2+3wSbMG4sMu3WmlOlcOlUhuowXDSCcXUDROAUuOunDAuEeCrfVuGSHw9P2i65Kne0YGWFm1Yfs29nEpkLtOKFfHcO+iuCkS4uVK2XhSQORI+CsO/WKOYVUKcc4Ycf8BACYqopG+D61rq0r8IZ1tnaKUhugfGg+7+81nrNLOSfQ5+m02x3xkr9ze gbTsXEwZ UCv+qprPDoQgjIRhSL/xwfURO2G7HfSpynFIVdwdX6c2wNFT4H3GwVR3gcnxQam9hW2c7SYXkJXMJnVieizHN7mJxU3MOEESihwT0NBfzDo3/dSxFauH3QIIuLi/wgX1ApTpD2YV+6gpfqUf/U+oxYh/B6ym2uVXUmDS0NYXddNbQ/kw1xIaSG7ygiRhJA+dzeyres3pjX7+GUb444iDHWM+HEwU2O+z3kcQqeavdE1AZC2X1o6cuMf8HPERGOGxngPDbDqKkppOWouIhAD8e63+qcd6KSPHcqWEqmVzX5EOjtiZd5+5UCr38AM2isgeJj74sL0f6kf44HAYVnNZS/jR5J56Uxuakr77GzUN/AS6/4G70052gUbC3pFd3Zg6xM0uY84gjDIInU2S+RgiQOV0qWB+vNnbe4MNwvEHhTezXfx0= 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: List-Subscribe: List-Unsubscribe: On Sat, 17 May 2025 19:50:34 +0100 Lorenzo Stoakes wrote: [...] > Let's keep this simple - I'm just wrong here :) apologies, entirely my > fault. No worry, appreciate your kind and detailed answer. [...] > Anyway, let's dig into the code to get things right: [...] > So - this confirms it - we're fine, it just tries to use the stack-based > array if it can - otherwise it kmalloc()'s. > > Of course, UIO_MAXIOV remains the _actual_ hard limit (hardcoded to 1,024 > in include/uapi/linux/uio.h). Thanks for kind clarifications. All your explanations perfectly matches with my understanding. I'm happy to be on the same page with you! > > The other points I made about the proposed interface remain, but I won't go > into more detail as we are obviously lacking that context here. > > Thanks for bringing this up and correcting my misinterpretation, as well as > providing the below repro code, and let's revisit your old series... but on > Monday :) Sure, and no worry, take your time :) > > I should really not be looking at work mail on a Saturday (mea culpa, once > again... :) I hope your remaining weekend be calm and uninterruptable. Keeping you not burned out is important for the community :) > > One small nit in the repro code below (hey I'm a kernel dev, can't help > myself... ;) To me, being a kernel programmer rather than a user-space c code programmer is a good excuse for asking to be generous to my user-space bugs ;) Thank you for your kind comment below, anyway :) > > Cheers, Lorenzo > > > > > Attaching my test code below. You could simply run it as below. > > > > gcc test.c && ./a.out > > > > ==== Attachment 0 (test.c) ==== [...] > > ret = syscall(SYS_process_madvise, pidfd, vec, NR_PAGES, > > MADV_DONTNEED, 0); > > if (ret != MMAP_SZ) { > > printf("process_madvise fail\n"); > > return -1; > > } > > To be pedantic, you are really only checking to see if an error was > returned, in theory no error might have been returned but the operation > might have not proceeded, so a more proper check here would be to populated > the anon memory with non-zero data, then check afterwards that it's zeroed. > > Given this outcome would probably imply iovec issues, it's not likely, but > to really assert the point you'd probably want to do that! Good points! I once considered making this test better and posting to be included in mm selftests, but found no time to do that so far. Above input must be very helpful in a case that I (or someone else) find a time to write such process_madvise() selftest. Thanks, SJ [...]