All of lore.kernel.org
 help / color / mirror / Atom feed
* [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test
@ 2014-05-12 15:06 Jeff Layton
  2014-05-12 15:06 ` [xfstests PATCH 1/4] locktest: don't assume that F_OPEN should use O_RDWR Jeff Layton
                   ` (4 more replies)
  0 siblings, 5 replies; 10+ messages in thread
From: Jeff Layton @ 2014-05-12 15:06 UTC (permalink / raw)
  To: xfs

This patchset does some general cleanup of the locktest binary, adds
some infrastructure to allow testing F_GETLK requests, and adds a new
F_GETLK test to the pile.

The main impetus here is a regression that I caused in F_GETLK handling
for v3.15. The patch is making its way to Linus now, but I want to be
sure that it doesn't regress in the future.

Jeff Layton (4):
  locktest: don't assume that F_OPEN should use O_RDWR
  locktest: set f_fd to INVALID_HANDLE on close
  locktest: consolidate do_lock and do_unlock, and add ability to
    F_GETLK
  locktest: add a F_GETLK vs. openmode test

 src/locktest.c | 125 ++++++++++++++++++++++++++-------------------------------
 1 file changed, 56 insertions(+), 69 deletions(-)

-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [xfstests PATCH 1/4] locktest: don't assume that F_OPEN should use O_RDWR
  2014-05-12 15:06 [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Jeff Layton
@ 2014-05-12 15:06 ` Jeff Layton
  2014-05-12 15:06 ` [xfstests PATCH 2/4] locktest: set f_fd to INVALID_HANDLE on close Jeff Layton
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 10+ messages in thread
From: Jeff Layton @ 2014-05-12 15:06 UTC (permalink / raw)
  To: xfs

In a later patch, I'll be adding a test for F_GETLK that will require
that we open the file with a different f_mode. Change do_open not to
assume that the it needs to open the file O_RDWR.

While we're at it, fix a bug in do_open. Just because we pass in '0' for
the flags, doesn't mean that this is the initial open.  Move the exit(1)
for that case to the caller.

Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
---
 src/locktest.c | 27 +++++++++++++--------------
 1 file changed, 13 insertions(+), 14 deletions(-)

diff --git a/src/locktest.c b/src/locktest.c
index d6198b6c1f1b..b440a43e3947 100644
--- a/src/locktest.c
+++ b/src/locktest.c
@@ -73,7 +73,7 @@ extern int h_errno;
        
 #define HANDLE              int
 #define INVALID_HANDLE      -1
-#define OPEN(N,F)           (open(N, F|O_CREAT|O_RDWR|O_BINARY| \
+#define OPEN(N,F)           (open(N, F|O_CREAT|O_BINARY| \
                             (D_flag ? O_DIRECT : 0), 0644))
 #define SEEK(H, O)          (lseek(H, O, SEEK_SET))
 #define READ(H, B, L)       (read(H, B, L))
@@ -512,35 +512,35 @@ static int64_t tests[][6] =
 		{27,	WRLOCK,	1,		5,		FAIL,		CLIENT,	},
 		{27,	F_CLOSE,0,		0,		PASS,		SERVER,	},
 		{27,	WRLOCK,	1,		5,		PASS,		CLIENT,	},
-		{27,	F_OPEN,	0,		0,		PASS,		SERVER,	},
+		{27,	F_OPEN,	O_RDWR,		0,		PASS,		SERVER,	},
 		{27,	UNLOCK,	1,		5,		PASS,		CLIENT,	},
 	/* Acquire two read locks, close one file and then reopen to check that first lock still exists */
 		{28,	RDLOCK,	1,		5,		PASS,		SERVER,	},
 		{28,	RDLOCK,	1,		5,		PASS,		CLIENT,	},
 		{28,	F_CLOSE,0,		0,		PASS,		SERVER,	},
