]>
Commit | Line | Data |
---|---|---|
1da177e4 LT |
1 | Do the ax25_list_lock, ax25_dev_lock, linkfail_lockreally, ax25_frag_lock and |
2 | listen_lock have to be bh-safe? | |
3 | ||
4 | Do the netrom and rose locks have to be bh-safe? | |
5 | ||
6 | A device might be deleted after lookup in the SIOCADDRT ioctl but before it's | |
7 | being used. | |
8 | ||
9 | Routes to a device being taken down might be deleted by ax25_rt_device_down | |
10 | but added by somebody else before the device has been deleted fully. | |
11 | ||
12 | Massive amounts of lock_kernel / unlock_kernel are just a temporary solution to | |
13 | get around the removal of SOCKOPS_WRAP. A serious locking strategy has to be | |
14 | implemented. | |
15 | ||
16 | The ax25_rt_find_route synopsys is pervert but I somehow had to deal with | |
17 | the race caused by the static variable in it's previous implementation. | |
18 | ||
19 | Implement proper socket locking in netrom and rose. | |
20 | ||
21 | Check socket locking when ax25_rcv is sending to raw sockets. In particular | |
22 | ax25_send_to_raw() seems fishy. Heck - ax25_rcv is fishy. | |
23 | ||
24 | Handle XID and TEST frames properly. |