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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCAB9C77B6E for ; Wed, 12 Apr 2023 16:12:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229983AbjDLQMh (ORCPT ); Wed, 12 Apr 2023 12:12:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40778 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229899AbjDLQMd (ORCPT ); Wed, 12 Apr 2023 12:12:33 -0400 Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FD448A5F; Wed, 12 Apr 2023 09:12:28 -0700 (PDT) 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 Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org 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