- 03 Apr, 2008 15 commits
-
-
Denis V. Lunev authored
Signed-off-by:
Denis V.Lunev <den@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Denis V. Lunev authored
Signed-off-by:
-
Denis V. Lunev authored
Do this by replacing sock_create_kern with inet_ctl_sock_create. Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
-
Denis V. Lunev authored
uc_ttl is initialized in inet(6)_create and never changed except setsockopt ioctl. Remove this assignment. Signed-off-by:
-
Denis V. Lunev authored
Replace sock_create_kern with inet_ctl_sock_create. Signed-off-by:
-
Denis V. Lunev authored
This is a generic requirement, so make inet_ctl_sock_create namespace aware and create a inet_ctl_sock_destroy wrapper around sk_release_kernel. Signed-off-by:
-
Denis V. Lunev authored
All upper protocol layers are already use sock internally. Signed-off-by:
-
Denis V. Lunev authored
Signed-off-by:
-
Denis V. Lunev authored
sk->sk_proc->(un)hash is noop right now, so the unification is correct. Signed-off-by:
-
Denis V. Lunev authored
This call is nothing common with INET connection sockets code. It simply creates an unhashes kernel sockets for protocol messages. Move the new call into af_inet.c after the rename. Signed-off-by:
-
Denis V. Lunev authored
This seems a purism as module can't be unloaded, but though if cleanup method is present it should be correct and clean all staff created. Signed-off-by:
-
Denis V. Lunev authored
Replace dccp_v(4|6)_ctl_socket with sock to unify a code with TCP/ICMP. Signed-off-by:
-
Denis V. Lunev authored
Replace tcp_socket with tcp_sock. This is more effective (less derefferences on fast paths). Additionally, the approach is unified to one used in ICMP. Signed-off-by:
-
Denis V. Lunev authored
This does not look good, but there is no other choice. The compilation without CONFIG_NET is broken and can not be fixed with ease. After that there is no need for the following commits: 1567ca7e 3edf8fa5 2d38f9a4 Revert them. Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6David S. Miller authored
Conflicts: drivers/net/s2io.c
-
- 02 Apr, 2008 12 commits
-
-
Denis V. Lunev authored
Signed-off-by:
-
Denis V. Lunev authored
They are redundant as this file is linked in iff CONFIG_NET is turned on. Signed-off-by:
-
Denis V. Lunev authored
Signed-off-by:
-
Pavel Emelyanov authored
This may lead to situations, when each of two proc entries produce data for the other's device. Looks like a BUG, so this patch is for net-2.6. It will not apply to net-2.6.26 since dev->nd_net access is replaced with dev_net(dev) one. Signed-off-by:
Pavel Emelyanov <xemul@openvz.org> Signed-off-by:
-
Herbert Xu authored
When we encounter an error while looking up the dst the second time we need to drop the first dst. This patch is pretty much the same as the one for IPv4. Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Leonardo Potenza authored
Removed the warning messages: drivers/atm/iphase.c:961: warning: 'tcnter' defined but not used drivers/atm/iphase.c:963: warning: 'xdump' defined but not used tcnter and xdump() are used only in debug build Signed-off-by:
Leonardo Potenza <lpotenza@inwind.it> Signed-off-by:
-
Benoit Boissinot authored
From RFC341: A temporary address is created only if this calculated Preferred Lifetime is greater than REGEN_ADVANCE time units. In particular, an implementation must not create a temporary address with a zero Preferred Lifetime. Signed-off-by:
Benoit Boissinot <benoit.boissinot@ens-lyon.org> Signed-off-by:
YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org> Signed-off-by:
-
Benoit Boissinot authored
When receiving a prefix information from a routeur, only update the lifetimes of the temporary address associated with that prefix. Otherwise if one deprecated prefix is advertized, all your temporary addresses will become deprecated. Signed-off-by:
-
Dave Young authored
Lockdep warning will be trigged while rfcomm connection closing. The locks taken in rfcomm_dev_add: rfcomm_dev_lock --> d->lock In __rfcomm_dlc_close: d->lock --> rfcomm_dev_lock (in rfcomm_dev_state_change) There's two way to fix it, one is in rfcomm_dev_add we first locking d->lock then the rfcomm_dev_lock The other (in this patch), remove the locking of d->lock for rfcomm_dev_state_change because just locking "d->state = BT_CLOSED;" is enough. [ 295.002046] ======================================================= [ 295.002046] [ INFO: possible circular locking dependency detected ] [ 295.002046] 2.6.25-rc7 #1 [ 295.002046] ------------------------------------------------------- [ 295.002046] krfcommd/2705 is trying to acquire lock: [ 295.002046] (rfcomm_dev_lock){-.--}, at: [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [ 295.002046] but task is already holding lock: [ 295.002046] (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] which lock already depends on the new lock. [ 295.002046] [ 295.002046] [ 295.002046] the existing dependency chain (in reverse order) is: [ 295.002046] [ 295.002046] -> #1 (&d->lock){--..}: [ 295.002046] [<c0149b23>] check_prev_add+0xd3/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<c03d6b99>] _spin_lock+0x39/0x80 [ 295.002046] [<f89a01c0>] rfcomm_dev_add+0x240/0x360 [rfcomm] [ 295.002046] [<f89a047e>] rfcomm_create_dev+0x6e/0xe0 [rfcomm] [ 295.002046] [<f89a0823>] rfcomm_dev_ioctl+0x33/0x60 [rfcomm] [ 295.002046] [<f899facc>] rfcomm_sock_ioctl+0x2c/0x50 [rfcomm] [ 295.002046] [<c0363d38>] sock_ioctl+0x118/0x240 [ 295.002046] [<c0194196>] vfs_ioctl+0x76/0x90 [ 295.002046] [<c0194446>] do_vfs_ioctl+0x56/0x140 [ 295.002046] [<c0194569>] sys_ioctl+0x39/0x60 [ 295.002046] [<c0104faa>] syscall_call+0x7/0xb [ 295.002046] [<ffffffff>] 0xffffffff [ 295.002046] [ 295.002046] -> #0 (rfcomm_dev_lock){-.--}: [ 295.002046] [<c0149a84>] check_prev_add+0x34/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<c03d6639>] _read_lock+0x39/0x80 [ 295.002046] [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [<c013c18c>] kthread+0x5c/0xa0 [ 295.002046] [<c0105c07>] kernel_thread_helper+0x7/0x10 [ 295.002046] [<ffffffff>] 0xffffffff [ 295.002046] [ 295.002046] other info that might help us debug this: [ 295.002046] [ 295.002046] 2 locks held by krfcommd/2705: [ 295.002046] #0: (rfcomm_mutex){--..}, at: [<f899e2eb>] rfcomm_run+0x7b/0x550 [rfcomm] [ 295.002046] #1: (&d->lock){--..}, at: [<f899c533>] __rfcomm_dlc_close+0x43/0xd0 [rfcomm] [ 295.002046] [ 295.002046] stack backtrace: [ 295.002046] Pid: 2705, comm: krfcommd Not tainted 2.6.25-rc7 #1 [ 295.002046] [<c0128a38>] ? printk+0x18/0x20 [ 295.002046] [<c014927f>] print_circular_bug_tail+0x6f/0x80 [ 295.002046] [<c0149a84>] check_prev_add+0x34/0x200 [ 295.002046] [<c0149ce5>] check_prevs_add+0x95/0xe0 [ 295.002046] [<c0149f6f>] validate_chain+0x23f/0x320 [ 295.002046] [<c014b7b1>] __lock_acquire+0x1c1/0x760 [ 295.002046] [<c014c349>] lock_acquire+0x79/0xb0 [ 295.002046] [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<c03d6639>] _read_lock+0x39/0x80 [ 295.002046] [<f89a090a>] ? rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f89a090a>] rfcomm_dev_state_change+0x6a/0xd0 [rfcomm] [ 295.002046] [<f899c548>] __rfcomm_dlc_close+0x58/0xd0 [rfcomm] [ 295.002046] [<f899d44f>] rfcomm_recv_ua+0x6f/0x120 [rfcomm] [ 295.002046] [<f899e061>] rfcomm_recv_frame+0x171/0x1e0 [rfcomm] [ 295.002046] [<c014abd9>] ? trace_hardirqs_on+0xb9/0x130 [ 295.002046] [<c03d6e89>] ? _spin_unlock_irqrestore+0x39/0x70 [ 295.002046] [<f899e357>] rfcomm_run+0xe7/0x550 [rfcomm] [ 295.002046] [<c03d4559>] ? __sched_text_start+0x229/0x4c0 [ 295.002046] [<c0120000>] ? cpu_avg_load_per_task+0x20/0x30 [ 295.002046] [<f899e270>] ? rfcomm_run+0x0/0x550 [rfcomm] [ 295.002046] [<c013c18c>] kthread+0x5c/0xa0 [ 295.002046] [<c013c130>] ? kthread+0x0/0xa0 [ 295.002046] [<c0105c07>] kernel_thread_helper+0x7/0x10 [ 295.002046] ======================= Signed-off-by:Dave Young <hidave.darkstar@gmail.com> Signed-off-by:
-
Dave Young authored
'rfcomm connect' will trigger lockdep warnings which is caused by locking diffrent kinds of bluetooth sockets at the same time. So using sub-classes per AF_BLUETOOTH sub-type for lockdep. Thanks for the hints from dave jones. --- > From: Dave Jones <davej@codemonkey.org.uk> > Date: Thu, 27 Mar 2008 12:21:56 -0400 > > > Mar 27 08:10:57 localhost kernel: Pid: 3611, comm: obex-data-serve Not tainted 2.6.25-0.121.rc5.git4.fc9 #1 > > Mar 27 08:10:57 localhost kernel: [__lock_acquire+2287/3089] __lock_acquire+0x8ef/0xc11 > > Mar 27 08:10:57 localhost kernel: [sched_clock+8/11] ? sched_clock+0x8/0xb > > Mar 27 08:10:57 localhost kernel: [lock_acquire+106/144] lock_acquire+0x6a/0x90 > > Mar 27 08:10:57 localhost kernel: [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [lock_sock_nested+182/198] lock_sock_nested+0xb6/0xc6 > > Mar 27 08:10:57 localhost kernel: [<f8bd9321>] ? l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [security_socket_post_create+22/27] ? security_socket_post_create+0x16/0x1b > > Mar 27 08:10:57 localhost kernel: [__sock_create+388/472] ? __sock_create+0x184/0x1d8 > > Mar 27 08:10:57 localhost kernel: [<f8bd9321>] l2cap_sock_bind+0x29/0x108 [l2cap] > > Mar 27 08:10:57 localhost kernel: [kernel_bind+10/13] kernel_bind+0xa/0xd > > Mar 27 08:10:57 localhost kernel: [<f8dad3d7>] rfcomm_dlc_open+0xc8/0x294 [rfcomm] > > Mar 27 08:10:57 localhost kernel: [lock_sock_nested+187/198] ? lock_sock_nested+0xbb/0xc6 > > Mar 27 08:10:57 localhost kernel: [<f8dae18c>] rfcomm_sock_connect+0x8b/0xc2 [rfcomm] > > Mar 27 08:10:57 localhost kernel: [sys_connect+96/125] sys_connect+0x60/0x7d > > Mar 27 08:10:57 localhost kernel: [__lock_acquire+1370/3089] ? __lock_acquire+0x55a/0xc11 > > Mar 27 08:10:57 localhost kernel: [sys_socketcall+140/392] sys_socketcall+0x8c/0x188 > > Mar 27 08:10:57 localhost kernel: [syscall_call+7/11] syscall_call+0x7/0xb --- Signed-off-by:
-
YOSHIFUJI Hideaki authored
Signed-off-by:
-
Jarek Poplawski authored
rose_release() doesn't release sockets properly, e.g. it skips sock_orphan(), so OOPSes are triggered in sock_def_write_space(), which was observed especially while ROSE skbs were kfreed from ax25_frames_acked(). There is also sock_hold() and lock_sock() added - similarly to ax25_release(). Thanks to Bernard Pidoux for substantial help in debugging this problem. Signed-off-by:
Jarek Poplawski <jarkao2@gmail.com> Reported-and-tested-by:
Bernard Pidoux <bpidoux@free.fr> Signed-off-by:
-
- 01 Apr, 2008 13 commits
-
-
John W. Linville authored
drivers/net/wireless/ath5k/base.c: In function `ath5k_check_ibss_tsf': drivers/net/wireless/ath5k/base.c:1740: warning: long long unsigned int format, u64 arg (arg 5) drivers/net/wireless/ath5k/base.c:1740: warning: long long unsigned int format, u64 arg (arg 6) drivers/net/wireless/ath5k/base.c:1740: warning: long long int format, u64 arg (arg 7) drivers/net/wireless/ath5k/base.c:1740: warning: long long unsigned int format, u64 arg (arg 8) drivers/net/wireless/ath5k/base.c:1757: warning: long long unsigned int format, u64 arg (arg 5) drivers/net/wireless/ath5k/base.c:1757: warning: long long unsigned int format, u64 arg (arg 6) drivers/net/wireless/iwlwifi/iwl4965-base.c: In function `iwl4965_tx_status_reply_tx': drivers/net/wireless/iwlwifi/iwl4965-base.c:3105: warning: long long unsigned int format, u64 arg (arg 6) drivers/net/wireless/iwlwifi/iwl-4965.c: In function `iwl4965_rx_reply_rx': drivers/net/wireless/iwlwifi/iwl-4965.c:3978: warning: long long unsigned int format, u64 arg (arg 7) Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:John W. Linville <linville@tuxdriver.com>
-
Luis Carlos Cobo authored
This allows cleaner code when accesing bss->mesh_config components. Signed-off-by:
Luis Carlos Cobo <luisca@cozybit.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Luis Carlos Cobo authored
Signed-off-by:
-
Luis Carlos Cobo authored
...not only broadcast. Signed-off-by:
-
Luis Carlos Cobo authored
Signed-off-by:
-
Luis Carlos Cobo authored
The bug shows up with CONFIG_PREEMPT enabled. Pointed out by Andrew Morton. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Johannes Berg authored
A variable 'i' is being shadowed by another one, but the second one can just be removed. Signed-off-by:
-
Johannes Berg authored
When the IBSS code tries to flush the STA list, it does so in an atomic context. Flushing isn't safe there, however, and requires the RTNL, so we need to defer it to a workqueue. Signed-off-by:
-
Johannes Berg authored
Calling sta_info_destroy() doesn't require RCU-synchronisation before-hand because it does that internally. However, it does require rtnl-locking so insert that where necessary. Also clean up the code doing it internally to be a bit clearer and not synchronize twice if keys are configured. Signed-off-by:
-
Johannes Berg authored
When STA structure insertion fails, it has been allocated but isn't really alive yet, it isn't reachable by any other code and also can't yet have much configured. This patch changes the code so that when the insertion fails, the resulting STA pointer is no longer valid because it is freed. Signed-off-by:
-
Johannes Berg authored
sta_info_destroy(NULL) should be valid, but currently isn't because the argument is dereferenced before the NULL check. There are no users that currently pass in NULL, i.e. all check before calling the function, but I want to change that. Signed-off-by:
-
Johannes Berg authored
When joining a new IBSS, all old stations are flushed, but currently all stations belonging to all virtual interfaces are flushed, which is wrong. This patch fixes it. Signed-off-by:
-
Ivo van Doorn authored
Implement triggers inside rt2x00 itself based on input from mac80211. This replaces the method of using the mac80211 trigger events which do not work for USB drivers due to the scheduling requirement. After this patch RT2500USB_LEDS and RT73USB_LEDS no longer need to be tagged as broken since they now support LED handling again without having to check for in_atomic(). Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
