Date: Sat, 21 Oct 2006 00:56:34 -0600 From: John E Hein <jhein@timing.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-stable@freebsd.org, David Xu <davidxu@freebsd.org>, jhb@freebsd.org Subject: Re: locked vnode / nfs... requires kill -9 in ddb Message-ID: <17721.50338.220767.201120@gromit.timing.com> In-Reply-To: <20061021035749.GY55428@deviant.kiev.zoral.com.ua> References: <17718.20457.799395.602805@gromit.timing.com> <20061019100442.GN55428@deviant.kiev.zoral.com.ua> <200610210825.00228.davidxu@freebsd.org> <20061021035749.GY55428@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote at 06:57 +0300 on Oct 21, 2006: > On Sat, Oct 21, 2006 at 08:25:00AM +0800, David Xu wrote: > > On Thursday 19 October 2006 18:04, Kostik Belousov wrote: > > > > > > > > The nfs_reply is sleeping with the PCATCH set. The question is why SIGTSTP > > > does not cause msleep to return with EINTR. > > > > I have not been tracking the thread. but if the thread is sleeping with > > PCATCH, the SIGTSTP should cause the process to stop unless the signal > > is masked by sigprocmask or the signal has an action handler been set, > > this is a correct behavior. > > > David, > as I understand the report, the following happens. The nfs mount point with > intr option issued the request and waits for the reply. Some vnode locks are > held while waiting. Code needs to catch the signals to abort the operation > on user request. It uses msleep with PCATCH. The thread in question has > td_locks > 0. > > The SIGTSTP is delivered, and thread is stopped, while holding vnode lock. > How this situation shall be handled ? Namely, how to sleep while having the > ability to safely clean up on attempt of stopping ? Masking SIGTSTP is not > the option, due to SIGSTOP having the same results and not being blockable. > > [Would it be right to stop the threads only on returning from kernel to user > mode ?] David, here's the original report. http://lists.freebsd.org/pipermail/freebsd-stable/2006-October/029755.html Indeed, as Kostik surmised, the mount point is mounted intr. I did not notice this problem while running with releng_6 from late June for 3 months. Could it be this problem was introduced between then and now? This also just happened today on a system I just updated from 5.3 to 5.5-p8.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17721.50338.220767.201120>