| Age | Commit message (Collapse) | Author |
|---|
|
bug introduced with cea194d90b11aff7fc289149e4c7f305fad3535a
In the current TT code, when a TT_Response containing a full table is received
from an originator, first the node purges all the clients for that originator in
the global translation-table and then merges the newly received table.
During the purging phase each client deletion is done by means of a call_rcu()
invocation and at the end of this phase the global entry counter for that
originator is set to 0. However the invoked rcu function decreases the global
entry counter for that originator by one too and since the rcu invocation is
likely to be postponed, the node will end up in first setting the counter to 0
and then decreasing it one by one for each deleted client.
This bug leads to having a wrong global entry counter for the related node, say
X. Then when the node with the broken counter will answer to a TT_REQUEST on
behalf of node X, it will create faulty TT_RESPONSE that will generate an
unrecoverable situation on the node that asked for the full table recover.
The non-recoverability is given by the fact that the node with the broken
counter will keep answering on behalf of X because its knowledge about X's state
(ttvn + tt_crc) is correct.
To solve this problem the counter is not explicitly set to 0 anymore and the
counter decrement is performed right before the invocation of call_rcu().
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
|
|
bug introduced with 59b699cdee039d75915c354da06937102d1f9a84
If the source or destination mac address of an ethernet packet
could not be found in the translation table the packet was
dropped if AP isolation was turned on. This behavior would
make it impossible to send broadcast packets over the mesh as
the broadcast address will never enter the translation table.
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
Acked-by: Antonio Quartulli <ordex@autistici.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
skb_linearize(skb) possibly rearranges the skb internal data and then changes
the skb->data pointer value. For this reason any other pointer in the code that
was assigned skb->data before invoking skb_linearise(skb) must be re-assigned.
In the current tt_query message handling code this is not done and therefore, in
case of skb linearization, the pointer used to handle the packet header ends up
in pointing to free'd memory.
This bug was introduced by a73105b8d4c765d9ebfb664d0a66802127d8e4c7
(batman-adv: improved client announcement mechanism)
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
|
|
net/sctp/protocol.c: In function ‘sctp_addr_wq_timeout_handler’:
net/sctp/protocol.c:676: warning: label ‘free_next’ defined but not used
Signed-off-by: Daniel Halperin <dhalperi@cs.washington.edu>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
/proc/net/ipv6_route reflects the contents of fib_table_hash. The proc
handler is installed in ip6_route_net_init() whereas fib_table_hash is
allocated in fib6_net_init() _after_ the proc handler has been installed.
This opens up a short time frame to access fib_table_hash with its pants
down.
Move the registration of the proc files to a later point in the init
order to avoid the race.
Tested :-)
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Cc: Sakari Ailus <sakari.ailus@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
/proc/net/ipv6_route"
This reverts commit 2a0c451ade8e1783c5d453948289e4a978d417c9.
It causes crashes, because now ip6_null_entry is used before
it is initialized.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
/proc/net/ipv6_route reflects the contents of fib_table_hash. The proc
handler is installed in ip6_route_net_init() whereas fib_table_hash is
allocated in fib6_net_init() _after_ the proc handler has been installed.
This opens up a short time frame to access fib_table_hash with its pants
down.
fib6_init() as a whole can't be moved to an earlier position as it also
registers the rtnetlink message handlers which should be registered at
the end. Therefore split it into fib6_init() which is run early and
fib6_init_late() to register the rtnetlink message handlers.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Orphaning skb in dev_hard_start_xmit() makes bonding behavior
unfriendly for applications sending big UDP bursts : Once packets
pass the bonding device and come to real device, they might hit a full
qdisc and be dropped. Without orphaning, the sender is automatically
throttled because sk->sk_wmemalloc reaches sk->sk_sndbuf (assuming
sk_sndbuf is not too big)
We could try to defer the orphaning adding another test in
dev_hard_start_xmit(), but all this seems of little gain,
now that BQL tends to make packets more likely to be parked
in Qdisc queues instead of NIC TX ring, in cases where performance
matters.
Reverts commits :
fc6055a5ba31 net: Introduce skb_orphan_try()
87fd308cfc6b net: skb_tx_hash() fix relative to skb_orphan_try()
and removes SKBTX_DRV_NEEDS_SK_REF flag
Reported-and-bisected-by: Jean-Michel Hautbois <jhautbois@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Oliver Hartkopp <socketcan@hartkopp.net>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
HCI_Disconnect should only be sent after connection is established.
If connection is not yet established and HCI_Disconnect is called
then disconnection complete will be received with a handle which
does not exist and hence this event will be ignored.
But as mgmt.c will not receive this event, its variable for pending
command is not cleared.This will result in future Disconnect commands
for that BD Address to be blocked with error busy.
Signed-off-by: Vishal Agarwal <vishal.agarwal@stericsson.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
Bogdan Hamciuc diagnosed and fixed following bug in netpoll_send_udp() :
"skb->len += len;" instead of "skb_put(skb, len);"
Meaning that _if_ a network driver needs to call skb_realloc_headroom(),
only packet headers would be copied, leaving garbage in the payload.
However the skb_realloc_headroom() must be avoided as much as possible
since it requires memory and netpoll tries hard to work even if memory
is exhausted (using a pool of preallocated skbs)
It appears netpoll_send_udp() reserved 16 bytes for the ethernet header,
which happens to work for typicall drivers but not all.
Right thing is to use LL_RESERVED_SPACE(dev)
(And also add dev->needed_tailroom of tailroom)
This patch combines both fixes.
Many thanks to Bogdan for raising this issue.
Reported-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Tested-by: Bogdan Hamciuc <bogdan.hamciuc@freescale.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Neil Horman <nhorman@tuxdriver.com>
Reviewed-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211
|
|
Stop connection monitor poll during disassociation.
This clears the polling flags and if a scan was
deferred it will be run.
Without this fix, if a scan was deferred due to
connection monitoring while disassociation happens,
this scan blocks further scan requests until interface
down/up which causes problems connecting to another AP.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Otherwise, we might call the driver callback before
the interface was uploaded.
Solves the following warning:
WARNING: at net/mac80211/driver-ops.h:12 ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]()
wlan0: Failed check-sdata-in-driver check, flags: 0x0
Modules linked in: wlcore_sdio wl12xx wl18xx wlcore mac80211 cfg80211 [last unloaded: cfg80211]
[<c001b964>] (unwind_backtrace+0x0/0x12c) from [<c0495550>] (dump_stack+0x20/0x24)
[<c0495550>] (dump_stack+0x20/0x24) from [<c003ee28>] (warn_slowpath_common+0x5c/0x74)
[<c003ee28>] (warn_slowpath_common+0x5c/0x74) from [<c003eefc>] (warn_slowpath_fmt+0x40/0x48)
[<c003eefc>] (warn_slowpath_fmt+0x40/0x48) from [<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211])
[<bf5c1ad0>] (ieee80211_set_bitrate_mask+0xbc/0x18c [mac80211]) from [<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211])
[<bf575960>] (nl80211_set_tx_bitrate_mask+0x350/0x358 [cfg80211]) from [<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8)
[<c03e9e94>] (genl_rcv_msg+0x1a8/0x1e8) from [<c03e9164>] (netlink_rcv_skb+0x5c/0xc0)
[<c03e9164>] (netlink_rcv_skb+0x5c/0xc0) from [<c03e9ce0>] (genl_rcv+0x28/0x34)
[<c03e9ce0>] (genl_rcv+0x28/0x34) from [<c03e8e74>] (netlink_unicast+0x158/0x234)
[<c03e8e74>] (netlink_unicast+0x158/0x234) from [<c03e93e0>] (netlink_sendmsg+0x218/0x298)
[<c03e93e0>] (netlink_sendmsg+0x218/0x298) from [<c03b4e5c>] (sock_sendmsg+0xa4/0xc0)
[<c03b4e5c>] (sock_sendmsg+0xa4/0xc0) from [<c03b5af4>] (__sys_sendmsg+0x1d8/0x254)
[<c03b5af4>] (__sys_sendmsg+0x1d8/0x254) from [<c03b5ca8>] (sys_sendmsg+0x4c/0x70)
[<c03b5ca8>] (sys_sendmsg+0x4c/0x70) from [<c0013980>] (ret_fast_syscall+0x0/0x3c)
Note that calling the driver can also result
in undefined behaviour since it doesn't have
to deal with calls while down.
Signed-off-by: Eliad Peller <eliad@wizery.com>
[removed timestamps, added note - Johannes]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
reg_timeout_work() calls restore_regulatory_settings() which
takes cfg80211_mutex.
reg_set_request_processed() already holds cfg80211_mutex
before calling cancel_delayed_work_sync(reg_timeout),
so it might deadlock.
Call the async cancel_delayed_work instead, in order
to avoid the potential deadlock.
This is the relevant lockdep warning:
cfg80211: Calling CRDA for country: XX
======================================================
[ INFO: possible circular locking dependency detected ]
3.4.0-rc5-wl+ #26 Not tainted
-------------------------------------------------------
kworker/0:2/1391 is trying to acquire lock:
(cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
but task is already holding lock:
((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 ((reg_timeout).work){+.+...}:
[<c008fd44>] validate_chain+0xb94/0x10f0
[<c0090b68>] __lock_acquire+0x8c8/0x9b0
[<c0090d40>] lock_acquire+0xf0/0x114
[<c005b600>] wait_on_work+0x4c/0x154
[<c005c000>] __cancel_work_timer+0xd4/0x11c
[<c005c064>] cancel_delayed_work_sync+0x1c/0x20
[<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
[<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
[<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
[<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
[<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
[<c03c7584>] genl_rcv+0x28/0x34
[<c03c6720>] netlink_unicast+0x15c/0x228
[<c03c6c7c>] netlink_sendmsg+0x218/0x298
[<c03933c8>] sock_sendmsg+0xa4/0xc0
[<c039406c>] __sys_sendmsg+0x1e4/0x268
[<c0394228>] sys_sendmsg+0x4c/0x70
[<c0013840>] ret_fast_syscall+0x0/0x3c
-> #1 (reg_mutex){+.+.+.}:
[<c008fd44>] validate_chain+0xb94/0x10f0
[<c0090b68>] __lock_acquire+0x8c8/0x9b0
[<c0090d40>] lock_acquire+0xf0/0x114
[<c04734dc>] mutex_lock_nested+0x48/0x320
[<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
[<c0059f44>] process_one_work+0x2a0/0x480
[<c005a4b4>] worker_thread+0x1bc/0x2bc
[<c0061148>] kthread+0x98/0xa4
[<c0014af4>] kernel_thread_exit+0x0/0x8
-> #0 (cfg80211_mutex){+.+.+.}:
[<c008ed58>] print_circular_bug+0x68/0x2cc
[<c008fb28>] validate_chain+0x978/0x10f0
[<c0090b68>] __lock_acquire+0x8c8/0x9b0
[<c0090d40>] lock_acquire+0xf0/0x114
[<c04734dc>] mutex_lock_nested+0x48/0x320
[<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
[<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
[<c0059f44>] process_one_work+0x2a0/0x480
[<c005a4b4>] worker_thread+0x1bc/0x2bc
[<c0061148>] kthread+0x98/0xa4
[<c0014af4>] kernel_thread_exit+0x0/0x8
other info that might help us debug this:
Chain exists of:
cfg80211_mutex --> reg_mutex --> (reg_timeout).work
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock((reg_timeout).work);
lock(reg_mutex);
lock((reg_timeout).work);
lock(cfg80211_mutex);
*** DEADLOCK ***
2 locks held by kworker/0:2/1391:
#0: (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
#1: ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
stack backtrace:
[<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
[<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
[<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
[<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
[<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
[<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
[<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
[<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
[<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
[<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
[<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
[<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
cfg80211: Calling CRDA to update world regulatory domain
cfg80211: World regulatory domain updated:
cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Cc: stable@kernel.org
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
|
|
Add a few kernel-doc descriptions that were missed
during mesh development.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Ashok Nagarajan <ashok@cozybit.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
If remote device sends bogus RFC option with invalid length,
undefined options values are used. Fix this by using defaults when
remote misbehaves.
This also fixes the following warning reported by gcc 4.7.0:
net/bluetooth/l2cap_core.c: In function 'l2cap_config_rsp':
net/bluetooth/l2cap_core.c:3302:13: warning: 'rfc.max_pdu_size' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.max_pdu_size' was declared here
net/bluetooth/l2cap_core.c:3298:25: warning: 'rfc.monitor_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.monitor_timeout' was declared here
net/bluetooth/l2cap_core.c:3297:25: warning: 'rfc.retrans_timeout' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.retrans_timeout' was declared here
net/bluetooth/l2cap_core.c:3295:2: warning: 'rfc.mode' may be used uninitialized in this function [-Wmaybe-uninitialized]
net/bluetooth/l2cap_core.c:3266:24: note: 'rfc.mode' was declared here
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
|
|
Don't validate interface combinations on a stopped
interface. Otherwise we might end up being able to
create a new interface with a certain type, but
won't be able to change an existing interface
into that type.
This also skips some other functions when
interface is stopped and changing interface type.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Add a few kernel-doc descriptions that were missed
during development.
Reported-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Fix kernel-doc warnings in net/core:
Warning(net/core/skbuff.c:3368): No description found for parameter 'delta_truesize'
Warning(net/core/filter.c:628): No description found for parameter 'pfp'
Warning(net/core/filter.c:628): Excess function parameter 'sk' description in 'sk_unattached_filter_create'
Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
With LE/SMP the completion of a security level elavation from medium to
high is indicated by a HCI Encryption Key Refresh Complete event. The
necessary behavior upon receiving this event is a mix of what's done for
auth_complete and encryption_change, which is also where most of the
event handling code has been copied from.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
Commit 081b1b1bb27f (l2tp: fix l2tp_ip_sendmsg() route handling) added
a race, in case IP route cache is disabled.
In this case, we should not do the dst_release(&rt->dst), since it'll
free the dst immediately, instead of waiting a RCU grace period.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: James Chapman <jchapman@katalix.com>
Cc: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
commit 24398e39c8ee4a9d9123eed322b859ece4d16cac
Author: Johannes Berg <johannes.berg@intel.com>
Date: Wed Mar 28 10:58:36 2012 +0200
mac80211: set HT channel before association
removed IEEE80211_CONF_CHANGE_CHANNEL argument from ieee80211_hw_config,
which is required by iwl4965 driver, otherwise that driver does not
configure channel properly and is not able to associate.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
llcp_sock_getname() might get called before the LLCP socket was created.
This condition isn't checked, and llcp_sock_getname will simply deref a
NULL ptr in that case.
This exists starting with d646960 ("NFC: Initial LLCP support").
Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
If we have an unauthenticated key it is not sufficient to acheive high
security. Therefore, when deciding whether to encrypt the link or
request pairing, it is essential to in addition to checking the
existence of a key to also check whether it is authenticated or not.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
The l2cap_conn_del function tries to cancel_sync the security timer, but
when it's called from the timeout function itself a deadlock occurs.
Subsequently the "hcon->l2cap_data = NULL" that's supposed to protect
multiple calls to l2cap_conn_del never gets cleared and when the
connection finally drops we double free's etc which will crash the
kernel.
This patch fixes the issue by using the HCI_CONN_LE_SMP_PEND for
protecting against this. The same flag is also used for the same purpose
in other places in the SMP code.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
For BR/EDR pairing is assumed to be finished when connection is
done. For LE if connection is successful it did not necessarily
mean that pairing is also done but if the connection is unsuccessful
it should be assumed that pairing procedure is also finished.
This patch registers a new function with connect_cfm_cb callback for
LE link which sends the pairing complete signal to user space if
connection is unsuccessful.
Signed-off-by: Vishal Agarwal <vishal.agarwal@stericsson.com>
Acked-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
The tk_request function takes the local IO capability as the second last
parameter and the remote IO capability as the last parameter. They were
previously swapped: when we receive a pairing response
req->io_capability contains the local one and rsp->io_capability the
remote one.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
RFC 4293 defines ipIfStatsOutOctets (similar definition for
ipSystemStatsOutOctets):
The total number of octets in IP datagrams delivered to the lower
layers for transmission. Octets from datagrams counted in
ipIfStatsOutTransmits MUST be counted here.
And ipIfStatsOutTransmits:
The total number of IP datagrams that this entity supplied to the
lower layers for transmission. This includes datagrams generated
locally and those forwarded by this entity.
Therefore, IPSTATS_MIB_OUTOCTETS must be incremented when incrementing
IPSTATS_MIB_OUTFORWDATAGRAMS.
IP_UPD_PO_STATS is not used since ipIfStatsOutRequests must not
include forwarded datagrams:
The total number of IP datagrams that local IP user-protocols
(including ICMP) supplied to IP in requests for transmission. Note
that this counter does not include any datagrams counted in
ipIfStatsOutForwDatagrams.
Signed-off-by: Vincent Bernat <bernat@luffy.cx>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
I accidentally triggered this printk, which amused me for a few moments.
Given we're post 2.2, we could just -EACCES, but does anyone even care about Appletalk now ?
I figure it's better to leave sleeping dogs lie, and just update the message.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit 5339ab8b1dd82 (ipv6: fib: Convert fib6_age() to
dst_neigh_lookup().) seems to have mistakenly inverted the
exception for cached NTF_ROUTER routes.
Signed-off-by: Thomas Graf <tgraf@suug.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Denys found out "ip neigh" output was truncated to
about 54 neighbours.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We must prevent module unloading if some devices are still attached to
l2tp_eth driver.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Denys Fedoryshchenko <denys@visp.net.lb>
Tested-by: Denys Fedoryshchenko <denys@visp.net.lb>
Cc: James Chapman <jchapman@katalix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The nat_rtp_rtcp hook takes two separate parameters port and rtp_port.
port is expected to be the real h245 address (found inside the packet).
rtp_port is the even number closest to port (RTP ports are even and
RTCP ports are odd).
However currently, both port and rtp_port are having same value (both are
rounded to nearest even numbers).
This works well in case of openlogicalchannel with media (RTP/even) port.
But in case of openlogicalchannel for media control (RTCP/odd) port,
h245 address in the packet is wrongly modified to have an even port.
I am attaching a pcap demonstrating the problem, for any further analysis.
This behavior was introduced around v2.6.19 while rewriting the helper.
Signed-off-by: Jagdish Motwani <jagdish.motwani@elitecore.com>
Signed-off-by: Sanket Shah <sanket.shah@elitecore.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
This patch addresses two issues:
a) Fix usage of u32 and __be32 that causes endianess warnings via sparse.
b) Ensure consistent hashing in a cluster that is composed of big and
little endian systems. Thus, we obtain the same hash mark in an
heterogeneous cluster.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Schillstrom <hans@schillstrom.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
John Linville says:
====================
Amitkumar Karwar gives us a cfg80211 fix that changes some state
tracking in order to avoid a WARNING.
Arik Nemtsov provide a mac80211 fix for an RCU-related race.
Avinash Patil shares a pair of mwifiex fixes, one which invalidates
some stale configuration data before a channel change and another to
restrict hidden SSID support to zero-length SSIDs only.
Chun-Yeow Yeoh brings a mac80211 fix for a mesh problem triggered
when combining multiple mesh networks into one.
Felix Fietkau provides a mac80211 lockdep fix.
Joe Perches fixes a couple of thinkos related to bitwise operations.
Johannes Berg comes through with a flurry of fixes. The iwlwifi ones
address a problem Linus recently reported, and some of the fallout
discovered while fixing it. The mac80211 fix properly cleans-up
remain-on-channel work on an interface that is stopped. The others
are clean-ups for regressions caused by stricter checking of possible
virtual interfaces supported by wireless drivers.
Meenakshi Venkataraman provides a mac80211 fix for an off-by-one error.
Seth Forshee provides a fix to make the wireless adapters used in
some Mac boxes work after being in S3 power saving state.
Stanislaw Gruszka offers a copule of fixes, a fix for a mac80211
scanning regression and an rt2x00 fix to avoid some lockdep spew.
Last but not least, Vinicius Costa Gomes provides a bluetooth fix
for a typo that "was preventing important features of Bluetooth
from working".
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
|
|
commit 5faa5df1fa2024 (inetpeer: Invalidate the inetpeer tree along with
the routing cache) added a race :
Before freeing an inetpeer, we must respect a RCU grace period, and make
sure no user will attempt to increase refcnt.
inetpeer_invalidate_tree() waits for a RCU grace period before inserting
inetpeer tree into gc_list and waking the worker. At that time, no
concurrent lookup can find a inetpeer in this tree.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If a given interface combination doesn't contain
a required interface type then we missed checking
that and erroneously allowed it even though iface
type wasn't there at all. Add a check that makes
sure that all interface types are accounted for.
Cc: stable@kernel.org
Reported-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Most probably a typo, the check should have been for BT_SK_DEFER_SETUP
instead of BT_DEFER_SETUP (which right now only represents a socket
option).
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Acked-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
|
|
sta_info_cleanup locks the sta_list using rcu_read_lock however
the delete operation isn't rcu safe. A race between sta_info_cleanup
timer being called and a STA being removed can occur which leads
to a panic while traversing sta_list. Fix this by switching to the
RCU-safe versions.
Cc: stable@vger.kernel.org
Reported-by: Eyal Shapira <eyal@wizery.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Using | with a constant is always true.
Likely this should have be &.
cc: Ben Greear <greearb@candelatech.com>
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Fixes a lockdep warning:
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
net/mac80211/agg-rx.c:148 invoked rcu_dereference_check() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
1 lock held by arecord/11226:
#0: (&tid_agg_rx->session_timer){+.-...}, at: [<ffffffff81066bb0>] call_timer_fn+0x0/0x360
stack backtrace:
Pid: 11226, comm: arecord Not tainted 3.1.0-kml #16
Call Trace:
<IRQ> [<ffffffff81093454>] lockdep_rcu_dereference+0xa4/0xc0
[<ffffffffa02778c9>] sta_rx_agg_session_timer_expired+0xc9/0x110 [mac80211]
[<ffffffffa0277800>] ? ieee80211_process_addba_resp+0x220/0x220 [mac80211]
[<ffffffff81066c3a>] call_timer_fn+0x8a/0x360
[<ffffffff81066bb0>] ? init_timer_deferrable_key+0x30/0x30
[<ffffffff81477bb0>] ? _raw_spin_unlock_irq+0x30/0x70
[<ffffffff81067049>] run_timer_softirq+0x139/0x310
[<ffffffff81091d5e>] ? put_lock_stats.isra.25+0xe/0x40
[<ffffffff810922ac>] ? lock_release_holdtime.part.26+0xdc/0x160
[<ffffffffa0277800>] ? ieee80211_process_addba_resp+0x220/0x220 [mac80211]
[<ffffffff8105cb78>] __do_softirq+0xc8/0x3c0
[<ffffffff8108f088>] ? tick_dev_program_event+0x48/0x110
[<ffffffff8108f16f>] ? tick_program_event+0x1f/0x30
[<ffffffff81153b15>] ? putname+0x35/0x50
[<ffffffff8147a43c>] call_softirq+0x1c/0x30
[<ffffffff81004c55>] do_softirq+0xa5/0xe0
[<ffffffff8105d1ee>] irq_exit+0xae/0xe0
[<ffffffff8147ac6b>] smp_apic_timer_interrupt+0x6b/0x98
[<ffffffff81479ab3>] apic_timer_interrupt+0x73/0x80
<EOI> [<ffffffff8146aac6>] ? free_debug_processing+0x1a1/0x1d5
[<ffffffff81153b15>] ? putname+0x35/0x50
[<ffffffff8146ab2b>] __slab_free+0x31/0x2ca
[<ffffffff81477c3a>] ? _raw_spin_unlock_irqrestore+0x4a/0x90
[<ffffffff81253b8f>] ? __debug_check_no_obj_freed+0x15f/0x210
[<ffffffff81097054>] ? lock_release_nested+0x84/0xc0
[<ffffffff8113ec55>] ? kmem_cache_free+0x105/0x250
[<ffffffff81153b15>] ? putname+0x35/0x50
[<ffffffff81153b15>] ? putname+0x35/0x50
[<ffffffff8113ed8f>] kmem_cache_free+0x23f/0x250
[<ffffffff81153b15>] putname+0x35/0x50
[<ffffffff81146d8d>] do_sys_open+0x16d/0x1d0
[<ffffffff81146e10>] sys_open+0x20/0x30
[<ffffffff81478f42>] system_call_fastpath+0x16/0x1b
Reported-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
