lkml.org 
[lkml]   [2000]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Imminent death of /proc/locks predicted; film at 11
On Sun, Oct 01, 2000 at 12:55:30AM +0100, Alan Cox wrote:
> > When debugging this kind of problem, you're not interested in the
> > non-conflicting locks, only the ones which are blocked waiting for
> > another lock, right?
>
> All I care about is what locks are currently in force in the system. So for
> example I can do something like
>
> showlocks /var/spool/mail/alan

there's already a F_GETLK fcntl. however, it's not entirely suitable
for use as a debugging tool since it dosen't report the blocked locks
and it might not find all the locks in force (or if it does,it could
take 2^64 calls to fcntl to find them all).

given an inode, it's trivial to find the locks in force on it (and the
locks blocked on the locks in force upon it). the difficulty lies in
reporting this data to userspace.

if fcntl took a 4th argument specifying the length of the buffer, i'd
recommend a F_GETLKS fcntl. a horrid work around for this would be that
the first 4 bytes of the buffer pointed to by the third argument of the
fcntl is the length of the buffer.

i'd appreciate anyone coming up with a nicer interface. How do other
unices provide this information? grovelling through /proc/kcore?

--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.056 / U:3.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site