* [PATCH v3 3/3] genetlink: synchronize socket closing and family removal
From: Johannes Berg @ 2015-01-16 10:37 UTC (permalink / raw)
To: netdev; +Cc: Jeff Layton, Sedat Dilek, Johannes Berg
In-Reply-To: <1421404634-8973-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
In addition to the problem Jeff Layton reported, I looked at the code
and reproduced the same warning by subscribing and removing the genl
family with a socket still open. This is a fairly tricky race which
originates in the fact that generic netlink allows the family to go
away while sockets are still open - unlike regular netlink which has
a module refcount for every open socket so in general this cannot be
triggered.
Trying to resolve this issue by the obvious locking isn't possible as
it will result in deadlocks between unregistration and group unbind
notification (which incidentally lockdep doesn't find due to the home
grown locking in the netlink table.)
To really resolve this, introduce a "closing socket" reference counter
(for generic netlink only, as it's the only affected family) in the
core netlink code and use that in generic netlink to wait for all the
sockets that are being closed at the same time as a generic netlink
family is removed.
This fixes the race that when a socket is closed, it will should call
the unbind, but if the family is removed at the same time the unbind
will not find it, leading to the warning. The real problem though is
that in this case the unbind could actually find a new family that is
registered to have a multicast group with the same ID, and call its
mcast_unbind() leading to confusing.
Also remove the warning since it would still trigger, but is now no
longer a problem.
This also moves the code in af_netlink.c to before unreferencing the
module to avoid having the same problem in the normal non-genl case.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/linux/genetlink.h | 4 ++++
include/net/genetlink.h | 5 ++++-
net/netlink/af_netlink.c | 24 +++++++++++++++++-------
net/netlink/af_netlink.h | 1 +
net/netlink/genetlink.c | 16 +++++++++-------
5 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/include/linux/genetlink.h b/include/linux/genetlink.h
index 55b685719d52..09460d6d6682 100644
--- a/include/linux/genetlink.h
+++ b/include/linux/genetlink.h
@@ -11,6 +11,10 @@ extern void genl_unlock(void);
extern int lockdep_genl_is_held(void);
#endif
+/* for synchronisation between af_netlink and genetlink */
+extern atomic_t genl_sk_destructing_cnt;
+extern wait_queue_head_t genl_sk_destructing_waitq;
+
/**
* rcu_dereference_genl - rcu_dereference with debug checking
* @p: The pointer to read, prior to dereferencing
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index 2ea2c55bdc87..6c92415311ca 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -35,7 +35,10 @@ struct genl_info;
* undo operations done by pre_doit, for example release locks
* @mcast_bind: a socket bound to the given multicast group (which
* is given as the offset into the groups array)
- * @mcast_unbind: a socket was unbound from the given multicast group
+ * @mcast_unbind: a socket was unbound from the given multicast group.
+ * Note that unbind() will not be called symmetrically if the
+ * generic netlink family is removed while there are still open
+ * sockets.
* @attrbuf: buffer to store parsed attributes
* @family_list: family list
* @mcgrps: multicast groups used by this family (private)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 01b702d63457..0a91ea36ac55 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -61,6 +61,7 @@
#include <linux/rhashtable.h>
#include <asm/cacheflush.h>
#include <linux/hash.h>
+#include <linux/genetlink.h>
#include <net/net_namespace.h>
#include <net/sock.h>
@@ -1089,6 +1090,8 @@ static void netlink_remove(struct sock *sk)
__sk_del_bind_node(sk);
netlink_update_listeners(sk);
}
+ if (sk->sk_protocol == NETLINK_GENERIC)
+ atomic_inc(&genl_sk_destructing_cnt);
netlink_table_ungrab();
}
@@ -1212,6 +1215,20 @@ static int netlink_release(struct socket *sock)
* will be purged.
*/
+ /* must not acquire netlink_table_lock in any way again before unbind
+ * and notifying genetlink is done as otherwise it might deadlock
+ */
+ if (nlk->netlink_unbind) {
+ int i;
+
+ for (i = 0; i < nlk->ngroups; i++)
+ if (test_bit(i, nlk->groups))
+ nlk->netlink_unbind(sock_net(sk), i + 1);
+ }
+ if (sk->sk_protocol == NETLINK_GENERIC &&
+ atomic_dec_return(&genl_sk_destructing_cnt) == 0)
+ wake_up(&genl_sk_destructing_waitq);
+
sock->sk = NULL;
wake_up_interruptible_all(&nlk->wait);
@@ -1247,13 +1264,6 @@ static int netlink_release(struct socket *sock)
netlink_table_ungrab();
}
- if (nlk->netlink_unbind) {
- int i;
-
- for (i = 0; i < nlk->ngroups; i++)
- if (test_bit(i, nlk->groups))
- nlk->netlink_unbind(sock_net(sk), i + 1);
- }
kfree(nlk->groups);
nlk->groups = NULL;
diff --git a/net/netlink/af_netlink.h b/net/netlink/af_netlink.h
index 7518375782f5..89008405d6b4 100644
--- a/net/netlink/af_netlink.h
+++ b/net/netlink/af_netlink.h
@@ -2,6 +2,7 @@
#define _AF_NETLINK_H
#include <linux/rhashtable.h>
+#include <linux/atomic.h>
#include <net/sock.h>
#define NLGRPSZ(x) (ALIGN(x, sizeof(unsigned long) * 8) / 8)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index c18d3f5624b2..ee57459fc258 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -23,6 +23,9 @@
static DEFINE_MUTEX(genl_mutex); /* serialization of message processing */
static DECLARE_RWSEM(cb_lock);
+atomic_t genl_sk_destructing_cnt = ATOMIC_INIT(0);
+DECLARE_WAIT_QUEUE_HEAD(genl_sk_destructing_waitq);
+
void genl_lock(void)
{
mutex_lock(&genl_mutex);
@@ -435,15 +438,18 @@ int genl_unregister_family(struct genl_family *family)
genl_lock_all();
- genl_unregister_mc_groups(family);
-
list_for_each_entry(rc, genl_family_chain(family->id), family_list) {
if (family->id != rc->id || strcmp(rc->name, family->name))
continue;
+ genl_unregister_mc_groups(family);
+
list_del(&rc->family_list);
family->n_ops = 0;
- genl_unlock_all();
+ up_write(&cb_lock);
+ wait_event(genl_sk_destructing_waitq,
+ atomic_read(&genl_sk_destructing_cnt) == 0);
+ genl_unlock();
kfree(family->attrbuf);
genl_ctrl_event(CTRL_CMD_DELFAMILY, family, NULL, 0);
@@ -1014,7 +1020,6 @@ static int genl_bind(struct net *net, int group)
static void genl_unbind(struct net *net, int group)
{
int i;
- bool found = false;
down_read(&cb_lock);
for (i = 0; i < GENL_FAM_TAB_SIZE; i++) {
@@ -1027,14 +1032,11 @@ static void genl_unbind(struct net *net, int group)
if (f->mcast_unbind)
f->mcast_unbind(net, fam_grp);
- found = true;
break;
}
}
}
up_read(&cb_lock);
-
- WARN_ON(!found);
}
static int __net_init genl_pernet_init(struct net *net)
--
2.1.4
^ permalink raw reply related
* [PATCH v3 2/3] genetlink: disallow subscribing to unknown mcast groups
From: Johannes Berg @ 2015-01-16 10:37 UTC (permalink / raw)
To: netdev; +Cc: Jeff Layton, Sedat Dilek, Johannes Berg
In-Reply-To: <1421404634-8973-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Jeff Layton reported that he could trigger the multicast unbind warning
in generic netlink using trinity. I originally thought it was a race
condition between unregistering the generic netlink family and closing
the socket, but there's a far simpler explanation: genetlink currently
allows subscribing to groups that don't (yet) exist, and the warning is
triggered when unsubscribing again while the group still doesn't exist.
Originally, I had a warning in the subscribe case and accepted it out of
userspace API concerns, but the warning was of course wrong and removed
later.
However, I now think that allowing userspace to subscribe to groups that
don't exist is wrong and could possibly become a security problem:
Consider a (new) genetlink family implementing a permission check in
the mcast_bind() function similar to the like the audit code does today;
it would be possible to bypass the permission check by guessing the ID
and subscribing to the group it exists. This is only possible in case a
family like that would be dynamically loaded, but it doesn't seem like a
huge stretch, for example wireless may be loaded when you plug in a USB
device.
To avoid this reject such subscription attempts.
If this ends up causing userspace issues we may need to add a workaround
in af_netlink to deny such requests but not return an error.
Reported-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/netlink/genetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 2e11061ef885..c18d3f5624b2 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -985,7 +985,7 @@ static struct genl_multicast_group genl_ctrl_groups[] = {
static int genl_bind(struct net *net, int group)
{
- int i, err = 0;
+ int i, err = -ENOENT;
down_read(&cb_lock);
for (i = 0; i < GENL_FAM_TAB_SIZE; i++) {
--
2.1.4
^ permalink raw reply related
* [PATCH v3 1/3] genetlink: document parallel_ops
From: Johannes Berg @ 2015-01-16 10:37 UTC (permalink / raw)
To: netdev; +Cc: Jeff Layton, Sedat Dilek, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The kernel-doc for the parallel_ops family struct member is
missing, add it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/genetlink.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/genetlink.h b/include/net/genetlink.h
index 84125088c309..2ea2c55bdc87 100644
--- a/include/net/genetlink.h
+++ b/include/net/genetlink.h
@@ -27,6 +27,8 @@ struct genl_info;
* @maxattr: maximum number of attributes supported
* @netnsok: set to true if the family can handle network
* namespaces and should be presented in all of them
+ * @parallel_ops: operations can be called in parallel and aren't
+ * synchronized by the core genetlink code
* @pre_doit: called before an operation's doit callback, it may
* do additional, common, filtering and return an error
* @post_doit: called after an operation's doit callback, it may
--
2.1.4
^ permalink raw reply related
* RE: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
From: Hayes Wang @ 2015-01-16 9:37 UTC (permalink / raw)
To: poma, nic_swsd
Cc: Community support for Fedora users,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <54B8CAC2.6020406-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
poma [mailto:pomidorabelisima-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> Sent: Friday, January 16, 2015 4:25 PM
[...]
> > This looks like a USB problem. Is there a way to get usb (or
> > NetworkManager) to reinitialize the driver when this happens?
>
> I would ask these people for advice, therefore.
Our hw engineers need to analyse the behavior of the device.
However, I don't think you have such instrument to provide
the required information. If we don't know the reason, we
couldn't give you the proper solution. Besides, your solution
would work if and only if reloading the driver is helpful.
The issue have to debug from the hardware, and I have no idea
about what the software could do before analysing the hw. Maybe
you could try the following driver first to check if it is useful.
http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=2&PNid=13&PFid=56&Level=5&Conn=4&DownTypeID=3&GetDown=false
Best Regards,
Hayes
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] can: dev: fix semicolon.cocci warnings
From: Marc Kleine-Budde @ 2015-01-16 8:56 UTC (permalink / raw)
To: kbuild test robot, Andri Yngvason
Cc: kbuild-all, Wolfgang Grandegger, linux-can, netdev, linux-kernel
In-Reply-To: <20150116085221.GA26042@waimea>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On 01/16/2015 09:52 AM, kbuild test robot wrote:
> drivers/net/can/dev.c:294:2-3: Unneeded semicolon
>
>
> Removes unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Andri Yngvason <andri.yngvason@marel.com>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Tnx, applied to can/master.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] can: dev: fix semicolon.cocci warnings
From: kbuild test robot @ 2015-01-16 8:52 UTC (permalink / raw)
To: Andri Yngvason
Cc: kbuild-all, Marc Kleine-Budde, Wolfgang Grandegger, linux-can,
netdev, linux-kernel
In-Reply-To: <201501161614.VyaaG8DL%fengguang.wu@intel.com>
drivers/net/can/dev.c:294:2-3: Unneeded semicolon
Removes unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Andri Yngvason <andri.yngvason@marel.com>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -291,7 +291,7 @@ static void can_update_state_error_stats
case CAN_STATE_BUS_OFF:
default:
break;
- };
+ }
}
static int can_tx_state_to_frame(struct net_device *dev, enum can_state state)
^ permalink raw reply
* Re: NETDEV WATCHDOG: internal(r8152): transmit queue 0 timed out
From: poma @ 2015-01-16 8:24 UTC (permalink / raw)
To: Realtek linux nic maintainers, hayeswang
Cc: Community support for Fedora users, linux-usb, netdev
In-Reply-To: <m99j1v$n60$1@ger.gmane.org>
On 16.01.2015 00:38, sean darcy wrote:
> I've got F20 on an old laptop I'm using as a router. The external
> interface uses the RJ45 port. The internal uses a USB ethernet adapter.
> Every 2-3 weeks, the internal USB adapter fails. I can fix it by just
> moving it to the other USB port. In another 2-3 weeks, it will fail
> again, and I move it back to the original USB port, and so on.
>
> No problems with the external RJ45 interface.
>
> The logs aren't very helpful:
>
> 12:39:22 kernel: NETDEV WATCHDOG: internal (r8152): transmit queue 0
> timed out
> 12:39:22 kernel: Modules linked in: xt_conntrack xt_nat ipt_MASQUERADE
> xt_DSCP iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4
> nf_nat_ipv4 iptable_raw sch_pie nf_nat_sip nf_nat nf_conntrack_sip
> nf_conntrack bnep bluetooth arc4 snd_hda_codec_hdmi
> snd_hda_codec_realtek b43 bcma snd_hda_codec_generic snd_hda_intel
> snd_hda_controller mac80211 snd_hda_codec uvcvideo snd_hwdep snd_seq
> snd_seq_device coretemp sdhci_pci snd_pcm acer_wmi videobuf2_vmalloc
> cfg80211 sparse_keymap microcode sdhci videobuf2_memops iTCO_wdt
> videobuf2_core rfkill iTCO_vendor_support v4l2_common tg3 ssb cdc_ether
> ptp joydev pps_core usbnet videodev media i2c_i801 serio_raw mmc_core
> irda r8152 lpc_ich shpchp tifm_7xx1 snd_timer snd soundcore mfd_core
> tifm_core crc_ccitt wmi mii acpi_cpufreq firewire_ohci firewire_core
> crc_itu_t
> 12:39:22 kernel: r8152 2-2:1.0 internal: Tx timeout
> 12:39:23 kernel: r8152 2-2:1.0 internal: Tx timeout
> 12:39:24 kernel: r8152 2-2:1.0 internal: Tx timeout
> ......
>
> This looks like a USB problem. Is there a way to get usb (or
> NetworkManager) to reinitialize the driver when this happens?
>
> sean
>
>
I would ask these people for advice, therefore.
^ permalink raw reply
* Re: [PATCH] net: ipv4: Fix incorrect free in ICMP receive
From: David Miller @ 2015-01-16 8:09 UTC (permalink / raw)
To: subashab; +Cc: netdev
In-Reply-To: <05e337f44c7a71ac317194cfa3dcdf62.squirrel@www.codeaurora.org>
From: subashab@codeaurora.org
Date: Fri, 16 Jan 2015 07:48:36 -0000
> An exception is seen in ICMP ping receive path where the skb
> destructor sock_rfree() tries to access a freed socket. This happens
> because ping_rcv() releases socket reference with sock_put() and this
> internally frees up the socket. Later icmp_rcv() will try to free the
> skb and as part of this, skb destructor is called and panics as the
> socket is freed already in ping_rcv().
At the point in which foo_sock_destruct() is called, the 'sk' is not
freed. We're operating on it inside of the destruct function itself.
^ permalink raw reply
* Re: [PATCH net-next v12 5/5] openvswitch: Add support for unique flow IDs.
From: Pravin Shelar @ 2015-01-16 8:07 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <1421358507-5992-6-git-send-email-joestringer@nicira.com>
On Thu, Jan 15, 2015 at 1:48 PM, Joe Stringer <joestringer@nicira.com> wrote:
> Previously, flows were manipulated by userspace specifying a full,
> unmasked flow key. This adds significant burden onto flow
> serialization/deserialization, particularly when dumping flows.
>
> This patch adds an alternative way to refer to flows using a
> variable-length "unique flow identifier" (UFID). At flow setup time,
> userspace may specify a UFID for a flow, which is stored with the flow
> and inserted into a separate table for lookup, in addition to the
> standard flow table. Flows created using a UFID must be fetched or
> deleted using the UFID.
>
> All flow dump operations may now be made more terse with OVS_UFID_F_*
> flags. For example, the OVS_UFID_F_OMIT_KEY flag allows responses to
> omit the flow key from a datapath operation if the flow has a
> corresponding UFID. This significantly reduces the time spent assembling
> and transacting netlink messages. With all OVS_UFID_F_OMIT_* flags
> enabled, the datapath only returns the UFID and statistics for each flow
> during flow dump, increasing ovs-vswitchd revalidator performance by 40%
> or more.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
Patch looks pretty good now. I have one comment below.
> +#define MAX_UFID_LENGTH 16 /* 128 bits */
> +
> +struct sw_flow_id {
> + u32 ufid_len;
> + union {
> + u32 ufid[MAX_UFID_LENGTH / 4];
> + struct sw_flow_key flow_key;
> + };
> +};
> +
> struct sw_flow_actions {
> struct rcu_head rcu;
> u32 actions_len;
> @@ -213,13 +223,15 @@ struct flow_stats {
>
> struct sw_flow {
> struct rcu_head rcu;
> - struct hlist_node hash_node[2];
> - u32 hash;
> + struct {
> + struct hlist_node node[2];
> + u32 hash;
> + } flow_table, ufid_table;
> int stats_last_writer; /* NUMA-node id of the last writer on
> * 'stats[0]'.
> */
> struct sw_flow_key key;
> - struct sw_flow_key unmasked_key;
> + struct sw_flow_id *id;
> struct sw_flow_mask *mask;
> struct sw_flow_actions __rcu *sf_acts;
> struct flow_stats __rcu *stats[]; /* One for each NUMA node. First one
> @@ -243,6 +255,16 @@ struct arp_eth_header {
> unsigned char ar_tip[4]; /* target IP address */
> } __packed;
>
In last round we agreed on following struct flow-id which saves around
four hundred bytes per flow and kmalloc per flow add operation for
common case. Is there any reason for not doing it?
struct {
u32 ufid_len;
union {
u32 ufid[MAX_UFID_LENGTH / 4];
struct sw_flow_key *unmasked_key;
}
} id;
^ permalink raw reply
* [PATCH] net: ipv4: Fix incorrect free in ICMP receive
From: subashab @ 2015-01-16 7:48 UTC (permalink / raw)
To: netdev
An exception is seen in ICMP ping receive path where the skb
destructor sock_rfree() tries to access a freed socket. This happens
because ping_rcv() releases socket reference with sock_put() and this
internally frees up the socket. Later icmp_rcv() will try to free the
skb and as part of this, skb destructor is called and panics as the
socket is freed already in ping_rcv().
WARN stack trace @ WARN_ON(atomic_read(&sk->sk_rmem_alloc));
dump_backtrace+0x0/0x248
show_stack+0x10/0x1c
dump_stack+0x1c/0x28
warn_slowpath_common+0x74/0x9c
warn_slowpath_null+0x14/0x20
inet_sock_destruct+0x130/0x1a0
__sk_free+0x1c/0x168
sk_free+0x24/0x30
ping_rcv+0xf4/0x124
icmp_rcv+0x224/0x2c4
ip_local_deliver_finish+0x108/0x214
ip_local_deliver+0x88/0xa0
ip_rcv_finish+0x234/0x284
ip_rcv+0x258/0x2e8
__netif_receive_skb_core+0x640/0x6b4
<snip>
-->|exception
-007|sk_mem_uncharge
-007|sock_rfree
-008|skb_release_head_state
-009|skb_release_all
-009|__kfree_skb
-010|kfree_skb
-011|icmp_rcv
-012|ip_local_deliver_finish
Fix this by orphaning the skb's before freeing the socket
Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
---
net/ipv4/af_inet.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index b507a47..0c58f0e5 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -147,6 +147,12 @@ EXPORT_SYMBOL(ipv4_config);
void inet_sock_destruct(struct sock *sk)
{
struct inet_sock *inet = inet_sk(sk);
+ struct sk_buff *skb;
+
+ skb_queue_walk(&sk->sk_receive_queue, skb)
+ skb_orphan(skb);
+ skb_queue_walk(&sk->sk_error_queue, skb)
+ skb_orphan(skb);
__skb_queue_purge(&sk->sk_receive_queue);
__skb_queue_purge(&sk->sk_error_queue);
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* Re: netlink: Fix netlink_insert EADDRINUSE error
From: David Miller @ 2015-01-16 7:38 UTC (permalink / raw)
To: herbert; +Cc: netdev, ying.xue
In-Reply-To: <20150116062348.GA8588@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Fri, 16 Jan 2015 17:23:48 +1100
> The patch c5adde9468b0714a051eac7f9666f23eb10b61f7 ("netlink:
> eliminate nl_sk_hash_lock") introduced a bug where the EADDRINUSE
> error has been replaced by ENOMEM. This patch rectifies that
> problem.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied, thanks Herbert.
^ permalink raw reply
* Re: pull-request: mac80211-next 2015-01-15
From: Johannes Berg @ 2015-01-16 7:36 UTC (permalink / raw)
To: David Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150115.192820.2095761147762961625.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Thu, 2015-01-15 at 19:28 -0500, David Miller wrote:
> I had to resolve a minor merge conflict, please take a look to make sure
> I got it right.
Ah, yes, sorry about that - I knew about the conflict (had resolved it
numerous times) but forgot to give you a heads-up.
What you did is good, thanks.
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] Remove T4 FCoE support
From: Hannes Reinecke @ 2015-01-16 7:19 UTC (permalink / raw)
To: Praveen Madhavan, David Miller
Cc: netdev, linux-scsi, JBottomley, hch, hariprasad, varun
In-Reply-To: <20150116042616.GA1264@fcoe-test11>
On 01/16/2015 05:32 AM, Praveen Madhavan wrote:
> On Thu, Jan 15, 2015 at 02:04:53PM -0500, David Miller wrote:
>> From: Praveen Madhavan <praveenm@chelsio.com>
>> Date: Thu, 15 Jan 2015 19:15:50 +0530
>>
>>> These patches removes FCoE support for chelsio T4 adapter.
>>> Please apply on net-next since depends on previous commits.
>>
>> Why is it being removed? You have to state this in the
>> commit log messages at a minimum.
>>
> We found a subtle issue with FCoE on T4 very late in the game
> and decided not to productize FCoE on T4 and therefore there
> are no customers that will be impacted by this change. FCoE is
> supported on T5 cards.
> Sorry about that, not mentioning in commit log. Can i resend this
> patch with updated commit log?
>
Yes, please do.
Cheers,
Hannes
--
Dr. Hannes Reinecke zSeries & Storage
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] [PATCH] net: sxgbe: Fix waring for double kfree()
From: Dan Carpenter @ 2015-01-16 7:12 UTC (permalink / raw)
To: David Miller; +Cc: kgene, netdev, davem, bh74.an
In-Reply-To: <20150115.191416.1303150560556013280.davem@davemloft.net>
On Thu, Jan 15, 2015 at 07:14:16PM -0500, David Miller wrote:
> From: Kukjin Kim <kgene@kernel.org>
> Date: Thu, 15 Jan 2015 10:43:11 +0900
>
> > From: Byungho An <bh74.an@samsung.com>
> >
> > This patch fixes double kfree() calls at init_rx_ring() because
> > it causes static checker warning.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Signed-off-by: Byungho An <bh74.an@samsung.com>
> > Signed-off-by: Kukjin Kim <kgene@kernel.org>
>
> Applied.
It does silence the warning but it doesn't fix the bug.
Kukjin, let me know if you have any questions. I can write the fix if
you need me to.
regards,
dan carpenter
^ permalink raw reply
* [PATCH net-next] iproute2: bridge: support vlan range
From: roopa @ 2015-01-16 6:52 UTC (permalink / raw)
To: netdev, shemminger, vyasevic; +Cc: wkok
From: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds vlan range support to bridge command
using the newly added vinfo flags BRIDGE_VLAN_INFO_RANGE_BEGIN and
BRIDGE_VLAN_INFO_RANGE_END.
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
$bridge vlan add vid 10-15 dev dummy0
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
10
11
12
13
14
15
$bridge vlan del vid 14 dev dummy0
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
10
11
12
13
15
$bridge vlan del vid 10-15 dev dummy0
$bridge vlan show
port vlan ids
br0 1 PVID Egress Untagged
dummy0 1 PVID Egress Untagged
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
---
bridge/vlan.c | 46 ++++++++++++++++++++++++++++++++++++++-------
include/linux/if_bridge.h | 2 ++
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/bridge/vlan.c b/bridge/vlan.c
index 3bd7b0d..90b3b6b 100644
--- a/bridge/vlan.c
+++ b/bridge/vlan.c
@@ -32,6 +32,7 @@ static int vlan_modify(int cmd, int argc, char **argv)
} req;
char *d = NULL;
short vid = -1;
+ short vid_end = -1;
struct rtattr *afspec;
struct bridge_vlan_info vinfo;
unsigned short flags = 0;
@@ -49,8 +50,18 @@ static int vlan_modify(int cmd, int argc, char **argv)
NEXT_ARG();
d = *argv;
} else if (strcmp(*argv, "vid") == 0) {
+ char *p;
NEXT_ARG();
- vid = atoi(*argv);
+ p = strchr(*argv, '-');
+ if (p) {
+ *p = '\0';
+ p++;
+ vinfo.vid = atoi(*argv);
+ vid_end = atoi(p);
+ vinfo.flags |= BRIDGE_VLAN_INFO_RANGE_BEGIN;
+ } else {
+ vinfo.vid = atoi(*argv);
+ }
} else if (strcmp(*argv, "self") == 0) {
flags |= BRIDGE_FLAGS_SELF;
} else if (strcmp(*argv, "master") == 0) {
@@ -67,7 +78,7 @@ static int vlan_modify(int cmd, int argc, char **argv)
argc--; argv++;
}
- if (d == NULL || vid == -1) {
+ if (d == NULL || vinfo.vid == -1) {
fprintf(stderr, "Device and VLAN ID are required arguments.\n");
exit(-1);
}
@@ -78,20 +89,41 @@ static int vlan_modify(int cmd, int argc, char **argv)
return -1;
}
- if (vid >= 4096) {
- fprintf(stderr, "Invalid VLAN ID \"%hu\"\n", vid);
+ if (vinfo.vid >= 4096) {
+ fprintf(stderr, "Invalid VLAN ID \"%hu\"\n", vinfo.vid);
return -1;
}
- vinfo.vid = vid;
+ if (vinfo.flags & BRIDGE_VLAN_INFO_RANGE_BEGIN) {
+ if (vid_end == -1 || vid_end >= 4096 || vinfo.vid >= vid_end) {
+ fprintf(stderr, "Invalid VLAN range \"%hu-%hu\"\n",
+ vinfo.vid, vid_end);
+ return -1;
+ }
+ if (vinfo.flags & BRIDGE_VLAN_INFO_PVID) {
+ fprintf(stderr,
+ "pvid cannot be configured for a vlan range\n");
+ return -1;
+ }
+ }
afspec = addattr_nest(&req.n, sizeof(req), IFLA_AF_SPEC);
if (flags)
addattr16(&req.n, sizeof(req), IFLA_BRIDGE_FLAGS, flags);
- addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
- sizeof(vinfo));
+ if (vid_end != -1) {
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ vinfo.flags &= ~BRIDGE_VLAN_INFO_RANGE_BEGIN;
+ vinfo.flags |= BRIDGE_VLAN_INFO_RANGE_END;
+ vinfo.vid = vid_end;
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ } else {
+ addattr_l(&req.n, sizeof(req), IFLA_BRIDGE_VLAN_INFO, &vinfo,
+ sizeof(vinfo));
+ }
addattr_nest_end(&req.n, afspec);
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index ed6868e..e21a649 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -124,6 +124,8 @@ enum {
#define BRIDGE_VLAN_INFO_MASTER (1<<0) /* Operate on Bridge device as well */
#define BRIDGE_VLAN_INFO_PVID (1<<1) /* VLAN is PVID, ingress untagged */
#define BRIDGE_VLAN_INFO_UNTAGGED (1<<2) /* VLAN egresses untagged */
+#define BRIDGE_VLAN_INFO_RANGE_BEGIN (1<<3) /* VLAN is start of vlan range */
+#define BRIDGE_VLAN_INFO_RANGE_END (1<<4) /* VLAN is end of vlan range */
struct bridge_vlan_info {
__u16 flags;
--
1.7.10.4
^ permalink raw reply related
* UDP checksum handling in UFO packets from raw sockets
From: Michal Kubecek @ 2015-01-16 6:52 UTC (permalink / raw)
To: netdev
Hello,
I'm working on an issue with sending over-MTU UDP datagrams from a raw
socket via a virtio_net interface. The problem is quite clear:
ip_ufo_append_data() sets skb->ip_summed to CHECKSUM_PARTIAL
unconditionally but skb->csum_start and skb->csum_offset are never set
properly as it is normally done in udp_send_skb() which these packets
never pass through.
There are few possible solutions but I realized I have no idea which
behaviour would be the correct one (documentation is either missing or
unclear).
1. Make sure that for UFO packets csum_start and csum_offset are always
set even if they come from a raw socket. Pro: consistent with UFO
packets from regular UDP sockets, easy. Con: if sender sets the checksum
field to zero or sets SO_NO_CHECK, we ignore his wish (one could even
argue that we shouldn't touch higher layer headers at all for raw
sockets). It would be also inconsistent between UFO and non-UFO packets.
2. Always preserve UDP checksum set by userspace and set ip_summed to
CHECKSUM_NONE. Pro: we preserve the UDP datagram as provided by
userspace application which seems to be the logic behind raw sockets.
Con: this would require an exception in skb_gso_segment() which
currently issues a WARN as it doesn't expect packets other than
CHECKSUM_PARTIAL.
3. Do (2) if checksum field is zero ("no checksum" according to RFC 768)
or socket has SO_NO_CHECK option, (1) otherwise. Both pros and cons are
combination of those of (1) and (2).
4. Don't allow UFO for UDP packets from raw sockets. Pro: very easy,
consistency between "short" and "long" datagrams. Con: inefficient (but
using raw sockets to generate UDP traffic is unusual and rare).
I suppose the key question is: what are we supposed to do with the UDP
checksum? Should we always preserve it (user expects us to send the
datagram they created), always recalculate (we do so for IPv4 checksum
for raw sockets with IP_HDRINCL option) or something between
(recalculate unless it's zero or SO_NO_CHECK is set)? I would be
thankful for any ideas or references to documents saying what it should
work like.
Michal Kubecek
^ permalink raw reply
* Re: [PATCH for 3.19 2/3] rtlwifi: Fix handling of new style descriptors
From: Kalle Valo @ 2015-01-16 6:40 UTC (permalink / raw)
To: Larry Finger
Cc: 谭杭波, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <54B81EAA.9040706-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org> writes:
> Troy and I will try to prepare a patch that only fixes the bugs, and
> we will submit the cleanup for -next.
That's great, thank you.
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: netlink: Fix netlink_insert EADDRINUSE error
From: Ying Xue @ 2015-01-16 6:30 UTC (permalink / raw)
To: Herbert Xu, netdev
In-Reply-To: <20150116062348.GA8588@gondor.apana.org.au>
On 01/16/2015 02:23 PM, Herbert Xu wrote:
> The patch c5adde9468b0714a051eac7f9666f23eb10b61f7 ("netlink:
> eliminate nl_sk_hash_lock") introduced a bug where the EADDRINUSE
> error has been replaced by ENOMEM. This patch rectifies that
> problem.
>
Nice catch!
Acked-by: Ying Xue <ying.xue@windriver.com>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
>
> diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
> index 01b702d..7a94185 100644
> --- a/net/netlink/af_netlink.c
> +++ b/net/netlink/af_netlink.c
> @@ -1050,7 +1050,7 @@ netlink_update_listeners(struct sock *sk)
> static int netlink_insert(struct sock *sk, struct net *net, u32 portid)
> {
> struct netlink_table *table = &nl_table[sk->sk_protocol];
> - int err = -EADDRINUSE;
> + int err;
>
> lock_sock(sk);
>
> @@ -1065,10 +1065,13 @@ static int netlink_insert(struct sock *sk, struct net *net, u32 portid)
>
> nlk_sk(sk)->portid = portid;
> sock_hold(sk);
> - if (__netlink_insert(table, sk, net))
> - err = 0;
> - else
> +
> + err = 0;
> + if (!__netlink_insert(table, sk, net)) {
> + err = -EADDRINUSE;
> sock_put(sk);
> + }
> +
> err:
> release_sock(sk);
> return err;
>
^ permalink raw reply
* netlink: Fix netlink_insert EADDRINUSE error
From: Herbert Xu @ 2015-01-16 6:23 UTC (permalink / raw)
To: netdev, Ying Xue
The patch c5adde9468b0714a051eac7f9666f23eb10b61f7 ("netlink:
eliminate nl_sk_hash_lock") introduced a bug where the EADDRINUSE
error has been replaced by ENOMEM. This patch rectifies that
problem.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 01b702d..7a94185 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1050,7 +1050,7 @@ netlink_update_listeners(struct sock *sk)
static int netlink_insert(struct sock *sk, struct net *net, u32 portid)
{
struct netlink_table *table = &nl_table[sk->sk_protocol];
- int err = -EADDRINUSE;
+ int err;
lock_sock(sk);
@@ -1065,10 +1065,13 @@ static int netlink_insert(struct sock *sk, struct net *net, u32 portid)
nlk_sk(sk)->portid = portid;
sock_hold(sk);
- if (__netlink_insert(table, sk, net))
- err = 0;
- else
+
+ err = 0;
+ if (!__netlink_insert(table, sk, net)) {
+ err = -EADDRINUSE;
sock_put(sk);
+ }
+
err:
release_sock(sk);
return err;
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [PATCH net-next v5] rhashtable: Fix race in rhashtable_destroy() and use regular work_struct
From: David Miller @ 2015-01-16 6:19 UTC (permalink / raw)
To: ying.xue; +Cc: tgraf, sergei.shtylyov, netdev
In-Reply-To: <1421377989-7891-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Fri, 16 Jan 2015 11:13:09 +0800
> When we put our declared work task in the global workqueue with
> schedule_delayed_work(), its delay parameter is always zero.
> Therefore, we should define a regular work in rhashtable structure
> instead of a delayed work.
>
> By the way, we add a condition to check whether resizing functions
> are NULL before cancelling the work, avoiding to cancel an
> uninitialized work.
>
> Lastly, while we wait for all work items we submitted before to run
> to completion with cancel_delayed_work(), ht->mutex has been taken in
> rhashtable_destroy(). Moreover, cancel_delayed_work() doesn't return
> until all work items are accomplished, and when work items are
> scheduled, the work's function - rht_deferred_worker() will be called.
> However, as rht_deferred_worker() also needs to acquire the lock,
> deadlock might happen at the moment as the lock is already held before.
> So if the cancel work function is moved out of the lock covered scope,
> this will avoid the deadlock.
>
> Fixes: 97defe1 ("rhashtable: Per bucket locks & deferred expansion/shrinking")
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Cc: Thomas Graf <tgraf@suug.ch>
> Acked-by: Thomas Graf <tgraf@suug.ch>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH for-next 0/2] Refactor macros to conform to uniform standards
From: David Miller @ 2015-01-16 6:07 UTC (permalink / raw)
To: hariprasad-ut6Up61K2wZBDgjK7y7TUQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
roland-BHEL68pLQRGGvPXPguhicg, leedom-ut6Up61K2wZBDgjK7y7TUQ,
anish-ut6Up61K2wZBDgjK7y7TUQ, nirranjan-ut6Up61K2wZBDgjK7y7TUQ,
praveenm-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW
In-Reply-To: <1421380488-1111-1-git-send-email-hariprasad-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
From: Hariprasad Shenai <hariprasad-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
Date: Fri, 16 Jan 2015 09:24:46 +0530
> This patch series cleansup macros/register defines, defined in t4.h and
> t4fw_ri_api.h and all the affected files.
>
> This patch series is created against net-next tree and includes patches on
> iw_cxgb4 tree. Since the patches are dependent on previous cleanup patched we
> would line to get this series merged through net-next tree.
>
> We have included all the maintainers of respective drivers. Kindly review the
> change and let us know in case of any review comments.
Series applied, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 net] net: rps: fix cpu unplug
From: David Miller @ 2015-01-16 6:05 UTC (permalink / raw)
To: eric.dumazet; +Cc: subashab, psodagud, netdev, therbert
In-Reply-To: <1421370262.11734.111.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 15 Jan 2015 17:04:22 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> softnet_data.input_pkt_queue is protected by a spinlock that
> we must hold when transferring packets from victim queue to an active
> one. This is because other cpus could still be trying to enqueue packets
> into victim queue.
>
> A second problem is that when we transfert the NAPI poll_list from
> victim to current cpu, we absolutely need to special case the percpu
> backlog, because we do not want to add complex locking to protect
> process_queue : Only owner cpu is allowed to manipulate it, unless cpu
> is offline.
>
> Based on initial patch from Prasad Sodagudi & Subash Abhinov
> Kasiviswanathan.
>
> This version is better because we do not slow down packet processing,
> only make migration safer.
>
> Reported-by: Prasad Sodagudi <psodagud@codeaurora.org>
> Reported-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCHv2 0/6] Fixes for davinci_emac
From: David Miller @ 2015-01-16 6:01 UTC (permalink / raw)
To: tony; +Cc: netdev, linux-omap
In-Reply-To: <1421361914-4612-1-git-send-email-tony@atomide.com>
From: Tony Lindgren <tony@atomide.com>
Date: Thu, 15 Jan 2015 14:45:08 -0800
> Here's a repost of the fixes for davinci_emac with patches
> updated for comments and acks collected.
Series applied, thanks Tony.
^ permalink raw reply
* Re: [PATCH v3 3/3] net/macb: Create gem_ethtool_ops for new statistics functions
From: David Miller @ 2015-01-16 5:32 UTC (permalink / raw)
To: xander.huff
Cc: nicolas.ferre, david.light, netdev, jaeden.amero, rich.tollerton,
brad.mouring, linux-kernel, cyrille.pitchen
In-Reply-To: <1421358316-23660-3-git-send-email-xander.huff@ni.com>
From: Xander Huff <xander.huff@ni.com>
Date: Thu, 15 Jan 2015 15:45:16 -0600
> 10/100 MACB does not have the same statistics possibilities as GEM. Separate
> macb_ethtool_ops to make a new GEM-specific struct with the new statistics
> functions included.
>
> Signed-off-by: Xander Huff <xander.huff@ni.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3 2/3] net/macb: Add whitespace around arithmetic operators
From: David Miller @ 2015-01-16 5:32 UTC (permalink / raw)
To: xander.huff
Cc: nicolas.ferre, david.light, netdev, jaeden.amero, rich.tollerton,
brad.mouring, linux-kernel, cyrille.pitchen
In-Reply-To: <1421358316-23660-2-git-send-email-xander.huff@ni.com>
From: Xander Huff <xander.huff@ni.com>
Date: Thu, 15 Jan 2015 15:45:15 -0600
> Spaces should surround add, multiply, and bitshift operators.
>
> Signed-off-by: Xander Huff <xander.huff@ni.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox