Bug 742596 - open() of existing file with O_EXCL on NFS filesystems incorrectly succeeds immediately after mounting filesystem
Summary: open() of existing file with O_EXCL on NFS filesystems incorrectly succeeds i...
Keywords:
Status: CLOSED DUPLICATE of bug 694210
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-30 17:19 UTC by Marc Riddle
Modified: 2011-10-03 12:30 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-10-03 12:30:25 UTC
Target Upstream Version:


Attachments (Terms of Use)
reproducer for o_excl bug (695 bytes, application/octet-stream)
2011-09-30 17:22 UTC, Marc Riddle
no flags Details

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 ***


Note You need to log in before you can comment on or make changes to this bug.