linux-toradex.git/net/rose, branch v2.6.28 Linux kernel for Apalis and Colibri modules rose: zero length frame filtering in af_rose.c 2008-11-25T08:56:20+00:00 Bernard Pidoux bernard.pidoux@upmc.fr 2008-11-24T11:49:40+00:00 244f46ae6e9e18f6fc0be7d1f49febde4762c34b Since changeset e79ad711a0108475c1b3a03815527e7237020b08 from mainline, >From David S. Miller, empty packet can be transmitted on connected socket for datagram protocols. However, this patch broke a high level application using ROSE network protocol with connected datagram. Bulletin Board Stations perform bulletins forwarding between BBS stations via ROSE network using a forward protocol. Now, if for some reason, a buffer in the application software happens to be empty at a specific moment, ROSE sends an empty packet via unfiltered packet socket. When received, this ROSE packet introduces perturbations of data exchange of BBS forwarding, for the application message forwarding protocol is waiting for something else. We agree that a more careful programming of the application protocol would avoid this situation and we are willing to debug it. But, as an empty frame is no use and does not have any meaning for ROSE protocol, we may consider filtering zero length data both when sending and receiving socket data. The proposed patch repaired BBS data exchange through ROSE network that were broken since 2.6.22.11 kernel. Signed-off-by: Bernard Pidoux <f6bvp@amsat.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Since changeset e79ad711a0108475c1b3a03815527e7237020b08 from  mainline,
>From David S. Miller,
empty packet can be transmitted on connected socket for datagram protocols.

However, this patch broke a high level application using ROSE network protocol with connected datagram.

Bulletin Board Stations perform bulletins forwarding between BBS stations via ROSE network using a forward protocol.
Now, if for some reason, a buffer in the application software happens to be empty at a specific moment,
ROSE sends an empty packet via unfiltered packet socket.
When received, this ROSE packet introduces perturbations of data exchange of BBS forwarding,
for the application message forwarding protocol is waiting for something else.
We agree that a more careful programming of the application protocol would avoid this situation and we are
willing to debug it.
But, as an empty frame is no use and does not have any meaning for ROSE protocol,
we may consider filtering zero length data both when sending and receiving socket data.

The proposed patch repaired BBS data exchange through ROSE network that were broken since 2.6.22.11 kernel.

Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
netdev: Handle ->addr_list_lock just like ->_xmit_lock for lockdep. 2008-07-22T21:16:42+00:00 David S. Miller davem@davemloft.net 2008-07-22T21:16:42+00:00 cf508b1211dbe576778ff445ea1b4b0bcfa5c4ea The new address list lock needs to handle the same device layering issues that the _xmit_lock one does. This integrates work done by Patrick McHardy. Signed-off-by: David S. Miller <davem@davemloft.net> 
The new address list lock needs to handle the same device layering
issues that the _xmit_lock one does.

This integrates work done by Patrick McHardy.

Signed-off-by: David S. Miller <davem@davemloft.net>
netns: Use net_eq() to compare net-namespaces for optimization. 2008-07-20T05:34:43+00:00 YOSHIFUJI Hideaki yoshfuji@linux-ipv6.org 2008-07-20T05:34:43+00:00 721499e8931c5732202481ae24f2dfbf9910f129 Without CONFIG_NET_NS, namespace is always &init_net. Compiler will be able to omit namespace comparisons with this patch. Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
Without CONFIG_NET_NS, namespace is always &init_net.
Compiler will be able to omit namespace comparisons with this patch.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
netdev: Allocate multiple queues for TX. 2008-07-18T02:21:00+00:00 David S. Miller davem@davemloft.net 2008-07-17T07:34:19+00:00 e8a0464cc950972824e2e128028ae3db666ec1ed alloc_netdev_mq() now allocates an array of netdev_queue structures for TX, based upon the queue_count argument. Furthermore, all accesses to the TX queues are now vectored through the netdev_get_tx_queue() and netdev_for_each_tx_queue() interfaces. This makes it easy to grep the tree for all things that want to get to a TX queue of a net device. Problem spots which are not really multiqueue aware yet, and only work with one queue, can easily be spotted by grepping for all netdev_get_tx_queue() calls that pass in a zero index. Signed-off-by: David S. Miller <davem@davemloft.net> 
alloc_netdev_mq() now allocates an array of netdev_queue
structures for TX, based upon the queue_count argument.

