* [PATCH 0/1] xfs: Use xarray to track SB UUIDs instead of plain array. @ 2026-01-30 15:42 Lukas Herbolt 2026-01-30 15:42 ` [PATCH] " Lukas Herbolt 0 siblings, 1 reply; 10+ messages in thread From: Lukas Herbolt @ 2026-01-30 15:42 UTC (permalink / raw) To: linux-xfs; +Cc: cem, Lukas Herbolt Hi, It was discussed in previous thread [1]. Some older kernels (pre v6.12), complained doing allocation over 2xPAGE_SIZE in krealloc when mounting over 512 unique XFS. The warning was removed in v6.12, but Christoph suggested to start using xrarray instead of plain array. So here it is. [1] - https://lore.kernel.org/linux-xfs/aPhjZ4sfHngyJRQK@infradead.org/ Lukas Herbolt (1): xfs: Use xarray to track SB UUIDs instead of plain array. fs/xfs/xfs_mount.c | 87 +++++++++++++++++++++++----------------------- fs/xfs/xfs_mount.h | 3 +- fs/xfs/xfs_super.c | 2 +- 3 files changed, 46 insertions(+), 46 deletions(-) base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 -- 2.52.0 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-01-30 15:42 [PATCH 0/1] xfs: Use xarray to track SB UUIDs instead of plain array Lukas Herbolt @ 2026-01-30 15:42 ` Lukas Herbolt 2026-01-30 16:55 ` Darrick J. Wong 2026-02-02 7:37 ` Christoph Hellwig 0 siblings, 2 replies; 10+ messages in thread From: Lukas Herbolt @ 2026-01-30 15:42 UTC (permalink / raw) To: linux-xfs; +Cc: cem, Lukas Herbolt Removing the plain array to track the UUIDs and switch xarray to make more readable. Signed-off-by: Lukas Herbolt <lukas@herbolt.com> --- fs/xfs/xfs_mount.c | 87 +++++++++++++++++++++++----------------------- fs/xfs/xfs_mount.h | 3 +- fs/xfs/xfs_super.c | 2 +- 3 files changed, 46 insertions(+), 46 deletions(-) diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c index 0953f6ae94ab..35c0d411e0cb 100644 --- a/fs/xfs/xfs_mount.c +++ b/fs/xfs/xfs_mount.c @@ -42,18 +42,48 @@ #include "scrub/stats.h" #include "xfs_zone_alloc.h" -static DEFINE_MUTEX(xfs_uuid_table_mutex); -static int xfs_uuid_table_size; -static uuid_t *xfs_uuid_table; +static DEFINE_XARRAY_ALLOC(xfs_uuid_table); + +/* + * Helper fucntions to store UUID in xarray. + */ +STATIC int +xfs_uuid_insert(uuid_t *uuid) +{ + uint32_t index = 0; + + return xa_alloc(&xfs_uuid_table, &index, uuid, + xa_limit_32b, GFP_KERNEL); +} + +STATIC uuid_t +*xfs_uuid_search(uuid_t *new_uuid) +{ + unsigned long index = 0; + uuid_t *uuid = NULL; + + xa_for_each(&xfs_uuid_table, index, uuid) { + if (uuid_equal(uuid, new_uuid)) + return uuid; + } + return NULL; +} + +STATIC void +xfs_uuid_delete(uuid_t *uuid) +{ + unsigned long index = 0; + + xa_for_each(&xfs_uuid_table, index, uuid) { + xa_erase(&xfs_uuid_table, index); + } +} void -xfs_uuid_table_free(void) +xfs_uuid_table_destroy(void) { - if (xfs_uuid_table_size == 0) - return; - kfree(xfs_uuid_table); - xfs_uuid_table = NULL; - xfs_uuid_table_size = 0; + ASSERT(xa_empty(&xfs_uuid_table)); + xa_destroy(&xfs_uuid_table); } /* @@ -65,7 +95,6 @@ xfs_uuid_mount( struct xfs_mount *mp) { uuid_t *uuid = &mp->m_sb.sb_uuid; - int hole, i; /* Publish UUID in struct super_block */ super_set_uuid(mp->m_super, uuid->b, sizeof(*uuid)); @@ -78,29 +107,9 @@ xfs_uuid_mount( return -EINVAL; } - mutex_lock(&xfs_uuid_table_mutex); - for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) { - if (uuid_is_null(&xfs_uuid_table[i])) { - hole = i; - continue; - } - if (uuid_equal(uuid, &xfs_uuid_table[i])) - goto out_duplicate; - } + if (!xfs_uuid_search(uuid)) + return xfs_uuid_insert(uuid); - if (hole < 0) { - xfs_uuid_table = krealloc(xfs_uuid_table, - (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table), - GFP_KERNEL | __GFP_NOFAIL); - hole = xfs_uuid_table_size++; - } - xfs_uuid_table[hole] = *uuid; - mutex_unlock(&xfs_uuid_table_mutex); - - return 0; - - out_duplicate: - mutex_unlock(&xfs_uuid_table_mutex); xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount", uuid); return -EINVAL; } @@ -110,22 +119,12 @@ xfs_uuid_unmount( struct xfs_mount *mp) { uuid_t *uuid = &mp->m_sb.sb_uuid; - int i; if (xfs_has_nouuid(mp)) return; + xfs_uuid_delete(uuid); + return; - mutex_lock(&xfs_uuid_table_mutex); - for (i = 0; i < xfs_uuid_table_size; i++) { - if (uuid_is_null(&xfs_uuid_table[i])) - continue; - if (!uuid_equal(uuid, &xfs_uuid_table[i])) - continue; - memset(&xfs_uuid_table[i], 0, sizeof(uuid_t)); - break; - } - ASSERT(i < xfs_uuid_table_size); - mutex_unlock(&xfs_uuid_table_mutex); } /* diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h index b871dfde372b..c3a5035c1fb6 100644 --- a/fs/xfs/xfs_mount.h +++ b/fs/xfs/xfs_mount.h @@ -689,7 +689,8 @@ xfs_daddr_to_agbno(struct xfs_mount *mp, xfs_daddr_t d) return (xfs_agblock_t) do_div(ld, mp->m_sb.sb_agblocks); } -extern void xfs_uuid_table_free(void); +extern void xfs_uuid_table_destroy(void); + uint64_t xfs_default_resblks(struct xfs_mount *mp, enum xfs_free_counter ctr); extern int xfs_mountfs(xfs_mount_t *mp); diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index bc71aa9dcee8..fc9d2e5acf96 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -2723,7 +2723,7 @@ exit_xfs_fs(void) xfs_mru_cache_uninit(); xfs_destroy_workqueues(); xfs_destroy_caches(); - xfs_uuid_table_free(); + xfs_uuid_table_destroy(); } module_init(init_xfs_fs); base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 -- 2.52.0 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-01-30 15:42 ` [PATCH] " Lukas Herbolt @ 2026-01-30 16:55 ` Darrick J. Wong 2026-02-02 7:31 ` Christoph Hellwig 2026-02-02 7:37 ` Christoph Hellwig 1 sibling, 1 reply; 10+ messages in thread From: Darrick J. Wong @ 2026-01-30 16:55 UTC (permalink / raw) To: Lukas Herbolt; +Cc: linux-xfs, cem On Fri, Jan 30, 2026 at 04:42:08PM +0100, Lukas Herbolt wrote: > Removing the plain array to track the UUIDs and switch > xarray to make more readable. > > Signed-off-by: Lukas Herbolt <lukas@herbolt.com> > --- > fs/xfs/xfs_mount.c | 87 +++++++++++++++++++++++----------------------- > fs/xfs/xfs_mount.h | 3 +- > fs/xfs/xfs_super.c | 2 +- > 3 files changed, 46 insertions(+), 46 deletions(-) > > diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c > index 0953f6ae94ab..35c0d411e0cb 100644 > --- a/fs/xfs/xfs_mount.c > +++ b/fs/xfs/xfs_mount.c > @@ -42,18 +42,48 @@ > #include "scrub/stats.h" > #include "xfs_zone_alloc.h" > > -static DEFINE_MUTEX(xfs_uuid_table_mutex); > -static int xfs_uuid_table_size; > -static uuid_t *xfs_uuid_table; > +static DEFINE_XARRAY_ALLOC(xfs_uuid_table); > + > +/* > + * Helper fucntions to store UUID in xarray. > + */ > +STATIC int > +xfs_uuid_insert(uuid_t *uuid) > +{ > + uint32_t index = 0; > + > + return xa_alloc(&xfs_uuid_table, &index, uuid, > + xa_limit_32b, GFP_KERNEL); > +} > + > +STATIC uuid_t > +*xfs_uuid_search(uuid_t *new_uuid) > +{ > + unsigned long index = 0; > + uuid_t *uuid = NULL; > + > + xa_for_each(&xfs_uuid_table, index, uuid) { > + if (uuid_equal(uuid, new_uuid)) > + return uuid; > + } > + return NULL; > +} > + > +STATIC void > +xfs_uuid_delete(uuid_t *uuid) > +{ > + unsigned long index = 0; > + > + xa_for_each(&xfs_uuid_table, index, uuid) { > + xa_erase(&xfs_uuid_table, index); > + } Why not store the xarray index in the xfs_mount so you can delete the entry directly without having to walk the entire array? And while I'm on about it ... if you're going to change data structures, why not use rhashtable or something that can do a direct lookup? > +} > > void > -xfs_uuid_table_free(void) > +xfs_uuid_table_destroy(void) > { > - if (xfs_uuid_table_size == 0) > - return; > - kfree(xfs_uuid_table); > - xfs_uuid_table = NULL; > - xfs_uuid_table_size = 0; > + ASSERT(xa_empty(&xfs_uuid_table)); > + xa_destroy(&xfs_uuid_table); > } > > /* > @@ -65,7 +95,6 @@ xfs_uuid_mount( > struct xfs_mount *mp) > { > uuid_t *uuid = &mp->m_sb.sb_uuid; > - int hole, i; > > /* Publish UUID in struct super_block */ > super_set_uuid(mp->m_super, uuid->b, sizeof(*uuid)); > @@ -78,29 +107,9 @@ xfs_uuid_mount( > return -EINVAL; > } > > - mutex_lock(&xfs_uuid_table_mutex); > - for (i = 0, hole = -1; i < xfs_uuid_table_size; i++) { > - if (uuid_is_null(&xfs_uuid_table[i])) { > - hole = i; > - continue; > - } > - if (uuid_equal(uuid, &xfs_uuid_table[i])) > - goto out_duplicate; > - } > + if (!xfs_uuid_search(uuid)) > + return xfs_uuid_insert(uuid); xfs_uuid_table_mutex went away, so what's protecting the lookup and insert from racing to insert the same uuid twice? --D > > - if (hole < 0) { > - xfs_uuid_table = krealloc(xfs_uuid_table, > - (xfs_uuid_table_size + 1) * sizeof(*xfs_uuid_table), > - GFP_KERNEL | __GFP_NOFAIL); > - hole = xfs_uuid_table_size++; > - } > - xfs_uuid_table[hole] = *uuid; > - mutex_unlock(&xfs_uuid_table_mutex); > - > - return 0; > - > - out_duplicate: > - mutex_unlock(&xfs_uuid_table_mutex); > xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount", uuid); > return -EINVAL; > } > @@ -110,22 +119,12 @@ xfs_uuid_unmount( > struct xfs_mount *mp) > { > uuid_t *uuid = &mp->m_sb.sb_uuid; > - int i; > > if (xfs_has_nouuid(mp)) > return; > + xfs_uuid_delete(uuid); > + return; > > - mutex_lock(&xfs_uuid_table_mutex); > - for (i = 0; i < xfs_uuid_table_size; i++) { > - if (uuid_is_null(&xfs_uuid_table[i])) > - continue; > - if (!uuid_equal(uuid, &xfs_uuid_table[i])) > - continue; > - memset(&xfs_uuid_table[i], 0, sizeof(uuid_t)); > - break; > - } > - ASSERT(i < xfs_uuid_table_size); > - mutex_unlock(&xfs_uuid_table_mutex); > } > > /* > diff --git a/fs/xfs/xfs_mount.h b/fs/xfs/xfs_mount.h > index b871dfde372b..c3a5035c1fb6 100644 > --- a/fs/xfs/xfs_mount.h > +++ b/fs/xfs/xfs_mount.h > @@ -689,7 +689,8 @@ xfs_daddr_to_agbno(struct xfs_mount *mp, xfs_daddr_t d) > return (xfs_agblock_t) do_div(ld, mp->m_sb.sb_agblocks); > } > > -extern void xfs_uuid_table_free(void); > +extern void xfs_uuid_table_destroy(void); > + > uint64_t xfs_default_resblks(struct xfs_mount *mp, > enum xfs_free_counter ctr); > extern int xfs_mountfs(xfs_mount_t *mp); > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index bc71aa9dcee8..fc9d2e5acf96 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -2723,7 +2723,7 @@ exit_xfs_fs(void) > xfs_mru_cache_uninit(); > xfs_destroy_workqueues(); > xfs_destroy_caches(); > - xfs_uuid_table_free(); > + xfs_uuid_table_destroy(); > } > > module_init(init_xfs_fs); > > base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377 > -- > 2.52.0 > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-01-30 16:55 ` Darrick J. Wong @ 2026-02-02 7:31 ` Christoph Hellwig 2026-02-02 9:37 ` Lukas Herbolt 0 siblings, 1 reply; 10+ messages in thread From: Christoph Hellwig @ 2026-02-02 7:31 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Lukas Herbolt, linux-xfs, cem On Fri, Jan 30, 2026 at 08:55:34AM -0800, Darrick J. Wong wrote: > > + xa_erase(&xfs_uuid_table, index); > > + } > > Why not store the xarray index in the xfs_mount so you can delete the > entry directly without having to walk the entire array? Yeah, that makes a lot of sense. > And while I'm on about it ... if you're going to change data structures, > why not use rhashtable or something that can do a direct lookup? rhashtables require quite a bit of boilerplate. Probably not worth if for a single lookup in a relatively small colletion once per mount. But yeah, if only we had a data structure that allows directly lookups without all that boilerplate.. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-02-02 7:31 ` Christoph Hellwig @ 2026-02-02 9:37 ` Lukas Herbolt 2026-02-02 18:50 ` Darrick J. Wong 0 siblings, 1 reply; 10+ messages in thread From: Lukas Herbolt @ 2026-02-02 9:37 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Darrick J. Wong, linux-xfs, cem On 2026-02-02 08:31, Christoph Hellwig wrote: > On Fri, Jan 30, 2026 at 08:55:34AM -0800, Darrick J. Wong wrote: >> > + xa_erase(&xfs_uuid_table, index); >> > + } >> >> Why not store the xarray index in the xfs_mount so you can delete the >> entry directly without having to walk the entire array? > > Yeah, that makes a lot of sense. > I did not want to touch the xfs_mount but if there is no objection against, I will add the index there. >> And while I'm on about it ... if you're going to change data >> structures, >> why not use rhashtable or something that can do a direct lookup? > > rhashtables require quite a bit of boilerplate. Probably not worth > if for a single lookup in a relatively small colletion once per > mount. But yeah, if only we had a data structure that allows > directly lookups without all that boilerplate.. I do not have strong preference here. -- -lhe ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-02-02 9:37 ` Lukas Herbolt @ 2026-02-02 18:50 ` Darrick J. Wong 2026-02-03 5:17 ` Christoph Hellwig 0 siblings, 1 reply; 10+ messages in thread From: Darrick J. Wong @ 2026-02-02 18:50 UTC (permalink / raw) To: Lukas Herbolt; +Cc: Christoph Hellwig, linux-xfs, cem On Mon, Feb 02, 2026 at 10:37:23AM +0100, Lukas Herbolt wrote: > On 2026-02-02 08:31, Christoph Hellwig wrote: > > On Fri, Jan 30, 2026 at 08:55:34AM -0800, Darrick J. Wong wrote: > > > > + xa_erase(&xfs_uuid_table, index); > > > > + } > > > > > > Why not store the xarray index in the xfs_mount so you can delete the > > > entry directly without having to walk the entire array? > > > > Yeah, that makes a lot of sense. > > > I did not want to touch the xfs_mount but if there is no objection against, > I will add the index there. > > > > And while I'm on about it ... if you're going to change data > > > structures, > > > why not use rhashtable or something that can do a direct lookup? > > > > rhashtables require quite a bit of boilerplate. Probably not worth > > if for a single lookup in a relatively small colletion once per > > mount. But yeah, if only we had a data structure that allows > > directly lookups without all that boilerplate.. > > I do not have strong preference here. <shrug> Since the original message said "krealloc prints out warning if allocation is bigger than 2x PAGE_SIZE", I figured that meant you were trying to mount more than (2 * 4096) / 16 == 512 different xfs filesystems on the same host. I don't have a particular problem with the array search and large memory allocation since I never mount that many filesystems, but you would appear to be the first user to complain about a scaling limit there... :) --D > -- > -lhe > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-02-02 18:50 ` Darrick J. Wong @ 2026-02-03 5:17 ` Christoph Hellwig 2026-02-03 7:23 ` Darrick J. Wong 0 siblings, 1 reply; 10+ messages in thread From: Christoph Hellwig @ 2026-02-03 5:17 UTC (permalink / raw) To: Darrick J. Wong; +Cc: Lukas Herbolt, Christoph Hellwig, linux-xfs, cem On Mon, Feb 02, 2026 at 10:50:13AM -0800, Darrick J. Wong wrote: > > I do not have strong preference here. > > <shrug> Since the original message said "krealloc prints out warning if > allocation is bigger than 2x PAGE_SIZE", I figured that meant you were > trying to mount more than (2 * 4096) / 16 == 512 different xfs > filesystems on the same host. I don't remember any such message. But array or xarray iterations should still scale well enough for a single mount time operation into the 10.000nds of entries. > I don't have a particular problem with the array search and large memory > allocation since I never mount that many filesystems, but you would > appear to be the first user to complain about a scaling limit there... I was really just concerned about a single large allocation. But yeah, it's not that large... That beind said I think the xarray version will also look nicer than the original one. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-02-03 5:17 ` Christoph Hellwig @ 2026-02-03 7:23 ` Darrick J. Wong 0 siblings, 0 replies; 10+ messages in thread From: Darrick J. Wong @ 2026-02-03 7:23 UTC (permalink / raw) To: Christoph Hellwig; +Cc: Lukas Herbolt, linux-xfs, cem On Mon, Feb 02, 2026 at 09:17:31PM -0800, Christoph Hellwig wrote: > On Mon, Feb 02, 2026 at 10:50:13AM -0800, Darrick J. Wong wrote: > > > I do not have strong preference here. > > > > <shrug> Since the original message said "krealloc prints out warning if > > allocation is bigger than 2x PAGE_SIZE", I figured that meant you were > > trying to mount more than (2 * 4096) / 16 == 512 different xfs > > filesystems on the same host. > > I don't remember any such message. But array or xarray iterations > should still scale well enough for a single mount time operation into > the 10.000nds of entries. > > > I don't have a particular problem with the array search and large memory > > allocation since I never mount that many filesystems, but you would > > appear to be the first user to complain about a scaling limit there... > > I was really just concerned about a single large allocation. But yeah, > it's not that large... That beind said I think the xarray version will > also look nicer than the original one. It's better than the raw kvalloc'd blob we have now :) --D ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-01-30 15:42 ` [PATCH] " Lukas Herbolt 2026-01-30 16:55 ` Darrick J. Wong @ 2026-02-02 7:37 ` Christoph Hellwig 2026-02-02 9:38 ` Lukas Herbolt 1 sibling, 1 reply; 10+ messages in thread From: Christoph Hellwig @ 2026-02-02 7:37 UTC (permalink / raw) To: Lukas Herbolt; +Cc: linux-xfs, cem > +STATIC int We're phasing out the magic STATIC, so pleae just use plain static here. > +xfs_uuid_insert(uuid_t *uuid) The somewhat unique XFS coding style uses separate lines for each argument: static int xfs_uuid_insert( uuid_t *uuid) > +{ > + uint32_t index = 0; .. and aligns the variables the same way: { uint32_t index = 0; Although this one will go away with Darrick's suggestion anyway. > + > + return xa_alloc(&xfs_uuid_table, &index, uuid, > + xa_limit_32b, GFP_KERNEL); > +} > + > +STATIC uuid_t > +*xfs_uuid_search(uuid_t *new_uuid) The * for pointers goes with the type: static uuid_t * xfs_uuid_search( uuid_t *new_uuid) > + uuid_t *uuid = NULL; no need to initialize the iterator to NULL before xa_for_each. > +STATIC void > +xfs_uuid_delete(uuid_t *uuid) > +{ > + unsigned long index = 0; > + > + xa_for_each(&xfs_uuid_table, index, uuid) { > + xa_erase(&xfs_uuid_table, index); > + } I don't think this works as expected, as it just erases all uuids in the table. > +} > > void > -xfs_uuid_table_free(void) > +xfs_uuid_table_destroy(void) I'd drop this rename. Free works just fine here as a name. > + if (!xfs_uuid_search(uuid)) > + return xfs_uuid_insert(uuid); > > xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount", uuid); > return -EINVAL; Just return an error here if xfs_uuid_search finds something, and then open code the insert in the straight line path. > @@ -110,22 +119,12 @@ xfs_uuid_unmount( > struct xfs_mount *mp) > { > uuid_t *uuid = &mp->m_sb.sb_uuid; > > if (xfs_has_nouuid(mp)) > return; > + xfs_uuid_delete(uuid); > + return; No need for the last return. Also I think you can just open code xfs_uuid_delete here. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] xfs: Use xarray to track SB UUIDs instead of plain array. 2026-02-02 7:37 ` Christoph Hellwig @ 2026-02-02 9:38 ` Lukas Herbolt 0 siblings, 0 replies; 10+ messages in thread From: Lukas Herbolt @ 2026-02-02 9:38 UTC (permalink / raw) To: Christoph Hellwig; +Cc: linux-xfs, cem On 2026-02-02 08:37, Christoph Hellwig wrote: >> +STATIC int > > We're phasing out the magic STATIC, so pleae just use plain static > here. > >> +xfs_uuid_insert(uuid_t *uuid) > > The somewhat unique XFS coding style uses separate lines for each > argument: > > static int > xfs_uuid_insert( > uuid_t *uuid) > >> +{ >> + uint32_t index = 0; > > .. and aligns the variables the same way: > > { > uint32_t index = 0; > > Although this one will go away with Darrick's suggestion anyway. > >> + >> + return xa_alloc(&xfs_uuid_table, &index, uuid, >> + xa_limit_32b, GFP_KERNEL); >> +} >> + >> +STATIC uuid_t >> +*xfs_uuid_search(uuid_t *new_uuid) > > The * for pointers goes with the type: > > static uuid_t * > xfs_uuid_search( > uuid_t *new_uuid) > >> + uuid_t *uuid = NULL; > > no need to initialize the iterator to NULL before xa_for_each. > >> +STATIC void >> +xfs_uuid_delete(uuid_t *uuid) >> +{ >> + unsigned long index = 0; >> + >> + xa_for_each(&xfs_uuid_table, index, uuid) { >> + xa_erase(&xfs_uuid_table, index); >> + } > > I don't think this works as expected, as it just erases all uuids in > the > table. > >> +} >> >> void >> -xfs_uuid_table_free(void) >> +xfs_uuid_table_destroy(void) > > I'd drop this rename. Free works just fine here as a name. > >> + if (!xfs_uuid_search(uuid)) >> + return xfs_uuid_insert(uuid); >> >> xfs_warn(mp, "Filesystem has duplicate UUID %pU - can't mount", >> uuid); >> return -EINVAL; > > Just return an error here if xfs_uuid_search finds something, and then > open code the insert in the straight line path. > >> @@ -110,22 +119,12 @@ xfs_uuid_unmount( >> struct xfs_mount *mp) >> { >> uuid_t *uuid = &mp->m_sb.sb_uuid; >> >> if (xfs_has_nouuid(mp)) >> return; >> + xfs_uuid_delete(uuid); >> + return; > > No need for the last return. Also I think you can just open code > xfs_uuid_delete here. Thank you for all the comments! I will do all the changes. -- -lhe ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-02-03 7:23 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2026-01-30 15:42 [PATCH 0/1] xfs: Use xarray to track SB UUIDs instead of plain array Lukas Herbolt 2026-01-30 15:42 ` [PATCH] " Lukas Herbolt 2026-01-30 16:55 ` Darrick J. Wong 2026-02-02 7:31 ` Christoph Hellwig 2026-02-02 9:37 ` Lukas Herbolt 2026-02-02 18:50 ` Darrick J. Wong 2026-02-03 5:17 ` Christoph Hellwig 2026-02-03 7:23 ` Darrick J. Wong 2026-02-02 7:37 ` Christoph Hellwig 2026-02-02 9:38 ` Lukas Herbolt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox