Files
seaweedfs/weed/mount/weedfs_xattr_test.go
T
Chris Lu fd493f2547 mount: refuse to attach opens to a draining file handle (#12219)
* mount: refuse to attach opens to a draining file handle

With the writeback cache, releasing the last open of a file leaves the
shared FileHandle in the map at counter zero while an async flush
drains it; the worker removes the map entries once the flush commits.
AcquireHandle waits for a pending flush and then attaches, but the two
steps are not atomic: a release can slip in between, drop the counter
to zero, and queue the drain while the opener goes on to mint a new
file-handle id on the draining handle. When the drain completes,
RemoveFileHandle deletes every fh id for the inode -- including the one
just minted. The kernel still holds that id, so its next FUSE_READ
gets ENOENT from GetHandle; the failed read leaves the folio not
uptodate and the kernel surfaces EIO to userspace. This was the flaky
TestWritebackCacheConcurrentMixedOps failure.

AcquireFileHandle now refuses to attach when the shared handle has
reached a zero counter and reports it as draining. AcquireHandle and
the Create path retry the whole wait-resolve-attach sequence; the next
pass blocks on the pending flush (flag registration and the counter
drop share pendingAsyncFlushMu) and builds a fresh handle from the
post-flush entry. The DLM-failure release in AcquireHandle also goes
through ReleaseHandle so it cannot strand a counter-zero handle
outside the drain bookkeeping.

Removes the refreshEntryForRead retry from #12206, which worked around
the symptom by refetching the entry after the fh id was already gone.

Test: TestAcquireFileHandleRefusesDrainingHandle covers the refusal
and fresh-handle path; TestWritebackCacheConcurrentMixedOps and an
amplified concurrent-overwrite repro run clean.

* mount: keep refresh-on-error retry for stale-chunk reads
2026-10-29 16:06:57 -07:00

63 lines
2.1 KiB
Go

//go:build !freebsd
package mount
import (
"testing"
"github.com/seaweedfs/go-fuse/v2/fuse"
"github.com/seaweedfs/seaweedfs/weed/pb/filer_pb"
"github.com/seaweedfs/seaweedfs/weed/util"
)
// TestSetXAttrCopiesValueBuffer reproduces the bug from
// https://github.com/seaweedfs/seaweedfs/discussions/9275 where `cp -a`
// of a file with an extended attribute leaves the destination with a
// corrupted value. The root cause is that go-fuse hands SetXAttr a
// `data` slice that aliases the per-request input buffer; when the
// buffer is returned to the pool and reused for another FUSE request,
// any reference still held by entry.Extended sees garbage.
//
// The bug only manifested when the file was open during setxattr (the
// open-fh path defers persistence to flush). We simulate that by
// mutating the caller-supplied buffer after SetXAttr returns.
func TestSetXAttrCopiesValueBuffer(t *testing.T) {
wfs := newCopyRangeTestWFS()
path := util.FullPath("/aaa.txt")
inode := wfs.inodeToPath.Lookup(path, 1, false, false, 0, true)
fh, _, _, _ := wfs.fhMap.AcquireFileHandle(wfs, inode, &filer_pb.Entry{
Name: "aaa.txt",
Attributes: &filer_pb.FuseAttributes{
FileMode: 0100644,
Inode: inode,
},
}, 0, 0)
fh.RememberPath(path)
// Caller buffer aliases a pool that the kernel will overwrite on
// the very next request. SetXAttr must defensively copy.
buf := []byte("test,in")
status := wfs.SetXAttr(make(chan struct{}), &fuse.SetXAttrIn{
InHeader: fuse.InHeader{NodeId: inode},
}, "user.xtags", buf)
if status != fuse.OK {
t.Fatalf("SetXAttr status = %v, want OK", status)
}
// Simulate the request buffer being recycled and reused for an
// unrelated payload.
for i := range buf {
buf[i] = 0xff
}
dest := make([]byte, 64)
n, status := wfs.GetXAttr(make(chan struct{}), &fuse.InHeader{NodeId: inode}, "user.xtags", dest)
if status != fuse.OK {
t.Fatalf("GetXAttr status = %v, want OK", status)
}
if got := string(dest[:n]); got != "test,in" {
t.Fatalf("GetXAttr value = %q, want %q (buffer aliasing leaked into stored xattr)", got, "test,in")
}
}