Furthermore, all accesses to the TX queues are now vectored
through the netdev_get_tx_queue() and netdev_for_each_tx_queue()
interfaces.  This makes it easy to grep the tree for all
things that want to get to a TX queue of a net device.

Problem spots which are not really multiqueue aware yet, and
only work with one queue, can easily be spotted by grepping
for all netdev_get_tx_queue() calls that pass in a zero index.

Signed-off-by: David S. Miller <davem@davemloft.net>
netdev: Move _xmit_lock and xmit_lock_owner into netdev_queue. 2008-07-09T06:13:53+00:00 David S. Miller davem@davemloft.net 2008-07-09T06:13:53+00:00 c773e847ea8f6812804e40f52399c6921a00eab1 Accesses are mostly structured such that when there are multiple TX queues the code transformations will be a little bit simpler. Signed-off-by: David S. Miller <davem@davemloft.net> 
Accesses are mostly structured such that when there are multiple TX
queues the code transformations will be a little bit simpler.

Signed-off-by: David S. Miller <davem@davemloft.net>
rose: improving AX25 routing frames via ROSE network 2008-06-18T00:08:32+00:00 Bernard Pidoux f6bvp@amsat.org 2008-06-18T00:08:32+00:00 fe2c802ab62aa63d276deafa905875f3455f2621 ROSE network is organized through nodes connected via hamradio or Internet. AX25 packet radio frames sent to a remote ROSE address destination are routed through these nodes. Without the present patch, automatic routing mechanism did not work optimally due to an improper parameter checking. rose_get_neigh() function is called either by rose_connect() or by rose_route_frame(). In the case of a call from rose_connect(), f0 timer is checked to find if a connection is already pending. In that case it returns the address of the neighbour, or returns a NULL otherwise. When called by rose_route_frame() the purpose was to route a packet AX25 frame through an adjacent node given a destination rose address. However, in that case, t0 timer checked does not indicate if the adjacent node is actually connected even if the timer is not null. Thus, for each frame sent, the function often tried to start a new connexion even if the adjacent node was already connected. The patch adds a "new" parameter that is true when the function is called by rose route_frame(). This instructs rose_get_neigh() to check node parameter "restarted". If restarted is true it means that the route to the destination address is opened via a neighbour node already connected. If "restarted" is false the function returns a NULL. In that case the calling function will initiate a new connection as before. This results in a fast routing of frames, from nodes to nodes, until destination is reached, as originaly specified by ROSE protocole. Signed-off-by: Bernard Pidoux <f6bvp@amsat.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
ROSE network is organized through nodes connected via hamradio or Internet.
AX25 packet radio frames sent to a remote ROSE address destination are routed
through these nodes.

Without the present patch, automatic routing mechanism did not work optimally
due to an improper parameter checking.

rose_get_neigh() function is called either by rose_connect() or by
rose_route_frame().

In the case of a call from rose_connect(), f0 timer is checked to find if a connection
is already pending. In that case it returns the address of the neighbour, or returns a NULL otherwise.

When called by rose_route_frame() the purpose was to route a packet AX25 frame
through an adjacent node given a destination rose address.
However, in that case, t0 timer checked does not indicate if the adjacent node
is actually connected even if the timer is not null. Thus, for each frame sent, the
function often tried to start a new connexion even if the adjacent node was already connected.

The patch adds a "new" parameter that is true when the function is called by
rose route_frame().
This instructs rose_get_neigh() to check node parameter "restarted". 
If restarted is true it means that the route to the destination address is opened via a neighbour
node already connected.
If "restarted" is false the function returns a NULL.
In that case the calling function will initiate a new connection as before.

