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 BA58EC7619A for ; Wed, 12 Apr 2023 16:12:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2BEE56B0074; Wed, 12 Apr 2023 12:12:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 27147900002; Wed, 12 Apr 2023 12:12:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 139726B0078; Wed, 12 Apr 2023 12:12:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 068A76B0074 for ; Wed, 12 Apr 2023 12:12:31 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BDF3116015F for ; Wed, 12 Apr 2023 16:12:30 +0000 (UTC) X-FDA: 80673231660.06.48C810F Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by imf05.hostedemail.com (Postfix) with ESMTP id 54A00100018 for ; Wed, 12 Apr 2023 16:12:27 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm3 header.b=iKpcflRs; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=CZtJsZzm; spf=pass (imf05.hostedemail.com: domain of shr@devkernel.io designates 64.147.123.20 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681315947; 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:dkim-signature; bh=iggGSzv6t6qQPSvLwa1Px6Q2AiO6aDZaux4wvq90NTY=; b=YyI1EprSp/g9uTH8q8ZiZEed1ZRUlR2Li/3AOXUZe8xOABwEAcmIDG7N/nd3dQa4noBhS4 HMFRLbvxtRebepP/CX9Gho5KbWshZfy4FPfoFhxRQKHY2nkehLrr85bRgHz1B/asPcLKJj ygSkzBi7ONaUtP/Y6xzrIr7IODTco0U= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=devkernel.io header.s=fm3 header.b=iKpcflRs; dkim=pass header.d=messagingengine.com header.s=fm3 header.b=CZtJsZzm; spf=pass (imf05.hostedemail.com: domain of shr@devkernel.io designates 64.147.123.20 as permitted sender) smtp.mailfrom=shr@devkernel.io; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681315947; a=rsa-sha256; cv=none; b=wIa+Ts9v85p43Xi6TfSU99hiiLGSkQXZ1j7RARdS4PAuJhGEcWau6hEbO7RoMDS0VBtGh6 OWSedLrY5P6/BrPN9GjmK47qS63jpEr5IjCfCULCU96OVUahIh3bMYbYg1BWIY/SKpd7dF huG/OoQfCJMfmh8RgxQjnJZw+2Roxpk= Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 0360132006F2; Wed, 12 Apr 2023 12:12:24 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 12 Apr 2023 12:12:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devkernel.io; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1681315944; x=1681402344; bh=ig gGSzv6t6qQPSvLwa1Px6Q2AiO6aDZaux4wvq90NTY=; b=iKpcflRslOThbWi/Am 8zvAfFAlarv3e/sa1xLbmEZpnOKZrUsGYJo6KL3dqycsM1XJ2lJtAtsaJ+157anY kA42IMrRwEtW17h9x+4lom1dOXtNaFnM+xHx+ToH4DgaRVhRlihzcfclaVvdPBa+ TJ3D6ZyT2/VsAHHbw82FAwpUhLwZZH5w+LtbUqSgeRvTHYVaZn/aFkc3ycSEkIKt FphMD1JMUbb5MRVtlMPgZtbMV7Bhk+eK8zzR010hJwcFemopSHy8ynQQvKGaRYFm EBmn1Fck6qyeezSpaWP0wxLBZdQFsqxMkpMGSAzj1ho5P6NdiEVqJ/40jEu/Q/mN dkGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1681315944; x=1681402344; bh=iggGSzv6t6qQP SvLwa1Px6Q2AiO6aDZaux4wvq90NTY=; b=CZtJsZzmFLwcDDvYHzZnrK2nKJqjO CqAgG4uUXntYX2WcxmBF3uWm0mKUqHOntpG448b6sPSCQdPR7Hcm5lPvKq/+Od30 Km8Jzt8Kk8eJWpUOuCdcBCl9NdhFETxJhX0k3Lf3pzHspR8jo9OO2F/MFmOOU5lJ lqZkrZEfEJSZ0yyMWGN1zyAJa2eMgirToJ8Rg1+V8Ox51tCxkFXbH6zDZVpAk8pc rf5tAD+XszCd42e7zbNQsEMPqEpCYqxlFwambLD7pm7xD6X7jEGotSXVALMIBTql vsQDI8bqQup446nXWZmBvCXLO9hjSvVEdRmVYxvspvSxHmNHfK5OfdL5g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekiedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehffgfhvfevufffjgfkgggtsehttd ertddtredtnecuhfhrohhmpefuthgvfhgrnhcutfhovghstghhuceoshhhrhesuggvvhhk vghrnhgvlhdrihhoqeenucggtffrrghtthgvrhhnpeevlefggffhheduiedtheejveehtd fhtedvhfeludetvdegieekgeeggfdugeeutdenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehshhhrseguvghvkhgvrhhnvghlrdhioh X-ME-Proxy: Feedback-ID: i84614614:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 12 Apr 2023 12:12:22 -0400 (EDT) References: <20230412031648.2206875-1-shr@devkernel.io> <20230412031648.2206875-2-shr@devkernel.io> User-agent: mu4e 1.10.1; emacs 28.2.50 From: Stefan Roesch To: Matthew Wilcox Cc: kernel-team@fb.com, linux-mm@kvack.org, riel@surriel.com, mhocko@suse.com, david@redhat.com, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, akpm@linux-foundation.org, hannes@cmpxchg.org, Bagas Sanjaya Subject: Re: [PATCH v6 1/3] mm: add new api to enable ksm per process Date: Wed, 12 Apr 2023 09:08:11 -0700 In-reply-to: Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 54A00100018 X-Stat-Signature: 3rgmopwnnh6i33cinwjqgesxn17pqzpx X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1681315947-115417 X-HE-Meta: U2FsdGVkX185V9qDWmoGipd5zXecHBs1EaZysy+WsZY7Qomo1GeYu/00GYkbYM5mcJKRiXbkOHx/ZtOMoU7XbFB8vyAy0R1mrEZDiHErD0BWyBtPE1S+PIs0QLWcuJ4HW73es3+lTTgSoi4n6qKVBaDG6EAe06oB+UGYzHGL+SNQDOL0iYZiI07efxLfhjAugGKHdRAR1pSDIecFw70I44ExmEThIPanCRwInyrecg7MiQxdQVZ7OvV6iCjwa9A+dug7Dk/5hX2U0atW0V9Zt82hSWjwxZmFC0fIEApDaT7ux8jFg/Ws/+hoZeJig2dDbT08iHBWIHxNkb7uofV0VKQsepqgGnLpsfVKUIkGyPpx+uckLoPd4Z/9bnNoiIUAjscBM4ok7WUPKjGijngiqvgeXNsY+bsSufn+25MKTG0zsvpwAAA+HYZAqikKtn3QETysTMngVuq8R4GfncT26EWCtYRFN2f7ftBpsJuMz6lpxx9nz/IjdjK+eJBm4atgK70L4BHGUQYWGC/GJWdAOMvTB3oEE5/GBd+xvALSo+iOpbksSTJOpeP08QzrFSy6gcBqIdX9cvLXL5B+A9qk+TWEYFl/iKrBkgUioUZmQpRf3GF+pbYXUCGmgtH+P4XZ0lr0fYHLPSGUBZzvo7IJ3i8f2bcc5QURKEXnpLt/NoomgO6aB6CGFGef0k81g5GKxH+8VMoH8FybLd8ypqbP7mAvpOdak4K1fr7tjY7awpbqX4neUnkJZXa+JkP6NgEZIZXh+QP207aUNJpJzxXz2PmhLcHpZkSzo6eg2PWo13p1HLHRfTI+uw4ehnnU/cZkM1T5YvTHwttsmJBw8Sy89yB2a5t+yf9Bs7jRjzyDNB4lO6hfTYNbXkF2iFEjSS0D2t3ICJA4VxZYNPt7q9UWDZzY0kPf2sFDKPJPRo8FbtKbcUubFk9T1poqx2JPpiFjNyMd9XfPU9bsCKUC3+u j5cZiR/i DPev6qTMKx8TIz3d2+V4G5UHM3bNewib6HnFpZt89NFv8YSM/ZmqfhosHVbevRuQCQNQjAsB3y9DqSQJhoU4gPC6oR9EMMsHTH9sdkIXEHvL5e3dTbAEQPPNAkwBQM4/L2Vb9tYTvguSVSU7SFkd+40x/2uSF7JS/Q7o2kknJg9/TJGXRLVbS7MrOUyxKMB2+yexaCbyIZhapyK0= 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: Matthew Wilcox writes: > On Tue, Apr 11, 2023 at 08:16:46PM -0700, Stefan Roesch wrote: >> case PR_SET_VMA: >> error = prctl_set_vma(arg2, arg3, arg4, arg5); >> break; >> +#ifdef CONFIG_KSM >> + case PR_SET_MEMORY_MERGE: >> + if (mmap_write_lock_killable(me->mm)) >> + return -EINTR; >> + >> + if (arg2) { >> + int err = ksm_add_mm(me->mm); >> + >> + if (!err) >> + ksm_add_vmas(me->mm); > > in the last version of this patch, you reported the error. Now you > swallow the error. I have no idea which is correct, but you've > changed the behaviour without explaining it, so I assume it's wrong. > I don't see how the error is swallowed in the arg2 case. If there is an error ksm_add_vmas is not executedd and at the end of the function the error is returned. Am I missing something? >> + } else { >> + clear_bit(MMF_VM_MERGE_ANY, &me->mm->flags); >> + } >> + mmap_write_unlock(me->mm); >> + break; >> + case PR_GET_MEMORY_MERGE: >> + if (arg2 || arg3 || arg4 || arg5) >> + return -EINVAL; >> + >> + error = !!test_bit(MMF_VM_MERGE_ANY, &me->mm->flags); >> + break; > > Why do we need a GET? Just for symmetry, or is there an actual need for > it? There are three reasons: - For symmetry - The ksm sharing is inherited by child processes. This allows the test programs to verify that this is working. - For child processes it might be useful to have the ability to check if ksm sharing has been enabled