* Re: [LARTC] LARTC mailing list
From: Niccolò Belli @ 2011-11-13 22:02 UTC (permalink / raw)
To: Linux Advanced Routing & Traffic Control project
Cc: Dave Taht, Andrew Beverley, linux-new-lists, netdev, netfilter,
Jan Engelhardt
In-Reply-To: <CAA93jw49j--DFrj-040ii6Tp4S3v=QVKzUS8ShtBf_dG9zAoRw@mail.gmail.com>
I think we should just create a new list called "LARTC", on
vger.kernel.org, hosted on my own servers or wherever you want.
The most important thing is trying to keep alive the community around it.
Niccolò
^ permalink raw reply
* Re: [patch 0/8 2.6.32] CVE-2010-4251: packet backlog can get too large
From: Ben Hutchings @ 2011-11-13 23:29 UTC (permalink / raw)
To: David Miller; +Cc: dan.carpenter, stable, greg, netdev, yi.zhu, eric.dumazet
In-Reply-To: <20111113.155851.2167389434844487922.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1884 bytes --]
On Sun, 2011-11-13 at 15:58 -0500, David Miller wrote:
> From: Dan Carpenter <dan.carpenter@oracle.com>
> Date: Sun, 13 Nov 2011 23:13:36 +0300
>
> > This patch series is to address CVE-2010-4251 for the 2.6.32 stable
> > kernel. Here is the CVE summary:
> >
> > "The socket implementation in net/core/sock.c in the Linux kernel
> > before 2.6.34 does not properly manage a backlog of received
> > packets, which allows remote attackers to cause a denial of service
> > (memory consumption) by sending a large amount of network traffic,
> > as demonstrated by netperf UDP tests."
> >
> > [patch 1/8] introduces sk_add_backlog_limited()
> > [patch 2-7/8] change each network protocol to use sk_add_backlog_limited()
> > where appropriate.
> > [patch 8/8] renames sk_add_backlog() to __sk_add_backlog() and
> > sk_add_backlog_limited() to sk_add_backlog().
> >
> > The patches mostly apply without changes. The exception is:
> > [patch 2/8] udp: use limited socket backlog
> > Then the rename [patch 8/8] needed to be changed as well to match.
>
> These changes are way too intrusive and potentially regression
> inducing for -stable inclusion, especially a kernel that is in such
> deep maintainence mode as 2.6.32 is.
Debian 6.0 based on Linux 2.6.32 has patches #1-7, except our backport
of #2 (for udp) looks a bit different.
Apparently several other distributions have also applied these.
> Also, I tend to personally submit networking -stable patches, so please
> do not bypass me in this manner and instead recommend such submissions
> on the netdev list so I can evaluate the request.
But you've previously said that you are not submitting networking
patches to the longterm series. Did you change your mind?
Ben.
--
Ben Hutchings
Never attribute to conspiracy what can adequately be explained by stupidity.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [LARTC] LARTC mailing list
From: Ben Hutchings @ 2011-11-14 0:44 UTC (permalink / raw)
To: Andrew Beverley
Cc: Benjamin Poirier,
Linux Advanced Routing & Traffic Control project,
linux-new-lists, netfilter, netdev
In-Reply-To: <1321220346.1965.10.camel@andybev-desktop>
On Sun, 2011-11-13 at 21:39 +0000, Andrew Beverley wrote:
> On Wed, 2011-11-02 at 13:54 -0400, Benjamin Poirier wrote:
> > On 11/10/22 15:10, Andrew Beverley wrote:
> > > On Sat, 2011-10-22 at 15:03 +0200, Niccolò Belli wrote:
> > > > Is someone still interested to bring LARTC to a new life?
> > > > I'm sorry for the subscription but the list didn't work anymore and it
> > > > was unfeasible to CC 30+ addresses. Let me know if you want to
> > > > unsubscribe and you don't know how to.
> > >
> > > Thanks for doing this Niccolo. However, I'd rather see it hosted at
> > > vger.kernel.org for all the reasons previously outlined.
> > >
> > > I was actually going to suggest a new list called net-users instead.
> > > There is netdev, netfilter-devel and netfilter, but not a general
> > > networking users list.
> >
> > Isn't that what linux-net@vger.kernel.org is/was supposed to be about?
>
> Hmmm, hadn't even come across that before.
>
> > Not sure what's its status, it's no longer listed on
> > http://vger.kernel.org/vger-lists.html, the last message I've received
> > on it was a month ago and it was mostly spam before that.
>
> Maybe not much interest for a users' list then...
I suggested to David to delete the linux-net list because it had very
low (legitimate) traffic and the people who could answer questions were
mostly subscribed only to netdev. And since he agreed, it's gone.
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-new-lists" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] brcmsmac: Use current logging styles
From: Stephen Hemminger @ 2011-11-14 1:08 UTC (permalink / raw)
To: Joe Perches
Cc: Arend van Spriel, John W. Linville, linux-wireless, netdev, LKML
In-Reply-To: <1321213264.15834.4.camel@Joe-Laptop>
On Sun, 13 Nov 2011 11:41:04 -0800
Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org> wrote:
> Add and use pr_fmt and pr_<level>
> Remove useless double parentheses from macros.
> Remove function names from format strings, add to pr_debug use.
> Coalesce formats.
> Remove uncompileable undeclared variable in a DMA_NONE use.
If you are going to change it why not got all the way to netdev_XXX and dev_XXX macros
instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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] brcmsmac: Use current logging styles
From: Joe Perches @ 2011-11-14 1:10 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Arend van Spriel, John W. Linville, linux-wireless, netdev, LKML
In-Reply-To: <20111113170825.6633b17e@nehalam.linuxnetplumber.net>
On Sun, 2011-11-13 at 17:08 -0800, Stephen Hemminger wrote:
> On Sun, 13 Nov 2011 11:41:04 -0800
> Joe Perches <joe@perches.com> wrote:
>
> > Add and use pr_fmt and pr_<level>
> > Remove useless double parentheses from macros.
> > Remove function names from format strings, add to pr_debug use.
> > Coalesce formats.
> > Remove uncompileable undeclared variable in a DMA_NONE use.
>
> If you are going to change it why not got all the way to netdev_XXX and dev_XXX macros
> instead.
No dev always available, simpler change,
mirrors the changes in brcmfmac.
^ permalink raw reply
* Re: [RFC] kvm tools: Implement multiple VQ for virtio-net
From: Asias He @ 2011-11-14 2:04 UTC (permalink / raw)
To: Sasha Levin
Cc: Michael S. Tsirkin, penberg, kvm, mingo, gorcunov, Krishna Kumar,
Rusty Russell, virtualization, netdev
In-Reply-To: <1321196430.2425.2.camel@sasha>
Hi, Shsha
On 11/13/2011 11:00 PM, Sasha Levin wrote:
> On Sun, 2011-11-13 at 12:24 +0200, Michael S. Tsirkin wrote:
>> On Sat, Nov 12, 2011 at 12:12:01AM +0200, Sasha Levin wrote:
>>> This is a patch based on Krishna Kumar's patch series which implements
>>> multiple VQ support for virtio-net.
>>>
>>> The patch was tested with ver3 of the patch.
>>>
>>> Cc: Krishna Kumar<krkumar2@in.ibm.com>
>>> Cc: Michael S. Tsirkin<mst@redhat.com>
>>> Cc: Rusty Russell<rusty@rustcorp.com.au>
>>> Cc: virtualization@lists.linux-foundation.org
>>> Cc: netdev@vger.kernel.org
>>> Signed-off-by: Sasha Levin<levinsasha928@gmail.com>
>>
>> Any performance numbers?
>
> I tried finding a box with more than two cores so I could test it on
> something like that as well.
>
>> From what I see this patch causes a performance regression on my 2 core
> box.
>
> I'll send an updated KVM tools patch in a bit as well.
>
> Before:
>
> # netperf -H 192.168.33.4,ipv4 -t TCP_RR
> MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
> to 192.168.33.4 (192.168.33.4) port 0 AF_INET : first burst 0
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 16384 87380 1 1 10.00 11160.63
> 16384 87380
>
> # netperf -H 192.168.33.4,ipv4 -t UDP_RR
> MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
> to 192.168.33.4 (192.168.33.4) port 0 AF_INET : first burst 0
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 122880 122880 1 1 10.00 12072.64
> 229376 229376
>
> # netperf -H 192.168.33.4,ipv4 -t TCP_STREAM
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.00 4654.50
>
> netperf -H 192.168.33.4,ipv4 -t TCP_STREAM -- -m 128
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 128 10.00 635.45
>
> # netperf -H 192.168.33.4,ipv4 -t UDP_STREAM
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 122880 65507 10.00 113894 0 5968.54
> 229376 10.00 89373 4683.54
>
> # netperf -H 192.168.33.4,ipv4 -t UDP_STREAM -- -m 128
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 122880 128 10.00 550634 0 56.38
> 229376 10.00 398786 40.84
>
>
> After:
>
> # netperf -H 192.168.33.4,ipv4 -t TCP_RR
> MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
> to 192.168.33.4 (192.168.33.4) port 0 AF_INET : first burst 0
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 16384 87380 1 1 10.00 8952.47
> 16384 87380
>
> # netperf -H 192.168.33.4,ipv4 -t UDP_RR
> MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET
> to 192.168.33.4 (192.168.33.4) port 0 AF_INET : first burst 0
> Local /Remote
> Socket Size Request Resp. Elapsed Trans.
> Send Recv Size Size Time Rate
> bytes Bytes bytes bytes secs. per sec
>
> 122880 122880 1 1 10.00 9534.52
> 229376 229376
>
> # netperf -H 192.168.33.4,ipv4 -t TCP_STREAM
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.13 2278.23
>
> # netperf -H 192.168.33.4,ipv4 -t TCP_STREAM -- -m 128
> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 128 10.00 623.27
>
> # netperf -H 192.168.33.4,ipv4 -t UDP_STREAM
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 122880 65507 10.00 136930 0 7175.72
> 229376 10.00 16726 876.51
>
> # netperf -H 192.168.33.4,ipv4 -t UDP_STREAM -- -m 128
> MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
> 192.168.33.4 (192.168.33.4) port 0 AF_INET
> Socket Message Elapsed Messages
> Size Size Time Okay Errors Throughput
> bytes bytes secs # # 10^6bits/sec
>
> 122880 128 10.00 982492 0 100.61
> 229376 10.00 249597 25.56
>
Why both the bandwidth and latency performance are dropping so
dramatically with multiple VQ?
--
Asias He
^ permalink raw reply
* Re: [patch 0/8 2.6.32] CVE-2010-4251: packet backlog can get too large
From: David Miller @ 2011-11-14 3:24 UTC (permalink / raw)
To: ben; +Cc: dan.carpenter, stable, greg, netdev, yi.zhu, eric.dumazet
In-Reply-To: <1321226949.3059.13.camel@deadeye>
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sun, 13 Nov 2011 23:29:09 +0000
> But you've previously said that you are not submitting networking
> patches to the longterm series. Did you change your mind?
No, I in fact haven't.
But I will say that if distributions want to apply this thing, that's
fine, but it doesn't automatically make it a good idea for -stable
to take it too.
^ permalink raw reply
* Re: [LARTC] LARTC mailing list
From: Jan Engelhardt @ 2011-11-14 4:30 UTC (permalink / raw)
To: Andrew Beverley
Cc: Linux Advanced Routing & Traffic Control project,
linux-new-lists, netfilter,
Linux Networking Developer Mailing List
In-Reply-To: <1321220521.1965.13.camel@andybev-desktop>
On Sunday 2011-11-13 22:42, Andrew Beverley wrote:
>>
>> Might as well just go to netfilter for now, it's not like as if the
>> traffic was as much as linux-kernel.
>
>[...] I was just conscious that there doesn't appear to be many "tc"
>experts.
Talk about blackboxes.
tc is like the selinux of networking.
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: reduce skb truesize by 50%
From: David Miller @ 2011-11-14 5:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: eilong, bhutchings, pstaszewski, netdev
In-Reply-To: <1321221657.17837.51.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 13 Nov 2011 23:00:57 +0100
> OK then we need using build_skb() for this driver :)
>
> http://lists.openwall.net/netdev/2011/07/11/19
>
> This way, we build the skb_shared_info content _after_ frame is
> delivered by device.
I fully support bringing this thing back to life :-)
^ permalink raw reply
* Re: [PATCH] net/packet: remove dead code and unneeded variable from prb_setup_retire_blk_timer()
From: David Miller @ 2011-11-14 5:09 UTC (permalink / raw)
To: jj
Cc: netdev, linux-kernel, eric.dumazet, xiaosuo, greearb, loke.chetan,
waltje, gw4pts, waltje, ross.biro, alan
In-Reply-To: <alpine.LNX.2.00.1111132247440.3368@swampdragon.chaosbits.net>
From: Jesper Juhl <jj@chaosbits.net>
Date: Sun, 13 Nov 2011 22:55:50 +0100 (CET)
> We test for 'tx_ring' being != zero and BUG() if that's the case. So after
> that check there is no way that 'tx_ring' could be anything _but_ zero, so
> testing it again is just dead code. Once that dead code is removed, the
> 'pkc' local variable becomes entirely redundant, so remove that as well.
>
> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Applied, thanks Jesper.
^ permalink raw reply
* Re: [PATCH] rds: drop "select LLIST"
From: David Miller @ 2011-11-14 5:12 UTC (permalink / raw)
To: pebolle; +Cc: venkat.x.venkatsubra, rds-devel, netdev, linux-kernel
In-Reply-To: <1321191397.20271.62.camel@x61.thuisdomein>
From: Paul Bolle <pebolle@tiscali.nl>
Date: Sun, 13 Nov 2011 14:36:37 +0100
> Commit 1bc144b625 ("net, rds, Replace xlist in net/rds/xlist.h with
> llist") added "select LLIST" to the RDS_RDMA Kconfig entry. But there is
> no Kconfig symbol named LLIST. The select statement for that symbol is a
> nop. Drop it.
>
> lib/llist.o is builtin, so all that's needed to use the llist
> functionality is to include linux/llist.h, which this commit also did.
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: reduce percpu needs for icmpv6msg mibs
From: David Miller @ 2011-11-14 5:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1321183444.17837.21.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 13 Nov 2011 12:24:04 +0100
> Reading /proc/net/snmp6 on a machine with a lot of cpus is very
> expensive (can be ~88000 us).
>
> This is because ICMPV6MSG MIB uses 4096 bytes per cpu, and folding
> values for all possible cpus can read 16 Mbytes of memory (32MBytes on
> non x86 arches)
>
> ICMP messages are not considered as fast path on a typical server, and
> eventually few cpus handle them anyway. We can afford an atomic
> operation instead of using percpu data.
>
> This saves 4096 bytes per cpu and per network namespace.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH Fix] mlx4_en: Remove FCS bytes from packet length.
From: David Miller @ 2011-11-14 5:13 UTC (permalink / raw)
To: yevgenyp; +Cc: netdev
In-Reply-To: <4EBF733E.5020801@mellanox.co.il>
From: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Sun, 13 Nov 2011 09:35:26 +0200
> diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> index 8fda331c..d93476b 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> +++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
> @@ -140,6 +140,7 @@ enum {
> #define MLX4_EN_TX_POLL_TIMEOUT (HZ / 4)
>
> #define ETH_LLC_SNAP_SIZE 8
> +#define FCS_SIZE 4
>
Please use ETH_FCS_LEN from linux/if_ether.h
^ permalink raw reply
* Re: [PATCH FIX net v2] forcedeth: fix stats on hardware without extended stats support
From: David Miller @ 2011-11-14 5:15 UTC (permalink / raw)
To: david.decotigny
Cc: netdev, linux-kernel, ian.campbell, eric.dumazet,
jeffrey.t.kirsher, jpirko, joe, szymon, rick.jones2, AAbdulla
In-Reply-To: <51c23650f3fc6e48b652a7ab322ca09a1cb7cbcc.1321064621.git.david.decotigny@google.com>
From: David Decotigny <david.decotigny@google.com>
Date: Fri, 11 Nov 2011 18:27:34 -0800
> This change makes sure that tx_packets/rx_bytes ifconfig counters are
> updated even on NICs that don't provide hardware support for these
> stats: they are now updated in software. For the sake of consistency,
> we also now have tx_bytes updated in software (hardware counters
> include ethernet CRC, and software doesn't account for it).
>
> This reverts parts of:
> - "forcedeth: statistics optimization" (21828163b2)
> - "forcedeth: Improve stats counters" (0bdfea8ba8)
> - "forcedeth: remove unneeded stats updates" (4687f3f364)
>
> Tested:
> pktgen + loopback (http://patchwork.ozlabs.org/patch/124698/)
> reports identical tx_packets/rx_packets and tx_bytes/rx_bytes.
>
> Signed-off-by: David Decotigny <david.decotigny@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH series][6LoWPAN][net-next]
From: David Miller @ 2011-11-14 5:22 UTC (permalink / raw)
To: alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-zigbee-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111110173258.GA8056-AUGNqIMGY+bGcXpsla5Oef8+0UxHXcjY@public.gmane.org>
From: Alexander Smirnov <alex.bluesman.smirnov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 10 Nov 2011 20:32:58 +0300
> Hello all,
>
> The following patch series adds both major feature and minor fixes.
> Please find detailed description in each of the patches.
>
> Just to summarize current development status:
> By using MAC and PHY layers support from
> "http://sourceforge.net/projects/linux-zigbee"
> project now it's possible to run generic network applications (ssh, iperf) over
> ieee802.15.4 network.
>
> iperf shows about ~40Kbits/sec for TCP
All applied, thanks.
In future patch submissions, please layout your Subject lines
correctly.
Everything that is inside of brackes "[]" will be removed before
the subject line is placed at the top of the commit message. So
as-is, your commits would lack any kind of indication of where
the code changes were occuring since the "6LowPAN" part was removed.
In fact, you didn't mention 6LowPAN at all in the subject line
of some of your commits. This is unacceptable. There must always
be a subject prefix of the form "${SUBSYSTEM}: " so that what
ends up in the commit message lets readers know the general area
where the change was made.
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
^ permalink raw reply
* Re: [PATCH net-next v2] net-forcedeth: Add internal loopback support for forcedeth NICs.
From: David Miller @ 2011-11-14 5:22 UTC (permalink / raw)
To: horti
Cc: netdev, linux-kernel, david.decotigny, ian.campbell, rick.jones2,
eric.dumazet, maheshb
In-Reply-To: <0a790bcdac9827d6e4a9162cc8f6b5bcb70acd4e.1321063429.git.horti@google.com>
From: Sanjay Hortikar <horti@google.com>
Date: Fri, 11 Nov 2011 18:11:21 -0800
> Support enabling/disabling/querying internal loopback mode for
> forcedeth NICs using ethtool.
>
> Signed-off-by: Sanjay Hortikar <horti@google.com>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] ip6_tunnel: copy parms.name after register_netdevice
From: David Miller @ 2011-11-14 5:24 UTC (permalink / raw)
To: jwboyer; +Cc: jpirko, netdev, linux-kernel, stable
In-Reply-To: <20111111011023.GE2170@zod.bos.redhat.com>
From: Josh Boyer <jwboyer@redhat.com>
Date: Thu, 10 Nov 2011 20:10:23 -0500
> @@ -288,6 +288,8 @@ static struct ip6_tnl *ip6_tnl_create(struct net *net, struct ip6_tnl_parm *p)
>
> if ((err = register_netdevice(dev)) < 0)
> goto failed_free;
> +
> + strcpy(t->parms.name, dev->name);
Trailing whitespace on that blank line you're adding.
I fixed this up, applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] fsl_pq_mdio: Clean up tbi address configuration
From: David Miller @ 2011-11-14 5:26 UTC (permalink / raw)
To: afleming; +Cc: netdev
In-Reply-To: <1321024239-18861-1-git-send-email-afleming@freescale.com>
From: Andy Fleming <afleming@freescale.com>
Date: Fri, 11 Nov 2011 09:10:39 -0600
> The code for setting the address of the internal TBI PHY was
> convoluted enough without a maze of ifdefs. Clean it up a bit
> so we allow the logic to fail down to -ENODEV at the end of
> the if/else ladder, rather than using ifdefs to repeat the same
> failure code over and over.
>
> Also, remove the support for the auto-configuration. I'm not aware of
> anyone using it, and it ends up using the bus mutex before it's been
> initialized.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH V2 1/6] net/ethernet/atl1c: Disable ASPM on various chipsets
From: David Miller @ 2011-11-14 5:30 UTC (permalink / raw)
To: mjg; +Cc: linux-kernel, netdev, jcliburn, chris.snook
In-Reply-To: <1321028064-644-2-git-send-email-mjg@redhat.com>
From: Matthew Garrett <mjg@redhat.com>
Date: Fri, 11 Nov 2011 11:14:19 -0500
> The Windows driver disables ASPM support for various chipsets supported
> by atl1c. This adds the same set of logic to the Linux driver. ASPM is
> disabled on l1c, l2c, l2cb and l2cb2 devices except for those in Toshiba
> or Lenovo devices. Data taken from
> http://www.atheros.cz/atheros-inf-file.php?inf=199&chipset=51&system=6
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH V2 2/6] net/ethernet/atl1e: Disable ASPM
From: David Miller @ 2011-11-14 5:31 UTC (permalink / raw)
To: mjg; +Cc: linux-kernel, netdev, jcliburn, chris.snook
In-Reply-To: <1321028064-644-3-git-send-email-mjg@redhat.com>
From: Matthew Garrett <mjg@redhat.com>
Date: Fri, 11 Nov 2011 11:14:20 -0500
> http://www.atheros.cz/atheros-inf-file.php?inf=209&chipset=45&system=6
> indicates that ASPM is disabled on all L1E hardware. Duplicate for sanity.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH V2 3/6] net/ethernet/jme: Disable ASPM
From: David Miller @ 2011-11-14 5:31 UTC (permalink / raw)
To: mjg; +Cc: linux-kernel, netdev, cooldavid
In-Reply-To: <1321028064-644-4-git-send-email-mjg@redhat.com>
From: Matthew Garrett <mjg@redhat.com>
Date: Fri, 11 Nov 2011 11:14:21 -0500
> http://driveragent.com/archive/30421/7-0-14 indicates that ASPM is
> disabled on the 250 and 260. Duplicate for sanity.
>
> Signed-off-by: Matthew Garrett <mjg@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH V2 2/6] net/ethernet/atl1e: Disable ASPM
From: David Miller @ 2011-11-14 5:33 UTC (permalink / raw)
To: mjg; +Cc: linux-kernel, netdev, jcliburn, chris.snook
In-Reply-To: <20111114.003113.40819474361221233.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Mon, 14 Nov 2011 00:31:13 -0500 (EST)
> From: Matthew Garrett <mjg@redhat.com>
> Date: Fri, 11 Nov 2011 11:14:20 -0500
>
>> http://www.atheros.cz/atheros-inf-file.php?inf=209&chipset=45&system=6
>> indicates that ASPM is disabled on all L1E hardware. Duplicate for sanity.
>>
>> Signed-off-by: Matthew Garrett <mjg@redhat.com>
>
> Applied.
Ummm, -ENOBUILDTESTING?!??!
drivers/net/ethernet/atheros/atl1e/atl1e_main.c: In function ‘atl1e_probe’:
drivers/net/ethernet/atheros/atl1e/atl1e_main.c:2267:2: error: implicit declaration of function ‘pci_disable_link_state’ [-Werror=implicit-function-declaration]
drivers/net/ethernet/atheros/atl1e/atl1e_main.c:2267:31: error: ‘PCIE_LINK_STATE_L0S’ undeclared (first use in this function)
drivers/net/ethernet/atheros/atl1e/atl1e_main.c:2267:31: note: each undeclared identifier is reported only once for each function it appears in
drivers/net/ethernet/atheros/atl1e/atl1e_main.c:2267:53: error: ‘PCIE_LINK_STATE_L1’ undeclared (first use in this function)
drivers/net/ethernet/atheros/atl1e/atl1e_main.c:2268:11: error: ‘PCIE_LINK_STATE_CLKPM’ undeclared (first use in this function)
^ permalink raw reply
* Re: [PATCH V2 1/6] net/ethernet/atl1c: Disable ASPM on various chipsets
From: David Miller @ 2011-11-14 5:34 UTC (permalink / raw)
To: mjg; +Cc: linux-kernel, netdev, jcliburn, chris.snook
In-Reply-To: <20111114.003048.2051399548192848039.davem@davemloft.net>
I'm reverting all of these.
You do all of that work to research the inf files and whatnot, then
you don't even build test the patches you submit?
Forget it, for something as potentially fragile as this stuff might
be, I simply cannot trust you if you can't even do due diligence
wrt. the build validation.
^ permalink raw reply
* Re: [PATCH] net, bridge: print log message after state changed
From: David Miller @ 2011-11-14 5:37 UTC (permalink / raw)
To: holger.brunck; +Cc: netdev, wolfgang.fritz, shemminger, bridge
In-Reply-To: <1320941934-3534-1-git-send-email-holger.brunck@keymile.com>
From: Holger Brunck <holger.brunck@keymile.com>
Date: Thu, 10 Nov 2011 17:18:54 +0100
> From: Wolfgang Fritz <wolfgang.fritz@keymile.com>
>
> Function br_log_state writes log message "... entering XXXX state" so it
> should be called after the state has changed and not before.
>
> Signed-off-by: Wolfgang Fritz <wolfgang.fritz@keymile.com>
> Signed-off-by: Holger Brunck <holger.brunck@keymile.com>
"entering" can roughly mean "about to enter"
The message is therefore appropriately timed as far as I'm concerned.
I'm not applying this patch.
^ permalink raw reply
* Re: [PATCH] bridge: Fix potential deadlock on br->multicast_lock
From: David Miller @ 2011-11-14 5:39 UTC (permalink / raw)
To: avagin; +Cc: shemminger, bridge, netdev, linux-kernel, devel
In-Reply-To: <1320940083-3719823-1-git-send-email-avagin@openvz.org>
From: Andrew Vagin <avagin@openvz.org>
Date: Thu, 10 Nov 2011 18:48:03 +0300
> multicast_lock is taken in softirq context, so we should use
> spin_lock_bh() in userspace.
>
> call-chain in softirq context:
> run_timer_softirq()
> br_multicast_query_expired()
>
> call-chain in userspace:
> sysfs_write_file()
> store_multicast_snooping()
> br_multicast_toggle()
>
> Signed-off-by: Andrew Vagin <avagin@openvz.org>
Applied, thanks.
^ 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