[PATCH] MIPS: export __cmpxchg_small()

David Sterba posted 1 patch 1 month ago
arch/mips/kernel/cmpxchg.c | 1 +
1 file changed, 1 insertion(+)
[PATCH] MIPS: export __cmpxchg_small()
Posted by David Sterba 1 month ago
Export the symbol __cmpxchg_small() for btrfs.ko that will use it to
store blk_status_t, which is u8. Reported by LKP:

>> ERROR: modpost: "__cmpxchg_small" [fs/btrfs/btrfs.ko] undefined!

Patch using the cmpxchg() https://lore.kernel.org/linux-btrfs/1d4f72f7fee285b2ddf4bf62b0ac0fd89def5417.1728575379.git.naohiro.aota@wdc.com/

Link: https://lore.kernel.org/all/20241016134919.GO1609@suse.cz/
Signed-off-by: David Sterba <dsterba@suse.com>
---

I can merge it via the btrfs git tree along the fix or wait until it's
merged the usual way, please let me know.

 arch/mips/kernel/cmpxchg.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/kernel/cmpxchg.c b/arch/mips/kernel/cmpxchg.c
index e974a4954df8..c371def2302d 100644
--- a/arch/mips/kernel/cmpxchg.c
+++ b/arch/mips/kernel/cmpxchg.c
@@ -102,3 +102,4 @@ unsigned long __cmpxchg_small(volatile void *ptr, unsigned long old,
 			return old;
 	}
 }
+EXPORT_SYMBOL(__cmpxchg_small);
-- 
2.45.0
Re: [PATCH] MIPS: export __cmpxchg_small()
Posted by Thomas Bogendoerfer 1 month ago
On Tue, Oct 22, 2024 at 04:39:13PM +0200, David Sterba wrote:
> Export the symbol __cmpxchg_small() for btrfs.ko that will use it to
> store blk_status_t, which is u8. Reported by LKP:
> 
> >> ERROR: modpost: "__cmpxchg_small" [fs/btrfs/btrfs.ko] undefined!
> 
> Patch using the cmpxchg() https://lore.kernel.org/linux-btrfs/1d4f72f7fee285b2ddf4bf62b0ac0fd89def5417.1728575379.git.naohiro.aota@wdc.com/
> 
> Link: https://lore.kernel.org/all/20241016134919.GO1609@suse.cz/
> Signed-off-by: David Sterba <dsterba@suse.com>
> ---
> 
> I can merge it via the btrfs git tree along the fix or wait until it's
> merged the usual way, please let me know.

just merge via btrfs tree.

Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]