From e3501faaf5e8ca0da102155f8cfa1a6543217ce8 Mon Sep 17 00:00:00 2001 From: Panu Matilainen Date: Thu, 16 May 2013 12:32:45 +0300 Subject: [PATCH] - check for stale locks when opening write-cursors (#860500, #962750...) --- rpm-4.11.x-cursor-failchk.patch | 56 +++++++++++++++++++++++++++++++++ rpm.spec | 8 ++++- 2 files changed, 63 insertions(+), 1 deletion(-) create mode 100644 rpm-4.11.x-cursor-failchk.patch diff --git a/rpm-4.11.x-cursor-failchk.patch b/rpm-4.11.x-cursor-failchk.patch new file mode 100644 index 0000000..1f46068 --- /dev/null +++ b/rpm-4.11.x-cursor-failchk.patch @@ -0,0 +1,56 @@ +commit 452553111b9929074bcbb77a49c041582daae0e8 +Author: Panu Matilainen +Date: Tue Feb 5 10:11:19 2013 +0200 + + Check for stale db locks when opening write-cursors + + - During long-running transactions its entirely possible for some + other player to come and go leaving stale locks behind and cause + the transaction to get stuck until the cavalry comes along in the + form of somebody else opening the rpmdb, clearing the blockage. + - Presumably dbenv->failchk() is not entirely free of cost so we only + do this for writes which are way more critical and also more prone to + getting stuck. + - dbenv->failchk() could return DB_RUNRECOVER in which case we should + abort everything but we lack a mechanism to do it... just add + a reminder comment for now. + +diff --git a/lib/backend/db3.c b/lib/backend/db3.c +index 656486b..de8071b 100644 +--- a/lib/backend/db3.c ++++ b/lib/backend/db3.c +@@ -248,7 +248,7 @@ dbiCursor dbiCursorInit(dbiIndex dbi, unsigned int flags) + DB * db = dbi->dbi_db; + DBC * cursor; + int cflags; +- int rc; ++ int rc = 0; + uint32_t eflags = db_envflags(db); + + /* DB_WRITECURSOR requires CDB and writable db */ +@@ -259,8 +259,23 @@ dbiCursor dbiCursorInit(dbiIndex dbi, unsigned int flags) + } else + cflags = 0; + +- rc = db->cursor(db, NULL, &cursor, cflags); +- rc = cvtdberr(dbi, "db->cursor", rc, _debug); ++ /* ++ * Check for stale locks which could block writes "forever". ++ * XXX: Should we also do this on reads? Reads are less likely ++ * to get blocked so it seems excessive... ++ * XXX: On DB_RUNRECOVER, we should abort everything. Now ++ * we'll just fail to open a cursor again and again and again. ++ */ ++ if (cflags & DB_WRITECURSOR) { ++ DB_ENV *dbenv = db->get_env(db); ++ rc = dbenv->failchk(dbenv, 0); ++ rc = cvtdberr(dbi, "dbenv->failchk", rc, _debug); ++ } ++ ++ if (rc == 0) { ++ rc = db->cursor(db, NULL, &cursor, cflags); ++ rc = cvtdberr(dbi, "db->cursor", rc, _debug); ++ } + + if (rc == 0) { + dbc = xcalloc(1, sizeof(*dbc)); diff --git a/rpm.spec b/rpm.spec index b061045..6bbc491 100644 --- a/rpm.spec +++ b/rpm.spec @@ -21,7 +21,7 @@ Summary: The RPM package management system Name: rpm Version: %{rpmver} -Release: %{?snapver:0.%{snapver}.}3%{?dist} +Release: %{?snapver:0.%{snapver}.}4%{?dist} Group: System Environment/Base Url: http://www.rpm.org/ Source0: http://rpm.org/releases/testing/%{name}-%{srcver}.tar.bz2 @@ -47,6 +47,8 @@ Patch6: rpm-4.9.0-armhfp-logic.patch # Patches already in upstream # http://www.rpm.org/ticket/865 Patch100: 0001-Finish-lua-5.2-support-trac-865.patch +# Check for stale locks when opening write-cursors +Patch101: rpm-4.11.x-cursor-failchk.patch # These are not yet upstream Patch301: rpm-4.6.0-niagara.patch @@ -226,6 +228,7 @@ packages on a system. %patch4 -p1 -b .use-gpg2 %patch100 -p1 -b .lua-5.2 +%patch101 -p1 -b .cursor-failchk %patch301 -p1 -b .niagara %patch302 -p1 -b .geode @@ -459,6 +462,9 @@ exit 0 %doc COPYING doc/librpm/html/* %changelog +* Thu May 16 2013 Panu Matilainen - - 4.11.0.1-4 +- check for stale locks when opening write-cursors (#860500, #962750...) + * Fri May 10 2013 Tom Callaway - 4.11.0.1-3 - lua 5.2 fix from upstream