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 X-Spam-Level: X-Spam-Status: No, score=-16.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B357BC433EF for ; Thu, 23 Sep 2021 23:25:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5059D60F3A for ; Thu, 23 Sep 2021 23:25:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 5059D60F3A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id CD8FE6B006C; Thu, 23 Sep 2021 19:25:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8838900002; Thu, 23 Sep 2021 19:25:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4EF16B0073; Thu, 23 Sep 2021 19:25:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A58FD6B006C for ; Thu, 23 Sep 2021 19:25:19 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 51B948249980 for ; Thu, 23 Sep 2021 23:25:19 +0000 (UTC) X-FDA: 78620421558.22.8F5A637 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf12.hostedemail.com (Postfix) with ESMTP id 8058110000A0 for ; Thu, 23 Sep 2021 23:25:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1632439517; h=from:from: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; bh=OWRAOD1kkJz6XiLKgu5hMtfHp+8QmnStWvfGHKzXlyc=; b=Dg3mmtNTAHOBH2xCYDKyzagzvc25MEgPLNCFFDiqLQHj+HUHAtEGMRrXqISfR6goDGOVsT kBRvB1+qebyD7ifKIibkueAVYQYTvMIjXuSNoJl/f9mtQ6B09q9Ipje7zcESVytFtiMZQ3 +oXdL6IYXRCqazTilMR77oLXCwJWBmE= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-410-iiQYM4zFNjujodxaKd3CMQ-1; Thu, 23 Sep 2021 19:25:16 -0400 X-MC-Unique: iiQYM4zFNjujodxaKd3CMQ-1 Received: by mail-qk1-f199.google.com with SMTP id w2-20020a3794020000b02903b54f40b442so28338043qkd.0 for ; Thu, 23 Sep 2021 16:25:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=OWRAOD1kkJz6XiLKgu5hMtfHp+8QmnStWvfGHKzXlyc=; b=4arM1flN7NSLbnHFHw0GdwUh4JfXcsK20UQSDINLIxkSnm++rrxUJhUVNacVrcCh3Q hc2x1ONMWVJf0Y7mCXTcabhQBHhsL286645LwvE0Tj4Z0zZNOke9DfzPdKOZ5Dmskhyu fjVvSep17r49y/14yUQlK1uDSNnhhz/bIduVTPu2CAkChmNDWedfKTZT1Tezvd6zWcjz FU8bKa46cw3Z6jfUAh6RVgwemvNgXTs/cjdpRLD/sYiYQSscIZrLbBZC3NEaZtdm2ZTj qDMlWb87igRXa0RDQqLeZNsdZeVgz6y95xNRnXns0mZSeuVsQn6h5485vMhYGNe5GJjw qUiA== X-Gm-Message-State: AOAM5334+TQlbJP8erUZSbv4344f1yF4jPxttZXaSsbVLMEzHhmYeWFr tD+S2hrtFZhh/SYKrKaUI2D4MamIzTt+8PBnbJenlBiDGS2WoxrsSyZCCek6mCAY8ahSIxrVBu5 wg8oUZ6owt/+IX5YOhaehfMt+HJtapUcWmWdw78jkKyf3rRQvgMJ5pE3DTW5a X-Received: by 2002:ac8:1090:: with SMTP id a16mr1290810qtj.297.1632439515448; Thu, 23 Sep 2021 16:25:15 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy364R1AwTCp7sR65ye1IseTJYrbscmW58fi4R3hUU0BoOV0BwbaQiLicMBWVS9rIkTkrmN4A== X-Received: by 2002:ac8:1090:: with SMTP id a16mr1290769qtj.297.1632439515055; Thu, 23 Sep 2021 16:25:15 -0700 (PDT) Received: from t490s.redhat.com ([2607:fea8:56a2:9100::d3ec]) by smtp.gmail.com with ESMTPSA id q192sm5170112qka.93.2021.09.23.16.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Sep 2021 16:25:14 -0700 (PDT) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: peterx@redhat.com, Andrew Morton , Andrea Arcangeli , Axel Rasmussen , Nadav Amit , Li Wang Subject: [PATCH] mm/userfaultfd: selftests: Fix memory corruption with thp enabled Date: Thu, 23 Sep 2021 19:25:12 -0400 Message-Id: <20210923232512.210092-1-peterx@redhat.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="US-ASCII" Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Dg3mmtNT; spf=none (imf12.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8058110000A0 X-Stat-Signature: o8wg6a4k86theb4rnysq8gyyi7puh7qx X-HE-Tag: 1632439518-528722 Content-Transfer-Encoding: quoted-printable 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: In RHEL's gating selftests we've encountered memory corruption in the uff= d event test even with upstream kernel: # ./userfaultfd anon 128 4 nr_pages: 32768, nr_pages_per_cpu: 32768 bounces: 3, mode: rnd racing read, userfaults: 6240 missing (6240= ) 14729 wp (14729) bounces: 2, mode: racing read, userfaults: 1444 missing (1444) 28= 877 wp (28877) bounces: 1, mode: rnd read, userfaults: 6055 missing (6055) 14699= wp (14699) bounces: 0, mode: read, userfaults: 82 missing (82) 25196 wp (251= 96) testing uffd-wp with pagemap (pgsize=3D4096): done testing uffd-wp with pagemap (pgsize=3D2097152): done testing events (fork, remap, remove): ERROR: nr 32427 memory corr= uption 0 1 (errno=3D0, line=3D963) ERROR: faulting process failed (errno=3D0, line=3D1117) It can be easily reproduced when global thp enabled, which is the default= for RHEL. It's also known as a side effect of commit 0db282ba2c12 ("selftest: use m= map instead of posix_memalign to allocate memory", 2021-07-23), which is imho= right itself on using mmap() to make sure the addresses will be untagged even o= n arm. The problem is, for each test we allocate buffers using two allocate_area= () calls. We assumed these two buffers won't affect each other, however the= y could, because mmap() could have found that the two buffers are near each= other and having the same VMA flags, so they got merged into one VMA. It won't be a big problem if thp is not enabled, but when thp is agressiv= ely enabled it means when initializing the src buffer it could accidentally s= etup part of the dest buffer too when there's a shared THP that overlaps the t= wo regions. Then some of the dest buffer won't be able to be trapped by userfaultfd missing mode, then it'll cause memory corruption as described= . To fix it, do release_pages() after initializing the src buffer. Since the previous two release_pages() calls are after uffd_test_ctx_clea= r() which will unmap all the buffers anyway (which is stronger than release p= ages; as unmap() also tear town pgtables), drop them as they shouldn't really b= e anything useful. We can mark the Fixes tag upon 0db282ba2c12 as it's reported to only happ= en there, however the real "Fixes" IMHO should be 8ba6e8640844, as before th= at commit we'll always do explicit release_pages() before registration of uf= fd, and 8ba6e8640844 changed that logic by adding extra unmap/map and we didn= 't release the pages at the right place. Meanwhile I don't have a solid glu= e anyway on whether posix_memalign() could always avoid triggering this bug= , hence it's safer to attach this fix to commit 8ba6e8640844. Cc: Andrea Arcangeli Cc: Axel Rasmussen Cc: Nadav Amit Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=3D1994931 Fixes: 8ba6e8640844 ("userfaultfd/selftests: reinitialize test context in= each test") Reported-by: Li Wang Signed-off-by: Peter Xu --- tools/testing/selftests/vm/userfaultfd.c | 23 ++++++++++++++++++++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/sel= ftests/vm/userfaultfd.c index 10ab56c2484a..60aa1a4fc69b 100644 --- a/tools/testing/selftests/vm/userfaultfd.c +++ b/tools/testing/selftests/vm/userfaultfd.c @@ -414,9 +414,6 @@ static void uffd_test_ctx_init_ext(uint64_t *features= ) uffd_test_ops->allocate_area((void **)&area_src); uffd_test_ops->allocate_area((void **)&area_dst); =20 - uffd_test_ops->release_pages(area_src); - uffd_test_ops->release_pages(area_dst); - userfaultfd_open(features); =20 count_verify =3D malloc(nr_pages * sizeof(unsigned long long)); @@ -437,6 +434,26 @@ static void uffd_test_ctx_init_ext(uint64_t *feature= s) *(area_count(area_src, nr) + 1) =3D 1; } =20 + /* + * After initialization of area_src, we must explicitly release pages + * for area_dst to make sure it's fully empty. Otherwise we could have + * some area_dst pages be errornously initialized with zero pages, + * hence we could hit memory corruption later in the test. + * + * One example is when THP is globally enabled, above allocate_area() + * calls could have the two areas merged into a single VMA (as they + * will have the same VMA flags so they're mergeable). When we + * initialize the area_src above, it's possible that some part of + * area_dst could have been faulted in via one huge THP that will be + * shared between area_src and area_dst. It could cause some of the + * area_dst won't be trapped by missing userfaults. + * + * This release_pages() will guarantee even if that happened, we'll + * proactively split the thp and drop any accidentally initialized + * pages within area_dst. + */ + uffd_test_ops->release_pages(area_dst); + pipefd =3D malloc(sizeof(int) * nr_cpus * 2); if (!pipefd) err("pipefd"); --=20 2.31.1