linux/net/rose, branch v2.6.27.48

rose: Fix rose_getname() leak

2009-09-09T03:17:44Z

commit 17ac2e9c58b69a1e25460a568eae1b0dc0188c25 upstream. rose_getname() can leak kernel memory to user. Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

af_rose/x25: Sanity check the maximum user frame size

2009-05-02T17:24:04Z

upstream commit: 83e0bbcbe2145f160fbaa109b0439dae7f4a38a9 CVE-2009-0795. Otherwise we can wrap the sizes and end up sending garbage. Closes #10423 Signed-off-by: Alan Cox Signed-off-by: David S. Miller Signed-off-by: Chris Wright Signed-off-by: Greg Kroah-Hartman

netdev: Handle ->addr_list_lock just like ->_xmit_lock for lockdep.

2008-07-22T21:16:42Z

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

netns: Use net_eq() to compare net-namespaces for optimization.

2008-07-20T05:34:43Z

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 Signed-off-by: David S. Miller

netdev: Allocate multiple queues for TX.

2008-07-18T02:21:00Z

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

netdev: Move _xmit_lock and xmit_lock_owner into netdev_queue.

2008-07-09T06:13:53Z

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

rose: improving AX25 routing frames via ROSE network

2008-06-18T00:08:32Z

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 Signed-off-by: David S. Miller

rose: Use sock_graft() and remove bogus sk_socket and sk_sleep init.

2008-06-17T09:39:21Z

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

rose: Wrong list_lock argument in rose_node seqops

2008-05-03T00:03:22Z

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 Signed-off-by: David S. Miller

[ROSE]: Fix soft lockup wrt. rose_node_list_lock

2008-04-20T22:58:07Z

