On Wed, Feb 3, 2016 at 5:13 PM, Nick Hudson <sk...@netbsd.org> wrote: > On 02/03/16 04:44, Ryota Ozaki wrote: >> >> On Tue, Feb 2, 2016 at 8:51 AM, Taylor R Campbell >> <campbell+netbsd-tech-k...@mumble.net> wrote: > > [snip] >>> >>> In this case, it's not a priori clear to me why the caller must be in >>> hardintr context. Perhaps you want to discourage callers from using >>> this if they're already in softint context. But even if the caller is >>> in softint context, maybe it's higher-priority softint context than >>> softnet (e.g., I think skrll@ plans to make all USB softints run at >>> softserial instead of softnet), and maybe you don't want ifp->if_input >>> to run at >softnet priority. > > > I'm still debating what to do here, but it's clear to me that all USB > callbacks running at splsoftnet > has issues - see > > http://gnats.netbsd.org/50491 > > and somewhat related > > http://gnats.netbsd.org/49065
Hmm, it looks that the issue isn't due to splsofnet but rather due to bad use of softnet_lock (for example it is held longer than it should be, it can be held on socket operations that even don't run in softnet, etc.). Once Mp-safe work is done, softnet_lock will disappear (or at least we stop holding it on calling a driver), and the issue will be resolved. BTW can we replace softnet_lock with KERNEL_LOCK until getting MP-safe work done? That may be a backdown though, it may be less problematic. > >> Oh, that's a case I didn't take into account. Running if->if_input >> at >softnet priority would break the assumption that we rely on. > > > What assumption are you making? If networking codes run in softint, they're in softnet (or lower) ipl. So we can use splsoftnet for mutual exclusion. > >> We may be able to change the assert to >> KASSERT(cpu_intr_p() || (cpu_softintr_p() && level != SOFTINT_NET)) >> though, I think we don't need to be paranoid for the case. >> (And I don't know how to get level. Is there API?). > > > There isn't an API afaik. I see. Thanks. ozaki-r
