Switch to the new atomic Uint64.Add api

The new api guarantees that the value is aligned, preventing
stuff like this on 32 bit platforms:

	goroutine 26 [running]:
	internal/runtime/atomic.panicUnaligned()
		/usr/lib/go-1.24/src/internal/runtime/atomic/unaligned.go:8 +0x24
	internal/runtime/atomic.Xadd64(0x2496c74, 0x1)
		/usr/lib/go-1.24/src/internal/runtime/atomic/atomic_arm.s:318 +0x14
	github.com/rfjakob/gocryptfs/internal/inomap.(*InoMap).NextSpillIno(0x2496c60)

Fixes https://github.com/rfjakob/gocryptfs/issues/912

1 files changed, 3 insertions, 3 deletions

diff --git a/internal/openfiletable/open_file_table.go b/internal/openfiletable/open_file_table.go
index ce8df76..420d070 100644
--- a/internal/openfiletable/open_file_table.go
+++ b/internal/openfiletable/open_file_table.go
@@ -29,7 +29,7 @@ type table struct {
 	// The variable is accessed without holding any locks so atomic operations
 	// must be used. It must be the first element of the struct to guarantee
 	// 64-bit alignment.
-	writeOpCount uint64
+	writeOpCount atomic.Uint64
 	// Protects map access
 	sync.Mutex
 	// Table entries
@@ -85,13 +85,13 @@ type countingMutex struct {
 
 func (c *countingMutex) Lock() {
 	c.RWMutex.Lock()
-	atomic.AddUint64(&t.writeOpCount, 1)
+	t.writeOpCount.Add(1)
 }
 
 // WriteOpCount returns the write lock counter value. This value is incremented
 // each time writeLock.Lock() on a file table entry is called.
 func WriteOpCount() uint64 {
-	return atomic.LoadUint64(&t.writeOpCount)
+	return t.writeOpCount.Load()
 }
 
 // CountOpenFiles returns how many entries are currently in the table