head     1.1;
branch   1.1.1;
access   ;
symbols  start:1.1.1.1 project:1.1.1;
locks    ; strict;
comment  @# @;


1.1
date     2006.08.10.10.42.49;  author kaurikim;  state Exp;
branches 1.1.1.1;
next     ;

1.1.1.1
date     2006.08.10.10.42.49;  author kaurikim;  state Exp;
branches ;
next     ;


desc
@@



1.1
log
@Initial revision
@
text
@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.
@


1.1.1.1
log
@analysis linux network system
@
text
@@
