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 42755E65D10 for ; Fri, 22 Nov 2024 01:56:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E2888D0008; Thu, 21 Nov 2024 20:56:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 894CC8D0007; Thu, 21 Nov 2024 20:56:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70C518D0008; Thu, 21 Nov 2024 20:56:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 520318D0007 for ; Thu, 21 Nov 2024 20:56:56 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EEFDAAEA29 for ; Fri, 22 Nov 2024 01:56:55 +0000 (UTC) X-FDA: 82812067128.14.52391F9 Received: from mail-pj1-f51.google.com (mail-pj1-f51.google.com [209.85.216.51]) by imf07.hostedemail.com (Postfix) with ESMTP id 533334000B for ; Fri, 22 Nov 2024 01:55:40 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="I/fmuB1a"; spf=pass (imf07.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732240521; 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=ZYw2d70zj3fLcyL/GZSLH0sLEFFOIq2ghVO7jLs6al4=; b=QLakZW1pqqLz+j5Sj/mIkRm41fa6LJpNJ4gOppReFMBL8vhgvq40dOoCSbp0CVPR8Snt/C zFCU5qAahy5X0npyfj1zjTpPJcCWkFeYgLfUWMqq6j4AFY1zPuadoDCUX7Qeal55DK4uKo xgdBhGxXhSbwmuy8U26jSLEwLYOmRyU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732240521; a=rsa-sha256; cv=none; b=4B5ul5fIsdyI5bdMMMkey2ri5ZO00dfvdqXEX2XPtqXqXffDuvfjuy7cUvoPUnWy5006sz 4yUBaVXqkxRILGMk0MkJGSuOPwmsrjoYsvyAy8152tcpmg2bypcImTo71giuRs79CKuL+W /YRQBRO7YIeCmN4JO79cII1qFktQF+M= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="I/fmuB1a"; spf=pass (imf07.hostedemail.com: domain of david@fromorbit.com designates 209.85.216.51 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com Received: by mail-pj1-f51.google.com with SMTP id 98e67ed59e1d1-2ea2dd09971so1360594a91.3 for ; Thu, 21 Nov 2024 17:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1732240612; x=1732845412; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ZYw2d70zj3fLcyL/GZSLH0sLEFFOIq2ghVO7jLs6al4=; b=I/fmuB1aeVis8s5j4pUaIa3B1+wRIkKtSzAPUrWxsHESJjUHP3V2z5PsZTRuujNq2W kOX20RScG/sZEz0zmWQAk4uHlLfPxqJzk5UI1CT2lW02vo9NajKH8O2/cEVrNMLuknS2 GV82Yy5SssSwxpCVI0GpzU1185QhqIOCS7WlnBmxZs7MLSkuhRv+m5GDSnsF794t5+vo 5kSu12Q8LVXiQl4ExvCEJg5eup1FXDrvEhbgE06k/xoTOK6TrlyRn8rYvg1Yg4XSdLP3 WMuZVtDHxyaXnXKAsnqcEg+kEKfva7M0QC8z4SF1XQyt6ZM/GN5ZqLwnHkIueicCLlVa KBdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732240612; x=1732845412; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ZYw2d70zj3fLcyL/GZSLH0sLEFFOIq2ghVO7jLs6al4=; b=Tj7LqPQhswbDGmPIAaqUiNRpU7ZV+yVqfw1Xn1jmkyOif5GfDtvlpEKunHs9n10pOH 8OXLa54cei3vi1GDG6KOZ8Wnjj7+sGkwKz2EstdgtcJtEDSThqvRB5mVBbmdav605Iz3 GX/aPLbELxhh1bJKSJ0ID2aOPvRw/d9HYKT4VTPkkq9jK1fcPrrcPlVwKYhxRPk8yj0m Zxb6w66D0ktgMH28+xSUydKXPDP+SFW/4OqvdDhyzVj0Z09HhUjvZowrufKso/iSAISe 2nWQcUXQbGqOmPgViJMoisHw/rfuDjlFR6FKxVW9bhF7GqSzq68wx/NZTyhJUCiwOgzf 2g+w== X-Forwarded-Encrypted: i=1; AJvYcCW0k2gCS1KbRIHR5LKDLxeKdAMuNW07AaVoJFOS/UsmSBgm5dnVxWWD4AvsmYKBjEj/aPiwAoDEVg==@kvack.org X-Gm-Message-State: AOJu0YwAy9JL6ZMCbukAJasadvWitsAiTSzv9HFTAl256BiyMahUaWTk oD/ygko85JYDB6/qOz3TPskGMOJsJuWLf4/3LirIn83hI8JsZFEb3UNEz94oSFE= X-Gm-Gg: ASbGncsVOIjiKi52VGOXXkFe7HKZx/e1UH9PnVvqp9k9FDPbqmQaiMiqP90145JnEO4 a55gaUEAMVX7QBkn/Po6xgFscAGTK0z8iUPQi8hsjVS9wBbKCINUwFIKTOY6F0cfy5m+s/rkpKo 3QgsvsT3cKbHWNH70j3k3m8nY36JikHCK4+xm+EP9rmPCLkIWF7iWQWwO/JyQwAJIenaJxd/s75 Ha4TS6+7+3Wpvs3Vy4v2jEElBqlmhRQtU2852Qf3Asar7EqQhdwfrcst+e7cMlbcj+zedtUeikn sP0bLf4hf5xcbKyWxaJV414FXQ== X-Google-Smtp-Source: AGHT+IG5UfbjzHrcBQ6JBzzjEPdk8N0DmBlY27dT4IXLy8mOucaRHdLyvzq4hqFdrjdY5qkD8nwwrw== X-Received: by 2002:a17:90b:1c03:b0:2ea:546f:7e7b with SMTP id 98e67ed59e1d1-2eb0e52646amr1335784a91.20.1732240612595; Thu, 21 Nov 2024 17:56:52 -0800 (PST) Received: from dread.disaster.area (pa49-180-121-96.pa.nsw.optusnet.com.au. [49.180.121.96]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2ead02ea3ddsm3954315a91.3.2024.11.21.17.56.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Nov 2024 17:56:52 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.98) (envelope-from ) id 1tEIue-00000001VSd-2OfP; Fri, 22 Nov 2024 12:56:48 +1100 Date: Fri, 22 Nov 2024 12:56:48 +1100 From: Dave Chinner To: Christian Brauner Cc: Mateusz Guzik , viro@zeniv.linux.org.uk, jack@suse.cz, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, hughd@google.com, linux-ext4@vger.kernel.org, tytso@mit.edu, linux-mm@kvack.org Subject: Re: [PATCH v3 1/3] vfs: support caching symlink lengths in inodes Message-ID: References: <20241120112037.822078-1-mjguzik@gmail.com> <20241120112037.822078-2-mjguzik@gmail.com> <20241121-seilschaft-zeitig-7c8c3431bd00@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241121-seilschaft-zeitig-7c8c3431bd00@brauner> X-Rspamd-Server: rspam10 X-Stat-Signature: jroh7ixqozxian9h9wxtdsqww9nkdgiy X-Rspamd-Queue-Id: 533334000B X-Rspam-User: X-HE-Tag: 1732240540-933461 X-HE-Meta: U2FsdGVkX1/Q71vo1litXhdGnsTd9kPmskdgktc69YjcdYR7GQLrzo/GeiqQXnjvcy4qR1Wov3Q9fqGmPNCjxhwt2AOxLM9i97iQjcP9qOm2X8DqHVsBzwt4vm6DQSQEJpG4i1MCOjycKbkWV5myKDL3FoCTzAUSG/DC/qcJWOY56EksGmoK6Yw+QigejNIF8pbfIjPA8A8oo1ta/5q2Zg/Z9bPxTo6DtrSFr+shKw29RI16qs6leISISVAzxfRhvyLPq43mnR8e0wtVx0xef90sYHRzqHKqbdzRsWI6720+z7KbdKvuvZYkpGT1pCTbFm6FbC8TLvobGN18MZnqJ60y7ZO2SYba0FumLAUOUrRw4z6DbCp91Pdhmz2kW+M3J30AvS6HcbQvR2WiG4hKCl5OLgPb6+IBIqzHiqrvEBFbnvsNqj9Wq9zpswCVoXcfzaqb8qzbaRFdapeI862oufKYzDK+AElDz/zwgGUbbx8qA+UHYnr1i+CABxzgZIIAUuVImfF7oF8oBVB9Vew1VZ9O2UnOpNLNjuALRKscaIkd672yqTWS1/hZ2sa1oATeTfng5XznxEVH+TD6SfNL4lav55VmeNlqEcCcvzg4N5YqWQgM7a/wF/Hcllt0Q1WBmtFDcq9FGg+j9wmJSskc3J8sKvcOEdU/Clv7Mkt273dCtc8iGRmxiwk6kt6v/MLh23aARWmKDUG/oA985FEKi0qHEKPg9zIV6I6o3wyrYphILzcPXa2wNpbiZ5tt19yXWxt8ZPg5YCwxlnRUMKiIBLw0B/GTTk9ndKu5UwmvUa10YXhbUVTFu3Z7b7Ygyfi4XyklsOlkwuBpAGPVwMjrNs3iYKAJCDAz8s+pSUQi8jp79/yTAebbte6O7uukUuTqqZUnFp/MChiUEgH5PlmstGpzVVzqTA2EMl3gCiSNe9vnSZUaNODPDcbvyDbNQmK2RYECooF1vZJFko3BeD3 MhepD83A MLJdBArF6nS7v9yxprJaEX/AcWmxNV/G7ZYwJftexp9sbEOhz2PDDcDtUUjvkZFhG1PMQZVPIRu5PY+LNzBQYe58I3FrA4Js5D7kXj3fKTqSnE0Kz7gcimoeUfvV2y6IzudyvWoAcIcCxkRN3DnC03aXUEGccWIEohzffYscH4rs+/WeDBvaHmKW0t3GEAXP0B3Ff/QXACVhYEil2eY0pN6o6wXDTGpG5aHGJ2bKHW+PnKmIAZOzR5YasZDtSOFWBHmmZkt/PnSNy1MYrhrmii12PLL0InrJg5uh8xIaaeKpctNCYwFQOaBQOU26CAGxwH53SN14kGS5puonrCsnl51aHaLLUQ3NnxIp+fLUzQCOtDIRXncyj1lqJXKVLWlPSiyRpSA8VRzkdGHlo+Tz8UAWoBMffkq4eqhCgxB7Bg06AEhrgJZHo9b373LxZAA2BJ+aa 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 Thu, Nov 21, 2024 at 11:12:52AM +0100, Christian Brauner wrote: > I think that i_devices should be moved into the union as it's really > only used with i_cdev but it's not that easily done because list_head > needs to be initialized. I'm planning on using i_devices with block devices, too, so the block device list doesn't need to use i_sb_list anymore (similar to how i_devices is used by the char dev infrastructure. See the patch below... > I roughly envisioned something like: > > union { > struct { > struct cdev *i_cdev; > struct list_head i_devices; > }; > struct { > char *i_link; > unsigned int i_link_len; > }; > struct pipe_inode_info *i_pipe; > unsigned i_dir_seq; > }; > I'd probably have to undo any unioning/association with i_cdev to use i_devices with block devs... -Dave -- Dave Chinner david@fromorbit.com bdev: stop using sb->s_inodes From: Dave Chinner Iteration of block device inodes is done via the blockdev_superblock->s_inodes list. We want to remove this list and the inode i_sb_list list heads, so we need some other way for block devices to be iterated. Take a leaf from the chardev code and use the inode->i_devices list head to link all the block device inodes together and replace the s_inodes list with a bdev private global list. Signed-off-by: Dave Chinner --- block/bdev.c | 56 +++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 39 insertions(+), 17 deletions(-) diff --git a/block/bdev.c b/block/bdev.c index 33f9c4605e3a..d733507f584a 100644 --- a/block/bdev.c +++ b/block/bdev.c @@ -317,6 +317,8 @@ EXPORT_SYMBOL(bdev_thaw); static __cacheline_aligned_in_smp DEFINE_MUTEX(bdev_lock); static struct kmem_cache *bdev_cachep __ro_after_init; +static LIST_HEAD(bdev_inodes); +static DEFINE_SPINLOCK(bdev_inodes_lock); static struct inode *bdev_alloc_inode(struct super_block *sb) { @@ -362,6 +364,10 @@ static void init_once(void *data) static void bdev_evict_inode(struct inode *inode) { + spin_lock(&bdev_inodes_lock); + list_del_init(&inode->i_devices); + spin_unlock(&bdev_inodes_lock); + truncate_inode_pages_final(&inode->i_data); invalidate_inode_buffers(inode); /* is it needed here? */ clear_inode(inode); @@ -412,19 +418,35 @@ void __init bdev_cache_init(void) blockdev_superblock = blockdev_mnt->mnt_sb; /* For writeback */ } -struct block_device *bdev_alloc(struct gendisk *disk, u8 partno) +static struct inode *bdev_new_inode(void) { - struct block_device *bdev; struct inode *inode; - inode = new_inode(blockdev_superblock); + inode = new_inode_pseudo(blockdev_superblock); if (!inode) return NULL; + + spin_lock(&bdev_inodes_lock); + list_add(&inode->i_devices, &bdev_inodes); + spin_unlock(&bdev_inodes_lock); + inode->i_mode = S_IFBLK; inode->i_rdev = 0; inode->i_data.a_ops = &def_blk_aops; mapping_set_gfp_mask(&inode->i_data, GFP_USER); + return inode; +} + +struct block_device *bdev_alloc(struct gendisk *disk, u8 partno) +{ + struct block_device *bdev; + struct inode *inode; + + inode = bdev_new_inode(); + if (!inode) + return NULL; + bdev = I_BDEV(inode); mutex_init(&bdev->bd_fsfreeze_mutex); spin_lock_init(&bdev->bd_size_lock); @@ -477,10 +499,10 @@ long nr_blockdev_pages(void) struct inode *inode; long ret = 0; - spin_lock(&blockdev_superblock->s_inode_list_lock); - list_for_each_entry(inode, &blockdev_superblock->s_inodes, i_sb_list) + spin_lock(&bdev_inodes_lock); + list_for_each_entry(inode, &bdev_inodes, i_devices) ret += inode->i_mapping->nrpages; - spin_unlock(&blockdev_superblock->s_inode_list_lock); + spin_unlock(&bdev_inodes_lock); return ret; } @@ -1218,8 +1240,8 @@ void sync_bdevs(bool wait) { struct inode *inode, *old_inode = NULL; - spin_lock(&blockdev_superblock->s_inode_list_lock); - list_for_each_entry(inode, &blockdev_superblock->s_inodes, i_sb_list) { + spin_lock(&bdev_inodes_lock); + list_for_each_entry(inode, &bdev_inodes, i_devices) { struct address_space *mapping = inode->i_mapping; struct block_device *bdev; @@ -1231,14 +1253,14 @@ void sync_bdevs(bool wait) } __iget(inode); spin_unlock(&inode->i_lock); - spin_unlock(&blockdev_superblock->s_inode_list_lock); + spin_unlock(&bdev_inodes_lock); + /* - * We hold a reference to 'inode' so it couldn't have been - * removed from s_inodes list while we dropped the - * s_inode_list_lock We cannot iput the inode now as we can - * be holding the last reference and we cannot iput it under - * s_inode_list_lock. So we keep the reference and iput it - * later. + * We hold a reference to 'inode' so it won't get removed from + * bdev inodes list while we drop the lock. We need to hold the + * reference until we have a reference on the next inode on the + * list, so we can't drop it until the next time we let go of + * the bdev_inodes_lock. */ iput(old_inode); old_inode = inode; @@ -1260,9 +1282,9 @@ void sync_bdevs(bool wait) } mutex_unlock(&bdev->bd_disk->open_mutex); - spin_lock(&blockdev_superblock->s_inode_list_lock); + spin_lock(&bdev_inodes_lock); } - spin_unlock(&blockdev_superblock->s_inode_list_lock); + spin_unlock(&bdev_inodes_lock); iput(old_inode); }