Small fix to remove invalid byte range locks

[Zack Kirsch]

Hi Volker and samba-tech,

 

This is a small bug that we noticed while working on some byte range
locking code. This patch sets the modified bit on the byte_range_lock
struct, if validate_lock_entries() has changed the pplocks parameter
passed in (i.e. removed some invalid locks.)  With the modified bit set,
the byte_range_lock_destructor() should commit the modifications, by
calling tdb_store().

 

You could argue that perhaps this is done by design, but it seems that
if Samba is going to go through the effort to find invalid byte range
locks, it should remove them as well.

 

As a warning, I haven't had time to test this code path. The bug was
originally found and fixed by Doug Rudoff (doug_rudoff at isilon.com).

Zack Kirsch | Software Development Engineer
Isilon Systems    P +1-206-315-7500     F  +1-206-315-7501
www.isilon.com    D +1-206-315-7487    M +1-206-601-5465

Isilon Systems: How breakthroughs begin. (tm)

-------------- next part --------------
Index: locking/brlock.c
===================================================================
--- locking/brlock.c	(revision 23511)
+++ locking/brlock.c	(working copy)
@@ -1646,6 +1646,7 @@
 	memcpy(br_lck->lock_data, data.dptr, data.dsize);
 	
 	if (!fsp->lockdb_clean) {
+		int orig_num_locks = br_lck->num_locks;
 
 		/* This is the first time we've accessed this. */
 		/* Go through and ensure all entries exist - remove any that don't. */
@@ -1658,6 +1659,10 @@
 			return NULL;
 		}
 
+		/* Ensure invalid locks are cleaned up in the destructor. */
+		if (orig_num_locks != br_lck->num_locks)
+			br_lck->modified = True;
+
 		/* Mark the lockdb as "clean" as seen from this open file. */
 		fsp->lockdb_clean = True;
 	}