Age | Commit message (Collapse) | Author | Files | Lines |
|
Removes all references to the global variable that records whether
TIPC is running in "single node" mode or "network" mode, since this
information can be easily deduced from the global variable that
records TIPC's network address. (i.e. a non-zero network address
means that TIPC is running in network mode.)
The changes made update most existing mode-based checks to use the
network address global variable. A few checks that are no longer
needed are removed entirely, along with any associated code lying on
non-executable control paths.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Removes all references to TIPC's "not running" mode, since the
removal of support for the native API means that there is no longer
any way to interact with TIPC if it has not been initialized.
The changes made consist of removing mode-based checks that are no
longer needed, along with any associated code lying on non-executable
control paths.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Restores name table translation using a non-zero domain that is
"out of scope", which was broken by an earlier commit
(5d9c54c1e9ececcf7e99c4f014f9bec7ee3a7def). Comments have now been
added to the name table translation routine to make it clear that
there are actually three possible outcomes to a translation request
(found/not found/deferred), rather than just two (found/not found).
Note that a straightforward revert of the earlier commit is not
possible, as other changes to the name table translation logic
have occurred since the incorrect optimization was made.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Optimizes processing done when contact with a neighboring node is
established to avoid recording the current state of outgoing broadcast
messages if the neighboring node isn't a valid broadcast link destination,
since this state information isn't needed for such nodes.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Eliminates a block of comments that describe how routing table updates
are to be handled. These comments no longer apply following the removal
of TIPC's prototype multi-cluster support.
Note that these changes are essentially cosmetic in nature, and have
no impact on the actual operation of TIPC.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Gets rid of two inlined routines that simply call existing sk_buff
manipulation routines, since there is no longer any extra processing
done by the helper routines.
Note that these changes are essentially cosmetic in nature, and have
no impact on the actual operation of TIPC.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Relocates information about the size of TIPC's node table index and
its associated hash function, since only node subsystem routines need
to have access to this information.
Note that these changes are essentially cosmetic in nature, and have
no impact on the actual operation of TIPC.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Simplifies a comparison operation to eliminate a useless test that
checks if an unsigned value is less than zero.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
This "shortform" is actually longer than typing out what it is really
trying to do, and just makes reading the code more difficult, so
lets simply shoot it in the head.
In the case of log.c - the comparison is on a u32, so we can drop the
check for < 0 at the same time.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Adds a new check to TIPC's name table logic to reject any attempt to
create a new name publication that is identical to an existing one.
(Such an attempt will never happen under normal circumstances, but
could arise if another network node malfunctions and issues a duplicate
name publication message.)
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Streamlines the logic that prevents an application from binding a
reserved TIPC name type to a port by moving the check to the code
that handles a socket bind() operation. This allows internal TIPC
subsystems to bind a reserved name without having to set an atomic
flag to gain permission to use such a name. (This simplification is
now possible due to the elimination of support for TIPC's native API.)
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Eliminates a check in the processing of TIPC messages arriving from
off node that ensures the message is destined for this node, since this
check duplicates an earlier check. (The check would be necessary if TIPC
needed to be able to route incoming messages to another node, but the
elimination of multi-cluster support means that this never happens and
all incoming messages are consumed by the receiving node.)
Note: This change involves the elimination of a single "if" statement
with a large "then" clause; consequently, a significant number of lines
end up getting re-indented. In addition, a simple message header access
routine that is no longer referenced is eliminated. However, the only
functional change is the elimination of the single check described above.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Utilizes the new "node signature" field in neighbor discovery messages
to ensure that all links TIPC associates with a given <Z.C.N> network
address belong to the same neighboring node. (Previously, TIPC could not
tell if link setup requests arriving on different interfaces were from
the same node or from two different nodes that has mistakenly been assigned
the same network address.)
The revised algorithm for detecting a duplicate node considers both the
node signature and the network interface adddress specified in a request
message when deciding how to respond to a link setup request. This prevents
false alarms that might otherwise arise during normal network operation
under the following scenarios:
a) A neighboring node reboots. (The node's signature changes, but the
network interface address remains unchanged.)
b) A neighboring node's network interface is replaced. (The node's signature
remains unchanged, but the network interface address changes.)
c) A neighboring node is completely replaced. (The node's signature and
network interface address both change.)
The algorithm also handles cases in which a node reboots and re-establishes
its links to TIPC (or begins re-establishing those links) before TIPC
detects that it is using a new node signature. In such cases of "delayed
rediscovery" TIPC simply accepts the new signature without disrupting
communication that is already underway over the links.
Thanks to Laser [gotolaser@gmail.com] for his contributions to the
development of this enhancement.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Adds support for the new "node signature" in neighbor discovery messages,
which is a 16 bit identifier chosen randomly when TIPC is initialized.
This field makes it possible for nodes receiving a neighbor discovery
message to detect if multiple neighboring nodes are using the same network
address (i.e. <Z.C.N>), even when the messages are arriving on different
interfaces.
This first phase of node signature support creates the signature,
incorporates it into outgoing neighbor discovery messages, and tracks
the signature used by valid neighbors. An upcoming patch builds on this
foundation to implement the improved duplicate neighbor detection checking.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
|
|
Unify return value of .ndo_set_mac_address if the given address
isn't valid. Return -EADDRNOTAVAIL as eth_mac_addr() already does
if is_valid_ether_addr() fails.
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Piergiorgio Beruto expressed the need to fetch size of first datagram in
queue for AF_UNIX sockets and suggested a patch against SIOCINQ ioctl.
I suggested instead to implement MSG_TRUNC support as a recv() input
flag, as already done for RAW, UDP & NETLINK sockets.
len = recv(fd, &byte, 1, MSG_PEEK | MSG_TRUNC);
MSG_TRUNC asks recv() to return the real length of the packet, even when
is was longer than the passed buffer.
There is risk that a userland application used MSG_TRUNC by accident
(since it had no effect on af_unix sockets) and this might break after
this patch.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
CC: Michael Kerrisk <mtk.manpages@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use eth_mac_addr() for .ndo_set_mac_address, remove
lowpan_set_address since it do currently the same as
eth_mac_addr(). Additional advantage: eth_mac_addr() already
checks if the given address is valid
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Acked-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem
|
|
The same here -- we can protect the sk_peek_off manipulations with
the unix_sk->readlock mutex.
The peeking of data from a stream socket is done in the datagram style,
i.e. even if there's enough room for more data in the user buffer, only
the head skb's data is copied in there. This feature is preserved when
peeking data from a given offset -- the data is read till the nearest
skb's boundary.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The sk_peek_off manipulations are protected with the unix_sk->readlock mutex.
This mutex is enough since all we need is to syncronize setting the offset
vs reading the queue head. The latter is fully covered with the mentioned lock.
The recently added __skb_recv_datagram's offset is used to pick the skb to
read the data from.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This one specifies where to start MSG_PEEK-ing queue data from. When
set to negative value means that MSG_PEEK works as ususally -- peeks
from the head of the queue always.
When some bytes are peeked from queue and the peeking offset is non
negative it is moved forward so that the next peek will return next
portion of data.
When non-peeking recvmsg occurs and the peeking offset is non negative
is is moved backward so that the next peek will still peek the proper
data (i.e. the one that would have been picked if there were no non
peeking recv in between).
The offset is set using per-proto opteration to let the protocol handle
the locking issues and to check whether the peeking offset feature is
supported by the protocol the socket belongs to.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This one is only considered for MSG_PEEK flag and the value pointed by
it specifies where to start peeking bytes from. If the offset happens to
point into the middle of the returned skb, the offset within this skb is
put back to this very argument.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
This makes lines shorter and simplifies further patching.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Conflicts:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c
Small minor conflict in bnx2x, wherein one commit changed how
statistics were stored in software, and another commit
fixed endianness bugs wrt. reading the values provided by
the chip in memory.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Use eth_hw_addr_random() instead of calling random_ether_addr()
to set addr_assign_type correctly to NET_ADDR_RANDOM.
Remove dev_addr in interface_setup(), it's not needed anymore.
Reset the state to NET_ADDR_PERM as soon as the MAC get
changed via .ndo_set_mac_address.
v2: use bitops, adapt to eth_hw_addr_random()
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
|
|
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
Both translation tables and network coding use timeouts to do house
keeping, so we might as well share the function used to compare a
timestamp+timeout with current time.
For readability and simplicity, the function is renamed to
has_timed_out() and uses time_is_before_jiffies() instead of
time_after().
Signed-off-by: Martin Hundebøll <martin@hundeboll.net>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
Signed-off-by: Martin Hundebøll <martin@hundeboll.net>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
Most of the values in that call are derived from the skb, so we can hand
over the skb instead.
Reported-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
All batman-adv packets have a common 3 byte header. It can be used to share
some code between different code paths, but it was never explicit stated that
this header has to be always the same for all packets. Therefore, new code
changes always have the problem that they may accidently introduce regressions
by moving some elements around.
A new structure is introduced that contains the common header and makes it
easier visible that these 3 bytes have to be the same for all on-wire packets.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
(ttvn == 0) is currently used as initial condition. However this is not a good
idea because ttvn gets the vale zero each time after reaching the maximum value
(wrap around). For this reason a new flag is added in order to define whether a
node has an initialised table or not. Moreover, after invoking
tt_global_del_orig(), tt_initialised has to be set to false
Reported-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Tested-by: Alexey Fisher <bug-track@fisher-privat.net>
Signed-off-by: Marek Lindner <lindner_marek@yahoo.de>
|
|
'tbl' is always arp_tbl, so specifying it is pointless.
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless
Conflicts:
net/mac80211/debugfs_sta.c
net/mac80211/sta_info.h
|
|
Use eth_hw_addr_random() instead of calling random_ether_addr()
to set addr_assign_type correctly to NET_ADDR_RANDOM.
Reset the state to NET_ADDR_PERM as soon as the MAC get
changed via .ndo_set_mac_address.
v2: adapt to renamed eth_hw_addr_random()
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Replace usage of random_ether_addr() with eth_hw_addr_random()
to set addr_assign_type correctly to NET_ADDR_RANDOM.
Change the trivial cases.
v2: adapt to renamed eth_hw_addr_random()
Signed-off-by: Danny Kukawka <danny.kukawka@bisect.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Most rate control implementations assume .get_rate and .tx_status are only
called once the per-station data has been fully initialized.
minstrel_ht crashes if this assumption is violated.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Tested-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
There are situations where we don't have the
necessary rate control information yet for
station entries, e.g. when associating. This
currently doesn't really happen due to the
dummy station handling; explicitly disabling
rate control when it's not initialised will
allow us to remove dummy stations.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
|
|
We need to use the _sync() version for cancelling the info and security
timer in the L2CAP connection delete path. Otherwise the delayed work
handler might run after the connection object is freed.
Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
__cancel_delayed_work() is being used in some paths where we cannot
sleep waiting for the delayed work to finish. However, that function
might return while the timer is running and the work will be queued
again. Replace the calls with safer cancel_delayed_work() version
which spins until the timer handler finishes on other CPUs and
cancels the delayed work.
Signed-off-by: Ulisses Furquim <ulisses@profusion.mobi>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
We should only perform a reset in hci_dev_do_close if the
HCI_QUIRK_NO_RESET flag is set (since in such a case a reset will not be
performed when initializing the device).
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
|
|
There is an imbalance in the rfcomm_session_hold / rfcomm_session_put
operations which causes the following crash:
[ 685.010159] BUG: unable to handle kernel paging request at 6b6b6b6b
[ 685.010169] IP: [<c149d76d>] rfcomm_process_dlcs+0x1b/0x15e
[ 685.010181] *pdpt = 000000002d665001 *pde = 0000000000000000
[ 685.010191] Oops: 0000 [#1] PREEMPT SMP
[ 685.010247]
[ 685.010255] Pid: 947, comm: krfcommd Tainted: G C 3.0.16-mid8-dirty #44
[ 685.010266] EIP: 0060:[<c149d76d>] EFLAGS: 00010246 CPU: 1
[ 685.010274] EIP is at rfcomm_process_dlcs+0x1b/0x15e
[ 685.010281] EAX: e79f551c EBX: 6b6b6b6b ECX: 00000007 EDX: e79f40b4
[ 685.010288] ESI: e79f4060 EDI: ed4e1f70 EBP: ed4e1f68 ESP: ed4e1f50
[ 685.010295] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 685.010303] Process krfcommd (pid: 947, ti=ed4e0000 task=ed43e5e0 task.ti=ed4e0000)
[ 685.010308] Stack:
[ 685.010312] ed4e1f68 c149eb53 e5925150 e79f4060 ed500000 ed4e1f70 ed4e1f80 c149ec10
[ 685.010331] 00000000 ed43e5e0 00000000 ed4e1f90 ed4e1f9c c149ec87 0000bf54 00000000
[ 685.010348] 00000000 ee03bf54 c149ec37 ed4e1fe4 c104fe01 00000000 00000000 00000000
[ 685.010367] Call Trace:
[ 685.010376] [<c149eb53>] ? rfcomm_process_rx+0x6e/0x74
[ 685.010387] [<c149ec10>] rfcomm_process_sessions+0xb7/0xde
[ 685.010398] [<c149ec87>] rfcomm_run+0x50/0x6d
[ 685.010409] [<c149ec37>] ? rfcomm_process_sessions+0xde/0xde
[ 685.010419] [<c104fe01>] kthread+0x63/0x68
[ 685.010431] [<c104fd9e>] ? __init_kthread_worker+0x42/0x42
[ 685.010442] [<c14dae82>] kernel_thread_helper+0x6/0xd
This issue has been brought up earlier here:
https://lkml.org/lkml/2011/5/21/127
The issue appears to be the rfcomm_session_put in rfcomm_recv_ua. This
operation doesn't seem be to required as for the non-initiator case we
have the rfcomm_process_rx doing an explicit put and in the initiator
case the last dlc_unlink will drive the reference counter to 0.
There have been several attempts to fix these issue:
6c2718d Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket
683d949 Bluetooth: Never deallocate a session when some DLC points to it
but AFAICS they do not fix the issue just make it harder to reproduce.
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Signed-off-by: Gopala Krishna Murala <gopala.krishna.murala@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
Since bluetooth uses multiple protocols types, to avoid lockdep
warnings, we need to use different lockdep classes (one for each
protocol type).
This is already done in bt_sock_create but it misses a couple of cases
when new connections are created. This patch corrects that to fix the
following warning:
<4>[ 1864.732366] =======================================================
<4>[ 1864.733030] [ INFO: possible circular locking dependency detected ]
<4>[ 1864.733544] 3.0.16-mid3-00007-gc9a0f62 #3
<4>[ 1864.733883] -------------------------------------------------------
<4>[ 1864.734408] t.android.btclc/4204 is trying to acquire lock:
<4>[ 1864.734869] (rfcomm_mutex){+.+.+.}, at: [<c14970ea>] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.735541]
<4>[ 1864.735549] but task is already holding lock:
<4>[ 1864.736045] (sk_lock-AF_BLUETOOTH){+.+.+.}, at: [<c1498bf7>] lock_sock+0xa/0xc
<4>[ 1864.736732]
<4>[ 1864.736740] which lock already depends on the new lock.
<4>[ 1864.736750]
<4>[ 1864.737428]
<4>[ 1864.737437] the existing dependency chain (in reverse order) is:
<4>[ 1864.738016]
<4>[ 1864.738023] -> #1 (sk_lock-AF_BLUETOOTH){+.+.+.}:
<4>[ 1864.738549] [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.738977] [<c13d35c1>] lock_sock_nested+0x58/0x68
<4>[ 1864.739411] [<c1493c33>] l2cap_sock_sendmsg+0x3e/0x76
<4>[ 1864.739858] [<c13d06c3>] __sock_sendmsg+0x50/0x59
<4>[ 1864.740279] [<c13d0ea2>] sock_sendmsg+0x94/0xa8
<4>[ 1864.740687] [<c13d0ede>] kernel_sendmsg+0x28/0x37
<4>[ 1864.741106] [<c14969ca>] rfcomm_send_frame+0x30/0x38
<4>[ 1864.741542] [<c1496a2a>] rfcomm_send_ua+0x58/0x5a
<4>[ 1864.741959] [<c1498447>] rfcomm_run+0x441/0xb52
<4>[ 1864.742365] [<c104f095>] kthread+0x63/0x68
<4>[ 1864.742742] [<c14d5182>] kernel_thread_helper+0x6/0xd
<4>[ 1864.743187]
<4>[ 1864.743193] -> #0 (rfcomm_mutex){+.+.+.}:
<4>[ 1864.743667] [<c1061ada>] __lock_acquire+0x988/0xc00
<4>[ 1864.744100] [<c1062273>] lock_acquire+0x104/0x140
<4>[ 1864.744519] [<c14d2c70>] __mutex_lock_common+0x3b/0x33f
<4>[ 1864.744975] [<c14d303e>] mutex_lock_nested+0x2d/0x36
<4>[ 1864.745412] [<c14970ea>] rfcomm_dlc_close+0x15/0x30
<4>[ 1864.745842] [<c14990d9>] __rfcomm_sock_close+0x5f/0x6b
<4>[ 1864.746288] [<c1499114>] rfcomm_sock_shutdown+0x2f/0x62
<4>[ 1864.746737] [<c13d275d>] sys_socketcall+0x1db/0x422
<4>[ 1864.747165] [<c14d42f0>] syscall_call+0x7/0xb
Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|
|
After moving L2CAP timers to workqueues l2cap_set_timer expects timeout
value to be specified in jiffies but constants defined in miliseconds
are used. This makes timeouts unreliable when CONFIG_HZ is not set to
1000.
__set_chan_timer macro still uses jiffies as input to avoid multiple
conversions from/to jiffies for sk_sndtimeo value which is already
specified in jiffies.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Ackec-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
|