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."