This results in a fast routing of frames, from nodes to nodes, until
destination is reached, as originaly specified by ROSE protocole.

Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
rose: Use sock_graft() and remove bogus sk_socket and sk_sleep init. 2008-06-17T09:39:21+00:00 David S. Miller davem@davemloft.net 2008-06-17T09:39:21+00:00 44ccff1f539c8c5bbfc1eacd41cb9ef65022a4ca This is the rose variant of changeset 9375cb8a1232d2a15fe34bec4d3474872e02faec ("ax25: Use sock_graft() and remove bogus sk_socket and sk_sleep init.") Signed-off-by: David S. Miller <davem@davemloft.net> 
This is the rose variant of changeset
9375cb8a1232d2a15fe34bec4d3474872e02faec
("ax25: Use sock_graft() and remove bogus sk_socket and sk_sleep init.")

Signed-off-by: David S. Miller <davem@davemloft.net>
rose: Wrong list_lock argument in rose_node seqops 2008-05-03T00:03:22+00:00 Bernard Pidoux f6bvp@amsat.org 2008-05-03T00:03:22+00:00 f37f2c62a28e848e06399ea2f9be1e098212625c In rose_node_start() as well as in rose_node_stop() __acquires() and spin_lock_bh() were wrongly passing rose_neigh_list_lock instead of rose_node_list_lock arguments. Signed-off-by: Bernard Pidoux <f6bvp@amsat.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
In rose_node_start() as well as in rose_node_stop() __acquires() and
spin_lock_bh() were wrongly passing rose_neigh_list_lock instead of
rose_node_list_lock arguments.

Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
[ROSE]: Fix soft lockup wrt. rose_node_list_lock 2008-04-20T22:58:07+00:00 Bernard Pidoux f6bvp@amsat.org 2008-04-20T22:58:07+00:00 047f7617eba3653ff3bcfbe902986903fff2ed3b [ INFO: possible recursive locking detected ] 2.6.25 #3 --------------------------------------------- ax25ipd/3811 is trying to acquire lock: (rose_node_list_lock){-+..}, at: [<f8d31f1a>] rose_get_neigh+0x1a/0xa0 [rose] but task is already holding lock: (rose_node_list_lock){-+..}, at: [<f8d31fed>] rose_route_frame+0x4d/0x620 [rose] other info that might help us debug this: 6 locks held by ax25ipd/3811: #0: (&tty->atomic_write_lock){--..}, at: [<c0259a1c>] tty_write_lock+0x1c/0x50 #1: (rcu_read_lock){..--}, at: [<c02aea36>] net_rx_action+0x96/0x230 #2: (rcu_read_lock){..--}, at: [<c02ac5c0>] netif_receive_skb+0x100/0x2f0 #3: (rose_node_list_lock){-+..}, at: [<f8d31fed>] rose_route_frame+0x4d/0x620 [rose] #4: (rose_neigh_list_lock){-+..}, at: [<f8d31ff7>] rose_route_frame+0x57/0x620 [rose] #5: (rose_route_list_lock){-+..}, at: [<f8d32001>] rose_route_frame+0x61/0x620 [rose] stack backtrace: Pid: 3811, comm: ax25ipd Not tainted 2.6.25 #3 [<c0147e27>] print_deadlock_bug+0xc7/0xd0 [<c0147eca>] check_deadlock+0x9a/0xb0 [<c0149cd2>] validate_chain+0x1e2/0x310 [<c0149b95>] ? validate_chain+0xa5/0x310 [<c010a7d8>] ? native_sched_clock+0x88/0xc0 [<c0149fa1>] __lock_acquire+0x1a1/0x750 [<c014a5d1>] lock_acquire+0x81/0xa0 [<f8d31f1a>] ? rose_get_neigh+0x1a/0xa0 [rose] [<c03201a3>] _spin_lock_bh+0x33/0x60 [<f8d31f1a>] ? rose_get_neigh+0x1a/0xa0 [rose] [<f8d31f1a>] rose_get_neigh+0x1a/0xa0 [rose] [<f8d32404>] rose_route_frame+0x464/0x620 [rose] [<c031ffdd>] ? _read_unlock+0x1d/0x20 [<f8d31fa0>] ? rose_route_frame+0x0/0x620 [rose] [<f8d1c396>] ax25_rx_iframe+0x66/0x3b0 [ax25] [<f8d1f42f>] ? ax25_start_t3timer+0x1f/0x40 [ax25] [<f8d1e65b>] ax25_std_frame_in+0x7fb/0x890 [ax25] [<c0320005>] ? _spin_unlock_bh+0x25/0x30 [<f8d1bdf6>] ax25_kiss_rcv+0x2c6/0x800 [ax25] [<c02a4769>] ? sock_def_readable+0x59/0x80 [<c014a8a7>] ? __lock_release+0x47/0x70 [<c02a4769>] ? sock_def_readable+0x59/0x80 [<c031ffdd>] ? _read_unlock+0x1d/0x20 [<c02a4769>] ? sock_def_readable+0x59/0x80 [<c02a4d3a>] ? sock_queue_rcv_skb+0x13a/0x1d0 [<c02a4c45>] ? sock_queue_rcv_skb+0x45/0x1d0 [<f8d1bb30>] ? ax25_kiss_rcv+0x0/0x800 [ax25] [<c02ac715>] netif_receive_skb+0x255/0x2f0 [<c02ac5c0>] ? netif_receive_skb+0x100/0x2f0 [<c02af05c>] process_backlog+0x7c/0xf0 [<c02aeb0c>] net_rx_action+0x16c/0x230 [<c02aea36>] ? net_rx_action+0x96/0x230 [<c012bd53>] __do_softirq+0x93/0x120 [<f8d2a68a>] ? mkiss_receive_buf+0x33a/0x3f0 [mkiss] [<c012be37>] do_softirq+0x57/0x60 [<c012c265>] local_bh_enable_ip+0xa5/0xe0 [<c0320005>] _spin_unlock_bh+0x25/0x30 [<f8d2a68a>] mkiss_receive_buf+0x33a/0x3f0 [mkiss] [<c025ea37>] pty_write+0x47/0x60 [<c025c620>] write_chan+0x1b0/0x220 [<c0259a1c>] ? tty_write_lock+0x1c/0x50 [<c011fec0>] ? default_wake_function+0x0/0x10 [<c0259bea>] tty_write+0x12a/0x1c0 [<c025c470>] ? write_chan+0x0/0x220 [<c018bbc6>] vfs_write+0x96/0x130 [<c0259ac0>] ? tty_write+0x0/0x1c0 [<c018c24d>] sys_write+0x3d/0x70 [<c0104d1e>] sysenter_past_esp+0x5f/0xa5 ======================= BUG: soft lockup - CPU#0 stuck for 61s! [ax25ipd:3811] Pid: 3811, comm: ax25ipd Not tainted (2.6.25 #3) EIP: 0060:[<c010a9db>] EFLAGS: 00000246 CPU: 0 EIP is at native_read_tsc+0xb/0x20 EAX: b404aa2c EBX: b404a9c9 ECX: 017f1000 EDX: 0000076b ESI: 00000001 EDI: 00000000 EBP: ecc83afc ESP: ecc83afc DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: b7f5f000 CR3: 2cd8e000 CR4: 000006f0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 [<c0204937>] delay_tsc+0x17/0x30 [<c02048e9>] __delay+0x9/0x10 [<c02127f6>] __spin_lock_debug+0x76/0xf0 [<c0212618>] ? spin_bug+0x18/0x100 [<c0147923>] ? __lock_contended+0xa3/0x110 [<c0212998>] _raw_spin_lock+0x68/0x90 [<c03201bf>] _spin_lock_bh+0x4f/0x60 [<f8d31f1a>] ? rose_get_neigh+0x1a/0xa0 [rose] [<f8d31f1a>] rose_get_neigh+0x1a/0xa0 [rose] [<f8d32404>] rose_route_frame+0x464/0x620 [rose] [<c031ffdd>] ? _read_unlock+0x1d/0x20 [<f8d31fa0>] ? rose_route_frame+0x0/0x620 [rose] [<f8d1c396>] ax25_rx_iframe+0x66/0x3b0 [ax25] [<f8d1f42f>] ? ax25_start_t3timer+0x1f/0x40 [ax25] [<f8d1e65b>] ax25_std_frame_in+0x7fb/0x890 [ax25] [<c0320005>] ? _spin_unlock_bh+0x25/0x30 [<f8d1bdf6>] ax25_kiss_rcv+0x2c6/0x800 [ax25] [<c02a4769>] ? sock_def_readable+0x59/0x80 [<c014a8a7>] ? __lock_release+0x47/0x70 [<c02a4769>] ? sock_def_readable+0x59/0x80 [<c031ffdd>] ? _read_unlock+0x1d/0x20 [<c02a4769>] ? sock_def_readable+0x59/0x80 [<c02a4d3a>] ? sock_queue_rcv_skb+0x13a/0x1d0 [<c02a4c45>] ? sock_queue_rcv_skb+0x45/0x1d0 [<f8d1bb30>] ? ax25_kiss_rcv+0x0/0x800 [ax25] [<c02ac715>] netif_receive_skb+0x255/0x2f0 [<c02ac5c0>] ? netif_receive_skb+0x100/0x2f0 [<c02af05c>] process_backlog+0x7c/0xf0 [<c02aeb0c>] net_rx_action+0x16c/0x230 [<c02aea36>] ? net_rx_action+0x96/0x230 [<c012bd53>] __do_softirq+0x93/0x120 [<f8d2a68a>] ? mkiss_receive_buf+0x33a/0x3f0 [mkiss] [<c012be37>] do_softirq+0x57/0x60 [<c012c265>] local_bh_enable_ip+0xa5/0xe0 [<c0320005>] _spin_unlock_bh+0x25/0x30 [<f8d2a68a>] mkiss_receive_buf+0x33a/0x3f0 [mkiss] [<c025ea37>] pty_write+0x47/0x60 [<c025c620>] write_chan+0x1b0/0x220 [<c0259a1c>] ? tty_write_lock+0x1c/0x50 [<c011fec0>] ? default_wake_function+0x0/0x10 [<c0259bea>] tty_write+0x12a/0x1c0 [<c025c470>] ? write_chan+0x0/0x220 [<c018bbc6>] vfs_write+0x96/0x130 [<c0259ac0>] ? tty_write+0x0/0x1c0 [<c018c24d>] sys_write+0x3d/0x70 [<c0104d1e>] sysenter_past_esp+0x5f/0xa5 ======================= Since rose_route_frame() does not use rose_node_list we can safely remove rose_node_list_lock spin lock here and let it be free for rose_get_neigh(). Signed-off-by: Bernard Pidoux <f6bvp@amsat.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
[ INFO: possible recursive locking detected ]
2.6.25 #3
---------------------------------------------
ax25ipd/3811 is trying to acquire lock:
  (rose_node_list_lock){-+..}, at: [<f8d31f1a>] rose_get_neigh+0x1a/0xa0 
