* linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2014-12-10 8:54 UTC (permalink / raw)
To: David Miller, netdev; +Cc: linux-next, linux-kernel, Hariprasad Shenai
[-- Attachment #1: Type: text/plain, Size: 4399 bytes --]
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/net/ethernet/chelsio/cxgb4vf/built-in.o:(.opd+0x630): multiple definition of `t4_bar2_sge_qregs'
drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.opd+0x14d0): first defined here
drivers/net/ethernet/chelsio/cxgb4vf/built-in.o: In function `.t4_bar2_sge_qregs':
(.text+0x9220): multiple definition of `.t4_bar2_sge_qregs'
drivers/net/ethernet/chelsio/cxgb4/built-in.o:(.text+0x24e24): first defined here
Caused by commit e85c9a7abfa4 ("cxgb4/cxgb4vf: Add code to calculate T5
BAR2 Offsets for SGE Queue Registers") which added both versions. :-(
I have applied this fir patch for today (including the subject
typo :-)):
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 10 Dec 2014 19:48:02 +1100
Subject: [PATCH] cxgb4/cxgb4vf: global named must be unique
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 ++--
drivers/net/ethernet/chelsio/cxgb4/sge.c | 2 +-
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index 2c37e1bf253a..a18d33fdb271 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -1007,7 +1007,7 @@ int t4_prep_fw(struct adapter *adap, struct fw_info *fw_info,
int t4_prep_adapter(struct adapter *adapter);
enum t4_bar2_qtype { T4_BAR2_QTYPE_EGRESS, T4_BAR2_QTYPE_INGRESS };
-int t4_bar2_sge_qregs(struct adapter *adapter,
+int cxgb4_t4_bar2_sge_qregs(struct adapter *adapter,
unsigned int qid,
enum t4_bar2_qtype qtype,
u64 *pbar2_qoffset,
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index c8c5b3d36d4e..1645f59648f0 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -3815,7 +3815,7 @@ int cxgb4_bar2_sge_qregs(struct net_device *dev,
u64 *pbar2_qoffset,
unsigned int *pbar2_qid)
{
- return t4_bar2_sge_qregs(netdev2adap(dev),
+ return cxgb4_t4_bar2_sge_qregs(netdev2adap(dev),
qid,
(qtype == CXGB4_BAR2_QTYPE_EGRESS
? T4_BAR2_QTYPE_EGRESS
@@ -4011,7 +4011,7 @@ static void process_db_drop(struct work_struct *work)
unsigned int bar2_qid;
int ret;
- ret = t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS,
+ ret = cxgb4_t4_bar2_sge_qregs(adap, qid, T4_BAR2_QTYPE_EGRESS,
&bar2_qoffset, &bar2_qid);
if (ret)
dev_err(adap->pdev_dev, "doorbell drop recovery: "
diff --git a/drivers/net/ethernet/chelsio/cxgb4/sge.c b/drivers/net/ethernet/chelsio/cxgb4/sge.c
index f12debd98dac..ebf935a1e352 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/sge.c
@@ -2270,7 +2270,7 @@ static void __iomem *bar2_address(struct adapter *adapter,
u64 bar2_qoffset;
int ret;
- ret = t4_bar2_sge_qregs(adapter, qid, qtype,
+ ret = cxgb4_t4_bar2_sge_qregs(adapter, qid, qtype,
&bar2_qoffset, pbar2_qid);
if (ret)
return NULL;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
index 67345c73e570..28d04153f999 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_hw.c
@@ -4031,7 +4031,7 @@ int t4_prep_adapter(struct adapter *adapter)
}
/**
- * t4_bar2_sge_qregs - return BAR2 SGE Queue register information
+ * cxgb4_t4_bar2_sge_qregs - return BAR2 SGE Queue register information
* @adapter: the adapter
* @qid: the Queue ID
* @qtype: the Ingress or Egress type for @qid
@@ -4055,7 +4055,7 @@ int t4_prep_adapter(struct adapter *adapter)
* Write Combining Doorbell Buffer. If the BAR2 Queue ID is not 0,
* then these "Inferred Queue ID" register may not be used.
*/
-int t4_bar2_sge_qregs(struct adapter *adapter,
+int cxgb4_t4_bar2_sge_qregs(struct adapter *adapter,
unsigned int qid,
enum t4_bar2_qtype qtype,
u64 *pbar2_qoffset,
--
2.1.3
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply related
* [PATCH net-next] tipc: fix broadcast wakeup contention after congestion
From: richard.alpe @ 2014-12-10 8:46 UTC (permalink / raw)
To: netdev; +Cc: tipc-discussion, Richard Alpe, Erik Hugne
From: Richard Alpe <richard.alpe@ericsson.com>
commit 908344cdda80 ("tipc: fix bug in multicast congestion handling")
introduced a race in the broadcast link wakeup functionality.
This patch eliminates this broadcast link wakeup race caused by
operation on the wakeup list without proper locking. If this race
hit and corrupted the list all subsequent wakeup messages would be
lost, resulting in a considerable memory leak.
Signed-off-by: Richard Alpe <richard.alpe@ericsson.com>
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
---
net/tipc/link.c | 8 ++++----
net/tipc/node.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 34bf15c..23bcc11 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -293,7 +293,7 @@ struct tipc_link *tipc_link_create(struct tipc_node *n_ptr,
l_ptr->next_out_no = 1;
__skb_queue_head_init(&l_ptr->outqueue);
__skb_queue_head_init(&l_ptr->deferred_queue);
- __skb_queue_head_init(&l_ptr->waiting_sks);
+ skb_queue_head_init(&l_ptr->waiting_sks);
link_reset_statistics(l_ptr);
@@ -358,7 +358,7 @@ static bool link_schedule_user(struct tipc_link *link, u32 oport,
return false;
TIPC_SKB_CB(buf)->chain_sz = chain_sz;
TIPC_SKB_CB(buf)->chain_imp = imp;
- __skb_queue_tail(&link->waiting_sks, buf);
+ skb_queue_tail(&link->waiting_sks, buf);
link->stats.link_congs++;
return true;
}
@@ -378,8 +378,8 @@ static void link_prepare_wakeup(struct tipc_link *link)
if (pend_qsz >= link->queue_limit[TIPC_SKB_CB(skb)->chain_imp])
break;
pend_qsz += TIPC_SKB_CB(skb)->chain_sz;
- __skb_unlink(skb, &link->waiting_sks);
- __skb_queue_tail(&link->owner->waiting_sks, skb);
+ skb_unlink(skb, &link->waiting_sks);
+ skb_queue_tail(&link->owner->waiting_sks, skb);
}
}
diff --git a/net/tipc/node.c b/net/tipc/node.c
index 69b96be..8d353ec 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -115,7 +115,7 @@ struct tipc_node *tipc_node_create(u32 addr)
INIT_LIST_HEAD(&n_ptr->list);
INIT_LIST_HEAD(&n_ptr->publ_list);
INIT_LIST_HEAD(&n_ptr->conn_sks);
- __skb_queue_head_init(&n_ptr->waiting_sks);
+ skb_queue_head_init(&n_ptr->waiting_sks);
__skb_queue_head_init(&n_ptr->bclink.deferred_queue);
hlist_add_head_rcu(&n_ptr->hash, &node_htable[tipc_hashfn(addr)]);
--
2.1.3
^ permalink raw reply related
* Re: [patch v2] ipvs: uninitialized data with IP_VS_IPV6
From: Simon Horman @ 2014-12-10 8:47 UTC (permalink / raw)
To: Dan Carpenter
Cc: Julian Anastasov, Wensong Zhang, Pablo Neira Ayuso,
Patrick McHardy, Jozsef Kadlecsik, David S. Miller, netdev,
lvs-devel, netfilter-devel, coreteam, kernel-janitors
In-Reply-To: <20141209064947.GH4912@mwanda>
On Tue, Dec 09, 2014 at 09:49:47AM +0300, Dan Carpenter wrote:
> On Tue, Dec 09, 2014 at 09:52:15AM +0900, Simon Horman wrote:
> > On Sun, Dec 07, 2014 at 08:39:35PM +0200, Julian Anastasov wrote:
> > >
> > > Hello,
> > >
> > > On Sat, 6 Dec 2014, Dan Carpenter wrote:
> > >
> > > > The app_tcp_pkt_out() function expects "*diff" to be set and ends up
> > > > using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.
> > > >
> > > > The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov
> > > > for noticing that.
> > > >
> > > > Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> > > > ---
> > > > v2: fix app_tcp_pkt_in() as well. This is an old bug.
> > >
> > > Thanks! It will not break seqs for IPv6 control
> > > connection, only that we do not support FTP yet :( I have
> > > the doubt whether this should be classified as bugfix :)
> > > I guess, it is a net-next material, right?
> >
> > Agreed, I have queued it up in ipvs-next.
> > I'll send a pull request to Pablo if Dan doesn't object
> > to it going there.
>
> No objections from me.
Thanks, I have sent a pull-request.
^ permalink raw reply
* [PATCH nf-next] ipvs: uninitialized data with IP_VS_IPV6
From: Simon Horman @ 2014-12-10 8:46 UTC (permalink / raw)
To: lvs-devel
Cc: netdev, netfilter-devel, Wensong Zhang, Julian Anastasov,
Dan Carpenter, Simon Horman
In-Reply-To: <1418201201-19257-1-git-send-email-horms@verge.net.au>
From: Dan Carpenter <dan.carpenter@oracle.com>
The app_tcp_pkt_out() function expects "*diff" to be set and ends up
using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.
The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov
for noticing that.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
---
net/netfilter/ipvs/ip_vs_ftp.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_ftp.c b/net/netfilter/ipvs/ip_vs_ftp.c
index 1d5341f..5d3daae 100644
--- a/net/netfilter/ipvs/ip_vs_ftp.c
+++ b/net/netfilter/ipvs/ip_vs_ftp.c
@@ -183,6 +183,8 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp,
struct nf_conn *ct;
struct net *net;
+ *diff = 0;
+
#ifdef CONFIG_IP_VS_IPV6
/* This application helper doesn't work with IPv6 yet,
* so turn this into a no-op for IPv6 packets
@@ -191,8 +193,6 @@ static int ip_vs_ftp_out(struct ip_vs_app *app, struct ip_vs_conn *cp,
return 1;
#endif
- *diff = 0;
-
/* Only useful for established sessions */
if (cp->state != IP_VS_TCP_S_ESTABLISHED)
return 1;
@@ -322,6 +322,9 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp,
struct ip_vs_conn *n_cp;
struct net *net;
+ /* no diff required for incoming packets */
+ *diff = 0;
+
#ifdef CONFIG_IP_VS_IPV6
/* This application helper doesn't work with IPv6 yet,
* so turn this into a no-op for IPv6 packets
@@ -330,9 +333,6 @@ static int ip_vs_ftp_in(struct ip_vs_app *app, struct ip_vs_conn *cp,
return 1;
#endif
- /* no diff required for incoming packets */
- *diff = 0;
-
/* Only useful for established sessions */
if (cp->state != IP_VS_TCP_S_ESTABLISHED)
return 1;
--
2.1.3
^ permalink raw reply related
* [GIT PULL nf-next] Second round of IPVS Updates for v3.19
From: Simon Horman @ 2014-12-10 8:46 UTC (permalink / raw)
To: lvs-devel
Cc: netdev, netfilter-devel, Wensong Zhang, Julian Anastasov,
Simon Horman
Hi Pablo,
please consider these IPVS updates for v3.19 or alternatively v3.20.
The single patch in this series fixes a long standing bug that
has not caused any trouble and thus is not being prioritised as a fix.
The following changes since commit d6b00fec5dbbe976904b4d77e7d4f9493df5c2ec:
macvlan: play well with ipvlan device (2014-12-09 16:10:06 -0500)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/horms/ipvs-next.git tags/ipvs2-for-v3.19
for you to fetch changes up to 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f:
ipvs: uninitialized data with IP_VS_IPV6 (2014-12-10 17:36:47 +0900)
----------------------------------------------------------------
Dan Carpenter (1):
ipvs: uninitialized data with IP_VS_IPV6
net/netfilter/ipvs/ip_vs_ftp.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH net-next RESEND 2/2] ipv6: fix sparse warning
From: Ying Xue @ 2014-12-10 8:46 UTC (permalink / raw)
To: paulmck
Cc: davem, eric.dumazet, jon.maloy, erik.hugne, netdev, kbuild-all,
linux-kernel
In-Reply-To: <1418201167-9591-1-git-send-email-ying.xue@windriver.com>
This fixes the following spare warning when using
make C=1 CF=-D__CHECK_ENDIAN__ net/ipv6/addrconf.o
net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
To silence above spare complaint, an RCU annotation should be added
to "next" pointer of hlist_node structure through hlist_next_rcu()
macro when iterating over a hlist with
hlist_for_each_entry_continue_rcu_bh().
By the way, this commit also resolves the same error appearing in
hlist_for_each_entry_continue_rcu().
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
include/linux/rculist.h | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index 866d9c9..32bd4ad 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -524,11 +524,11 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n,
* @member: the name of the hlist_node within the struct.
*/
#define hlist_for_each_entry_continue_rcu(pos, member) \
- for (pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\
- typeof(*(pos)), member); \
+ for (pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \
+ &(pos)->member)), typeof(*(pos)), member); \
pos; \
- pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\
- typeof(*(pos)), member))
+ pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \
+ &(pos)->member)), typeof(*(pos)), member))
/**
* hlist_for_each_entry_continue_rcu_bh - iterate over a hlist continuing after current point
@@ -536,11 +536,11 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n,
* @member: the name of the hlist_node within the struct.
*/
#define hlist_for_each_entry_continue_rcu_bh(pos, member) \
- for (pos = hlist_entry_safe(rcu_dereference_bh((pos)->member.next),\
- typeof(*(pos)), member); \
+ for (pos = hlist_entry_safe(rcu_dereference_bh(hlist_next_rcu( \
+ &(pos)->member)), typeof(*(pos)), member); \
pos; \
- pos = hlist_entry_safe(rcu_dereference_bh((pos)->member.next),\
- typeof(*(pos)), member))
+ pos = hlist_entry_safe(rcu_dereference_bh(hlist_next_rcu( \
+ &(pos)->member)), typeof(*(pos)), member))
/**
* hlist_for_each_entry_from_rcu - iterate over a hlist continuing from current point
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next RESEND 1/2] tipc: fix RCU sparse error
From: Ying Xue @ 2014-12-10 8:46 UTC (permalink / raw)
To: paulmck
Cc: davem, eric.dumazet, jon.maloy, erik.hugne, netdev, kbuild-all,
linux-kernel
In-Reply-To: <1418201167-9591-1-git-send-email-ying.xue@windriver.com>
The commit 97ede29e80ee ("tipc: convert name table read-write lock to
RCU") involves the following sparse when using
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
net/tipc/name_table.c:1136:17: sparse: incompatible types in comparison expression (different address spaces)
net/tipc/name_table.c:1136:17: sparse: incompatible types in comparison expression (different address spaces)
To silence above spare complaint, an RCU annotation should be added
to "next" pointer of hlist_node structure through hlist_next_rcu()
macro when iterating over a hlist with hlist_for_each_entry_from_rcu().
By the way, this commit also simplifies the way of dereferencing
the first element of a hlist_head list by replacing
hlist_for_each_entry_rcu() with hlist_entry_safe().
Reported-by: Kbuild test robot <kbuild-all@01.org>
Cc: Kbuild test robot <kbuild-all@01.org>
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
include/linux/rculist.h | 4 ++--
net/tipc/name_table.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/rculist.h b/include/linux/rculist.h
index aa79b3c..866d9c9 100644
--- a/include/linux/rculist.h
+++ b/include/linux/rculist.h
@@ -549,8 +549,8 @@ static inline void hlist_add_behind_rcu(struct hlist_node *n,
*/
#define hlist_for_each_entry_from_rcu(pos, member) \
for (; pos; \
- pos = hlist_entry_safe(rcu_dereference((pos)->member.next),\
- typeof(*(pos)), member))
+ pos = hlist_entry_safe(rcu_dereference_raw(hlist_next_rcu( \
+ &(pos)->member)), typeof(*(pos)), member))
#endif /* __KERNEL__ */
#endif
diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index c8df022..fa4341f 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -1110,7 +1110,7 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg, u32 *last_type,
u32 *last_lower, u32 *last_publ)
{
struct hlist_head *seq_head;
- struct name_seq *seq = NULL;
+ struct name_seq *seq;
int err;
int i;
@@ -1127,8 +1127,8 @@ static int __tipc_nl_seq_list(struct tipc_nl_msg *msg, u32 *last_type,
if (!seq)
return -EPIPE;
} else {
- hlist_for_each_entry_rcu(seq, seq_head, ns_list)
- break;
+ seq = hlist_entry_safe(rcu_dereference_raw(
+ hlist_first_rcu(seq_head)), struct name_seq, ns_list);
if (!seq)
continue;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH net-next RESEND 0/2] fix rculist sparse errors
From: Ying Xue @ 2014-12-10 8:46 UTC (permalink / raw)
To: paulmck
Cc: davem, eric.dumazet, jon.maloy, erik.hugne, netdev, kbuild-all,
linux-kernel
When hlist_for_each_entry_continue_rcu_bh() gets "next" pointer of
hlist_node structure through rcu_dereference_bh(), sparse warning
appears as the "next" pointer is not annotated as __rcu. So if
the "next" pointer is accessed with hlist_next_rcu() macro, the
__rcu annotation will be added to the pointer. As a consequence,
sparse warning is eliminated too.
The similar errors also appear in hlist_for_each_entry_continue_rcu()
and hlist_for_each_entry_from_rcu().
In this version, CC more people like Paul E. McKenney and lkml mail
list.
Ying Xue (2):
tipc: fix RCU sparse error
ipv6: fix sparse warning
include/linux/rculist.h | 20 ++++++++++----------
net/tipc/name_table.c | 6 +++---
2 files changed, 13 insertions(+), 13 deletions(-)
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH v2] net: introduce helper macro for_each_cmsghdr
From: Gu Zheng @ 2014-12-10 8:15 UTC (permalink / raw)
To: Joe Perches; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <1418194583.1047.8.camel@perches.com>
Hi Joe,
On 12/10/2014 02:56 PM, Joe Perches wrote:
> On Wed, 2014-12-10 at 13:36 +0800, Gu Zheng wrote:
>> Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
>> cmsghdr from msghdr, just cleanup.
>
> This looks nicer.
> Ideally this would have used: [PATCH V3] as the subject
Thanks for your review.
The previous v2 thread was marked as mistake, so this is the really active
v2 version.
Regards,
Gu
>
>> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
>> ---
>> v2: use the lower-case macro name as Joe suggested.
>
> And a description of the v2->v3 change here.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* [PATCH iproute2 v3] ip link: Show devices by type
From: Vadim Kochan @ 2014-12-10 8:11 UTC (permalink / raw)
To: netdev; +Cc: Vadim Kochan
From: Vadim Kochan <vadim4j@gmail.com>
Added new option 'type' to 'ip link show'
command which allows to filter devices by type:
ip link show type bridge
ip link show type vlan
Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
---
Changes v2 -> v3
Fixed conflicts in man/man8/ip-link.8.in
ip/ipaddress.c | 26 ++++++++++++++++++++++++++
ip/iplink.c | 2 +-
man/man8/ip-link.8.in | 19 ++++++++++++++++++-
3 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 221ae1f..e1e26a7 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -57,6 +57,7 @@ static struct
int flushe;
int group;
int master;
+ char *kind;
} filter;
static int do_link;
@@ -189,6 +190,18 @@ static void print_linkmode(FILE *f, struct rtattr *tb)
fprintf(f, "mode %s ", link_modes[mode]);
}
+static char *parse_link_kind(struct rtattr *tb)
+{
+ struct rtattr *linkinfo[IFLA_INFO_MAX+1];
+
+ parse_rtattr_nested(linkinfo, IFLA_INFO_MAX, tb);
+
+ if (linkinfo[IFLA_INFO_KIND])
+ return RTA_DATA(linkinfo[IFLA_INFO_KIND]);
+
+ return "";
+}
+
static void print_linktype(FILE *fp, struct rtattr *tb)
{
struct rtattr *linkinfo[IFLA_INFO_MAX+1];
@@ -551,6 +564,16 @@ int print_linkinfo(const struct sockaddr_nl *who,
else if (filter.master > 0)
return -1;
+ if (filter.kind) {
+ if (tb[IFLA_LINKINFO]) {
+ char *kind = parse_link_kind(tb[IFLA_LINKINFO]);
+ if (strcmp(kind, filter.kind))
+ return -1;
+ } else {
+ return -1;
+ }
+ }
+
if (n->nlmsg_type == RTM_DELLINK)
fprintf(fp, "Deleted ");
@@ -1293,6 +1316,9 @@ static int ipaddr_list_flush_or_save(int argc, char **argv, int action)
if (!ifindex)
invarg("Device does not exist\n", *argv);
filter.master = ifindex;
+ } else if (do_link && strcmp(*argv, "type") == 0) {
+ NEXT_ARG();
+ filter.kind = *argv;
} else {
if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/iplink.c b/ip/iplink.c
index ce6eb3e..f9a75d5 100644
--- a/ip/iplink.c
+++ b/ip/iplink.c
@@ -82,7 +82,7 @@ void iplink_usage(void)
fprintf(stderr, " [ master DEVICE ]\n");
fprintf(stderr, " [ nomaster ]\n");
fprintf(stderr, " [ addrgenmode { eui64 | none } ]\n");
- fprintf(stderr, " ip link show [ DEVICE | group GROUP ] [up] [master DEV]\n");
+ fprintf(stderr, " ip link show [ DEVICE | group GROUP ] [up] [master DEV] [type TYPE]\n");
if (iplink_have_newlink()) {
fprintf(stderr, " ip link help [ TYPE ]\n");
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 6fd8de6..5134e28 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -148,7 +148,9 @@ ip-link \- network device configuration
.IR GROUP " | "
.BR up " | "
.B master
-.IR DEVICE " ]"
+.IR DEVICE " | "
+.B type
+.IR TYPE " ]"
.ti -8
.B ip link help
@@ -689,6 +691,11 @@ only display running interfaces.
specifies the master device which enslaves devices to show.
.TP
+.BI type " TYPE "
+.I TYPE
+specifies the type of devices to show.
+
+.TP
The show command has additional formatting options:
.RS
@@ -722,6 +729,16 @@ ip link show
Shows the state of all network interfaces on the system.
.RE
.PP
+ip link show type bridge
+.RS 4
+Shows the bridge devices.
+.RE
+.PP
+ip link show type vlan
+.RS 4
+Shows the vlan devices.
+.RE
+.PP
ip link set dev ppp0 mtu 1400
.RS 4
Change the MTU the ppp0 device.
--
2.1.3
^ permalink raw reply related
* [PATCH net-next v2] enic: add support for set/get rss hash key
From: Govindarajulu Varadarajan @ 2014-12-10 8:10 UTC (permalink / raw)
To: davem, netdev; +Cc: ssujith, benve, Govindarajulu Varadarajan
This patch adds support for setting/getting rss hash key using ethtool.
v2:
respin patch to support RSS hash function changes.
Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
---
drivers/net/ethernet/cisco/enic/enic.h | 2 ++
drivers/net/ethernet/cisco/enic/enic_ethtool.c | 38 ++++++++++++++++++++++++++
drivers/net/ethernet/cisco/enic/enic_main.c | 13 ++++++---
3 files changed, 49 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic.h b/drivers/net/ethernet/cisco/enic/enic.h
index 5ba5ad0..25c4d88 100644
--- a/drivers/net/ethernet/cisco/enic/enic.h
+++ b/drivers/net/ethernet/cisco/enic/enic.h
@@ -187,6 +187,7 @@ struct enic {
unsigned int cq_count;
struct enic_rfs_flw_tbl rfs_h;
u32 rx_copybreak;
+ u8 rss_key[ENIC_RSS_LEN];
};
static inline struct device *enic_get_dev(struct enic *enic)
@@ -246,5 +247,6 @@ int enic_sriov_enabled(struct enic *enic);
int enic_is_valid_vf(struct enic *enic, int vf);
int enic_is_dynamic(struct enic *enic);
void enic_set_ethtool_ops(struct net_device *netdev);
+int __enic_set_rsskey(struct enic *enic);
#endif /* _ENIC_H_ */
diff --git a/drivers/net/ethernet/cisco/enic/enic_ethtool.c b/drivers/net/ethernet/cisco/enic/enic_ethtool.c
index 85173d6..eba1eb8 100644
--- a/drivers/net/ethernet/cisco/enic/enic_ethtool.c
+++ b/drivers/net/ethernet/cisco/enic/enic_ethtool.c
@@ -23,6 +23,7 @@
#include "enic.h"
#include "enic_dev.h"
#include "enic_clsf.h"
+#include "vnic_rss.h"
struct enic_stat {
char name[ETH_GSTRING_LEN];
@@ -416,6 +417,40 @@ static int enic_set_tunable(struct net_device *dev,
return ret;
}
+static u32 enic_get_rxfh_key_size(struct net_device *netdev)
+{
+ return ENIC_RSS_LEN;
+}
+
+static int enic_get_rxfh(struct net_device *netdev, u32 *indir, u8 *hkey,
+ u8 *hfunc)
+{
+ struct enic *enic = netdev_priv(netdev);
+
+ if (hkey)
+ memcpy(hkey, enic->rss_key, ENIC_RSS_LEN);
+
+ if (hfunc)
+ *hfunc = ETH_RSS_HASH_TOP;
+
+ return 0;
+}
+
+static int enic_set_rxfh(struct net_device *netdev, const u32 *indir,
+ const u8 *hkey, const u8 hfunc)
+{
+ struct enic *enic = netdev_priv(netdev);
+
+ if ((hfunc != ETH_RSS_HASH_NO_CHANGE && hfunc != ETH_RSS_HASH_TOP) ||
+ indir)
+ return -EINVAL;
+
+ if (hkey)
+ memcpy(enic->rss_key, hkey, ENIC_RSS_LEN);
+
+ return __enic_set_rsskey(enic);
+}
+
static const struct ethtool_ops enic_ethtool_ops = {
.get_settings = enic_get_settings,
.get_drvinfo = enic_get_drvinfo,
@@ -430,6 +465,9 @@ static const struct ethtool_ops enic_ethtool_ops = {
.get_rxnfc = enic_get_rxnfc,
.get_tunable = enic_get_tunable,
.set_tunable = enic_set_tunable,
+ .get_rxfh_key_size = enic_get_rxfh_key_size,
+ .get_rxfh = enic_get_rxfh,
+ .set_rxfh = enic_set_rxfh,
};
void enic_set_ethtool_ops(struct net_device *netdev)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index 86ee350..868d0f6 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -1888,11 +1888,10 @@ static int enic_dev_hang_reset(struct enic *enic)
return err;
}
-static int enic_set_rsskey(struct enic *enic)
+int __enic_set_rsskey(struct enic *enic)
{
union vnic_rss_key *rss_key_buf_va;
dma_addr_t rss_key_buf_pa;
- u8 rss_key[ENIC_RSS_LEN];
int i, kidx, bidx, err;
rss_key_buf_va = pci_zalloc_consistent(enic->pdev,
@@ -1901,11 +1900,10 @@ static int enic_set_rsskey(struct enic *enic)
if (!rss_key_buf_va)
return -ENOMEM;
- netdev_rss_key_fill(rss_key, ENIC_RSS_LEN);
for (i = 0; i < ENIC_RSS_LEN; i++) {
kidx = i / ENIC_RSS_BYTES_PER_KEY;
bidx = i % ENIC_RSS_BYTES_PER_KEY;
- rss_key_buf_va->key[kidx].b[bidx] = rss_key[i];
+ rss_key_buf_va->key[kidx].b[bidx] = enic->rss_key[i];
}
spin_lock_bh(&enic->devcmd_lock);
err = enic_set_rss_key(enic,
@@ -1919,6 +1917,13 @@ static int enic_set_rsskey(struct enic *enic)
return err;
}
+static int enic_set_rsskey(struct enic *enic)
+{
+ netdev_rss_key_fill(enic->rss_key, ENIC_RSS_LEN);
+
+ return __enic_set_rsskey(enic);
+}
+
static int enic_set_rsscpu(struct enic *enic, u8 rss_hash_bits)
{
dma_addr_t rss_cpu_buf_pa;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2 tuntap: Increase the number of queues in tun.
From: Pankaj Gupta @ 2014-12-10 7:56 UTC (permalink / raw)
To: Jason Wang, Michael S. Tsirkin
Cc: linux-kernel, netdev, davem, dgibson, vfalico, edumazet, vyasevic,
hkchu, wuzhy, xemul, therbert, bhutchings, xii, stephen, jiri,
sergei shtylyov
In-Reply-To: <5481602E.1030508@redhat.com>
>
> On 12/04/2014 06:20 PM, Michael S. Tsirkin wrote:
> > On Thu, Dec 04, 2014 at 03:03:34AM +0008, Jason Wang wrote:
> >> >
> >> >
> >> > On Wed, Dec 3, 2014 at 5:52 PM, Michael S. Tsirkin <mst@redhat.com>
> >> > wrote:
> >>> > >On Wed, Dec 03, 2014 at 12:49:37PM +0530, Pankaj Gupta wrote:
> >>>> > >> Networking under kvm works best if we allocate a per-vCPU RX and TX
> >>>> > >> queue in a virtual NIC. This requires a per-vCPU queue on the host
> >>>> > >>side.
> >>>> > >> It is now safe to increase the maximum number of queues.
> >>>> > >> Preceding patche: 'net: allow large number of rx queues'
> >>> > >
> >>> > >s/patche/patch/
> >>> > >
> >>>> > >> made sure this won't cause failures due to high order memory
> >>>> > >> allocations. Increase it to 256: this is the max number of vCPUs
> >>>> > >> KVM supports.
> >>>> > >> Signed-off-by: Pankaj Gupta <pagupta@redhat.com>
> >>>> > >> Reviewed-by: David Gibson <dgibson@redhat.com>
> >>> > >
> >>> > >Hmm it's kind of nasty that each tun device is now using x16 memory.
> >>> > >Maybe we should look at using a flex array instead, and removing the
> >>> > >limitation altogether (e.g. make it INT_MAX)?
> >> >
> >> > But this only happens when IFF_MULTIQUEUE were used.
> > I refer to this field:
> > struct tun_file __rcu *tfiles[MAX_TAP_QUEUES];
> > if we make MAX_TAP_QUEUES 256, this will use 4K bytes,
> > apparently unconditionally.
> >
> >
>
> How about just allocate one tfile if IFF_MULTIQUEUE were disabled?
Yes, we can also go with one tfile if for single queue.
As tfiles is array of 'tun_file' pointers with size 256. For multiqueue
we would be using 256 queues. But for single queue if we have one tfile
makes sense.
Also, we are making sure to avoid memory failures with vzalloc.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: Antw: Re: Q: need effective backlog for listen()
From: Ulrich Windl @ 2014-12-10 7:23 UTC (permalink / raw)
To: phil; +Cc: netdev
In-Reply-To: <1418137657.384.17.camel@niobium.home.fifi.org>
>>> Philippe Troin <phil@fifi.org> schrieb am 09.12.2014 um 16:07 in Nachricht
<1418137657.384.17.camel@niobium.home.fifi.org>:
> On Tue, 2014-12-09 at 08:01 +0100, Ulrich Windl wrote:
>> >>> Philippe Troin <phil@fifi.org> schrieb am 08.12.2014 um 17:35 in Nachricht
>> <1418056540.384.5.camel@niobium.home.fifi.org>:
>>
>> > The argument to listen() specifies how many connections the system is
>> > allow to keep waiting to be accept()ed.
>> > As soon as you accept() the connection, the count is decremented.
>> > So that won't help for your use case.
>> >
>> >> However none of the above see ms true. Even if my server delays
>> >> accept()ing new connections, no client ever sees a "connection
>> >> refused" or "connection timed out". Is there any chance to signal the
>> >> client that no more connections are accepted at the moment?
>> >
>> > Close the listening socket. No new connections will be accepted.
>> > When you reopen the socket for accepting new connections, you may have
>> > to use SO_REUSEADDR before bind()ing to the port.
>>
>> This is what I had done, but those connections who are waiting to be
>> accepted: If I close the listening socket, will the clients see a
>> connection abort, or will they see a connection refused?
>> Connection aborts could confuse clients.
>
> The clients that completed the 3-way handshake and are waiting for their
> (server-side) socket to be accept()ed will see connection reset I
> believe.
>
> You may be able to work something out by having no listen backlog
> (listen(0)) and closing and reopening the socket when needed.
I think I'd feel happier if listen() would implement the old semantics by default, and a new ioctl() (or such) would change to the "Linux accept all connections (3-way handshake) mode" on demand... Wishful thinking...
Ulrich
^ permalink raw reply
* RE: [PATCH net-next 0/9] r8169:update hardware ephy parameter
From: Hau @ 2014-12-10 7:17 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, nic_swsd, linux-kernel@vger.kernel.org
In-Reply-To: <20141209.183549.1930188640715074097.davem@davemloft.net>
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, December 10, 2014 7:36 AM
> To: Hau
> Cc: netdev@vger.kernel.org; nic_swsd; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH net-next 0/9] r8169:update hardware ephy parameter
>
> From: Chunhao Lin <hau@realtek.com>
> Date: Wed, 10 Dec 2014 00:45:54 +0800
>
> > Update hardware ephy parameter to improve pcie compatibility.
>
> This really doesn't tell me anything, I really dislike patch series like this one.
>
> All of the programming is magic values to magic offsets.
>
> You aren't even trying to describe in the commit log message exactly what
> kind of settings are being changed, and exactly how those changes achieve
> the stated goal.
>
> Furthermore, the commit description makes no sense at all to me.
>
> How can programming the ethernet MAC PHY have any influence on PCI-E
> bus compatability? Or are you programming the PCI bus interface's PHY?
>
> In what way are you adjusting which settings and in what way do those
> adjustments help improve PCI-E bus behavior?
>
> You absolutely must describe exactly what the new programming is actually
> doing, precisely, and in detail. I want to know if some kind of timings are
> being adjusted, and in what way.
> Are some fifo limits being changes? If so, in what way, and why does that
> help.
>
> You have to describe what you are doing. Short and non-informative commit
> log messages alongside random changes to undocumented magic constant
> registers is simply unacceptable.
>
These series patch is an alignment with our latest hardware pcie ephy parameters. I will try to explain more on my next patch.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] net: introduce helper macro for_each_cmsghdr
From: Joe Perches @ 2014-12-10 6:56 UTC (permalink / raw)
To: Gu Zheng; +Cc: David S. Miller, netdev, linux-kernel
In-Reply-To: <5487DBD9.1010908@cn.fujitsu.com>
On Wed, 2014-12-10 at 13:36 +0800, Gu Zheng wrote:
> Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
> cmsghdr from msghdr, just cleanup.
This looks nicer.
Ideally this would have used: [PATCH V3] as the subject
> Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
> ---
> v2: use the lower-case macro name as Joe suggested.
And a description of the v2->v3 change here.
^ permalink raw reply
* Re: [PATCH v8 3/3] net: hisilicon: new hip04 ethernet driver
From: Ding Tianhong @ 2014-12-10 6:45 UTC (permalink / raw)
To: Arnd Bergmann, Alexander Graf
Cc: Zhangfei Gao, davem, linux, f.fainelli, sergei.shtylyov,
mark.rutland, David.Laight, eric.dumazet, xuwei5,
linux-arm-kernel, netdev, devicetree
In-Reply-To: <5487C357.9030507@huawei.com>
On 2014/12/10 11:51, Ding Tianhong wrote:
> On 2014/12/8 4:09, Arnd Bergmann wrote:
>> On Sunday 07 December 2014 10:49:12 Alexander Graf wrote:
>>> On 07.12.14 04:28, Ding Tianhong wrote:
>>>> On 2014/12/7 8:42, Alexander Graf wrote:
>>>>> On 19.04.14 03:13, Zhangfei Gao wrote:
>>>>>> Support Hisilicon hip04 ethernet driver, including 100M / 1000M controller.
>>>>>> The controller has no tx done interrupt, reclaim xmitted buffer in the poll.
>>>>>>
>>>>>> Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
>>>>>
>>>>> Is this driver still supposed to go upstream? I presume this was the
>>>>> last submission and it's been quite some time ago
>>>>>
>>>>
>>>> yes, it is really a long time, but The hip04 did not support tx irq,
>>>> we couldn't get any better idea to fix this defect, do you have any suggestion?
>>>
>>> Well, if hardware doesn't have a TX irq I don't see there's anything we
>>> can do to fix that ;).
>>
>> I don't know if it's related to the ethernet on hip01, but I would assume
>> it is, and that platform is currently being submitted for inclusion, so
>> I'd definitely hope to see this driver get merged too eventually.
>>
>> IIRC, the last revision of the patch set had basically fixed the problem,
>> except for a race that would still allow the napi poll function to exit
>> with poll_complete() but a full queue of TX descriptors and no fallback
>> to clean them up. There was also still an open question about whether or
>> not the driver should use skb_orphan, but I may be misremembering that part.
>>
>
> Hi Arnd:
>
> what about use a state machine to check the tx queue and free the skb, just like:
>
> diff --git a/drivers/net/ethernet/hisilicon/hip04_eth.c b/drivers/net/ethernet/hisilicon/hip04_eth.c
> index 8593658..71faca8 100644
> --- a/drivers/net/ethernet/hisilicon/hip04_eth.c
> +++ b/drivers/net/ethernet/hisilicon/hip04_eth.c
> @@ -396,9 +396,25 @@ static int hip04_mac_start_xmit(struct sk_buff *skb, struct net_device *ndev)
> stats->tx_packets++;
> priv->tx_count++;
>
> +
> + queue_delayed_work(priv->wq, &priv->tx_queue, delay);
> +
> return NETDEV_TX_OK;
> }
>
> +static void hip04_tx_queue_monitor(struct work_struct *work)
> +{
> + struct hip04_priv *priv = container_of(work, struct hip04_priv,
> + queue_work.work);
> + struct net_device *dev = priv->ndev;
> + hip04_tx_reclain(ndev, false);
> +
> + if (TX_QUEUE_IS_EMPRY(ndev))
> + return;
> +
> + queue_delayed_work(priv->wq, &priv->tx_queue, delay);
> +}
> +
> static int hip04_rx_poll(struct napi_struct *napi, int budget)
> {
> struct hip04_priv *priv = container_of(napi, struct hip04_priv, napi);
> @@ -736,6 +752,8 @@ static int hip04_mac_probe(struct platform_device *pdev)
> goto alloc_fail;
> }
>
> + INIT_DELAYED_WORK(&priv->tx_queue, hip04_tx_queue_monitor);
> +
> return 0;
>
>
>
> what do you think of this solution?
>
> Regards
> Ding
>
Miss this code, I think the best way is skb_orphan(skb), just like the cxgb3 drivers, some hardware
didn't use the tx inq to free dmad Tx packages.
Ding
>
>>> Dave, what's your take here? Should we keep a driver from going upstream
>>> just because the hardware is partly broken? I'd really prefer to have an
>>> upstream driver on that SoC rather than some random (eventually even
>>> more broken) downstream code.
>>
>> We can certainly have a slow driver for this hardware, and I'd much
>> prefer slow over broken. I'd guess that some of the performance impact
>> of the missing interrupts can now be offset with the xmit_more logic.
>>
>> Arnd
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> .
>>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: [PATCHv11 net-next 2/2] openvswitch: Add support for unique flow IDs.
From: Pravin Shelar @ 2014-12-10 6:11 UTC (permalink / raw)
To: Joe Stringer; +Cc: netdev, LKML, dev@openvswitch.org
In-Reply-To: <CANr6G5yOqVkA6hf3J9mk41Kh=0k3sM3tQx4sdADSgFaAx9xrWg@mail.gmail.com>
On Tue, Dec 9, 2014 at 4:25 PM, Joe Stringer <joestringer@nicira.com> wrote:
> On 9 December 2014 at 10:32, Pravin Shelar <pshelar@nicira.com> wrote:
>> On Tue, Dec 2, 2014 at 6:56 PM, Joe Stringer <joestringer@nicira.com> wrote:
>>> @@ -662,11 +664,18 @@ static void get_dp_stats(const struct datapath *dp, struct ovs_dp_stats *stats,
>>> }
>>> }
>>> + error = ovs_nla_copy_ufid(a[OVS_FLOW_ATTR_UFID], &ufid, log);
>>> + if (error)
>>> + return error;
>>> + if (a[OVS_FLOW_ATTR_KEY]) {
>>> + ovs_match_init(&match, &key, &mask);
>>> + error = ovs_nla_get_match(&match, a[OVS_FLOW_ATTR_KEY],
>>> + a[OVS_FLOW_ATTR_MASK], log);
>>> + } else if (!ufid) {
>>> OVS_NLERR(log, "Flow key attribute not present in set flow.");
>>> - goto error;
>>> + error = -EINVAL;
>>> }
>>> -
>>> - ovs_match_init(&match, &key, &mask);
>>> - error = ovs_nla_get_match(&match, a[OVS_FLOW_ATTR_KEY],
>>> - a[OVS_FLOW_ATTR_MASK], log);
>>> if (error)
>>> goto error;
>>>
>>> - /* Validate actions. */
>>> - if (a[OVS_FLOW_ATTR_ACTIONS]) {
>>> - acts = get_flow_actions(a[OVS_FLOW_ATTR_ACTIONS], &key, &mask,
>>> - log);
>>> - if (IS_ERR(acts)) {
>>> - error = PTR_ERR(acts);
>>> - goto error;
>>> - }
>>> -
>>> - /* Can allocate before locking if have acts. */
>>> - reply = ovs_flow_cmd_alloc_info(acts, info, false);
>>> - if (IS_ERR(reply)) {
>>> - error = PTR_ERR(reply);
>>> - goto err_kfree_acts;
>>> - }
>>> - }
>>> -
>> Why are you moving this action validation under ovs-lock?
>
> The thought was that flow_cmd_set may receive UFID and not key/mask.
> One could imagine a command that sends a UFID and actions, telling OVS
> kmod to update just the actions. Masked key is required for
> ovs_nla_copy_actions(), so in this case a lookup would be required to
> get a masked key.
>
> Perhaps the better alternative for the moment is to still require flow
> key and mask for this command (just as we do for flow_cmd_new). That
> would simplify this change greatly, and doesn't affect current OVS
> userspace.
>
sounds good.
>>> @@ -1194,9 +1254,18 @@ unlock:
>>>
>>> static int ovs_flow_cmd_dump(struct sk_buff *skb, struct netlink_callback *cb)
>>> {
>>> + struct nlattr *a[__OVS_FLOW_ATTR_MAX];
>>> struct ovs_header *ovs_header = genlmsg_data(nlmsg_data(cb->nlh));
>>> struct table_instance *ti;
>>> struct datapath *dp;
>>> + u32 ufid_flags;
>>> + int err;
>>> +
>>> + err = nlmsg_parse(cb->nlh, GENL_HDRLEN + dp_flow_genl_family.hdrsize,
>>> + a, dp_flow_genl_family.maxattr, flow_policy);
>>
>> Can you add genl helper function for this?
>
> OK.
>
>>> @@ -1235,6 +1304,8 @@ static const struct nla_policy flow_policy[OVS_FLOW_ATTR_MAX + 1] = {
>>> [OVS_FLOW_ATTR_ACTIONS] = { .type = NLA_NESTED },
>>> [OVS_FLOW_ATTR_CLEAR] = { .type = NLA_FLAG },
>>> [OVS_FLOW_ATTR_PROBE] = { .type = NLA_FLAG },
>>> + [OVS_FLOW_ATTR_UFID] = { .type = NLA_UNSPEC },
>>> + [OVS_FLOW_ATTR_UFID_FLAGS] = { .type = NLA_U32 },
>>> };
>>>
>>> static const struct genl_ops dp_flow_genl_ops[] = {
>>> diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
>>> index a8b30f3..7f31dbf 100644
>>> --- a/net/openvswitch/flow.h
>>> +++ b/net/openvswitch/flow.h
>>> @@ -197,6 +197,13 @@ struct sw_flow_match {
>>> struct sw_flow_mask *mask;
>>> };
>>>
>>> +#define MAX_UFID_LENGTH 256
>>> +
>> For now we can limit this to 128 bits.
>
> Is there a reason beyond trying to avoid the warning in flow_cmd_set()?
> I suppose that its purpose as an identifier means that it's unlikely to
> need to be much bigger in future (indeed, the larger it gets, the more
> it would trade off the performance gains from using it).
>
I am also not sure why would we need ID larger than 128 bit. In such
unlikely scenario I think we can increase it later if we need it.
>>> @@ -213,13 +220,16 @@ 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_hash, ufid_hash;
>> I am not sure about _hash suffix here, Can you explain it? I think
>> _table is better.
>
> Agreed, table is better.
>
>>> 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 *ufid;
>> Lets move this structure inside sw_flow, so that we can avoid one
>> kmalloc during flow-install in case of UFID. something like:
>>
>> struct {
>> u32 ufid_len;
>> union {
>> u32 ufid[MAX_UFID_LENGTH / 4];
>> struct sw_flow_key *unmasked_key;
>> }
>> } id;
>
> Agreed.
>
>>> @@ -424,10 +475,9 @@ static struct sw_flow *masked_flow_lookup(struct table_instance *ti,
>>> ovs_flow_mask_key(&masked_key, unmasked, mask);
>>> hash = flow_hash(&masked_key, key_start, key_end);
>>> head = find_bucket(ti, hash);
>>> - hlist_for_each_entry_rcu(flow, head, hash_node[ti->node_ver]) {
>>> - if (flow->mask == mask && flow->hash == hash &&
>>> - flow_cmp_masked_key(flow, &masked_key,
>>> - key_start, key_end))
>>> + hlist_for_each_entry_rcu(flow, head, flow_hash.node[ti->node_ver]) {
>>> + if (flow->mask == mask && flow->flow_hash.hash == hash &&
>>> + flow_cmp_masked_key(flow, &masked_key, key_start, key_end))
>>> return flow;
>>> }
>>> return NULL;
>>> @@ -469,7 +519,40 @@ struct sw_flow *ovs_flow_tbl_lookup_exact(struct flow_table *tbl,
>>> /* Always called under ovs-mutex. */
>>> list_for_each_entry(mask, &tbl->mask_list, list) {
>>> flow = masked_flow_lookup(ti, match->key, mask);
>>> - if (flow && ovs_flow_cmp_unmasked_key(flow, match)) /* Found */
>>> + if (flow && !flow->ufid &&
>> why not NULL check for flow->unmasked_key here rather than ufid?
>
> In this version, I tried to consistently use flow->ufid as the switch
> for whether UFID exists or not. In the next version, this statement
> would refer to flow->id->ufid_len.
>
> The current approach means that ovs_flow_tbl_lookup_exact() is really
> ovs_flow_tbl_lookup_unmasked_key(). Do you think this should remain
> specific to unmasked key or should it be made to check that the
> identifier (ufid OR unmasked key) is the same?
It is easier to read code if we check for flow->unmasked_key here.
ovs_flow_cmp_unmasked_key() has assert on ufid anyways.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: fix sparse warning
From: Ying Xue @ 2014-12-10 5:54 UTC (permalink / raw)
To: Eric Dumazet, davem; +Cc: netdev
In-Reply-To: <1418190018.27198.12.camel@edumazet-glaptop2.roam.corp.google.com>
On 12/10/2014 01:40 PM, Eric Dumazet wrote:
> On Wed, 2014-12-10 at 11:28 +0800, Ying Xue wrote:
>> This fixes the following sparse warning when using
>>
>> make C=1 CF=-D__CHECK_ENDIAN__ net/ipv6/addrconf.o
>> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
>> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
>> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
>> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
>>
>> To silence above spare complaint, an RCU annotation should be added
>> to next pointer of hlist_node structure through hlist_next_rcu() macro
>> when iterating over a hlist with hlist_for_each_entry_continue_rcu_bh().
>>
>> By the way, this commit also resolves the same error appearing in
>> hlist_for_each_entry_continue_rcu().
>
> This probably should be sent to lkml and CC Paul E. McKenney
>
>
>
>
I prefer that the patch as well as another similar patch ("tipc: fix RCU
sparse error") are still based on net-next tree, but I will CC Paul E.
McKenney and lkml when resend them, is it ok?
Especially for the patch ("tipc: fix RCU sparse error"), it fixes the
sparse error introduced by the commit 97ede29e80ee ("tipc: convert name
table read-write lock to RCU") which was only merged into net-next tree.
Regards,
Ying
^ permalink raw reply
* ipv6: oops in datagram.c line 260
From: Chris Ruehl @ 2014-12-10 5:43 UTC (permalink / raw)
To: netdev
Hi all,
We running a Dell server which crash frequently with (dell crash video
snapshot) vanilla 3.14.25
Capture viewed here: http://www.gtsys.com.hk/~chris/datagram_c_line260.png
The capture don't sadly don't show the full trace, so we lack on
information.
1st line I can see in the crash video from the idrac :
tcp_transmit_skb+0x461
RIP [<ffffffff815da587>] ipv6_local_error+0x17/0x140
The null pointer happen:
Type "apropos word" to search for commands related to "word"...
Reading symbols from net/ipv6/datagram.o...done.
(gdb) list *(ipv6_local_error+0x17)
0xae7 is in ipv6_local_error (net/ipv6/datagram.c:260).
255 struct ipv6_pinfo *np = inet6_sk(sk);
256 struct sock_exterr_skb *serr;
257 struct ipv6hdr *iph;
258 struct sk_buff *skb;
259
260 if (!np->recverr)
261 return;
262
263 skb = alloc_skb(sizeof(struct ipv6hdr), GFP_ATOMIC);
264 if (!skb)
(gdb) quit
We running a 6in4 with ipsec tunnel on the 6. I found a pull request from
Steffen Klassert
here:
http://article.gmane.org/gmane.linux.network/281469
Which might be relevant to this problem.
For time being I add a
if (np == NULL){
LIMIT_NETDEBUG(KERN_DEBUG "ipv6_pinfo is NULL\n");
return;
}
as work around to stop the server crashing
With kind regards
Chris
^ permalink raw reply
* [PATCH v2] if_bridge: fix conflict with glibc
From: Stephen Hemminger @ 2014-12-10 5:41 UTC (permalink / raw)
To: David Miller; +Cc: gregory.0xf0, f.fainelli, xiyou.wangcong, netdev
In-Reply-To: <20141209.234954.1634249639621060084.davem@davemloft.net>
Even though kernel and glibc headers have same effective values
Gcc complains about redefinitions. Since this is a header expected
to be used by userspace, use glibc header.
This supersedes change in commit 66f1c44887ba4f47d617f8ae21cf8e04e1892bd7
and fixes build of iproute2 with Glibc-2.19. This follows similar usage
in include/uapi/linux for l2tp.h
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/include/uapi/linux/if_bridge.h 2014-12-09 20:25:21.656016605 -0800
+++ b/include/uapi/linux/if_bridge.h 2014-12-09 21:32:01.391034756 -0800
@@ -15,7 +15,9 @@
#include <linux/types.h>
#include <linux/if_ether.h>
-#include <linux/in6.h>
+#ifndef __KERNEL__
+#include <netinet/in.h>
+#endif
#define SYSFS_BRIDGE_ATTR "bridge"
#define SYSFS_BRIDGE_FDB "brforward"
^ permalink raw reply
* Re: [PATCH net-next] ipv6: fix sparse warning
From: Eric Dumazet @ 2014-12-10 5:40 UTC (permalink / raw)
To: Ying Xue; +Cc: davem, netdev
In-Reply-To: <1418182101-7992-1-git-send-email-ying.xue@windriver.com>
On Wed, 2014-12-10 at 11:28 +0800, Ying Xue wrote:
> This fixes the following sparse warning when using
>
> make C=1 CF=-D__CHECK_ENDIAN__ net/ipv6/addrconf.o
> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
> net/ipv6/addrconf.c:3495:9: error: incompatible types in comparison expression (different address spaces)
>
> To silence above spare complaint, an RCU annotation should be added
> to next pointer of hlist_node structure through hlist_next_rcu() macro
> when iterating over a hlist with hlist_for_each_entry_continue_rcu_bh().
>
> By the way, this commit also resolves the same error appearing in
> hlist_for_each_entry_continue_rcu().
This probably should be sent to lkml and CC Paul E. McKenney
^ permalink raw reply
* [PATCH v2] net: introduce helper macro for_each_cmsghdr
From: Gu Zheng @ 2014-12-10 5:36 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Joe Perches
Introduce helper macro for_each_cmsghdr as a wrapper of the enumerating
cmsghdr from msghdr, just cleanup.
Signed-off-by: Gu Zheng <guz.fnst@cn.fujitsu.com>
---
v2: use the lower-case macro name as Joe suggested.
---
.../networking/timestamping/timestamping.c | 4 +---
.../networking/timestamping/txtimestamp.c | 4 +---
crypto/af_alg.c | 2 +-
include/linux/socket.h | 4 ++++
net/core/scm.c | 3 +--
net/dccp/proto.c | 5 ++---
net/ipv4/ip_sockglue.c | 2 +-
net/ipv6/datagram.c | 2 +-
net/iucv/af_iucv.c | 4 +---
net/rds/send.c | 4 ++--
net/rxrpc/ar-output.c | 2 +-
net/sctp/socket.c | 3 +--
12 files changed, 17 insertions(+), 22 deletions(-)
diff --git a/Documentation/networking/timestamping/timestamping.c b/Documentation/networking/timestamping/timestamping.c
index 5cdfd74..635a43a 100644
--- a/Documentation/networking/timestamping/timestamping.c
+++ b/Documentation/networking/timestamping/timestamping.c
@@ -169,9 +169,7 @@ static void printpacket(struct msghdr *msg, int res,
res,
inet_ntoa(from_addr->sin_addr),
msg->msg_controllen);
- for (cmsg = CMSG_FIRSTHDR(msg);
- cmsg;
- cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
printf(" cmsg len %zu: ", cmsg->cmsg_len);
switch (cmsg->cmsg_level) {
case SOL_SOCKET:
diff --git a/Documentation/networking/timestamping/txtimestamp.c b/Documentation/networking/timestamping/txtimestamp.c
index b32fc2a..f4fd9a2 100644
--- a/Documentation/networking/timestamping/txtimestamp.c
+++ b/Documentation/networking/timestamping/txtimestamp.c
@@ -149,9 +149,7 @@ static void __recv_errmsg_cmsg(struct msghdr *msg, int payload_len)
struct scm_timestamping *tss = NULL;
struct cmsghdr *cm;
- for (cm = CMSG_FIRSTHDR(msg);
- cm && cm->cmsg_len;
- cm = CMSG_NXTHDR(msg, cm)) {
+ for_each_cmsghdr(cmsg, msg) {
if (cm->cmsg_level == SOL_SOCKET &&
cm->cmsg_type == SCM_TIMESTAMPING) {
tss = (void *) CMSG_DATA(cm);
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 6a3ad80..bc21f52 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -399,7 +399,7 @@ int af_alg_cmsg_send(struct msghdr *msg, struct af_alg_control *con)
{
struct cmsghdr *cmsg;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
if (cmsg->cmsg_level != SOL_ALG)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index bb9b836..0e71278 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -94,6 +94,10 @@ struct cmsghdr {
(cmsg)->cmsg_len <= (unsigned long) \
((mhdr)->msg_controllen - \
((char *)(cmsg) - (char *)(mhdr)->msg_control)))
+#define for_each_cmsghdr(cmsg, msg) \
+ for (cmsg = CMSG_FIRSTHDR(msg); \
+ cmsg; \
+ cmsg = CMSG_NXTHDR(msg, cmsg))
/*
* Get the next cmsg header
diff --git a/net/core/scm.c b/net/core/scm.c
index b442e7e..3b6899b 100644
--- a/net/core/scm.c
+++ b/net/core/scm.c
@@ -129,8 +129,7 @@ int __scm_send(struct socket *sock, struct msghdr *msg, struct scm_cookie *p)
struct cmsghdr *cmsg;
int err;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg))
- {
+ for_each_cmsghdr(cmsg, msg) {
err = -EINVAL;
/* Verify that cmsg_len is at least sizeof(struct cmsghdr) */
diff --git a/net/dccp/proto.c b/net/dccp/proto.c
index 5ab6627..e7413a9 100644
--- a/net/dccp/proto.c
+++ b/net/dccp/proto.c
@@ -703,7 +703,7 @@ EXPORT_SYMBOL_GPL(compat_dccp_getsockopt);
static int dccp_msghdr_parse(struct msghdr *msg, struct sk_buff *skb)
{
- struct cmsghdr *cmsg = CMSG_FIRSTHDR(msg);
+ struct cmsghdr *cmsg;
/*
* Assign an (opaque) qpolicy priority value to skb->priority.
@@ -717,8 +717,7 @@ static int dccp_msghdr_parse(struct msghdr *msg, struct sk_buff *skb)
*/
skb->priority = 0;
- for (; cmsg != NULL; cmsg = CMSG_NXTHDR(msg, cmsg)) {
-
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index 9daf217..839db9d 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -192,7 +192,7 @@ int ip_cmsg_send(struct net *net, struct msghdr *msg, struct ipcm_cookie *ipc,
int err, val;
struct cmsghdr *cmsg;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
#if IS_ENABLED(CONFIG_IPV6)
diff --git a/net/ipv6/datagram.c b/net/ipv6/datagram.c
index 2cdc383..7252965 100644
--- a/net/ipv6/datagram.c
+++ b/net/ipv6/datagram.c
@@ -640,7 +640,7 @@ int ip6_datagram_send_ctl(struct net *net, struct sock *sk,
int len;
int err = 0;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
int addr_type;
if (!CMSG_OK(msg, cmsg)) {
diff --git a/net/iucv/af_iucv.c b/net/iucv/af_iucv.c
index a089b6b..b69d87e 100644
--- a/net/iucv/af_iucv.c
+++ b/net/iucv/af_iucv.c
@@ -1070,9 +1070,7 @@ static int iucv_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
txmsg.class = 0;
/* iterate over control messages */
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg;
- cmsg = CMSG_NXTHDR(msg, cmsg)) {
-
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg)) {
err = -EINVAL;
goto out;
diff --git a/net/rds/send.c b/net/rds/send.c
index 0a64541..b23e7b8 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -826,7 +826,7 @@ static int rds_rm_size(struct msghdr *msg, int data_len)
int cmsg_groups = 0;
int retval;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
@@ -878,7 +878,7 @@ static int rds_cmsg_send(struct rds_sock *rs, struct rds_message *rm,
struct cmsghdr *cmsg;
int ret = 0;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
diff --git a/net/rxrpc/ar-output.c b/net/rxrpc/ar-output.c
index 0b4b9a7..83b4616 100644
--- a/net/rxrpc/ar-output.c
+++ b/net/rxrpc/ar-output.c
@@ -45,7 +45,7 @@ static int rxrpc_sendmsg_cmsg(struct rxrpc_sock *rx, struct msghdr *msg,
if (msg->msg_controllen == 0)
return -EINVAL;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg; cmsg = CMSG_NXTHDR(msg, cmsg)) {
+ for_each_cmsghdr(cmsg, msg) {
if (!CMSG_OK(msg, cmsg))
return -EINVAL;
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 634a2ab..a3802ed 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -6592,8 +6592,7 @@ static int sctp_msghdr_parse(const struct msghdr *msg, sctp_cmsgs_t *cmsgs)
struct cmsghdr *cmsg;
struct msghdr *my_msg = (struct msghdr *)msg;
- for (cmsg = CMSG_FIRSTHDR(msg); cmsg != NULL;
- cmsg = CMSG_NXTHDR(my_msg, cmsg)) {
+ for_each_cmsghdr(cmsg, my_msg) {
if (!CMSG_OK(my_msg, cmsg))
return -EINVAL;
--
1.7.7
^ permalink raw reply related
* Re: PATCH] Revert "bridge: include in6.h in if_bridge.h for struct in6_addr"
From: David Miller @ 2014-12-10 4:49 UTC (permalink / raw)
To: stephen; +Cc: gregory.0xf0, f.fainelli, xiyou.wangcong, netdev
In-Reply-To: <20141209203007.188651df@urahara>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Tue, 9 Dec 2014 20:30:07 -0800
> This reverts commit 66f1c44887ba4f47d617f8ae21cf8e04e1892bd7.
>
> iproute2 uses sanitized kernel headers, and this change broke the build.
> The problem is that the iproute2 ip/iplink_bridge_slave.c include if_bridge.h
> but this causes a redefintion error when Glibc <netlink/in.h> is included.
>
> Since iproute2 is arguably the most important user of network headers,
> the uapi header change should be reverted.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Stephen, please understand first the reason for this change.
GLIBC and the kernel fight over various definitions of core
networking types.
The only way to resolve this in the long term is this change
in question.
If you can make iproute2 work with both the new and the old
mechanims, please do so instead of reverting this important
change.
^ permalink raw reply
* Re: [PATCH iproute2] ss: Use nl_proto_a2n for filtering by netlink proto
From: Stephen Hemminger @ 2014-12-10 4:40 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417827139-10241-1-git-send-email-vadim4j@gmail.com>
On Sat, 6 Dec 2014 02:52:19 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Now it is posible to filter by existing Netlink protos:
>
> ss -A netlink src uevent
> ss -A netlink src nft
> ss -A netlink src genl
>
> Signed-off-by: Vadim Kochan <vadim4j@gmail.com>
Applied
^ permalink raw reply
* Re: [PATCH iproute2 0/2] lib names: Refactoring and cleanups
From: Stephen Hemminger @ 2014-12-10 4:38 UTC (permalink / raw)
To: Vadim Kochan; +Cc: netdev
In-Reply-To: <1417831512-19452-1-git-send-email-vadim4j@gmail.com>
On Sat, 6 Dec 2014 04:05:10 +0200
Vadim Kochan <vadim4j@gmail.com> wrote:
> Some cleanups and refactoring in lib/rt_names.c:
>
> #1 Replaced using of /etc/iproute2 path by CONFDIR define
> when initializing tables of group names.
>
> #2 Added helper to have one func for parsing id and names from
> db files.
>
> Vadim Kochan (2):
> lib names: Use CONFDIR for specify 'group' file path
> lib names: Add helper func for parse id and name from file
>
> lib/rt_names.c | 70 +++++++++++++++++++++++++++++++++-------------------------
> 1 file changed, 40 insertions(+), 30 deletions(-)
>
Both 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