| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-next-2.6
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
different interfaces
If overlapping networks with different interfaces was added to
the set, the type did not handle it properly. Example
ipset create test hash:net,iface
ipset add test 192.168.0.0/16,eth0
ipset add test 192.168.0.0/24,eth1
Now, if a packet was sent from 192.168.0.0/24,eth0, the type returned
a match.
In the patch the algorithm is fixed in order to correctly handle
overlapping networks.
Limitation: the same network cannot be stored with more than 64 different
interfaces in a single set.
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Introduces a new nfnetlink type that applies a given
verdict to all queued packets with an id <= the id in the verdict
message.
If a mark is provided it is applied to all matched packets.
This reduces the number of verdicts that have to be sent.
Applications that make use of this feature need to maintain
a timeout to send a batchverdict periodically to avoid starvation.
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Packet identifier is currently setup in nfqnl_build_packet_message(),
using one atomic_inc_return().
Problem is that since several cpus might concurrently call
nfqnl_enqueue_packet() for the same queue, we can deliver packets to
consumer in non monotonic way (packet N+1 being delivered after packet
N)
This patch moves the packet id setup from nfqnl_build_packet_message()
to nfqnl_enqueue_packet() to guarantee correct delivery order.
This also removes one atomic operation.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Florian Westphal <fw@strlen.de>
CC: Pablo Neira Ayuso <pablo@netfilter.org>
CC: Eric Leblond <eric@regit.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
nenetlink_queue operations on SMP are not efficent if several queues are
used, because of nfnl_mutex contention when applications give packet
verdict.
Use new call_rcu field in struct nfnl_callback to advertize a callback
that is called under rcu_read_lock instead of nfnl_mutex.
On my 2x4x2 machine, I was able to reach 2.000.000 pps going through
user land returning NF_ACCEPT verdicts without losses, instead of less
than 500.000 pps before patch.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Florian Westphal <fw@strlen.de>
CC: Eric Leblond <eric@regit.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Goal of this patch is to permit nfnetlink providers not mandate
nfnl_mutex being held while nfnetlink_rcv_msg() calls them.
If struct nfnl_callback contains a non NULL call_rcu(), then
nfnetlink_rcv_msg() will use it instead of call() field, holding
rcu_read_lock instead of nfnl_mutex
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Florian Westphal <fw@strlen.de>
CC: Eric Leblond <eric@regit.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In this revision the conversion of secid to SELinux context and adding it
to the audit log is moved from xt_AUDIT.c to audit.c with the aid of a
separate helper function - audit_log_secctx - which does both the conversion
and logging of SELinux context, thus also preventing internal secid number
being leaked to userspace. If conversion is not successful an error is raised.
With the introduction of this helper function the work done in xt_AUDIT.c is
much more simplified. It also opens the possibility of this helper function
being used by other modules (including auditd itself), if desired. With this
addition, typical (raw auditd) output after applying the patch would be:
type=NETFILTER_PKT msg=audit(1305852240.082:31012): action=0 hook=1 len=52 inif=? outif=eth0 saddr=10.1.1.7 daddr=10.1.2.1 ipid=16312 proto=6 sport=56150 dport=22 obj=system_u:object_r:ssh_client_packet_t:s0
type=NETFILTER_PKT msg=audit(1306772064.079:56): action=0 hook=3 len=48 inif=eth0 outif=? smac=00:05:5d:7c:27:0b dmac=00:02:b3:0a:7f:81 macproto=0x0800 saddr=10.1.2.1 daddr=10.1.1.7 ipid=462 proto=6 sport=22 dport=3561 obj=system_u:object_r:ssh_server_packet_t:s0
Acked-by: Eric Paris <eparis@redhat.com>
Signed-off-by: Mr Dash Four <mr.dash.four@googlemail.com>
Signed-off-by: Patrick McHardy <kaber@trash.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Compiler is not smart enough to avoid double BSWAP instructions in
ntohl(inet_make_mask(plen)).
Lets cache this value in struct leaf_info, (fill a hole on 64bit arches)
With route cache disabled, this saves ~2% of cpu in udpflood bench on
x86_64 machine.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| |
| |
| | |
In the future dst entries will be neigh-less. In that environment we
need to have an easy transition point for current users of
dst->neighbour outside of the packet output fast path.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| | |
dst_{get,set}_neighbour()
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| |
| | |
It just makes it harder to see 1) what the code is doing
and 2) grep for all users of dst{->,.}neighbour
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This will get us closer to being able to do "neigh stuff"
completely independent of the underlying dst_entry for
protocols (ipv4/ipv6) that wish to do so.
We will also be able to make dst entries neigh-less.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
there is only one user of vlan_find_dev outside of the actual vlan code:
qlcnic uses it to iterate over some VLANs it knows.
let's just make vlan_find_dev private to the VLAN code and have the
iteration in qlcnic be a bit more direct. (a few rcu dereferences less
too)
Signed-off-by: David Lamparter <equinox@diac24.net>
Cc: Patrick McHardy <kaber@trash.net>
Cc: Amit Kumar Salecha <amit.salecha@qlogic.com>
Cc: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
Cc: linux-driver@qlogic.com
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| | |
It is always dev_queue_xmit().
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| |
| |
| | |
It's just taking on one of two possible values, either
neigh_ops->output or dev_queue_xmit(). And this is purely depending
upon whether nud_state has NUD_CONNECTED set or not.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| | |
It's always dev_queue_xmit().
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that hh_cache entries are embedded inside of neighbour
entries, their lifetimes and accesses are now synchronous
to that of the encompassing neighbour object.
Therefore we don't need to hook up the blackhole op to
hh_output on destroy.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| | |
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| | |
Signed-off-by: David S. Miller <davem@davemloft.net>
|
| |
| |
| |
| | |
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|\ \
| | |
| | |
| | | |
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6 into for-davem
Conflicts:
net/bluetooth/l2cap_core.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In WoWLAN, devices may use crypto keys for TX/RX
and could also implement GTK rekeying. If the
driver isn't able to retrieve replay counters and
similar information from the device upon resume,
or if the device isn't responsive due to platform
issues, it isn't safe to keep the connection up
as GTK rekey messages from during the sleep time
could be replayed against it.
The only protection against that is disconnecting
from the AP. Modifying mac80211 to do that while
it is resuming would be very complex and invasive
in the case that the driver requires a reconfig,
so do it after it has resumed completely. In that
case, however, packets might be replayed since it
can then only happen after TX/RX are up again, so
mark keys for interfaces that need to disconnect
as "tainted" and drop all packets that are sent
or received with those keys.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
is_valid_ether_addr itself checks for is_zero_ether_addr
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We don't have multiple RX queues, so there's no use
in allocating multiple, use alloc_netdev_mqs() to
allocate multiple TX but only one RX queue.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
mac80211 maintains a running average of the RSSI when a STA
is associated to an AP. Report threshold events to any driver
that has registered callbacks for getting RSSI measurements.
Implement callbacks in mac80211 so that driver can set thresholds.
Add callbacks in mac80211 which is invoked when an RSSI threshold
event occurs.
mac80211: add tracing to rssi_reports api and remove extraneous fn argument
mac80211: scale up rssi thresholds from driver by 16 before storing
Signed-off-by: Meenakshi Venkataraman <meenakshi.venkataraman@intel.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
| | |\ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
master.kernel.org:/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6
Conflicts:
net/bluetooth/l2cap_core.c
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There can 3 reasons for the "command reject" reply produced
by the stack. Each such reply should be accompanied by the
relevand data ( as defined in spec. ). Currently there is one
instance of "command reject" reply with reason "invalid cid"
wich is fixed. Also, added clean-up definitions related to the
"command reject" replies.
Signed-off-by: Ilia Kolomisnky <iliak@ti.com>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will be useful when userspace wants to restrict some kinds of
operations based on the length of the key size used to encrypt the
link.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
In some cases it will be useful having the key size used for
encrypting the link. For example, some profiles may restrict
some operations depending on the key length.
The key size is stored in the key that is passed to userspace
using the pin_length field in the key structure.
For now this field is only valid for LE controllers. 3.0+HS
controllers define the Read Encryption Key Size command, this
field is intended for storing the value returned by that
command.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As the key format has changed to something that has a dynamic size,
the way that keys are received and sent must be changed.
The structure fields order is changed to make the parsing of the
information received from the Management Interface easier.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now that it's possible that the exchanged key is present in
the link key list, we may be able to estabilish security with
an already existing key, without need to perform any SMP
procedure.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
With this we can use only one place to store all keys, without
need to use a field in the connection structure for this
purpose.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now when the LTK is received from the remote or generated it is stored,
so it can later be used.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Before implementing SM key distribution, the pairing features
exchange must be better negotiated, taking into account some
features of the host and connection requirements.
If we are in the "not pairable" state, it makes no sense to
exchange any key. This allows for simplification of the key
negociation method.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Now that we have methods to finding keys by its parameters we can
reject an encryption request if the key isn't found.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
As the LTK (the new type of key being handled now) has more data
associated with it, we need to store this extra data and retrieve
the keys based on that data.
Methods for searching for a key and for adding a new LTK are
introduced here.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This adds support for generating and distributing all the keys
specified in the third phase of SMP.
This will make possible to re-establish secure connections, resolve
private addresses and sign commands.
For now, the values generated are random.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The ERTM receive buffer is now handled in a way that does not require
the busy queue and the associated polling code.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This change moves most L2CAP ERTM receive buffer handling out of the
L2CAP core and in to the socket code. It's up to the higher layer
(the socket code, in this case) to tell the core when its buffer is
full or has space available. The recv op should always accept
incoming ERTM data or else the connection will go down.
Within the socket layer, an skb that does not fit in the socket
receive buffer will be temporarily stored. When the socket is read
from, that skb will be placed in the receive buffer if possible. Once
adequate buffer space becomes available, the L2CAP core is informed
and the ERTM local busy state is cleared.
Receive buffer management for non-ERTM modes is unchanged.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The local busy state is entered and exited based on buffer status in
the socket layer (or other upper layer). This change is in
preparation for general buffer status reports from the socket layer,
which will then be used to change the local busy status.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
All threads running in process context should disable local bottom
halve before locking hdev->lock.
This patch fix the following message generated when Bluetooh module
is loaded with enable_mgmt=y (CONFIG_PROVE_LOCKING enabled).
[ 107.880781] =================================
[ 107.881631] [ INFO: inconsistent lock state ]
[ 107.881631] 2.6.39+ #1
[ 107.881631] ---------------------------------
[ 107.881631] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 107.881631] rcuc0/7 [HC0[0]:SC1[3]:HE1:SE0] takes:
[ 107.881631] (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] {SOFTIRQ-ON-W} state was registered at:
[ 107.881631] [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[ 107.881631] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 107.881631] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[ 107.881631] [<ffffffffa0011cc2>] mgmt_control+0xd4d/0x175b [bluetooth]
[ 107.881631] [<ffffffffa0013275>] hci_sock_sendmsg+0x97/0x293 [bluetooth]
[ 107.881631] [<ffffffff8121940c>] sock_aio_write+0x126/0x13a
[ 107.881631] [<ffffffff810a35fa>] do_sync_write+0xba/0xfa
[ 107.881631] [<ffffffff810a3beb>] vfs_write+0xaa/0xca
[ 107.881631] [<ffffffff810a3d80>] sys_write+0x45/0x69
[ 107.881631] [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[ 107.881631] irq event stamp: 2100876
[ 107.881631] hardirqs last enabled at (2100876): [<ffffffff812b40d4>] restore_args+0x0/0x30
[ 107.881631] hardirqs last disabled at (2100875): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[ 107.881631] softirqs last enabled at (2100862): [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] softirqs last disabled at (2100863): [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[ 107.881631]
[ 107.881631] other info that might help us debug this:
[ 107.881631] Possible unsafe locking scenario:
[ 107.881631]
[ 107.881631] CPU0
[ 107.881631] ----
[ 107.881631] lock(&(&hdev->lock)->rlock);
[ 107.881631] <Interrupt>
[ 107.881631] lock(&(&hdev->lock)->rlock);
[ 107.881631]
[ 107.881631] *** DEADLOCK ***
[ 107.881631]
[ 107.881631] 1 lock held by rcuc0/7:
[ 107.881631] #0: (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[ 107.881631]
[ 107.881631] stack backtrace:
[ 107.881631] Pid: 7, comm: rcuc0 Not tainted 2.6.39+ #1
[ 107.881631] Call Trace:
[ 107.881631] <IRQ> [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[ 107.881631] [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[ 107.881631] [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[ 107.881631] [<ffffffff810504bb>] mark_lock+0x106/0x258
[ 107.881631] [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[ 107.881631] [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[ 107.881631] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 107.881631] [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [<ffffffff81052615>] ? lock_release+0x16c/0x179
[ 107.881631] [<ffffffff812b3952>] _raw_spin_lock_bh+0x31/0x40
[ 107.881631] [<ffffffffa0012c8d>] ? mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [<ffffffffa0012c8d>] mgmt_set_local_name_complete+0x84/0x10b [bluetooth]
[ 107.881631] [<ffffffffa000d3fe>] hci_event_packet+0x122b/0x3e12 [bluetooth]
[ 107.881631] [<ffffffff81050658>] ? mark_held_locks+0x4b/0x6d
[ 107.881631] [<ffffffff812b3cff>] ? _raw_spin_unlock_irqrestore+0x40/0x4d
[ 107.881631] [<ffffffff810507b9>] ? trace_hardirqs_on_caller+0x13f/0x172
[ 107.881631] [<ffffffff812b3d07>] ? _raw_spin_unlock_irqrestore+0x48/0x4d
[ 107.881631] [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[ 107.881631] [<ffffffff8102f836>] ? __local_bh_enable+0x90/0xa4
[ 107.881631] [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[ 107.881631] [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[ 107.881631] [<ffffffff812b56bc>] call_softirq+0x1c/0x26
[ 107.881631] <EOI> [<ffffffff810033b8>] ? do_softirq+0x46/0x9a
[ 107.881631] [<ffffffff8106a805>] ? rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] [<ffffffff8102f906>] _local_bh_enable_ip+0xac/0xc9
[ 107.881631] [<ffffffff8102f93b>] local_bh_enable+0xd/0xf
[ 107.881631] [<ffffffff8106a805>] rcu_cpu_kthread+0x2b5/0x2e2
[ 107.881631] [<ffffffff81041586>] ? __init_waitqueue_head+0x46/0x46
[ 107.881631] [<ffffffff8106a550>] ? rcu_yield.constprop.42+0x98/0x98
[ 107.881631] [<ffffffff81040f0a>] kthread+0x7f/0x87
[ 107.881631] [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[ 107.881631] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[ 107.881631] [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[ 107.881631] [<ffffffff812b55c0>] ? gs_change+0x13/0x13
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since hdev->lock may be acquired by threads runnning in interrupt
context, all threads running in process context should disable
local bottom halve before locking hdev->lock. This can be done by
using hci_dev_lock_bh macro.
This way, we avoid potencial deadlocks like this one reported by
CONFIG_PROVE_LOCKING=y.
[ 304.788780] =================================
[ 304.789686] [ INFO: inconsistent lock state ]
[ 304.789686] 2.6.39+ #1
[ 304.789686] ---------------------------------
[ 304.789686] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
[ 304.789686] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
[ 304.789686] (&(&hdev->lock)->rlock){+.?...}, at: [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] {SOFTIRQ-ON-W} state was registered at:
[ 304.789686] [<ffffffff8105188b>] __lock_acquire+0x347/0xd52
[ 304.789686] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 304.789686] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[ 304.789686] [<ffffffffa0009cf0>] hci_blacklist_del+0x1f/0x8a [bluetooth]
[ 304.789686] [<ffffffffa00139fd>] hci_sock_ioctl+0x2d9/0x314 [bluetooth]
[ 304.789686] [<ffffffff812197d8>] sock_ioctl+0x1f2/0x214
[ 304.789686] [<ffffffff810b0fd6>] do_vfs_ioctl+0x46c/0x4ad
[ 304.789686] [<ffffffff810b1059>] sys_ioctl+0x42/0x65
[ 304.789686] [<ffffffff812b4892>] system_call_fastpath+0x16/0x1b
[ 304.789686] irq event stamp: 9768
[ 304.789686] hardirqs last enabled at (9768): [<ffffffff812b40d4>] restore_args+0x0/0x30
[ 304.789686] hardirqs last disabled at (9767): [<ffffffff812b3f6a>] save_args+0x6a/0x70
[ 304.789686] softirqs last enabled at (9726): [<ffffffff8102fa9b>] __do_softirq+0x129/0x13f
[ 304.789686] softirqs last disabled at (9739): [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[ 304.789686]
[ 304.789686] other info that might help us debug this:
[ 304.789686] Possible unsafe locking scenario:
[ 304.789686]
[ 304.789686] CPU0
[ 304.789686] ----
[ 304.789686] lock(&(&hdev->lock)->rlock);
[ 304.789686] <Interrupt>
[ 304.789686] lock(&(&hdev->lock)->rlock);
[ 304.789686]
[ 304.789686] *** DEADLOCK ***
[ 304.789686]
[ 304.789686] 1 lock held by ksoftirqd/0/3:
[ 304.789686] #0: (hci_task_lock){++.-..}, at: [<ffffffffa0008353>] hci_rx_task+0x49/0x2f3 [bluetooth]
[ 304.789686]
[ 304.789686] stack backtrace:
[ 304.789686] Pid: 3, comm: ksoftirqd/0 Not tainted 2.6.39+ #1
[ 304.789686] Call Trace:
[ 304.789686] [<ffffffff812ae901>] print_usage_bug+0x1e7/0x1f8
[ 304.789686] [<ffffffff8100a796>] ? save_stack_trace+0x27/0x44
[ 304.789686] [<ffffffff8104fc3f>] ? print_irq_inversion_bug.part.26+0x19a/0x19a
[ 304.789686] [<ffffffff810504bb>] mark_lock+0x106/0x258
[ 304.789686] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[ 304.789686] [<ffffffff81051817>] __lock_acquire+0x2d3/0xd52
[ 304.789686] [<ffffffff8102be73>] ? vprintk+0x3ab/0x3d7
[ 304.789686] [<ffffffff812ae126>] ? printk+0x3c/0x3e
[ 304.789686] [<ffffffff810526ac>] lock_acquire+0x8a/0xa7
[ 304.789686] [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [<ffffffff811601c6>] ? __dynamic_pr_debug+0x10c/0x11a
[ 304.789686] [<ffffffff812b3758>] _raw_spin_lock+0x2c/0x3b
[ 304.789686] [<ffffffffa000bbfe>] ? hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [<ffffffffa000bbfe>] hci_conn_check_pending+0x38/0x76 [bluetooth]
[ 304.789686] [<ffffffffa000c561>] hci_event_packet+0x38e/0x3e12 [bluetooth]
[ 304.789686] [<ffffffff81052615>] ? lock_release+0x16c/0x179
[ 304.789686] [<ffffffff812b3b41>] ? _raw_read_unlock+0x23/0x27
[ 304.789686] [<ffffffffa0013e7f>] ? hci_send_to_sock+0x179/0x188 [bluetooth]
[ 304.789686] [<ffffffffa00083d2>] hci_rx_task+0xc8/0x2f3 [bluetooth]
[ 304.789686] [<ffffffff8102f5a9>] tasklet_action+0x87/0xe6
[ 304.789686] [<ffffffff8102fa11>] __do_softirq+0x9f/0x13f
[ 304.789686] [<ffffffff8102fb33>] run_ksoftirqd+0x82/0x133
[ 304.789686] [<ffffffff8102fab1>] ? __do_softirq+0x13f/0x13f
[ 304.789686] [<ffffffff81040f0a>] kthread+0x7f/0x87
[ 304.789686] [<ffffffff812b55c4>] kernel_thread_helper+0x4/0x10
[ 304.789686] [<ffffffff812b40d4>] ? retint_restore_args+0x13/0x13
[ 304.789686] [<ffffffff81040e8b>] ? __init_kthread_worker+0x53/0x53
[ 304.789686] [<ffffffff812b55c0>] ? gs_change+0x13/0x13
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The enable_smp parameter is no longer needed. It can be replaced by
checking lmp_host_le_capable.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since we have the extended LMP features properly implemented, we
should check the LMP_HOST_LE bit to know if the host supports LE.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This patch adds a new module parameter to enable/disable host LE
support. By default host LE support is disabled.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This patch adds a handler to Write LE Host Supported command complete
events. Once this commands has completed successfully, we should
read the extended LMP features and update the extfeatures field in
hci_dev.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This new field holds the extended LMP features value. Some LE
mechanism such as discovery procedure needs to read the extended
LMP features to work properly.
Signed-off-by: Andre Guedes <andre.guedes@openbossa.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Even when the received tx_seq is expected, the frame still needs to be
dropped if the TX window is exceeded or the receiver is in the local
busy state.
Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
|