* Re: [PATCH net-next v4 0/3] path mtu hardening patches
From: Hannes Frederic Sowa @ 2014-01-13 21:28 UTC (permalink / raw)
To: John Heffner
Cc: David Miller, Netdev, Eric Dumazet, steffen.klassert, fweimer
In-Reply-To: <CABrhC0=9ff8aLG4y4gxiGrGBBHvdcWD2pCC3wyLTveKHRySg4A@mail.gmail.com>
On Mon, Jan 13, 2014 at 04:08:22PM -0500, John Heffner wrote:
> On Mon, Jan 13, 2014 at 3:42 PM, Hannes Frederic Sowa
> <hannes@stressinduktion.org> wrote:
> > On Mon, Jan 13, 2014 at 02:35:31PM -0500, John Heffner wrote:
> >> My only comment would be not to look to me as the only source of
> >> reason not to include this change. I've been largely disconnected
> >> from Linux development for several years and don't have time to get
> >> into a protracted discussion on this topic.
> >>
> >> FWIW, I still have doubts as to whether this is the best approach to
> >> solving the underlying problem. I still haven't heard any reason why
> >> firewall rules and other administrative best practices, such as using
> >
> > Because we currently cannot easily filter icmp payloads and check whether
> > it is in a response for a local socket or a malicious one.
> >
> >> separate management and forwarding interfaces on a router, don't
> >> practically solve this problem.
> >
> > I don't think this is practiable, especially in times of small devices
> > doing routing (e.g. smartphones).
> >
> >> I'd also be curious to hear what
> >> dedicated routing operating systems do, and why I haven't heard about
> >> widespread fragmentation DoS attacks.
> >
> > My old Cisco didn't honour those pmtu packets (at least in default
> > configuration) and FreeBSD only accepts pmtu information for TCP sockets
> > where it also verifies the sequence number. It does not react to pmtu
> > notifications in response to icmp or udp payloads.
> >
> > Routing path does use the pmtu values on FreeBSD, though. But it is much
> > harder to inject path mtu packets there because, as said, they are only
> > accepted for tcp.
>
> Would it be sufficient to allow Linux to be configured in a way that
> matches FreeBSD's behavior? (I believe you can do this easily with
> stateful firewall rules now, or possibly in the ICMP processing code
> with a sysctl switch.) I feel this would be a much cleaner approach.
Actually, this is part of this series. The hardened path mtu mode provides
exactly that (Patch 3).
But because we cannot switch this on by default, I also protected the
forwarding path. UDP path mtu discovery has been too long available on
Linux and, I guess, a lot of applications, especially running on routers,
depend on that.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: Tom Herbert @ 2014-01-13 21:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1389644256.31367.223.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Jan 13, 2014 at 12:17 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2014-01-13 at 11:59 -0800, David Miller wrote:
>
>> It also doesn't jive well with Eric's recent patch to adjust the GRO
>> overflow strategy (600adc18eba823f9fd8ed5fec8b04f11dddf3884 ("net:
>> gro: change GRO overflow strategy"))
>>
>> :-)
>>
>> I sort of like Tom's idea to optimistically compare the hash, if we
>> do in fact have one already.
>>
>> Eric would the change be OK if Tom did it that way?
>> --
>
> Yes this is what I suggested, but it seems Tom had something different
> in mind.
>
I will add skb_get_hash_noeval
> I would rather not call flow dissector from GRO, especially considering
> nobody but Google uses RPS/RFS (otherwise CVE-2013-4348 would have been
> discovered much sooner)
Or maybe nobody uses IPIP. ;-)
>
>
>
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] path mtu hardening patches
From: John Heffner @ 2014-01-13 21:08 UTC (permalink / raw)
To: John Heffner, David Miller, Netdev, Eric Dumazet,
steffen.klassert, fweimer
In-Reply-To: <20140113204253.GI6586@order.stressinduktion.org>
On Mon, Jan 13, 2014 at 3:42 PM, Hannes Frederic Sowa
<hannes@stressinduktion.org> wrote:
> On Mon, Jan 13, 2014 at 02:35:31PM -0500, John Heffner wrote:
>> My only comment would be not to look to me as the only source of
>> reason not to include this change. I've been largely disconnected
>> from Linux development for several years and don't have time to get
>> into a protracted discussion on this topic.
>>
>> FWIW, I still have doubts as to whether this is the best approach to
>> solving the underlying problem. I still haven't heard any reason why
>> firewall rules and other administrative best practices, such as using
>
> Because we currently cannot easily filter icmp payloads and check whether
> it is in a response for a local socket or a malicious one.
>
>> separate management and forwarding interfaces on a router, don't
>> practically solve this problem.
>
> I don't think this is practiable, especially in times of small devices
> doing routing (e.g. smartphones).
>
>> I'd also be curious to hear what
>> dedicated routing operating systems do, and why I haven't heard about
>> widespread fragmentation DoS attacks.
>
> My old Cisco didn't honour those pmtu packets (at least in default
> configuration) and FreeBSD only accepts pmtu information for TCP sockets
> where it also verifies the sequence number. It does not react to pmtu
> notifications in response to icmp or udp payloads.
>
> Routing path does use the pmtu values on FreeBSD, though. But it is much
> harder to inject path mtu packets there because, as said, they are only
> accepted for tcp.
Would it be sufficient to allow Linux to be configured in a way that
matches FreeBSD's behavior? (I believe you can do this easily with
stateful firewall rules now, or possibly in the ICMP processing code
with a sysctl switch.) I feel this would be a much cleaner approach.
Thanks,
-John
^ permalink raw reply
* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: Ben Hutchings @ 2014-01-13 20:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, therbert, netdev
In-Reply-To: <1389644256.31367.223.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, 2014-01-13 at 12:17 -0800, Eric Dumazet wrote:
> On Mon, 2014-01-13 at 11:59 -0800, David Miller wrote:
>
> > It also doesn't jive well with Eric's recent patch to adjust the GRO
> > overflow strategy (600adc18eba823f9fd8ed5fec8b04f11dddf3884 ("net:
> > gro: change GRO overflow strategy"))
> >
> > :-)
> >
> > I sort of like Tom's idea to optimistically compare the hash, if we
> > do in fact have one already.
> >
> > Eric would the change be OK if Tom did it that way?
> > --
>
> Yes this is what I suggested, but it seems Tom had something different
> in mind.
>
> I would rather not call flow dissector from GRO, especially considering
> nobody but Google uses RPS/RFS (otherwise CVE-2013-4348 would have been
> discovered much sooner)
According to the original report of that vulnerability:
> skb_flow_dissect() were used by several places:
> - packet scheduler that want classify flows
> - skb_get_rxhash() that will be used by RPS, vxlan, multiqueue
> tap,macvtap packet fanout
> - skb_probe_transport_header() which was used for probing transport
> header for DODGY packets
> - __skb_get_poff() which will be used by socket filter
So flow dissector is already part of the attack surface for both local
and remote users in common configurations.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] path mtu hardening patches
From: Hannes Frederic Sowa @ 2014-01-13 20:42 UTC (permalink / raw)
To: John Heffner
Cc: David Miller, Netdev, Eric Dumazet, steffen.klassert, fweimer
In-Reply-To: <CABrhC0n2AgHNQg-2nQk-sx1=k2=TvmGa+2seqoNT=XyDdz59yg@mail.gmail.com>
On Mon, Jan 13, 2014 at 02:35:31PM -0500, John Heffner wrote:
> On Mon, Jan 13, 2014 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
> > From: hannes@stressinduktion.org
> > Date: Thu, 9 Jan 2014 10:01:14 +0100
> >
> >> After a lot of back and forth I want to propose these changes regarding
> >> path mtu hardening and give an outline why I think this is the best way
> >> how to proceed:
> >
> > I'm not going to fight this any more even though I still disagree with
> > these changes. John Heffner has not provided a coherent strong
> > argument for not doing this, in fact the counter arguments were
> > extremely vague.
> >
> > I am pretty sure that now my worst fears will be realized and every
> > single distribution will not use the kernel's default, and everyone
> > will get this behavior rather than adminstrators making well informed
> > decisions about how to defend against these kind of situations when
> > enabling routing, or whether they'd even be exposed to the issue at
> > all in a particular setup.
> >
> > Such is life.
:/
> My only comment would be not to look to me as the only source of
> reason not to include this change. I've been largely disconnected
> from Linux development for several years and don't have time to get
> into a protracted discussion on this topic.
>
> FWIW, I still have doubts as to whether this is the best approach to
> solving the underlying problem. I still haven't heard any reason why
> firewall rules and other administrative best practices, such as using
Because we currently cannot easily filter icmp payloads and check whether
it is in a response for a local socket or a malicious one.
> separate management and forwarding interfaces on a router, don't
> practically solve this problem.
I don't think this is practiable, especially in times of small devices
doing routing (e.g. smartphones).
> I'd also be curious to hear what
> dedicated routing operating systems do, and why I haven't heard about
> widespread fragmentation DoS attacks.
My old Cisco didn't honour those pmtu packets (at least in default
configuration) and FreeBSD only accepts pmtu information for TCP sockets
where it also verifies the sequence number. It does not react to pmtu
notifications in response to icmp or udp payloads.
Routing path does use the pmtu values on FreeBSD, though. But it is much
harder to inject path mtu packets there because, as said, they are only
accepted for tcp.
> That said, this probably won't deeply break anything, but adds yet
> more complexity in the core of the network stack...
Actually I feel a bit emberrased how these changes went in. At first I
thought they wouldn't be that much of a problem. I'll try to improve my
communiation skills and try to listen more carefully.
Thank you, David and John!
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: Eric Dumazet @ 2014-01-13 20:17 UTC (permalink / raw)
To: David Miller; +Cc: therbert, netdev
In-Reply-To: <20140113.115913.1269834557058575064.davem@davemloft.net>
On Mon, 2014-01-13 at 11:59 -0800, David Miller wrote:
> It also doesn't jive well with Eric's recent patch to adjust the GRO
> overflow strategy (600adc18eba823f9fd8ed5fec8b04f11dddf3884 ("net:
> gro: change GRO overflow strategy"))
>
> :-)
>
> I sort of like Tom's idea to optimistically compare the hash, if we
> do in fact have one already.
>
> Eric would the change be OK if Tom did it that way?
> --
Yes this is what I suggested, but it seems Tom had something different
in mind.
I would rather not call flow dissector from GRO, especially considering
nobody but Google uses RPS/RFS (otherwise CVE-2013-4348 would have been
discovered much sooner)
^ permalink raw reply
* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: Tom Herbert @ 2014-01-13 20:13 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, Linux Netdev List
In-Reply-To: <20140113.115913.1269834557058575064.davem@davemloft.net>
On Mon, Jan 13, 2014 at 11:59 AM, David Miller <davem@davemloft.net> wrote:
> From: Tom Herbert <therbert@google.com>
> Date: Fri, 10 Jan 2014 08:27:20 -0800
>
>> On Thu, Jan 9, 2014 at 9:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>>> On Thu, 2014-01-09 at 20:54 -0800, Tom Herbert wrote:
>>>> When initializing a gro_list for a packet, first check the rxhash of
>>>> the incoming skb against that of the skb's in the list. This should be
>>>> a very strong inidicator of whether the flow is going to be matched,
>>>> and potentially allows a lot of other checks to be short circuited.
>>>>
>>>
>>> Hmm... this idea was discussed in the past. I used it when attempting to
>>> use a hash table instead of a gro_list last year.
>>>
>>> Unfortunately this added lot of cycles when rxhash is not provided by
>>> hardware, and my tests found it was not a win.
>>>
>>> Remember : in most cases, gro_list contains one flow, so this test does
>>> nothing special but adds overhead.
>>
>> I don't understand what your basis is that gro_list in most cases
>> contains one flow
>
> It also doesn't jive well with Eric's recent patch to adjust the GRO
> overflow strategy (600adc18eba823f9fd8ed5fec8b04f11dddf3884 ("net:
> gro: change GRO overflow strategy"))
>
> :-)
>
> I sort of like Tom's idea to optimistically compare the hash, if we
> do in fact have one already.
>
> Eric would the change be OK if Tom did it that way?
btw, I'm also looking at "if ((a ^ b) | (c ^ d)...)" versus "if ((a !=
b) || (c != d)...)". There's a pretty small number of functions that
use this trick. In isolating one for testing, I really don't see the
^ | method as being much of win, even with a modest amount of branch
correct branch prediction || can be better, if we can get mostly
correct branch prediction it can be significantly better. Before I fix
this, is there any background I should know about? :-)
Tom
^ permalink raw reply
* Re: [PATCH net-next] l2tp: make local functions static
From: David Miller @ 2014-01-13 20:01 UTC (permalink / raw)
To: stephen; +Cc: jchapman, netdev
In-Reply-To: <20140109222227.3b3b5776@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 9 Jan 2014 22:22:27 -0800
> Avoid needless export of local functions
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: namespace and dead code cleanups
From: David Miller @ 2014-01-13 20:00 UTC (permalink / raw)
To: stephen; +Cc: ariele, netdev
In-Reply-To: <20140109222011.59eb4ff1@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Thu, 9 Jan 2014 22:20:11 -0800
> Fix a bunch of whole lot of namespace issues with the Broadcom bnx2x driver
> found by running 'make namespacecheck'
>
> * global variables must be prefixed with bnx2x_
> naming a variable int_mode, or num_queue is invitation to disaster
>
> * make local functions static
>
> * move some inline's used in one file out of header
> (this driver has a bad case of inline-itis)
>
> * remove resulting dead code fallout
> bnx2x_pfc_statistic,
> bnx2x_emac_get_pfc_stat
> bnx2x_init_vlan_mac_obj,
> Looks like vlan mac support in this driver was a botch from day one
> either never worked, or not implemented or missing support functions
>
> Compile tested only.
>
> Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Applied.
^ permalink raw reply
* Re: [PATCH] net: Check skb->rxhash in gro_receive
From: David Miller @ 2014-01-13 19:59 UTC (permalink / raw)
To: therbert; +Cc: eric.dumazet, netdev
In-Reply-To: <CA+mtBx_c=we-13b0Vyrim0=kArhx0OYY1P99HwUeuR2w87hRFw@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Fri, 10 Jan 2014 08:27:20 -0800
> On Thu, Jan 9, 2014 at 9:38 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Thu, 2014-01-09 at 20:54 -0800, Tom Herbert wrote:
>>> When initializing a gro_list for a packet, first check the rxhash of
>>> the incoming skb against that of the skb's in the list. This should be
>>> a very strong inidicator of whether the flow is going to be matched,
>>> and potentially allows a lot of other checks to be short circuited.
>>>
>>
>> Hmm... this idea was discussed in the past. I used it when attempting to
>> use a hash table instead of a gro_list last year.
>>
>> Unfortunately this added lot of cycles when rxhash is not provided by
>> hardware, and my tests found it was not a win.
>>
>> Remember : in most cases, gro_list contains one flow, so this test does
>> nothing special but adds overhead.
>
> I don't understand what your basis is that gro_list in most cases
> contains one flow
It also doesn't jive well with Eric's recent patch to adjust the GRO
overflow strategy (600adc18eba823f9fd8ed5fec8b04f11dddf3884 ("net:
gro: change GRO overflow strategy"))
:-)
I sort of like Tom's idea to optimistically compare the hash, if we
do in fact have one already.
Eric would the change be OK if Tom did it that way?
^ permalink raw reply
* Re: [PATCH 1/1] drivers: net: silence compiler warning in smc91x.c
From: David Miller @ 2014-01-13 19:54 UTC (permalink / raw)
To: sergei.shtylyov
Cc: pankaj.dubey, linux-samsung-soc, linux-arm-kernel, jg1.han,
netdev
In-Reply-To: <52D05B41.7000601@cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Fri, 10 Jan 2014 23:42:41 +0300
> Hello.
>
> On 01/10/2014 06:04 AM, Pankaj Dubey wrote:
>
>> If used 64 bit compiler GCC warns that:
>
>> drivers/net/ethernet/smsc/smc91x.c:1897:7:
>> warning: cast from pointer to integer of different
>> size [-Wpointer-to-int-cast]
>
>> This patch fixes this by changing typecase from "unsigned int" to
>> "unsigned long"
>
> Only "typecast".
Applied with this typo fixed, thanks.
^ permalink raw reply
* Re: [PATCH net-next] gre_offload: simplify GRE header length calculation in gre_gso_segment()
From: David Miller @ 2014-01-13 19:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: ncardwell, netdev, edumazet, hkchu, pshelar
In-Reply-To: <1389319758.31367.81.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 09 Jan 2014 18:09:18 -0800
> On Thu, 2014-01-09 at 20:47 -0500, Neal Cardwell wrote:
>> Simplify the GRE header length calculation in gre_gso_segment().
>> Switch to an approach that is simpler, faster, and more general. The
>> new approach will continue to be correct even if we add support for
>> the optional variable-length routing info that may be present in a GRE
>> header.
>>
>> Signed-off-by: Neal Cardwell <ncardwell@google.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> Cc: H.K. Jerry Chu <hkchu@google.com>
>> Cc: Pravin B Shelar <pshelar@nicira.com>
>> ---
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied, thank you.
^ permalink raw reply
* Re: [Patch net-next 6/7] net_sched: cls: move allocation in ->init to generic layer
From: David Miller @ 2014-01-13 19:49 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev, tgraf, jhs
In-Reply-To: <1389312845-10304-7-git-send-email-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 9 Jan 2014 16:14:04 -0800
> + if (!head->init) {
> head->handle = handle;
> -
> - tcf_tree_lock(tp);
> - tp->root = head;
> - tcf_tree_unlock(tp);
> + head->init = true;
...
> head->mask = mask;
> -
> - tcf_tree_lock(tp);
> - tp->root = head;
> - tcf_tree_unlock(tp);
> + head->init = true;
Like Jamal, I don't think these transformations are valid.
You can't make the root visible in the hierarchy until the
->handle and ->mask (respectively) members are initialized
in these two classifiers.
What I'm going to do for now is apply patches 1-5 and 7.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: gro: change GRO overflow strategy
From: David Miller @ 2014-01-13 19:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, hkchu
In-Reply-To: <1389305539.31367.65.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 09 Jan 2014 14:12:19 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> GRO layer has a limit of 8 flows being held in GRO list,
> for performance reason.
>
> When a packet comes for a flow not yet in the list,
> and list is full, we immediately give it to upper
> stacks, lowering aggregation performance.
>
> With TSO auto sizing and FQ packet scheduler, this situation
> happens more often.
>
> This patch changes strategy to simply evict the oldest flow of
> the list. This works better because of the nature of packet
> trains for which GRO is efficient. This also has the effect
> of lowering the GRO latency if many flows are competing.
>
> Tested :
>
> Used a 40Gbps NIC, with 4 RX queues, and 200 concurrent TCP_STREAM
> netperf.
>
> Before patch, aggregate rate is 11Gbps (while a single flow can reach
> 30Gbps)
>
> After patch, line rate is reached.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, looks great.
If someone is really concerned about improving the list traversal,
we can maintain a tail pointer.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx4_en: call gro handler for encapsulated frames
From: David Miller @ 2014-01-13 19:44 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, amirv, ogerlitz, hkchu
In-Reply-To: <1389292213.31367.49.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 09 Jan 2014 10:30:13 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> In order to use the native GRO handling of encapsulated protocols on
> mlx4, we need to call napi_gro_receive() instead of netif_receive_skb()
> unless busy polling is in action.
>
> While we are at it, rename mlx4_en_cq_ll_polling() to
> mlx4_en_cq_busy_polling()
>
> Tested with GRE tunnel : GRO aggregation is now performed on the
> ethernet device instead of being done later on gre device.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH v4 0/3] Send audit/procinfo/cgroup data in socket-level control message
From: Casey Schaufler @ 2014-01-13 19:44 UTC (permalink / raw)
To: Jan Kaluza, davem
Cc: LKML, netdev, eparis, rgb, tj, lizefan, containers, cgroups, viro
In-Reply-To: <1389600109-30739-1-git-send-email-jkaluza@redhat.com>
On 1/13/2014 12:01 AM, Jan Kaluza wrote:
> Hi,
>
> this patchset against net-next (applies also to linux-next) adds 3 new types
> of "Socket"-level control message (SCM_AUDIT, SCM_PROCINFO and SCM_CGROUP).
How about the group list, while you're at it?
>
> Server-like processes in many cases need credentials and other
> metadata of the peer, to decide if the calling process is allowed to
> request a specific action, or the server just wants to log away this
> type of information for auditing tasks.
>
> The current practice to retrieve such process metadata is to look that
> information up in procfs with the $PID received over SCM_CREDENTIALS.
> This is sufficient for long-running tasks, but introduces a race which
> cannot be worked around for short-living processes; the calling
> process and all the information in /proc/$PID/ is gone before the
> receiver of the socket message can look it up.
>
> Changes introduced in this patchset can also increase performance
> of such server-like processes, because current way of opening and
> parsing /proc/$PID/* files is much more expensive than receiving these
> metadata using SCM.
>
> Changes in v4:
> - Rebased to work with the latest net-next tree
>
> Changes in v3:
> - Better description of patches (Thanks to Kay Sievers)
>
> Changes in v2:
> - use PATH_MAX instead of PAGE_SIZE in SCM_CGROUP patch
> - describe each patch individually
>
> Jan Kaluza (3):
> Send loginuid and sessionid in SCM_AUDIT
> Send comm and cmdline in SCM_PROCINFO
> Send cgroup_path in SCM_CGROUP
>
> include/linux/socket.h | 9 ++++++
> include/net/af_unix.h | 10 ++++++
> include/net/scm.h | 67 ++++++++++++++++++++++++++++++++++++++--
> net/core/scm.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++++++
> net/unix/af_unix.c | 70 ++++++++++++++++++++++++++++++++++++++++++
> 5 files changed, 237 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: [PATCH net-next 3/4] flowcache: Fixup flow cache part in xfrm policy
From: Cong Wang @ 2014-01-13 19:42 UTC (permalink / raw)
To: Fan Du; +Cc: steffen.klassert, David Miller, netdev
In-Reply-To: <1389599348-5214-4-git-send-email-fan.du@windriver.com>
On Sun, Jan 12, 2014 at 11:49 PM, Fan Du <fan.du@windriver.com> wrote:
> void xfrm_garbage_collect(struct net *net)
> {
> - flow_cache_flush();
> + flow_cache_flush(net);
> __xfrm_garbage_collect(net);
> }
> EXPORT_SYMBOL(xfrm_garbage_collect);
>
> static void xfrm_garbage_collect_deferred(struct net *net)
> {
> - flow_cache_flush_deferred();
> + flow_cache_flush_deferred(net);
> __xfrm_garbage_collect(net);
> }
>
You changed the prototypes of flow_cache_flush*() in the previous
patch, so, here you break bisect. They have to be in one commit.
^ permalink raw reply
* Re: [PATCH -next] gre_offload: fix sparse non static symbol warning
From: David Miller @ 2014-01-13 19:38 UTC (permalink / raw)
To: weiyj.lk; +Cc: xeb, kuznet, jmorris, yoshfuji, kaber, yongjun_wei, netdev
In-Reply-To: <CAPgLHd_s+M1XkL+Bf-Zd8CtOyt0aaOaNLRevO2JK=oX8zunR4Q@mail.gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Thu, 9 Jan 2014 22:22:05 +0800
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Fixes the following sparse warning:
>
> net/ipv4/gre_offload.c:253:5: warning:
> symbol 'gre_gro_complete' was not declared. Should it be static?
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] xprtrdma: silence frame size warning
From: Paul Bolle @ 2014-01-13 19:35 UTC (permalink / raw)
To: Chuck Lever
Cc: Trond Myklebust, J. Bruce Fields, Miller David S.,
Linux NFS Mailing List, netdev-u79uwXL29TY76Z2rM5mHXA,
LKML Kernel
In-Reply-To: <D3560A1A-59B3-4480-8627-9114A4B9895C-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
On Mon, 2014-01-13 at 11:17 -0500, Chuck Lever wrote:
> I’m building a queue of NFS/RDMA work on bugzilla.kernel.org. Let’s
> create a defect report there to document this, and it will get
> prioritized with the rest. Paul, can you do that to start us off?
> Product “File system”, Component “NFS”.
Sure, see https://bugzilla.kernel.org/show_bug.cgi?id=68661 . Please
feel free to edit the bug's title, etc, as you see fit.
> I can’t say that a warning on 32-bit x86 is going to be an especially
> high priority.
I see. 32-bit x86 seems to be dropping in relevance quite fast.
On the other hand, this is one of the last warnings I see when currently
building x86 (32-bit, that is) and it would be rather nice to see this
warning gone. Since my .config is basically a Fedora 20 .config, that
would help make Fedora's 32-bit x86 build (almost) warning free too.
> However, the underlying issue of allocating arrays of data segments on
> the stack is something that needs extended attention, and is already
> in plan.
Thanks,
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [patch net-next] neigh: use NEIGH_VAR_INIT in ndo_neigh_setup functions.
From: David Miller @ 2014-01-13 19:35 UTC (permalink / raw)
To: jiri; +Cc: netdev, jes
In-Reply-To: <1389273227-17532-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Thu, 9 Jan 2014 14:13:47 +0100
> When ndo_neigh_setup is called, the bitfield used by NEIGH_VAR_SET is
> not initialized yet. This might cause confusion for the people who use
> NEIGH_VAR_SET in ndo_neigh_setup. So rather introduce NEIGH_VAR_INIT for
> usage in ndo_neigh_setup.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Wouldn't it be better to move the neigh_parms_data_state_cleanall() call
before we invoke ->ndo_neigh_setup()? It seems that this code intended
to work that way, no?
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] path mtu hardening patches
From: John Heffner @ 2014-01-13 19:35 UTC (permalink / raw)
To: David Miller; +Cc: hannes, Netdev, Eric Dumazet, steffen.klassert, fweimer
In-Reply-To: <20140113.112504.922587457597727366.davem@davemloft.net>
On Mon, Jan 13, 2014 at 2:25 PM, David Miller <davem@davemloft.net> wrote:
> From: hannes@stressinduktion.org
> Date: Thu, 9 Jan 2014 10:01:14 +0100
>
>> After a lot of back and forth I want to propose these changes regarding
>> path mtu hardening and give an outline why I think this is the best way
>> how to proceed:
>
> I'm not going to fight this any more even though I still disagree with
> these changes. John Heffner has not provided a coherent strong
> argument for not doing this, in fact the counter arguments were
> extremely vague.
>
> I am pretty sure that now my worst fears will be realized and every
> single distribution will not use the kernel's default, and everyone
> will get this behavior rather than adminstrators making well informed
> decisions about how to defend against these kind of situations when
> enabling routing, or whether they'd even be exposed to the issue at
> all in a particular setup.
>
> Such is life.
My only comment would be not to look to me as the only source of
reason not to include this change. I've been largely disconnected
from Linux development for several years and don't have time to get
into a protracted discussion on this topic.
FWIW, I still have doubts as to whether this is the best approach to
solving the underlying problem. I still haven't heard any reason why
firewall rules and other administrative best practices, such as using
separate management and forwarding interfaces on a router, don't
practically solve this problem. I'd also be curious to hear what
dedicated routing operating systems do, and why I haven't heard about
widespread fragmentation DoS attacks.
That said, this probably won't deeply break anything, but adds yet
more complexity in the core of the network stack...
-John
^ permalink raw reply
* Re: suspicious RCU usage in net/ipv4/ip_tunnel.c:80
From: Cong Wang @ 2014-01-13 19:35 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, netdev
In-Reply-To: <1389403281.31367.171.camel@edumazet-glaptop2.roam.corp.google.com>
On Fri, Jan 10, 2014 at 5:21 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Please use following sparse ready patch, thanks :
>
> diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
> index d3929a69f008..6eda759b5c4b 100644
> --- a/net/ipv4/ip_tunnel.c
> +++ b/net/ipv4/ip_tunnel.c
> @@ -77,10 +77,11 @@ static inline void __tunnel_dst_set(struct ip_tunnel_dst *idst,
> dst = NULL;
>
> spin_lock_bh(&idst->lock);
> - old_dst = rcu_dereference(idst->dst);
> + old_dst = rcu_dereference_protected(idst->dst,
> + lockdep_is_held(&idst->lock));
> rcu_assign_pointer(idst->dst, dst);
> - dst_release(old_dst);
> spin_unlock_bh(&idst->lock);
> + dst_release(old_dst);
> }
>
> static inline void tunnel_dst_set(struct ip_tunnel *t, struct dst_entry *dst)
>
>
Tested-by: Cong Wang <cwang@twopensource.com>
^ permalink raw reply
* Re: net/mlx4_core: clean up two functions
From: Amir Vadai @ 2014-01-13 19:34 UTC (permalink / raw)
To: David Miller
Cc: pebolle, ogerlitz, jackm, ronye, hadarh, netdev, linux-kernel,
amirv
In-Reply-To: <20140113.111312.1323236808342705421.davem@davemloft.net>
On 13/01/14 11:13 -0800, David Miller wrote:
> From: Paul Bolle <pebolle@tiscali.nl>
> Date: Tue, 07 Jan 2014 14:00:22 +0100
>
> > 0) These two patches are very similar. They both clean up a function to
> > help GCC understand the codeflow. Both help silence a warning.
> >
> > 1) Compile tested only (on 32 bits x86). I do not have this hardware.
> >
> > 2) Please note that there's no MAINTAINERS entry for mlx4_core. (Neither
> > is there an entry for the MLX4 IB driver.) Shouldn't it be added?
>
> These patches have been rotting for a week. I know the mlx4 folks
> said the SRIOV guy inside Mellanox will look at it, but this is taking
> way too long.
>
> This is absolutely unreasonable from Paul's perspective to have to wait
> this long for a review of these relatively simple patches.
You're absolutely right.
And yes, jack is very busy.
We will have a reply ready tomorrow morning.
Amir
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] xen-netfront: use new skb_checksum_setup function
From: David Miller @ 2014-01-13 19:27 UTC (permalink / raw)
To: paul.durrant
Cc: netdev, xen-devel, konrad.wilk, boris.ostrovsky, david.vrabel
In-Reply-To: <1389261768-30606-4-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Thu, 9 Jan 2014 10:02:48 +0000
> Use skb_checksum_setup to set up partial checksum offsets rather
> then a private implementation.
>
> Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
This patch really needs review by a netfront expert before I can apply
this series.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] path mtu hardening patches
From: David Miller @ 2014-01-13 19:25 UTC (permalink / raw)
To: hannes; +Cc: netdev, eric.dumazet, johnwheffner, steffen.klassert, fweimer
In-Reply-To: <1389258077-23282-1-git-send-email-hannes@stressinduktion.org>
From: hannes@stressinduktion.org
Date: Thu, 9 Jan 2014 10:01:14 +0100
> After a lot of back and forth I want to propose these changes regarding
> path mtu hardening and give an outline why I think this is the best way
> how to proceed:
I'm not going to fight this any more even though I still disagree with
these changes. John Heffner has not provided a coherent strong
argument for not doing this, in fact the counter arguments were
extremely vague.
I am pretty sure that now my worst fears will be realized and every
single distribution will not use the kernel's default, and everyone
will get this behavior rather than adminstrators making well informed
decisions about how to defend against these kind of situations when
enabling routing, or whether they'd even be exposed to the issue at
all in a particular setup.
Such is life.
^ 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