-		{28,	F_OPEN,	0,		0,		PASS,		SERVER,	},
+		{28,	F_OPEN,	O_RDWR,		0,		PASS,		SERVER,	},
 		{28,	WRLOCK,	0,		0,		FAIL,		SERVER,	},
 		{28,	UNLOCK,	1,		5,		PASS,		SERVER,	},
 #ifdef macosx
 	/* Close the opened file and open the file with SHLOCK, other client will try to open with SHLOCK too */
 		{29,	F_CLOSE,0,		0,		PASS,		SERVER,	},
-		{29,	F_OPEN,	O_SHLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
+		{29,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
 		{29,	F_CLOSE,0,		0,		PASS,		CLIENT,	},
-		{29,	F_OPEN,	O_SHLOCK|O_NONBLOCK,	0,	PASS,		CLIENT,	},
+		{29,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		CLIENT,	},
 	/* Close the opened file and open the file with SHLOCK, other client will try to open with EXLOCK */
 		{30,	F_CLOSE,0,		0,		PASS,		SERVER,	},
 		{30,	F_CLOSE,0,		0,		PASS,		CLIENT,	},
-		{30,	F_OPEN,	O_SHLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
-		{30,	F_OPEN,	O_EXLOCK|O_NONBLOCK,	0,	FAIL,		CLIENT,	},
+		{30,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
+		{30,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	FAIL,		CLIENT,	},
 	/* Close the opened file and open the file with EXLOCK, other client will try to open with EXLOCK too */
 		{31,	F_CLOSE,0,		0,		PASS,		SERVER,	},
 		{31,	F_CLOSE,0,		0,		FAIL,		CLIENT,	},
-		{31,	F_OPEN,	O_EXLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
-		{31,	F_OPEN,	O_EXLOCK|O_NONBLOCK,	0,	FAIL,		CLIENT,	},
+		{31,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
+		{31,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	FAIL,		CLIENT,	},
 		{31,	F_CLOSE,0,		0,		PASS,		SERVER,	},
 		{31,	F_CLOSE,0,		0,		FAIL,		CLIENT,	},
-		{31,	F_OPEN,	0,		0,		PASS,		SERVER,	},
-		{31,	F_OPEN,	0,		0,		PASS,		CLIENT,	},
+		{31,	F_OPEN,	O_RDWR,		0,		PASS,		SERVER,	},
+		{31,	F_OPEN,	O_RDWR,		0,		PASS,		CLIENT,	},
 #endif /* macosx */
 	/* indicate end of array */
 		{0,0,0,0,0,SERVER},
@@ -615,8 +615,6 @@ int do_open(int flag)
 {
     if ((f_fd = OPEN(filename, flag)) == INVALID_HANDLE) {
 	perror("shared file create");
-	if (!flag)	/* Only exit if the first open fails */
-	    exit(1);
 	closed = 0;
 	return FAIL;
 	/*NOTREACHED*/
@@ -858,7 +856,8 @@ main(int argc, char *argv[])
     }
 
     filename=argv[optind];
-    do_open(0);
+    if (do_open(O_RDWR) == FAIL)
+	exit(1);
 
     /*
      * +10 is slop for the iteration number if do_write() ... never
-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [xfstests PATCH 2/4] locktest: set f_fd to INVALID_HANDLE on close
  2014-05-12 15:06 [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Jeff Layton
  2014-05-12 15:06 ` [xfstests PATCH 1/4] locktest: don't assume that F_OPEN should use O_RDWR Jeff Layton
@ 2014-05-12 15:06 ` Jeff Layton
  2014-05-12 15:06 ` [xfstests PATCH 3/4] locktest: consolidate do_lock and do_unlock, and add ability to F_GETLK Jeff Layton
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 10+ messages in thread
From: Jeff Layton @ 2014-05-12 15:06 UTC (permalink / raw)
  To: xfs

Ensure that the fd is marked invalid after close. Also, the "closed"
and "reopen" variables are always set to 0. Remove them.

Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
---
 src/locktest.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/locktest.c b/src/locktest.c
index b440a43e3947..0a674a7ff5c2 100644
--- a/src/locktest.c
+++ b/src/locktest.c
@@ -96,8 +96,6 @@ static int	debug = 0;
 static int	server = 1;
 static int	maxio = 8192;
 static int	port = 7890;
-static int	reopen=0;
-static int	closed=0;
 static int 	testnumber = -1;
 static int	saved_errno = 0;
 
@@ -615,13 +613,10 @@ int do_open(int flag)
 {
     if ((f_fd = OPEN(filename, flag)) == INVALID_HANDLE) {
 	perror("shared file create");
-	closed = 0;
 	return FAIL;
 	/*NOTREACHED*/
     }
 
-    closed = 0;
-
 #ifdef __sun
     if (D_flag) {
         directio(f_fd, DIRECTIO_ON);
@@ -701,12 +696,13 @@ int do_close(void)
 
     errno =0;
     CLOSE(f_fd);
+    f_fd = INVALID_HANDLE;
 
     saved_errno = errno;	    
 	
     if (errno)
 	return FAIL;
-    return(PASS);
+    return PASS;
 }
 
 void
@@ -778,7 +774,7 @@ void recv_ctl(void)
 void
 cleanup(void)
 {
-    if (f_fd>=0 && !reopen && !closed)
+    if (f_fd>=0)
         CLOSE(f_fd);
     
     if (c_fd>=0)
-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [xfstests PATCH 3/4] locktest: consolidate do_lock and do_unlock, and add ability to F_GETLK
  2014-05-12 15:06 [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Jeff Layton
  2014-05-12 15:06 ` [xfstests PATCH 1/4] locktest: don't assume that F_OPEN should use O_RDWR Jeff Layton
  2014-05-12 15:06 ` [xfstests PATCH 2/4] locktest: set f_fd to INVALID_HANDLE on close Jeff Layton
@ 2014-05-12 15:06 ` Jeff Layton
  2014-05-12 15:06 ` [xfstests PATCH 4/4] locktest: add a F_GETLK vs. openmode test Jeff Layton
  2014-05-12 22:58 ` [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Dave Chinner
  4 siblings, 0 replies; 10+ messages in thread
From: Jeff Layton @ 2014-05-12 15:06 UTC (permalink / raw)
  To: xfs

Eliminate do_unlock as it's just cut-and-paste of do_lock (down to the
bad stderr fprintf). Fix the debug messages to print the cmd and type,
and add the ability to do a WRTEST and RDTEST.

Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
---
 src/locktest.c | 61 ++++++++++++++++++++++------------------------------------
 1 file changed, 23 insertions(+), 38 deletions(-)

diff --git a/src/locktest.c b/src/locktest.c
index 0a674a7ff5c2..c9cd04ca4a59 100644
--- a/src/locktest.c
+++ b/src/locktest.c
@@ -110,6 +110,8 @@ static int	D_flag = 0;
 #define		UNLOCK	2
 #define		F_CLOSE	3
 #define		F_OPEN	4
+#define		WRTEST	5
+#define		RDTEST	6
 
 #define		PASS 	1
 #define		FAIL	0
@@ -629,14 +631,14 @@ int do_open(int flag)
     return PASS;
 }
 
-int do_lock(int type, int start, int length)
+static int do_lock(int cmd, int type, int start, int length)
 {
     int ret;
     int filedes = f_fd;
     struct flock fl;
 
     if(debug > 1) {
-	fprintf(stderr, "do_lock: start=%d, length=%d\n", start, length);
+	fprintf(stderr, "do_lock: cmd=%d type=%d start=%d, length=%d\n", cmd, type, start, length);
     }
 
     if (f_fd < 0)
@@ -650,7 +652,7 @@ int do_lock(int type, int start, int length)
 
     errno = 0;
 
-    ret = fcntl(filedes, F_SETLK, &fl);
+    ret = fcntl(filedes, cmd, &fl);
     saved_errno = errno;	    
 
     if(debug > 1 && ret)
@@ -659,35 +661,6 @@ int do_lock(int type, int start, int length)
     return(ret==0?PASS:FAIL);
 }
 
-int do_unlock(int start, int length)
-{
-    int ret;
-    int filedes = f_fd;
-    struct flock fl;
-
-    if(debug > 1) {
-	fprintf(stderr, "do_unlock: start=%d, length=%d\n", start, length);
-    }
-
-    if (f_fd < 0)
-	return f_fd;
-    
-    fl.l_start = start;
-    fl.l_len = length;
-    fl.l_whence = SEEK_SET;
-    fl.l_pid = getpid();
-    fl.l_type = F_UNLCK;
-
-    errno = 0;
-
-    ret = fcntl(filedes, F_SETLK, &fl);
-    saved_errno = errno;	    
-    if(debug > 1 && ret)
-	fprintf(stderr, "do_lock: ret = %d, errno = %d (%s)\n", ret, errno, strerror(errno));
-
-    return(ret==0?PASS:FAIL);
-}
-
 int do_close(void)
 {	
     if(debug > 1) {
@@ -1016,13 +989,13 @@ main(int argc, char *argv[])
 		if(tests[index][TEST_NUM] != 0) {
 		    switch(tests[index][COMMAND]) {
 			case WRLOCK:
-			    result = do_lock(F_WRLCK, tests[index][OFFSET], tests[index][LENGTH]);
+			    result = do_lock(F_SETLK, F_WRLCK, tests[index][OFFSET], tests[index][LENGTH]);
 			    break;
 			case RDLOCK:
-			    result = do_lock(F_RDLCK, tests[index][OFFSET], tests[index][LENGTH]);
+			    result = do_lock(F_SETLK, F_RDLCK, tests[index][OFFSET], tests[index][LENGTH]);
 			    break;
 			case UNLOCK:
-			    result = do_unlock(tests[index][OFFSET], tests[index][LENGTH]);
+			    result = do_lock(F_SETLK, F_UNLCK, tests[index][OFFSET], tests[index][LENGTH]);
 			    break;
 			case F_CLOSE:
 			    result = do_close();
@@ -1030,6 +1003,12 @@ main(int argc, char *argv[])
 			case F_OPEN:
 			    result = do_open(tests[index][FLAGS]);
 			    break;
+			case WRTEST:
+			    result = do_lock(F_GETLK, F_WRLCK, tests[index][OFFSET], tests[index][LENGTH]);
+			    break;
+			case RDTEST:
+			    result = do_lock(F_GETLK, F_RDLCK, tests[index][OFFSET], tests[index][LENGTH]);
+			    break;
 		    }
 		    if( result != tests[index][RESULT]) {
 			fail_flag++;
@@ -1126,13 +1105,13 @@ main(int argc, char *argv[])
 	    ctl.length = tests[index][LENGTH];
 	    switch(tests[index][COMMAND]) {
 		case WRLOCK:
-		    result = do_lock(F_WRLCK, tests[index][OFFSET], tests[index][LENGTH]);
+		    result = do_lock(F_SETLK, F_WRLCK, tests[index][OFFSET], tests[index][LENGTH]);
 		    break;
 		case RDLOCK:
-		    result = do_lock(F_RDLCK, tests[index][OFFSET], tests[index][LENGTH]);
+		    result = do_lock(F_SETLK, F_RDLCK, tests[index][OFFSET], tests[index][LENGTH]);
 		    break;
 		case UNLOCK:
-		    result = do_unlock(tests[index][OFFSET], tests[index][LENGTH]);
+		    result = do_lock(F_SETLK, F_UNLCK, tests[index][OFFSET], tests[index][LENGTH]);
 		    break;
 		case F_CLOSE:
 		    result = do_close();
@@ -1140,6 +1119,12 @@ main(int argc, char *argv[])
 		case F_OPEN:
 		    result = do_open(tests[index][FLAGS]);
 		    break;
+		case WRTEST:
+		    result = do_lock(F_GETLK, F_WRLCK, tests[index][OFFSET], tests[index][LENGTH]);
+		    break;
+		case RDTEST:
+		    result = do_lock(F_GETLK, F_RDLCK, tests[index][OFFSET], tests[index][LENGTH]);
+		    break;
 	    }
 	    if( result != tests[index][RESULT] ) {
 		if(debug)
-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* [xfstests PATCH 4/4] locktest: add a F_GETLK vs. openmode test
  2014-05-12 15:06 [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Jeff Layton
                   ` (2 preceding siblings ...)
  2014-05-12 15:06 ` [xfstests PATCH 3/4] locktest: consolidate do_lock and do_unlock, and add ability to F_GETLK Jeff Layton
@ 2014-05-12 15:06 ` Jeff Layton
  2014-05-12 22:58 ` [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Dave Chinner
  4 siblings, 0 replies; 10+ messages in thread
From: Jeff Layton @ 2014-05-12 15:06 UTC (permalink / raw)
  To: xfs

POSIX says that you're allowed to do F_GETLK for a F_WRLCK on an
O_RDONLY file description.

Signed-off-by: Jeff Layton <jlayton@poochiereds.net>
---
 src/locktest.c | 41 ++++++++++++++++++++++++-----------------
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/src/locktest.c b/src/locktest.c
index c9cd04ca4a59..23bb2406dc24 100644
--- a/src/locktest.c
+++ b/src/locktest.c
@@ -180,10 +180,11 @@ char *descriptions[] = {
     /* 26 */"Acquire read and write locks with overlapping ranges",
     /* 27 */"Acquire whole file write lock and then close without unlocking (and attempt a lock)",
     /* 28 */"Acquire two read locks, close and reopen the file, and test if the inital lock is still there",
+    /* 29 */"Verify that F_GETLK for F_WRLCK doesn't require that file be opened for write",
     #if defined(macosx)
-    /* 29 */"Close the opened file and open the file with SHLOCK, other client will try to open with SHLOCK too",
-    /* 30 */"Close the opened file and open the file with SHLOCK, other client will try to open with EXLOCK",
-    /* 31 */"Close the opened file and open the file with EXLOCK, other client will try to open with EXLOCK too"
+    /* 30 */"Close the opened file and open the file with SHLOCK, other client will try to open with SHLOCK too",
+    /* 31 */"Close the opened file and open the file with SHLOCK, other client will try to open with EXLOCK",
+    /* 32 */"Close the opened file and open the file with EXLOCK, other client will try to open with EXLOCK too"
     #endif
 };
 
@@ -521,26 +522,32 @@ static int64_t tests[][6] =
 		{28,	F_OPEN,	O_RDWR,		0,		PASS,		SERVER,	},
 		{28,	WRLOCK,	0,		0,		FAIL,		SERVER,	},
 		{28,	UNLOCK,	1,		5,		PASS,		SERVER,	},
+	/* Verify that F_GETLK for F_WRLCK doesn't require that file be opened for write */
+		{29,	F_CLOSE, 0,		0,		PASS,		SERVER, },
+		{29,	F_OPEN, O_RDONLY,	0,		PASS,		SERVER, },
+		{29,	WRTEST, 0,		0,		PASS,		SERVER, },
+		{29,	F_CLOSE,0,		0,		PASS,		SERVER,	},
+		{29,	F_OPEN,	O_RDWR,		0,		PASS,		SERVER,	},
 #ifdef macosx
 	/* Close the opened file and open the file with SHLOCK, other client will try to open with SHLOCK too */
-		{29,	F_CLOSE,0,		0,		PASS,		SERVER,	},
-		{29,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
-		{29,	F_CLOSE,0,		0,		PASS,		CLIENT,	},
-		{29,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		CLIENT,	},
-	/* Close the opened file and open the file with SHLOCK, other client will try to open with EXLOCK */
 		{30,	F_CLOSE,0,		0,		PASS,		SERVER,	},
-		{30,	F_CLOSE,0,		0,		PASS,		CLIENT,	},
 		{30,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
-		{30,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	FAIL,		CLIENT,	},
-	/* Close the opened file and open the file with EXLOCK, other client will try to open with EXLOCK too */
+		{30,	F_CLOSE,0,		0,		PASS,		CLIENT,	},
+		{30,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		CLIENT,	},
+	/* Close the opened file and open the file with SHLOCK, other client will try to open with EXLOCK */
 		{31,	F_CLOSE,0,		0,		PASS,		SERVER,	},
-		{31,	F_CLOSE,0,		0,		FAIL,		CLIENT,	},
-		{31,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
+		{31,	F_CLOSE,0,		0,		PASS,		CLIENT,	},
+		{31,	F_OPEN,	O_RDWR|O_SHLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
 		{31,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	FAIL,		CLIENT,	},
-		{31,	F_CLOSE,0,		0,		PASS,		SERVER,	},
-		{31,	F_CLOSE,0,		0,		FAIL,		CLIENT,	},
-		{31,	F_OPEN,	O_RDWR,		0,		PASS,		SERVER,	},
-		{31,	F_OPEN,	O_RDWR,		0,		PASS,		CLIENT,	},
+	/* Close the opened file and open the file with EXLOCK, other client will try to open with EXLOCK too */
+		{32,	F_CLOSE,0,		0,		PASS,		SERVER,	},
+		{32,	F_CLOSE,0,		0,		FAIL,		CLIENT,	},
+		{32,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	PASS,		SERVER,	},
+		{32,	F_OPEN,	O_RDWR|O_EXLOCK|O_NONBLOCK,	0,	FAIL,		CLIENT,	},
+		{32,	F_CLOSE,0,		0,		PASS,		SERVER,	},
+		{32,	F_CLOSE,0,		0,		FAIL,		CLIENT,	},
+		{32,	F_OPEN,	O_RDWR,		0,		PASS,		SERVER,	},
+		{32,	F_OPEN,	O_RDWR,		0,		PASS,		CLIENT,	},
 #endif /* macosx */
 	/* indicate end of array */
 		{0,0,0,0,0,SERVER},
-- 
1.9.0

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test
  2014-05-12 15:06 [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Jeff Layton
                   ` (3 preceding siblings ...)
  2014-05-12 15:06 ` [xfstests PATCH 4/4] locktest: add a F_GETLK vs. openmode test Jeff Layton
@ 2014-05-12 22:58 ` Dave Chinner
  2014-05-13  0:35   ` Jeff Layton
  4 siblings, 1 reply; 10+ messages in thread
From: Dave Chinner @ 2014-05-12 22:58 UTC (permalink / raw)
  To: Jeff Layton; +Cc: xfs

On Mon, May 12, 2014 at 11:06:29AM -0400, Jeff Layton wrote:
> This patchset does some general cleanup of the locktest binary, adds
> some infrastructure to allow testing F_GETLK requests, and adds a new
> F_GETLK test to the pile.
> 
> The main impetus here is a regression that I caused in F_GETLK handling
> for v3.15. The patch is making its way to Linus now, but I want to be
> sure that it doesn't regress in the future.

So do these changes cause locktest to fail on older kernels? i.e.
does changing the test cause the locktest tests to fail where
previously they passed? If so, we're going to have to make this a
little more complex...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test
  2014-05-12 22:58 ` [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Dave Chinner
@ 2014-05-13  0:35   ` Jeff Layton
  2014-05-13  0:54     ` Dave Chinner
  2014-05-13  1:00     ` Dave Chinner
  0 siblings, 2 replies; 10+ messages in thread
From: Jeff Layton @ 2014-05-13  0:35 UTC (permalink / raw)
  To: Dave Chinner; +Cc: xfs

On Tue, 13 May 2014 08:58:45 +1000
Dave Chinner <david@fromorbit.com> wrote:

> On Mon, May 12, 2014 at 11:06:29AM -0400, Jeff Layton wrote:
> > This patchset does some general cleanup of the locktest binary, adds
> > some infrastructure to allow testing F_GETLK requests, and adds a new
> > F_GETLK test to the pile.
> > 
> > The main impetus here is a regression that I caused in F_GETLK handling
> > for v3.15. The patch is making its way to Linus now, but I want to be
> > sure that it doesn't regress in the future.
> 
> So do these changes cause locktest to fail on older kernels? i.e.
> does changing the test cause the locktest tests to fail where
> previously they passed? If so, we're going to have to make this a
> little more complex...
> 

I haven't tested on much in the way of older kernels, but I wouldn't
expect it to cause any problems. The only behavior change that should
be introduced is the F_GETLK test, and older kernels should pass that
just fine (modulo v3.15 which has a regression that should be patched
soon). The rest of the changes are just cleanups, and shouldn't
introduce any behavioral changes.

-- 
Jeff Layton <jlayton@poochiereds.net>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test
  2014-05-13  0:35   ` Jeff Layton
@ 2014-05-13  0:54     ` Dave Chinner
  2014-05-13  1:00     ` Dave Chinner
  1 sibling, 0 replies; 10+ messages in thread
From: Dave Chinner @ 2014-05-13  0:54 UTC (permalink / raw)
  To: Jeff Layton; +Cc: xfs

On Mon, May 12, 2014 at 08:35:05PM -0400, Jeff Layton wrote:
> On Tue, 13 May 2014 08:58:45 +1000
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > On Mon, May 12, 2014 at 11:06:29AM -0400, Jeff Layton wrote:
> > > This patchset does some general cleanup of the locktest binary, adds
> > > some infrastructure to allow testing F_GETLK requests, and adds a new
> > > F_GETLK test to the pile.
> > > 
> > > The main impetus here is a regression that I caused in F_GETLK handling
> > > for v3.15. The patch is making its way to Linus now, but I want to be
> > > sure that it doesn't regress in the future.
> > 
> > So do these changes cause locktest to fail on older kernels? i.e.
> > does changing the test cause the locktest tests to fail where
> > previously they passed? If so, we're going to have to make this a
> > little more complex...
> > 
> 
> I haven't tested on much in the way of older kernels, but I wouldn't
> expect it to cause any problems. The only behavior change that should
> be introduced is the F_GETLK test, and older kernels should pass that
> just fine (modulo v3.15 which has a regression that should be patched
> soon). The rest of the changes are just cleanups, and shouldn't
> introduce any behavioral changes.

Ok, I wasn't sure if it was adding a test that never worked, or
whether it was checking for a recent regression. If it's a recent
regression, then there's no problem with the change. Thanks! :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test
  2014-05-13  0:35   ` Jeff Layton
  2014-05-13  0:54     ` Dave Chinner
@ 2014-05-13  1:00     ` Dave Chinner
  2014-05-13  1:13       ` Jeff Layton
  1 sibling, 1 reply; 10+ messages in thread
From: Dave Chinner @ 2014-05-13  1:00 UTC (permalink / raw)
  To: Jeff Layton; +Cc: xfs

On Mon, May 12, 2014 at 08:35:05PM -0400, Jeff Layton wrote:
> On Tue, 13 May 2014 08:58:45 +1000
> Dave Chinner <david@fromorbit.com> wrote:
> 
> > On Mon, May 12, 2014 at 11:06:29AM -0400, Jeff Layton wrote:
> > > This patchset does some general cleanup of the locktest binary, adds
> > > some infrastructure to allow testing F_GETLK requests, and adds a new
> > > F_GETLK test to the pile.
> > > 
> > > The main impetus here is a regression that I caused in F_GETLK handling
> > > for v3.15. The patch is making its way to Linus now, but I want to be
> > > sure that it doesn't regress in the future.
> > 
> > So do these changes cause locktest to fail on older kernels? i.e.
> > does changing the test cause the locktest tests to fail where
> > previously they passed? If so, we're going to have to make this a
> > little more complex...
> > 
> 
> I haven't tested on much in the way of older kernels, but I wouldn't
> expect it to cause any problems. The only behavior change that should
> be introduced is the F_GETLK test, and older kernels should pass that
> just fine (modulo v3.15 which has a regression that should be patched
> soon). The rest of the changes are just cleanups, and shouldn't
> introduce any behavioral changes.

Is this the regression in question?

+Server failure in 29:Verify that F_GETLK for F_WRLCK doesn't
require that file be opened for write

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test
  2014-05-13  1:00     ` Dave Chinner
@ 2014-05-13  1:13       ` Jeff Layton
  0 siblings, 0 replies; 10+ messages in thread
From: Jeff Layton @ 2014-05-13  1:13 UTC (permalink / raw)
  To: Dave Chinner; +Cc: xfs

On Tue, 13 May 2014 11:00:28 +1000
Dave Chinner <david@fromorbit.com> wrote:

> On Mon, May 12, 2014 at 08:35:05PM -0400, Jeff Layton wrote:
> > On Tue, 13 May 2014 08:58:45 +1000
> > Dave Chinner <david@fromorbit.com> wrote:
> > 
> > > On Mon, May 12, 2014 at 11:06:29AM -0400, Jeff Layton wrote:
> > > > This patchset does some general cleanup of the locktest binary, adds
> > > > some infrastructure to allow testing F_GETLK requests, and adds a new
> > > > F_GETLK test to the pile.
> > > > 
> > > > The main impetus here is a regression that I caused in F_GETLK handling
> > > > for v3.15. The patch is making its way to Linus now, but I want to be
> > > > sure that it doesn't regress in the future.
> > > 
> > > So do these changes cause locktest to fail on older kernels? i.e.
> > > does changing the test cause the locktest tests to fail where
> > > previously they passed? If so, we're going to have to make this a
> > > little more complex...
> > > 
> > 
> > I haven't tested on much in the way of older kernels, but I wouldn't
> > expect it to cause any problems. The only behavior change that should
> > be introduced is the F_GETLK test, and older kernels should pass that
> > just fine (modulo v3.15 which has a regression that should be patched
> > soon). The rest of the changes are just cleanups, and shouldn't
> > introduce any behavioral changes.
> 
> Is this the regression in question?
> 
> +Server failure in 29:Verify that F_GETLK for F_WRLCK doesn't
> require that file be opened for write
> 
> Cheers,
> 
> Dave.

Yes, that's the test I'm adding for the kernel regression. The patch
for the bug is:

    [PATCH v2] locks: only validate the lock vs. f_mode in F_SETLK codepaths

...and I sent a pull request to Linus for it today. It should go in
fairly soon, I hope.

Thanks,
-- 
Jeff Layton <jlayton@poochiereds.net>

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2014-05-13  1:13 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-12 15:06 [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 1/4] locktest: don't assume that F_OPEN should use O_RDWR Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 2/4] locktest: set f_fd to INVALID_HANDLE on close Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 3/4] locktest: consolidate do_lock and do_unlock, and add ability to F_GETLK Jeff Layton
2014-05-12 15:06 ` [xfstests PATCH 4/4] locktest: add a F_GETLK vs. openmode test Jeff Layton
2014-05-12 22:58 ` [xfstests PATCH 0/4] locktest: cleanup, bugfixes, and add new locking test Dave Chinner
2014-05-13  0:35   ` Jeff Layton
2014-05-13  0:54     ` Dave Chinner
2014-05-13  1:00     ` Dave Chinner
2014-05-13  1:13       ` Jeff Layton

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.