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 B22ADC433F5 for ; Wed, 2 Mar 2022 01:11:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D17338D0002; Tue, 1 Mar 2022 20:11:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id CC8438D0001; Tue, 1 Mar 2022 20:11:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B40AB8D0002; Tue, 1 Mar 2022 20:11:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0237.hostedemail.com [216.40.44.237]) by kanga.kvack.org (Postfix) with ESMTP id A1A6F8D0001 for ; Tue, 1 Mar 2022 20:11:22 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 60F5196768 for ; Wed, 2 Mar 2022 01:11:22 +0000 (UTC) X-FDA: 79197668004.18.A9E74D5 Received: from mail-ed1-f45.google.com (mail-ed1-f45.google.com [209.85.208.45]) by imf29.hostedemail.com (Postfix) with ESMTP id 6F41312000B for ; Wed, 2 Mar 2022 01:11:21 +0000 (UTC) Received: by mail-ed1-f45.google.com with SMTP id q17so193526edd.4 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=IDPZ5w8/5qHyHHaBHGMoRuhIdvCdKNRNpN7MfN6oymhjl1dzafU4yufvC3ZG7pfwIf 4dI7Kd+MEyk3ONPCTTudDywaheGyNUStM/90QCDGQ92kzjjMxy3zvJMBgxXt9wbEtZtm Af7vAe9aip+Qhs1+PjkYMUjPzDeYobz6hqNzProOZCKNE8zQv8zIByE+OyjTSQYrjGLp 5nkoLF96Hm6STK6UwFgdqN0eEgPv4l+dCs0qi1X2Wo9mT7FD5+oKoa4WJYnipJ13hNA4 xwEhR8iD2k0P3A2Qfxqgp3NpcUUuNbfAyICQ2e53q1D6XHj1e7dBa51Q/q2pZ98wNvY8 ew1w== X-Gm-Message-State: AOAM532QIhLbzvbAxnSEaFwF+s9IElgNudTZ6A6UoelSt3wpmryRy+MJ bVxxKnLJyKNJaqjT96t7jZtiKmVXVzOxL2nAlQU= X-Google-Smtp-Source: ABdhPJxXRIlLn/L9tVzObJU1m7g2HQIHiyG8p73bYywPy5UoKAvwNBi0PRUT+7lx2VxrfDypf654hz0gXIRyYwgOSk8= 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-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 6F41312000B X-Rspam-User: Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=BDE3x5UJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of yongw.pur@gmail.com designates 209.85.208.45 as permitted sender) smtp.mailfrom=yongw.pur@gmail.com X-Stat-Signature: 4dhy1ef76373khp5eo9dyu4ot96incfi X-HE-Tag: 1646183481-787806 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: 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);