All of lore.kernel.org
 help / color / mirror / Atom feed
From: CGEL <cgel.zte@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: hughd@google.com, mike.kravetz@oracle.com, kirill@shutemov.name,
	songliubraving@fb.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, yang.yang29@zte.com.cn,
	wang.yong12@zte.com.cn, Zeal Robot <zealci@zte.com.cn>
Subject: Re: [PATCH linux-next] Fix shmem huge page failed to set F_SEAL_WRITE attribute problem
Date: Wed, 16 Feb 2022 06:57:42 +0000	[thread overview]
Message-ID: <620ca068.1c69fb81.d3595.69fa@mx.google.com> (raw)
In-Reply-To: <20220215141236.de1a3eca3a8a52d04507c50f@linux-foundation.org>

O Tue, Feb 15, 2022 at 02:12:36PM -0800, Andrew Morton wrote:
> On Tue, 15 Feb 2022 07:37:43 +0000 cgel.zte@gmail.com wrote:
> 
> > From: wangyong <wang.yong12@zte.com.cn>
> > 
> > After enabling tmpfs filesystem to support transparent hugepage with the
> > following command:
> >  echo always > /sys/kernel/mm/transparent_hugepage/shmem_enabled
> > The docker program adds F_SEAL_WRITE through the following command will
> > prompt EBUSY.
> >  fcntl(5, F_ADD_SEALS, F_SEAL_WRITE)=-1.
> > 
> > It is found that in memfd_wait_for_pins function, the page_count of
> > hugepage is 512 and page_mapcount is 0, which does not meet the
> > conditions:
> >  page_count(page) - page_mapcount(page) != 1.
> > But the page is not busy at this time, therefore, the page_order of
> > hugepage should be taken into account in the calculation.
> 
> What are the real-world runtime effects of this?
>
The problem I encounter is that the "docker-runc run busybox" command
fails, and then the container cannot be started. The following alarm is
prompted:
[pid  1412] fcntl(5, F_ADD_SEALS,F_SEAL_SEAL|F_SEAL_SHRINK|F_SEAL_GROW|F_SEAL_WRITE) = -1 EBUSY (Device or resource busy)
[pid  1412] close(5)                    = 0
[pid  1412] write(2, "nsenter: could not ensure we are"..., 74) = 74
...
[pid  1491] write(3, "\33[31mERRO\33[0m[0005] container_li"..., 166) = 166
[pid  1491] write(2, "container_linux.go:299: starting"..., 144container_linux.go:299: starting container process caused
"process_linux.go:245: running exec setns process for init caused \"exit statu" ) = 144

I'm not sure how this will affect other situations.
> Do we think that this fix (or one similar to it) should be backported
> into -stable kernels?
> 
> If "yes" then Mike's 5d752600a8c373 ("mm: restructure memfd code") will
> get in the way because it moved lots of code around.
> 
Yes, 4.14 does not have this patch, but 4.19 does.
In addition, Kirill A. Shutemov's 800d8c63b2e989c2e349632d1648119bf5862f01 
(shmem: add huge pages support) is not included in 4.4, but it is available in 4.14.

> But then, that's four years old and perhaps that's far enough back in
> time.

Thanks.


  reply	other threads:[~2022-02-16  6:57 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-15  7:37 [PATCH linux-next] Fix shmem huge page failed to set F_SEAL_WRITE attribute problem cgel.zte
2022-02-15 22:12 ` Andrew Morton
2022-02-16  6:57   ` CGEL [this message]
2022-02-17  1:00 ` Mike Kravetz
2022-02-17  1:25   ` Hugh Dickins
2022-02-17 13:43     ` Matthew Wilcox
2022-02-27  3:00       ` Hugh Dickins
2022-02-27  5:20         ` [PATCH] memfd: fix F_SEAL_WRITE after shmem huge page allocated Hugh Dickins
2022-03-02  1:11           ` yong w
2022-03-02 19:52             ` Hugh Dickins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=620ca068.1c69fb81.d3595.69fa@mx.google.com \
    --to=cgel.zte@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=hughd@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=songliubraving@fb.com \
    --cc=wang.yong12@zte.com.cn \
    --cc=yang.yang29@zte.com.cn \
    --cc=zealci@zte.com.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.