Bug 103674 - fcntl database locking doesn't work
Summary: fcntl database locking doesn't work
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
(Show other bugs)
Version: GinGin64
Hardware: All Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-03 19:11 UTC by Michael Schröder
Modified: 2007-04-18 16:57 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-09-15 03:22:42 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 19:12 UTC, Michael Schröder
no flags Details | Diff

Description Michael Schröder 2003-09-03 19:11:05 UTC
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 19:12:11 UTC
Created attachment 94176 [details]
proposed patch

Comment 2 Jeff Johnson 2003-09-10 14:03:11 UTC

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 15:57:05 UTC
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-15 03:22:42 UTC
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 09:50:10 UTC
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 16:33:07 UTC
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.