Bug 742596

Summary: open() of existing file with O_EXCL on NFS filesystems incorrectly succeeds immediately after mounting filesystem
Product: Red Hat Enterprise Linux 6 Reporter: Marc Riddle <mriddle>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED DUPLICATE QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.4CC: bfields, dhowells, jlayton, rwheeler, sprabhu, steved
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-10-03 12:30:25 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
reproducer for o_excl bug none

Description Marc Riddle 2011-09-30 17:19:02 UTC
Description of problem:
(some background: we run several mysql databases with nfs datadirs, and recently upgraded one of our servers to rhel6. After unmounting and remounting the datadir, mysql was starting up with lots of errors about inaccessible tables. Some further troubleshooting found that when mysql starts up it tries to open the ibdata file with O_RDWR|O_CREAT|O_EXCL, and if that call is successful (which would generally indicate that the file didn't exist) it creates a new ibdata file, effectively destroying the relationship between datafiles on disk and the running database.)

Root problem: moving to rhel6, a regression appears to have been introduced, which causes an open() wiht the O_EXCL flag to return incorrect results on file on a newly mounted nfs filesytem.

Version-Release number of selected component (if applicable):
rhel 6.1

How reproducible:
compile attached o_excl.c and follow directions below.

Steps to Reproduce:
(in this case, /db is an nfs filesystem)

[mriddle@db101 src]$ cc -o o_excl o_excl.c 
[mriddle@db101 src]$ sudo touch /db/foo; sudo chown mriddle /db/foo
[mriddle@db101 src]$ ./o_excl /db/foo 
open() of /db/foo returned -1, not creating new file (this is good)
[mriddle@db101 src]$ sudo umount /db
[mriddle@db101 src]$ sudo mount /db
[mriddle@db101 src]$ ./o_excl /db/foo 
open() of /db/foo successful, this is bad!


Actual results:
After mounting an nfs filesystem, an open() that should fail succeeds

Expected results:
open() should fail in this scenario

Additional info:

Comment 1 Marc Riddle 2011-09-30 17:22:45 UTC
Created attachment 525802 [details]
reproducer for o_excl bug

Comment 3 Marc Riddle 2011-09-30 17:57:46 UTC
Looking at the release notes of the most recent kernel package, I found:

2011-07-21 12:00:00 
Frantisek Hrbata <fhrbata> [2.6.32-131.10.1.el6]: 
- [fs] NFS: Fix NFSv3 exclusive open semantics (Jeff Layton) [719925 694210]

along with this in the errata notes:

This update fixes a regression in which a client would use an UNCHECKED NFS CREATE call when an oen system call was attempted with the O_EXCL|O_CREAT flag combination. An EXCLUSIVE NFS CREATE call should have been used instead to ensure that O_EXCL semantics were preserved. As a result, an application could be led to believe that it had created the file when it was in fact created by anyother application.

I'm installing this package now, but expect it to resolve my issue. 

Unfortunately the two bugzilla bugs referenced in the changelog are not visible to me, so when I searched for a similar bug I was unable to find one.

Comment 4 Ric Wheeler 2011-09-30 17:58:51 UTC
Please let us know how the testing goes, thanks!

Comment 5 Jeff Layton 2011-10-03 12:30:25 UTC

*** This bug has been marked as a duplicate of bug 694210 ***