Subject: Re: PR/34293 CVS commit: src/sys/dev
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Michael van Elst <mlelstv@serpens.de>
List: netbsd-bugs
Date: 09/03/2006 20:35:02
The following reply was made to PR kern/34293; it has been noted by GNATS.
From: Michael van Elst <mlelstv@serpens.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: PR/34293 CVS commit: src/sys/dev
Date: Sun, 3 Sep 2006 22:32:54 +0200
On Sun, Sep 03, 2006 at 08:00:10PM +0000, Manuel Bouyer wrote:
> it's not correct to tsleep() in a strategy routine, which may be called from
> interrupt context.
vndstrategy isn't called from interrupt context. But if that is
a problem, the feedback loop can be put into both vndread()/vndwrite().
> Unfortunably this reopens PR/10731, PR/12189, PR/20296, PR/34293
> As for what the correct fix it, this needs to be analysed deeper.
Then I suggest you do that before you break vnd.
> I suspect
> throttling the caller in vnd only hides the problem;
No, it prevents the problem. The writer needs to be throttled to
not overwhelm the consumer because in this case it just eats up
all memory. That necessary feedback loop is created by the patch.
> the same caller writing
> to some other device could exaust all buffers as well.
This is a general problem with every device but so far not seen as
a problem. If there is memory to buffer the requests, the current
buffering policy is to allow all buffers to be used. This is more or
less harmless as normal device drivers will only consume and free
buffers on the queue.
However, vnd is special in that it requires further buffers to be
allocated to consume and free buffers on the queue. There is also
no need to double buffer writes to vnd this way, once in the
device queue and once in the underlying filesystem. That strategy
is broken and this is also fixed by the patch that limits the
double-buffer to whatever the device thread is prepared to consume.
> If this driver doesn't
> need to allocate buffer this won't cause a deadlock, but it's bad for
> performances on systems with e.g. multiple drives.
Preventing vnd from consuming all buffers cannot be bad for
performances on systems with multiple drives.
> Also, others stacked
> block device drivers may also have this issue.
That is a possiblity. Find those drivers, resolve the issue and
provide a proper solution for all cases.
--
Michael van Elst
Internet: mlelstv@serpens.de
"A potential Snark may lurk in every tree."