lkml.org 
[lkml]   [1999]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
Subjectper-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/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.177 / U:0.360 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site