summaryrefslogtreecommitdiff
path: root/net/ax25/TODO
blob: 69fb4e368d922fe57ab543983416d2532fca1cad (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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.

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.
nrpc/auth_gss/gss_krb5_crypto.c?id=bd4ce941c8d5b862b2f83364be5dbe8fc8ab48f8'>gss_krb5_crypto.c27467logplain -rw-r--r--gss_krb5_keys.c9076logplain -rw-r--r--gss_krb5_mech.c20724logplain -rw-r--r--gss_krb5_seal.c6772logplain -rw-r--r--gss_krb5_seqnum.c4645logplain -rw-r--r--gss_krb5_unseal.c6813logplain -rw-r--r--gss_krb5_wrap.c18005logplain -rw-r--r--gss_mech_switch.c12603logplain -rw-r--r--gss_rpc_upcall.c9707logplain