Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp687140imw; Fri, 15 Jul 2022 10:57:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tQuPIg5AQoRHXQN9sLY8JpZ+sij/hBXK5haaoCOQZz97VZ2fzTgV2ho3OA4VtGd7JdoKqT X-Received: by 2002:a05:6402:34ce:b0:43a:a4bb:27a6 with SMTP id w14-20020a05640234ce00b0043aa4bb27a6mr20444785edc.158.1657907821553; Fri, 15 Jul 2022 10:57:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657907821; cv=none; d=google.com; s=arc-20160816; b=HOSlLZlu1yQU/pMYY5vvO4rc71v9sQ3U9+a8btLu9UmJzv3HVbUgIfOX/s4GvKK9NR BGgUcwsve7QnmT4k0nYWriKdMBxxtIOXICw3rve5bIHyRCKqKcQ3QHDJrb8R+YNZ4MNm d4/lTbMKmrkaiMqwadOGIkaabA1zGsRrQbQoI0lQ22qMDFAUsE63u75goj05YrB0UqSO xSiP94kfFZHHZ7mNFCWXXpkXAdK5BWNnAyJiuMt6qsmHG5oO+k9YvOkL6C5aAVP77Tyx uwVXa9XYXpr3oyA1uj6/XU4ynk2LgKIvN0JUBWQlp9/YwxgsvToZDVCl8rtVO6tQvNw1 JF6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=8Ib/oWEoGNGAe7E62KsRy28LW0NH5ciDw5Z/ulJeK9w=; b=lZ3SnvvPppydBzjr//ZWXrHEw3nJk5d7VHPtPfjZ87+6h5k2I++SZoDSdMX5J4N7rN 6l9PGMBIxrF9i5gKRTkzoRQsFpVUoNChZsnhZOtV7mogQAokvUfzhLUeGs716E6ajLtE dwiHdvyaBGKEoiH6EU/zXe80kIuX2dMGHXzrZmP/i+IgFspKgrltxQl6zYDo5C6BV8fv LBI05rLqCJesr6wafOBura0AqfBvtyXI8MNF+SzJNZC4Nsq6fhSivetHS1SNQLL3Tpfh bjK7yYCBeRW4UKJnNvOUlWYcbLpOUryQFRgAPw37/McDnVmjy3lMlI3V3tBxlzcN4lKF 3R0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=tK1+WtJd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id m5-20020a50d7c5000000b0043aaf85f329si6646567edj.349.2022.07.15.10.56.36; Fri, 15 Jul 2022 10:57:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=tK1+WtJd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229513AbiGORv5 (ORCPT + 99 others); Fri, 15 Jul 2022 13:51:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54052 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbiGORvz (ORCPT ); Fri, 15 Jul 2022 13:51:55 -0400 Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1EC3052882 for ; Fri, 15 Jul 2022 10:51:53 -0700 (PDT) Received: by mail-il1-x135.google.com with SMTP id m20so2887256ili.3 for ; Fri, 15 Jul 2022 10:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Ib/oWEoGNGAe7E62KsRy28LW0NH5ciDw5Z/ulJeK9w=; b=tK1+WtJdz6cJlCyxtgNS1wI18oypYIQlGknflDLiNCH+xw8kUdINNgFKKm0sdyscsU ha8qV+52x/+QiIPqi7KhkKArzKCc0XA5iWw3Q6ZaR/w7Qfy74sEXpkdk+wgf+rLvFS60 ymUVB+Z5u31zayhCPJgC2Rrak2PA6eIxbbx3AUeytu+n3TX772N5HIx5mfN/0vpukQ+k LDtat6ZoyjAPQOeUjatqEOgurIyszwUl8A6zAzuX+qrJO7k/xBMFIloY/Y0jdcBSrAKw aEOhq0Pj/dpdVkkA0KRAR9mKbxvL3vEP+8DR5p4jqW2HrhU44ch/Epm4/tdtnxgQJ3vb Znhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Ib/oWEoGNGAe7E62KsRy28LW0NH5ciDw5Z/ulJeK9w=; b=Zo4rOkKqkqEKlVDvQm6yxmq64XBzbuUm+BkkvufFYH4djbFF+yP1jgp0Ee6pN3vyi0 wSpjaGWljx9Ow8kKAFxNwDhu5o+axEXhQp0UbENF5KWJPmdPzfGZSDN9g2hQNKdbkYL5 7ArLrIDYB6TARCUOBY4pcCB8oqus3jZXrnyePmtLv/HiD5zzMoujvNfGaUdS9MmxSALN EHZnC1hSQMBd5xlf+seOpz3Y6m2O9IMMcRG3T+MKHiZ7+yO52FP3d9OxCl4i5pb7SZig FOB3vR+9C+xKRwMLCxCtt+fzlkR+DVwa1aOZESM2NKhCAkkQ1Vnd7RS4LX15OedSgBbu m9pA== X-Gm-Message-State: AJIora9ZXNyCtQJX+jcRgwIIClaXJZMmQSiwx2hnqLgarw2nr+CeMQS/ PCLACvPH56rVgfmzuaXdZXYvmofrjXBya3x7BJJZFg== X-Received: by 2002:a05:6e02:1885:b0:2dc:5ede:8537 with SMTP id o5-20020a056e02188500b002dc5ede8537mr7729954ilu.275.1657907512419; Fri, 15 Jul 2022 10:51:52 -0700 (PDT) MIME-Version: 1.0 References: <20220712130542.18836-1-linmiaohe@huawei.com> <20220713102357.8328614813db01b569650ffd@linux-foundation.org> <402ae708-4c86-8feb-75c4-9339e1deac3b@huawei.com> In-Reply-To: From: Axel Rasmussen Date: Fri, 15 Jul 2022 10:51:16 -0700 Message-ID: Subject: Re: [PATCH] mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pte To: Peter Xu Cc: Miaohe Lin , Andrew Morton , Mike Kravetz , Muchun Song , Linux MM , LKML Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 15, 2022 at 10:39 AM Peter Xu wrote: > > On Fri, Jul 15, 2022 at 10:28:44AM -0700, Axel Rasmussen wrote: > > On Fri, Jul 15, 2022 at 10:07 AM Peter Xu wrote: > > > > > > On Fri, Jul 15, 2022 at 09:45:37AM -0700, Axel Rasmussen wrote: > > > > I agree we should either: > > > > - Update the UFFD selftest to exercise this case > > > > - Or, don't allow it, update vma_can_userfault() to also require VM_SHARED > > > > for VM_UFFD_MINOR registration. > > > > > > > > The first one is unfortunately not completely straightforward as Peter > > > > described. I would say it's probably not worth holding up this fix while we > > > > wait for it to happen? > > > > > > Agreed, Andrew has already queued it. It actually is a real fix since we > > > never forbid the user running private mappings upon minor faults, so > > > it's literally a bug in kernel irrelevant of the kselftest. > > > > > > > > > > > I don't really have a strong preference between the two. The second option > > > > is what I originally proposed in the first version of the minor fault > > > > series, so going back to that isn't a problem at least from my perspective. > > > > If in the future we find a real use case for this, we could always easily > > > > re-enable it and add selftests for it at that point. > > > > > > I'd go for fixing the test case if possible. Mike, would it be fine if we > > > go back to /dev/hugepages path based approach in the test case? > > > > One possible alternative, can we use memfd_create() with MFD_HUGE_*? > > This afaict lets us have an fd so we can create two mappings, > > without having to mount hugetlbfs, pass in a path to the test, ... > > Sounds good. :) We can also rework the shared hugetlb too. Wanna post a > patch? I can do that too, let me know otherwise. Thanks! Sure, I'll take a whack at it. > > -- > Peter Xu >