[ INFO: possible recursive locking detected ] 2.6.25 #3 --------------------------------------------- ax25ipd/3811 is trying to acquire lock: (rose_node_list_lock){-+..}, at: [] rose_get_neigh+0x1a/0xa0 [rose] but task is already holding lock: (rose_node_list_lock){-+..}, at: [] 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: [] tty_write_lock+0x1c/0x50 #1: (rcu_read_lock){..--}, at: [] net_rx_action+0x96/0x230 #2: (rcu_read_lock){..--}, at: [] netif_receive_skb+0x100/0x2f0 #3: (rose_node_list_lock){-+..}, at: [] rose_route_frame+0x4d/0x620 [rose] #4: (rose_neigh_list_lock){-+..}, at: [] rose_route_frame+0x57/0x620 [rose] #5: (rose_route_list_lock){-+..}, at: [] rose_route_frame+0x61/0x620 [rose] stack backtrace: Pid: 3811, comm: ax25ipd Not tainted 2.6.25 #3 [] print_deadlock_bug+0xc7/0xd0 [] check_deadlock+0x9a/0xb0 [] validate_chain+0x1e2/0x310 [] ? validate_chain+0xa5/0x310 [] ? native_sched_clock+0x88/0xc0 [] __lock_acquire+0x1a1/0x750 [] lock_acquire+0x81/0xa0 [] ? rose_get_neigh+0x1a/0xa0 [rose] [] _spin_lock_bh+0x33/0x60 [] ? rose_get_neigh+0x1a/0xa0 [rose] [] rose_get_neigh+0x1a/0xa0 [rose] [] rose_route_frame+0x464/0x620 [rose] [] ? _read_unlock+0x1d/0x20 [] ? rose_route_frame+0x0/0x620 [rose] [] ax25_rx_iframe+0x66/0x3b0 [ax25] [] ? ax25_start_t3timer+0x1f/0x40 [ax25] [] ax25_std_frame_in+0x7fb/0x890 [ax25] [] ? _spin_unlock_bh+0x25/0x30 [] ax25_kiss_rcv+0x2c6/0x800 [ax25] [] ? sock_def_readable+0x59/0x80 [] ? __lock_release+0x47/0x70 [] ? sock_def_readable+0x59/0x80 [] ? _read_unlock+0x1d/0x20 [] ? sock_def_readable+0x59/0x80 [] ? sock_queue_rcv_skb+0x13a/0x1d0 [] ? sock_queue_rcv_skb+0x45/0x1d0 [] ? ax25_kiss_rcv+0x0/0x800 [ax25] [] netif_receive_skb+0x255/0x2f0 [] ? netif_receive_skb+0x100/0x2f0 [] process_backlog+0x7c/0xf0 [] net_rx_action+0x16c/0x230 [] ? net_rx_action+0x96/0x230 [] __do_softirq+0x93/0x120 [] ? mkiss_receive_buf+0x33a/0x3f0 [mkiss] [] do_softirq+0x57/0x60 [] local_bh_enable_ip+0xa5/0xe0 [] _spin_unlock_bh+0x25/0x30 [] mkiss_receive_buf+0x33a/0x3f0 [mkiss] [] pty_write+0x47/0x60 [] write_chan+0x1b0/0x220 [] ? tty_write_lock+0x1c/0x50 [] ? default_wake_function+0x0/0x10 [] tty_write+0x12a/0x1c0 [] ? write_chan+0x0/0x220 [] vfs_write+0x96/0x130 [] ? tty_write+0x0/0x1c0 [] sys_write+0x3d/0x70 [] 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:[] 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 [] delay_tsc+0x17/0x30 [] __delay+0x9/0x10 [] __spin_lock_debug+0x76/0xf0 [] ? spin_bug+0x18/0x100 [] ? __lock_contended+0xa3/0x110 [] _raw_spin_lock+0x68/0x90 [] _spin_lock_bh+0x4f/0x60 [] ? rose_get_neigh+0x1a/0xa0 [rose] [] rose_get_neigh+0x1a/0xa0 [rose] [] rose_route_frame+0x464/0x620 [rose] [] ? _read_unlock+0x1d/0x20 [] ? rose_route_frame+0x0/0x620 [rose] [] ax25_rx_iframe+0x66/0x3b0 [ax25] [] ? ax25_start_t3timer+0x1f/0x40 [ax25] [] ax25_std_frame_in+0x7fb/0x890 [ax25] [] ? _spin_unlock_bh+0x25/0x30 [] ax25_kiss_rcv+0x2c6/0x800 [ax25] [] ? sock_def_readable+0x59/0x80 [] ? __lock_release+0x47/0x70 [] ? sock_def_readable+0x59/0x80 [] ? _read_unlock+0x1d/0x20 [] ? sock_def_readable+0x59/0x80 [] ? sock_queue_rcv_skb+0x13a/0x1d0 [] ? sock_queue_rcv_skb+0x45/0x1d0 [] ? ax25_kiss_rcv+0x0/0x800 [ax25] [] netif_receive_skb+0x255/0x2f0 [] ? netif_receive_skb+0x100/0x2f0 [] process_backlog+0x7c/0xf0 [] net_rx_action+0x16c/0x230 [] ? net_rx_action+0x96/0x230 [] __do_softirq+0x93/0x120 [] ? mkiss_receive_buf+0x33a/0x3f0 [mkiss] [] do_softirq+0x57/0x60 [] local_bh_enable_ip+0xa5/0xe0 [] _spin_unlock_bh+0x25/0x30 [] mkiss_receive_buf+0x33a/0x3f0 [mkiss] [] pty_write+0x47/0x60 [] write_chan+0x1b0/0x220 [] ? tty_write_lock+0x1c/0x50 [] ? default_wake_function+0x0/0x10 [] tty_write+0x12a/0x1c0 [] ? write_chan+0x0/0x220 [] vfs_write+0x96/0x130 [] ? tty_write+0x0/0x1c0 [] sys_write+0x3d/0x70 [] 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 Signed-off-by: David S. Miller