* Re: [v2] Re: [RFC] l2tp/ipv6: support for L2TPv2 over UDP over IPv6
From: Benjamin LaHaise @ 2012-04-10 18:49 UTC (permalink / raw)
To: James Chapman; +Cc: Eric Dumazet, netdev
In-Reply-To: <4F840FCB.9050504@katalix.com>
On Tue, Apr 10, 2012 at 11:47:39AM +0100, James Chapman wrote:
> We've tested this in several L2TP environments - looks good. Will you be
> submitting a version soon?
Yes. I'll try to get that out tonight now that net-next is open again.
Also, I found a bug in OpenL2TPd (1.8 I think): certain types of AVPs are
not accepted if they are hidden, despite the fact that RFC 2661 permits
hiding these AVPs. The AVPs in question are: Assigned Tunnel ID, Challege,
Challenge Response and Assigned Session ID.
-ben
--
"Thought is the essence of where you are now."
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: David Miller @ 2012-04-10 18:47 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, nanditad, ycheng, edumazet, therbert
In-Reply-To: <1334080760-968-1-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Tue, 10 Apr 2012 13:59:20 -0400
> 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>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sample
From: Eric Dumazet @ 2012-04-10 18:45 UTC (permalink / raw)
To: Neal Cardwell
Cc: David Miller, netdev, Nandita Dukkipati, Yuchung Cheng,
Tom Herbert
In-Reply-To: <1334080760-968-1-git-send-email-ncardwell@google.com>
On Tue, Apr 10, 2012 at 7:59 PM, Neal Cardwell <ncardwell@google.com> wrote:
> 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
>
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH 0/5] netfilter fixes for 3.4-rc2
From: David Miller @ 2012-04-10 18:43 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1334062141-3962-1-git-send-email-pablo@netfilter.org>
From: pablo@netfilter.org
Date: Tue, 10 Apr 2012 14:48:56 +0200
> The following patchset includes netfilter fixes for 3.4-rc2, they are:
...
> You can pull changes these from:
>
> git://1984.lsi.us.es/net master
Pulled, thanks a lot Pablo.
^ permalink raw reply
* Re: [PATCH v2] tcp: restore correct limit
From: David Miller @ 2012-04-10 18:42 UTC (permalink / raw)
To: eric.dumazet; +Cc: jasowang, monstr, netdev, john.williams, glommer
In-Reply-To: <1334055402.3126.87.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 Apr 2012 12:56:42 +0200
> Commit c43b874d5d714f (tcp: properly initialize tcp memory limits) tried
> to fix a regression added in commits 4acb4190 & 3dc43e3,
> but still get it wrong.
>
> Result is machines with low amount of memory have too small tcp_rmem[2]
> value and slow tcp receives : Per socket limit being 1/1024 of memory
> instead of 1/128 in old kernels, so rcv window is capped to small
> values.
>
> Fix this to match comment and previous behavior.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Jason Wang <jasowang@redhat.com>
> Cc: Glauber Costa <glommer@parallels.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH 05/10] net: move destructor_arg to the front of sk_buff.
From: Eric Dumazet @ 2012-04-10 18:41 UTC (permalink / raw)
To: Alexander Duyck
Cc: Ian Campbell, netdev, David Miller, Michael S. Tsirkin, Wei Liu,
xen-devel
In-Reply-To: <4F847CF9.3090701@intel.com>
On Tue, 2012-04-10 at 11:33 -0700, Alexander Duyck wrote:
> Have you checked this for 32 bit as well as 64? Based on my math your
> next patch will still mess up the memset on 32 bit with the structure
> being split somewhere just in front of hwtstamps.
>
> Why not just take frags and move it to the start of the structure? It
> is already an unknown value because it can be either 16 or 17 depending
> on the value of PAGE_SIZE, and since you are making changes to frags the
> changes wouldn't impact the alignment of the other values later on since
> you are aligning the end of the structure. That way you would be
> guaranteed that all of the fields that will be memset would be in the
> last 64 bytes.
>
Now when a fragmented packet is copied in pskb_expand_head(), you access
two separate zones of memory to copy the shinfo. But its supposed to be
slow path.
Problem with this is that the offsets of often used fields will be big
(instead of being < 127) and code will be bigger on x86.
^ permalink raw reply
* Re: [patch net-next 1/5] team: add support for per-port options
From: David Miller @ 2012-04-10 18:33 UTC (permalink / raw)
To: jpirko; +Cc: netdev, eric.dumazet
In-Reply-To: <1334070946-7704-2-git-send-email-jpirko@redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Tue, 10 Apr 2012 17:15:42 +0200
> @@ -81,7 +81,16 @@ EXPORT_SYMBOL(team_port_set_team_mac);
> * Options handling
> *******************/
>
> -struct team_option *__team_find_option(struct team *team, const char *opt_name)
> +struct team_option_inst { /* One for each option instance */
> + struct list_head list;
> + struct team_option *option;
> + struct team_port *port; /* != NULL if per-port */
> + bool changed;
> + bool removed;
> +};
> +
All this indirection... just simply embed struct team_option into
struct team_option_inst instead of using a pointer, and allocate a
full team_option_inst where you currently memdup in the options.
^ permalink raw reply
* Re: [PATCH 05/10] net: move destructor_arg to the front of sk_buff.
From: Alexander Duyck @ 2012-04-10 18:33 UTC (permalink / raw)
To: Ian Campbell
Cc: netdev, David Miller, Eric Dumazet, Michael S. Tsirkin, Wei Liu,
xen-devel
In-Reply-To: <1334067984-7706-5-git-send-email-ian.campbell@citrix.com>
On 04/10/2012 07:26 AM, 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);
>
Have you checked this for 32 bit as well as 64? Based on my math your
next patch will still mess up the memset on 32 bit with the structure
being split somewhere just in front of hwtstamps.
Why not just take frags and move it to the start of the structure? It
is already an unknown value because it can be either 16 or 17 depending
on the value of PAGE_SIZE, and since you are making changes to frags the
changes wouldn't impact the alignment of the other values later on since
you are aligning the end of the structure. That way you would be
guaranteed that all of the fields that will be memset would be in the
last 64 bytes.
Thanks,
Alex
^ 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
* 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: 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
* 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: 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
* [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: [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
* 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 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: [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: 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 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: [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: 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: 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: [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: [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
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