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 29A73C4167B for ; Mon, 4 Dec 2023 18:45:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8BFB6B02E4; Mon, 4 Dec 2023 13:45:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A3C036B02E6; Mon, 4 Dec 2023 13:45:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DD4D6B02E7; Mon, 4 Dec 2023 13:45:15 -0500 (EST) 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 7DA366B02E4 for ; Mon, 4 Dec 2023 13:45:15 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1A6ECC0306 for ; Mon, 4 Dec 2023 18:45:15 +0000 (UTC) X-FDA: 81530013390.17.5A8051D Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf24.hostedemail.com (Postfix) with ESMTP id 3BA5D180014 for ; Mon, 4 Dec 2023 18:45:12 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="D37BqKu/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.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=1701715513; 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=mcZOoagNfuYTwGb5c2DFpOJBXe5yhQOWEede9pD77Ig=; b=PcVE3OP/dq6bG6hQNbbd0RTiudHFBF9hWvue6QAbfGbdEN0MGe6yXAtQ65OE7TQr4qEvfm 7Fi470XJo47+JqAS34SGEpkJvUA45trhuxD7W9/vMAyaN052ck3atqGeJBJUtabf2causs TblHpH36/m2prTcH/2uUIsHnjH1VbcQ= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="D37BqKu/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.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=1701715513; a=rsa-sha256; cv=none; b=w6xPjihwM4rDxANU5vHrxlSQXc3+SqQaaz6zhM4cT+1LOTVMF3gP0dCT04TEpMNeKVpF/5 t0WIOgtw4WBP3E2wTXXTKL6sm7AxPkyDP7Q5QMvxgXU3VafpvcOvULEmYSl+zHOfvnXdHv twwtQF0Tbdla7fAYVTdlI+IseTjfY1Q= Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-dae0ab8ac3eso3188764276.0 for ; Mon, 04 Dec 2023 10:45:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1701715512; x=1702320312; 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=mcZOoagNfuYTwGb5c2DFpOJBXe5yhQOWEede9pD77Ig=; b=D37BqKu/DLJobon2FEx0PaveqDjYbJXnfMwM1C23D9O7Q73V4lP3enUIqJYhzK0Qlr fcvtqI/Vu2Qjy623tewvGWaZtQ5bhXO9SW4aRAM3qVshUVmuwTfoQPT4Ru8a02Z1mC3z sLp+RK7r7P2v3/XUkdO1rKPj2HynoCxQnLBTppwNET1oqbWvZtbxHhGOn8sgfcFbFqT9 7gDk9Oj2wyoVx6u+v6aVRLL08uc/CRgpAetk7qIq9AUj7m/SD57/NSmUCEUVZcr6dHWU Ii9ohk6Um4vwevS+wR+u743qybbw7rCMHceFwCwXY0SewLC0Vk40ikz5z6ZzuEf2PesB RUCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701715512; x=1702320312; 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=mcZOoagNfuYTwGb5c2DFpOJBXe5yhQOWEede9pD77Ig=; b=bxXCu+RVLp++e92/tntkfacSTMsIY0QcGUg7mo0L73UZ6fV9wLugHVnzkHyTdcYhYf YNq2UkU7S0qumSsN7BNmBYlkch4WdzODJW+q5KwJpJDoNcXjecI610Prqvr4KaGxXJLA nz3h6X+XqewdXPzcQMJ2yJPdyBSkILwn/zhVkUGGBk534dHHZn0uYbXClT8tkRos6K3L K5J1YYtsKp1C16W1eixSXRu8CSKOm+moX6N++r4DCZAJrxIAAmYJnligsg2goIOmQcC4 D8A/ZIWQ/jR6U4//oc7bKw8t3j1mK8TAvBmzu99T/qvaSulJZtU8H8nlpSIrw6Yc+26Y OGGA== X-Gm-Message-State: AOJu0YxvujX/0ZvKGoPMtmv7i85hrx3J/xs83HOkFYvTR+vemb+iyk53 U6ogmpLhRMdUKqob2X9DPEqB1ROk86auCAOJDCpmcg== X-Google-Smtp-Source: AGHT+IG53Tprrzwkx2dmHW1+f8sbtKAiaQTT6sp9hmu4pFfnOzhawf2KKqgXFHmoLoh1lXYguEgo9GKmyXRuXChp0oE= X-Received: by 2002:a5b:b07:0:b0:db7:dacf:6fdf with SMTP id z7-20020a5b0b07000000b00db7dacf6fdfmr3544806ybp.103.1701715511977; Mon, 04 Dec 2023 10:45:11 -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> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 4 Dec 2023 10:44:59 -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-Rspamd-Queue-Id: 3BA5D180014 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: d4a3dd43f57uq1h3ypyrzoai1k1eb91p X-HE-Tag: 1701715512-336267 X-HE-Meta: U2FsdGVkX19bKbrbgHStF1dkMioCgTaQOnv30d/qMBew8B9h1PpNrKsvGDptLemvHGDNHn4hmlw/FfkLA2CzhpODe9s2b07rLB8sll7HyXKxKUC6hmN+bMk3e/6MMVBWcw9haoKZq8K+Z/yPdj9wyzh/5y4el1j1Pz2pRYpWxny7P+0S3I+yrWk/JFJLGnZMyWTuJxpaDVZj/XQoG7qZEcg5Od+5+feTeuYmKSIWKLuB9YipeYf8Sos0cnjf6RVrEFA/IHOvWnry+m6lxPX1PIVLRTANemJ7HApKA8AH8nh0SL8srgOs43oKIzydK7FZrsv5CGakBFNPl2Se8WjfNk/AAxT5av+AkIutoN/qTILN1liU75yW7OsmGNVrCo3McPal6md8N73mPXYzoiIetE/kq8jg7KJT1jAUTO3N4r4lfzY7Rf8ipfe4TsBO0ZX1Ea5jkmzovH4ngJeV+9c5l52wefjzRGfsBn0vTC68Cm81HfYTrWZKtVKEEvKffxngae572wR82KJa7MDrAoyY86aZDwFNWlrIBJfP0n7o2VTmSwTsjQKQHs8LjyYtYYVynlboWzYRI/HpWDJDO2AxB3uahSdLD5QH2LI2nosIeROaHUecA4n+RI+vkm2HY5oEPeAZpyfB5Op7zI0lpek9tshZIwZHFSfDprALARolUgqugLjVF9cyrWthfT4JYrIJJXYon8VDkQzYaJyJJSWys7hpfbdgpM9njlj5kaO5zKhBUCrIhpn+3ZgOAbkHbFu0Gx2oLW7VgsEMeI1C0XEnohZBiR0hKsxdfeeAk3jZR4ZqZHD3T5r1Ut9CVFGESGvigFuxUMNWSeNu+BeS3uTKR53ML71/W83GR4Gkpgkb6M+d6wfFbdTmJwVAZa2ZcDtBPNdAzNx5PLP41EAXAcik/nTqUtrgZK7wsb8coUmBof2Dbv9mt2Oxfm44x7PDZ5lH1sp/zNHSP9e5nfj4fYW zjnSjjV1 k88fch/AMG8Jd+svIaudzX9pni/XQmHZKhG0eiFldwsMDGMOAXLbyXKZXc1uFyP1kLMVt4t81AJksQwE/0mPb87kOYbc+RQvNxF0UZUaURLiPZO43XE6Y6KNsnQjFUmyBGSY83c8eP9970973jTfhNYCZXt6pChvaJv+3rG+9PoXl8UusfWqIC5UoN6AfubNu5Na9pp6xkH7bWS8SmWwZZ1sB83MSY8v/MpwhHWnhkx1KngfNXfjySh5WE7EuZlR5lAVGEcUOgCRGmD/ws6gwkPwTFM9VYF2DBr/ptABwvNhJDVau1YzFUKD0Qiq/YO6jn4nsKuPTa6dvkFs3GVQcgVe4yMS8hzcW5S3WLV6vcs3cBRu8Ah6DFQjZ/zryDpL+x4qe 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 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 sour= ce > >>>>>>>> into destination buffer while checking the contents of both afte= r > >>>>>>>> the move. After the operation the content of the destination buf= fer > >>>>>>>> should match the original source buffer's content while the sour= ce > >>>>>>>> buffer should be zeroed. Separate tests are designed for PMD ali= gned 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 offset= , 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", offset, l= en); > >>>>>>>> + 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 (errno= =3D16, > >>>>>>> @uffd-common.c:648) > >>>>>>> > >>>>>>> I'm running in a VM on Apple M2 (arm64). I haven't debugged any f= urther, 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; se= e 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 page s= ize to 2M. > >>>>> > >>>> > >>>> Okay, so that likely won't affect it. > >>>> > >>>> I can only guess that it has to do with the alignment of the virtual > >>>> area we are testing with, and that we do seem to get more odd patter= ns > >>>> on arm64. > >>>> > >>>> uffd_move_test_common() is a bit more elaborate, but if we aligned t= he > >>>> src+start area up, surely "step_count" cannot be left unmodified? > >>>> > >>>> So assuming we get either an unaligned source or an unaligned dst fr= om > >>>> mmap(), I am not convinced that we won't be moving areas that are no= t > >>>> 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 missing > >>>> something. It might make sense to just print the mmap'ed range and t= he > >>>> actual ranges we are trying to move. Maybe something "obvious" can b= e > >>>> observed. > >>> > >>> I was able to reproduce the issue on an Android device and after > >>> implementing David's suggestions to split the large folio and after > >>> 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 this > > 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 address > > 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! > > -- > Cheers, > > David / dhildenb >