Re: Bug#43529: debian-policy: mail locking in Debian is _not_ NFS safe
In article <cistron.Pine.LNX.3.96.990826101427.14545B-100000@Wakko.deltatee.com>,
Jason Gunthorpe <jgg@ualberta.ca> wrote:
>
>On Thu, 26 Aug 1999, Roland Rosenfeld wrote:
>
>> The solution for this problem is to use fcntl(), because Linux 2.2.*
>> flushes the cache of a file in the moment when it is locked using
>> fcntl().
>>
>> But only fcntl() locking is not enough, because Linux 2.0.* doesn't
>> support this over NFS and then we have no locking over NFS.
>
>And linux 2.2.x with a userland server also does not support fcntl
>locking, it generates an annoying kernel message and fails with ENOLCK.
As I said that's because you have to mount the partition with the
"nolock" option if the NFS server doesn't support server-side locking.
But the problem was that:
a) it's hard for liblockfile to use fcntl() locking since it doesn't
open the file you want to lock, and the current API doesn't allow
you to pass a filehandle. Opening the file anyway and keeping it
in some internal state/list would be possible but ugly
b) The 2.2.x kernels have a bug that prevents fcntl() from revalidating
the cache if you mount wth "nolock", bugger since that is the entire
point of calling fcntl()
Roland posted a patch from Olaf Kirch that will fix this. I just sent
that patch to the linux-kernel mailing list and Alan Cox for possible
inclusion into 2.2.13 (I'll try hard to convince Alan to put it in).
Now, for point a). I don't think it is mandatory that we actually
_use_ fcntl locking - the only thing we want to make sure of is that
the cache gets flushed, right? So that after the lock, the attributes
of the locked file are up-to-date.
I read the kernel source code and found out that the cache gets invalidated
*anyway* regardless of the fact that the lock succeeds or not. So, it
would be enough to simply open the file-to-be-locked (if it exists
already), do an fcntl(F_SETLK) on it, if that succeeds we immediately
unlock it, then we close the file. We didn't actually _use_ the lock,
but the cache got invalidated regardless.
This would let us keep the current policy, and current way to lock
the mailspool, but it would fix the problem.
Comments?
BTW, the original problem was with mutt, right? I don't think mutt
actually uses liblockfile - perhaps the mutt maintainer wants to
send this message upstream to the mutt developers for informational
purposes.
Mike.
--
... somehow I have a feeling the hurting hasn't even begun yet
-- Bill, "The Terrible Thunderlizards"
Reply to: