* 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
* 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: [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: 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 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 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] 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] 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: [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
* [PATCH] net/ipv6/ipv6_sockglue.c: Removed redundant extern
From: Eldad Zack @ 2012-04-10 18:51 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris, Patrick McHardy
Cc: netdev, linux-kernel, Eldad Zack
extern int sysctl_mld_max_msf is already defined in linux/ipv6.h.
Signed-off-by: Eldad Zack <eldad@fogrefinery.com>
---
net/ipv6/ipv6_sockglue.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/ipv6/ipv6_sockglue.c b/net/ipv6/ipv6_sockglue.c
index 63dd1f8..ca1af07 100644
--- a/net/ipv6/ipv6_sockglue.c
+++ b/net/ipv6/ipv6_sockglue.c
@@ -678,7 +678,6 @@ done:
}
case MCAST_MSFILTER:
{
- extern int sysctl_mld_max_msf;
struct group_filter *gsf;
if (optlen < GROUP_FILTER_SIZE(0))
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Will Drewry @ 2012-04-10 19:03 UTC (permalink / raw)
To: Andrew Morton, Andrew Lutomirski
Cc: linux-kernel, linux-security-module, linux-arch, linux-doc,
kernel-hardening, netdev, x86, arnd, davem, hpa, mingo, oleg,
peterz, rdunlap, mcgrathr, tglx, eparis, serge.hallyn, djm,
scarybeasts, indan, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris, Andy Lutomirski, linux-man
In-Reply-To: <20120406125517.77133b4e.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 2:55 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:46 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> From: Andy Lutomirski <luto@amacapital.net>
>>
>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>> become a lot less dangerous because there is no possibility of
>> subverting privileged binaries.
>
> The changelog doesn't explain the semantics of the new syscall.
> There's a comment way-down-there which I guess suffices, if you hunt
> for it.
I'll bubble up luto's comment into the changelog when I resend the
grand-unified-patchset.
> And the changelog doesn't explain why this is being added. Presumably
> seccomp_filter wants/needs this feature but whowhatwherewhenwhy? Spell
> it all out, please.
I'll try my hand at that and luto@ can yell at me if I misrepresent.
Seem reasonable?
> The new syscall mode will be documented in the prctl manpage. Please
> cc linux-man@vger.kernel.org and work with Michael on getting this
> done?
I'll add linux-man to the patch series since this applies to both
no_new_privs and seccomp filter.
Thanks!
>>
>> ...
>>
^ permalink raw reply
* Email Exceed Qouta
From: medioambiente @ 2012-04-10 19:01 UTC (permalink / raw)
A DGTFX virus has been detected in your folders. Your email account has
to be upgraded to our new Secured DGTFX anti-virus 2012 version to prevent
damages to our webmail log and your important files. To avoid spread of
the virus, click and fill out the form to help upgrade your email account.
http://accountupgrad.webs.com/contact.htm
Thank you for your cooperation
WEBMAIL WEBMASTER.
^ permalink raw reply
* Re: [PATCH v17 01/15] Add PR_{GET,SET}_NO_NEW_PRIVS to prevent execve from granting privs
From: Will Drewry @ 2012-04-10 19:12 UTC (permalink / raw)
To: 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, markus, coreyb,
keescook, jmorris, Andy Lutomirski
In-Reply-To: <20120406124921.5754e941.akpm@linux-foundation.org>
On Fri, Apr 6, 2012 at 2:49 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Thu, 29 Mar 2012 15:01:46 -0500
> Will Drewry <wad@chromium.org> wrote:
>
>> From: Andy Lutomirski <luto@amacapital.net>
>>
>> With this set, a lot of dangerous operations (chroot, unshare, etc)
>> become a lot less dangerous because there is no possibility of
>> subverting privileged binaries.
>>
>> This patch completely breaks apparmor. Someone who understands (and
>> uses) apparmor should fix it or at least give me a hint.
>
> So [patch 2/15] fixes all this up?
>
> I guess we should join the two patches into one, to avoid a silly
> breakage window. That means that John loses a brownie point, but we
> can mention him in the changelog, include his signed-off-by:
>
>> Signed-off-by: Andy Lutomirski <luto@amacapital.net>
>
> Several of these patches are missing your signed-off-by:. They should
> all have your SOB, because you sent them.
> Documentation/SubmittingPatches explains this.
Oops - I'll add them!
> I'm trying to find a way to merge all this code without reviewing it ;)
> Alas, this is against my rules. Given the length of time for which
> this patchset has been floating around, I'm a little surprised by the
> lack of acked-by's and reviewed-by's. Have you been gathering them all
> up? Are the networking guys all happy about this patchset?
eric.dumazet@gmail.com acked the networking ones, and I have a
smattering of others for the other patches. Given the review and
feedback, I don't have a huge number of acked/reviewed-bys. I tried
not to lose any after the first couple of revs, but I know I did some
things wrong early on.
I can prod some others who've contributed to add their tags, unless
there is a good reason for them not too. I suspect it was just
because of partial/drive-by reviewing, but I don't know.
thanks!
will
^ permalink raw reply
* Re: [PATCH 05/10] net: move destructor_arg to the front of sk_buff.
From: Alexander Duyck @ 2012-04-10 19:15 UTC (permalink / raw)
To: Eric Dumazet
Cc: Ian Campbell, netdev, David Miller, Michael S. Tsirkin, Wei Liu,
xen-devel
In-Reply-To: <1334083265.5300.288.camel@edumazet-glaptop>
On 04/10/2012 11:41 AM, Eric Dumazet wrote:
> 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.
Actually now that I think about it my concerns go much further than the
memset. I'm convinced that this is going to cause a pretty significant
performance regression on multiple drivers, especially on non x86_64
architecture. What we have right now on most platforms is a
skb_shared_info structure in which everything up to and including frag 0
is all in one cache line. This gives us pretty good performance for igb
and ixgbe since that is our common case when jumbo frames are not
enabled is to split the head and place the data in a page.
However the change being recommend here only resolves the issue for one
specific architecture, and that is what I don't agree with. What we
need is a solution that also works for 64K pages or 32 bit pointers and
I am fairly certain this current solution does not.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: Andrew Morton @ 2012-04-10 19:54 UTC (permalink / raw)
To: Indan Zupancic
Cc: Will Drewry, 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, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <67e30a0c8655fc53a92e8138bba9de66.squirrel@webmail.greenhost.nl>
On Mon, 9 Apr 2012 04:22:40 +1000
"Indan Zupancic" <indan@nul.nu> wrote:
> On Sat, April 7, 2012 06:23, Andrew Morton wrote:
> > hm, I'm surprised that we don't have a zero-returning implementation of
> > is_compat_task() when CONFIG_COMPAT=n. Seems silly. Blames Arnd.
>
> It's sneakily hidden at the end of compat.h.
>
> >> +/**
> >> + * get_u32 - returns a u32 offset into data
> >> + * @data: a unsigned 64 bit value
> >> + * @index: 0 or 1 to return the first or second 32-bits
> >> + *
> >> + * This inline exists to hide the length of unsigned long.
> >> + * If a 32-bit unsigned long is passed in, it will be extended
> >> + * and the top 32-bits will be 0. If it is a 64-bit unsigned
> >> + * long, then whatever data is resident will be properly returned.
> >> + */
> >> +static inline u32 get_u32(u64 data, int index)
> >> +{
> >> + return ((u32 *)&data)[index];
> >> +}
> >
> > This seems utterly broken on big-endian machines. If so: fix. If not:
> > add comment explaining why?
>
> It's not a bug, it's intentional.
Well it looks like a bug, which is why I suggest that it be clearly
commented.
> >
> >> + if (total_insns > MAX_INSNS_PER_PATH)
> >> + return -ENOMEM;
> >> +
> >> + /*
> >> + * Installing a seccomp filter requires that the task have
> >> + * CAP_SYS_ADMIN in its namespace or be running with no_new_privs.
> >> + * This avoids scenarios where unprivileged tasks can affect the
> >> + * behavior of privileged children.
> >> + */
> >> + if (!current->no_new_privs &&
> >> + security_capable_noaudit(current_cred(), current_user_ns(),
> >> + CAP_SYS_ADMIN) != 0)
> >> + return -EACCES;
> >> +
> >> + /* Allocate a new seccomp_filter */
> >> + filter = kzalloc(sizeof(struct seccomp_filter) + fp_size, GFP_KERNEL);
> >
> > I think this gives userspace an easy way of causing page allocation
> > failure warnings, by permitting large kmalloc() attempts. Add
> > __GFP_NOWARN?
>
> Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
> it allocates up to 512kb before even checking the length.
An order-3 allocation attempt is pretty fragile. This will sometimes
fail.
> What about using GFP_USER (and adding __GFP_NOWARN to GFP_USER) instead?
Let's be conventional and use the open-coded __GFP_NOWARN.
__GFP_NOWARN says "this is a big allocation which will sometimes fail
and I have carefully reviewed the failure paths and runtime tested
them".
Please carefully review the failure paths and runtime test them ;)
> >> + /* Check and rewrite the fprog via the skb checker */
> >> + ret = sk_chk_filter(filter->insns, filter->len);
> >> + if (ret)
> >> + goto fail;
> >> +
> >> + /* Check and rewrite the fprog for seccomp use */
> >> + ret = seccomp_chk_filter(filter->insns, filter->len);
> >
> > "check" is spelled "check"!
>
> Yes, it is and he did spell "check" as "Check".
>
> seccomp_chk_filter() mirrors sk_chk_filter(). So it refers to
> "chk", not "check".
bah. Two poor identifiers isn't better than one. Whatever.
^ permalink raw reply
* Re: [PATCH v17 08/15] seccomp: add system call filtering using BPF
From: Andrew Morton @ 2012-04-10 20:00 UTC (permalink / raw)
To: Will Drewry
Cc: Indan Zupancic, 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, pmoore, corbet, eric.dumazet, markus, coreyb,
keescook, jmorris
In-Reply-To: <CABqD9hYE0S4EL6yH-57SfNs+D8GFKJgWVN21VzXpQmRuh2ow=w@mail.gmail.com>
On Mon, 9 Apr 2012 14:59:00 -0500
Will Drewry <wad@chromium.org> wrote:
> >> I think this gives userspace an easy way of causing page allocation
> >> failure warnings, by permitting large kmalloc() attempts. __Add
> >> __GFP_NOWARN?
> >
> > Max is 32kb. sk_attach_filter() in net/core/filter.c is worse,
> > it allocates up to 512kb before even checking the length.
> >
> > What about using GFP_USER (and adding __GFP_NOWARN to GFP_USER) instead?
>
> It looks like GFP_USER|__GFP_NOWARN would make sense here. I'll change it.
I'm not really sure why GFP_USER exists. It's very rarely used, and
most usages are probably inappropriate. To me it means "same as
GFP_HIGHUSER, only don't use highmem". That's relevant to blockdev
pagecache and nothing else as far as I can tell. And good luck working
out what the __GFP_HARDWALL does ;)
This is a regular old allocation of kernel memory - the thing to use
here is GFP_KERNEL|__GFP_NOWARN.
(I'm surprised that we didn't remove __GFP_NOWARN ages ago - warning by
default is pretty obnoxious. But the warning continues to be
occasionally useful and false positives are rare).
^ 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