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 97B75C4167B for ; Wed, 6 Dec 2023 10:39:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 313536B00AC; Wed, 6 Dec 2023 05:39:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C3406B00AD; Wed, 6 Dec 2023 05:39:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 18BD06B00AE; Wed, 6 Dec 2023 05:39:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0B80C6B00AC for ; Wed, 6 Dec 2023 05:39:54 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E1D3E1A0002 for ; Wed, 6 Dec 2023 10:39:53 +0000 (UTC) X-FDA: 81536047866.20.1E98699 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf09.hostedemail.com (Postfix) with ESMTP id 1E44B14000D for ; Wed, 6 Dec 2023 10:39:51 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hfEVE7zf; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.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=1701859192; a=rsa-sha256; cv=none; b=aS7mxMgjwkJi9Wgsz51L1fHMKziQG/DaODPBkiAutqzWPbZ7bB169d1BKUFFEgoIXxhrmw QQBi9NKJP5eW5bAJdCZsDHKrEmrVp8Kkdlt6nMRfZMWCFUDiIRQBsXnXY0u8WJpY3HvgJz 2Ry4nLEy+4Pl9UkxMXF9NN7sNn1cATo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=hfEVE7zf; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf09.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=1701859192; 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=iQdifr2abX3HSlYGNn9HZ0F9hnYIWmyEvcln+QnyZu0=; b=xsr3ikFkEfYbxWh/Ry1ilEGlnuV86tmGGprf2nJUfvoJWD1lUThbcSngEOE8P0iY0M1xVG lceolehhx96ewViHLiFWgSB8fyN08OLaTh81M7DU2Ar1vRsq3a+3Qev/wPknOv0UF4LNIo t8lroPnqY7QxSxRs39kuaHJj/xMZ9yg= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-db4364ecd6aso4246415276.2 for ; Wed, 06 Dec 2023 02:39:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701859191; x=1702463991; 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=iQdifr2abX3HSlYGNn9HZ0F9hnYIWmyEvcln+QnyZu0=; b=hfEVE7zfEIGLyxivwkyJNQU62d6k42+O9KhZgSO/bVTdtubKPwarQfzpppO+2vbmCd OJ98wLNvPUmh9IemnxXzO5MQ5ZRebZzotQgzhPuvplIw0D5LNllQSaX0yKYC1ey5wYmA UbkVg94FUZZTyZpkYVjyT3Ql8i2sAxm/jfhpZq9K4PHnVn+LUCbimIf586wklEr8T6XA MQN9YASaieWyLZ5loInqM3gpJSxOaKRxkfGx2I8m1QlY3Bj6V3nnYf20wUc3/yYZCjCw d+2IBzdihkU0jqe5vUFsGyn2GpJpgMaXkINU/Tpm0tF9F/U/3AjC5AkJdnqXVUNkoIVd eLAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701859191; x=1702463991; 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=iQdifr2abX3HSlYGNn9HZ0F9hnYIWmyEvcln+QnyZu0=; b=OeXLTIgDRoEShgvWxr/hsOvkBeOWT3fUDLOMm3KZ7PRcH1OFUVfwHdjX5I1N8k4sGJ v2G+fdxeQkq7C63FuHDtl2q3E5udoCqOQQ14baoU798LagbEk2/VrCvbnZaUjfRCc/TQ 7Y/3NA6Ks74iGGeAtQ+qiT3wzg0cJJNUc3xPhuscWY88ExOC2pQNvPEhWKFR3OPxX13y m1+RWZUdB/SJzNfd4RfUYmNnZ37IoOWxTTrri2wBUAHXNV14TMOuqlu4Wg3ZTuzueg2J tOvCMZgR9KNTISlWjEQ7WtQ8e9RUcer4jEoaOExZqfjXrB9xDm4KP/Up3vTmUNpKXkSA yXUg== X-Gm-Message-State: AOJu0YxfJ0/lHo6oE+7wK+K9ejiVAtY42bVsAJFuL90WxyhVopds3FQ9 3xMh8eIPxSa7lBY6lTTKzKHNRLbE9W9JxwJ6AU/LZw== X-Google-Smtp-Source: AGHT+IER7xjB5IRLvMGcDEKuvEKxXZVwGUfdzV3VDT1Vsv/pO4A7HLd5GLlUs6A0WBOd00lfCGHWzJj94wiAk/VID7E= X-Received: by 2002:a25:1c2:0:b0:db7:dacf:4d65 with SMTP id 185-20020a2501c2000000b00db7dacf4d65mr262941ybb.97.1701859190881; Wed, 06 Dec 2023 02:39:50 -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: From: Suren Baghdasaryan Date: Wed, 6 Dec 2023 02:39:39 -0800 Message-ID: Subject: Re: [PATCH v5 5/5] selftests/mm: add UFFDIO_MOVE ioctl test To: akpm@linux-foundation.org Cc: David Hildenbrand , Ryan Roberts , 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: rspam06 X-Rspamd-Queue-Id: 1E44B14000D X-Stat-Signature: do9ee37ptquuhjre7rwociss6ydqdj1b X-HE-Tag: 1701859191-301740 X-HE-Meta: U2FsdGVkX19wGg8c0Cadnzv5z2A76sFgZCL7lXCzLH9S6/QpPBJ4sNyE4eCM3Pbt7pFxggLYbyIt9r891bu8052/0Bv6bywcc8w7RztmZAK7PLd7ZWnFzpaiJVU8Wo7QrbtLNnePd36w/qFY6rNcce8rA1VV5OTWL202u1cNX/JNXqi5OmDR+YiFYTPUm95e8aEi0dd3AOwJV7deHZ2XJFzz+wWlu8e4Epbg8NguZirGDunz7L7Pzi1FhxIMpvrZHPO6RggPuvFPNPpXAgDo48vP1Qh/hNqRytu5/2GRavga0IdCEaK7cXQsLHjxbzyMQfXoMOZU25nkxVG1QhP3XEkEZJTaZsdVyHsIbm9+w4V1SfUOJIooVTI+Nrx8LiDR9vkUc0/t/JtvjjLXPwpS7o68l4b4u7X1EvKZ8iknKdr2r1VgRIRbrOqowifR3NRkXxhByR4CDlkLsnKd6PJtup1HQchFnJg+2pLTtV2Ra4S4bYVfBoR/JXaYILJ/p92+ahJ31icPv7dllIHENip+S7N/IIar9okB3aFU1DZ0B9Q695H9ZJZKQcpAyrjdCENgEm91KilicscinLFhuVu5enmBK/PftvvvCAs8F4Q0jaGbQn2R+o+DsqsCXCXqqonWrRKSwxPNmkDADk+ELODPWK3b+hdHP0P8p8S9uzOusUHV646wepnHlKUoRBPpbQ6CEqmWbJ8KAPP6hvw6/WDMezggsOo0RPPe1XzSBDzftqaIzjVI0DBhIKTpGMD2v/A1wiQFwTPWxx4gXx1DD0L20tUu48im2L8bqIoxK9q9wiOIAQo5hhL+0GmLqSv5/ZuybpzXs4hslmCXur1GukY/jEaZ4EyDQpAAKUmaKqM+uEFb2YdITPsNp7FbGLhbGExff8uxJjFRy79w5nbDGd3Rwn8svBtvY3k4eQK/m3tgIl3xkP9zxP7F2X/kFND/974xR2g2p9FLoMVT0PtCTj3 eghsh8on UAj4JXLvWEaSJ93+UWDcVUAkBS3xoAa7+kpe6W+SfIhtrP+TT9LxCe+g/JokCRCCkbtiyF36IuPktKhnbdrybie1sR6wJGdO+WyBsI/bfqJtlLEANz2+RLR1Ky24xI7qbodAzrbtl8KPf13aswodS2yV0Hkqm6NvMfIhHW7H+hSM1JQZ25cJEmL0gnk/DHH3JRZFEORXkii6/v60/nm30NTOe3+0lPlxjbtxqpfggqMfnr6otf79Xvv1FsMo0fyRH3hYmx+nNs6aQG5XcBhPx9bcT1FZe5mrVjVvUtf/ze+SumRXTvZzoYhnAnNlA6TqI5Xon7p/V2AjAfFlfkk27aFkU/9jpN4HZ2JNfHAuGwFhtqsbieRkE2F7AGyag1mQstKXwL18Arzs1LX3fDZ0eIlUeZOP19HvHzlSeTkBf7/vWGwm5aCtMuBZL0RsjR+YsNcss 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 2:30=E2=80=AFAM Suren Baghdasaryan wrote: > > 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= source > > >>>>>>>>>>> into destination buffer while checking the contents of both= after > > >>>>>>>>>>> the move. After the operation the content of the destinatio= n buffer > > >>>>>>>>>>> should match the original source buffer's content while the= source > > >>>>>>>>>>> buffer should be zeroed. Separate tests are designed for PM= D aligned and > > >>>>>>>>>>> unaligned cases because they utilize different code paths i= n 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 o= ffset, bool wp) > > >>>>>>>>>>> return __copy_page(ufd, offset, false, wp); > > >>>>>>>>>>> } > > >>>>>>>>>>> +int move_page(int ufd, unsigned long offset, unsigned= long len) > > >>>>>>>>>>> +{ > > >>>>>>>>>>> + struct uffdio_move uffdio_move; > > >>>>>>>>>>> + > > >>>>>>>>>>> + if (offset + len > nr_pages * page_size) > > >>>>>>>>>>> + err("unexpected offset %lu and length %lu\n", offs= et, 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 (e= rrno=3D16, > > >>>>>>>>>> @uffd-common.c:648) > > >>>>>>>>>> > > >>>>>>>>>> I'm running in a VM on Apple M2 (arm64). I haven't debugged = any 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 kerne= l; see other email > > >>>>>>>> for full config. > > >>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I can spot that uffd_move_pmd_test()/uffd_move_pmd_handle_fau= lt() uses > > >>>>>>>>> default_huge_page_size(), which reads the default hugetlb siz= e. > > >>>>>>>> > > >>>>>>>> My kernel command line is explicitly seting the default huge p= age 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 vi= rtual > > >>>>>>> area we are testing with, and that we do seem to get more odd p= atterns > > >>>>>>> on arm64. > > >>>>>>> > > >>>>>>> uffd_move_test_common() is a bit more elaborate, but if we alig= ned the > > >>>>>>> src+start area up, surely "step_count" cannot be left unmodifie= d? > > >>>>>>> > > >>>>>>> So assuming we get either an unaligned source or an unaligned d= st from > > >>>>>>> mmap(), I am not convinced that we won't be moving areas that a= re not > > >>>>>>> necessarily fully backed by PMDs and maybe don't even fall into= the 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 missi= ng > > >>>>>>> something. It might make sense to just print the mmap'ed range = and the > > >>>>>>> actual ranges we are trying to move. Maybe something "obvious" = can 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 af= ter > > >>>>>> replacing default_huge_page_size() with read_pmd_pagesize(), the > > >>>>>> move-pmd test started working for me. Ryan, could you please app= ly > > >>>>>> 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 on= e > > >>>> with it. > > >>>> I'll also look into the reasons we need to split PMD on ARM64 in t= his > > >>>> test. It's good that this happened and we were able to test the PM= D > > >>>> split path but I'm curious about the reason. It's possible my addr= ess > > >>>> 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-mapp= ed THP. > > >> > > >> Huh, good point. I might be able to move the folio splitting code in= to > > >> 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 tr= y > > > 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. Posted v6 at https://lore.kernel.org/all/20231206103702.3873743-1-surenb@go= ogle.com/. Changes are listed in the cover letter. Andrew, could you please replace the current v5 version in mm-unstable with this new one? Thanks, Suren. > > > > > -- > > Cheers, > > > > David / dhildenb > >