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 AD385C48260 for ; Fri, 16 Feb 2024 06:55:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F34188D0006; Fri, 16 Feb 2024 01:55:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EBC9B8D0001; Fri, 16 Feb 2024 01:55:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D5CB48D0006; Fri, 16 Feb 2024 01:55:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id BF4A38D0001 for ; Fri, 16 Feb 2024 01:55:10 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8B9251C0102 for ; Fri, 16 Feb 2024 06:55:10 +0000 (UTC) X-FDA: 81796755180.08.A8B4B84 Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by imf26.hostedemail.com (Postfix) with ESMTP id B8B96140007 for ; Fri, 16 Feb 2024 06:55:08 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jbgu0KWK; spf=pass (imf26.hostedemail.com: domain of hughd@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708066508; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L/Ev7zx1OY2xavG089OEf6t+LzZ1+fWZhEmI/a93zMk=; b=TYXbB0VbAlHjDMnKcpL6DqcIuxVmRdg7Rn7DEkFQ7GRvKv9zw/GPuYtvgJUFIPIKwh5mNs zoRCREWUMpMUwcnge4lQA7Fb5pxoObsbsi2dweDNEWV44anNYZVSyZueS5Eg7VgqrFO3MI kpP/Y/BuvUMuiBGCPOZqn7wOlWvUl7c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708066508; a=rsa-sha256; cv=none; b=KPIcQO7Hnovq3hDuISlg6zUsHRjSbMCxt+sGpTcGpOxTffT6tcHohqdVzRADExCZU+pOjY zGxcFLg1AGVKM2h06LXQYY+VIq648pYa6BPjyl/DjaAcdUhPl9PQ6PiKAaU1yyIluAV7gS HPsxxTGQjUwIJpENELozhEjvvBNT9Wk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jbgu0KWK; spf=pass (imf26.hostedemail.com: domain of hughd@google.com designates 209.85.219.169 as permitted sender) smtp.mailfrom=hughd@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-dcc4de7d901so1456639276.0 for ; Thu, 15 Feb 2024 22:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708066508; x=1708671308; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=L/Ev7zx1OY2xavG089OEf6t+LzZ1+fWZhEmI/a93zMk=; b=Jbgu0KWKpU4h1H9g+9KDgTUFAqrTnAe18FaAhg7hUgJ8d/EVoLx4ZMQ9y2SECYh/Zl vvVTc/tA2SYc3DDpuAa1VslDK9pg8LO52zzaRjBuK3Nc1skgtqHBuHsypwcCIFKrcy/V bQtyh2tE4w9dBgiB28gtW3fx3LCGkrYRRSGqK9ru/i2ZYy7g3agOWCQLqxgjGsQpLRsC /MmuOnVkNkvL6M4cCVYuTPsR8ss+XuTCFIRjiMRpPmlBex3YN2vzs2D98Kzk5AYI15D3 3O78PuO9dREctFumuehAmFuMGOust2jzlHYmvHd7t+CrFieiBv2ASEoE0fl9SlLO9Ts1 Dhkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708066508; x=1708671308; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=L/Ev7zx1OY2xavG089OEf6t+LzZ1+fWZhEmI/a93zMk=; b=jhhUOnLswDzwjc52PamdVrBvGOPTy/qbaA5ygCYhTLvycpimNn9ujb+b6tCpBQY79F tQdqTZsILUEE9T3TTwKYs6CcFJFv/gZ6iQhAXW5NrXfAlXShSccQaEP9mdHew3hDgeA6 GG1L/31Hs5YSP9y9qo8J0Kxg9QKiNCM1pAOli+n9723cWvlBeEi7pvRshr3+jvKVRFGA bYMWULRPyKBGqtKZf3IFogG6dstwDspp7tO9HYHH1ndsi2vKF+xerstGsZSYIkpbz6Tt 6Iq5FfmcbNqff+NPN1hu0OPMaWaajbYoUJLyr4QFGO7UKuNzj/yrS9SZJ5CxB8GyFkFm Xasg== X-Forwarded-Encrypted: i=1; AJvYcCWhZyCzWWjXNd+ZnhgImgks8XxrPZtfyORJ14gDvdFfjUZ3sInbrwMQ9iMrCRy1J67YjxAymHcfYVEXoFKYWL/sCBs= X-Gm-Message-State: AOJu0Yz883EaU4C/tjw7rHV1NsXorBFH545j+MGqHTx9cSup8Xjx+UaZ dj01lj5Od7rUMGXVq3ahzPMKvYxLxPxp0bjlQdESFuZruYdSC2ixmBtQ62RbvQ== X-Google-Smtp-Source: AGHT+IHiZawZ5tPVjTUC1usJpsLxHJCItFfeYjDx3TyanwgMlnEkKbuj3kFT6PcFPQDRIjp/XIHWOg== X-Received: by 2002:a25:f903:0:b0:dc6:c617:7ca with SMTP id q3-20020a25f903000000b00dc6c61707camr4004856ybe.29.1708066507689; Thu, 15 Feb 2024 22:55:07 -0800 (PST) Received: from darker.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id r185-20020a25c1c2000000b00dcda90f43d7sm207542ybf.59.2024.02.15.22.55.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 15 Feb 2024 22:55:07 -0800 (PST) Date: Thu, 15 Feb 2024 22:55:05 -0800 (PST) From: Hugh Dickins To: Christoph Hellwig cc: Chandan Babu R , "Darrick J. Wong" , Hugh Dickins , Andrew Morton , linux-xfs@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 12/20] xfs: don't modify file and inode flags for shmem files In-Reply-To: <20240129143502.189370-13-hch@lst.de> Message-ID: References: <20240129143502.189370-1-hch@lst.de> <20240129143502.189370-13-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: B8B96140007 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 3ahyomokias9qfky943cossbekeefgof X-HE-Tag: 1708066508-170370 X-HE-Meta: U2FsdGVkX1+MMtynm5MzB+mqZLVJh7VmHnipW5S7r+tdGXGHqBLkQAzOLyPdyaLzNsyvGqWYNGWVwRVl7MwdtkYerX0GVI1rijqSqjdMOZfVP8sQgZsLmdd2zbuOIvJCSfb7EqtJweaAQfT/OjrA9k0i9e/OmlmG4iXG3PgUXi7PClN+iikqsS8VrCLcm4Cx9j63dJwcrpJy8PMEk9MxIKfu0eGhgkVn4jU/kbC/dOlkTRec4zd6Kphb7ucSQH+UJ8PkSDeg3hh/b49dK/sE12XJhuIJ8stsE/lqEK1H6xplvyYUYYlNkK7V3+/v05xR9drZk2NcN1PRGNiFsC/JhN/UlfsnpUITjvTbcjB2Qh8Q5vZVlFwoC2cfqVGbAW4Ie3oRiPmb94t5ey6KSiuQHOIK70Id5QbZ1lzngX2Ai4VkJVfiqiaDInI5Sf7sHnmrixpLuLwtOchRz75hr+u2QIiQdBdrWgwcgsqwr6ymvNELg9kSs8laJwyC4mh7RjoLBgYSQ7ZhEgIY0jFdfof+OpXoZubtfHEW5s7/vvNxWbBuxZsXlN3kRdE+MhXXyUpOj2sU9ldr/wbIjUop4DL6cBgiBLjbgwgb+sFPPi2PEuN7z5B1lIhZkxg6U1Y23YYX00oc+KIaCfylwfOCDigsGNxiyQ5xlLN/RRr9ATKUo+Prpcz7sQZIDg+lkeuclVe/RcGw5xXj2A/mF5Eu6b+B2QcRTTASvmX0N9oq7z3UzltKl0yto5wNl4uPx00/16n+xdh2LOLvIxYlU5yncbG7GMIiw/2UPTZsxulampKHA2xOoI4tFOe9Fs9CbP5lp3rZf5bHaWNyEXTJWEXJrzUJ0vWv4T5PFx4rHhPHJ46pk9mNhB9wjZYEblOgfy/BLwRNba0vjMHf3Ux7dEYqD4DSQFlCv74x4kSHBitrNA+BRbZSs6MVSTaOookFHdopPsF4FEh74z1JfHa0JMhuG0f QXtj36JI jKBXu9MxlVEAeHcHwrSf7d2ugtNGos8truO5v8HTalPCBG66N7j5tMLYazYrjpi9TEnEqZrro8UEgJitwLXjumPkPkk3qqY9yB23cHsVeFOGiQ+wkowoQqLf98CINPBsZmp0oyWy6h6WvBn/ogirPfZjiqt+LJkIziXm/v2ivQ1JmJBLMN4BK75kgMhHZVkcHYnZlVFnj50cUP6H/v2gA8PgfyGTyZQ6sHZCSJwCcrFJPN3gk2c4oBc+tQ3Mp9ezKTv2+ojI7cpz0ygFjRocJ5JfredW+0K1UN2xV++WXyKv/D7uP6lj0MCqd44WA/6+nkwkz1cXPtjGE3IA= 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: List-Subscribe: List-Unsubscribe: On Mon, 29 Jan 2024, Christoph Hellwig wrote: > shmem_file_setup is explicitly intended for a file that can be > fully read and written by kernel users without restrictions. Don't > poke into internals to change random flags in the file or inode. > > Signed-off-by: Christoph Hellwig > Reviewed-by: Darrick J. Wong > --- > fs/xfs/scrub/xfile.c | 17 +---------------- > 1 file changed, 1 insertion(+), 16 deletions(-) > > diff --git a/fs/xfs/scrub/xfile.c b/fs/xfs/scrub/xfile.c > index 7785afacf21809..7e915385ef0011 100644 > --- a/fs/xfs/scrub/xfile.c > +++ b/fs/xfs/scrub/xfile.c > @@ -68,28 +68,13 @@ xfile_create( > if (!xf) > return -ENOMEM; > > - xf->file = shmem_file_setup(description, isize, 0); > + xf->file = shmem_kernel_file_setup(description, isize, 0); I think you probably want to say VM_NORESERVE there, instead of 0. I see from the (deleted) comment below that "We want a large sparse file", and the VM_NORESERVE does become important on large sparse files. It is how normal flles and memfds are set up (whereas SysV SHM says 0 to reserve size at setup). It affects the Committed_AS seen in /proc/meminfo, and how __vm_enough_memory() behaves (depending on /proc/sys/vm/overcommit_memory). Hmm, I think mm/shmem.c is not prepared for the case of flags 0 there, and then the file growing bigger than isize later on - I suspect that Committed_AS will end up underflowing. shmem.c ought to be defensive against that, sure, but I don't think such a case has come up before. I see you have two calls to xfile_create(), one with what looks like a known fixed non-0 isize, but one with isize 0 which will grow later. > if (IS_ERR(xf->file)) { > error = PTR_ERR(xf->file); > goto out_xfile; > } > > - /* > - * We want a large sparse file that we can pread, pwrite, and seek. > - * xfile users are responsible for keeping the xfile hidden away from > - * all other callers, so we skip timestamp updates and security checks. > - * Make the inode only accessible by root, just in case the xfile ever > - * escapes. > - */ > - xf->file->f_mode |= FMODE_PREAD | FMODE_PWRITE | FMODE_NOCMTIME | > - FMODE_LSEEK; > - xf->file->f_flags |= O_RDWR | O_LARGEFILE | O_NOATIME; I've forgotten offhand how O_LARGEFILE propagates down to where a file gets grown, and I realize that 32-bit is not your primary concern: but please double-check that it works correctly without O_LARGEFILE now (maybe the new folio ops avoid everywhere that largefile would be checked). Hugh > inode = file_inode(xf->file); > - inode->i_flags |= S_PRIVATE | S_NOCMTIME | S_NOATIME; > - inode->i_mode &= ~0177; > - inode->i_uid = GLOBAL_ROOT_UID; > - inode->i_gid = GLOBAL_ROOT_GID; > - > lockdep_set_class(&inode->i_rwsem, &xfile_i_mutex_key); > > trace_xfile_create(xf); > -- > 2.39.2