Bug 103674 - fcntl database locking doesn't work
fcntl database locking doesn't work
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
GinGin64
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-09-03 15:11 EDT by Michael Schröder
Modified: 2007-04-18 12:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-09-14 23:22:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
proposed patch (947 bytes, patch)
2003-09-03 15:12 EDT, Michael Schröder
no flags Details | Diff

  None (edit)
Description Michael Schröder 2003-09-03 15:11:05 EDT
fcntl database locking is broken. The Packages database is locked once
at the start of rpm when dependency checking is done (db opened rdonly).
If everything is ok, the database is closed and re-opened rw. The problem
is that the db->close() closes the filedescriptor, and thus the fcntl
lock is lost.
Comment 1 Michael Schröder 2003-09-03 15:12:11 EDT
Created attachment 94176 [details]
proposed patch
Comment 2 Jeff Johnson 2003-09-10 10:03:11 EDT
Yup.

The more general question is:
    Does SuSE need fcntl exclusive locking?
The concurrent locking is reliable and sufficient (for rpmdb,
install/erase locking is different problem) afaict, and I'd
like to eliminate legacy code.
Comment 3 Michael Schröder 2003-09-10 11:57:05 EDT
Good question. The current code selects it as we don't have nptl.
"unshared posix mutexes found, adding DB_PRIVATE, using fcntl lock"
Comment 4 Jeff Johnson 2003-09-14 23:22:42 EDT
This is a run time test for nptl in rpmdb/db3.c.

If you don't have nptl, then you should eliminate the test,
and compile without --enable-posixmutexes (2 occurences,
autogen.sh and rpm.spec).

You will lose unified thread/process locks but that should not mattter,
the CDB locks will work fine.

Comment 5 Michael Schröder 2003-09-15 05:50:10 EDT
Uh, this *is still* a bug. If you really think it isn't you should throw
out the fcntl locking code, because it doesn't work.
Comment 6 Jeff Johnson 2003-09-15 12:33:07 EDT
Yes, fcntl locking is being phased out.

And the real bug is that reopening O_RDWR opens a locking
window, not anything else.

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