Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp676709pxm; Wed, 2 Mar 2022 06:25:24 -0800 (PST) X-Google-Smtp-Source: ABdhPJz2VMpMQeb9+S8e1DJ7fmPWIhpldQhn44ndQCDLnQ5IF5WxuGHp/r3ViFVPP3ay+dLyC4hy X-Received: by 2002:a05:6a00:14ca:b0:4cf:1930:9d67 with SMTP id w10-20020a056a0014ca00b004cf19309d67mr32821087pfu.55.1646231123847; Wed, 02 Mar 2022 06:25:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646231123; cv=none; d=google.com; s=arc-20160816; b=Px8me0IhE3kXn1BqfMevsJsGBTo5fj8LqtQ9IBo8WBWRMr8+vFqRlFBseNQ1oeY50U g84for849OquKP9Y71qoafkbTd5h3uGa82EpwEmACVx+q7FgzBc3CYZYMBsVrYGoN7H1 ledaFYk5TyP6Uw7HSI5ADfETOBDXfCQLeyxk2ImRX+K+JohbVKFnYFJzWz51i+9HmmEq /yoVSpZDQ3vKFgh7uvU/wGmx9o78RJ1c4/X+sjvYxeZUmViZE2QDd3RJ4Uw3bOT9ScgO Br/ZHan5SGaY1lGwrlZ3k4iotBCw2OUZEP5lo87IloBykKAPn+2VW5WeCoYESoIrMrFF a6Gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=BVjhXQ5SNbO/pW5hizdV6mz5H8/dxovfwEQSMmhkzAU=; b=FtPCWeB4TNcwgbVLzSxSC29ImSF1XoRdA17OQjR6EjILBNZe5ITV1j5kilyR1cW2BT JnyOOYY1eflhjh8bRR6CF56yBLxB+ngDIUpu3TkEsDTuhPv+1Xw3rFEzvA5z43wcML2U MvxIG7lOxtEh0eb71n02tgxopKEU6sroBklvnTmtbxhBmAVv57aZW4O/h2wkv5gxivOv noaGiuu+07nMTZ+glOKPq246XptSgiOoinWIRMoAjGYJZn72gl8CzQlqlz3J7i6XTCj+ 9uzq2XrEjNEfI8HymzcS7ERfDM5KlmF3XXeTD9eGnWKvHXJLwUJOAFzoWZFF3f9SuvMm OURA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=BDE3x5UJ; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i76-20020a639d4f000000b003784f4488cdsi15198215pgd.180.2022.03.02.06.25.05; Wed, 02 Mar 2022 06:25:23 -0800 (PST) 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=@gmail.com header.s=20210112 header.b=BDE3x5UJ; 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=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234875AbiCBBMH (ORCPT + 99 others); Tue, 1 Mar 2022 20:12:07 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48894 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbiCBBME (ORCPT ); Tue, 1 Mar 2022 20:12:04 -0500 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B051D98F50 for ; Tue, 1 Mar 2022 17:11:21 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id s24so191207edr.5 for ; Tue, 01 Mar 2022 17:11:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BVjhXQ5SNbO/pW5hizdV6mz5H8/dxovfwEQSMmhkzAU=; b=BDE3x5UJY+SDX6EudoqgIAwzgA4berHul9/6j7AEMmGHDtbDjJToYSV99AFzkKl55s lAf/KtgPvl04/7/fhjJMImPB7CK7DRXZrslXzpNiqZqyUWWS1W09QyLDoT2PWrB7TcMl SV72s46dP8bhvQ4mkOebTu9rioLLorOT0ag29vckNmOoXSZzIWc10e6qoHeQG7ZC07uN DuiTLBr7PoWW24P4LqSx8+vwzgA1x75uveBla4chuEgbuoxzxjP3+L86R/KD3giaOg0O YrFeN9lzWUTcHqWpUMlTh+U9y+3SnAxRMkUEBPQXAWR9RaKPFvTJo2eHk2WidG7gjzIY 2rJg== 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:content-transfer-encoding; bh=BVjhXQ5SNbO/pW5hizdV6mz5H8/dxovfwEQSMmhkzAU=; b=6gVjwX9Sq6kL0eNclOw+thp0x93X/CDTXCu5EBE55iQh9c0+V9KQ0/oiVi0IHfWMbR 7F1VoGkI8ihGJBiXLvU3c8MUrUpRxDkW5BSZd5amHRMozj8cGLlBVPinRqoUR5qOc0/n XGrVkzvIsUm8s4v+JXdZPshP8uULHU8X8Q1XBK/oEO6MNL8DgzN06zv+x3qgVrcUaXDi JWuUHMGfzTuRRd81IF2hIA1fr7f9qqE8CbxJJrIO9eJm/PIWwdaPkynYCrjmMwOTr8uX llC9/jV7o31pTh8/XBVy4eeuXd6QNvLr2tjfvH6vG7qGtP0vevKa3g/l9rKc+SyB1nE/ k5EQ== X-Gm-Message-State: AOAM532YmlFPM91s4RRCMx4eJZ+033nBgDAQNDOp6igbmzllmFUTZX2o hvYJFZ6+0xSUT6Rh3NB2vyY4h55cTw1DGOeG3Wk= X-Received: by 2002:a50:da4b:0:b0:40f:28f0:c2c0 with SMTP id a11-20020a50da4b000000b0040f28f0c2c0mr26884959edk.374.1646183480055; Tue, 01 Mar 2022 17:11:20 -0800 (PST) MIME-Version: 1.0 References: <20220215073743.1769979-1-cgel.zte@gmail.com> <1f486393-3829-4618-39a1-931afc580835@oracle.com> <8986d97-3933-8fa7-abba-aabd67924bc2@google.com> In-Reply-To: From: yong w Date: Wed, 2 Mar 2022 09:11:08 +0800 Message-ID: Subject: Re: [PATCH] memfd: fix F_SEAL_WRITE after shmem huge page allocated To: Hugh Dickins Cc: Andrew Morton , Mike Kravetz , Matthew Wilcox , cgel.zte@gmail.com, kirill@shutemov.name, songliubraving@fb.com, Linux MM , LKML , yang.yang29@zte.com.cn, wang.yong12@zte.com.cn Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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 Hello, this patch does not apply to the 4.19 kernel. Is it necessary to make corresponding patches for each stable version? Thanks. Hugh Dickins =E4=BA=8E2022=E5=B9=B42=E6=9C=8827=E6=97=A5= =E5=91=A8=E6=97=A5 14:41=E5=86=99=E9=81=93=EF=BC=9A > > Wangyong reports: after enabling tmpfs filesystem to support > transparent hugepage with the following command: > > echo always > /sys/kernel/mm/transparent_hugepage/shmem_enabled > > the docker program tries to add F_SEAL_WRITE through the following > command, but it fails unexpectedly with errno EBUSY: > > fcntl(5, F_ADD_SEALS, F_SEAL_WRITE) =3D -1. > > That is because memfd_tag_pins() and memfd_wait_for_pins() were never > updated for shmem huge pages: checking page_mapcount() against > page_count() is hopeless on THP subpages - they need to check > total_mapcount() against page_count() on THP heads only. > > Make memfd_tag_pins() (compared > 1) as strict as memfd_wait_for_pins() > (compared !=3D 1): either can be justified, but given the non-atomic > total_mapcount() calculation, it is better now to be strict. Bear in > mind that total_mapcount() itself scans all of the THP subpages, when > choosing to take an XA_CHECK_SCHED latency break. > > Also fix the unlikely xa_is_value() case in memfd_wait_for_pins(): if a > page has been swapped out since memfd_tag_pins(), then its refcount must > have fallen, and so it can safely be untagged. > > Reported-by: Zeal Robot > Reported-by: wangyong > Signed-off-by: Hugh Dickins > Cc: > --- > Andrew, please remove > fix-shmem-huge-page-failed-to-set-f_seal_write-attribute-problem.patch > fix-shmem-huge-page-failed-to-set-f_seal_write-attribute-problem-fix.patc= h > from mmotm, and replace them by this patch against 5.17-rc5: > wangyong's patch did not handle the case of pte-mapped huge pages, and I > had this one from earlier, when I found the same issue with MFD_HUGEPAGE > (but MFD_HUGEPAGE did not go in, so I didn't post this one, forgetting > the transparent_hugepage/shmem_enabled case). > > mm/memfd.c | 40 ++++++++++++++++++++++++++++------------ > 1 file changed, 28 insertions(+), 12 deletions(-) > > --- 5.17-rc5/mm/memfd.c > +++ linux/mm/memfd.c > @@ -31,20 +31,28 @@ > static void memfd_tag_pins(struct xa_state *xas) > { > struct page *page; > - unsigned int tagged =3D 0; > + int latency =3D 0; > + int cache_count; > > lru_add_drain(); > > xas_lock_irq(xas); > xas_for_each(xas, page, ULONG_MAX) { > - if (xa_is_value(page)) > - continue; > - page =3D find_subpage(page, xas->xa_index); > - if (page_count(page) - page_mapcount(page) > 1) > + cache_count =3D 1; > + if (!xa_is_value(page) && > + PageTransHuge(page) && !PageHuge(page)) > + cache_count =3D HPAGE_PMD_NR; > + > + if (!xa_is_value(page) && > + page_count(page) - total_mapcount(page) !=3D cache_co= unt) > xas_set_mark(xas, MEMFD_TAG_PINNED); > + if (cache_count !=3D 1) > + xas_set(xas, page->index + cache_count); > > - if (++tagged % XA_CHECK_SCHED) > + latency +=3D cache_count; > + if (latency < XA_CHECK_SCHED) > continue; > + latency =3D 0; > > xas_pause(xas); > xas_unlock_irq(xas); > @@ -73,7 +81,8 @@ static int memfd_wait_for_pins(struct ad > > error =3D 0; > for (scan =3D 0; scan <=3D LAST_SCAN; scan++) { > - unsigned int tagged =3D 0; > + int latency =3D 0; > + int cache_count; > > if (!xas_marked(&xas, MEMFD_TAG_PINNED)) > break; > @@ -87,10 +96,14 @@ static int memfd_wait_for_pins(struct ad > xas_lock_irq(&xas); > xas_for_each_marked(&xas, page, ULONG_MAX, MEMFD_TAG_PINN= ED) { > bool clear =3D true; > - if (xa_is_value(page)) > - continue; > - page =3D find_subpage(page, xas.xa_index); > - if (page_count(page) - page_mapcount(page) !=3D 1= ) { > + > + cache_count =3D 1; > + if (!xa_is_value(page) && > + PageTransHuge(page) && !PageHuge(page)) > + cache_count =3D HPAGE_PMD_NR; > + > + if (!xa_is_value(page) && cache_count !=3D > + page_count(page) - total_mapcount(page)) { > /* > * On the last scan, we clean up all thos= e tags > * we inserted; but make a note that we s= till > @@ -103,8 +116,11 @@ static int memfd_wait_for_pins(struct ad > } > if (clear) > xas_clear_mark(&xas, MEMFD_TAG_PINNED); > - if (++tagged % XA_CHECK_SCHED) > + > + latency +=3D cache_count; > + if (latency < XA_CHECK_SCHED) > continue; > + latency =3D 0; > > xas_pause(&xas); > xas_unlock_irq(&xas);