code in GEOM thread could not use vnode API (Was: alq_open_flags() panics in _mtx_lock_flags())

[Lev Serebryakov]

Hello, Kostik.
You wrote 3 октября 2011 г., 20:01:45:

> Look at the body of e.g. g_io_schedule_down(), the
>                 THREAD_NO_SLEEPING();
> call right before the call to geom start method.

> Basically, you cannot use any kernel subsystem in the context of
> the up/down threads that could sleep. This includes VFS, VM and
> everything that is layered on top of it.
  VM too? Allocating of new element to put into working queue is
 prohibited? It is what (almost) every GEOM class does.
  Even geom_nop() allocate new struct bio from g_down thread.

> The decision is deliberate. Up and down shall only schedule the processing,
> or perform the fast processing.
  Schedule is impossible without memory allocations in most
cases...

> BTW, it must be obvious that trying to perform any VFS operation from geom
> up or down causes deadlock.
  Could cause. alq uses its own thread for "real" VFS operations, and
 open() was called from g_event, not g_up/g_down... BTW, nothing stops
 me from calling msleep() in g_event thread (to wait when working
 thread stops on exit, for example). And, again, it is what many
 "base" geom classes uses, even if they use working thread concept.

   And panic due to NULL pointer derefernce is not best way to
 indicate, that logic is broken (but it is not broken in this case, as
 it is impossible to create consumer for occupied geom with file
 system) :)

-- 
// Black Lion AKA Lev Serebryakov <lev at serebryakov.spb.ru>