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 A77D9C47DA7 for ; Wed, 17 Jan 2024 20:51:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 317376B0078; Wed, 17 Jan 2024 15:51:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2A06B6B007E; Wed, 17 Jan 2024 15:51:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1683E6B0080; Wed, 17 Jan 2024 15:51:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 011876B0078 for ; Wed, 17 Jan 2024 15:51:39 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id ABE29401D5 for ; Wed, 17 Jan 2024 20:51:39 +0000 (UTC) X-FDA: 81689999118.23.E5FC593 Received: from vps.thesusis.net (vps.thesusis.net [34.202.238.73]) by imf25.hostedemail.com (Postfix) with ESMTP id 16118A0014 for ; Wed, 17 Jan 2024 20:51:37 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of phill@thesusis.net designates 34.202.238.73 as permitted sender) smtp.mailfrom=phill@thesusis.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705524698; 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; bh=jstidIHRly/wiUnDeaSvGTelC4jOAb96HNdpRfqzuo8=; b=KM5OAuM+Gw4Jb7CmWwAmN5UEb9no0E+VNVxcYyf2U5W1liNnlNRqoEjxh1rViJ7UI6TCC8 erNR+lCYLpXpive6rlLWG/n/1CHFRLuHJZpeaVBKKlEPQ558+Wrr9fOtTTc7ce09dBLyeG 2v/Zrvr/g9cp76ylM4L7GmgskuhHFAk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705524698; a=rsa-sha256; cv=none; b=JNKK7YTNEPhpIi9uPRPVdkV1nVYOQV6QieZt3J0NXykunhGNIGT3De43F4wDVOSYUdqXL0 syaNwHLhug6BMXEYgNwc15RXKp4v4VbJX3F1vHSiDcLJRyPQpf22UuQ6HEx1SMmUltfp8t AjOSNc2dLU1BYjWlRf2qwAsLfaYLBPo= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of phill@thesusis.net designates 34.202.238.73 as permitted sender) smtp.mailfrom=phill@thesusis.net; dmarc=none Received: by vps.thesusis.net (Postfix, from userid 1000) id 3AF89153C25; Wed, 17 Jan 2024 15:51:37 -0500 (EST) From: Phillip Susi To: Matthew Wilcox , Jan Kara Cc: Christian Brauner , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-btrfs@vger.kernel.org, linux-block@vger.kernel.org, Christoph Hellwig Subject: Re: [LSF/MM/BPF TOPIC] Dropping page cache of individual fs In-Reply-To: References: <20240116-tagelang-zugnummer-349edd1b5792@brauner> <20240116114519.jcktectmk2thgagw@quack3> <20240117-tupfen-unqualifiziert-173af9bc68c8@brauner> <20240117143528.idmyeadhf4yzs5ck@quack3> Date: Wed, 17 Jan 2024 15:51:37 -0500 Message-ID: <87il3rvg2u.fsf@vps.thesusis.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 16118A0014 X-Rspam-User: X-Stat-Signature: gy7oz9sdbhbyd7r3m3j6nuoz38cnf8aj X-Rspamd-Server: rspam03 X-HE-Tag: 1705524697-849001 X-HE-Meta: U2FsdGVkX19hOEYFKPqNDL0qmUxhv0c8YQ6sl/tdHl2d33h3dEQkjSL1KpjX/jL1VFnCU/XkYCnljAla2ypOFocEBrNcHDLI9IU+QzbwOYGz8SHhabWq+wWteKqgx7ZeH67kh2ny0GLspSuRnFGDWzP8XZ3sDB3q0Ld4unWQ1qQQug/XYH3LjgA5xIJn3Z+cT/yfD6S7LanuBtKNKPGb1eRLSyDLpyWmb9jl0+XdFR3KVL5MP0iKWxb1IJn9292zR50i5A1RnfIFrfy31tFRuykyJVpD5Nh8/A/Dte94Qt+cwdHIePRFrx8XA6e9ZiZf/scSHbkI8o+Yg1st1lOthzD+DbL5fzUDHADLYq6JKjvV1TG2+9SuhWWb0kFlGVahGvvoSTolbMJjK+NS6X54xYwQwqOyo97kAdrVylLGONqUtbg3H6wqWcofZzPiCHqN6+rqWYO10r9xt2/v1KJGNTAPBVuZjPuXweUJ+rwmEOb2Dh7RGCB9KRYMZ6PbPeqLJa+Coy8FoQnJZXt6zTodAgCb97LmKY8XazkoL49KN58LUE0vnfmDZ05xzTsnlX5LCUD1FGk/DEes6Sho6b4XLTRvvcMhkVbRlGX/rL/L3P7euBSly//9aAT+t8Ips7lA9/w6Ent1ygf57IYdO8KIfgcdF7o8TGRZRMe0j9kOaa9191DOlFz4VzZI19CimHO7el8lWFOz2X3zC6AJ4wlpz8d9XDCOwBQUpK+ieKYxGjVwM1AcIsOm/a+rCXekXgO7kFJBObENOE3k3iaiti6CG52hNQ1rVPZk+H926bLylqRCw87wwwrN/hOIdzyVcHm/uJWViMv8KITULc+AjOzRyxT41kEcSUPiezDG+1owvs5MrmRK8HzHS5s7wNuudJ0q/HY3BYByux07/7ZpW6G0XvYL0uyP5PhGngdJFJyFgkrfBTfZvZG0bSirEh3kHPLU9z2utovvosAQgI3898r HNHmHJP/ c/ny0adjrIuPUgw4GJCPA8z2Jt9hYzYBv7n8ovnuZtu9rNVKrtfqtIsFEW5giReLfhdCofaV2DcKSaYoa6UikWAfCIPGWK5CGu6z6ixB81KeEizfWE8OXBSuGwX+RtLu66dkW0o/+0BT9Ijy17u7O4MUsOg== 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: Matthew Wilcox writes: > We have numerous ways to intercept file reads and make them either > block or fail. The obvious one to me is security_file_permission() > called from rw_verify_area(). Can we do everything we need with an LSM? I like the idea. That runs when someone opens a file right? What about if they already had the file open or mapped before the volume was locked? If not, is that OK? Are we just trying to deny open requests of files while the volume is locked? Is that in addition to, or instead of throwing out the key and suspending IO at the block layer? If it is in addition, then that would mean that trying to open a file would fail cleanly, but accessing a page that is already mapped could hang the task. In an unkillable state. For a long time. Even the OOM killer can't kill a task blocked like that can it? Or did that get fixed at some point?