[rose]

but task is already holding lock:
  (rose_node_list_lock){-+..}, at: [<f8d31fed>] 
rose_route_frame+0x4d/0x620 [rose]

other info that might help us debug this:
6 locks held by ax25ipd/3811:
  #0:  (&tty->atomic_write_lock){--..}, at: [<c0259a1c>] 
tty_write_lock+0x1c/0x50
  #1:  (rcu_read_lock){..--}, at: [<c02aea36>] net_rx_action+0x96/0x230
  #2:  (rcu_read_lock){..--}, at: [<c02ac5c0>] netif_receive_skb+0x100/0x2f0
  #3:  (rose_node_list_lock){-+..}, at: [<f8d31fed>] 
rose_route_frame+0x4d/0x620 [rose]
  #4:  (rose_neigh_list_lock){-+..}, at: [<f8d31ff7>] 
rose_route_frame+0x57/0x620 [rose]
  #5:  (rose_route_list_lock){-+..}, at: [<f8d32001>] 
rose_route_frame+0x61/0x620 [rose]

stack backtrace:
Pid: 3811, comm: ax25ipd Not tainted 2.6.25 #3
  [<c0147e27>] print_deadlock_bug+0xc7/0xd0
  [<c0147eca>] check_deadlock+0x9a/0xb0
  [<c0149cd2>] validate_chain+0x1e2/0x310
  [<c0149b95>] ? validate_chain+0xa5/0x310
  [<c010a7d8>] ? native_sched_clock+0x88/0xc0
  [<c0149fa1>] __lock_acquire+0x1a1/0x750
  [<c014a5d1>] lock_acquire+0x81/0xa0
  [<f8d31f1a>] ? rose_get_neigh+0x1a/0xa0 [rose]
  [<c03201a3>] _spin_lock_bh+0x33/0x60
  [<f8d31f1a>] ? rose_get_neigh+0x1a/0xa0 [rose]
  [<f8d31f1a>] rose_get_neigh+0x1a/0xa0 [rose]
  [<f8d32404>] rose_route_frame+0x464/0x620 [rose]
  [<c031ffdd>] ? _read_unlock+0x1d/0x20
  [<f8d31fa0>] ? rose_route_frame+0x0/0x620 [rose]
  [<f8d1c396>] ax25_rx_iframe+0x66/0x3b0 [ax25]
  [<f8d1f42f>] ? ax25_start_t3timer+0x1f/0x40 [ax25]
  [<f8d1e65b>] ax25_std_frame_in+0x7fb/0x890 [ax25]
  [<c0320005>] ? _spin_unlock_bh+0x25/0x30
  [<f8d1bdf6>] ax25_kiss_rcv+0x2c6/0x800 [ax25]
  [<c02a4769>] ? sock_def_readable+0x59/0x80
  [<c014a8a7>] ? __lock_release+0x47/0x70
  [<c02a4769>] ? sock_def_readable+0x59/0x80
  [<c031ffdd>] ? _read_unlock+0x1d/0x20
  [<c02a4769>] ? sock_def_readable+0x59/0x80
  [<c02a4d3a>] ? sock_queue_rcv_skb+0x13a/0x1d0
  [<c02a4c45>] ? sock_queue_rcv_skb+0x45/0x1d0
  [<f8d1bb30>] ? ax25_kiss_rcv+0x0/0x800 [ax25]
  [<c02ac715>] netif_receive_skb+0x255/0x2f0
  [<c02ac5c0>] ? netif_receive_skb+0x100/0x2f0
  [<c02af05c>] process_backlog+0x7c/0xf0
  [<c02aeb0c>] net_rx_action+0x16c/0x230
  [<c02aea36>] ? net_rx_action+0x96/0x230
  [<c012bd53>] __do_softirq+0x93/0x120
  [<f8d2a68a>] ? mkiss_receive_buf+0x33a/0x3f0 [mkiss]
  [<c012be37>] do_softirq+0x57/0x60
  [<c012c265>] local_bh_enable_ip+0xa5/0xe0
  [<c0320005>] _spin_unlock_bh+0x25/0x30
  [<f8d2a68a>] mkiss_receive_buf+0x33a/0x3f0 [mkiss]
  [<c025ea37>] pty_write+0x47/0x60
  [<c025c620>] write_chan+0x1b0/0x220
  [<c0259a1c>] ? tty_write_lock+0x1c/0x50
  [<c011fec0>] ? default_wake_function+0x0/0x10
  [<c0259bea>] tty_write+0x12a/0x1c0
  [<c025c470>] ? write_chan+0x0/0x220
  [<c018bbc6>] vfs_write+0x96/0x130
  [<c0259ac0>] ? tty_write+0x0/0x1c0
  [<c018c24d>] sys_write+0x3d/0x70
  [<c0104d1e>] sysenter_past_esp+0x5f/0xa5
  =======================
