All upper protocol layers are already use sock internally.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDenis V. Lunev <den@openvz.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

sk->sk_proc->(un)hash is noop right now, so the unification is correct.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDenis V. Lunev <den@openvz.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDenis V. Lunev <den@openvz.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Replace dccp_v(4|6)_ctl_socket with sock to unify a code with TCP/ICMP.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDenis V. Lunev <den@openvz.org>
Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Conflicts:

	drivers/net/s2io.c

Signed-off-by: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

They are redundant as this file is linked in iff CONFIG_NET is turned
on.
Signed-off-by: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NDenis V. Lunev <den@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NLeonardo Potenza <lpotenza@inwind.it>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

'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: NDave Young <hidave.darkstar@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NJarek Poplawski <jarkao2@gmail.com>
Reported-and-tested-by: NBernard Pidoux <bpidoux@free.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NJohn W. Linville <linville@tuxdriver.com>

This allows cleaner code when accesing bss->mesh_config components.
Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

...not only broadcast.
Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NLuis Carlos Cobo <luisca@cozybit.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NLuis Carlos Cobo <luisca@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

A variable 'i' is being shadowed by another one, but the second
one can just be removed.
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
Cc: Vladimir Koutny <vlado@work.ksp.sk>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

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: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The TO_DS filter does not only depend on the FIF_PROMISC_IN_BSS flag
provided by mac80211, but also on the intf_ap_count count.
This makes sense, since when Master mode is active, we should all frames
that are send to the active AP (the device itself).

This means that when an interface is added we should force the
packet filter to be updated during the next mac80211 call of
configure_filter() to make sure the intf_ap_count field is checked.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Invert the check for scheduling the packet_filter configuration.
When DRIVER_REQUIRE_SCHEDULED is not set we should immediately
configure the the filter.

This fixes the 'infinite calls to rt2x00mc_configure_filter'
bug reported by Bas Hulsken.
Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch replaces static variable from send_cmd_sync
with flag in priv->status. It was used for reentrance protection
but clearly made it impossible to stuck more cards into the same machine

In addition it force check of return values of synchronous commands
commands that doesn't requires return value async commands have to be used
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NYi Zhu <yi.zhu@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch initialize all fields in led before registering it
This fixes oops on initialization
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch fixes an early release of driver's resources before upper stack
was notified that low-level driver shuts down.
Signed-off-by: NRon Rindjunsky <ron.rindjunsky@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Having rate registration during module load enables the use of
error checking as well as reliable registration/unregistration
pairing. Previously this was not possible as rate registration
was done during _probe where _probe could be run for more than
one device on the system.
Signed-off-by: NReinette Chatre <reinette.chatre@intel.com>
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>