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 BB8F4C4167B for ; Wed, 6 Dec 2023 10:30:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5814C6B0088; Wed, 6 Dec 2023 05:30:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5069E6B0092; Wed, 6 Dec 2023 05:30:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A79D6B0095; Wed, 6 Dec 2023 05:30:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 252D86B0088 for ; Wed, 6 Dec 2023 05:30:44 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id E36BE40173 for ; Wed, 6 Dec 2023 10:30:43 +0000 (UTC) X-FDA: 81536024766.02.8EA939A Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf19.hostedemail.com (Postfix) with ESMTP id 10BE11A001D for ; Wed, 6 Dec 2023 10:30:41 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NOtNcUDY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701858642; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oJAfBJe//jMp144Bh2ybimjx6ISuOne+BJIc9JPDue0=; b=Qym8QYtSaphQ2WQpPAlpOFeEsbIdM8In0cXEDjXlQ8Uug7KtJdt80JMVwf8vvJRwR67g3C 2W1Z7m94YXxIOd1VLfxrbs2lh3DXRZJ+54VU766EdU6EnEqiz2Ie75XzUXbsMjLaxPHT+E CwXg29jyJxX6zNmiVfZZw20pVO3tqaU= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=NOtNcUDY; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of surenb@google.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701858642; a=rsa-sha256; cv=none; b=PF5eMz0ID9rm2ZWtSEMshGYtmXmuuTV1GByOFHflCDft/ZgKUowlE5aYHPodZ/OTS3l2mt 8Vg63nP84Zt48n1mmMSqyRbWKtIc/PWF6IB0723GxYoDtx903jmeMNgSA6G8ttVgGa/7oG gs8Plo45ahWH9qT+GKgfVzCWfoPZB+M= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-da7ea62e76cso5336158276.3 for ; Wed, 06 Dec 2023 02:30:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701858641; x=1702463441; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=oJAfBJe//jMp144Bh2ybimjx6ISuOne+BJIc9JPDue0=; b=NOtNcUDYD1UQCIgZ2dYHd36WLg6CR6vP8PCOZZtjJIk59Fvz607e3v2mdAFFS+3fPe SXJV6rNjr30urW5wCN/yPP/yzmCeIVxh48OWHy9LV2gGEz5wNvaXehKj2qEhP62TzwPA HXlV241+8Hp8fqJA/pLe7/0GnCTvKgVgyLtEDFWc734Lg4QaDEVU5DLnwXk1hELEVfMn PmMK3mvxW8uIyJeeuL+IPIZd55h17nYczES8brkrjUaB5clsBKEADYjMCiJpQHTDGIL1 SLf1d+L+nFYH5HMGBQQMKCZtK+nP0ffp1fNl3PPLVIbiAsBe8/tfsdDb4TeTIXwHd+j6 KNXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701858641; x=1702463441; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=oJAfBJe//jMp144Bh2ybimjx6ISuOne+BJIc9JPDue0=; b=qu2Vk/OQzC1kLnOAkP4dkg+K7WghPOOzRjeTkRL8RdgPqaoYdOqWdX2nnNhSob7O8r 5FYru2BwpF3fLfDeDiVJXvfHO6dY1loAMb5XQqTtcXRE08pjwrm9MisxjtXsquEjLuo2 JAdEMAcHYqcrSEN3soFFxHKol5xtqTpeVBqQTqSQxLOsbxMMC+TSg5L/ZCAY8ppvoqpW UcbJIbK7GCpptj/BgNf44c4FFK638kk6/LFpKcTA86zpFB1tAITGrx1l9FEeA+rLaalO PcUh/a2T2yTNOFncZMWwKfIQQpWbBeDjPr3iAtoTvzwcpVdC1ZxafGG8P6hnyMI+7Ngi wN4g== X-Gm-Message-State: AOJu0YwtsA6jiHL1fGi92vDvk9+9FUobnxfd1UaTJZymnV1JMD9ixYHp rveeueyG2Rq+gx45MAN2oEPbi2X/JTtu5UKkF/oOJw== X-Google-Smtp-Source: AGHT+IFsrLqiAiOECeAi7vlVllrb2MVHSSJ0Sh4PmyzU4danP7PT/4yH1PAFrlzNyaMRm/sQgpHe+/mNLpSaLyYq/Oc= X-Received: by 2002:a25:c7cd:0:b0:db5:45f4:ec83 with SMTP id w196-20020a25c7cd000000b00db545f4ec83mr416954ybe.43.1701858640812; Wed, 06 Dec 2023 02:30:40 -0800 (PST) MIME-Version: 1.0 References: <20231121171643.3719880-1-surenb@google.com> <20231121171643.3719880-6-surenb@google.com> <744be4e0-48e0-4c77-825c-711386dd205f@arm.com> <3ba0015b-b36e-449a-8445-0f6272694db5@redhat.com> In-Reply-To: <3ba0015b-b36e-449a-8445-0f6272694db5@redhat.com> From: Suren Baghdasaryan Date: Wed, 6 Dec 2023 02:30:28 -0800 Message-ID: Subject: Re: [PATCH v5 5/5] selftests/mm: add UFFDIO_MOVE ioctl test To: David Hildenbrand Cc: Ryan Roberts , akpm@linux-foundation.org, viro@zeniv.linux.org.uk, brauner@kernel.org, shuah@kernel.org, aarcange@redhat.com, lokeshgidra@google.com, peterx@redhat.com, hughd@google.com, mhocko@suse.com, axelrasmussen@google.com, rppt@kernel.org, willy@infradead.org, Liam.Howlett@oracle.com, jannh@google.com, zhangpeng362@huawei.com, bgeffon@google.com, kaleshsingh@google.com, ngeoffray@google.com, jdduke@google.com, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, kernel-team@android.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 10BE11A001D X-Stat-Signature: k9fciqpuai8obcfpa69rht6oe6ewx4ei X-HE-Tag: 1701858641-325806 X-HE-Meta: U2FsdGVkX18/i73V1om8Pjk3qaT9uHJkfwndzt+JEKQksNr6rUuRBypk/0jTwHG1Upp9zMK3APxWT30RnRPSHhwGTPl2CtuXLLIkGOXx1yPD9NH4Pn73EFnf4LJnmxXqtekJuIhfQHv7DhsdhTSczlpn9fdNIsQ3BrEbmLBfUou01gKKuLWKhBUu1FnI6f17Hecz9nrXu+ieVWFoIhzkc7ekLj+PIoMj6DapErRLFkWpY0YgZ02PCAdycjv/4vxHRa7VfX9wvpj1PAOEroewFuW0Lq6ssbbuzH6U8IAeiQy4PufLgvCUBxfzUzinBwZFhlLy7tAFkQ5q7sB20Ufuke4oQnd/M7DsVrb1IZ4xjV48lXR20Jaucc5z/EjPn0DmWq8IG78cCnY24kEKyG8q6zadFpsUNeMHRD362C3wddf2nXRVLQYhDJqnZNYfCZ1G/Ew9/qJ49gH9KlBBHiKrNu3B0lH/ni/pg3903wBk65pdhLZyNmzrr5eUMXIyfDx+eQ914gLocwyA1Uhr2BGmQuS6UyE132yv9nRkgGXkJV5VOMP+EI2UiQMEXfU5a4la+Q2mJklEjSxw3GTnvs9eE7+FkNJ59BJXuTwM/AT06U+Kl4xvRfjiDKajyzLkyYuXA46iDRhXCy2zMAvnNdXFJCz/27ZtJEkSwE+IXivLoJQl4so823oM4QWA5LNW6LG+77txF3rjp4z8QQj9vQeVvIQC5WkXHZL468XH/ZBbvc5jO8SwopZo99LBdo24qNcl/Sa7m135yKDUP+IXDGNPgDMDOwtc0dIkb6UQ/ntqUOstmyirTBE8b88l/3pg0nfEW3HQiz5FsmEd/SQD5iO5dzU+opkCr3/xBzlLbp7gQGZ3kbiwsGVH26xLMSBF5UiE97C6hbPiwlgiuLD/zxEEL5ifYBRjgwZd3EMn05C/LpZGaPMCJrvpV5BJ4TZsXenFU/JeD2Xjw3LnvKvZczG AWLJIivb ttly7yC1sK3EwRahWi2A34D1ZNRKjQR5MG+vQtVcav3hkpa1lrZLELAgtjn25RfOWE4lMPwH4TeAxesanGRMX2axR3YEXnbQAGNGahn/aEurDjkurIPO1Ew4xEKpzByot1ltwMnGmxyWpixuzMV4FHqGu3vd6z6IJlJSMW2cltBF+n1mpmvCf5cvtBXLnpESbt827movnYSOHRTFhxQOBXjusYScvdAOOwMu7D1eZggPgtEjhR3S9bzT0XoNGyYGu9Nvw0fvA3hZIAwP5CUcz5c42Jfbz1EkMwAkHQGuPTT1rqECQh1C3YW0BpuTDwTYMpWzkyyfpSJAuz5DNcAQ5eL0qqbdOQrHrLiClJXRISySamYfbswqiG/kGDOV39jBS2u28 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 Wed, Dec 6, 2023 at 1:21=E2=80=AFAM David Hildenbrand = wrote: > > On 05.12.23 05:46, Suren Baghdasaryan wrote: > > On Mon, Dec 4, 2023 at 10:44=E2=80=AFAM Suren Baghdasaryan wrote: > >> > >> On Mon, Dec 4, 2023 at 10:27=E2=80=AFAM David Hildenbrand wrote: > >>> > >>> On 04.12.23 17:35, Suren Baghdasaryan wrote: > >>>> On Mon, Dec 4, 2023 at 1:27=E2=80=AFAM Ryan Roberts wrote: > >>>>> > >>>>> On 04/12/2023 04:09, Suren Baghdasaryan wrote: > >>>>>> On Sat, Dec 2, 2023 at 2:11=E2=80=AFAM David Hildenbrand wrote: > >>>>>>> > >>>>>>> On 02.12.23 09:04, Ryan Roberts wrote: > >>>>>>>> On 01/12/2023 20:47, David Hildenbrand wrote: > >>>>>>>>> On 01.12.23 10:29, Ryan Roberts wrote: > >>>>>>>>>> On 21/11/2023 17:16, Suren Baghdasaryan wrote: > >>>>>>>>>>> Add tests for new UFFDIO_MOVE ioctl which uses uffd to move s= ource > >>>>>>>>>>> into destination buffer while checking the contents of both a= fter > >>>>>>>>>>> the move. After the operation the content of the destination = buffer > >>>>>>>>>>> should match the original source buffer's content while the s= ource > >>>>>>>>>>> buffer should be zeroed. Separate tests are designed for PMD = aligned and > >>>>>>>>>>> unaligned cases because they utilize different code paths in = the kernel. > >>>>>>>>>>> > >>>>>>>>>>> Signed-off-by: Suren Baghdasaryan > >>>>>>>>>>> --- > >>>>>>>>>>> tools/testing/selftests/mm/uffd-common.c | 24 +++ > >>>>>>>>>>> tools/testing/selftests/mm/uffd-common.h | 1 + > >>>>>>>>>>> tools/testing/selftests/mm/uffd-unit-tests.c | 189 +++++= ++++++++++++++ > >>>>>>>>>>> 3 files changed, 214 insertions(+) > >>>>>>>>>>> > >>>>>>>>>>> diff --git a/tools/testing/selftests/mm/uffd-common.c > >>>>>>>>>>> b/tools/testing/selftests/mm/uffd-common.c > >>>>>>>>>>> index fb3bbc77fd00..b0ac0ec2356d 100644 > >>>>>>>>>>> --- a/tools/testing/selftests/mm/uffd-common.c > >>>>>>>>>>> +++ b/tools/testing/selftests/mm/uffd-common.c > >>>>>>>>>>> @@ -631,6 +631,30 @@ int copy_page(int ufd, unsigned long off= set, bool wp) > >>>>>>>>>>> return __copy_page(ufd, offset, false, wp); > >>>>>>>>>>> } > >>>>>>>>>>> +int move_page(int ufd, unsigned long offset, unsigned l= ong len) > >>>>>>>>>>> +{ > >>>>>>>>>>> + struct uffdio_move uffdio_move; > >>>>>>>>>>> + > >>>>>>>>>>> + if (offset + len > nr_pages * page_size) > >>>>>>>>>>> + err("unexpected offset %lu and length %lu\n", offset= , len); > >>>>>>>>>>> + uffdio_move.dst =3D (unsigned long) area_dst + offset; > >>>>>>>>>>> + uffdio_move.src =3D (unsigned long) area_src + offset; > >>>>>>>>>>> + uffdio_move.len =3D len; > >>>>>>>>>>> + uffdio_move.mode =3D UFFDIO_MOVE_MODE_ALLOW_SRC_HOLES; > >>>>>>>>>>> + uffdio_move.move =3D 0; > >>>>>>>>>>> + if (ioctl(ufd, UFFDIO_MOVE, &uffdio_move)) { > >>>>>>>>>>> + /* real retval in uffdio_move.move */ > >>>>>>>>>>> + if (uffdio_move.move !=3D -EEXIST) > >>>>>>>>>>> + err("UFFDIO_MOVE error: %"PRId64, > >>>>>>>>>>> + (int64_t)uffdio_move.move); > >>>>>>>>>> > >>>>>>>>>> Hi Suren, > >>>>>>>>>> > >>>>>>>>>> FYI this error is triggering in mm-unstable (715b67adf4c8): > >>>>>>>>>> > >>>>>>>>>> Testing move-pmd on anon... ERROR: UFFDIO_MOVE error: -16 (err= no=3D16, > >>>>>>>>>> @uffd-common.c:648) > >>>>>>>>>> > >>>>>>>>>> I'm running in a VM on Apple M2 (arm64). I haven't debugged an= y further, but > >>>>>>>>>> happy to go deeper if you can direct. > >>>>>>>>> > >>>>>>>>> Does it trigger reliably? Which pagesize is that kernel using? > >>>>>>>> > >>>>>>>> Yep, although very occasionally it fails with EAGAIN. 4K kernel;= see other email > >>>>>>>> for full config. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> I can spot that uffd_move_pmd_test()/uffd_move_pmd_handle_fault= () uses > >>>>>>>>> default_huge_page_size(), which reads the default hugetlb size. > >>>>>>>> > >>>>>>>> My kernel command line is explicitly seting the default huge pag= e size to 2M. > >>>>>>>> > >>>>>>> > >>>>>>> Okay, so that likely won't affect it. > >>>>>>> > >>>>>>> I can only guess that it has to do with the alignment of the virt= ual > >>>>>>> area we are testing with, and that we do seem to get more odd pat= terns > >>>>>>> on arm64. > >>>>>>> > >>>>>>> uffd_move_test_common() is a bit more elaborate, but if we aligne= d the > >>>>>>> src+start area up, surely "step_count" cannot be left unmodified? > >>>>>>> > >>>>>>> So assuming we get either an unaligned source or an unaligned dst= from > >>>>>>> mmap(), I am not convinced that we won't be moving areas that are= not > >>>>>>> necessarily fully backed by PMDs and maybe don't even fall into t= he VMA > >>>>>>> of interest? > >>>>>>> > >>>>>>> Not sure if that could trigger the THP splitting issue, though. > >>>>>>> > >>>>>>> But I just quickly scanned that test setup, could be I am missing > >>>>>>> something. It might make sense to just print the mmap'ed range an= d the > >>>>>>> actual ranges we are trying to move. Maybe something "obvious" ca= n be > >>>>>>> observed. > >>>>>> > >>>>>> I was able to reproduce the issue on an Android device and after > >>>>>> implementing David's suggestions to split the large folio and afte= r > >>>>>> replacing default_huge_page_size() with read_pmd_pagesize(), the > >>>>>> move-pmd test started working for me. Ryan, could you please apply > >>>>>> attached patches (over mm-unstable) and try the test again? > >>>>> > >>>>> Yep, all fixed with those patches! > >>>> > >>>> Great! Thanks for testing and confirming. I'll post an updated > >>>> patchset later today and will ask Andrew to replace the current one > >>>> with it. > >>>> I'll also look into the reasons we need to split PMD on ARM64 in thi= s > >>>> test. It's good that this happened and we were able to test the PMD > >>>> split path but I'm curious about the reason. It's possible my addres= s > >>>> alignment calculations are somehow incorrect. > >>> > >>> I only skimmed the diff briefly, but likely you also want to try > >>> splitting in move_pages_pte(), if you encounter an already-pte-mapped= THP. > >> > >> Huh, good point. I might be able to move the folio splitting code into > >> pte-mapped case and do a retry after splitting. That should minimize > >> the additional code required. Will do and post a new set shortly. > >> Thanks! > > > > Was planning to post an update today but need some more time. Will try > > to send it tomorrow. > > It would be great to have tests that cover these cases (having to > PTE-map a PMD-mapped THP, and stumbling over an already-PTE-mapped one). Agree. Let me post the new version so that mm-unstable does not produce these failures and will start working on covering additional cases in the tests. The new patchset is almost ready, just finishing final tests. > > -- > Cheers, > > David / dhildenb >