BUG: soft lockup - CPU#0 stuck for 61s! [ax25ipd:3811]

Pid: 3811, comm: ax25ipd Not tainted (2.6.25 #3)
EIP: 0060:[<c010a9db>] EFLAGS: 00000246 CPU: 0
EIP is at native_read_tsc+0xb/0x20
EAX: b404aa2c EBX: b404a9c9 ECX: 017f1000 EDX: 0000076b
ESI: 00000001 EDI: 00000000 EBP: ecc83afc ESP: ecc83afc
  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: b7f5f000 CR3: 2cd8e000 CR4: 000006f0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
  [<c0204937>] delay_tsc+0x17/0x30
  [<c02048e9>] __delay+0x9/0x10
  [<c02127f6>] __spin_lock_debug+0x76/0xf0
  [<c0212618>] ? spin_bug+0x18/0x100
  [<c0147923>] ? __lock_contended+0xa3/0x110
  [<c0212998>] _raw_spin_lock+0x68/0x90
  [<c03201bf>] _spin_lock_bh+0x4f/0x60
  [<f8d31f1a>] ? rose_get_neigh+0x1a/0xa0 [rose]
  [<f8d31f1a>] rose_get_neigh+0x1a/0xa0 [rose]
  [<f8d32404>] rose_route_frame+0x464/0x620 [rose]
  [<c031ffdd>] ? _read_unlock+0x1d/0x20
  [<f8d31fa0>] ? rose_route_frame+0x0/0x620 [rose]
  [<f8d1c396>] ax25_rx_iframe+0x66/0x3b0 [ax25]
  [<f8d1f42f>] ? ax25_start_t3timer+0x1f/0x40 [ax25]
  [<f8d1e65b>] ax25_std_frame_in+0x7fb/0x890 [ax25]
  [<c0320005>] ? _spin_unlock_bh+0x25/0x30
  [<f8d1bdf6>] ax25_kiss_rcv+0x2c6/0x800 [ax25]
  [<c02a4769>] ? sock_def_readable+0x59/0x80
  [<c014a8a7>] ? __lock_release+0x47/0x70
  [<c02a4769>] ? sock_def_readable+0x59/0x80
  [<c031ffdd>] ? _read_unlock+0x1d/0x20
  [<c02a4769>] ? sock_def_readable+0x59/0x80
  [<c02a4d3a>] ? sock_queue_rcv_skb+0x13a/0x1d0
  [<c02a4c45>] ? sock_queue_rcv_skb+0x45/0x1d0
  [<f8d1bb30>] ? ax25_kiss_rcv+0x0/0x800 [ax25]
  [<c02ac715>] netif_receive_skb+0x255/0x2f0
  [<c02ac5c0>] ? netif_receive_skb+0x100/0x2f0
  [<c02af05c>] process_backlog+0x7c/0xf0
  [<c02aeb0c>] net_rx_action+0x16c/0x230
  [<c02aea36>] ? net_rx_action+0x96/0x230
  [<c012bd53>] __do_softirq+0x93/0x120
  [<f8d2a68a>] ? mkiss_receive_buf+0x33a/0x3f0 [mkiss]
  [<c012be37>] do_softirq+0x57/0x60
  [<c012c265>] local_bh_enable_ip+0xa5/0xe0
  [<c0320005>] _spin_unlock_bh+0x25/0x30
  [<f8d2a68a>] mkiss_receive_buf+0x33a/0x3f0 [mkiss]
  [<c025ea37>] pty_write+0x47/0x60
  [<c025c620>] write_chan+0x1b0/0x220
  [<c0259a1c>] ? tty_write_lock+0x1c/0x50
  [<c011fec0>] ? default_wake_function+0x0/0x10
  [<c0259bea>] tty_write+0x12a/0x1c0
  [<c025c470>] ? write_chan+0x0/0x220
  [<c018bbc6>] vfs_write+0x96/0x130
  [<c0259ac0>] ? tty_write+0x0/0x1c0
  [<c018c24d>] sys_write+0x3d/0x70
  [<c0104d1e>] sysenter_past_esp+0x5f/0xa5
  =======================

Since rose_route_frame() does not use rose_node_list we can safely
remove rose_node_list_lock spin lock here and let it be free for
rose_get_neigh().

Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
rose: Socket lock was not released before returning to user space 2008-04-20T01:41:51+00:00 Bernard Pidoux f6bvp@amsat.org 2008-04-20T01:41:51+00:00 43837b1e6c5aef803d57009a68db18df13e64892 ================================================ [ BUG: lock held when returning to user space! ] ------------------------------------------------ xfbbd/3683 is leaving the kernel with locks still held! 1 lock held by xfbbd/3683: #0: (sk_lock-AF_ROSE){--..}, at: [<c8cd1eb3>] rose_connect+0x73/0x420 [rose] INFO: task xfbbd:3683 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. xfbbd D 00000246 0 3683 3669 c6965ee0 00000092 c02c5c40 00000246 c0f6b5f0 c0f6b5c0 c0f6b5f0 c0f6b5c0 c0f6b614 c6965f18 c024b74b ffffffff c06ba070 00000000 00000000 00000001 c6ab07c0 c012d450 c0f6b634 c0f6b634 c7b5bf10 c0d6004c c7b5bf10 c6965f40 Call Trace: [<c024b74b>] lock_sock_nested+0x6b/0xd0 [<c012d450>] ? autoremove_wake_function+0x0/0x40 [<c02488f1>] sock_fasync+0x41/0x150 [<c0249e69>] sock_close+0x19/0x40 [<c0175d54>] __fput+0xb4/0x170 [<c0176018>] fput+0x18/0x20 [<c017300e>] filp_close+0x3e/0x70 [<c01744e9>] sys_close+0x69/0xb0 [<c0103bda>] sysenter_past_esp+0x5f/0xa5 ======================= INFO: lockdep is turned off. Signed-off-by: Bernard Pidoux <f6bvp@amsat.org> Signed-off-by: David S. Miller <davem@davemloft.net> 
================================================
[ BUG: lock held when returning to user space! ]
------------------------------------------------
xfbbd/3683 is leaving the kernel with locks still held!
1 lock held by xfbbd/3683:
  #0:  (sk_lock-AF_ROSE){--..}, at: [<c8cd1eb3>] rose_connect+0x73/0x420 [rose]

INFO: task xfbbd:3683 blocked for more than 120 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
xfbbd         D 00000246     0  3683   3669
        c6965ee0 00000092 c02c5c40 00000246 c0f6b5f0 c0f6b5c0 c0f6b5f0 c0f6b5c0
        c0f6b614 c6965f18 c024b74b ffffffff c06ba070 00000000 00000000 00000001
        c6ab07c0 c012d450 c0f6b634 c0f6b634 c7b5bf10 c0d6004c c7b5bf10 c6965f40
Call Trace:
  [<c024b74b>] lock_sock_nested+0x6b/0xd0
  [<c012d450>] ? autoremove_wake_function+0x0/0x40
  [<c02488f1>] sock_fasync+0x41/0x150
  [<c0249e69>] sock_close+0x19/0x40
  [<c0175d54>] __fput+0xb4/0x170
  [<c0176018>] fput+0x18/0x20
  [<c017300e>] filp_close+0x3e/0x70
  [<c01744e9>] sys_close+0x69/0xb0
  [<c0103bda>] sysenter_past_esp+0x5f/0xa5
  =======================
INFO: lockdep is turned off.

Signed-off-by: Bernard Pidoux <f6bvp@amsat.org>
Signed-off-by: David S. Miller <davem@davemloft.net>