LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Aaron Wiebe <epiphani@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Fwd: uninterruptable fcntl calls
Date: Fri, 02 Feb 2007 11:45:57 -0800	[thread overview]
Message-ID: <1170445557.5890.35.camel@lade.trondhjem.org> (raw)
In-Reply-To: <e7ca40f70702021128n7325576et36d52adab6280de3@mail.gmail.com>

On Fri, 2007-02-02 at 14:28 -0500, Aaron Wiebe wrote:
> Greetings,
> 
> I've run into a situation where fcntl F_SETLKW calls lock up nearly
> completely.  I've tried several approaches to handle this case, and
> have yet to come up with some method of handling this.  I've never
> really ventured outside userspace, so I'm turning to this list to try
> and get a handle on this.
> 
> Over NFSv3 udp, this situation takes place VERY rarely, however with
> the volume I do, its creating a problem.
> 
> In short, I am attempting to read or write lock, and the call hangs to
> the point where a sigkill is not captured - no signal is.  I've tried
> alarming out and I've tried switching the socket to nonblocking -
> nothing I can think of prevents or even allows me to handle the case.
> I understand NFS locking can be rather sketchy at times - but all I
> need is the ability to handle the case.
> 
> I can force the process to die by sending a sigkill, then stracing.
> The strace reports the process as sigstop, then processes the kill
> signal.
> 
> All I need here is a method of capturing this case.  I can "repair"
> the stuck lock by regenerating the file, but I can't capture the case
> in order to handle this in code.
> 
> Any help would be useful - I am currently running 2.6.15.6 compiled
> with the NFS patches from linux-nfs.org, but this case was happening
> before applying those patches.  I'd be happy to provide any more
> information nessecary.  I've been struggling with this one for a few
> months now.
> 
> Thanks,
> -Aaron
> 
> 
> Straces:
> 
> rt_sigaction(SIGALRM, {0xb7f56640, [ALRM], 0}, {SIG_DFL}, 8) = 0
> alarm(120)                              = 0
> fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}
> [hangs]
> 
> Or:
> 
> fcntl64(3, F_GETFL)                     = 0x8002 (flags O_RDWR|O_LARGEFILE)
> fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK|O_LARGEFILE) = 0
> fcntl64(3, F_SETLKW, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}
> 
> 
> 
> Code used for locking:
> 
> static int db_lock(int fd, int type)
> {
>     struct flock fl;
>     struct timespec *tv = (struct timespec *) malloc(sizeof(struct timespec));
>     int ret, c = 0;
> 
>     if(!(fd > 0))
>         return -1;
> 
> #ifdef SIGALRM_HACK
>     /* after two minutes, wig out */
>     sigalrm_set();
>     alarm(120);
> #endif
> 
>     fl.l_whence = SEEK_SET;
>     fl.l_start = 0;
>     fl.l_len = 0;
>     fl.l_type = type;
> 
> #ifdef NONBLOCKING_HACK
>     set_nonblocking(fd);
> #endif
> 
>     while((ret = fcntl(fd, F_SETLKW, &fl)) < 0)
>     {
>         c++;
>         if(c > 600)
>         {
>             /* we've been waiting for 60 seconds... */
>             my_error("stuck on fcntl request, aborting");
>             return -1;
>         }
>         tv->tv_nsec = 100;   /* 10th of a second wait */
>         tv->tv_sec = 0;
>         nanosleep(tv, NULL);
>     }
>     free(tv);
> #ifdef SIGALRM_HACK
>     sigalrm_unset();
> #endif
> #ifdef NONBLOCKING_HACK
>     unset_nonblocking(fd);
> #endif
>     return ret;
> }

Should have been fixed in mainline in 2.6.16 by the following patch

http://linux-nfs.org/cgi-bin/gitweb.cgi?p=nfs-2.6.git;a=commitdiff;h=a9a801787a761616589a6526d7a29c13f4deb3d8;hp=03f28e3a2059fc466761d872122f30acb7be61ae

Cheers,
  Trond


      reply	other threads:[~2007-02-02 19:46 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-02 18:54 Aaron Wiebe
2007-02-02 19:28 ` Fwd: " Aaron Wiebe
2007-02-02 19:45   ` Trond Myklebust [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1170445557.5890.35.camel@lade.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=epiphani@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: Fwd: uninterruptable fcntl calls' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).