Date: Wed, 01 Aug 2018 12:37:46 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230259] [FUSE] [BUG]: File close (release) issue Message-ID: <bug-230259-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230259 Bug ID: 230259 Summary: [FUSE] [BUG]: File close (release) issue Product: Base System Version: 11.1-RELEASE Hardware: Any URL: https://robo.moosefs.com/support/fuse_helloworld.tgz OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: freebsd@moosefs.com This is one of three issues we detected in FreeBSD FUSE while developing our distributed file system. All four issues can be replicated using this simple test script: https://robo.moosefs.com/support/fuse_helloworld.tgz When an I/O operation (for example read) takes a bit long and the process t= hat performed the read operation is killed (i.e. with 9 signal), kernel does not wait for the operation to complete but immediately sends release. Since FUS= E is multithreaded, one's program can get the release before the read (race condition), effectively ending up reading data from an already closed descriptor into no-longer-existing structures. We handled that issue in our system by making reference counters and delayi= ng release (lots of FreeBSD specific code), but since FUSE behaviour on Linux = is completely different and FUSE was first developed on Linux, we feel some consitency is warranted. Best regards, Peter / MooseFS Team --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230259-227>