linux-toradex.git/net/netlink, branch v3.11.2

genl: Hold reference on correct module while netlink-dump.

2013-08-28T21:19:17+00:00

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

genl: Fix genl dumpit() locking.

2013-08-28T21:19:17+00:00

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

Revert "genetlink: fix family dump race"

2013-08-22T20:24:02+00:00

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

genetlink: fix family dump race

2013-08-13T07:57:06+00:00

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

genetlink: fix usage of NLM_F_EXCL or NLM_F_REPLACE

2013-07-30T23:43:19+00:00

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

genetlink: release cb_lock before requesting additional module

2013-07-28T05:19:20+00:00

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 #1

Problem 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 -0700

    nl80211: 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

netlink: fix splat in skb_clone with large messages

2013-06-28T05:44:16+00:00

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/0x3d0

Fix 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

net: netlink: virtual tap device management

2013-06-24T23:39:05+00:00

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

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

2013-06-19T23:49:39+00:00

Conflicts:
	drivers/net/wireless/ath/ath9k/Kconfig
	drivers/net/xen-netback/netback.c
	net/batman-adv/bat_iv_ogm.c
	net/wireless/nl80211.c

The 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

netlink: make compare exist all the time

2013-06-13T07:45:48+00:00

Commit da12c90e099789a63073fc82a19542ce54d4efb9
"netlink: Add compare function for netlink_table"
only set compare at the time we create kernel netlink,
and reset compare to NULL at the time we finially
release netlink socket, but netlink_lookup wants
the compare exist always.

So we should set compare after we allocate nl_table,
and never reset it. make comapre exist all the time.

Reported-by: Fengguang Wu 
Signed-off-by: Gao feng 
Signed-off-by: David S. Miller