* [PATCH] ndisc: Use more standard logging styles
From: Joe Perches @ 2012-12-14 4:07 UTC (permalink / raw)
To: David Miller; +Cc: djduanjiong, steffen.klassert, netdev
In-Reply-To: <20121213.145028.509906659453424680.davem@davemloft.net>
The logging style in this file is "baroque".
Convert indirect uses of net_<level>_ratelimited to
simply use net_<level>_ratelimited.
Add a nd_dbg macro and #define ND_DEBUG for the other
generally inactivated logging messages.
Make those inactivated messages emit only at KERN_DEBUG
instead of other levels. Add "%s: " __func__ to all
these nd_dbg macros and remove the embedded function
names and prefixes.
Signed-off-by: Joe Perches <joe@perches.com>
---
net/ipv6/ndisc.c | 139 ++++++++++++++++++++++++------------------------------
1 files changed, 61 insertions(+), 78 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index f2a007b..de1c1f2 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -72,14 +72,19 @@
#include <linux/netfilter.h>
#include <linux/netfilter_ipv6.h>
-/* Set to 3 to get tracing... */
-#define ND_DEBUG 1
+/* #define ND_DEBUG */
-#define ND_PRINTK(val, level, fmt, ...) \
+#ifdef ND_DEBUG
+#define nd_dbg(fmt, ...) \
+ net_dbg_ratelimited("%s: " fmt, __func__, ##__VA_ARGS__)
+#else
+#define nd_dbg(fmt, ...) \
do { \
- if (val <= ND_DEBUG) \
- net_##level##_ratelimited(fmt, ##__VA_ARGS__); \
+ if (0) \
+ net_dbg_ratelimited("%s: " fmt, \
+ __func__, ##__VA_ARGS__); \
} while (0)
+#endif
static u32 ndisc_hash(const void *pkey,
const struct net_device *dev,
@@ -220,9 +225,8 @@ struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
case ND_OPT_MTU:
case ND_OPT_REDIRECT_HDR:
if (ndopts->nd_opt_array[nd_opt->nd_opt_type]) {
- ND_PRINTK(2, warn,
- "%s: duplicated ND6 option found: type=%d\n",
- __func__, nd_opt->nd_opt_type);
+ nd_dbg("duplicated ND6 option found: type=%d\n",
+ nd_opt->nd_opt_type);
} else {
ndopts->nd_opt_array[nd_opt->nd_opt_type] = nd_opt;
}
@@ -250,11 +254,9 @@ struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
* to accommodate future extension to the
* protocol.
*/
- ND_PRINTK(2, notice,
- "%s: ignored unsupported option; type=%d, len=%d\n",
- __func__,
- nd_opt->nd_opt_type,
- nd_opt->nd_opt_len);
+ nd_dbg("ignored unsupported option; type=%d, len=%d\n",
+ nd_opt->nd_opt_type,
+ nd_opt->nd_opt_len);
}
}
opt_len -= l;
@@ -399,8 +401,8 @@ static struct sk_buff *ndisc_build_skb(struct net_device *dev,
len + hlen + tlen),
1, &err);
if (!skb) {
- ND_PRINTK(0, err, "ND: %s failed to allocate an skb, err=%d\n",
- __func__, err);
+ net_err_ratelimited("ND: %s failed to allocate an skb, err=%d\n",
+ __func__, err);
return NULL;
}
@@ -629,9 +631,8 @@ static void ndisc_solicit(struct neighbour *neigh, struct sk_buff *skb)
if ((probes -= neigh->parms->ucast_probes) < 0) {
if (!(neigh->nud_state & NUD_VALID)) {
- ND_PRINTK(1, dbg,
- "%s: trying to ucast probe in NUD_INVALID: %pI6\n",
- __func__, target);
+ net_dbg_ratelimited("%s: trying to ucast probe in NUD_INVALID: %pI6\n",
+ __func__, target);
}
ndisc_send_ns(dev, neigh, target, target, saddr);
} else if ((probes -= neigh->parms->app_probes) < 0) {
@@ -677,7 +678,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
int is_router = -1;
if (ipv6_addr_is_multicast(&msg->target)) {
- ND_PRINTK(2, warn, "NS: multicast target address\n");
+ nd_dbg("multicast target address\n");
return;
}
@@ -690,20 +691,19 @@ static void ndisc_recv_ns(struct sk_buff *skb)
daddr->s6_addr32[1] == htonl(0x00000000) &&
daddr->s6_addr32[2] == htonl(0x00000001) &&
daddr->s6_addr [12] == 0xff )) {
- ND_PRINTK(2, warn, "NS: bad DAD packet (wrong destination)\n");
+ nd_dbg("bad DAD packet (wrong destination)\n");
return;
}
if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) {
- ND_PRINTK(2, warn, "NS: invalid ND options\n");
+ nd_dbg("invalid ND options\n");
return;
}
if (ndopts.nd_opts_src_lladdr) {
lladdr = ndisc_opt_addr_data(ndopts.nd_opts_src_lladdr, dev);
if (!lladdr) {
- ND_PRINTK(2, warn,
- "NS: invalid link-layer address length\n");
+ nd_dbg("invalid link-layer address length\n");
return;
}
@@ -713,8 +713,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
* in the message.
*/
if (dad) {
- ND_PRINTK(2, warn,
- "NS: bad DAD packet (link-layer address option)\n");
+ nd_dbg("bad DAD packet (link-layer address option)\n");
return;
}
}
@@ -832,30 +831,29 @@ static void ndisc_recv_na(struct sk_buff *skb)
struct neighbour *neigh;
if (skb->len < sizeof(struct nd_msg)) {
- ND_PRINTK(2, warn, "NA: packet too short\n");
+ nd_dbg("packet too short\n");
return;
}
if (ipv6_addr_is_multicast(&msg->target)) {
- ND_PRINTK(2, warn, "NA: target address is multicast\n");
+ nd_dbg("target address is multicast\n");
return;
}
if (ipv6_addr_is_multicast(daddr) &&
msg->icmph.icmp6_solicited) {
- ND_PRINTK(2, warn, "NA: solicited NA is multicasted\n");
+ nd_dbg("solicited NA is multicasted\n");
return;
}
if (!ndisc_parse_options(msg->opt, ndoptlen, &ndopts)) {
- ND_PRINTK(2, warn, "NS: invalid ND option\n");
+ nd_dbg("invalid ND option\n");
return;
}
if (ndopts.nd_opts_tgt_lladdr) {
lladdr = ndisc_opt_addr_data(ndopts.nd_opts_tgt_lladdr, dev);
if (!lladdr) {
- ND_PRINTK(2, warn,
- "NA: invalid link-layer address length\n");
+ nd_dbg("invalid link-layer address length\n");
return;
}
}
@@ -876,9 +874,8 @@ static void ndisc_recv_na(struct sk_buff *skb)
unsolicited advertisement.
*/
if (skb->pkt_type != PACKET_LOOPBACK)
- ND_PRINTK(1, warn,
- "NA: someone advertises our address %pI6 on %s!\n",
- &ifp->addr, ifp->idev->dev->name);
+ net_warn_ratelimited("NA: someone advertises our address %pI6 on %s!\n",
+ &ifp->addr, ifp->idev->dev->name);
in6_ifa_put(ifp);
return;
}
@@ -940,7 +937,7 @@ static void ndisc_recv_rs(struct sk_buff *skb)
idev = __in6_dev_get(skb->dev);
if (!idev) {
- ND_PRINTK(1, err, "RS: can't find in6 device\n");
+ net_err_ratelimited("RS: can't find in6 device\n");
return;
}
@@ -957,7 +954,7 @@ static void ndisc_recv_rs(struct sk_buff *skb)
/* Parse ND options */
if (!ndisc_parse_options(rs_msg->opt, ndoptlen, &ndopts)) {
- ND_PRINTK(2, notice, "NS: invalid ND option, ignored\n");
+ nd_dbg("invalid ND option, ignored\n");
goto out;
}
@@ -1043,17 +1040,17 @@ static void ndisc_router_discovery(struct sk_buff *skb)
optlen = (skb->tail - skb->transport_header) - sizeof(struct ra_msg);
if (!(ipv6_addr_type(&ipv6_hdr(skb)->saddr) & IPV6_ADDR_LINKLOCAL)) {
- ND_PRINTK(2, warn, "RA: source address is not link-local\n");
+ nd_dbg("source address is not link-local\n");
return;
}
if (optlen < 0) {
- ND_PRINTK(2, warn, "RA: packet too short\n");
+ nd_dbg("packet too short\n");
return;
}
#ifdef CONFIG_IPV6_NDISC_NODETYPE
if (skb->ndisc_nodetype == NDISC_NODETYPE_HOST) {
- ND_PRINTK(2, warn, "RA: from host or unauthorized router\n");
+ nd_dbg("from host or unauthorized router\n");
return;
}
#endif
@@ -1064,13 +1061,13 @@ static void ndisc_router_discovery(struct sk_buff *skb)
in6_dev = __in6_dev_get(skb->dev);
if (in6_dev == NULL) {
- ND_PRINTK(0, err, "RA: can't find inet6 device for %s\n",
- skb->dev->name);
+ net_err_ratelimited("RA: can't find inet6 device for %s\n",
+ skb->dev->name);
return;
}
if (!ndisc_parse_options(opt, optlen, &ndopts)) {
- ND_PRINTK(2, warn, "RA: invalid ND options\n");
+ nd_dbg("invalid ND options\n");
return;
}
@@ -1123,9 +1120,8 @@ static void ndisc_router_discovery(struct sk_buff *skb)
if (rt) {
neigh = dst_neigh_lookup(&rt->dst, &ipv6_hdr(skb)->saddr);
if (!neigh) {
- ND_PRINTK(0, err,
- "RA: %s got default router without neighbour\n",
- __func__);
+ net_err_ratelimited("RA: %s got default router without neighbour\n",
+ __func__);
ip6_rt_put(rt);
return;
}
@@ -1136,21 +1132,19 @@ static void ndisc_router_discovery(struct sk_buff *skb)
}
if (rt == NULL && lifetime) {
- ND_PRINTK(3, dbg, "RA: adding default router\n");
+ nd_dbg("adding default router\n");
rt = rt6_add_dflt_router(&ipv6_hdr(skb)->saddr, skb->dev, pref);
if (rt == NULL) {
- ND_PRINTK(0, err,
- "RA: %s failed to add default route\n",
- __func__);
+ net_err_ratelimited("RA: %s failed to add default route\n",
+ __func__);
return;
}
neigh = dst_neigh_lookup(&rt->dst, &ipv6_hdr(skb)->saddr);
if (neigh == NULL) {
- ND_PRINTK(0, err,
- "RA: %s got default router without neighbour\n",
- __func__);
+ net_err_ratelimited("RA: %s got default router without neighbour\n",
+ __func__);
ip6_rt_put(rt);
return;
}
@@ -1218,8 +1212,7 @@ skip_linkparms:
lladdr = ndisc_opt_addr_data(ndopts.nd_opts_src_lladdr,
skb->dev);
if (!lladdr) {
- ND_PRINTK(2, warn,
- "RA: invalid link-layer address length\n");
+ nd_dbg("invalid link-layer address length\n");
goto out;
}
}
@@ -1283,7 +1276,7 @@ skip_routeinfo:
mtu = ntohl(n);
if (mtu < IPV6_MIN_MTU || mtu > skb->dev->mtu) {
- ND_PRINTK(2, warn, "RA: invalid mtu: %d\n", mtu);
+ nd_dbg("invalid mtu: %d\n", mtu);
} else if (in6_dev->cnf.mtu6 != mtu) {
in6_dev->cnf.mtu6 = mtu;
@@ -1304,7 +1297,7 @@ skip_routeinfo:
}
if (ndopts.nd_opts_tgt_lladdr || ndopts.nd_opts_rh) {
- ND_PRINTK(2, warn, "RA: invalid RA options\n");
+ nd_dbg("invalid RA options\n");
}
out:
ip6_rt_put(rt);
@@ -1318,15 +1311,13 @@ static void ndisc_redirect_rcv(struct sk_buff *skb)
switch (skb->ndisc_nodetype) {
case NDISC_NODETYPE_HOST:
case NDISC_NODETYPE_NODEFAULT:
- ND_PRINTK(2, warn,
- "Redirect: from host or unauthorized router\n");
+ nd_dbg("from host or unauthorized router\n");
return;
}
#endif
if (!(ipv6_addr_type(&ipv6_hdr(skb)->saddr) & IPV6_ADDR_LINKLOCAL)) {
- ND_PRINTK(2, warn,
- "Redirect: source address is not link-local\n");
+ nd_dbg("source address is not link-local\n");
return;
}
@@ -1356,15 +1347,13 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
bool ret;
if (ipv6_get_lladdr(dev, &saddr_buf, IFA_F_TENTATIVE)) {
- ND_PRINTK(2, warn, "Redirect: no link-local address on %s\n",
- dev->name);
+ nd_dbg("no link-local address on %s\n", dev->name);
return;
}
if (!ipv6_addr_equal(&ipv6_hdr(skb)->daddr, target) &&
ipv6_addr_type(target) != (IPV6_ADDR_UNICAST|IPV6_ADDR_LINKLOCAL)) {
- ND_PRINTK(2, warn,
- "Redirect: target address is not link-local unicast\n");
+ nd_dbg("target address is not link-local unicast\n");
return;
}
@@ -1383,8 +1372,7 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
rt = (struct rt6_info *) dst;
if (rt->rt6i_flags & RTF_GATEWAY) {
- ND_PRINTK(2, warn,
- "Redirect: destination is not a neighbour\n");
+ nd_dbg("destination is not a neighbour\n");
goto release;
}
peer = inet_getpeer_v6(net->ipv6.peers, &rt->rt6i_dst.addr, 1);
@@ -1397,8 +1385,7 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
if (dev->addr_len) {
struct neighbour *neigh = dst_neigh_lookup(skb_dst(skb), target);
if (!neigh) {
- ND_PRINTK(2, warn,
- "Redirect: no neigh for target address\n");
+ nd_dbg("no neigh for target address\n");
goto release;
}
@@ -1426,9 +1413,8 @@ void ndisc_send_redirect(struct sk_buff *skb, const struct in6_addr *target)
len + hlen + tlen),
1, &err);
if (buff == NULL) {
- ND_PRINTK(0, err,
- "Redirect: %s failed to allocate an skb, err=%d\n",
- __func__, err);
+ net_err_ratelimited("Redirect: %s failed to allocate an skb, err=%d\n",
+ __func__, err);
goto release;
}
@@ -1513,14 +1499,12 @@ int ndisc_rcv(struct sk_buff *skb)
__skb_push(skb, skb->data - skb_transport_header(skb));
if (ipv6_hdr(skb)->hop_limit != 255) {
- ND_PRINTK(2, warn, "NDISC: invalid hop-limit: %d\n",
- ipv6_hdr(skb)->hop_limit);
+ nd_dbg("invalid hop-limit: %d\n", ipv6_hdr(skb)->hop_limit);
return 0;
}
if (msg->icmph.icmp6_code != 0) {
- ND_PRINTK(2, warn, "NDISC: invalid ICMPv6 code: %d\n",
- msg->icmph.icmp6_code);
+ nd_dbg("invalid ICMPv6 code: %d\n", msg->icmph.icmp6_code);
return 0;
}
@@ -1648,9 +1632,8 @@ static int __net_init ndisc_net_init(struct net *net)
err = inet_ctl_sock_create(&sk, PF_INET6,
SOCK_RAW, IPPROTO_ICMPV6, net);
if (err < 0) {
- ND_PRINTK(0, err,
- "NDISC: Failed to initialize the control socket (err %d)\n",
- err);
+ net_err_ratelimited("NDISC: Failed to initialize the control socket (err %d)\n",
+ err);
return err;
}
^ permalink raw reply related
* Re: [RFC][PATCH] bgmac: driver for GBit MAC core on BCMA bus
From: Joe Perches @ 2012-12-14 1:21 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: netdev, David S. Miller
In-Reply-To: <CACna6rwJZpjdyWjkdoLrcyo3+Pq8CCk4x1N5GS+n8P5prBVm2A@mail.gmail.com>
On Thu, 2012-12-13 at 20:24 +0100, Rafał Miłecki wrote:
> 2012/12/13 Joe Perches <joe@perches.com>:
> > On Thu, 2012-12-13 at 18:43 +0100, Rafał Miłecki wrote:
> >> BCMA is a Broadcom specific bus with devices AKA cores. All recent BCMA
> >> based SoCs have gigabit ethernet provided by the GBit MAC core. This
> >> patch adds driver for such a cores registering itself as a netdev. It
> >> has been tested on a BCM4706 and BCM4718 chipsets.
[]
> >> + /* Stats */
> >> + bool stats_grabbed;
> >> + u32 mib_tx_regs[BGMAC_NUM_MIB_TX_REGS];
> >> + u32 mib_rx_regs[BGMAC_NUM_MIB_RX_REGS];
> >> +};
> >
> > Maybe some minor reordering of the u8/bools to reduce padding.
>
> Really? Compiler won't do that for me? I hope that compiler optimizes
> structs (until using __packed) :(
The compiler is not allowed to reorder struct members.
Perhaps you bundle together all the u8/bools.
Maybe not when/where cachelines are crossed.
^ permalink raw reply
* Re: [PATCH] bridge: Bug fix for incorrect interpretation of MLDv2 maximum response code
From: Stephen Hemminger @ 2012-12-14 0:51 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev, bridge
In-Reply-To: <50CA7449.8000305@sfc.wide.ad.jp>
On Fri, 14 Dec 2012 08:35:21 +0800
Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
> On 14/12/2012 08:23, Stephen Hemminger wrote:
> > On Fri, 14 Dec 2012 08:19:04 +0800
> > Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
> >
> >> On 14/12/2012 08:12, Stephen Hemminger wrote:
> >>> On Fri, 14 Dec 2012 08:07:01 +0800
> >>> Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
> >>>
> >>>> This patch fixes the incorrect interpretation of endianness of MLDv2 maximum response
> >>>> code within bridge's multicast snooping code.
> >>>>
> >>>> Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
> >>>> ---
> >>>> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> >>>> index 977c3ee..29c6283 100644
> >>>> --- a/net/bridge/br_multicast.c
> >>>> +++ b/net/bridge/br_multicast.c
> >>>> @@ -1172,7 +1172,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
> >>>> mld2q = (struct mld2_query *)icmp6_hdr(skb);
> >>>> if (!mld2q->mld2q_nsrcs)
> >>>> group = &mld2q->mld2q_mca;
> >>>> - max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(mld2q->mld2q_mrc) : 1;
> >>>> + max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(ntohs(mld2q->mld2q_mrc)) : 1;
> >>>> }
> >>>>
> >>>> if (!group)
> >>> Already fixed as part of my patch to fix sparse warnings.
> >>> --
> >>> 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
> >>>
> >> aye, aye.
> > Yours looks cleaner (I added a temp variable). You might want to submit
> > patch to switch to your oneline version.
> >
> Well, the patch did get into the netdev mailing list. I think your direct reply arrived in my mailbox first before I received my own patch through netdev. By the way, I don't see your patch on net-next git. Otherwise, I wouldn't have gone through the trouble of debugging and testing it on my computer. Is there any other repo that I should watch out to avoid this kind of silly situation in the future?
You didn't see it because net-next tree is currently closed/idle until Dave opens it up for next release (3.9)
At this time, the only patches are those in the net tree:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git
Which is where fixes for the current release are staged for Linus.
commit eca2a43bb0d2c6ebd528be6acb30a88435abe307
Author: stephen hemminger <shemminger@vyatta.com>
Date: Thu Dec 13 06:51:28 2012 +0000
bridge: fix icmpv6 endian bug and other sparse warnings
Fix the warnings reported by sparse on recent bridge multicast
changes. Mostly just rcu annotation issues but in this case
sparse found a real bug! The ICMPv6 mld2 query mrc
values is in network byte order.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] bridge: Bug fix for incorrect interpretation of MLDv2 maximum response code
From: Ang Way Chuang @ 2012-12-14 0:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bridge
In-Reply-To: <20121213162346.71c3779f@nehalam.linuxnetplumber.net>
On 14/12/2012 08:23, Stephen Hemminger wrote:
> On Fri, 14 Dec 2012 08:19:04 +0800
> Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
>
>> On 14/12/2012 08:12, Stephen Hemminger wrote:
>>> On Fri, 14 Dec 2012 08:07:01 +0800
>>> Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
>>>
>>>> This patch fixes the incorrect interpretation of endianness of MLDv2 maximum response
>>>> code within bridge's multicast snooping code.
>>>>
>>>> Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
>>>> ---
>>>> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
>>>> index 977c3ee..29c6283 100644
>>>> --- a/net/bridge/br_multicast.c
>>>> +++ b/net/bridge/br_multicast.c
>>>> @@ -1172,7 +1172,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
>>>> mld2q = (struct mld2_query *)icmp6_hdr(skb);
>>>> if (!mld2q->mld2q_nsrcs)
>>>> group = &mld2q->mld2q_mca;
>>>> - max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(mld2q->mld2q_mrc) : 1;
>>>> + max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(ntohs(mld2q->mld2q_mrc)) : 1;
>>>> }
>>>>
>>>> if (!group)
>>> Already fixed as part of my patch to fix sparse warnings.
>>> --
>>> 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
>>>
>> aye, aye.
> Yours looks cleaner (I added a temp variable). You might want to submit
> patch to switch to your oneline version.
>
Well, the patch did get into the netdev mailing list. I think your direct reply arrived in my mailbox first before I received my own patch through netdev. By the way, I don't see your patch on net-next git. Otherwise, I wouldn't have gone through the trouble of debugging and testing it on my computer. Is there any other repo that I should watch out to avoid this kind of silly situation in the future?
^ permalink raw reply
* Re: [PATCH] bridge: Bug fix for incorrect interpretation of MLDv2 maximum response code
From: Stephen Hemminger @ 2012-12-14 0:23 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev, bridge
In-Reply-To: <50CA7078.8070204@sfc.wide.ad.jp>
On Fri, 14 Dec 2012 08:19:04 +0800
Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
> On 14/12/2012 08:12, Stephen Hemminger wrote:
> > On Fri, 14 Dec 2012 08:07:01 +0800
> > Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
> >
> >> This patch fixes the incorrect interpretation of endianness of MLDv2 maximum response
> >> code within bridge's multicast snooping code.
> >>
> >> Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
> >> ---
> >> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> >> index 977c3ee..29c6283 100644
> >> --- a/net/bridge/br_multicast.c
> >> +++ b/net/bridge/br_multicast.c
> >> @@ -1172,7 +1172,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
> >> mld2q = (struct mld2_query *)icmp6_hdr(skb);
> >> if (!mld2q->mld2q_nsrcs)
> >> group = &mld2q->mld2q_mca;
> >> - max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(mld2q->mld2q_mrc) : 1;
> >> + max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(ntohs(mld2q->mld2q_mrc)) : 1;
> >> }
> >>
> >> if (!group)
> > Already fixed as part of my patch to fix sparse warnings.
> > --
> > 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
> >
> aye, aye.
Yours looks cleaner (I added a temp variable). You might want to submit
patch to switch to your oneline version.
^ permalink raw reply
* Re: [PATCH] bridge: Bug fix for incorrect interpretation of MLDv2 maximum response code
From: Ang Way Chuang @ 2012-12-14 0:19 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bridge
In-Reply-To: <20121213161201.6d2da433@nehalam.linuxnetplumber.net>
On 14/12/2012 08:12, Stephen Hemminger wrote:
> On Fri, 14 Dec 2012 08:07:01 +0800
> Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
>
>> This patch fixes the incorrect interpretation of endianness of MLDv2 maximum response
>> code within bridge's multicast snooping code.
>>
>> Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
>> ---
>> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
>> index 977c3ee..29c6283 100644
>> --- a/net/bridge/br_multicast.c
>> +++ b/net/bridge/br_multicast.c
>> @@ -1172,7 +1172,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
>> mld2q = (struct mld2_query *)icmp6_hdr(skb);
>> if (!mld2q->mld2q_nsrcs)
>> group = &mld2q->mld2q_mca;
>> - max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(mld2q->mld2q_mrc) : 1;
>> + max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(ntohs(mld2q->mld2q_mrc)) : 1;
>> }
>>
>> if (!group)
> Already fixed as part of my patch to fix sparse warnings.
> --
> 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
>
aye, aye.
^ permalink raw reply
* [PATCH] bridge: Bug fix for incorrect interpretation of MLDv2 maximum response code
From: Ang Way Chuang @ 2012-12-14 0:07 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger, bridge
This patch fixes the incorrect interpretation of endianness of MLDv2 maximum response
code within bridge's multicast snooping code.
Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
---
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 977c3ee..29c6283 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1172,7 +1172,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
mld2q = (struct mld2_query *)icmp6_hdr(skb);
if (!mld2q->mld2q_nsrcs)
group = &mld2q->mld2q_mca;
- max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(mld2q->mld2q_mrc) : 1;
+ max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(ntohs(mld2q->mld2q_mrc)) : 1;
}
if (!group)
^ permalink raw reply related
* Re: [PATCH] bridge: Bug fix for incorrect interpretation of MLDv2 maximum response code
From: Stephen Hemminger @ 2012-12-14 0:12 UTC (permalink / raw)
To: Ang Way Chuang; +Cc: netdev, bridge
In-Reply-To: <50CA6DA5.1020101@sfc.wide.ad.jp>
On Fri, 14 Dec 2012 08:07:01 +0800
Ang Way Chuang <wcang@sfc.wide.ad.jp> wrote:
> This patch fixes the incorrect interpretation of endianness of MLDv2 maximum response
> code within bridge's multicast snooping code.
>
> Signed-off-by: Ang Way Chuang <wcang@sfc.wide.ad.jp>
> ---
> diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
> index 977c3ee..29c6283 100644
> --- a/net/bridge/br_multicast.c
> +++ b/net/bridge/br_multicast.c
> @@ -1172,7 +1172,7 @@ static int br_ip6_multicast_query(struct net_bridge *br,
> mld2q = (struct mld2_query *)icmp6_hdr(skb);
> if (!mld2q->mld2q_nsrcs)
> group = &mld2q->mld2q_mca;
> - max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(mld2q->mld2q_mrc) : 1;
> + max_delay = mld2q->mld2q_mrc ? MLDV2_MRC(ntohs(mld2q->mld2q_mrc)) : 1;
> }
>
> if (!group)
Already fixed as part of my patch to fix sparse warnings.
^ permalink raw reply
* Re: [PATCH] Fix: kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock
From: Eric Dumazet @ 2012-12-13 23:38 UTC (permalink / raw)
To: Christoph Paasch
Cc: David Miller, Gerrit Renker, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, dccp
In-Reply-To: <1355435363-12766-1-git-send-email-christoph.paasch@uclouvain.be>
On Thu, 2012-12-13 at 22:49 +0100, Christoph Paasch wrote:
> If in either of the above functions inet_csk_route_child_sock() or
> __inet_inherit_port() fails, the newsk will not be freed:
>
> unreferenced object 0xffff88022e8a92c0 (size 1592):
> comm "softirq", pid 0, jiffies 4294946244 (age 726.160s)
> hex dump (first 32 bytes):
> 0a 01 01 01 0a 01 01 02 00 00 00 00 a7 cc 16 00 ................
> 02 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<ffffffff8153d190>] kmemleak_alloc+0x21/0x3e
> [<ffffffff810ab3e7>] kmem_cache_alloc+0xb5/0xc5
> [<ffffffff8149b65b>] sk_prot_alloc.isra.53+0x2b/0xcd
> [<ffffffff8149b784>] sk_clone_lock+0x16/0x21e
> [<ffffffff814d711a>] inet_csk_clone_lock+0x10/0x7b
> [<ffffffff814ebbc3>] tcp_create_openreq_child+0x21/0x481
> [<ffffffff814e8fa5>] tcp_v4_syn_recv_sock+0x3a/0x23b
> [<ffffffff814ec5ba>] tcp_check_req+0x29f/0x416
> [<ffffffff814e8e10>] tcp_v4_do_rcv+0x161/0x2bc
> [<ffffffff814eb917>] tcp_v4_rcv+0x6c9/0x701
> [<ffffffff814cea9f>] ip_local_deliver_finish+0x70/0xc4
> [<ffffffff814cec20>] ip_local_deliver+0x4e/0x7f
> [<ffffffff814ce9f8>] ip_rcv_finish+0x1fc/0x233
> [<ffffffff814cee68>] ip_rcv+0x217/0x267
> [<ffffffff814a7bbe>] __netif_receive_skb+0x49e/0x553
> [<ffffffff814a7cc3>] netif_receive_skb+0x50/0x82
>
> This happens, because sk_clone_lock initializes sk_refcnt to 2, and thus
> a single sock_put() is not enough to free the memory. Additionally, things
> like xfrm, memcg, cookie_values,... may have been initialized.
> We have to free them properly.
>
> This is fixed by forcing a call to tcp_done(), ending up in
> inet_csk_destroy_sock, doing the final sock_put(). tcp_done() is necessary,
> because it ends up doing all the cleanup on xfrm, memcg, cookie_values,
> xfrm,...
>
> Before calling tcp_done, we have to set the socket to SOCK_DEAD, to
> force it entering inet_csk_destroy_sock. To avoid the warning in
> inet_csk_destroy_sock, inet_num has to be set to 0.
> As inet_csk_destroy_sock does a dec on orphan_count, we first have to
> increase it.
>
> Calling tcp_done() allows us to remove the calls to
> tcp_clear_xmit_timer() and tcp_cleanup_congestion_control().
>
> A similar approach is taken for dccp by calling dccp_done().
>
> This probably should be backported to kernels >= 3.0 as it is in the
> kernel since 0e734419923bd (ipv4: Use inet_csk_route_child_sock() in
> DCCP and TCP.).
Are you sure the above commit is the bug origin ?
It looks like bug was bring by transparent proxy in 2.6.37
commit 093d282321daeb19c107e5f1f16d7f68484f3ade
Author: Balazs Scheidler <bazsi@balabit.hu>
Date: Thu Oct 21 13:06:43 2010 +0200
tproxy: fix hash locking issue when using port redirection in __inet_inherit_port()
When __inet_inherit_port() is called on a tproxy connection the wrong locks are
held for the inet_bind_bucket it is added to. __inet_inherit_port() made an
implicit assumption that the listener's port number (and thus its bind bucket).
Unfortunately, if you're using the TPROXY target to redirect skbs to a
transparent proxy that assumption is not true anymore and things break.
This patch adds code to __inet_inherit_port() so that it can handle this case
by looking up or creating a new bind bucket for the child socket and updates
callers of __inet_inherit_port() to gracefully handle __inet_inherit_port()
failing.
Reported by and original patch from Stephen Buck <stephen.buck@exinda.com>.
See http://marc.info/?t=128169268200001&r=1&w=2 for the original discussion.
Signed-off-by: KOVACS Krisztian <hidden@balabit.hu>
Signed-off-by: Patrick McHardy <kaber@trash.net>
^ permalink raw reply
* Re: [RFT PATCH] 8139cp: properly support change of MTU values [v2]
From: Francois Romieu @ 2012-12-13 22:36 UTC (permalink / raw)
To: John Greene; +Cc: David Miller, netdev, dwmw2
In-Reply-To: <50CA32F9.4090807@redhat.com>
John Greene <jogreene@redhat.com> :
[...]
> Have incorporated this and test it on virtual hardware with on top of
> cb64edb6b89491edfdbae52ba7db9a8b8391d339 (my original work now
> upstream). I plan to submit your work herein upstream as well, with
> attribution to you, if that's ok?
Sure, go ahead.
I have a nasty 8110s (old netgear) bug to keep me busy.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Jamal Hadi Salim @ 2012-12-13 22:56 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, vyasevic, or.gerlitz, netdev, mst, john.r.fastabend
In-Reply-To: <20121213143712.6932cb22@nehalam.linuxnetplumber.net>
On 12-12-13 05:37 PM, Stephen Hemminger wrote:
>
> You can, run any action before it hits the bridge.
I think you and I have had this discussion before ;->
It works just fine on ingress.
#Add ingress qdisc on br0
tc qdisc add dev br0 ingress
#Add a filter to accept all and count
tc filter add dev br0 parent ffff: protocol ip prio 6 u32 match ip dst
0/0 flowid 1:16 action ok
#show the stats
root@jhs12:~# tc -s filter show parent ffff: dev br0
filter protocol ip pref 6 u32
filter protocol ip pref 6 u32 fh 800: ht divisor 1
filter protocol ip pref 6 u32 fh 800::800 order 2048 key ht 800 bkt 0
flowid 1:16
match 00000000/00000000 at 16
action order 1: gact action pass
random type none pass val 0
index 2 ref 1 bind 1 installed 269 sec used 74 sec
Action statistics:
Sent 1210 bytes 15 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
------
Look at those packets ...
cheers,
jamal
cheers,
jamal
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Stephen Hemminger @ 2012-12-13 22:37 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: David Miller, vyasevic, or.gerlitz, netdev, mst, john.r.fastabend
In-Reply-To: <50CA588F.9040800@mojatatu.com>
On Thu, 13 Dec 2012 17:37:03 -0500
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 12-12-13 05:02 PM, Stephen Hemminger wrote:
> > On Thu, 13 Dec 2012 15:17:30 -0500
>
> >
> > Nah, no reinvention, people who want to do filtering and bridging
> > just use openvswitch instead.
>
>
> so says the maintainer of bridging and iproute2.
> Why cant i use bridging as is and iproute2/tc filter action?
> What is the impediment for you my friend? command line cryptic,
> performance problem - what is it?
>
> cheers,
> jamal
>
>
You can, run any action before it hits the bridge.
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Jamal Hadi Salim @ 2012-12-13 22:37 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, vyasevic, or.gerlitz, netdev, mst, john.r.fastabend
In-Reply-To: <20121213140218.2c705bb5@nehalam.linuxnetplumber.net>
On 12-12-13 05:02 PM, Stephen Hemminger wrote:
> On Thu, 13 Dec 2012 15:17:30 -0500
>
> Nah, no reinvention, people who want to do filtering and bridging
> just use openvswitch instead.
so says the maintainer of bridging and iproute2.
Why cant i use bridging as is and iproute2/tc filter action?
What is the impediment for you my friend? command line cryptic,
performance problem - what is it?
cheers,
jamal
^ permalink raw reply
* Re: netconsole fun
From: Peter Hurley @ 2012-12-13 22:24 UTC (permalink / raw)
To: Neil Horman; +Cc: Cong Wang, netdev
In-Reply-To: <20121213211754.GC14796@hmsreliant.think-freely.org>
On Thu, 2012-12-13 at 16:17 -0500, Neil Horman wrote:
> On Thu, Dec 13, 2012 at 02:27:01PM -0500, Peter Hurley wrote:
> > On Thu, 2012-12-13 at 13:08 -0500, Neil Horman wrote:
> > > On Thu, Dec 13, 2012 at 09:49:31AM -0500, Peter Hurley wrote:
> > > > On Thu, 2012-12-13 at 07:36 -0500, Neil Horman wrote:
> > > > > On Wed, Dec 12, 2012 at 03:59:17PM -0500, Peter Hurley wrote:
> > > > > > On Tue, 2012-12-11 at 11:45 -0500, Neil Horman wrote:
> > > > > > > On Tue, Dec 11, 2012 at 10:16:51AM -0500, Peter Hurley wrote:
> > > > > > > > On Tue, 2012-12-11 at 09:30 -0500, Neil Horman wrote:
> > > > > > > > > On Tue, Dec 11, 2012 at 09:19:52AM -0500, Peter Hurley wrote:
> > > > > > > > > > On Tue, 2012-12-11 at 04:51 +0000, Cong Wang wrote:
> > > > > > > > > > > On Mon, 10 Dec 2012 at 14:17 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
> > > > > > > > > > > > Now that netpoll has been disabled for slaved devices, is there a
> > > > > > > > > > > > recommended method of running netconsole on a machine that has a slaved
> > > > > > > > > > > > device?
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Yes, running it on the master device instead.
> > > > > > > > > >
> > > > > > > > > > Thanks for the suggestion, but:
> > > > > > > > > >
> > > > > > > > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.10.99/br0,30000@192.168.10.100/xx:xx:xx:xx:xx:xx
> > > > > > > > > > ...
> > > > > > > > > > [ 5.289869] netpoll: netconsole: local port 6665
> > > > > > > > > > [ 5.289885] netpoll: netconsole: local IP 192.168.10.99
> > > > > > > > > > [ 5.289892] netpoll: netconsole: interface 'br0'
> > > > > > > > > > [ 5.289898] netpoll: netconsole: remote port 30000
> > > > > > > > > > [ 5.289907] netpoll: netconsole: remote IP 192.168.10.100
> > > > > > > > > > [ 5.289914] netpoll: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
> > > > > > > > > > [ 5.289922] netpoll: netconsole: br0 doesn't exist, aborting
> > > > > > > > > > [ 5.289929] netconsole: cleaning up
> > > > > > > > > > ...
> > > > > > > > > > [ 9.392291] Bridge firewalling registered
> > > > > > > > > > [ 9.396805] device eth1 entered promiscuous mode
> > > > > > > > > > [ 9.418350] eth1: setting full-duplex.
> > > > > > > > > > [ 9.421268] br0: port 1(eth1) entered forwarding state
> > > > > > > > > > [ 9.423354] br0: port 1(eth1) entered forwarding state
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Is there a way to control or associate network device names prior to
> > > > > > > > > > udev renaming?
> > > > > > > > > >
> > > > > > > > > That looks like a systemd problem (or more specifically a boot dependency
> > > > > > > > > problem). You need to modify your netconsole unit/service file to start after
> > > > > > > > > all your networking is up. NetworkManager provides a dummy service file for
> > > > > > > > > this purpose, called networkmanager-wait-online.service
> > > > > > > >
> > > > > > > > Ok. So with a single physical network interface that will be bridged,
> > > > > > > > netconsole cannot used for kernel boot messages.
> > > > > > > >
> > > > > > > > With a machine with multiple nics, is there a way to control device
> > > > > > > > naming so that the interface name to be used by netconsole specified on
> > > > > > > > the boot command line will actually corresponding to the intended
> > > > > > > > device. For example,
> > > > > > > >
> > > > > > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.1.123/eth0,30000@192.168.1.139/xx:xx:xx:xx:xx:xx
> > > > > > > > ....
> > > > > > > > [ 4.092184] 3c59x: Donald Becker and others.
> > > > > > > > [ 4.092204] 0000:07:05.0: 3Com PCI 3c905C Tornado at ffffc9000186cf80.
> > > > > > > > [ 4.094035] tg3.c:v3.125 (September 26, 2012)
> > > > > > > > ....
> > > > > > > > [ 4.125038] tg3 0000:08:00.0 eth1: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
> > > > > > > > [ 4.125055] tg3 0000:08:00.0 eth1: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> > > > > > > > [ 4.125062] tg3 0000:08:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> > > > > > > > [ 4.125068] tg3 0000:08:00.0 eth1: dma_rwctrl[76180000] dma_mask[64-bit]
> > > > > > > >
> > > > > > > > This is attaching netconsole to the wrong device because bus
> > > > > > > > enumeration, and therefore load order, is not consistent from boot to
> > > > > > > > boot.
> > > > > > > >
> > > > > > > No, theres no way to do that. As you note device ennumeration isn't consistent
> > > > > > > accross boots, thats why udev creates rules to rename devices based on immutable
> > > > > > > (or semi-immutable) data, like mac addresses, or pci bus locations). Once that
> > > > > > > happens, you'll have consistent names for your interfaces, and that work will be
> > > > > > > guaranteed to be done after networkmanager has finished opening all the
> > > > > > > interfaces that it needs (hence my suggestion to make netconsole service
> > > > > > > dependent on networkmanager service startup completing).
> > > > > >
> > > > > > Just wondering if you think something like the patch below is
> > > > > > suitable/acceptable for insulating netconsole from inconsistent device
> > > > > > name scenarios without changing the existing semantics. The basic idea
> > > > > > is to allow an ethernet MAC address in the <dev> field of the
> > > > > > netconsole= options, and if a MAC address was specified rather than a
> > > > > > device name, to do the dev lookup from the MAC address instead.
> > > > > >
> > > > > > This doesn't extend to, but also doesn't interfere with, the dynamic
> > > > > > config of netconsole via configfs.
> > > > > >
> > > > > > Would you mind reviewing it?
> > > > > >
> > > > > > Regards,
> > > > > > Peter
> > > > > >
> > > > > This looks like a pretty good idea to me. That said, something occured to me
> > > > > when you wrote your summary above. Have you looked at the netconsole service
> > > > > scripts that most distros provide in their packaging? I'm almost positive Red
> > > > > Hat/Fedora (and also like Suse and Ubuntu), already implement this functionality
> > > > > from user space. Basically, instead of people just modprobing netconsole, they
> > > > > create a service script that parses a config file that has contains all the
> > > > > options needed to load the netconsole module, and it has the intellegence to see
> > > > > if you specified a mac address rather than a device. If you did that it finds
> > > > > the corresponding device mac address and uses that as the device. I'm sorry, I
> > > > > don't know why I didn't think of that before. Check that out though, that will
> > > > > likey give you exactly what you need
> > > >
> > > > Even with a udev rule to load netconsole that runs immediately after
> > > > device renaming (so before scripting), most of the dynamic module
> > > > loading has already happened so netconsole misses it. At least with the
> > > > patch, netconsole will load and attach to the proper interface much
> > > > earlier in the boot so that module-load-time messages will be caught.
> > > >
> > > I'm not sure what you mean by this.
> >
> > This is the beginning of my netconsole log if I use userspace scripts to
> > start it.
> >
> > [ 19.125314] ip_tables: (C) 2000-2006 Netfilter Core Team
> > [ 20.060925] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> > [ 21.829331] ip6_tables: (C) 2000-2006 Netfilter Core Team
> > [ 25.728370] at-spi-registry[1862]: segfault at 18 ip 00007f6dd1dd45f1 sp 00007fff49bcd760 error 4 in libgconf-2.so.4.1.5[7f6dd1dbd000+2d000]
> > [ 26.778848] EXT4-fs (dm-3): re-mounted. Opts: errors=remount-ro,commit=0
> > [ 30.643469] Bluetooth: RFCOMM TTY layer initialized
> > [ 30.643509] Bluetooth: RFCOMM socket layer initialized
> > [ 30.643512] Bluetooth: RFCOMM ver 1.11
> > [ 30.784550] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> > [ 30.784567] Bluetooth: BNEP filters: protocol multicast
> > [ 30.784584] Bluetooth: BNEP socket layer initialized
> > [ 34.010813] init: plymouth-stop pre-start process (2205) terminated with status 1
> >
> > This is the beginning of my netconsole log if I am able to specify
> > netconsole= options on the boot command line. Netconsole starts logging
> > much earlier because it is much loaded earlier.
> >
> > [ 8.764336] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null)
> > [ 9.409379] firewire_core 0000:07:06.0: created device fw1: GUID 0800460301c2d69e, S400
> > [ 9.567395] init: ureadahead main process (500) terminated with status 5
> > [ 10.400338] Adding 10996456k swap on /dev/mapper/isw_cbdbfhdjad_Raid0p5. Priority:-1 extents:1 across:10996456k
> > [ 10.496974] udevd[541]: starting version 173
> > [ 10.725906] EXT4-fs (dm-4): re-mounted. Opts: errors=remount-ro
> > [ 11.288352] lp: driver loaded but no devices found
> > [ 12.240058] parport_pc 00:05: reported by Plug and Play ACPI
> > [ 12.240145] parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
> > [ 12.336161] lp0: using parport0 (interrupt-driven).
> > [ 12.342867] microcode: CPU0 sig=0x10676, pf=0x40, revision=0x60f
> > [ 12.436657] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
> > [ 12.442245] ppdev: user-space parallel port driver
> > [ 12.451592] net firewire0: IPv4 over IEEE 1394 on card 0000:07:06.0
> >
> > Does that make more sense now?
> >
> No, actually, what exactly are you trying to show me here? I don't see any
> indication of netconsole doing anything in either of these log snippets.
^^^^^^^^^^^^^^^^^^^^^^
except that it was netconsole that wrote these logs
Note the log times.
In the first log, which is from a netconsole loaded by userspace
scripts, the first printk it logs isn't until 19.125314 secs into boot.
Most kernel + module init has already happened by this time.
In the second log, which is from a netconsole (still built as a module)
loaded as a result of using the boot command line. It starts logging at
8.764336 secs into boot -- almost 10 secs earlier than using userspace
scripting to load netconsole.
> I'm
> also not sure why you're specifying netconsole options on the kernel command
> line at all.
> Can you elaborate?
Specifying netconsole= on the boot command line loads the netconsole
module at the earliest possible time (and much earlier than scripting
will do). And also leaves it as an optional configuration (at least for
me it does since I use grub2 and can edit the boot command line before
booting).
AFAIK, there are 5 ways to load netconsole:
1. On the boot command line with netconsole=
If netconsole is built-in, this is the only way to initialize it.
If netconsole is a module, this forces netconsole to load at the
earliest possible time.
2. Via /etc/modules
This happens before network device renaming, so suffers from the
problems we've been discussing.
3. Via a custom udev rule in /etc/udev/rules.d/
Earliest userspace method to modprobe netconsole and can be used
after device renaming, but is still fairly late in the boot process.
4. Via init/service scripting
5. At the user shell
AFAIK, there are 4 ways to specify the necessary options to netconsole:
a. On the boot command line with netconsole=
Also loads netconsole
b. In a .conf file in /etc/modprobe.d
c. On the modprobe command line
d. Via configfs
Regards,
Peter
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Ani Sinha @ 2012-12-13 22:07 UTC (permalink / raw)
To: Daniel Borkmann
Cc: Michael Richardson, netdev, tcpdump-workers, Francesco Ruggeri
In-Reply-To: <CAD6jFUTht82HOjGjDU7hFCEWyE3TOx_W4_j=SZK-DrcGfrio-A@mail.gmail.com>
On Thu, Dec 13, 2012 at 1:49 PM, Daniel Borkmann
<danborkmann@iogearbox.net> wrote:
> Well, not everyone on netdev might be following this thread (resp.
> following fully). The best way to get responses for a patch is to go
> through the normal patch submission process on netdev, and if you like
> to request for comments, then mark it as RFC in the subject. This way,
> people will know and likely comment on it if it makes sense or not.
OK good to know.
> As Eric mentioned earlier, for now there seems not to be a reliable
> way to get to know which ops are present and which not. It's not
> really nice, but if you want to make use of those new (ANC*) features,
> probably checking kernel version might be the only way if I'm not
> missing something. Now net-next is closed, but if it reopens, I'll
> submit a version 2 of my patch where you've been CC'd to. If it gets
> in, then at least it's for sure that since kernel <xyz> this kind of
> feature test is present.
thanks, yes, I believe we do need some sort of validation on the
ancilliary features.
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Stephen Hemminger @ 2012-12-13 22:02 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: David Miller, vyasevic, or.gerlitz, netdev, mst, john.r.fastabend
In-Reply-To: <50CA37DA.1090905@mojatatu.com>
On Thu, 13 Dec 2012 15:17:30 -0500
Jamal Hadi Salim <jhs@mojatatu.com> wrote:
> On 12-12-13 02:04 PM, Stephen Hemminger wrote:
> >
> > Maybe a better filtering architecture (at the bridge level) would
> > be a good project.
> >
>
> Ok, please before you go off and re-invent the winter tire - take a look
> at tc filtering which works well with any netdev and point out what the
> issues are.
>
>
> cheers,
> jamal
Nah, no reinvention, people who want to do filtering and bridging
just use openvswitch instead.
^ permalink raw reply
* Re: [GIT] Networking
From: Olof Johansson @ 2012-12-13 21:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, Andrew Morton, Network Development,
Linux Kernel Mailing List, Arnd Bergmann, linux-arm-kernel,
Tony Lindgren
In-Reply-To: <CA+55aFwzUgxQAze=mYbEx8b61V542tzm06Df=mR1BtYVbJy0mg@mail.gmail.com>
On Thu, Dec 13, 2012 at 3:15 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Wed, Dec 12, 2012 at 12:11 PM, David Miller <davem@davemloft.net> wrote:
>>
>> There is one merge conflict to resolve in net/sched/cls_cgroup.c,
>> one commit changes the name of some members to "css_*" (this came
>> from Tejun's tree) and another commit adds an "attach" method.
>
> There's more than that. The ARM board mess is apparently now affecting
> the networking merges too.
>
> I fixed it up. Hopefully correctly.
Yes, it looks correct. Sorry about missing that earlier, sfr had
spotted it when it showed up in linux-next but I lost track of it.
We probably need to restructure/resort the device tree files to avoid
add/add conflicts when people just append to them all the time. I
really hope things will start to settle down churn-wise soon, as
conversions and DT enablement starts to be more complete.
(I also think we need to improve the way we handle our topics some, we
have a bit too much internal conflicts between topics in arm-soc
still, but that's a separate subject).
-Olof
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Daniel Borkmann @ 2012-12-13 21:49 UTC (permalink / raw)
To: Ani Sinha; +Cc: Michael Richardson, netdev, tcpdump-workers, Francesco Ruggeri
In-Reply-To: <CAOxq_8PuMF2n80g30aXbPFQyo6UfsypZOHREjB36dnnp87nv=A@mail.gmail.com>
On Thu, Dec 13, 2012 at 6:34 PM, Ani Sinha <ani@aristanetworks.com> wrote:
> On Thu, Dec 13, 2012 at 12:35 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 12/12/2012 10:53 PM, Ani Sinha wrote:
>>>>
>>>> unsigned int netdev_8021q_inskb = 1;
>>>>
>>>> ...
>>>> {
>>>> .ctl_name = NET_CORE_8021q_INSKB,
>>>> .procname = "netdev_8021q_inskb",
>>>> .data = &netdev_8021q_inskb,
>>>> .maxlen = sizeof(int),
>>>> .mode = 0444,
>>>> .proc_handler = proc_dointvec
>>>> },
>>>>
>>>> would seem to do it to me.
>>>> Then pcap can fopen("/proc/sys/net/core/netdev_8021q_inskb") and if it
>>>> finds it, and it is >0, then do the cmsg thing.
>>>>
>>
>> I think it doesn't. Because then you are obviously considering adding one
>> procfs file into /proc/sys/net/core/ *for each* feature that is added into
>> the ancillary ops which cannot be the right way ...
>
> We had already brought up this topic previously in the same thread. A
> suggestion was made to add that proc entry and no one from netdev
> responded to it saying that it did not make any sense. Therefore
> before I went ahead and made the fixes in libpcap, I wanted to run
> this by your guys again to make sure we are still on the same page.
Well, not everyone on netdev might be following this thread (resp.
following fully). The best way to get responses for a patch is to go
through the normal patch submission process on netdev, and if you like
to request for comments, then mark it as RFC in the subject. This way,
people will know and likely comment on it if it makes sense or not.
> I do agree that instead of a /proc entry, we should check for a kenrel
> version >= X where X is the upstream version that first started
> supporting all the features needed by libpcap for vlan filtering. This
> is not a compile time check but a run time one. Does anyone see any
> issues with this? Is there any long term implications of this, like if
> you backport patches to an older long term supported kernel? Are there
> other better ways to do this, like may be returning feature bits from
> an ioctl call? This is something we need to deal with on a continuous
> basis as we keep supporting newer AUX fields and libpcap and other
> user land code needs to make use of it. At the same time, they need to
> handle backward compatibility issues with older kernels.
As Eric mentioned earlier, for now there seems not to be a reliable
way to get to know which ops are present and which not. It's not
really nice, but if you want to make use of those new (ANC*) features,
probably checking kernel version might be the only way if I'm not
missing something. Now net-next is closed, but if it reopens, I'll
submit a version 2 of my patch where you've been CC'd to. If it gets
in, then at least it's for sure that since kernel <xyz> this kind of
feature test is present.
^ permalink raw reply
* [PATCH] Fix: kmemleak in tcp_v4/6_syn_recv_sock and dccp_v4/6_request_recv_sock
From: Christoph Paasch @ 2012-12-13 21:49 UTC (permalink / raw)
To: David Miller
Cc: Gerrit Renker, Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
Patrick McHardy, netdev, dccp
If in either of the above functions inet_csk_route_child_sock() or
__inet_inherit_port() fails, the newsk will not be freed:
unreferenced object 0xffff88022e8a92c0 (size 1592):
comm "softirq", pid 0, jiffies 4294946244 (age 726.160s)
hex dump (first 32 bytes):
0a 01 01 01 0a 01 01 02 00 00 00 00 a7 cc 16 00 ................
02 00 03 01 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff8153d190>] kmemleak_alloc+0x21/0x3e
[<ffffffff810ab3e7>] kmem_cache_alloc+0xb5/0xc5
[<ffffffff8149b65b>] sk_prot_alloc.isra.53+0x2b/0xcd
[<ffffffff8149b784>] sk_clone_lock+0x16/0x21e
[<ffffffff814d711a>] inet_csk_clone_lock+0x10/0x7b
[<ffffffff814ebbc3>] tcp_create_openreq_child+0x21/0x481
[<ffffffff814e8fa5>] tcp_v4_syn_recv_sock+0x3a/0x23b
[<ffffffff814ec5ba>] tcp_check_req+0x29f/0x416
[<ffffffff814e8e10>] tcp_v4_do_rcv+0x161/0x2bc
[<ffffffff814eb917>] tcp_v4_rcv+0x6c9/0x701
[<ffffffff814cea9f>] ip_local_deliver_finish+0x70/0xc4
[<ffffffff814cec20>] ip_local_deliver+0x4e/0x7f
[<ffffffff814ce9f8>] ip_rcv_finish+0x1fc/0x233
[<ffffffff814cee68>] ip_rcv+0x217/0x267
[<ffffffff814a7bbe>] __netif_receive_skb+0x49e/0x553
[<ffffffff814a7cc3>] netif_receive_skb+0x50/0x82
This happens, because sk_clone_lock initializes sk_refcnt to 2, and thus
a single sock_put() is not enough to free the memory. Additionally, things
like xfrm, memcg, cookie_values,... may have been initialized.
We have to free them properly.
This is fixed by forcing a call to tcp_done(), ending up in
inet_csk_destroy_sock, doing the final sock_put(). tcp_done() is necessary,
because it ends up doing all the cleanup on xfrm, memcg, cookie_values,
xfrm,...
Before calling tcp_done, we have to set the socket to SOCK_DEAD, to
force it entering inet_csk_destroy_sock. To avoid the warning in
inet_csk_destroy_sock, inet_num has to be set to 0.
As inet_csk_destroy_sock does a dec on orphan_count, we first have to
increase it.
Calling tcp_done() allows us to remove the calls to
tcp_clear_xmit_timer() and tcp_cleanup_congestion_control().
A similar approach is taken for dccp by calling dccp_done().
This probably should be backported to kernels >= 3.0 as it is in the
kernel since 0e734419923bd (ipv4: Use inet_csk_route_child_sock() in
DCCP and TCP.).
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
include/net/inet_connection_sock.h | 1 +
net/dccp/ipv4.c | 4 ++--
net/dccp/ipv6.c | 3 ++-
net/ipv4/inet_connection_sock.c | 16 ++++++++++++++++
net/ipv4/tcp_ipv4.c | 6 ++----
net/ipv6/tcp_ipv6.c | 3 ++-
6 files changed, 25 insertions(+), 8 deletions(-)
diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
index ba1d361..1832927 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -318,6 +318,7 @@ extern void inet_csk_reqsk_queue_prune(struct sock *parent,
const unsigned long max_rto);
extern void inet_csk_destroy_sock(struct sock *sk);
+extern void inet_csk_prepare_forced_close(struct sock *sk);
/*
* LISTEN is a special case for poll..
diff --git a/net/dccp/ipv4.c b/net/dccp/ipv4.c
index 176ecdb..4f9f5eb 100644
--- a/net/dccp/ipv4.c
+++ b/net/dccp/ipv4.c
@@ -439,8 +439,8 @@ exit:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
return NULL;
put_and_exit:
- bh_unlock_sock(newsk);
- sock_put(newsk);
+ inet_csk_prepare_forced_close(newsk);
+ dccp_done(newsk);
goto exit;
}
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c
index 56840b2..6e05981 100644
--- a/net/dccp/ipv6.c
+++ b/net/dccp/ipv6.c
@@ -585,7 +585,8 @@ static struct sock *dccp_v6_request_recv_sock(struct sock *sk,
newinet->inet_rcv_saddr = LOOPBACK4_IPV6;
if (__inet_inherit_port(sk, newsk) < 0) {
- sock_put(newsk);
+ inet_csk_prepare_forced_close(newsk);
+ dccp_done(newsk);
goto out;
}
__inet6_hash(newsk, NULL);
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 2026542..d0670f0 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -710,6 +710,22 @@ void inet_csk_destroy_sock(struct sock *sk)
}
EXPORT_SYMBOL(inet_csk_destroy_sock);
+/* This function allows to force a closure of a socket after the call to
+ * tcp/dccp_create_openreq_child().
+ */
+void inet_csk_prepare_forced_close(struct sock *sk)
+{
+ /* sk_clone_lock locked the socket and set refcnt to 2 */
+ bh_unlock_sock(sk);
+ sock_put(sk);
+
+ /* The below has to be done to allow calling inet_csk_destroy_sock */
+ sock_set_flag(sk, SOCK_DEAD);
+ percpu_counter_inc(sk->sk_prot->orphan_count);
+ inet_sk(sk)->inet_num = 0;
+}
+EXPORT_SYMBOL(inet_csk_prepare_forced_close);
+
int inet_csk_listen_start(struct sock *sk, const int nr_table_entries)
{
struct inet_sock *inet = inet_sk(sk);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 1ed2307..54139fa 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1767,10 +1767,8 @@ exit:
NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENDROPS);
return NULL;
put_and_exit:
- tcp_clear_xmit_timers(newsk);
- tcp_cleanup_congestion_control(newsk);
- bh_unlock_sock(newsk);
- sock_put(newsk);
+ inet_csk_prepare_forced_close(newsk);
+ tcp_done(newsk);
goto exit;
}
EXPORT_SYMBOL(tcp_v4_syn_recv_sock);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 6565cf5..93825dd 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1288,7 +1288,8 @@ static struct sock * tcp_v6_syn_recv_sock(struct sock *sk, struct sk_buff *skb,
#endif
if (__inet_inherit_port(sk, newsk) < 0) {
- sock_put(newsk);
+ inet_csk_prepare_forced_close(newsk);
+ tcp_done(newsk);
goto out;
}
__inet6_hash(newsk, NULL);
--
1.7.10.4
^ permalink raw reply related
* cpts: Fix build error caused by include of plat/clock.h
From: Tony Lindgren @ 2012-12-13 21:36 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-arm-kernel, linux-omap, netdev, Richard Cochran
Commit 87c0e764 (cpts: introduce time stamping code and a PTP hardware clock)
mistakenly included plat/clock.h that should not be included by drivers
even if it exists.
Otherwise we get the following error with at least omap2plus_defconfig:
drivers/net/ethernet/ti/cpts.c:30:24: error: plat/clock.h: No such file or directory
Signed-off-by: Tony Lindgren <tony@atomide.com
--- a/drivers/net/ethernet/ti/cpts.c
+++ b/drivers/net/ethernet/ti/cpts.c
@@ -27,8 +27,6 @@
#include <linux/uaccess.h>
#include <linux/workqueue.h>
-#include <plat/clock.h>
-
#include "cpts.h"
#ifdef CONFIG_TI_CPTS
^ permalink raw reply
* Re: [patch net-next 0/4] net: allow to change carrier from userspace
From: Jiri Pirko @ 2012-12-13 21:32 UTC (permalink / raw)
To: John Fastabend
Cc: Dan Williams, Stephen Hemminger, Flavio Leitner, John Fastabend,
netdev, davem, edumazet, bhutchings, mirqus, greearb
In-Reply-To: <50CA27CF.7010301@intel.com>
Thu, Dec 13, 2012 at 08:09:03PM CET, john.r.fastabend@intel.com wrote:
>On 12/13/2012 10:33 AM, Dan Williams wrote:
>>On Thu, 2012-12-13 at 10:20 -0800, Stephen Hemminger wrote:
>>>On Thu, 13 Dec 2012 16:17:33 -0200
>>>Flavio Leitner <fbl@redhat.com> wrote:
>>>
>>>>On Thu, 13 Dec 2012 10:09:33 -0800
>>>>Stephen Hemminger <shemminger@vyatta.com> wrote:
>>>>
>>>>>On Thu, 13 Dec 2012 15:54:23 -0200
>>>>>Flavio Leitner <fbl@redhat.com> wrote:
>>>>>
>>>>>>I am saying this because people are used to and there are scripts out
>>>>>>there using something like:
>>>>>># ethtool <iface> | grep 'Link'
>>>>>>to react an interface failure.
>>>>>
>>>>>Then the script is broken. It is asking about hardware state.
>>>>
>>>>I was talking about the team master interface, so it makes sense
>>>>to check its 'hardware' state. Just think on 'bond0' interface
>>>>with no slaves. It should report Link detected: no.
>>>>
>>>>See bond_release(), what happens if bond->slave_cnt == 0, for instance.
>>>>
>>>
>>>I was thinking more that ethtool operation for reporting link on
>>>the team device should use the proper check rather than just using netif_carrier_ok(),
>>>the team ethtool operation for get_link should be check IFF_RUNNING flag
>>>in dev->flags which is controlled by operstate transistions.
>>
>>That's not entirely sufficient, because not everything uses ethtool to
>>deterine whether the link/carrier is active. eg, anything listenting to
>>netlink for IFF_RUNNING won't know anything about this. I may have
>>missed previous conversation, but IFF_RUNNING is AFAIK the sole
>>mechanism to indicate to userspace that the link is operational and
>>ready for general traffic. Can the team drivers simply not set
>>IFF_RUNNING until the interface is actually ready for general traffic?
>>
>>I'd just caution people to be careful when it comes to carrier/link
>>states, as a lot of stuff relies on it, and people keep trying to
>>slightly change the meaning of it. We need it to be consistent across
>>net interfaces and driver implementations, not have specific meanings to
>>certain drivers that don't apply to others.
>>
>>If teamd needs to manage the carrier state of the teamX interface,
>>perhaps instead of munging the actual carrier state itself, it can flip
>>some team-private value that is one component of determining whether
>>IFF_RUNNING gets set or not?
>>
>>Dan
>
>Assuming the operstate documentation is correct IFF_RUNNING should only
>be set if the operstate is up or unknown. Quoting the text again,
>
> 32 ifinfomsg::if_flags & IFF_RUNNING:
> 33 Interface is in RFC2863 operational state UP or UNKNOWN. This is for
> 34 backward compatibility, routing daemons, dhcp clients can use this
> 35 flag to determine whether they should use the interface.
>
>So my guess is having a team ethtool get_link handler AND managing the
>operstate from teamd would satisfy the requirement. But maybe I missed
>something.
Yes, I've been thinking about the same thing. I'll check that.
>
>.John
^ permalink raw reply
* Re: netconsole fun
From: Neil Horman @ 2012-12-13 21:17 UTC (permalink / raw)
To: Peter Hurley; +Cc: Cong Wang, netdev
In-Reply-To: <1355426821.2612.16.camel@thor>
On Thu, Dec 13, 2012 at 02:27:01PM -0500, Peter Hurley wrote:
> On Thu, 2012-12-13 at 13:08 -0500, Neil Horman wrote:
> > On Thu, Dec 13, 2012 at 09:49:31AM -0500, Peter Hurley wrote:
> > > On Thu, 2012-12-13 at 07:36 -0500, Neil Horman wrote:
> > > > On Wed, Dec 12, 2012 at 03:59:17PM -0500, Peter Hurley wrote:
> > > > > On Tue, 2012-12-11 at 11:45 -0500, Neil Horman wrote:
> > > > > > On Tue, Dec 11, 2012 at 10:16:51AM -0500, Peter Hurley wrote:
> > > > > > > On Tue, 2012-12-11 at 09:30 -0500, Neil Horman wrote:
> > > > > > > > On Tue, Dec 11, 2012 at 09:19:52AM -0500, Peter Hurley wrote:
> > > > > > > > > On Tue, 2012-12-11 at 04:51 +0000, Cong Wang wrote:
> > > > > > > > > > On Mon, 10 Dec 2012 at 14:17 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
> > > > > > > > > > > Now that netpoll has been disabled for slaved devices, is there a
> > > > > > > > > > > recommended method of running netconsole on a machine that has a slaved
> > > > > > > > > > > device?
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Yes, running it on the master device instead.
> > > > > > > > >
> > > > > > > > > Thanks for the suggestion, but:
> > > > > > > > >
> > > > > > > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.10.99/br0,30000@192.168.10.100/xx:xx:xx:xx:xx:xx
> > > > > > > > > ...
> > > > > > > > > [ 5.289869] netpoll: netconsole: local port 6665
> > > > > > > > > [ 5.289885] netpoll: netconsole: local IP 192.168.10.99
> > > > > > > > > [ 5.289892] netpoll: netconsole: interface 'br0'
> > > > > > > > > [ 5.289898] netpoll: netconsole: remote port 30000
> > > > > > > > > [ 5.289907] netpoll: netconsole: remote IP 192.168.10.100
> > > > > > > > > [ 5.289914] netpoll: netconsole: remote ethernet address xx:xx:xx:xx:xx:xx
> > > > > > > > > [ 5.289922] netpoll: netconsole: br0 doesn't exist, aborting
> > > > > > > > > [ 5.289929] netconsole: cleaning up
> > > > > > > > > ...
> > > > > > > > > [ 9.392291] Bridge firewalling registered
> > > > > > > > > [ 9.396805] device eth1 entered promiscuous mode
> > > > > > > > > [ 9.418350] eth1: setting full-duplex.
> > > > > > > > > [ 9.421268] br0: port 1(eth1) entered forwarding state
> > > > > > > > > [ 9.423354] br0: port 1(eth1) entered forwarding state
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Is there a way to control or associate network device names prior to
> > > > > > > > > udev renaming?
> > > > > > > > >
> > > > > > > > That looks like a systemd problem (or more specifically a boot dependency
> > > > > > > > problem). You need to modify your netconsole unit/service file to start after
> > > > > > > > all your networking is up. NetworkManager provides a dummy service file for
> > > > > > > > this purpose, called networkmanager-wait-online.service
> > > > > > >
> > > > > > > Ok. So with a single physical network interface that will be bridged,
> > > > > > > netconsole cannot used for kernel boot messages.
> > > > > > >
> > > > > > > With a machine with multiple nics, is there a way to control device
> > > > > > > naming so that the interface name to be used by netconsole specified on
> > > > > > > the boot command line will actually corresponding to the intended
> > > > > > > device. For example,
> > > > > > >
> > > > > > > [ 0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.7.0-rc8-xeon ...... netconsole=@192.168.1.123/eth0,30000@192.168.1.139/xx:xx:xx:xx:xx:xx
> > > > > > > ....
> > > > > > > [ 4.092184] 3c59x: Donald Becker and others.
> > > > > > > [ 4.092204] 0000:07:05.0: 3Com PCI 3c905C Tornado at ffffc9000186cf80.
> > > > > > > [ 4.094035] tg3.c:v3.125 (September 26, 2012)
> > > > > > > ....
> > > > > > > [ 4.125038] tg3 0000:08:00.0 eth1: Tigon3 [partno(BCM95754) rev b002] (PCI Express) MAC address xx:xx:xx:xx:xx:xx
> > > > > > > [ 4.125055] tg3 0000:08:00.0 eth1: attached PHY is 5787 (10/100/1000Base-T Ethernet) (WireSpeed[1], EEE[0])
> > > > > > > [ 4.125062] tg3 0000:08:00.0 eth1: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
> > > > > > > [ 4.125068] tg3 0000:08:00.0 eth1: dma_rwctrl[76180000] dma_mask[64-bit]
> > > > > > >
> > > > > > > This is attaching netconsole to the wrong device because bus
> > > > > > > enumeration, and therefore load order, is not consistent from boot to
> > > > > > > boot.
> > > > > > >
> > > > > > No, theres no way to do that. As you note device ennumeration isn't consistent
> > > > > > accross boots, thats why udev creates rules to rename devices based on immutable
> > > > > > (or semi-immutable) data, like mac addresses, or pci bus locations). Once that
> > > > > > happens, you'll have consistent names for your interfaces, and that work will be
> > > > > > guaranteed to be done after networkmanager has finished opening all the
> > > > > > interfaces that it needs (hence my suggestion to make netconsole service
> > > > > > dependent on networkmanager service startup completing).
> > > > >
> > > > > Just wondering if you think something like the patch below is
> > > > > suitable/acceptable for insulating netconsole from inconsistent device
> > > > > name scenarios without changing the existing semantics. The basic idea
> > > > > is to allow an ethernet MAC address in the <dev> field of the
> > > > > netconsole= options, and if a MAC address was specified rather than a
> > > > > device name, to do the dev lookup from the MAC address instead.
> > > > >
> > > > > This doesn't extend to, but also doesn't interfere with, the dynamic
> > > > > config of netconsole via configfs.
> > > > >
> > > > > Would you mind reviewing it?
> > > > >
> > > > > Regards,
> > > > > Peter
> > > > >
> > > > This looks like a pretty good idea to me. That said, something occured to me
> > > > when you wrote your summary above. Have you looked at the netconsole service
> > > > scripts that most distros provide in their packaging? I'm almost positive Red
> > > > Hat/Fedora (and also like Suse and Ubuntu), already implement this functionality
> > > > from user space. Basically, instead of people just modprobing netconsole, they
> > > > create a service script that parses a config file that has contains all the
> > > > options needed to load the netconsole module, and it has the intellegence to see
> > > > if you specified a mac address rather than a device. If you did that it finds
> > > > the corresponding device mac address and uses that as the device. I'm sorry, I
> > > > don't know why I didn't think of that before. Check that out though, that will
> > > > likey give you exactly what you need
> > >
> > > Even with a udev rule to load netconsole that runs immediately after
> > > device renaming (so before scripting), most of the dynamic module
> > > loading has already happened so netconsole misses it. At least with the
> > > patch, netconsole will load and attach to the proper interface much
> > > earlier in the boot so that module-load-time messages will be caught.
> > >
> > I'm not sure what you mean by this.
>
> This is the beginning of my netconsole log if I use userspace scripts to
> start it.
>
> [ 19.125314] ip_tables: (C) 2000-2006 Netfilter Core Team
> [ 20.060925] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
> [ 21.829331] ip6_tables: (C) 2000-2006 Netfilter Core Team
> [ 25.728370] at-spi-registry[1862]: segfault at 18 ip 00007f6dd1dd45f1 sp 00007fff49bcd760 error 4 in libgconf-2.so.4.1.5[7f6dd1dbd000+2d000]
> [ 26.778848] EXT4-fs (dm-3): re-mounted. Opts: errors=remount-ro,commit=0
> [ 30.643469] Bluetooth: RFCOMM TTY layer initialized
> [ 30.643509] Bluetooth: RFCOMM socket layer initialized
> [ 30.643512] Bluetooth: RFCOMM ver 1.11
> [ 30.784550] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
> [ 30.784567] Bluetooth: BNEP filters: protocol multicast
> [ 30.784584] Bluetooth: BNEP socket layer initialized
> [ 34.010813] init: plymouth-stop pre-start process (2205) terminated with status 1
>
> This is the beginning of my netconsole log if I am able to specify
> netconsole= options on the boot command line. Netconsole starts logging
> much earlier because it is much loaded earlier.
>
> [ 8.764336] EXT4-fs (dm-4): mounted filesystem with ordered data mode. Opts: (null)
> [ 9.409379] firewire_core 0000:07:06.0: created device fw1: GUID 0800460301c2d69e, S400
> [ 9.567395] init: ureadahead main process (500) terminated with status 5
> [ 10.400338] Adding 10996456k swap on /dev/mapper/isw_cbdbfhdjad_Raid0p5. Priority:-1 extents:1 across:10996456k
> [ 10.496974] udevd[541]: starting version 173
> [ 10.725906] EXT4-fs (dm-4): re-mounted. Opts: errors=remount-ro
> [ 11.288352] lp: driver loaded but no devices found
> [ 12.240058] parport_pc 00:05: reported by Plug and Play ACPI
> [ 12.240145] parport0: PC-style at 0x378 (0x778), irq 7, using FIFO [PCSPP,TRISTATE,COMPAT,ECP]
> [ 12.336161] lp0: using parport0 (interrupt-driven).
> [ 12.342867] microcode: CPU0 sig=0x10676, pf=0x40, revision=0x60f
> [ 12.436657] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
> [ 12.442245] ppdev: user-space parallel port driver
> [ 12.451592] net firewire0: IPv4 over IEEE 1394 on card 0000:07:06.0
>
> Does that make more sense now?
>
No, actually, what exactly are you trying to show me here? I don't see any
indication of netconsole doing anything in either of these log snippets. I'm
also not sure why you're specifying netconsole options on the kernel command
line at all.
Can you elaborate?
Neil
> Thanks again,
> Peter
>
> > > There is an unforeseen consequence of the patch: it breaks device
> > > renaming because the device will already be in use by netconsole. Which
> > > is the whole problem with userspace device renaming to begin with...
> > >
> > That is bad, but see above, the netconsole service can work around this for you,
> > allowing you to never have to specify a particular device at all.
>
> Just to be clear here,
>
>
>
>
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: David Miller @ 2012-12-13 20:28 UTC (permalink / raw)
To: vyasevic; +Cc: netdev, shemminger, mst, john.r.fastabend
In-Reply-To: <1355342477-4971-1-git-send-email-vyasevic@redhat.com>
From: Vlad Yasevich <vyasevic@redhat.com>
Date: Wed, 12 Dec 2012 15:01:06 -0500
> This series of patches provides an ability to add VLANs to the bridge
> ports. This is similar to what can be found in most switches. The bridge
> port may have any number of VLANs added to it including vlan 0 priority tagged
> traffic. When vlans are added to the port, only traffic tagged with particular
> vlan will forwarded over this port. Additionally, vlan ids are added to FDB
> entries and become part of the lookup. This way we correctly identify the FDB
> entry.
>
> A single vlan may also be designated as untagged. Any untagged traffic
> recieved by the port will be assigned to this vlan. Any traffic exiting
> the port with a VID matching the untagged vlan will exit untagged (the
> bridge will strip the vlan header). This is similar to "Native Vlan" support
> available in most switches.
>
> The default behavior ofthe bridge is unchanged if no vlans have been
> configured.
FWIW I've reviewed these changes and I like them a lot.
They resolve a real ambiguity, and using ebtables as a reason these
changes should not be applied amounts to a scarecrow.
^ permalink raw reply
* Re: [PATCH 00/11] Add basic VLAN support to bridges
From: Jamal Hadi Salim @ 2012-12-13 20:17 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David Miller, vyasevic, or.gerlitz, netdev, mst, john.r.fastabend
In-Reply-To: <20121213110404.6d662baa@nehalam.linuxnetplumber.net>
On 12-12-13 02:04 PM, Stephen Hemminger wrote:
>
> Maybe a better filtering architecture (at the bridge level) would
> be a good project.
>
Ok, please before you go off and re-invent the winter tire - take a look
at tc filtering which works well with any netdev and point out what the
issues are.
cheers,
jamal
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-12-13 20:08 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
A pile of fixes in response to yesterday's big merge. The SCTP
HMAC thing hasn't been addressed yet, I'll take care of that
myself if Neil and Vlad don't show signs of life by tomorrow.
1) Use after free of SKB in tuntap code. Fix by Eric Dumazet, reported
by Dave Jones.
2) NFC LLCP code emits annoying kernel log message, triggerable
by the user. From Dave Jones.
3) Fix several endianness bugs noticed by sparse in the bridging code,
from Stephen Hemminger.
4) Ipv6 NDISC code doesn't take padding into account properly, fix from
YOSHIFUJI Hideaki.
5) Add missing docs to ethtool_flow_ext struct, from Yan Burman.
Please pull, thanks.
The following changes since commit 6be35c700f742e911ecedd07fcc43d4439922334:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2012-12-12 18:07:07 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to eca2a43bb0d2c6ebd528be6acb30a88435abe307:
bridge: fix icmpv6 endian bug and other sparse warnings (2012-12-13 12:58:11 -0500)
----------------------------------------------------------------
Dave Jones (1):
nfc: remove noisy message from llcp_sock_sendmsg
Eric Dumazet (1):
tuntap: dont use skb after netif_rx_ni(skb)
YOSHIFUJI Hideaki / 吉藤英明 (1):
ndisc: Fix padding error in link-layer address option.
Yan Burman (1):
net: ethool: Document struct ethtool_flow_ext
stephen hemminger (1):
bridge: fix icmpv6 endian bug and other sparse warnings
drivers/net/tun.c | 7 ++++---
include/uapi/linux/ethtool.h | 16 ++++++++++++++--
net/bridge/br_multicast.c | 10 ++++++----
net/ipv6/ndisc.c | 2 +-
net/nfc/llcp/sock.c | 4 ----
5 files changed, 25 insertions(+), 14 deletions(-)
^ 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