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 A5DE4C6FA82 for ; Mon, 26 Sep 2022 00:11:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F38708E0026; Sun, 25 Sep 2022 20:11:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC08E8E0007; Sun, 25 Sep 2022 20:11:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3AA18E0026; Sun, 25 Sep 2022 20:11:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id BF1E88E0007 for ; Sun, 25 Sep 2022 20:11:16 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8C04E40238 for ; Mon, 26 Sep 2022 00:11:16 +0000 (UTC) X-FDA: 79952306952.24.F3945DD Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 50D2710000C for ; Mon, 26 Sep 2022 00:11:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664151074; 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: in-reply-to:in-reply-to:references:references; bh=aK8oEr6Mo1r3LJjWh8qC8wg2ZbpaqIAd/c7oyUSXWrA=; b=HBO5wigpGSysqqI0rymLm575OWBCjrOvz564lZ39clHiZMXzofzNPG+XwIfDxtGp8fUF/Q JDbJvkmgUk6w/RZVVylgQ/gyhanf/mvoJOgJ0+OcppRqq3VvSRIJvfo1+FDr2GkzcF+ymJ 5ZW9Uy0SEFgMJjcWj9787ADDVf+ZFNU= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-443-cQERHvE4PxWQDXdqs9KfGg-1; Sun, 25 Sep 2022 20:11:13 -0400 X-MC-Unique: cQERHvE4PxWQDXdqs9KfGg-1 Received: by mail-qk1-f198.google.com with SMTP id bm21-20020a05620a199500b006cf6a722b16so3940117qkb.0 for ; Sun, 25 Sep 2022 17:11:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=aK8oEr6Mo1r3LJjWh8qC8wg2ZbpaqIAd/c7oyUSXWrA=; b=YWJdCAYAv5zdPdwtf0Llobi5zJjXBnRNua/GU7WipyidZNd5hhQoGTmtA/Gs81TgBS /D3Wu4IbGz0tTh3W6Y9jmEXrIOUr7+nf/1TG3Vq8ad2YoqpYRdQNqrwojIe8+dR7tKOd daCXRwB3WfNJkGzOtRRyKpp0YAzEYV6PQsmhEa3QbgpxDm29EHuuK1fw3y+FEjJwzZtQ 4R8NQt+weYUg3jtveOHKQsWfHeUojIhbYOispBw785tBUYu4OHve4jVW8z3bpSM7gv/c PTC2vHzwVll6QQZXq6Z8DEmL0EOG23qldY9a694eYpMJLUgd6OlGDzOsxvQsxGNgHSIW zigg== X-Gm-Message-State: ACrzQf1cMQVrKVjGSv5EBvfGRQBqwWVbXwnId1oHXbu3sKTNsDfQqVlm 9+HQnLH3mcNvrOuVu7D9lc5jzYsmGpO99l2/Kk6mZiowL7lkpXXmXpOKsbqBAXcFrUc6lyTCG4p syvPhfpAeAuM= X-Received: by 2002:a0c:a9d5:0:b0:4a6:3ec0:74ba with SMTP id c21-20020a0ca9d5000000b004a63ec074bamr15496724qvb.31.1664151071956; Sun, 25 Sep 2022 17:11:11 -0700 (PDT) X-Google-Smtp-Source: AMsMyM43SNkGk46w9cMJaZj4k1tISHBtvYVuTHN92lm9iGTPf61F+K085X1BBI2xtFUatWbkHwjQCA== X-Received: by 2002:a0c:a9d5:0:b0:4a6:3ec0:74ba with SMTP id c21-20020a0ca9d5000000b004a63ec074bamr15496698qvb.31.1664151071664; Sun, 25 Sep 2022 17:11:11 -0700 (PDT) Received: from x1n (bras-base-aurron9127w-grc-46-70-31-27-79.dsl.bell.ca. [70.31.27.79]) by smtp.gmail.com with ESMTPSA id bi16-20020a05620a319000b006b58d8f6181sm10636112qkb.72.2022.09.25.17.11.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 25 Sep 2022 17:11:11 -0700 (PDT) Date: Sun, 25 Sep 2022 20:11:09 -0400 From: Peter Xu To: Mike Kravetz Cc: Hugh Dickins , Axel Rasmussen , Yang Shi , Matthew Wilcox , syzbot , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, llvm@lists.linux.dev, nathan@kernel.org, ndesaulniers@google.com, songmuchun@bytedance.com, syzkaller-bugs@googlegroups.com, trix@redhat.com Subject: Re: [syzbot] general protection fault in PageHeadHuge Message-ID: References: <0000000000006c300705e95a59db@google.com> <7693a84-bdc2-27b5-2695-d0fe8566571f@google.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1664151076; a=rsa-sha256; cv=none; b=Jq5/fnmL7mz8S0CzZx0J/PSeKTtDzrzdjsWYTxwutB1ZgvTMW5ru2dw1CLa6kuFu1qDAjA edewY4tcc3Ty9LWcqiTXn8nVBH6cHSzmdYmrr9af3sSSw2JqovGMSha6pnxwhokWzchW/C dAlm3VvYO3eoth9/U31KibkR4493Vao= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HBO5wigp; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1664151076; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=aK8oEr6Mo1r3LJjWh8qC8wg2ZbpaqIAd/c7oyUSXWrA=; b=genUO5XP14XpsyWbaQhbiQRtIe5faYuORltk9OeKpbOO5vX150nuJNTsSgiIGkv8P4NruK 7/VpxZbILH36a3nkBjUlAjGivZnP6tv0NDxU7a68w18lahaCsbRK6Zra//jvNGPQTbK7dC jByIqaWozt7ShoIHJVSgeqXaGdrbofY= Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=HBO5wigp; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf05.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com X-Rspam-User: X-Stat-Signature: brqax6qzh463t9f45qpk57fhhw7wtknf X-Rspamd-Queue-Id: 50D2710000C X-Rspamd-Server: rspam06 X-HE-Tag: 1664151075-740059 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: On Sat, Sep 24, 2022 at 12:01:16PM -0700, Mike Kravetz wrote: > On 09/24/22 11:06, Peter Xu wrote: > > > > Sorry I forgot to reply on this one. > > > > I didn't try linux-next, but I can easily reproduce this with mm-unstable > > already, and I verified that Hugh's patch fixes the problem for shmem. > > > > When I was testing I found hugetlb selftest is broken too but with some > > other errors: > > > > $ sudo ./userfaultfd hugetlb 100 10 > > ... > > bounces: 6, mode: racing ver read, ERROR: unexpected write fault (errno=0, line=779) > > > > The failing check was making sure all MISSING events are not triggered by > > writes, but frankly I don't really know why it's required, and that check > > existed since the 1st commit when test was introduced. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c47174fc362a089b1125174258e53ef4a69ce6b8 > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/vm/userfaultfd.c?id=c47174fc362a089b1125174258e53ef4a69ce6b8#n291 > > > > And obviously some recent hugetlb-related change caused that to happen. > > > > Dropping that check can definitely work, but I'll have a closer look soon > > too to make sure I didn't miss something. Mike, please also let me know if > > you are aware of this problem. > > > > Peter, I am not aware of this problem. I really should make running ALL > hugetlb tests part of my regular routine. > > If you do not beat me to it, I will take a look in the next few days. Just to update - my bisection points to 00cdec99f3eb ("hugetlbfs: revert use i_mmap_rwsem to address page fault/truncate race", 2022-09-21). I don't understand how they are related so far, though. It should be a timing thing because the failure cannot be reproduced on a VM but only on the host, and it can also pass sometimes even on the host but rarely. Logically all the uffd messages in the stress test should be generated by the locking thread, upon: pthread_mutex_lock(area_mutex(area_dst, page_nr)); I thought a common scheme for lock() fast path should already be an userspace cmpxchg() and that should be a write fault already. For example, I did some stupid hack on the test and I can trigger the write check fault with anonymous easily with an explicit cmpxchg on byte offset 128: diff --git a/tools/testing/selftests/vm/userfaultfd.c b/tools/testing/selftests/vm/userfaultfd.c index 74babdbc02e5..a7d6938d4553 100644 --- a/tools/testing/selftests/vm/userfaultfd.c +++ b/tools/testing/selftests/vm/userfaultfd.c @@ -637,6 +637,10 @@ static void *locking_thread(void *arg) } else page_nr += 1; page_nr %= nr_pages; + char *ptr = area_dst + (page_nr * page_size) + 128; + char _old = 0, new = 1; + (void)__atomic_compare_exchange_n(ptr, &_old, new, false, + __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST); pthread_mutex_lock(area_mutex(area_dst, page_nr)); count = *area_count(area_dst, page_nr); if (count != count_verify[page_nr]) I'll need some more time thinking about it before I send a patch to drop the write check.. Thanks, -- Peter Xu