* Greetings
From: Sung Lee @ 2013-10-20 11:47 UTC (permalink / raw)
DAH SING BANK LTD
DES VOEUX RD.BRANCH,CENTRAL HONG KONG,
HONG KONG.
Greetings,
I am Mr.Sung Lee, Auditing and Account Credit Officer, Dah Sing Bank Ltd,(Hong Kong). I ask for your partnership in re-profiling funds Transfer.
Further to this,details would be made known if interested but in summary the funds would be transferred from my bank and further to this other informations to facilitate the remittance of the funds will be revealed to you in due course. For your assistance, you shall receive 25% of the funds to be transferred .
I will appreciate if you can reply me.
I'm looking forward to it
Sung Lee
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
^ permalink raw reply
* Re: [PATCH iproute2] ss: make socket statistic parseable
From: Eric Dumazet @ 2013-10-20 13:44 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: netdev, shemminger, Eric Dumazet
In-Reply-To: <20131020132427.GA4514@virgo.local>
On Sun, 2013-10-20 at 15:24 +0200, Hagen Paul Pfeifer wrote:
> * Eric Dumazet | 2013-10-19 14:56:16 [-0700]:
>
> >Seems fine to me, maybe we want to support json for better parsing
> >capabilities ?
>
> Currently the parsing is straight forward with Python: split for
> whitespaces and subsequent split for colon to get a key/value list. Supporting
> an additional format may be overhead - not sure?! But yeah, JSON formated
> output is nice too. The current format has the advantage that it is human
> readable and "good" machine parseable. Except the first line:
>
Yes, I was only suggesting adding the -j flag, as done lately on other
iproute2 commands. Default would stay as is ;)
> tcp ESTAB 0 0 192.168.1.29:58951 208.68.163.218:xmpp-cli
>
> The line has a strict order, so it is not that hard to write a correct parser.
>
>
> Btw: for people not following google plus circus: I wrote an parser for ss(8)
> for plotting TCP stack variables:
>
> http://research.protocollabs.com/captcp/doc-socket-statistic-module.html
Yeah, I saw that on your Google+ page, very nice tool !
Thanks
^ permalink raw reply
* Re: [PATCH iproute2] ss: make socket statistic parseable
From: Hagen Paul Pfeifer @ 2013-10-20 13:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, shemminger, Eric Dumazet
In-Reply-To: <1382219776.3284.49.camel@edumazet-glaptop.roam.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 841 bytes --]
* Eric Dumazet | 2013-10-19 14:56:16 [-0700]:
>Seems fine to me, maybe we want to support json for better parsing
>capabilities ?
Currently the parsing is straight forward with Python: split for
whitespaces and subsequent split for colon to get a key/value list. Supporting
an additional format may be overhead - not sure?! But yeah, JSON formated
output is nice too. The current format has the advantage that it is human
readable and "good" machine parseable. Except the first line:
tcp ESTAB 0 0 192.168.1.29:58951 208.68.163.218:xmpp-cli
The line has a strict order, so it is not that hard to write a correct parser.
Btw: for people not following google plus circus: I wrote an parser for ss(8)
for plotting TCP stack variables:
http://research.protocollabs.com/captcp/doc-socket-statistic-module.html
Cheers, Hagen
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] sfc: Fix efx_rx_buf_offset() for recycled pages
From: Ben Hutchings @ 2013-10-20 12:52 UTC (permalink / raw)
To: David Miller; +Cc: stable, netdev
In-Reply-To: <1379607231.1514.13.camel@bwh-desktop.uk.level5networks.com>
[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]
On Thu, 2013-09-19 at 17:13 +0100, Ben Hutchings wrote:
> [Re-sending with cc to the current stable address. I still had the old
> address in contacts, though I've definitely sent to the current address
> previously...]
>
> This bug fix is only for stable branches older than 3.10. The bug was
> fixed upstream by commit 2768935a4660 ('sfc: reuse pages to avoid DMA
> mapping/unmapping costs'), but that change is totally unsuitable for
> stable.
>
> Commit b590ace09d51 ('sfc: Fix efx_rx_buf_offset() in the presence of
> swiotlb') added an explicit page_offset member to struct
> efx_rx_buffer, which must be set consistently with the u.page and
> dma_addr fields. However, it failed to add the necessary assignment
> in efx_resurrect_rx_buffer(). It also did not correct the calculation
> of efx_rx_buffer::dma_addr in efx_resurrect_rx_buffer(), which assumes
> that DMA-mapping a page will result in a page-aligned DMA address
> (exactly what swiotlb violates).
>
> Add the assignment of efx_rx_buffer::page_offset and change the
> calculation of dma_addr to make use of it.
>
> I'm attaching the patches for 3.0.y, 3.2.y and 3.4.y (the last of which
> should also be applicable to the later unofficial stable branches).
Queued up for 3.2.
Ben.
--
Ben Hutchings
Tomorrow will be cancelled due to lack of interest.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH net-next] bonding: move bond-specific init after enslave happens
From: Veaceslav Falico @ 2013-10-20 12:47 UTC (permalink / raw)
To: netdev; +Cc: jiri, Veaceslav Falico, Jay Vosburgh, Andy Gospodarek
As Jiri noted, currently we first do all bonding-specific initialization
(specifically - bond_select_active_slave(bond)) before we actually attach
the slave (so that it becomes visible through bond_for_each_slave() and
friends). This might result in bond_select_active_slave() not seeing the
first/new slave and, thus, not actually selecting an active slave.
Fix this by moving all the bond-related init part after we've actually
completely initialized and linked (via bond_master_upper_dev_link()) the
new slave.
After this we have all the initialization of the new slave *before*
linking, and all the stuff that needs to be done on bonding *after* it. It
has also a bonus effect - we can remove the locking on the new slave init
completely, and only use it for bond_select_active_slave().
Reported-by: Jiri Pirko <jiri@resnulli.us>
CC: Jay Vosburgh <fubar@us.ibm.com>
CC: Andy Gospodarek <andy@greyhouse.net>
Signed-off-by: Veaceslav Falico <vfalico@redhat.com>
---
drivers/net/bonding/bond_main.c | 29 ++++++++++-------------------
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index d90734f..047c0fb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -1471,22 +1471,14 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
goto err_close;
}
- write_lock_bh(&bond->lock);
-
prev_slave = bond_last_slave(bond);
bond_attach_slave(bond, new_slave);
new_slave->delay = 0;
new_slave->link_failure_count = 0;
- write_unlock_bh(&bond->lock);
-
- bond_compute_features(bond);
-
bond_update_speed_duplex(new_slave);
- read_lock(&bond->lock);
-
new_slave->last_arp_rx = jiffies -
(msecs_to_jiffies(bond->params.arp_interval) + 1);
for (i = 0; i < BOND_MAX_ARP_TARGETS; i++)
@@ -1547,12 +1539,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
}
}
- write_lock_bh(&bond->curr_slave_lock);
-
switch (bond->params.mode) {
case BOND_MODE_ACTIVEBACKUP:
bond_set_slave_inactive_flags(new_slave);
- bond_select_active_slave(bond);
break;
case BOND_MODE_8023AD:
/* in 802.3ad mode, the internal mechanism
@@ -1578,7 +1567,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
case BOND_MODE_ALB:
bond_set_active_slave(new_slave);
bond_set_slave_inactive_flags(new_slave);
- bond_select_active_slave(bond);
break;
default:
pr_debug("This slave is always active in trunk mode\n");
@@ -1596,10 +1584,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
break;
} /* switch(bond_mode) */
- write_unlock_bh(&bond->curr_slave_lock);
-
- bond_set_carrier(bond);
-
#ifdef CONFIG_NET_POLL_CONTROLLER
slave_dev->npinfo = bond->dev->npinfo;
if (slave_dev->npinfo) {
@@ -1614,8 +1598,6 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
}
#endif
- read_unlock(&bond->lock);
-
res = netdev_rx_handler_register(slave_dev, bond_handle_frame,
new_slave);
if (res) {
@@ -1629,6 +1611,16 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
goto err_unregister;
}
+ bond_compute_features(bond);
+ bond_set_carrier(bond);
+
+ if (USES_PRIMARY(bond->params.mode)) {
+ read_lock(&bond->lock);
+ write_lock_bh(&bond->curr_slave_lock);
+ bond_select_active_slave(bond);
+ write_unlock_bh(&bond->curr_slave_lock);
+ read_unlock(&bond->lock);
+ }
pr_info("%s: enslaving %s as a%s interface with a%s link.\n",
bond_dev->name, slave_dev->name,
@@ -1686,7 +1678,6 @@ err_free:
kfree(new_slave);
err_undo_flags:
- bond_compute_features(bond);
/* Enslave of first slave has failed and we need to fix master's mac */
if (!bond_has_slaves(bond) &&
ether_addr_equal(bond_dev->dev_addr, slave_dev->dev_addr))
--
1.8.1.4
^ permalink raw reply related
* [PATCH net 3/3] netfilter: nf_conntrack: fix rt6i_gateway checks for H.323 helper
From: Julian Anastasov @ 2013-10-20 12:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netfilter-devel, lvs-devel, Hideaki YOSHIFUJI
In-Reply-To: <1382272985-1528-1-git-send-email-ja@ssi.bg>
Now when rt6_nexthop() can return nexthop address we can use it
for proper nexthop comparison of directly connected destinations.
For more information refer to commit bbb5823cf742a7
("netfilter: nf_conntrack: fix rt_gateway checks for H.323 helper").
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
net/netfilter/nf_conntrack_h323_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nf_conntrack_h323_main.c b/net/netfilter/nf_conntrack_h323_main.c
index bdebd03..70866d1 100644
--- a/net/netfilter/nf_conntrack_h323_main.c
+++ b/net/netfilter/nf_conntrack_h323_main.c
@@ -778,8 +778,8 @@ static int callforward_do_filter(const union nf_inet_addr *src,
flowi6_to_flowi(&fl1), false)) {
if (!afinfo->route(&init_net, (struct dst_entry **)&rt2,
flowi6_to_flowi(&fl2), false)) {
- if (!memcmp(&rt1->rt6i_gateway, &rt2->rt6i_gateway,
- sizeof(rt1->rt6i_gateway)) &&
+ if (ipv6_addr_equal(rt6_nexthop(rt1),
+ rt6_nexthop(rt2)) &&
rt1->dst.dev == rt2->dst.dev)
ret = 1;
dst_release(&rt2->dst);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/3] ipv6: fill rt6i_gateway with nexthop address
From: Julian Anastasov @ 2013-10-20 12:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netfilter-devel, lvs-devel, Hideaki YOSHIFUJI
In-Reply-To: <1382272985-1528-1-git-send-email-ja@ssi.bg>
Make sure rt6i_gateway contains nexthop information in
all routes returned from lookup or when routes are directly
attached to skb for generated ICMP packets.
The effect of this patch should be a faster version of
rt6_nexthop() and the consideration of local addresses as
nexthop.
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/net/ip6_route.h | 6 ++----
net/ipv6/ip6_output.c | 4 ++--
net/ipv6/route.c | 8 ++++++--
3 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index 481404a..2b786b7 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -194,11 +194,9 @@ static inline int ip6_skb_dst_mtu(struct sk_buff *skb)
skb_dst(skb)->dev->mtu : dst_mtu(skb_dst(skb));
}
-static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt, struct in6_addr *dest)
+static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt)
{
- if (rt->rt6i_flags & RTF_GATEWAY || !ipv6_addr_any(&rt->rt6i_gateway))
- return &rt->rt6i_gateway;
- return dest;
+ return &rt->rt6i_gateway;
}
#endif
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index a54c45c..2b404df 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -105,7 +105,7 @@ static int ip6_finish_output2(struct sk_buff *skb)
}
rcu_read_lock_bh();
- nexthop = rt6_nexthop((struct rt6_info *)dst, &ipv6_hdr(skb)->daddr);
+ nexthop = rt6_nexthop((struct rt6_info *)dst);
neigh = __ipv6_neigh_lookup_noref(dst->dev, nexthop);
if (unlikely(!neigh))
neigh = __neigh_create(&nd_tbl, nexthop, dst->dev, false);
@@ -874,7 +874,7 @@ static int ip6_dst_lookup_tail(struct sock *sk,
*/
rt = (struct rt6_info *) *dst;
rcu_read_lock_bh();
- n = __ipv6_neigh_lookup_noref(rt->dst.dev, rt6_nexthop(rt, &fl6->daddr));
+ n = __ipv6_neigh_lookup_noref(rt->dst.dev, rt6_nexthop(rt));
err = n && !(n->nud_state & NUD_VALID) ? -EINVAL : 0;
rcu_read_unlock_bh();
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c979dd9..c1ee381 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -851,7 +851,6 @@ static struct rt6_info *rt6_alloc_cow(struct rt6_info *ort,
if (ort->rt6i_dst.plen != 128 &&
ipv6_addr_equal(&ort->rt6i_dst.addr, daddr))
rt->rt6i_flags |= RTF_ANYCAST;
- rt->rt6i_gateway = *daddr;
}
rt->rt6i_flags |= RTF_CACHE;
@@ -1338,6 +1337,7 @@ struct dst_entry *icmp6_dst_alloc(struct net_device *dev,
rt->dst.flags |= DST_HOST;
rt->dst.output = ip6_output;
atomic_set(&rt->dst.__refcnt, 1);
+ rt->rt6i_gateway = fl6->daddr;
rt->rt6i_dst.addr = fl6->daddr;
rt->rt6i_dst.plen = 128;
rt->rt6i_idev = idev;
@@ -1873,7 +1873,10 @@ static struct rt6_info *ip6_rt_copy(struct rt6_info *ort,
in6_dev_hold(rt->rt6i_idev);
rt->dst.lastuse = jiffies;
- rt->rt6i_gateway = ort->rt6i_gateway;
+ if (ort->rt6i_flags & RTF_GATEWAY)
+ rt->rt6i_gateway = ort->rt6i_gateway;
+ else
+ rt->rt6i_gateway = *dest;
rt->rt6i_flags = ort->rt6i_flags;
if ((ort->rt6i_flags & (RTF_DEFAULT | RTF_ADDRCONF)) ==
(RTF_DEFAULT | RTF_ADDRCONF))
@@ -2160,6 +2163,7 @@ struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
else
rt->rt6i_flags |= RTF_LOCAL;
+ rt->rt6i_gateway = *addr;
rt->rt6i_dst.addr = *addr;
rt->rt6i_dst.plen = 128;
rt->rt6i_table = fib6_get_table(net, RT6_TABLE_LOCAL);
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 0/3] ipv6: use rt6i_gateway as nexthop
From: Julian Anastasov @ 2013-10-20 12:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netfilter-devel, lvs-devel, Hideaki YOSHIFUJI
The following patchset makes sure that rt6i_gateway
contains valid nexthop information in all cases, so that
we can use different nexthop for sending.
The first patch is a simple fix that makes IPVS, TEE,
RAW(hdrincl) and RTF_DYNAMIC(without RTF_GATEWAY) work as
before 3.9. There is a single corner case not solved by
this patch: RAW(hdrincl) or TEE using local address for
nexthop, a silly feature, I guess. In this case we
see zeroes in rt6i_gateway because we get route that is not
cloned. This is solved only with patch 2.
The second patch is an optimization that makes sure
all resulting routes have rt6i_gateway filled, so that we
can avoid the complex ipv6_addr_any() call added to rt6_nexthop()
by patch 1. And it sets rt6i_gateway for local routes, a case
not handled by patch 1.
The third patch uses the new rt6_nexthop() function to fix
the matching of gateways in the same way as commit bbb5823cf742a7
("netfilter: nf_conntrack: fix rt_gateway checks for H.323 helper")
fixes nf_conntrack_h323_main.c for IPv4. Currently, it depends on
the new definition of rt6_nexthop() in patch 2. Actually, if
patch 2 is applied, patch 3 becomes a cosmetic change.
I see the following two alternatives for applying these
patches:
1. Linger patch 2 in net-next to avoid surprises in the upcoming
release. In this case patch 3 can be reworked not to depend on
the new rt6_nexthop() definition in patch 2. I guess this is a
better option, so that patch 2 can be reviewed and tested for
longer time.
2. Include all 3 patches in net tree - more risky because this
is my first attempt to change IPv6.
Here is the situation as handled by patch 2:
In IPv6 the resolved routes are always host routes (/128
with DST_HOST), mostly cloned ones. We allow routes in FIB
to contain rt6i_gateway with zeroes (eg. for local subnets) but
on cloning we can fill the rt6i_gateway field in result.
This works even without this patchset.
There is a single special case where dst is provided as
skb_dst directly without a routing call: icmp6_dst_alloc(). It is a
private dst allocated just for the particular ICMP packet. Patch 2
fills rt6i_gateway in this case, needed for the new rt6_nexthop()
simplification.
The last case is addrconf_dst_alloc(), it can put in
FIB local/anycast routes when addresses are added. Patch 2
needs to fill rt6i_gateway in this case because such routes
are returned without cloning.
Julian Anastasov (3):
ipv6: always prefer rt6i_gateway if present
ipv6: fill rt6i_gateway with nexthop address
netfilter: nf_conntrack: fix rt6i_gateway checks for H.323 helper
include/net/ip6_route.h | 6 ++----
net/ipv6/ip6_output.c | 4 ++--
net/ipv6/route.c | 8 ++++++--
net/netfilter/nf_conntrack_h323_main.c | 4 ++--
4 files changed, 12 insertions(+), 10 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH net 1/3] ipv6: always prefer rt6i_gateway if present
From: Julian Anastasov @ 2013-10-20 12:43 UTC (permalink / raw)
To: David Miller; +Cc: netdev, netfilter-devel, lvs-devel, Hideaki YOSHIFUJI
In-Reply-To: <1382272985-1528-1-git-send-email-ja@ssi.bg>
In v3.9 6fd6ce2056de2709 ("ipv6: Do not depend on rt->n in
ip6_finish_output2()." changed the behaviour of ip6_finish_output2()
such that the recently introduced rt6_nexthop() is used
instead of an assigned neighbor.
As rt6_nexthop() prefers rt6i_gateway only for gatewayed
routes this causes a problem for users like IPVS, xt_TEE and
RAW(hdrincl) if they want to use different address for routing
compared to the destination address.
Another case is when redirect can create RTF_DYNAMIC
route without RTF_GATEWAY flag, we ignore the rt6i_gateway
in rt6_nexthop().
Fix the above problems by considering the rt6i_gateway if
present, so that traffic routed to address on local subnet is
not wrongly diverted to the destination address.
Thanks to Simon Horman and Phil Oester for spotting the
problematic commit.
Thanks to Hannes Frederic Sowa for his review and help in testing.
Reported-by: Phil Oester <kernel@linuxace.com>
Reported-by: Mark Brooks <mark@loadbalancer.org>
Signed-off-by: Julian Anastasov <ja@ssi.bg>
---
include/net/ip6_route.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h
index f525e70..481404a 100644
--- a/include/net/ip6_route.h
+++ b/include/net/ip6_route.h
@@ -196,7 +196,7 @@ static inline int ip6_skb_dst_mtu(struct sk_buff *skb)
static inline struct in6_addr *rt6_nexthop(struct rt6_info *rt, struct in6_addr *dest)
{
- if (rt->rt6i_flags & RTF_GATEWAY)
+ if (rt->rt6i_flags & RTF_GATEWAY || !ipv6_addr_any(&rt->rt6i_gateway))
return &rt->rt6i_gateway;
return dest;
}
--
1.8.3.1
^ permalink raw reply related
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-20 12:27 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks, Phil Oester
In-Reply-To: <20131020073308.GE27787@order.stressinduktion.org>
Hello,
On Sun, 20 Oct 2013, Hannes Frederic Sowa wrote:
> Is your kernel compiled with CONFIG_IPV6_ROUTER_PREF?
I tested with this flag, even with your patch,
added printk in rt6_probe_deferred() to be sure. But
in my setup without router I can not test it fully.
I'm on 32-bit platform, so may be the shorter structs
fit in stack and I don't see oops.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* E-mail Has Won 1.5M
From: China, Shenhua @ 2013-10-20 12:02 UTC (permalink / raw)
To: Recipients
Your E-mail Has Won 1.5M USD and A Brand New Gallery 2013 BMW X6 in the
China Coal Energy Company Grant 2013.To Receive Award send your
Name,Add,and Number on Email:companylimited_c1@yahoo.com.hk
^ permalink raw reply
* Re: [PATCH 03/17] netfilter: add nftables
From: Jan Engelhardt @ 2013-10-20 11:46 UTC (permalink / raw)
To: Pablo Neira Ayuso; +Cc: netfilter-devel, davem, kaber, netdev
In-Reply-To: <1381768738-17739-4-git-send-email-pablo@netfilter.org>
On Monday 2013-10-14 18:38, Pablo Neira Ayuso wrote:
>
>+static int __init nf_table_nat_init(void)
>+{
>+ int err;
>+
>+ list_add_tail(&nf_chain_nat_prerouting.chain.list,
>+ &nf_table_nat_ipv4.chains);
>+ list_add_tail(&nf_chain_nat_postrouting.chain.list,
>+ &nf_table_nat_ipv4.chains);
>+ list_add_tail(&nf_chain_nat_output.chain.list,
>+ &nf_table_nat_ipv4.chains);
>+ list_add_tail(&nf_chain_nat_input.chain.list,
>+ &nf_table_nat_ipv4.chains);
>+
>+ err = nft_register_table(&nf_table_nat_ipv4, NFPROTO_IPV4);
>+ if (err < 0)
>+ goto err1;
Why do we still have this redundant table separation?
This ugly 90s era relict was a result of the module split,
but given that arbitrary base chain creation is now exposed,
it is no longer necessary. (It was not really necessary
before either, but that is how things grew in the past.)
Don't carry over 90s mistakes.
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-20 8:33 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks, Phil Oester
In-Reply-To: <20131020073308.GE27787@order.stressinduktion.org>
Hello,
On Sun, 20 Oct 2013, Hannes Frederic Sowa wrote:
> The caller I found was ip6t_do_table which does deactivate bottom halves.
> Maybe there are others I did not see, so double checking is better.
Aha, I see.
> > In my test I used link route to local subnet, --gateway to IP
> > that is not present. I'll try other variants.
>
> Is your kernel compiled with CONFIG_IPV6_ROUTER_PREF?
Hm, no. I'll enable it. But it works for
RTF_GATEWAY, something I didn't tested before now.
> I cannot test my patch today any more, so I just leave it here. It is only
> compile tested. Maybe you can make use of it:
I'll try it. But note that my test setup has
no any routers around.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [PATCH net-next] e1000: fix wrong queue idx calculation
From: Hong Zhiguo @ 2013-10-20 8:15 UTC (permalink / raw)
To: davem; +Cc: e1000-devel, netdev, Hong Zhiguo
From: Hong Zhiguo <zhiguohong@tencent.com>
tx_ring and adapter->tx_ring are already of type "struct
e1000_tx_ring *"
Signed-off-by: Hong Zhiguo <zhiguohong@tencent.com>
---
drivers/net/ethernet/intel/e1000/e1000_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 59ad007..ad6800a 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -3917,8 +3917,7 @@ static bool e1000_clean_tx_irq(struct e1000_adapter *adapter,
" next_to_watch <%x>\n"
" jiffies <%lx>\n"
" next_to_watch.status <%x>\n",
- (unsigned long)((tx_ring - adapter->tx_ring) /
- sizeof(struct e1000_tx_ring)),
+ (unsigned long)(tx_ring - adapter->tx_ring),
readl(hw->hw_addr + tx_ring->tdh),
readl(hw->hw_addr + tx_ring->tdt),
tx_ring->next_to_use,
--
1.8.1.2
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply related
* Re: your mail
From: Antonio Quartulli @ 2013-10-20 7:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20131019.201511.2049734211571225673.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 539 bytes --]
On Sat, Oct 19, 2013 at 08:15:11PM -0400, David Miller wrote:
> From: Antonio Quartulli <antonio@meshcoding.com>
> Date: Sun, 20 Oct 2013 00:21:52 +0200
>
> > this is another batch intended for net-next/linux-3.13.
>
> Looks good, pulled, thanks a lot Antonio.
>
> Please don't use empty subject lines in the future, lots of
> sites block such emails and I see all of those bounces as
> vger postmaster :-/
>
Ops, my bad. I won't do it again in the future!
Thanks a lot David.
Regards,
--
Antonio Quartulli
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Hannes Frederic Sowa @ 2013-10-20 7:33 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks, Phil Oester
In-Reply-To: <alpine.LFD.2.03.1310200939330.1538@ssi.bg>
On Sun, Oct 20, 2013 at 10:11:16AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Sun, 20 Oct 2013, Hannes Frederic Sowa wrote:
>
> > > Hm, maybe. I don't have too much insight into netfilter stack and
> > > what are the differences between OUTPUT and FORWARD path but plan to
> > > investigate. ;)
> >
> > It seems tables are processed with bh disabled, so no preemption while
> > recursing. So I guess the use of tee_active is safe for breaking the
> > tie here.
>
> May be, I'll check it again, for now I see only
> rcu_read_lock() in nf_hook_slow() which is preemptable.
> Looking at rcu_preempt_note_context_switch, many levels of
> RCU locks are preemptable too.
The caller I found was ip6t_do_table which does deactivate bottom halves.
Maybe there are others I did not see, so double checking is better.
> In my test I used link route to local subnet, --gateway to IP
> that is not present. I'll try other variants.
Is your kernel compiled with CONFIG_IPV6_ROUTER_PREF?
> > The more I review the patch the more I think it is ok. But we could actually
> > try to just always return rt6i_gateway, as we should always be handed a cloned
> > rt6_info where the gateway is already filled in, no?
>
> Yes, this patch is ok and after spending the whole
> saturday I'm preparing a new patch that will convert
> rt6_nexthop() to return just rt6i_gateway, without daddr.
> This can happen after filling rt6i_gateway in all places.
>
> For your concern for loopback, I don't see problem,
> local/anycast route will have rt6i_gateway=IP, they are
> simple DST_HOST routes. I'm preparing now the patches and
> will post them in following hours.
Ok, that's a nice simplification. I'll have a look tomorrow.
I cannot test my patch today any more, so I just leave it here. It is only
compile tested. Maybe you can make use of it:
Btw: I cannot put a reference to the rt6_info into __rt6_probe_work because we
are not supposed to use rt6_info reference counters outside of ip6_fib
because the deletion from the fib will break otherwise.
Maybe we should also create a seperate ipv6 workqueue. Will check later.
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index c3130ff..6c539bc 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -476,6 +476,40 @@ out:
}
#ifdef CONFIG_IPV6_ROUTER_PREF
+struct __rt6_probe_work {
+ struct work_struct work;
+ struct in6_addr target;
+ struct net_device *dev;
+};
+
+static void rt6_probe_deferred(struct work_struct *w)
+{
+ struct in6_addr mcaddr;
+ struct __rt6_probe_work *work =
+ container_of(w, struct __rt6_probe_work, work);
+
+ addrconf_addr_solict_mult(&work->target, &mcaddr);
+ ndisc_send_ns(work->dev, NULL, &work->target, &mcaddr, NULL);
+ dev_put(work->dev);
+ kfree(w);
+}
+
+static bool rt6_probe_later(struct rt6_info *rt)
+{
+ struct __rt6_probe_work *work;
+
+ work = kmalloc(sizeof(*work), GFP_ATOMIC);
+ if (!work)
+ return false;
+
+ INIT_WORK(&work->work, rt6_probe_deferred);
+ work->target = rt->rt6i_gateway;
+ dev_hold(rt->dst.dev);
+ work->dev = rt->dst.dev;
+ schedule_work(&work->work);
+ return true;
+}
+
static void rt6_probe(struct rt6_info *rt)
{
struct neighbour *neigh;
@@ -499,17 +533,10 @@ static void rt6_probe(struct rt6_info *rt)
if (!neigh ||
time_after(jiffies, neigh->updated + rt->rt6i_idev->cnf.rtr_probe_interval)) {
- struct in6_addr mcaddr;
- struct in6_addr *target;
-
- if (neigh) {
- neigh->updated = jiffies;
+ if (neigh)
write_unlock(&neigh->lock);
- }
^ permalink raw reply related
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-20 7:11 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks, Phil Oester
In-Reply-To: <20131019223657.GH31333@order.stressinduktion.org>
Hello,
On Sun, 20 Oct 2013, Hannes Frederic Sowa wrote:
> > Hm, maybe. I don't have too much insight into netfilter stack and
> > what are the differences between OUTPUT and FORWARD path but plan to
> > investigate. ;)
>
> It seems tables are processed with bh disabled, so no preemption while
> recursing. So I guess the use of tee_active is safe for breaking the
> tie here.
May be, I'll check it again, for now I see only
rcu_read_lock() in nf_hook_slow() which is preemptable.
Looking at rcu_preempt_note_context_switch, many levels of
RCU locks are preemptable too.
> The reason I exhaust stack space is that we can actually send out packets
> while looking up routes (rt6_probe). The nonreachability of the default
> gateway and the to-teed-to box does the rest.
In my test I used link route to local subnet,
--gateway to IP that is not present. I'll try other
variants.
> We need to change the route lookup of the duplicated packet in xt_tee to not
> cause ndisc probes to be generated.
>
> The more I review the patch the more I think it is ok. But we could actually
> try to just always return rt6i_gateway, as we should always be handed a cloned
> rt6_info where the gateway is already filled in, no?
Yes, this patch is ok and after spending the whole
saturday I'm preparing a new patch that will convert
rt6_nexthop() to return just rt6i_gateway, without daddr.
This can happen after filling rt6i_gateway in all places.
For your concern for loopback, I don't see problem,
local/anycast route will have rt6i_gateway=IP, they are
simple DST_HOST routes. I'm preparing now the patches and
will post them in following hours.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* [net PATCH 1/1] drivers: net: cpsw: fix kernel warn during iperf test with interrupt pacing
From: Mugunthan V N @ 2013-10-20 7:02 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-omap, Mugunthan V N, Sebastian Siewior
When interrupt pacing is enabled, receive/transmit statistics are not
updated properly by hardware which leads to ISR return with IRQ_NONE
and inturn kernel disables the interrupt. This patch removed the checking
of receive/transmit statistics from ISR.
This patch is verified with AM335x Beagle Bone Black and below is the
kernel warn when interrupt pacing is enabled.
[ 104.298254] irq 58: nobody cared (try booting with the "irqpoll" option)
[ 104.305356] CPU: 0 PID: 1073 Comm: iperf Not tainted 3.12.0-rc3-00342-g77d4015 #3
[ 104.313284] [<c001bb84>] (unwind_backtrace+0x0/0xf0) from [<c0017db0>] (show_stack+0x10/0x14)
[ 104.322282] [<c0017db0>] (show_stack+0x10/0x14) from [<c0507920>] (dump_stack+0x78/0x94)
[ 104.330816] [<c0507920>] (dump_stack+0x78/0x94) from [<c0088c1c>] (__report_bad_irq+0x20/0xc0)
[ 104.339889] [<c0088c1c>] (__report_bad_irq+0x20/0xc0) from [<c008912c>] (note_interrupt+0x1dc/0x23c)
[ 104.349505] [<c008912c>] (note_interrupt+0x1dc/0x23c) from [<c0086d74>] (handle_irq_event_percpu+0xc4/0x238)
[ 104.359851] [<c0086d74>] (handle_irq_event_percpu+0xc4/0x238) from [<c0086f24>] (handle_irq_event+0x3c/0x5c)
[ 104.370198] [<c0086f24>] (handle_irq_event+0x3c/0x5c) from [<c008991c>] (handle_level_irq+0xac/0x10c)
[ 104.379907] [<c008991c>] (handle_level_irq+0xac/0x10c) from [<c00866d8>] (generic_handle_irq+0x20/0x30)
[ 104.389812] [<c00866d8>] (generic_handle_irq+0x20/0x30) from [<c0014ce8>] (handle_IRQ+0x4c/0xb0)
[ 104.399066] [<c0014ce8>] (handle_IRQ+0x4c/0xb0) from [<c000856c>] (omap3_intc_handle_irq+0x60/0x74)
[ 104.408598] [<c000856c>] (omap3_intc_handle_irq+0x60/0x74) from [<c050d8e4>] (__irq_svc+0x44/0x5c)
[ 104.418021] Exception stack(0xde4f7c00 to 0xde4f7c48)
[ 104.423345] 7c00: 00000001 00000000 00000000 dd002140 60000013 de006e54 00000002 00000000
[ 104.431952] 7c20: de345748 00000040 c11c8588 00018ee0 00000000 de4f7c48 c009dfc8 c050d300
[ 104.440553] 7c40: 60000013 ffffffff
[ 104.444237] [<c050d8e4>] (__irq_svc+0x44/0x5c) from [<c050d300>] (_raw_spin_unlock_irqrestore+0x34/0x44)
[ 104.454220] [<c050d300>] (_raw_spin_unlock_irqrestore+0x34/0x44) from [<c00868c0>] (__irq_put_desc_unlock+0x14/0x38)
[ 104.465295] [<c00868c0>] (__irq_put_desc_unlock+0x14/0x38) from [<c0088068>] (enable_irq+0x4c/0x74)
[ 104.474829] [<c0088068>] (enable_irq+0x4c/0x74) from [<c03abd24>] (cpsw_poll+0xb8/0xdc)
[ 104.483276] [<c03abd24>] (cpsw_poll+0xb8/0xdc) from [<c044ef68>] (net_rx_action+0xc0/0x1e8)
[ 104.492085] [<c044ef68>] (net_rx_action+0xc0/0x1e8) from [<c0048a90>] (__do_softirq+0x100/0x27c)
[ 104.501338] [<c0048a90>] (__do_softirq+0x100/0x27c) from [<c0048cd0>] (do_softirq+0x68/0x70)
[ 104.510224] [<c0048cd0>] (do_softirq+0x68/0x70) from [<c0048e8c>] (local_bh_enable+0xd0/0xe4)
[ 104.519211] [<c0048e8c>] (local_bh_enable+0xd0/0xe4) from [<c048c774>] (tcp_rcv_established+0x450/0x648)
[ 104.529201] [<c048c774>] (tcp_rcv_established+0x450/0x648) from [<c0494904>] (tcp_v4_do_rcv+0x154/0x474)
[ 104.539195] [<c0494904>] (tcp_v4_do_rcv+0x154/0x474) from [<c043d750>] (release_sock+0xac/0x1ac)
[ 104.548448] [<c043d750>] (release_sock+0xac/0x1ac) from [<c04844e8>] (tcp_recvmsg+0x4d0/0xa8c)
[ 104.557528] [<c04844e8>] (tcp_recvmsg+0x4d0/0xa8c) from [<c04a8720>] (inet_recvmsg+0xcc/0xf0)
[ 104.566507] [<c04a8720>] (inet_recvmsg+0xcc/0xf0) from [<c0439744>] (sock_recvmsg+0x90/0xb0)
[ 104.575394] [<c0439744>] (sock_recvmsg+0x90/0xb0) from [<c043b778>] (SyS_recvfrom+0x88/0xd8)
[ 104.584280] [<c043b778>] (SyS_recvfrom+0x88/0xd8) from [<c043b7e0>] (sys_recv+0x18/0x20)
[ 104.592805] [<c043b7e0>] (sys_recv+0x18/0x20) from [<c0013da0>] (ret_fast_syscall+0x0/0x48)
[ 104.601587] handlers:
[ 104.603992] [<c03acd94>] cpsw_interrupt
[ 104.608040] Disabling IRQ #58
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
drivers/net/ethernet/ti/cpsw.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index fccd9d4..cc3ce55 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -639,13 +639,6 @@ void cpsw_rx_handler(void *token, int len, int status)
static irqreturn_t cpsw_interrupt(int irq, void *dev_id)
{
struct cpsw_priv *priv = dev_id;
- u32 rx, tx, rx_thresh;
-
- rx_thresh = __raw_readl(&priv->wr_regs->rx_thresh_stat);
- rx = __raw_readl(&priv->wr_regs->rx_stat);
- tx = __raw_readl(&priv->wr_regs->tx_stat);
- if (!rx_thresh && !rx && !tx)
- return IRQ_NONE;
cpsw_intr_disable(priv);
if (priv->irq_enabled == true) {
--
1.8.4.1.516.g1d25dd4
^ permalink raw reply related
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Hannes Frederic Sowa @ 2013-10-20 6:47 UTC (permalink / raw)
To: Julian Anastasov
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks, Phil Oester
In-Reply-To: <alpine.LFD.2.03.1310200936590.1538@ssi.bg>
On Sun, Oct 20, 2013 at 09:39:26AM +0300, Julian Anastasov wrote:
>
> Hello,
>
> On Sat, 19 Oct 2013, Hannes Frederic Sowa wrote:
>
> > On Sat, Oct 19, 2013 at 07:37:10PM +0300, Julian Anastasov wrote:
> > >
> > > Problem with process stack? May be some packet loop
> > > happens? Because I can not reproduce such problem in my
> > > virtual setup, I tested TEE too, with careful packet
> > > matching and 1 CPU. Should I assume that you don't have such
> > > oops when the patch is not applied, with the same TEE rule?
> >
> > Oh, sorry, you are right. It happens with an unpatched net-next kernel, too.
> >
> > I inserted the TEE rule in mangel/OUTGOING and had only one route, ip -6 r a
> > default via fe80::1 dev eth0 which at the time of the panic was actually not
> > reachable.
>
> Thanks for the confirmation! I'll try later
> to reproduce such problem with TEE, it is interesting
> to know the real reason for this loop.
Yup, I have a patch in works wich defers the ndisc_send_ns call in
rt6_probe into a workqueue out of the call stack. This should solve
the problem.
Still wonder if there is a nicer api as to create a new structure and pass the
arguments via container_of dereferencing to the deferred function (and I
don't think async calls are useable there).
Greetings,
Hannes
^ permalink raw reply
* [PATCH] mac80211: document IEEE80211_HW_SUPPORTS_HT_CCK_RATES
From: Michael Opdenacker @ 2013-10-20 6:45 UTC (permalink / raw)
To: johannes, davem; +Cc: linux-wireless, netdev, linux-kernel, Michael Opdenacker
This patch documents the IEEE80211_HW_SUPPORTS_HT_CCK_RATES flag
in ieee80211_hw_flags.
Without this, you get countless warnings in "make htmldocs".
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
include/net/mac80211.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index cc6035f..0a26a6e 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1492,6 +1492,9 @@ struct ieee80211_tx_control {
*
* @IEEE80211_HW_TIMING_BEACON_ONLY: Use sync timing from beacon frames
* only, to allow getting TBTT of a DTIM beacon.
+ *
+ * @IEEE80211_HW_SUPPORTS_HT_CCK_RATES:
+ * Hardware has CCK support for HT clients.
*/
enum ieee80211_hw_flags {
IEEE80211_HW_HAS_RATE_CONTROL = 1<<0,
--
1.8.1.2
^ permalink raw reply related
* Re: [RFC net-next] ipv6: Use destination address determined by IPVS
From: Julian Anastasov @ 2013-10-20 6:39 UTC (permalink / raw)
To: Hannes Frederic Sowa
Cc: Simon Horman,
YOSHIFUJI Hideaki / 吉藤英明, lvs-devel,
netdev, Mark Brooks, Phil Oester
In-Reply-To: <20131019183433.GC31333@order.stressinduktion.org>
Hello,
On Sat, 19 Oct 2013, Hannes Frederic Sowa wrote:
> On Sat, Oct 19, 2013 at 07:37:10PM +0300, Julian Anastasov wrote:
> >
> > Problem with process stack? May be some packet loop
> > happens? Because I can not reproduce such problem in my
> > virtual setup, I tested TEE too, with careful packet
> > matching and 1 CPU. Should I assume that you don't have such
> > oops when the patch is not applied, with the same TEE rule?
>
> Oh, sorry, you are right. It happens with an unpatched net-next kernel, too.
>
> I inserted the TEE rule in mangel/OUTGOING and had only one route, ip -6 r a
> default via fe80::1 dev eth0 which at the time of the panic was actually not
> reachable.
Thanks for the confirmation! I'll try later
to reproduce such problem with TEE, it is interesting
to know the real reason for this loop.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: [PATCH] iwlwifi: remove duplicate includes
From: Grumbach, Emmanuel @ 2013-10-20 6:01 UTC (permalink / raw)
To: Michael Opdenacker, Berg, Johannes, ilw@linux.intel.com,
linville@tuxdriver.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1382245260-19065-1-git-send-email-michael.opdenacker@free-electrons.com>
> Subject: [PATCH] iwlwifi: remove duplicate includes
>
> Reported by "make includecheck"
>
> Tested that the corresponding sources still compile well on x86
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-
> electrons.com>
> ---
Picked up. Thanks.
^ permalink raw reply
* [PATCH] ethernet: moxa: remove duplicate includes
From: Michael Opdenacker @ 2013-10-20 5:13 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-kernel, Michael Opdenacker
Reported by "make includecheck"
Tested that drivers/net/ethernet/moxa/moxart_ether.c still compiles
well on ARM
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/moxa/moxart_ether.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/moxa/moxart_ether.c b/drivers/net/ethernet/moxa/moxart_ether.c
index bd1a2d2..7d4c8cc 100644
--- a/drivers/net/ethernet/moxa/moxart_ether.c
+++ b/drivers/net/ethernet/moxa/moxart_ether.c
@@ -26,7 +26,6 @@
#include <linux/of_irq.h>
#include <linux/crc32.h>
#include <linux/crc32c.h>
-#include <linux/dma-mapping.h>
#include "moxart_ether.h"
--
1.8.1.2
^ permalink raw reply related
* [PATCH] cgxb4: remove duplicate include in cxgb4.h
From: Michael Opdenacker @ 2013-10-20 5:10 UTC (permalink / raw)
To: dm; +Cc: netdev, linux-kernel, Michael Opdenacker
Reported by "make includecheck"
Tested that C sources including this file still compile well on x86
Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index dfd1e36..ecd2fb3 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -48,7 +48,6 @@
#include <linux/vmalloc.h>
#include <asm/io.h>
#include "cxgb4_uld.h"
-#include "t4_hw.h"
#define FW_VERSION_MAJOR 1
#define FW_VERSION_MINOR 4
--
1.8.1.2
^ permalink raw reply related
* nf_tables*.h: Remove extern from function prototypes
From: Joe Perches @ 2013-10-20 5:05 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, linux-kernel
In-Reply-To: <cover.1382129045.git.joe@perches.com>
There are a mix of function prototypes with and without extern
in the kernel sources. Standardize on not using extern for
function prototypes.
Function prototypes don't need to be written with extern.
extern is assumed by the compiler. Its use is as unnecessary as
using auto to declare automatic/local variables in a block.
Signed-off-by: Joe Perches <joe@perches.com>
---
include/net/netfilter/nf_tables.h | 55 ++++++++++++++++------------------
include/net/netfilter/nf_tables_core.h | 28 ++++++++---------
2 files changed, 40 insertions(+), 43 deletions(-)
diff --git a/include/net/netfilter/nf_tables.h b/include/net/netfilter/nf_tables.h
index 54c4a5c..5a91abf 100644
--- a/include/net/netfilter/nf_tables.h
+++ b/include/net/netfilter/nf_tables.h
@@ -91,13 +91,11 @@ struct nft_data_desc {
unsigned int len;
};
-extern int nft_data_init(const struct nft_ctx *ctx, struct nft_data *data,
- struct nft_data_desc *desc, const struct nlattr *nla);
-extern void nft_data_uninit(const struct nft_data *data,
- enum nft_data_types type);
-extern int nft_data_dump(struct sk_buff *skb, int attr,
- const struct nft_data *data,
- enum nft_data_types type, unsigned int len);
+int nft_data_init(const struct nft_ctx *ctx, struct nft_data *data,
+ struct nft_data_desc *desc, const struct nlattr *nla);
+void nft_data_uninit(const struct nft_data *data, enum nft_data_types type);
+int nft_data_dump(struct sk_buff *skb, int attr, const struct nft_data *data,
+ enum nft_data_types type, unsigned int len);
static inline enum nft_data_types nft_dreg_to_type(enum nft_registers reg)
{
@@ -109,12 +107,11 @@ static inline enum nft_registers nft_type_to_reg(enum nft_data_types type)
return type == NFT_DATA_VERDICT ? NFT_REG_VERDICT : NFT_REG_1;
}
-extern int nft_validate_input_register(enum nft_registers reg);
-extern int nft_validate_output_register(enum nft_registers reg);
-extern int nft_validate_data_load(const struct nft_ctx *ctx,
- enum nft_registers reg,
- const struct nft_data *data,
- enum nft_data_types type);
+int nft_validate_input_register(enum nft_registers reg);
+int nft_validate_output_register(enum nft_registers reg);
+int nft_validate_data_load(const struct nft_ctx *ctx, enum nft_registers reg,
+ const struct nft_data *data,
+ enum nft_data_types type);
/**
* struct nft_set_elem - generic representation of set elements
@@ -183,8 +180,8 @@ struct nft_set_ops {
u32 features;
};
-extern int nft_register_set(struct nft_set_ops *ops);
-extern void nft_unregister_set(struct nft_set_ops *ops);
+int nft_register_set(struct nft_set_ops *ops);
+void nft_unregister_set(struct nft_set_ops *ops);
/**
* struct nft_set - nf_tables set instance
@@ -220,8 +217,8 @@ static inline void *nft_set_priv(const struct nft_set *set)
return (void *)set->data;
}
-extern struct nft_set *nf_tables_set_lookup(const struct nft_table *table,
- const struct nlattr *nla);
+struct nft_set *nf_tables_set_lookup(const struct nft_table *table,
+ const struct nlattr *nla);
/**
* struct nft_set_binding - nf_tables set binding
@@ -237,10 +234,10 @@ struct nft_set_binding {
const struct nft_chain *chain;
};
-extern int nf_tables_bind_set(const struct nft_ctx *ctx, struct nft_set *set,
- struct nft_set_binding *binding);
-extern void nf_tables_unbind_set(const struct nft_ctx *ctx, struct nft_set *set,
- struct nft_set_binding *binding);
+int nf_tables_bind_set(const struct nft_ctx *ctx, struct nft_set *set,
+ struct nft_set_binding *binding);
+void nf_tables_unbind_set(const struct nft_ctx *ctx, struct nft_set *set,
+ struct nft_set_binding *binding);
/**
@@ -446,8 +443,8 @@ static inline struct nft_base_chain *nft_base_chain(const struct nft_chain *chai
return container_of(chain, struct nft_base_chain, chain);
}
-extern unsigned int nft_do_chain_pktinfo(struct nft_pktinfo *pkt,
- const struct nf_hook_ops *ops);
+unsigned int nft_do_chain_pktinfo(struct nft_pktinfo *pkt,
+ const struct nf_hook_ops *ops);
/**
* struct nft_table - nf_tables table
@@ -489,8 +486,8 @@ struct nft_af_info {
nf_hookfn *hooks[NF_MAX_HOOKS];
};
-extern int nft_register_afinfo(struct net *, struct nft_af_info *);
-extern void nft_unregister_afinfo(struct nft_af_info *);
+int nft_register_afinfo(struct net *, struct nft_af_info *);
+void nft_unregister_afinfo(struct nft_af_info *);
struct nf_chain_type {
unsigned int hook_mask;
@@ -501,11 +498,11 @@ struct nf_chain_type {
int family;
};
-extern int nft_register_chain_type(struct nf_chain_type *);
-extern void nft_unregister_chain_type(struct nf_chain_type *);
+int nft_register_chain_type(struct nf_chain_type *);
+void nft_unregister_chain_type(struct nf_chain_type *);
-extern int nft_register_expr(struct nft_expr_type *);
-extern void nft_unregister_expr(struct nft_expr_type *);
+int nft_register_expr(struct nft_expr_type *);
+void nft_unregister_expr(struct nft_expr_type *);
#define MODULE_ALIAS_NFT_FAMILY(family) \
MODULE_ALIAS("nft-afinfo-" __stringify(family))
diff --git a/include/net/netfilter/nf_tables_core.h b/include/net/netfilter/nf_tables_core.h
index fe7b162..cf2b7ae 100644
--- a/include/net/netfilter/nf_tables_core.h
+++ b/include/net/netfilter/nf_tables_core.h
@@ -1,11 +1,11 @@
#ifndef _NET_NF_TABLES_CORE_H
#define _NET_NF_TABLES_CORE_H
-extern int nf_tables_core_module_init(void);
-extern void nf_tables_core_module_exit(void);
+int nf_tables_core_module_init(void);
+void nf_tables_core_module_exit(void);
-extern int nft_immediate_module_init(void);
-extern void nft_immediate_module_exit(void);
+int nft_immediate_module_init(void);
+void nft_immediate_module_exit(void);
struct nft_cmp_fast_expr {
u32 data;
@@ -15,17 +15,17 @@ struct nft_cmp_fast_expr {
extern const struct nft_expr_ops nft_cmp_fast_ops;
-extern int nft_cmp_module_init(void);
-extern void nft_cmp_module_exit(void);
+int nft_cmp_module_init(void);
+void nft_cmp_module_exit(void);
-extern int nft_lookup_module_init(void);
-extern void nft_lookup_module_exit(void);
+int nft_lookup_module_init(void);
+void nft_lookup_module_exit(void);
-extern int nft_bitwise_module_init(void);
-extern void nft_bitwise_module_exit(void);
+int nft_bitwise_module_init(void);
+void nft_bitwise_module_exit(void);
-extern int nft_byteorder_module_init(void);
-extern void nft_byteorder_module_exit(void);
+int nft_byteorder_module_init(void);
+void nft_byteorder_module_exit(void);
struct nft_payload {
enum nft_payload_bases base:8;
@@ -36,7 +36,7 @@ struct nft_payload {
extern const struct nft_expr_ops nft_payload_fast_ops;
-extern int nft_payload_module_init(void);
-extern void nft_payload_module_exit(void);
+int nft_payload_module_init(void);
+void nft_payload_module_exit(void);
#endif /* _NET_NF_TABLES_CORE_H */
^ permalink raw reply related
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