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 842ACC433F5 for ; Wed, 16 Feb 2022 06:57:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F3F376B0078; Wed, 16 Feb 2022 01:57:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EEEC46B007B; Wed, 16 Feb 2022 01:57:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D68046B007D; Wed, 16 Feb 2022 01:57:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id C43396B0078 for ; Wed, 16 Feb 2022 01:57:46 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8928C234CB for ; Wed, 16 Feb 2022 06:57:46 +0000 (UTC) X-FDA: 79147737732.01.50CC053 Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by imf21.hostedemail.com (Postfix) with ESMTP id 2717A1C000C for ; Wed, 16 Feb 2022 06:57:46 +0000 (UTC) Received: by mail-qt1-f171.google.com with SMTP id ca12so1270006qtb.4 for ; Tue, 15 Feb 2022 22:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:from:to:cc:subject:references:mime-version :content-disposition:in-reply-to; bh=IV3FPtEnsUXk8oMp48bq68PERCfU0wMBWQO4LKNQXdQ=; b=QIV+jlqu6fvKp1QYlRNOIShzVZOFKv9OjsVpegSb9qgT61agwFKN322mX6v+9sangF w34t+f6KeN9DpwhHIf8QhPzuo9ToQw6NALxOmv3JHkV5VfLrIcivKKJxhblm5AWU9iYT hRCRB/9v3rFE3yLFIIp/xYBPuZII9s25CpaxpH32gaDhA2aMJBvOZjN1kAvxJzkN7qqZ N067oLE8K9u56fSV3gRRubAnlc84SmAhQTkCO7hYS2Xtz6+Cqw2Xr505Dlie9mheFg4H MzfWFahN0qM8KWDPf+egZunuYdmf3xL2rOylg8k+6A9fvvmog2SclAAh0cJFTDX/qbZk JcZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:from:to:cc:subject:references :mime-version:content-disposition:in-reply-to; bh=IV3FPtEnsUXk8oMp48bq68PERCfU0wMBWQO4LKNQXdQ=; b=nJfHu7BuBzYguhutMIb8o/cYFlkzvSPtnsIDhhjdySgNWThHDRSf1X0bdMKyz89Fup xoS+Nx3YqVzvRGoyHGRbaiHp3avB0Z7xRuQr2rtVNoETAkptB2jpJrq0tgpDj58TdZXO QambdamneBAXBk8Y9WW5ogPpUJlNEMKQdcWPkfGb40Ye6UGseZ36gUeSht0nE9Qu0WqO EYcAcqW+z7cd/LZJzxMmqZ8U5Fm9wALBIyAc0G/wtanS4qnCIzipHezGJ54xIahFjhc4 RM7/l/SaTYV6ew5pxMCz+R9ckWpfCT/v1aeeIsLm7qz8JG8LNEFDblCXOZ2Qh9Amzznr P97Q== X-Gm-Message-State: AOAM533+mMTQcSY+zvRSvL5zVs8fM5z367frK4B1xfrIgsETvwmDYymf gpJh1+8pw8AvPD2LEdslJxc= X-Google-Smtp-Source: ABdhPJy5Y5fq7G10KLe7Xka551ZsrYaR34pM3sRqhmoK2ERIiKSseTy5n1RVa47e+qktgUrP5S93JA== X-Received: by 2002:ac8:7f49:0:b0:2cd:a931:a423 with SMTP id g9-20020ac87f49000000b002cda931a423mr1012389qtk.650.1644994665431; Tue, 15 Feb 2022 22:57:45 -0800 (PST) Received: from localhost ([193.203.214.57]) by smtp.gmail.com with ESMTPSA id e16sm21727706qty.47.2022.02.15.22.57.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Feb 2022 22:57:44 -0800 (PST) Message-ID: <620ca068.1c69fb81.d3595.69fa@mx.google.com> X-Google-Original-Message-ID: <20220216065742.GA1864737@cgel.zte@gmail.com> Date: Wed, 16 Feb 2022 06:57:42 +0000 From: CGEL To: Andrew Morton 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 Subject: Re: [PATCH linux-next] Fix shmem huge page failed to set F_SEAL_WRITE attribute problem References: <20220215073743.1769979-1-cgel.zte@gmail.com> <20220215141236.de1a3eca3a8a52d04507c50f@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220215141236.de1a3eca3a8a52d04507c50f@linux-foundation.org> X-Rspamd-Queue-Id: 2717A1C000C X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=QIV+jlqu; spf=pass (imf21.hostedemail.com: domain of cgel.zte@gmail.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=cgel.zte@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-Stat-Signature: gghi6ktbkw3tqgaa98f6c6qdeqngm1gr X-Rspamd-Server: rspam11 X-HE-Tag: 1644994666-485082 X-Bogosity: Ham, tests=bogofilter, spamicity=0.002055, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 > > > > 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.