Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Mon, 13 Sep 1999 16:36:27 MET-1 | Subject | per-filesystem fcntl lock() implementation |
| |
Hi Alexander, hi others, it looks like that for some time it is possible for filesystem to implement its own record locking features available through fcntl (lockf) interface. And because of codefreeze starts, it is probably right time to start porting ncpfs ioctl-specific locking to this scheme :-) Unfortunately, I have problem that Netware locking semantic does not match POSIX one so closely - for example, it is not possible to do lock(start=0,len=1000); unlock(start=400,len=200); and it is not possible to upgrade shared lock to exclusive (you must release lock) and so on... It could be implemented if I remove this strange code from fs/locks.c:fcntl_setlk(): == if (filp->f_op->lock != NULL) { error = filp->f_op->lock(filp, cmd, &file_lock); if (error < 0) goto out_putf; } error = posix_lock_file(filp, &file_lock, cmd == F_SETLKW); out_putf: fput(filp); out: return error; == This code does not make any sense to me :-( For example, (over NFS) call to ->lock() locks file on server, but what if posix_lock_file() fails? Who remove lock from server then? Or must filesystem's lock() function guarantee that posix_lock_file() succeeds? And if so, is not it better to leave call to posix_lock_file() on filesystem itself? (and how can filesystem's function guarantee this if posix_lock_file can sleep?!) Thanks, Petr Vandrovec vandrove@vc.cvut.cz
P.S.: Changing code above to
if (filp->f_op->lock) error = filp->f_op->lock(filp, cmd, &file_lock); else error = posix_lock_file(filp, &file_lock, cmd == F_SETLKW); fput(filp); return error;
or
error = posix_lock_file(filp, &file_lock, cmd == F_SETLKW); if (!error && filp->f_op->lock) { error = filp->f_op->lock(filp, cmd, &file_lock); if (error) { file_lock.fl_type = F_UNLCK; posix_lock_file(filp, &file_lock, cmd == F_SETLKW); } } fput(filp); return error;
makes much more sense to me... I'm probably missing something. What?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |