* [patch net-next 2/5] team: add bool option type
From: Jiri Pirko @ 2012-04-10 15:15 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet
In-Reply-To: <1334070946-7704-1-git-send-email-jpirko@redhat.com>
Add another (hopefully last) option type. Use NLA_FLAG to implement
that.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/team/team.c | 40 +++++++++++++++++++++++++++++-----------
include/linux/if_team.h | 2 ++
2 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index eaf8441..2645fae 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -1463,6 +1463,16 @@ static int team_nl_fill_options_get(struct sk_buff *skb,
ctx.data.bin_val.len, ctx.data.bin_val.ptr))
goto nla_put_failure;
break;
+ case TEAM_OPTION_TYPE_BOOL:
+ if (nla_put_u8(skb, TEAM_ATTR_OPTION_TYPE, NLA_FLAG))
+ goto nla_put_failure;
+ err = team_option_get(team, opt_inst, &ctx);
+ if (err)
+ goto errout;
+ if (ctx.data.bool_val &&
+ nla_put_flag(skb, TEAM_ATTR_OPTION_DATA))
+ goto nla_put_failure;
+ break;
default:
BUG();
}
@@ -1524,6 +1534,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
nla_for_each_nested(nl_option, info->attrs[TEAM_ATTR_LIST_OPTION], i) {
struct nlattr *opt_attrs[TEAM_ATTR_OPTION_MAX + 1];
struct nlattr *attr_port_ifindex;
+ struct nlattr *attr_data;
enum team_option_type opt_type;
int opt_port_ifindex = 0; /* != 0 for per-port options */
struct team_option_inst *opt_inst;
@@ -1539,8 +1550,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
if (err)
goto team_put;
if (!opt_attrs[TEAM_ATTR_OPTION_NAME] ||
- !opt_attrs[TEAM_ATTR_OPTION_TYPE] ||
- !opt_attrs[TEAM_ATTR_OPTION_DATA]) {
+ !opt_attrs[TEAM_ATTR_OPTION_TYPE]) {
err = -EINVAL;
goto team_put;
}
@@ -1554,10 +1564,19 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
case NLA_BINARY:
opt_type = TEAM_OPTION_TYPE_BINARY;
break;
+ case NLA_FLAG:
+ opt_type = TEAM_OPTION_TYPE_BOOL;
+ break;
default:
goto team_put;
}
+ attr_data = opt_attrs[TEAM_ATTR_OPTION_DATA];
+ if (opt_type != TEAM_OPTION_TYPE_BOOL && !attr_data) {
+ err = -EINVAL;
+ goto team_put;
+ }
+
opt_name = nla_data(opt_attrs[TEAM_ATTR_OPTION_NAME]);
attr_port_ifindex = opt_attrs[TEAM_ATTR_OPTION_PORT_IFINDEX];
if (attr_port_ifindex)
@@ -1565,9 +1584,7 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
list_for_each_entry(opt_inst, &team->option_inst_list, list) {
struct team_option *option = opt_inst->option;
- struct nlattr *opt_data_attr;
struct team_gsetter_ctx ctx;
- int data_len;
int tmp_ifindex;
tmp_ifindex = opt_inst->port ?
@@ -1577,23 +1594,24 @@ static int team_nl_cmd_options_set(struct sk_buff *skb, struct genl_info *info)
tmp_ifindex != opt_port_ifindex)
continue;
opt_found = true;
- opt_data_attr = opt_attrs[TEAM_ATTR_OPTION_DATA];
- data_len = nla_len(opt_data_attr);
ctx.port = opt_inst->port;
switch (opt_type) {
case TEAM_OPTION_TYPE_U32:
- ctx.data.u32_val = nla_get_u32(opt_data_attr);
+ ctx.data.u32_val = nla_get_u32(attr_data);
break;
case TEAM_OPTION_TYPE_STRING:
- if (data_len > TEAM_STRING_MAX_LEN) {
+ if (nla_len(attr_data) > TEAM_STRING_MAX_LEN) {
err = -EINVAL;
goto team_put;
}
- ctx.data.str_val = nla_data(opt_data_attr);
+ ctx.data.str_val = nla_data(attr_data);
break;
case TEAM_OPTION_TYPE_BINARY:
- ctx.data.bin_val.len = data_len;
- ctx.data.bin_val.ptr = nla_data(opt_data_attr);
+ ctx.data.bin_val.len = nla_len(attr_data);
+ ctx.data.bin_val.ptr = nla_data(attr_data);
+ break;
+ case TEAM_OPTION_TYPE_BOOL:
+ ctx.data.bool_val = attr_data ? true : false;
break;
default:
BUG();
diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index 6f27c84..78c84fd 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -69,6 +69,7 @@ enum team_option_type {
TEAM_OPTION_TYPE_U32,
TEAM_OPTION_TYPE_STRING,
TEAM_OPTION_TYPE_BINARY,
+ TEAM_OPTION_TYPE_BOOL,
};
struct team_gsetter_ctx {
@@ -79,6 +80,7 @@ struct team_gsetter_ctx {
const void *ptr;
u32 len;
} bin_val;
+ bool bool_val;
} data;
struct team_port *port;
};
--
1.7.9.1
^ permalink raw reply related
* [patch net-next 3/5] team: add user_linkup and user_linkup_enabled per-port option
From: Jiri Pirko @ 2012-04-10 15:15 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet
In-Reply-To: <1334070946-7704-1-git-send-email-jpirko@redhat.com>
Allows userspace to setup linkup for ports. Default is to take linkup
directly from ethtool state.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/team/team.c | 72 +++++++++++++++++++++++++++++++++++++++++------
include/linux/if_team.h | 26 ++++++++++++-----
2 files changed, 81 insertions(+), 17 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index 2645fae..e639abe 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -76,6 +76,11 @@ int team_port_set_team_mac(struct team_port *port)
}
EXPORT_SYMBOL(team_port_set_team_mac);
+static void team_refresh_port_linkup(struct team_port *port)
+{
+ port->linkup = port->user.linkup_enabled ? port->user.linkup :
+ port->state.linkup;
+}
/*******************
* Options handling
@@ -880,6 +885,40 @@ static int team_mode_option_set(struct team *team, struct team_gsetter_ctx *ctx)
return team_change_mode(team, ctx->data.str_val);
}
+static int team_user_linkup_option_get(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ ctx->data.bool_val = ctx->port->user.linkup;
+ return 0;
+}
+
+static int team_user_linkup_option_set(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ ctx->port->user.linkup = ctx->data.bool_val;
+ team_refresh_port_linkup(ctx->port);
+ return 0;
+}
+
+static int team_user_linkup_en_option_get(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ struct team_port *port = ctx->port;
+
+ ctx->data.bool_val = port->user.linkup_enabled;
+ return 0;
+}
+
+static int team_user_linkup_en_option_set(struct team *team,
+ struct team_gsetter_ctx *ctx)
+{
+ struct team_port *port = ctx->port;
+
+ port->user.linkup_enabled = ctx->data.bool_val;
+ team_refresh_port_linkup(ctx->port);
+ return 0;
+}
+
static const struct team_option team_options[] = {
{
.name = "mode",
@@ -887,6 +926,20 @@ static const struct team_option team_options[] = {
.getter = team_mode_option_get,
.setter = team_mode_option_set,
},
+ {
+ .name = "user_linkup",
+ .type = TEAM_OPTION_TYPE_BOOL,
+ .per_port = true,
+ .getter = team_user_linkup_option_get,
+ .setter = team_user_linkup_option_set,
+ },
+ {
+ .name = "user_linkup_enabled",
+ .type = TEAM_OPTION_TYPE_BOOL,
+ .per_port = true,
+ .getter = team_user_linkup_en_option_get,
+ .setter = team_user_linkup_en_option_set,
+ },
};
static int team_init(struct net_device *dev)
@@ -1670,10 +1723,10 @@ static int team_nl_fill_port_list_get(struct sk_buff *skb,
}
if ((port->removed &&
nla_put_flag(skb, TEAM_ATTR_PORT_REMOVED)) ||
- (port->linkup &&
+ (port->state.linkup &&
nla_put_flag(skb, TEAM_ATTR_PORT_LINKUP)) ||
- nla_put_u32(skb, TEAM_ATTR_PORT_SPEED, port->speed) ||
- nla_put_u8(skb, TEAM_ATTR_PORT_DUPLEX, port->duplex))
+ nla_put_u32(skb, TEAM_ATTR_PORT_SPEED, port->state.speed) ||
+ nla_put_u8(skb, TEAM_ATTR_PORT_DUPLEX, port->state.duplex))
goto nla_put_failure;
nla_nest_end(skb, port_item);
}
@@ -1833,23 +1886,24 @@ static void __team_port_change_check(struct team_port *port, bool linkup)
{
int err;
- if (!port->removed && port->linkup == linkup)
+ if (!port->removed && port->state.linkup == linkup)
return;
port->changed = true;
- port->linkup = linkup;
+ port->state.linkup = linkup;
+ team_refresh_port_linkup(port);
if (linkup) {
struct ethtool_cmd ecmd;
err = __ethtool_get_settings(port->dev, &ecmd);
if (!err) {
- port->speed = ethtool_cmd_speed(&ecmd);
- port->duplex = ecmd.duplex;
+ port->state.speed = ethtool_cmd_speed(&ecmd);
+ port->state.duplex = ecmd.duplex;
goto send_event;
}
}
- port->speed = 0;
- port->duplex = 0;
+ port->state.speed = 0;
+ port->state.duplex = 0;
send_event:
err = team_nl_send_event_port_list_get(port->team);
diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index 78c84fd..5fd5ab1 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -33,6 +33,24 @@ struct team_port {
struct team *team;
int index;
+ bool linkup; /* either state.linkup or user.linkup */
+
+ struct {
+ bool linkup;
+ u32 speed;
+ u8 duplex;
+ } state;
+
+ /* Values set by userspace */
+ struct {
+ bool linkup;
+ bool linkup_enabled;
+ } user;
+
+ /* Custom gennetlink interface related flags */
+ bool changed;
+ bool removed;
+
/*
* A place for storing original values of the device before it
* become a port.
@@ -42,14 +60,6 @@ struct team_port {
unsigned int mtu;
} orig;
- bool linkup;
- u32 speed;
- u8 duplex;
-
- /* Custom gennetlink interface related flags */
- bool changed;
- bool removed;
-
struct rcu_head rcu;
};
--
1.7.9.1
^ permalink raw reply related
* [patch net-next 4/5] team: ab: walk through port list non-rcu
From: Jiri Pirko @ 2012-04-10 15:15 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet
In-Reply-To: <1334070946-7704-1-git-send-email-jpirko@redhat.com>
Since team->lock is being held, _rcu variant make no sense.
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/team/team_mode_activebackup.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/team/team_mode_activebackup.c b/drivers/net/team/team_mode_activebackup.c
index 6cde1ab..a715c40 100644
--- a/drivers/net/team/team_mode_activebackup.c
+++ b/drivers/net/team/team_mode_activebackup.c
@@ -72,7 +72,7 @@ static int ab_active_port_set(struct team *team, struct team_gsetter_ctx *ctx)
{
struct team_port *port;
- list_for_each_entry_rcu(port, &team->port_list, list) {
+ list_for_each_entry(port, &team->port_list, list) {
if (port->dev->ifindex == ctx->data.u32_val) {
rcu_assign_pointer(ab_priv(team)->active_port, port);
return 0;
--
1.7.9.1
^ permalink raw reply related
* [patch net-next 5/5] team: add missed "statics"
From: Jiri Pirko @ 2012-04-10 15:15 UTC (permalink / raw)
To: netdev; +Cc: davem, eric.dumazet
In-Reply-To: <1334070946-7704-1-git-send-email-jpirko@redhat.com>
Signed-off-by: Jiri Pirko <jpirko@redhat.com>
---
drivers/net/team/team.c | 2 +-
drivers/net/team/team_mode_activebackup.c | 4 ++--
drivers/net/team/team_mode_loadbalance.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index e639abe..153a62d 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -65,7 +65,7 @@ static int __set_port_mac(struct net_device *port_dev,
return dev_set_mac_address(port_dev, &addr);
}
-int team_port_set_orig_mac(struct team_port *port)
+static int team_port_set_orig_mac(struct team_port *port)
{
return __set_port_mac(port->dev, port->orig.dev_addr);
}
diff --git a/drivers/net/team/team_mode_activebackup.c b/drivers/net/team/team_mode_activebackup.c
index a715c40..fd6bd03 100644
--- a/drivers/net/team/team_mode_activebackup.c
+++ b/drivers/net/team/team_mode_activebackup.c
@@ -90,12 +90,12 @@ static const struct team_option ab_options[] = {
},
};
-int ab_init(struct team *team)
+static int ab_init(struct team *team)
{
return team_options_register(team, ab_options, ARRAY_SIZE(ab_options));
}
-void ab_exit(struct team *team)
+static void ab_exit(struct team *team)
{
team_options_unregister(team, ab_options, ARRAY_SIZE(ab_options));
}
diff --git a/drivers/net/team/team_mode_loadbalance.c b/drivers/net/team/team_mode_loadbalance.c
index 167cdb4..2b506b2 100644
--- a/drivers/net/team/team_mode_loadbalance.c
+++ b/drivers/net/team/team_mode_loadbalance.c
@@ -130,13 +130,13 @@ static const struct team_option lb_options[] = {
},
};
-int lb_init(struct team *team)
+static int lb_init(struct team *team)
{
return team_options_register(team, lb_options,
ARRAY_SIZE(lb_options));
}
-void lb_exit(struct team *team)
+static void lb_exit(struct team *team)
{
team_options_unregister(team, lb_options,
ARRAY_SIZE(lb_options));
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH 05/10] net: move destructor_arg to the front of sk_buff.
From: Ian Campbell @ 2012-04-10 15:19 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev@vger.kernel.org, David Miller, Michael S. Tsirkin,
Wei Liu (Intern), xen-devel@lists.xen.org
In-Reply-To: <1334070301.5300.65.camel@edumazet-glaptop>
On Tue, 2012-04-10 at 16:05 +0100, Eric Dumazet wrote:
> On Tue, 2012-04-10 at 15:26 +0100, Ian Campbell wrote:
> > As of the previous patch we align the end (rather than the start) of the struct
> > to a cache line and so, with 32 and 64 byte cache lines and the shinfo size
> > increase from the next patch, the first 8 bytes of the struct end up on a
> > different cache line to the rest of it so make sure it is something relatively
> > unimportant to avoid hitting an extra cache line on hot operations such as
> > kfree_skb.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > ---
> > include/linux/skbuff.h | 15 ++++++++++-----
> > net/core/skbuff.c | 5 ++++-
> > 2 files changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> > index 0ad6a46..f0ae39c 100644
> > --- a/include/linux/skbuff.h
> > +++ b/include/linux/skbuff.h
> > @@ -265,6 +265,15 @@ struct ubuf_info {
> > * the end of the header data, ie. at skb->end.
> > */
> > struct skb_shared_info {
> > + /* Intermediate layers must ensure that destructor_arg
> > + * remains valid until skb destructor */
> > + void *destructor_arg;
> > +
> > + /*
> > + * Warning: all fields from here until dataref are cleared in
> > + * __alloc_skb()
> > + *
> > + */
> > unsigned char nr_frags;
> > __u8 tx_flags;
> > unsigned short gso_size;
> > @@ -276,14 +285,10 @@ struct skb_shared_info {
> > __be32 ip6_frag_id;
> >
> > /*
> > - * Warning : all fields before dataref are cleared in __alloc_skb()
> > + * Warning: all fields before dataref are cleared in __alloc_skb()
> > */
> > atomic_t dataref;
> >
> > - /* Intermediate layers must ensure that destructor_arg
> > - * remains valid until skb destructor */
> > - void * destructor_arg;
> > -
> > /* must be last field, see pskb_expand_head() */
> > skb_frag_t frags[MAX_SKB_FRAGS];
> > };
> > diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> > index d4e139e..b8a41d6 100644
> > --- a/net/core/skbuff.c
> > +++ b/net/core/skbuff.c
> > @@ -214,7 +214,10 @@ struct sk_buff *__alloc_skb(unsigned int size, gfp_t gfp_mask,
> >
> > /* make sure we initialize shinfo sequentially */
> > shinfo = skb_shinfo(skb);
> > - memset(shinfo, 0, offsetof(struct skb_shared_info, dataref));
> > +
> > + memset(&shinfo->nr_frags, 0,
> > + offsetof(struct skb_shared_info, dataref)
> > + - offsetof(struct skb_shared_info, nr_frags));
> > atomic_set(&shinfo->dataref, 1);
> > kmemcheck_annotate_variable(shinfo->destructor_arg);
> >
>
> Not sure if we can do the same in build_skb()
I don't think there's any chance of there being a destructor_arg to
preserve in that case?
Regardless of that though I think for consistency it would be worth
pulling the common shinfo init out into a helper and using it in both
places.
I'll make that change.
Ian.
>
>
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-10 15:26 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120410143500.GD19556@redhat.com>
On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
>>> Hmm okay, but this would mean we should convert
>>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
>>> that can combined with all modes. E.g.
>>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
>>>
>>> and document that it does not promise to flood
>>> multicast.
>>>
>>
>> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
>> for this patch. Then a follow on series can rework bridge
>> and VEPA to use it as well.
>
> Right. We probably need a better name if it's going to
> affect other things besides promisc though.
>
how about MACVLAN_MODE_FDBFLAG?
^ permalink raw reply
* [PATCH] iproute: show metrics as an unsigned value
From: Jorge Boncompte [DTI2] @ 2012-04-10 15:20 UTC (permalink / raw)
To: netdev; +Cc: shemminger, Jorge Boncompte [DTI2]
From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
Avoids showing negative metrics.
Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
---
ip/iproute.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index c97f979..2d15c01 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -404,7 +404,7 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
abuf, sizeof(abuf)));
}
if (tb[RTA_PRIORITY])
- fprintf(fp, " metric %d ", *(__u32*)RTA_DATA(tb[RTA_PRIORITY]));
+ fprintf(fp, " metric %u ", *(__u32*)RTA_DATA(tb[RTA_PRIORITY]));
if (r->rtm_flags & RTNH_F_DEAD)
fprintf(fp, "dead ");
if (r->rtm_flags & RTNH_F_ONLINK)
--
1.7.8.3
^ permalink raw reply related
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-10 15:29 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120410143306.GC19556@redhat.com>
On 4/10/2012 7:33 AM, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 06:50:42AM -0700, John Fastabend wrote:
>> On 4/10/2012 1:14 AM, Michael S. Tsirkin wrote:
>>> On Tue, Apr 10, 2012 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
>>>> On Mon, Apr 09, 2012 at 03:00:54PM -0700, John Fastabend wrote:
>>>>> This adds a new macvlan mode MACVLAN_PASSTHRU_NOPROMISC
>>>>> this mode acts the same as the original passthru mode _except_
>>>>> it does not set promiscuous mode on the lowerdev. Because the
>>>>> lowerdev is not put in promiscuous mode any unicast or multicast
>>>>> addresses the device should receive must be explicitely added
>>>>> with the FDB bridge ops. In many use cases the management stack
>>>>> will know the mac addresses needed (maybe negotiated via EVB/VDP)
>>>>> or may require only receiving known "good" mac addresses. This
>>>>> mode with the FDB ops supports this usage model.
>>>>
>>>>
>>>> Looks good to me. Some questions below:
>>>>
>>>>> This patch is a result of Roopa Prabhu's work. Follow up
>>>>> patches are needed for VEPA and VEB macvlan modes.
>>>>
>>>> And bridge too?
>>>>
>>>> Also, my understanding is that other modes won't need a flag
>>>> like this since they don't put the device in promisc mode initially,
>>>> so no assumptions are broken if we require all addresses
>>>> to be declared, right?
>>>>
>>>> A final question: I think we'll later add a macvlan mode
>>>> that does not flood all multicasts. This would change behaviour
>>>> in an incompatible way so we'll probably need yet another
>>>> flag. Would it make sense to combine this functionality
>>>> with nopromisc so we have less modes to support?
>>>
>>> One other question I forgot:
>>>
>>
>> [...]
>>
>>>>>
>>>>> @@ -344,12 +346,15 @@ static int macvlan_stop(struct net_device *dev)
>>>>> struct macvlan_dev *vlan = netdev_priv(dev);
>>>>> struct net_device *lowerdev = vlan->lowerdev;
>>>>>
>>>>> + dev_uc_unsync(lowerdev, dev);
>>>>> + dev_mc_unsync(lowerdev, dev);
>>>>> +
>>>>> if (vlan->port->passthru) {
>>>>> - dev_set_promiscuity(lowerdev, -1);
>>>>> + if (vlan->mode == MACVLAN_MODE_PASSTHRU)
>>>>> + dev_set_promiscuity(lowerdev, 1);
>>>>> goto hash_del;
>>>>> }
>>>>>
>>>>> - dev_mc_unsync(lowerdev, dev);
>>>>> if (dev->flags & IFF_ALLMULTI)
>>>>> dev_set_allmulti(lowerdev, -1);
>>>>>
>>>>> @@ -399,10 +404,11 @@ static void macvlan_change_rx_flags(struct net_device *dev, int change)
>>>>> dev_set_allmulti(lowerdev, dev->flags & IFF_ALLMULTI ? 1 : -1);
>>>
>>> In the new mode, do we want to have promisc on lowerdev follow whatever
>>> is set on the macvlan, like we do for allmulti?
>>> I'm not sure at this point - what do others think?
>>>
>>
>> Just to enumerate why you would need this: (1) socket set with
>> PACKET_MR_MULTICAST and (2) something like mrouted is running
>> on the macvlan (3) maybe some case I missed?
>>
>> Don't you need CAP_NET_RAW to set these though anyways? So I
>> wouldn't think it would be a problem. I assume if a user has
>> CAP_NET_RAW or UUID 0 they really should be able to set this
>> up.
>>
>> .John
>
> I am not sure, really.
> But I note that with a security mechanism such as selinux, CAP_NET_RAW
> might be insufficient to change the underlying device.
> So there might be value in being able to change it in
> a controlled manner through macvlan.
>
> There's also something to be said for being able to let
> management deal with macvlan devices (and there are
> some very complex tools for that around) while
> keeping a simple script around for the physical
> one and knowing that they won't disrupt each other.
>
If people really _need_/_want_ this then I guess we can
add another flag. I don't think we should to tie this into
the FDB bits creating an interface with strange side effects
is probably a poor design. Much better IMHO to have an
explicit bit if and when this is needed.
.John
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: Michael S. Tsirkin @ 2012-04-10 15:30 UTC (permalink / raw)
To: John Fastabend
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <4F84511D.7060902@intel.com>
On Tue, Apr 10, 2012 at 08:26:21AM -0700, John Fastabend wrote:
> On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
> > On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
> >>> Hmm okay, but this would mean we should convert
> >>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
> >>> that can combined with all modes. E.g.
> >>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
> >>>
> >>> and document that it does not promise to flood
> >>> multicast.
> >>>
> >>
> >> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
> >> for this patch. Then a follow on series can rework bridge
> >> and VEPA to use it as well.
> >
> > Right. We probably need a better name if it's going to
> > affect other things besides promisc though.
> >
>
> how about MACVLAN_MODE_FDBFLAG?
The idea being that no one figures out what this means so
no one will make any wrong assumptions? ;)
--
MST
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-10 15:35 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120410153014.GA20488@redhat.com>
On 4/10/2012 8:30 AM, Michael S. Tsirkin wrote:
> On Tue, Apr 10, 2012 at 08:26:21AM -0700, John Fastabend wrote:
>> On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
>>> On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
>>>>> Hmm okay, but this would mean we should convert
>>>>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
>>>>> that can combined with all modes. E.g.
>>>>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
>>>>>
>>>>> and document that it does not promise to flood
>>>>> multicast.
>>>>>
>>>>
>>>> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
>>>> for this patch. Then a follow on series can rework bridge
>>>> and VEPA to use it as well.
>>>
>>> Right. We probably need a better name if it's going to
>>> affect other things besides promisc though.
>>>
>>
>> how about MACVLAN_MODE_FDBFLAG?
>
> The idea being that no one figures out what this means so
> no one will make any wrong assumptions? ;)
>
Well its a flag to enable the FDB (forwarding database) ops
and skip dev_set_promisc() on passthru mode. Any better ideas?
Maybe MACVLAN_MODE_FDBENABLE or MACVLAN_MODE_MANAGE_FDB?
^ permalink raw reply
* Re: [PATCH v4 0/10] skb paged fragment destructors
From: Bart Van Assche @ 2012-04-10 15:46 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, David Miller, Eric Dumazet, Michael S. Tsirkin, Wei Liu,
David VomLehn, xen-devel
In-Reply-To: <1334067965.5394.22.camel@zakaz.uk.xensource.com>
On 04/10/12 14:26, Ian Campbell wrote:
> I think this is v4, but I've sort of lost count, sorry that it's taken
> me so long to get back to this stuff.
>
> The following series makes use of the skb fragment API (which is in 3.2
> +) to add a per-paged-fragment destructor callback. This can be used by
> creators of skbs who are interested in the lifecycle of the pages
> included in that skb after they have handed it off to the network stack.
Hello Ian,
Great to see v4 of this patch series. But which kernel version has this
patch series been based on ? I've tried to apply this series on 3.4-rc2 but
apparently applying patch 09/10 failed:
patching file net/ceph/messenger.c
Hunk #1 FAILED at 851.
1 out of 1 hunk FAILED -- saving rejects to file net/ceph/messenger.c.rej
Regards,
Bart.
^ permalink raw reply
* Re: [PATCH] iproute: show metrics as an unsigned value
From: Stephen Hemminger @ 2012-04-10 15:48 UTC (permalink / raw)
To: jorge; +Cc: netdev
In-Reply-To: <1334071226-17865-1-git-send-email-jorge@dti2.net>
On Tue, 10 Apr 2012 17:20:26 +0200
"Jorge Boncompte [DTI2]" <jorge@dti2.net> wrote:
> From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
>
> Avoids showing negative metrics.
>
> Signed-off-by: Jorge Boncompte [DTI2] <jorge@dti2.net>
> ---
> ip/iproute.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/ip/iproute.c b/ip/iproute.c
> index c97f979..2d15c01 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -404,7 +404,7 @@ int print_route(const struct sockaddr_nl *who, struct nlmsghdr *n, void *arg)
> abuf, sizeof(abuf)));
> }
> if (tb[RTA_PRIORITY])
> - fprintf(fp, " metric %d ", *(__u32*)RTA_DATA(tb[RTA_PRIORITY]));
> + fprintf(fp, " metric %u ", *(__u32*)RTA_DATA(tb[RTA_PRIORITY]));
> if (r->rtm_flags & RTNH_F_DEAD)
> fprintf(fp, "dead ");
> if (r->rtm_flags & RTNH_F_ONLINK)
Applied
^ permalink raw reply
* Re: [PATCH v4 0/10] skb paged fragment destructors
From: Ian Campbell @ 2012-04-10 15:50 UTC (permalink / raw)
To: Bart Van Assche
Cc: netdev@vger.kernel.org, David Miller, Eric Dumazet,
Michael S. Tsirkin, Wei Liu (Intern), David VomLehn, xen-devel
In-Reply-To: <4F8455EE.8010709@acm.org>
On Tue, 2012-04-10 at 16:46 +0100, Bart Van Assche wrote:
> On 04/10/12 14:26, Ian Campbell wrote:
>
> > I think this is v4, but I've sort of lost count, sorry that it's taken
> > me so long to get back to this stuff.
> >
> > The following series makes use of the skb fragment API (which is in 3.2
> > +) to add a per-paged-fragment destructor callback. This can be used by
> > creators of skbs who are interested in the lifecycle of the pages
> > included in that skb after they have handed it off to the network stack.
>
>
> Hello Ian,
>
> Great to see v4 of this patch series. But which kernel version has this
> patch series been based on ? I've tried to apply this series on 3.4-rc2
It's based on net-next/master. Specifically commit de8856d2c11f.
Ian.
^ permalink raw reply
* Re: [PATCH iproute] tc pedit action: fix parsing offset options.
From: Stephen Hemminger @ 2012-04-10 16:08 UTC (permalink / raw)
To: Anton 'EvilMan' Danilov; +Cc: netdev
In-Reply-To: <CAEzD07+xdGxMh9-RHvF0RJZsCvj0Dj=VEY=0csPrSbTED4Hb6g@mail.gmail.com>
On Wed, 29 Feb 2012 19:34:28 +0300
"Anton 'EvilMan' Danilov" <littlesmilingcloud@gmail.com> wrote:
> This patch fix parsing offset option with "at" parameter.
> Tc returns error If keywords "offmask" and "shift" are presented.
>
> Example of wrong parsing:
>
> ~$ tc f add dev eth0 parent 1: protocol ip pref 10 \
> u32 match u32 0 0 \
> action pedit help
> Usage: ... pedit munge <MUNGE>
> Where: MUNGE := <RAW>|<LAYERED>
> <RAW>:= <OFFSETC>[ATC]<CMD>
> OFFSETC:= offset <offval> <u8|u16|u32>
> ATC:= at <atval> offmask <maskval> shift <shiftval>
> NOTE: offval is byte offset, must be multiple of 4
> NOTE: maskval is a 32 bit hex number
> NOTE: shiftval is a is a shift value
> CMD:= clear | invert | set <setval>| retain
> <LAYERED>:= ip <ipdata> | ip6 <ip6data>
> | udp <udpdata> | tcp <tcpdata> | icmp <icmpdata>
> For Example usage look at the examples directory
>
> #try to add filter with pedit action using "at" option
> ~$ tc f add dev eth0 parent 1: pref 10 protocol all handle ::10 \
> u32 match ip protocol 6 0xff \
> match ip src 10.10.20.119/32 \
> match ip dst 10.10.20.254/32 \
> action pedit munge offset 2 u16 at 0 offmask 0f0000000 shift 22 set 11500
> Illegal pedit construct (2)
> ...
> bad action parsing
> parse_action: bad value (19:pedit)!
> Illegal "action"
>
> ~$ tc f add dev eth0 parent 1: pref 10 protocol all handle ::10 \
> u32 match ip protocol 6 0xff \
> match ip src 10.10.20.119/32 \
> match ip dst 10.10.20.254/32 \
> action pedit munge offset 2 u16 at 0 0f0000000 22 set 11500
> parse_cmd argc 8 set offset 2 length 2
> pack_key16: Final val ec2c0000 mask 0000ffff
> parse_cmd done argc 6 pipe offset 0 length 2
>
Won't this break existing scripts because you changed the offset mask
from being a value to requiring a "offmask"?
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-07
From: David Miller @ 2012-04-10 16:21 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <1333824598-27771-1-git-send-email-ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Sat, 7 Apr 2012 20:49:42 +0200
> this is the updated and cleaned up version of our last pull request (sent on
> 2012-04-05).
You absolutely must base your tree off the correct tree, which is
net-next
You cannot use Linus's tree or my 'net' tree to base your work,
because otherwise when I pull I get all the damn crap that's in those
trees but not in net-next yet and that's never right.
^ permalink raw reply
* Re: [PATCH 4/5] staging: octeon_ethernet: Convert to use device tree.
From: Greg Kroah-Hartman @ 2012-04-10 16:43 UTC (permalink / raw)
To: David Daney
Cc: linux-mips, ralf, devicetree-discuss, Grant Likely, Rob Herring,
linux-kernel, David Daney, netdev
In-Reply-To: <1332808075-8333-5-git-send-email-ddaney.cavm@gmail.com>
On Mon, Mar 26, 2012 at 05:27:54PM -0700, David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> Get MAC address and PHY connection from the device tree. The driver
> is converted to a platform driver.
>
> Cc: netdev@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: David Daney <david.daney@cavium.com>
> ---
>
> Should probably go via Ralf's linux-mips.org tree.
That's fine with me:
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v3 2/2] cgroup: get rid of populate for memcg
From: Tejun Heo @ 2012-04-10 17:05 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: Glauber Costa, netdev-u79uwXL29TY76Z2rM5mHXA,
cgroups-u79uwXL29TY76Z2rM5mHXA, Li Zefan, Johannes Weiner,
Michal Hocko
In-Reply-To: <4F839E73.1000204-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
On Tue, Apr 10, 2012 at 11:44:03AM +0900, KAMEZAWA Hiroyuki wrote:
> (2012/04/10 7:36), Glauber Costa wrote:
>
> > The last man standing justifying the need for populate() is the
> > sock memcg initialization functions. Now that we are able to pass
> > a struct mem_cgroup instead of a struct cgroup to the socket
> > initialization, there is nothing that stops us from initializing
> > everything in create().
> >
> > Signed-off-by: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
> > CC: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> > CC: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > CC: Kamezawa Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
> > CC: Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
> > CC: Michal Hocko <mhocko-AlSwsSmVLrQ@public.gmane.org>
>
> Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>
Applied to cgroup/for-3.5. Thanks.
--
tejun
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: Michael S. Tsirkin @ 2012-04-10 15:32 UTC (permalink / raw)
To: John Fastabend
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <4F8451E9.5060805@intel.com>
On Tue, Apr 10, 2012 at 08:29:45AM -0700, John Fastabend wrote:
> On 4/10/2012 7:33 AM, Michael S. Tsirkin wrote:
> > On Tue, Apr 10, 2012 at 06:50:42AM -0700, John Fastabend wrote:
> >> On 4/10/2012 1:14 AM, Michael S. Tsirkin wrote:
> >>> On Tue, Apr 10, 2012 at 11:09:16AM +0300, Michael S. Tsirkin wrote:
> >>>> On Mon, Apr 09, 2012 at 03:00:54PM -0700, John Fastabend wrote:
> >>>>> This adds a new macvlan mode MACVLAN_PASSTHRU_NOPROMISC
> >>>>> this mode acts the same as the original passthru mode _except_
> >>>>> it does not set promiscuous mode on the lowerdev. Because the
> >>>>> lowerdev is not put in promiscuous mode any unicast or multicast
> >>>>> addresses the device should receive must be explicitely added
> >>>>> with the FDB bridge ops. In many use cases the management stack
> >>>>> will know the mac addresses needed (maybe negotiated via EVB/VDP)
> >>>>> or may require only receiving known "good" mac addresses. This
> >>>>> mode with the FDB ops supports this usage model.
> >>>>
> >>>>
> >>>> Looks good to me. Some questions below:
> >>>>
> >>>>> This patch is a result of Roopa Prabhu's work. Follow up
> >>>>> patches are needed for VEPA and VEB macvlan modes.
> >>>>
> >>>> And bridge too?
> >>>>
> >>>> Also, my understanding is that other modes won't need a flag
> >>>> like this since they don't put the device in promisc mode initially,
> >>>> so no assumptions are broken if we require all addresses
> >>>> to be declared, right?
> >>>>
> >>>> A final question: I think we'll later add a macvlan mode
> >>>> that does not flood all multicasts. This would change behaviour
> >>>> in an incompatible way so we'll probably need yet another
> >>>> flag. Would it make sense to combine this functionality
> >>>> with nopromisc so we have less modes to support?
> >>>
> >>> One other question I forgot:
> >>>
> >>
> >> [...]
> >>
> >>>>>
> >>>>> @@ -344,12 +346,15 @@ static int macvlan_stop(struct net_device *dev)
> >>>>> struct macvlan_dev *vlan = netdev_priv(dev);
> >>>>> struct net_device *lowerdev = vlan->lowerdev;
> >>>>>
> >>>>> + dev_uc_unsync(lowerdev, dev);
> >>>>> + dev_mc_unsync(lowerdev, dev);
> >>>>> +
> >>>>> if (vlan->port->passthru) {
> >>>>> - dev_set_promiscuity(lowerdev, -1);
> >>>>> + if (vlan->mode == MACVLAN_MODE_PASSTHRU)
> >>>>> + dev_set_promiscuity(lowerdev, 1);
> >>>>> goto hash_del;
> >>>>> }
> >>>>>
> >>>>> - dev_mc_unsync(lowerdev, dev);
> >>>>> if (dev->flags & IFF_ALLMULTI)
> >>>>> dev_set_allmulti(lowerdev, -1);
> >>>>>
> >>>>> @@ -399,10 +404,11 @@ static void macvlan_change_rx_flags(struct net_device *dev, int change)
> >>>>> dev_set_allmulti(lowerdev, dev->flags & IFF_ALLMULTI ? 1 : -1);
> >>>
> >>> In the new mode, do we want to have promisc on lowerdev follow whatever
> >>> is set on the macvlan, like we do for allmulti?
> >>> I'm not sure at this point - what do others think?
> >>>
> >>
> >> Just to enumerate why you would need this: (1) socket set with
> >> PACKET_MR_MULTICAST and (2) something like mrouted is running
> >> on the macvlan (3) maybe some case I missed?
> >>
> >> Don't you need CAP_NET_RAW to set these though anyways? So I
> >> wouldn't think it would be a problem. I assume if a user has
> >> CAP_NET_RAW or UUID 0 they really should be able to set this
> >> up.
> >>
> >> .John
> >
> > I am not sure, really.
> > But I note that with a security mechanism such as selinux, CAP_NET_RAW
> > might be insufficient to change the underlying device.
> > So there might be value in being able to change it in
> > a controlled manner through macvlan.
> >
> > There's also something to be said for being able to let
> > management deal with macvlan devices (and there are
> > some very complex tools for that around) while
> > keeping a simple script around for the physical
> > one and knowing that they won't disrupt each other.
> >
>
> If people really _need_/_want_ this then I guess we can
> add another flag. I don't think we should to tie this into
> the FDB bits creating an interface with strange side effects
> is probably a poor design. Much better IMHO to have an
> explicit bit if and when this is needed.
>
> .John
OK so with the new flag, you will also disable
the forwarding of ALLMULTI from macvlan to lowerdev?
Fair enough.
--
MST
^ permalink raw reply
* Re: [PATCH v17 15/15] Documentation: prctl/seccomp_filter
From: Ryan Ware @ 2012-04-10 17:49 UTC (permalink / raw)
To: Will Drewry, Markus Gutschke, Andrew Morton
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, luto, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, coreyb,
keescook, jmorris
In-Reply-To: <CABqD9hYQPDmNadkPw9O6fRXHpWDxh=MVPf7VB_3fz_X72dNz4w@mail.gmail.com>
On 4/9/12 3:47 PM, "Will Drewry" <wad@chromium.org> wrote:
>On Mon, Apr 9, 2012 at 3:58 PM, Ryan Ware <ware@linux.intel.com> wrote:
>>
>> On 4/9/12 1:47 PM, "Markus Gutschke" <markus@chromium.org> wrote:
>>
>>>No matter what you do, please leave the samples accessible somewhere.
>>>They proved incredibly useful in figuring out how the API works. I am
>>>sure, other developers are going to appreciate them as well.
>>>
>>>Alternatively, if you don't want to include the samples with the
>>>kernel sources, figure out how you can include a sample in the
>>>official manual page for prctl().
>>>
>>
>> I second this! They are extremely useful.
>>
>> Ryan
>
>In that case, would it make sense to put up a separate tools/testing
>patch and leave samples where they lie? (I'd _love_ to keep this patch
>series from acquiring another 1000 lines, but either way works :)
>
>My current tester and harness lives here:
> https://github.com/redpig/seccomp/blob/master/tests/
>and the licensing can be sorted out prior to a patch mail.
I have absolutely no problems with that solution. Availability is the
important thing.
Ryan
^ permalink raw reply
* [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Neal Cardwell @ 2012-04-10 17:59 UTC (permalink / raw)
To: David Miller
Cc: netdev, Nandita Dukkipati, Yuchung Cheng, Eric Dumazet,
Tom Herbert, Neal Cardwell
Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and
unscaled RTT samples.
The intent in the code was to only use the 'm' measurement if it was a
new minimum. However, since 'm' had not yet been shifted left 3 bits
but 'new_sample' had, this comparison would nearly always succeed,
leading us to erroneously set our receive-side RTT estimate to the 'm'
sample when that sample could be nearly 8x too high to use.
The overall effect is to often cause the receive-side RTT estimate to
be significantly too large (up to 40% too large for brief periods in
my tests).
Signed-off-by: Neal Cardwell <ncardwell@google.com>
---
net/ipv4/tcp_input.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index e886e2f..e7b54d2 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -474,8 +474,11 @@ static void tcp_rcv_rtt_update(struct tcp_sock *tp, u32 sample, int win_dep)
if (!win_dep) {
m -= (new_sample >> 3);
new_sample += m;
- } else if (m < new_sample)
- new_sample = m << 3;
+ } else {
+ m <<= 3;
+ if (m < new_sample)
+ new_sample = m;
+ }
} else {
/* No previous measure. */
new_sample = m << 3;
--
1.7.7.3
^ permalink raw reply related
* Re: pull request: batman-adv 2012-04-07
From: Sven Eckelmann @ 2012-04-10 18:03 UTC (permalink / raw)
To: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <20120410.122119.454371140692964064.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
On Tuesday, April 10, 2012 12:21:19 PM David Miller wrote:
> From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
> Date: Sat, 7 Apr 2012 20:49:42 +0200
>
> > this is the updated and cleaned up version of our last pull request
> > (sent on 2012-04-05).
>
> You absolutely must base your tree off the correct tree, which is
> net-next
>
> You cannot use Linus's tree or my 'net' tree to base your work,
> because otherwise when I pull I get all the damn crap that's in those
> trees but not in net-next yet and that's never right.
Can you please tell us your "stable point" [1].
Thanks,
Sven
[1] https://lkml.org/lkml/2010/9/28/362
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Please revert removal of /sys/class/net/*/features
From: Stephen Hemminger @ 2012-04-10 18:08 UTC (permalink / raw)
To: David Miller; +Cc: Michał Mirosław, netdev
This commit needs to be reverted. It removed an available sysfs file, and sysfs
files are part of the ABI. It caused a bug in our current release of Vyatta because
the shell script was using the sysfs file to see if VLAN was supported on a device.
An API maybe redundant, but you can't just remove it.
commit 974151e6119f20d2af4acb97526c780ae0f18ccb
Author: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Date: Thu Jul 14 14:45:15 2011 -0700
net: remove /sys/class/net/*/features
The same information and more can be obtained by using ethtool
with ETHTOOL_GFEATURES.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: pull request: batman-adv 2012-04-07
From: David Miller @ 2012-04-10 18:26 UTC (permalink / raw)
To: sven-KaDOiPu9UxWEi8DpZVb4nw
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r
In-Reply-To: <4234545.h1xVgDKcJ2@bentobox>
From: Sven Eckelmann <sven-KaDOiPu9UxWEi8DpZVb4nw@public.gmane.org>
Date: Tue, 10 Apr 2012 20:03:43 +0200
> On Tuesday, April 10, 2012 12:21:19 PM David Miller wrote:
>> From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
>> Date: Sat, 7 Apr 2012 20:49:42 +0200
>>
>> > this is the updated and cleaned up version of our last pull request
>> > (sent on 2012-04-05).
>>
>> You absolutely must base your tree off the correct tree, which is
>> net-next
>>
>> You cannot use Linus's tree or my 'net' tree to base your work,
>> because otherwise when I pull I get all the damn crap that's in those
>> trees but not in net-next yet and that's never right.
>
> Can you please tell us your "stable point" [1].
Please, just base your work on the current tip of net-next like the
rest of the networking developers do. I haven't once ever had to
talk about "stable point" or anything like that, you just simply
work against the tip of my tree and that's the end of it.
^ permalink raw reply
* Re: Please revert removal of /sys/class/net/*/features
From: David Miller @ 2012-04-10 18:27 UTC (permalink / raw)
To: shemminger; +Cc: mirq-linux, netdev
In-Reply-To: <20120410110851.5690739c@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 10 Apr 2012 11:08:51 -0700
> This commit needs to be reverted. It removed an available sysfs file, and sysfs
> files are part of the ABI. It caused a bug in our current release of Vyatta because
> the shell script was using the sysfs file to see if VLAN was supported on a device.
>
> An API maybe redundant, but you can't just remove it.
I think it's more about representability with an expanded
netdev_features_t type.
^ permalink raw reply
* Re: Please revert removal of /sys/class/net/*/features
From: Ben Greear @ 2012-04-10 18:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, Michał Mirosław, netdev
In-Reply-To: <20120410110851.5690739c@nehalam.linuxnetplumber.net>
On 04/10/2012 11:08 AM, Stephen Hemminger wrote:
> This commit needs to be reverted. It removed an available sysfs file, and sysfs
> files are part of the ABI. It caused a bug in our current release of Vyatta because
> the shell script was using the sysfs file to see if VLAN was supported on a device.
It's a hack, but you can also make some vlan IOCTL calls to a device
to probe if it's VLAN or not..thats what I've been doing for the last
decade or so :)
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ 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