19 Jan, 2014
1 commit
-
This is a follow-up patch to f3d3342602f8bc ("net: rework recvmsg
handler msg_name and msg_namelen logic").DECLARE_SOCKADDR validates that the structure we use for writing the
name information to is not larger than the buffer which is reserved
for msg->msg_name (which is 128 bytes). Also use DECLARE_SOCKADDR
consistently in sendmsg code paths.Signed-off-by: Steffen Hurrle
Suggested-by: Hannes Frederic Sowa
Acked-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
07 Jan, 2014
3 commits
-
Jesse Gross says:
====================
[GIT net-next] Open vSwitchOpen vSwitch changes for net-next/3.14. Highlights are:
* Performance improvements in the mechanism to get packets to userspace
using memory mapped netlink and skb zero copy where appropriate.
* Per-cpu flow stats in situations where flows are likely to be shared
across CPUs. Standard flow stats are used in other situations to save
memory and allocation time.
* A handful of code cleanups and rationalization.
====================Signed-off-by: David S. Miller
-
An insufficent ring frame size configuration can lead to an
unnecessary skb allocation for every Netlink message. Check frame
size before taking the queue lock and allocating the skb and
re-check with lock to be safe.Signed-off-by: Thomas Graf
Reviewed-by: Daniel Borkmann
Signed-off-by: Jesse Gross -
Allocates a new sk_buff large enough to cover the specified payload
plus required Netlink headers. Will check receiving socket for
memory mapped i/o capability and use it if enabled. Will fall back
to non-mapped skb if message size exceeds the frame size of the ring.Signed-of-by: Thomas Graf
Reviewed-by: Daniel Borkmann
Signed-off-by: Jesse Gross
02 Jan, 2014
1 commit
-
Cleanups in netlink_tap code
* remove unused function netlink_clear_multicast_users
* make local function staticSigned-off-by: Stephen Hemminger
Reviewed-by: Johannes Berg
Signed-off-by: David S. Miller
01 Jan, 2014
2 commits
-
In order to facilitate development for netlink protocol dissector,
fill the unused field skb->pkt_type of the cloned skb with a hint
of the address space of the new owner (receiver) socket in the
notion of "to kernel" resp. "to user".At the time we invoke __netlink_deliver_tap_skb(), we already have
set the new skb owner via netlink_skb_set_owner_r(), so we can use
that for netlink_is_kernel() probing.In normal PF_PACKET network traffic, this field denotes if the
packet is destined for us (PACKET_HOST), if it's broadcast
(PACKET_BROADCAST), etc.As we only have 3 bit reserved, we can use the value (= 6) of
PACKET_FASTROUTE as it's _not used_ anywhere in the whole kernel
and not supported anywhere, and packets of such type were never
exposed to user space, so there are no overlapping users of such
kind. Thus, as wished, that seems the only way to make both
PACKET_* values non-overlapping and therefore device agnostic.By using those two flags for netlink skbs on nlmon devices, they
can be made available and picked up via sll_pkttype (previously
unused in netlink context) in struct sockaddr_ll. We now have
these two directions:- PACKET_USER (= 6) -> to user space
- PACKET_KERNEL (= 7) -> to kernel spacePartial `ip a` example strace for sa_family=AF_NETLINK with
detected nl msg direction:syscall: direction:
sendto(3, ...) = 40 /* to kernel */
recvmsg(3, ...) = 3404 /* to user */
recvmsg(3, ...) = 1120 /* to user */
recvmsg(3, ...) = 20 /* to user */
sendto(3, ...) = 40 /* to kernel */
recvmsg(3, ...) = 168 /* to user */
recvmsg(3, ...) = 144 /* to user */
recvmsg(3, ...) = 20 /* to user */Signed-off-by: Daniel Borkmann
Signed-off-by: Jakub Zawadzki
Signed-off-by: David S. Miller -
We should also deliver packets to nlmon devices when we are in
netlink_unicast_kernel(), and only one of the {src,dst} sockets
is user sk and the other one kernel sk. That's e.g. the case in
netlink diag, netlink route, etc. Still, forbid to deliver messages
from kernel to kernel sks.Signed-off-by: Daniel Borkmann
Signed-off-by: Jakub Zawadzki
Signed-off-by: David S. Miller
29 Nov, 2013
2 commits
-
The pmcraid driver is abusing the genetlink API and is using its
family ID as the multicast group ID, which is invalid and may
belong to somebody else (and likely will.)Make it use the correct API, but since this may already be used
as-is by userspace, reserve a family ID for this code and also
reserve that group ID to not break userspace assumptions.My previous patch broke event delivery in the driver as I missed
that it wasn't using the right API and forgot to update it later
in my series.While changing this, I noticed that the genetlink code could use
the static group ID instead of a strcmp(), so also do that for
the VFS_DQUOT family.Cc: Anil Ravindranath
Cc: "James E.J. Bottomley"
Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
net/netlink/genetlink.c: In function ‘genl_validate_assign_mc_groups’:
net/netlink/genetlink.c:217: warning: ‘err’ may be used uninitialized in this
functionCommit 2a94fe48f32ccf7321450a2cc07f2b724a444e5b ("genetlink: make multicast
groups const, prevent abuse") split genl_register_mc_group() in multiple
functions, but dropped the initialization of err.Initialize err to zero to fix this.
Signed-off-by: Geert Uytterhoeven
Signed-off-by: David S. Miller
22 Nov, 2013
1 commit
-
Unfortunately, I introduced a tremendously stupid bug into
genlmsg_multicast() when doing all those multicast group
changes: it adjusts the group number, but then passes it
to genlmsg_multicast_netns() which does that again.Somehow, my tests failed to catch this, so add a warning
into genlmsg_multicast_netns() and remove the offending
group ID adjustment.Also add a warning to the similar code in other functions
so people who misuse them are more loudly warned.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller
21 Nov, 2013
1 commit
-
This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size
Suggested-by: Eric Dumazet
Signed-off-by: Hannes Frederic Sowa
Signed-off-by: David S. Miller
20 Nov, 2013
8 commits
-
Register generic netlink multicast groups as an array with
the family and give them contiguous group IDs. Then instead
of passing the global group ID to the various functions that
send messages, pass the ID relative to the family - for most
families that's just 0 because the only have one group.This avoids the list_head and ID in each group, adding a new
field for the mcast group ID offset to the family.At the same time, this allows us to prevent abusing groups
again like the quota and dropmon code did, since we can now
check that a family only uses a group it owns.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
This doesn't really change anything, but prepares for the
next patch that will change the APIs to pass the group ID
within the family, rather than the global group ID.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
There's no reason to have the family pointer there since it
can just be passed internally where needed, so remove it.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
There are no users of this API remaining, and we'll soon
change group registration to be static (like ops are now)Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
The quota code is abusing the genetlink API and is using
its family ID as the multicast group ID, which is invalid
and may belong to somebody else (and likely will.)Make the quota code use the correct API, but since this
is already used as-is by userspace, reserve a family ID
for this code and also reserve that group ID to not break
userspace assumptions.Acked-by: Jan Kara
Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
The drop monitor code is abusing the genetlink API and is
statically using the generic netlink multicast group 1, even
if that group belongs to somebody else (which it invariably
will, since it's not reserved.)Make the drop monitor code use the proper APIs to reserve a
group ID, but also reserve the group id 1 in generic netlink
code to preserve the userspace API. Since drop monitor can
be a module, don't clear the bit for it on unregistration.Acked-by: Neil Horman
Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
As suggested by David Miller, make genl_register_family_with_ops()
a macro and pass only the array, evaluating ARRAY_SIZE() in the
macro, this is a little safer.The openvswitch has some indirection, assing ops/n_ops directly in
that code. This might ultimately just assign the pointers in the
family initializations, saving the struct genl_family_and_ops and
code (once mcast groups are handled differently.)Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
The parameter is just 'group', not 'groups', fix the documentation typo.
Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller
19 Nov, 2013
1 commit
-
Sparse pointed out that the new flags variable I had added
shadowed an existing one, rename the new one to avoid that,
making the code clearer.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller
16 Nov, 2013
1 commit
-
Now that the ops assignment is just two variables rather than a
long list iteration etc., there's no reason to separately export
__genl_register_family() and __genl_register_family_with_ops().Unify the two functions into __genl_register_family() and make
genl_register_family_with_ops() call it after assigning the ops.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller
15 Nov, 2013
3 commits
-
Allow making the ops array const by not modifying the ops
flags on registration but rather only when ops are sent
out in the family information.No users are updated yet except for the pre_doit/post_doit
calls in wireless (the only ones that exist now.)Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
Instead of using a linked list, use an array. This reduces
the data size needed by the users of genetlink, for example
in wireless (net/wireless/nl80211.c) on 64-bit it frees up
over 1K of data space.Remove the attempted sending of CTRL_CMD_NEWOPS ctrl event
since genl_ctrl_event(CTRL_CMD_NEWOPS, ...) only returns
-EINVAL anyway, therefore no such event could ever be sent.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller -
genl_register_ops() is still needed for internal registration,
but is no longer available to users of the API.Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller
07 Sep, 2013
1 commit
-
Fix finer-grained control and let only a whitelist of allowed netlink
protocols pass, in our case related to networking. If later on, other
subsystems decide they want to add their protocol as well to the list
of allowed protocols they shall simply add it. While at it, we also
need to tell what protocol is in use otherwise BPF_S_ANC_PROTOCOL can
not pick it up (as it's not filled out).Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller
06 Sep, 2013
1 commit
-
Conflicts:
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
net/bridge/br_multicast.c
net/ipv6/sit.cThe conflicts were minor:
1) sit.c changes overlap with change to ip_tunnel_xmit() signature.
2) br_multicast.c had an overlap between computing max_delay using
msecs_to_jiffies and turning MLDV2_MRC() into an inline function
with a name using lowercase instead of uppercase letters.3) stmmac had two overlapping changes, one which conditionally allocated
and hooked up a dma_cfg based upon the presence of the pbl OF property,
and another one handling store-and-forward DMA made. The latter of
which should not go into the new of_find_property() basic block.Signed-off-by: David S. Miller
29 Aug, 2013
2 commits
-
netlink dump operations take module as parameter to hold
reference for entire netlink dump duration.
Currently it holds ref only on genl module which is not correct
when we use ops registered to genl from another module.
Following patch adds module pointer to genl_ops so that netlink
can hold ref count on it.CC: Jesse Gross
CC: Johannes Berg
Signed-off-by: Pravin B Shelar
Signed-off-by: David S. Miller -
In case of genl-family with parallel ops off, dumpif() callback
is expected to run under genl_lock, But commit def3117493eafd9df
(genl: Allow concurrent genl callbacks.) changed this behaviour
where only first dumpit() op was called under genl-lock.
For subsequent dump, only nlk->cb_lock was taken.
Following patch fixes it by defining locked dumpit() and done()
callback which takes care of genl-locking.CC: Jesse Gross
CC: Johannes Berg
Signed-off-by: Pravin B Shelar
Signed-off-by: David S. Miller
27 Aug, 2013
1 commit
-
Conflicts:
drivers/net/wireless/iwlwifi/pcie/trans.c
include/linux/inetdevice.hThe inetdevice.h conflict involves moving the IPV4_DEVCONF values
into a UAPI header, overlapping additions of some new entries.The iwlwifi conflict is a context overlap.
Signed-off-by: David S. Miller
23 Aug, 2013
1 commit
-
This reverts commit 58ad436fcf49810aa006016107f494c9ac9013db.
It turns out that the change introduced a potential deadlock
by causing a locking dependency with netlink's cb_mutex. I
can't seem to find a way to resolve this without doing major
changes to the locking, so revert this.Signed-off-by: Johannes Berg
Acked-by: Pravin B Shelar
Signed-off-by: David S. Miller
17 Aug, 2013
1 commit
16 Aug, 2013
1 commit
-
Following patch stores struct netlink_callback in netlink_sock
to avoid allocating and freeing it on every netlink dump msg.
Only one dump operation is allowed for a given socket at a time
therefore we can safely convert cb pointer to cb struct inside
netlink_sock.Signed-off-by: Pravin B Shelar
Signed-off-by: David S. Miller
13 Aug, 2013
1 commit
-
When dumping generic netlink families, only the first dump call
is locked with genl_lock(), which protects the list of families,
and thus subsequent calls can access the data without locking,
racing against family addition/removal. This can cause a crash.
Fix it - the locking needs to be conditional because the first
time around it's already locked.A similar bug was reported to me on an old kernel (3.4.47) but
the exact scenario that happened there is no longer possible,
on those kernels the first round wasn't locked either. Looking
at the current code I found the race described above, which had
also existed on the old kernel.Cc: stable@vger.kernel.org
Reported-by: Andrei Otcheretianski
Signed-off-by: Johannes Berg
Signed-off-by: David S. Miller
04 Aug, 2013
1 commit
-
Merge net into net-next to setup some infrastructure Eric
Dumazet needs for usbnet changes.Signed-off-by: David S. Miller
03 Aug, 2013
1 commit
-
Variable ptr is being assigned, but never used, so just remove it.
Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller
31 Jul, 2013
1 commit
-
Currently, it is not possible to use neither NLM_F_EXCL nor
NLM_F_REPLACE from genetlink. This is due to this checking in
genl_family_rcv_msg:if (nlh->nlmsg_flags & NLM_F_DUMP)
NLM_F_DUMP is NLM_F_MATCH|NLM_F_ROOT. Thus, if NLM_F_EXCL or
NLM_F_REPLACE flag is set, genetlink believes that you're
requesting a dump and it calls the .dumpit callback.The solution that I propose is to refine this checking to
make it stricter:if ((nlh->nlmsg_flags & NLM_F_DUMP) == NLM_F_DUMP)
And given the combination NLM_F_REPLACE and NLM_F_EXCL does
not make sense to me, it removes the ambiguity.There was a patch that tried to fix this some time ago (0ab03c2
netlink: test for all flags of the NLM_F_DUMP composite) but it
tried to resolve this ambiguity in *all* existing netlink subsystems,
not only genetlink. That patch was reverted since it broke iproute2,
which is using NLM_F_ROOT to request the dump of the routing cache.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: David S. Miller
28 Jul, 2013
1 commit
-
Requesting external module with cb_lock taken can result in
the deadlock like showed below:[ 2458.111347] Showing all locks held in the system:
[ 2458.111347] 1 lock held by NetworkManager/582:
[ 2458.111347] #0: (cb_lock){++++++}, at: [] genl_rcv+0x19/0x40
[ 2458.111347] 1 lock held by modprobe/603:
[ 2458.111347] #0: (cb_lock){++++++}, at: [] genl_lock_all+0x15/0x30[ 2461.579457] SysRq : Show Blocked State
[ 2461.580103] task PC stack pid father
[ 2461.580103] NetworkManager D ffff880034b84500 4040 582 1 0x00000080
[ 2461.580103] ffff8800197ff720 0000000000000046 00000000001d5340 ffff8800197fffd8
[ 2461.580103] ffff8800197fffd8 00000000001d5340 ffff880019631700 7fffffffffffffff
[ 2461.580103] ffff8800197ff880 ffff8800197ff878 ffff880019631700 ffff880019631700
[ 2461.580103] Call Trace:
[ 2461.580103] [] schedule+0x29/0x70
[ 2461.580103] [] schedule_timeout+0x1c1/0x360
[ 2461.580103] [] ? mark_held_locks+0xbb/0x140
[ 2461.580103] [] ? _raw_spin_unlock_irq+0x2c/0x50
[ 2461.580103] [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 2461.580103] [] wait_for_completion_killable+0xe8/0x170
[ 2461.580103] [] ? wake_up_state+0x20/0x20
[ 2461.580103] [] call_usermodehelper_exec+0x1a5/0x210
[ 2461.580103] [] ? wait_for_completion_killable+0x3d/0x170
[ 2461.580103] [] __request_module+0x1b3/0x370
[ 2461.580103] [] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 2461.580103] [] ctrl_getfamily+0x159/0x190
[ 2461.580103] [] genl_family_rcv_msg+0x1f4/0x2e0
[ 2461.580103] [] ? genl_family_rcv_msg+0x2e0/0x2e0
[ 2461.580103] [] genl_rcv_msg+0x8e/0xd0
[ 2461.580103] [] netlink_rcv_skb+0xa9/0xc0
[ 2461.580103] [] genl_rcv+0x28/0x40
[ 2461.580103] [] netlink_unicast+0xdd/0x190
[ 2461.580103] [] netlink_sendmsg+0x329/0x750
[ 2461.580103] [] sock_sendmsg+0x99/0xd0
[ 2461.580103] [] ? local_clock+0x5f/0x70
[ 2461.580103] [] ? lock_release_non_nested+0x308/0x350
[ 2461.580103] [] ___sys_sendmsg+0x39e/0x3b0
[ 2461.580103] [] ? kvm_clock_read+0x2f/0x50
[ 2461.580103] [] ? sched_clock+0x9/0x10
[ 2461.580103] [] ? sched_clock_local+0x1d/0x80
[ 2461.580103] [] ? sched_clock_cpu+0xa8/0x100
[ 2461.580103] [] ? trace_hardirqs_off+0xd/0x10
[ 2461.580103] [] ? local_clock+0x5f/0x70
[ 2461.580103] [] ? lock_release_holdtime.part.28+0xf/0x1a0
[ 2461.580103] [] ? fget_light+0xf9/0x510
[ 2461.580103] [] ? fget_light+0x3c/0x510
[ 2461.580103] [] __sys_sendmsg+0x42/0x80
[ 2461.580103] [] SyS_sendmsg+0x12/0x20
[ 2461.580103] [] system_call_fastpath+0x16/0x1b
[ 2461.580103] modprobe D ffff88000f2c8000 4632 603 602 0x00000080
[ 2461.580103] ffff88000f04fba8 0000000000000046 00000000001d5340 ffff88000f04ffd8
[ 2461.580103] ffff88000f04ffd8 00000000001d5340 ffff8800377d4500 ffff8800377d4500
[ 2461.580103] ffffffff81d0b260 ffffffff81d0b268 ffffffff00000000 ffffffff81d0b2b0
[ 2461.580103] Call Trace:
[ 2461.580103] [] schedule+0x29/0x70
[ 2461.580103] [] rwsem_down_write_failed+0xed/0x1a0
[ 2461.580103] [] ? update_cpu_load_active+0x10/0xb0
[ 2461.580103] [] call_rwsem_down_write_failed+0x13/0x20
[ 2461.580103] [] ? down_write+0x9d/0xb2
[ 2461.580103] [] ? genl_lock_all+0x15/0x30
[ 2461.580103] [] genl_lock_all+0x15/0x30
[ 2461.580103] [] genl_register_family+0x53/0x1f0
[ 2461.580103] [] ? 0xffffffffa01dbfff
[ 2461.580103] [] genl_register_family_with_ops+0x20/0x80
[ 2461.580103] [] ? 0xffffffffa01dbfff
[ 2461.580103] [] nl80211_init+0x24/0xf0 [cfg80211]
[ 2461.580103] [] ? 0xffffffffa01dbfff
[ 2461.580103] [] cfg80211_init+0x43/0xdb [cfg80211]
[ 2461.580103] [] do_one_initcall+0xfa/0x1b0
[ 2461.580103] [] ? set_memory_nx+0x43/0x50
[ 2461.580103] [] load_module+0x1c6f/0x27f0
[ 2461.580103] [] ? store_uevent+0x40/0x40
[ 2461.580103] [] SyS_finit_module+0x86/0xb0
[ 2461.580103] [] system_call_fastpath+0x16/0x1b
[ 2461.580103] Sched Debug Version: v0.10, 3.11.0-0.rc1.git4.1.fc20.x86_64 #1Problem start to happen after adding net-pf-16-proto-16-family-nl80211
alias name to cfg80211 module by below commit (though that commit
itself is perfectly fine):commit fb4e156886ce6e8309e912d8b370d192330d19d3
Author: Marcel Holtmann
Date: Sun Apr 28 16:22:06 2013 -0700nl80211: Add generic netlink module alias for cfg80211/nl80211
Reported-and-tested-by: Jeff Layton
Reported-by: Richard W.M. Jones
Signed-off-by: Stanislaw Gruszka
Reviewed-by: Pravin B Shelar
Signed-off-by: David S. Miller
28 Jun, 2013
1 commit
-
Since (c05cdb1 netlink: allow large data transfers from user-space),
netlink splats if it invokes skb_clone on large netlink skbs since:* skb_shared_info was not correctly initialized.
* skb->destructor is not set in the cloned skb.This was spotted by trinity:
[ 894.990671] BUG: unable to handle kernel paging request at ffffc9000047b001
[ 894.991034] IP: [] skb_clone+0x24/0xc0
[...]
[ 894.991034] Call Trace:
[ 894.991034] [] nl_fib_input+0x6a/0x240
[ 894.991034] [] ? _raw_read_unlock+0x26/0x40
[ 894.991034] [] netlink_unicast+0x169/0x1e0
[ 894.991034] [] netlink_sendmsg+0x251/0x3d0Fix it by:
1) introducing a new netlink_skb_clone function that is used in nl_fib_input,
that sets our special skb->destructor in the cloned skb. Moreover, handle
the release of the large cloned skb head area in the destructor path.2) not allowing large skbuffs in the netlink broadcast path. I cannot find
any reasonable use of the large data transfer using netlink in that path,
moreover this helps to skip extra skb_clone handling.I found two more netlink clients that are cloning the skbs, but they are
not in the sendmsg path. Therefore, the sole client cloning that I found
seems to be the fib frontend.Thanks to Eric Dumazet for helping to address this issue.
Reported-by: Fengguang Wu
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: David S. Miller
25 Jun, 2013
1 commit
-
Similarly to the networking receive path with ptype_all taps, we add
the possibility to register netdevices that are for ARPHRD_NETLINK to
the netlink subsystem, so that those can be used for netlink analyzers
resp. debuggers. We do not offer a direct callback function as out-of-tree
modules could do crap with it. Instead, a netdevice must be registered
properly and only receives a clone, managed by the netlink layer. Symbols
are exported as GPL-only.Signed-off-by: Daniel Borkmann
Signed-off-by: David S. Miller
20 Jun, 2013
1 commit
-
Conflicts:
drivers/net/wireless/ath/ath9k/Kconfig
drivers/net/xen-netback/netback.c
net/batman-adv/bat_iv_ogm.c
net/wireless/nl80211.cThe ath9k Kconfig conflict was a change of a Kconfig option name right
next to the deletion of another option.The xen-netback conflict was overlapping changes involving the
handling of the notify list in xen_netbk_rx_action().Batman conflict resolution provided by Antonio Quartulli, basically
keep everything in both conflict hunks.The nl80211 conflict is a little more involved. In 'net' we added a
dynamic memory allocation to nl80211_dump_wiphy() to fix a race that
Linus reported. Meanwhile in 'net-next' the handlers were converted
to use pre and post doit handlers which use a flag to determine
whether to hold the RTNL mutex around the operation.However, the dump handlers to not use this logic. Instead they have
to explicitly do the locking. There were apparent bugs in the
conversion of nl80211_dump_wiphy() in that we were not dropping the
RTNL mutex in all the return paths, and it seems we very much should
be doing so. So I fixed that whilst handling the overlapping changes.To simplify the initial returns, I take the RTNL mutex after we try
to allocate 'tb'.Signed-off-by: David S. Miller