|  | Do the ax25_list_lock, ax25_dev_lock, linkfail_lockreally, ax25_frag_lock and | 
|  | listen_lock have to be bh-safe? | 
|  |  | 
|  | Do the netrom and rose locks have to be bh-safe? | 
|  |  | 
|  | A device might be deleted after lookup in the SIOCADDRT ioctl but before it's | 
|  | being used. | 
|  |  | 
|  | Routes to a device being taken down might be deleted by ax25_rt_device_down | 
|  | but added by somebody else before the device has been deleted fully. | 
|  |  | 
|  | Massive amounts of lock_kernel / unlock_kernel are just a temporary solution to | 
|  | get around the removal of SOCKOPS_WRAP.  A serious locking strategy has to be | 
|  | implemented. | 
|  |  | 
|  | The ax25_rt_find_route synopsys is pervert but I somehow had to deal with | 
|  | the race caused by the static variable in it's previous implementation. | 
|  |  | 
|  | Implement proper socket locking in netrom and rose. | 
|  |  | 
|  | Check socket locking when ax25_rcv is sending to raw sockets.  In particular | 
|  | ax25_send_to_raw() seems fishy.  Heck - ax25_rcv is fishy. | 
|  |  | 
|  | Handle XID and TEST frames properly. |