Subject: RE: [nfsv4] Parallel open support

From: [email-masked]
Date: Wed, 20 Sep 2006 15:41:43 -0400 (EDT)

> So how do you deal with situations like the following:
> 
> 2 threads, both part of the same process (and therefore sharing the same
> lock_owner). Due to an application programming error, both launch a
> conflicting lock request at the same time.
> 
> Thread 1				Thread 2
> ========				========
> fd1 = open("foo",O_RDONLY);
> 					fd1 = open("foo", O_WRONLY);
> 
> fcntl(fd1, F_SETLK,			fd2 = fcntl(fd2, F_SETLK,
> 	{ F_RDLCK,					{ F_WRLCK,
> 	  SEEK_SET,					  SEEK_SET,
> 	  0, 100,					  50, 100,
> 	});						});
> 
> Will your client order these requests on the wire? How?
> 
> If the requests are unordered, how does it figure out what type of lock
> was just set on this file?
> 
> Note that if the client gets the type of lock wrong above, then reboot
> recovery quickly becomes a nightmare: imagine if the client recovers a
> write lock, when it originally held a read lock on the server.

They will be serialized above the vfs layer and happen in one of the two
possible orders. The recovery will recover that result. (Maybe not what
the broken app. expected, but as you said, it's broken.) In BSD, vops are
serialized for a given nfs vnode and an nfs vnode is issued for an FH, not
per descriptor.

If the vfs didn't serialize them, I would do so at the beginning of the
VOP_ADVLOCK() call, just below the vfs.

rick

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Erblichs <[email-masked]>
Date: Wed, 20 Sep 2006 17:36:43 -0700

Group,

	Fill me in...

	The two open calls SHOULD be acting like a pipe call, one fd
	does reading and the other writing..

	So the first question should be whether the implementation
	allows over-writing the fd variable. I don't know of any that
	prevent this type of accidental coding.

	A VOP access call will be implicitly called to verify
	that the VOP operation is restricted by the FCNTL arg
	wich is the 2nd arg to the open.

	Also, In a UP environment only one thread could launch the
	request and I assume the standard implimentation will
	guarantee a completion of the request at the time it
	returns. I will also assume that another thread request
	can not be started until the first returns. Basicly
	prevent a context switch until it returns or ..

	Thus, if thread 1's open is done 2nd and then the fcntl is 
	  processed first any CORRECT write lock request over the 
	  offset range specified will fail. Correct?

	However,,,
	Thread 2's fcntl specifies fd2 as the first arg, which I do 
	not see specified as opened. Thus, I would expect that call
	to fail with a EBADF return. The fd has not been opened.
	Thus, the fcntl will never succeed for thread 2. Right????

	However, in the past fcntl calls are advisory, so any read/write
	op that was later performed would succeed without the care of
	the lock, only the open 2nd args would then generate restrictions.

	As implicitly stated, file handles are not keep between reboots,
	so i would expect that implmentations should use file handles to
	generate any "stale file handle" errors.

	So, the only questions is which open was done 2nd and did either
	of the fcntl's succeed? However, if the fcntl was an advisory call
	the fcntl call would make no difference. The issue is whether which
	 2nd arg to the open (RDONLY/WRONLY) is in effect when the final
	read/writes are attempted. Right?

	Mitchell Erblich
	-------------------