Bug 92552
| Summary: | A serious bug in most network drivers from 5.X to 6.X [regression] | ||
|---|---|---|---|
| Product: | Base System | Reporter: | LiangYi <liangyi571> |
| Component: | kern | Assignee: | Pyun YongHyeon <yongari> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to freebsd-net for evaluation. Hi, Sorry it's taken such a long time to get around to looking at this problem report. I'm not very familiar with the network code but from looking at if_em.c it appears that a dual locking implementation was added in rev 1.65.2.28 (FreeBSD 6.3) so that the core lock is held by both the ioctl and interrupt handlers and so this problems should no longer occur. However, the _CORE_LOCK macros are only used in if_em so unless the problem has been fixed in the other network drivers this problem will still exist. Do you remember which other network drivers are affected? Thanks, Bruce State Changed From-To: open->feedback Note that submitter has been asked for feedback. Responsible Changed From-To: freebsd-net->yongari Over to expert. State Changed From-To: feedback->closed Feedback timeout. This PR is quite old by now. |
From Release 5, adapter will be locked while interrupt received, except if_input was called. Look at these code in if_em.c EM_UNLOCK(adapter); (*ifp->if_input)(ifp, m); EM_LOCK(adapter); After if_input returned, adapter will be locked again. These code will be ok at most time. But if you shutdown the interface under heavy load, ioctl would be called by another thread while if_input was called by interrupt thread, which will crash the system. The work flow seems like this: "interrupt thread": lock adapter -> receive packet -> unlock adapter -> if_input -> (task switch) | V "ioctl thread": lock adapter -> shutdown interface -> release all resource for this adapter -> unlock adapter -> (task switch) | V "interrupt thread": return from if_input -> lock adapter again -> resource not avaliable -> SYSTEM crash! Fix: Add a patch to the drivers which works like above. Use another lock or some special flags to prevent other thread to call ioctl while receiving packet. How-To-Repeat: Run sniffer in a heavy load env, shutdown the interface or reboot the machine, system will be crashed at most time.