kern/92552: A serious bug in most network drivers from R5 to R6

[Liang Yi]

>Number:         92552
>Category:       kern
>Synopsis:       A serious bug in most network drivers from R5 to R6
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 30 15:50:02 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Liang Yi
>Release:        Release 5.x to Release 6.x
>Organization:
LingZhou Network Inc
>Environment:
FreeBSD XXXXX 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Fri Jan 27 00:32:43 UTC 2006   i386
>Description:
>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!


>How-To-Repeat:
Run sniffer in a heavy load env, shutdown the interface or reboot the machine, system will be crashed at most time.

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

>Release-Note:
>Audit-Trail:
>Unformatted: