search for: orphan_lock

...cb03b4..ecc9d0829a91 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -35,15 +35,6 @@ static const struct iommu_ops omap_iommu_ops; -struct orphan_dev { - struct device *dev; - struct list_head node; -}; - -static LIST_HEAD(orphan_dev_list); - -static DEFINE_SPINLOCK(orphan_lock); - #define to_iommu(dev) ((struct omap_iommu *)dev_get_drvdata(dev)) /* bitmap of the page sizes currently supported */ @@ -62,8 +53,6 @@ static DEFINE_SPINLOCK(orphan_lock); static struct platform_driver omap_iommu_driver; static struct kmem_cache *iopte_cachep; -static int _omap_iommu_ad...

...ound_key, root, NULL); - if (IS_ERR(inode)) { - ret = PTR_ERR(inode); + ret = PTR_RET(inode); + if (ret && ret != -ESTALE) goto out; - } - - /* - * add this inode to the orphan list so btrfs_orphan_del does - * the proper thing when we hit it - */ - spin_lock(&root->orphan_lock); - list_add(&BTRFS_I(inode)->i_orphan, &root->orphan_list); - spin_unlock(&root->orphan_lock); /* - * if this is a bad inode, means we actually succeeded in - * removing the inode, but not the orphan record, which means - * we need to manually delete the orphan si...

After running ceph on XFS for some time, I decided to try btrfs again. Performance with the current "for-linux-min" branch and big metadata is much better. The only problem (?) I''m still seeing is a warning that seems to occur from time to time: [87703.784552] ------------[ cut here ]------------ [87703.789759] WARNING: at fs/btrfs/inode.c:2103

...void btrfs_orphan_commit_root(struct btrfs_trans_handle *trans, struct btrfs_root *root) { + struct btrfs_block_rsv *block_rsv; int ret; if (!list_empty(&root->orphan_list) || root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE) return; + spin_lock(&root->orphan_lock); + if (!list_empty(&root->orphan_list)) { + spin_unlock(&root->orphan_lock); + return; + } + + if (root->orphan_cleanup_state != ORPHAN_CLEANUP_DONE) { + spin_unlock(&root->orphan_lock); + return; + } + + block_rsv = root->orphan_block_rsv; + root->orphan_block_rs...

Hello, I''m seeing a lot of warnings in dmesg with a BTRFS filesystem. I''m using the 3.1 kernel, I found a patch for these warnings ( http://marc.info/?l=linux-btrfs&m=131547325515336&w=2) <http://marc.info/?l=linux-btrfs&m=131547325515336&w=2>, but that patch has already been included in 3.1. Are there any other patches I can try? I''m using

...if its not being used by other tasks, seems to fix the leak without failing xfstests so far. But this is unlikely to be a correct solution without causing issues elsewhere. This commit also changes calls to btrfs_orphan_del() which grabbed the root''s orphan_block_rsv without acquiring the orphan_lock first (confront with btrfs_orphan_commit_root(), which acquires the lock before getting and setting the root''s orphan_block_rsv). This issue is simple to reproduce and observe if kmemleak is enabled. Two simple ways to reproduce it: ** 1 $ mkfs.btrfs -f /dev/loop0 $ mount /dev/loop0 /mn...

...o.c @@ -1064,7 +1064,6 @@ static int __setup_root(u32 nodesize, u32 leafsize, u32 sectorsize, INIT_LIST_HEAD(&root->dirty_list); INIT_LIST_HEAD(&root->orphan_list); INIT_LIST_HEAD(&root->root_list); - spin_lock_init(&root->node_lock); spin_lock_init(&root->orphan_lock); spin_lock_init(&root->inode_lock); spin_lock_init(&root->accounting_lock); -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majord...

...quot;btrfs: bad extent! em: [%llu %llu] passed " "[%llu %llu]\n", (unsigned long long)em->start, (unsigned long long)em->len, (unsigned long long)start, @@ -6693,7 +6693,7 @@ void btrfs_destroy_inode(struct inode *inode) spin_lock(&root->orphan_lock); if (!list_empty(&BTRFS_I(inode)->i_orphan)) { - printk(KERN_INFO "BTRFS: inode %llu still on the orphan list\n", + printk(KERN_INFO "btrfs: inode %llu still on the orphan list\n", (unsigned long long)btrfs_ino(inode)); list_del_init(&BTRFS_I(inode)-...

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the second version of this patch-set. The first version with some more introductory text can be found here: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ Changes v1->v2: * Rebased to v5.7-rc1 * Re-wrote the arm-smmu changes as suggested by Robin Murphy * Re-worked the Exynos patches to hopefully not break the driver anymore * Fixed a missing

Hi, here is the third version of this patch-set. Older versions can be found here: v1: https://lore.kernel.org/lkml/20200407183742.4344-1-joro at 8bytes.org/ (Has some more introductory text) v2: https://lore.kernel.org/lkml/20200414131542.25608-1-joro at 8bytes.org/ Changes v2 -> v3: * Rebased v5.7-rc3 * Added a missing iommu_group_put() as reported by Lu Baolu. * Added a

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a

Hi, here is a patch-set to remove all calls of iommu_group_get_for_dev() from the IOMMU drivers and move the per-device group setup and default domain allocation into the IOMMU core code. This eliminates some ugly back and forth between IOMMU core code and the IOMMU drivers, where the driver called iommu_group_get_for_dev() which itself called back into the driver. The patch-set started as a

If we have particularly full nodes, we could call btrfs_node_blockptr up to 32 times, which is 32 pairs of kmap/kunmap, which _sucks_. So go ahead and map the extent buffer while we look for readahead targets. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> --- fs/btrfs/ctree.c | 23 +++++++++++++++++++++-- 1 files changed, 21 insertions(+), 2 deletions(-) diff --git