Re: Add a dead mount
Date: Sun, 23 Feb 2014 13:57:52 +0100 From: "J. Hannken-Illjes" Currently dead vnodes still reside on the vnodelist of the file system they have been removed from. To me it looks much better to create a "dead mount" that takes dead vnodes until they get freed. Diff available at http://www.netbsd.org/~hannken/dead-mount.diff Comments or objections anyone? Sounds plausible to me. vclean doesn't seem like quite the right place to be handling dead_mount->mnt_refcnt, but I don't see a better place to do it.
Re: Vnode API change: VOP_LOCK
Date: Fri, 21 Feb 2014 12:35:40 +0100 From: "J. Hannken-Illjes" Diff available at http://www.netbsd.org/~hannken/vnode-pass3-1.diff Comments or objections anyone? This seems needlessly complicated to me. Outside of the vfs lifecycle code, why would you ever want to lock a dead vnode? It seems to me it would be better to just bite the bullet, kill LK_RETRY, and make everyone handle possible vn_lock failure (or VOP_LOCK, since vn_lock would cease to be necessary). The LK_INTERLOCK flag doesn't seem right. It looks like the only place you use it is a place where you recently removed some code to drop the interlock before taking the vnode lock. We ought to be removing superfluous extra states, not adding more lock order workarounds, especially ones that involve asking more of the particular file systems by passing them new flags. A little more broadly, do you have a plan for what the vnode life cycle should look like? We ought to have a well-defined set of states that a vnode can be in (something like embryonic, active, cached, dead) and a clear set of transitions with invariants and lock order and a clear protocol for file systems to implement. Without that, I'm sceptical of churn in vrelel, vclean, &c.
Re: ci_mtx_count issue on NetBSD/Milkymist
On 02/24/2014 06:38 PM, Mindaugas Rasiukevicius wrote: Yann Sionneau wrote: I've tried to understand how ci_mtx_count is supposed to be managed my MD code, so far I failed to understand. It seems some arch use spin_mutex and inc/dec ci_mtx_count upon spin_mutex_enter/exit. Some other archs do it in softint handling. Could someone give my some clue (or documentation) about the intended behaviour of curcpu()->ci_mtx_count please? It is a reference count on the IPL raised by spin-mutexes. The IPL should be lowered (straight to IPL_NONE) on a last reference. Notice that this is a negative counter - mutex_spin_enter() decrements, while mutex_spin_exit() incremenets. Not the other way round. Hi Mindaugas, if I have __HAVE_SIMPLE_MUTEXES set to 1, and __HAVE_MUTEX_STUBS is undefined, then I should not care about ci_mtx_count in MD code at all, right? Thanks :) Regards, -- Yann Sionneau
Re: ci_mtx_count issue on NetBSD/Milkymist
Yann Sionneau wrote: > I've tried to understand how ci_mtx_count is supposed to be managed my > MD code, so far I failed to understand. > It seems some arch use spin_mutex and inc/dec ci_mtx_count upon > spin_mutex_enter/exit. > Some other archs do it in softint handling. > > Could someone give my some clue (or documentation) about the intended > behaviour of curcpu()->ci_mtx_count please? It is a reference count on the IPL raised by spin-mutexes. The IPL should be lowered (straight to IPL_NONE) on a last reference. Notice that this is a negative counter - mutex_spin_enter() decrements, while mutex_spin_exit() incremenets. Not the other way round. -- Mindaugas
ci_mtx_count issue on NetBSD/Milkymist
Hello, I get this while working on my port of NetBSD to Milkymist (lm32) SoC: panic: kernel diagnostic assertion "ci->ci_mtx_count == -1" failed: file "/home/ysionneau/perso/NetBSD/sys/kern/kern_synch.c", line 676 mi_switch: cpu0: ci_mtx_count (0) != -1 (block with spin-mutex held) I put a watchpoint on lwp0->l_cpu->ci_mtx_count , in my port it is never modified and stays at value 0. I've tried to understand how ci_mtx_count is supposed to be managed my MD code, so far I failed to understand. It seems some arch use spin_mutex and inc/dec ci_mtx_count upon spin_mutex_enter/exit. Some other archs do it in softint handling. Could someone give my some clue (or documentation) about the intended behaviour of curcpu()->ci_mtx_count please? Thank you :) Best regards, -- Yann Sionneau
