On Thu, Dec 22, 2016 at 12:57:10PM +0100, J. Hannken-Illjes wrote:
> > On 11 Dec 2016, at 21:01, David Holland wrote:
> >
> > On a low-memory machine Nick ran into the following deadlock:
> >
> > (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> > no memory in buffe
On Sun, Dec 11, 2016 at 08:39:06PM +, Michael van Elst wrote:
> dholland-t...@netbsd.org (David Holland) writes:
>
> >On a low-memory machine Nick ran into the following deadlock:
>
> > (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> > no memory in buffer pool -> wai
> On 11 Dec 2016, at 21:01, David Holland wrote:
>
> On a low-memory machine Nick ran into the following deadlock:
>
> (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> no memory in buffer pool -> wait for syncer
This prediction seems wrong. It is not the syncers job t
> > Some time ago I unconditionally removed LK_NOWAIT from vn_lock().
> > Suppose we need this patch:
> >
> > RCS file: /cvsroot/src/sys/ufs/ffs/ffs_vfsops.c,v
> > retrieving revision 1.341
> > diff -p -u -2 -r1.341 ffs_vfsops.c
> > --- ffs_vfsops.c20 Oct 2016 19:31:32 - 1.341
> >
On 12/12/16 09:55, J. Hannken-Illjes wrote:
On 11 Dec 2016, at 22:33, Nick Hudson wrote:
On 12/11/16 21:05, J. Hannken-Illjes wrote:
On 11 Dec 2016, at 21:01, David Holland wrote:
On a low-memory machine Nick ran into the following deadlock:
(a) rename -> vrele on child -> inactive -> tru
On Mon, Dec 12, 2016 at 10:55:27AM +0100, J. Hannken-Illjes wrote:
> Some time ago I unconditionally removed LK_NOWAIT from vn_lock().
> Suppose we need this patch:
You realize that isn't sufficient, right? :-) Although it should stop
the deadlock. (see my other mail)
--
David A. Holland
dholl
> On 11 Dec 2016, at 22:33, Nick Hudson wrote:
>
> On 12/11/16 21:05, J. Hannken-Illjes wrote:
>>> On 11 Dec 2016, at 21:01, David Holland wrote:
>>>
>>> On a low-memory machine Nick ran into the following deadlock:
>>>
>>> (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
>>
On Sun, Dec 11, 2016 at 08:39:06PM +, Michael van Elst wrote:
> >On a low-memory machine Nick ran into the following deadlock:
>
> > (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> > no memory in buffer pool -> wait for syncer
> > (b) syncer waiting for locked p
On 12/11/16 21:05, J. Hannken-Illjes wrote:
On 11 Dec 2016, at 21:01, David Holland wrote:
On a low-memory machine Nick ran into the following deadlock:
(a) rename -> vrele on child -> inactive -> truncate -> getblk ->
no memory in buffer pool -> wait for syncer
(b) syncer waiting fo
> On 11 Dec 2016, at 21:01, David Holland wrote:
>
> On a low-memory machine Nick ran into the following deadlock:
>
> (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> no memory in buffer pool -> wait for syncer
> (b) syncer waiting for locked parent vnode from the ren
dholland-t...@netbsd.org (David Holland) writes:
>On a low-memory machine Nick ran into the following deadlock:
> (a) rename -> vrele on child -> inactive -> truncate -> getblk ->
> no memory in buffer pool -> wait for syncer
> (b) syncer waiting for locked parent vnode from the rename
>D
On a low-memory machine Nick ran into the following deadlock:
(a) rename -> vrele on child -> inactive -> truncate -> getblk ->
no memory in buffer pool -> wait for syncer
(b) syncer waiting for locked parent vnode from the rename
This makes it in general unsafe to vrele while holding a
12 matches
Mail list logo
