* Re: dmfe/tulip device id overlap
From: David Miller @ 2009-11-30 20:26 UTC (permalink / raw)
To: grundler; +Cc: brandon, tobias, kyle, netdev, grundler
In-Reply-To: <da824cf30911300914p2d08b87cr4625e9bc30ec7e5b@mail.gmail.com>
From: Grant Grundler <grundler@google.com>
Date: Mon, 30 Nov 2009 09:14:01 -0800
> Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
> V100" motherboards?
>
> I'm asking because I'm hoping it's possible to disambiguate the add-on
> cards from
> LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
I think more likely OF properties will help here.
Have a look at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/prtconfs.git
In particular 'v100' which has a network device OF node with properties:
Node 0xf007fae8
.node: f007fae8
local-mac-address: 0003ba11.b371
assigned-addresses: 81006010.00000000.00010000.00000000.00000100.82006014.00000000.00000000.00000000.00002000.82006030.00000000.00040000.00000000.00040000
version: '1.0'
compatible: 70636934.3535342c.34333465.00706369.31323868.2c393130.32007063.69313238.322c3931.30320070.6369636c.6173732c.30323030.303000
device_type: 'network'
subsystem-id: 0000434e
subsystem-vendor-id: 00004554
reg: 00006000.00000000.00000000.00000000.00000000.01006010.00000000.00000000.00000000.00000100.02006014.00000000.00000000.00000000.00000100
name: 'ethernet'
devsel-speed: 00000001
class-code: 00020000
interrupts: 00000001
max-latency: 00000028
min-grant: 00000014
revision-id: 00000031
device-id: 00009102
vendor-id: 00001282
Hmmm, what vendor is '0x4554'? :-)
^ permalink raw reply
* Re: warning: massive change to conditional coding style in net?
From: David Miller @ 2009-11-30 20:36 UTC (permalink / raw)
To: william.allen.simpson; +Cc: linux-kernel, netdev
In-Reply-To: <4B13A025.7000103@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Mon, 30 Nov 2009 05:36:21 -0500
> Over the past several days, David Miller (with help from Joe Perches)
> made sweeping changes to the format of conditional statements in the
> net tree -- the equivalent of mass patches that change spaces.
>
> This makes writing patches for multiple versions of the tree very
> difficult, and will make future pullups problematic. It's enough to
> make a grown man cry.... Patching conflicts everywhere!
William, you're unreasonable.
We asked you to follow a certain style, and then you immediately
complain that the style isn't followed consistently in the tree, and
therefore as a consequence you shouldn't be required to follow it.
Then Joe comes and submits patches making the tree follow the style
more consistently. See, instead of merely complaining like you did,
he proactively did something positive.
Now you're complaining because this makes your patches harder to
maintain.
You're being difficult about this from every possible angle. I can
only conclude that for whatever reason you don't want to have any
requirements made upon you for your submission. You've handled this
negatively in every way possible, and every step of the way. No
matter how hard other people have been to try and help you, you've
continued to do this.
Whereas if you had merely fixed up the coding style as I and others
have asked you, your code would be in my tree weeks ago.
Why is it such a huge deal to follow the coding style that the
maintainer (and other prominent developers of that subsystem) are
asking you to follow?
^ permalink raw reply
* Re: scp stalls mysteriously
From: Frederic Leroy @ 2009-11-30 20:37 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev, Asdo
In-Reply-To: <alpine.DEB.2.00.0911302113390.9826@melkinpaasi.cs.helsinki.fi>
Le Mon, 30 Nov 2009 22:18:22 +0200 (EET),
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> On Mon, 30 Nov 2009, Frederic Leroy wrote:
>
> Thanks, at least ....3.... shows that cwnd (congestion window, the
> 2nd to last field in /proc/net/tcp) goes to zero which it never ever
> should. ...I'll start reading some code to figure out the cause for
> that.
>
> How much is your RTT btw?
The RTT is ~ 1.4ms.
The following trace has a rtt as big as 5ms but most of the time, it's
under 1.4ms and periodically grow to 3ms.
-------------------------------------------
64 bytes from sg (192.168.1.19): icmp_seq=681 ttl=64 time=1.26 ms
64 bytes from sg (192.168.1.19): icmp_seq=682 ttl=64 time=1.26 ms
64 bytes from sg (192.168.1.19): icmp_seq=683 ttl=64 time=1.34 ms
64 bytes from sg (192.168.1.19): icmp_seq=684 ttl=64 time=2.01 ms
64 bytes from sg (192.168.1.19): icmp_seq=686 ttl=64 time=2.15 ms
64 bytes from sg (192.168.1.19): icmp_seq=687 ttl=64 time=5.07 ms
64 bytes from sg (192.168.1.19): icmp_seq=688 ttl=64 time=1.19 ms
64 bytes from sg (192.168.1.19): icmp_seq=689 ttl=64 time=1.30 ms
64 bytes from sg (192.168.1.19): icmp_seq=690 ttl=64 time=1.19 ms
64 bytes from sg (192.168.1.19): icmp_seq=691 ttl=64 time=1.14 ms
-------------------------------------------
> The RTO timeout easily goes up to 120
> secods similar to what I found myself already. Thus I'm not sure if
> this stall would be "infinite" after all.
I notice that grep '":0016" /proc/net/tcp' stop to report something when
it stalls. Is the connection closed ?
> I've some problem in .3. case in matching timing of the proc/net/tcp
> dump and the tcpdump ... did you perhaps cut it somewhere?
No, I didn't cut it.
> This might
> point out to yet another problem, however, I'm not sure what I can
> atm trust in the logs. ...Timestamps would probably help me a bit
> (I've changed also sleep to do 0.01 granularity):
>
> while [ : ]; do date "+%s.%N"; grep ":0016" /proc/net/tcp; sleep
> 0.01; done | tee scp_stall-houba.x.proc_net_tcp
> (Please run start while loop before starting the transfer and all the
> way until the connection is already killed and only then stop the
> loop).
I took care to timings this time. I did as you said.
> What happened in .2. case I've very little idea, proc/net/tcp does
> claim retransmission would have happened on TCP layer but that never
> went into tcpdump log (the kind of thing might have happened in
> the .3. case too which is why I asked for the timestamps for matching
> captures more exactly but there were some retransmissions earlier in
> the log so I cannot be sure). Can you also check that tcpdump doesn't
> lose any packets, it should show: "0 packets dropped by kernel" when
> you ctrl-c it.
I still have the logs, O packet dropped :
-------------------------------------------
houba tmp # tcpdump -i wlan1 -s 1500 -w /tmp/ssh_stall-houba.1.pcap -vv
ether host 00:40:45:09:3f:3f tcpdump: listening on wlan1, link-type
EN10MB (Ethernet), capture size 1500 bytes ^C8923 packets captured
8923 packets received by filter
0 packets dropped by kernel
houba tmp # tcpdump -i wlan1 -s 1500 -w /tmp/scp_stall-houba.3.pcap
-vv ether host 00:40:45:09:3f:3f tcpdump: listening on wlan1, link-type
EN10MB (Ethernet), capture size 1500 bytes ^C17045 packets captured
17045 packets received by filter
0 packets dropped by kernel
houba tmp #
-------------------------------------------
--
Frédéric Leroy
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device
From: Andy Gospodarek @ 2009-11-30 20:53 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Andy Gospodarek, netdev, fubar
In-Reply-To: <4B142989.6070207@trash.net>
On Mon, Nov 30, 2009 at 09:22:33PM +0100, Patrick McHardy wrote:
> Andy Gospodarek wrote:
> > diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
> > index e75a2f3..8d8a778 100644
> > --- a/net/8021q/vlan_core.c
> > +++ b/net/8021q/vlan_core.c
> > @@ -14,6 +14,7 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
> > if (skb_bond_should_drop(skb))
> > goto drop;
> >
> > + skb->skb_iif = skb->dev->ifindex;
> > __vlan_hwaccel_put_tag(skb, vlan_tci);
> > skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
> >
> > @@ -85,6 +86,7 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
> > if (skb_bond_should_drop(skb))
> > goto drop;
> >
> > + skb->skb_iif = skb->dev->ifindex;
> > __vlan_hwaccel_put_tag(skb, vlan_tci);
> > skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
> >
>
> How about pulling the skb->iif assignment in netif_receive_skb() up
> before the vlan_hwaccel_do_receive() call instead?
I'm not sure how that will help. My goal with the two changes in
vlan_core.c was to capture the input device index before we lost it --
which is precisely what happens when coming up through a driver like
bnx2 that supports vlan acceleration:
(NAPI poll)
bnx2_poll
bnx2_poll_work
bnx2_rx_int
vlan_hwaccel_receive_skb
__vlan_hwaccel_rx
(skb->dev set to vlan device)
netif_receive_skb
In that case, setting skb_iif in netif_receive_skb would be too late.
The original dev would no longer be known.
> I'd actually call
> this a bug fix since hardware accelerated devices should not differ
> from non-accelerated devices in their iif value.
This dances the line between bugfix and feature since the arp monitoring
component was never really advertised as working, but you are correct
that it could be a bug since skb_iif should be consistent depending the
the devices capabilities.
^ permalink raw reply
* RE: MERGE check, net-next-2.6...
From: Allan, Bruce W @ 2009-11-30 20:54 UTC (permalink / raw)
To: David Miller, netdev@vger.kernel.org
Cc: Kirsher, Jeffrey T, linville@tuxdriver.com, amit@netxen.com
In-Reply-To: <20091129.011709.11078985.davem@davemloft.net>
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of David Miller
>Sent: Sunday, November 29, 2009 1:17 AM
>To: netdev@vger.kernel.org
>Cc: Kirsher, Jeffrey T; linville@tuxdriver.com; amit@netxen.com
>Subject: MERGE check, net-next-2.6...
>
>
>I just merged net-2.6 into net-next-2.6, there were several
>conflicts.
>
>They happened in e1000e, ath9k, generic ieee80211, and the
>netxen driver.
>
>Please check my work and send any necessary fixes.
>
>Thanks!
Your merge conflict fix-ups for e1000e look good to me. Thanks!
Bruce.
^ permalink raw reply
* Re: Problem with tcp (2.6.31) as first
From: David Miller @ 2009-11-30 20:56 UTC (permalink / raw)
To: eric.dumazet; +Cc: ilpo.jarvinen, ole, herbert, netdev
In-Reply-To: <4B138C73.8040401@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 30 Nov 2009 10:12:19 +0100
> [PATCH] tcp: tcp_disconnect() should clear window_clamp
>
> NFS can reuse its TCP socket after calling tcp_disconnect().
> We noticed window scaling was not negotiated in SYN packet of next connection request.
>
> Fix is to clear tp->window_clamp in tcp_disconnect().
>
> Reported-by: Krzysztof Oledzki <ole@ans.pl>
> Tested-by: Krzysztof Oledzki <ole@ans.pl>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
You voiced some concerns about window clamp route and socket settings
and whatnot. But I think the route side should be OK. When a new
connect() occurs, TCP will reinitialize the window clamp setting based
upon the route metric and other values.
The TCP_WINDOW_CLAMP socket option case is tedious however. If we
want to preserve such settings across disconnect operations we'll need
to store two pieces of state I believe.
^ permalink raw reply
* Re: [PATCH net-next-2.6 PATCH] net: Move && and || to end of previous line
From: David Miller @ 2009-11-30 21:00 UTC (permalink / raw)
To: shemminger; +Cc: joe, netdev
In-Reply-To: <20091130092837.4998f961@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 30 Nov 2009 09:28:37 -0800
> Rather than playing with the dangling operator format which seems to
> be a coding style that only David cares about.
I think Joe's work is useful and valuable.
Please don't discourage him.
^ permalink raw reply
* Re: MERGE check, net-next-2.6...
From: David Miller @ 2009-11-30 21:02 UTC (permalink / raw)
To: bruce.w.allan; +Cc: netdev, jeffrey.t.kirsher, linville, amit
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A903E332F65@orsmsx509.amr.corp.intel.com>
From: "Allan, Bruce W" <bruce.w.allan@intel.com>
Date: Mon, 30 Nov 2009 12:54:48 -0800
> Your merge conflict fix-ups for e1000e look good to me. Thanks!
Thanks a lot for checking Allan.
^ permalink raw reply
* Re: scp stalls mysteriously
From: Frederic Leroy @ 2009-11-30 21:24 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev, Asdo
In-Reply-To: <alpine.DEB.2.00.0911302113390.9826@melkinpaasi.cs.helsinki.fi>
Le Mon, 30 Nov 2009 22:18:22 +0200 (EET),
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> On Mon, 30 Nov 2009, Frederic Leroy wrote:
>
> > Le Sat, 28 Nov 2009 13:31:14 +0200 (EET),
> > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> point out to yet another problem, however, I'm not sure what I can
> atm trust in the logs. ...Timestamps would probably help me a bit
> (I've changed also sleep to do 0.01 granularity):
I made 2 other traces with 0.01 granularity, but it works normally. I
suppose there are less interference in the evening.
The .4 is a bad trace where I forgot to put timestamp. And when I
realized it was copying successfully, I stopped it before it tooks too
much space.
It can be interesting because the stream had a little "pause".
The .5 is the trace of a successfull copy. I limited packet capture size
to 96 bytes. It has stalled once in the middle.
--
Frédéric Leroy
^ permalink raw reply
* Re: MERGE check, net-next-2.6...
From: John W. Linville @ 2009-11-30 21:20 UTC (permalink / raw)
To: Allan, Bruce W
Cc: David Miller, netdev@vger.kernel.org, Kirsher, Jeffrey T,
amit@netxen.com
In-Reply-To: <8DD2590731AB5D4C9DBF71A877482A903E332F65@orsmsx509.amr.corp.intel.com>
On Mon, Nov 30, 2009 at 12:54:48PM -0800, Allan, Bruce W wrote:
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
> >On Behalf Of David Miller
> >Sent: Sunday, November 29, 2009 1:17 AM
> >To: netdev@vger.kernel.org
> >Cc: Kirsher, Jeffrey T; linville@tuxdriver.com; amit@netxen.com
> >Subject: MERGE check, net-next-2.6...
> >
> >
> >I just merged net-2.6 into net-next-2.6, there were several
> >conflicts.
> >
> >They happened in e1000e, ath9k, generic ieee80211, and the
> >netxen driver.
> >
> >Please check my work and send any necessary fixes.
> >
> >Thanks!
>
> Your merge conflict fix-ups for e1000e look good to me. Thanks!
The wireless bits seem alright too...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-11-30 21:26 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091130222417.77ce13a4@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1072 bytes --]
On Mon, 30 Nov 2009, Frederic Leroy wrote:
> Le Mon, 30 Nov 2009 22:18:22 +0200 (EET),
> "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
>
> > On Mon, 30 Nov 2009, Frederic Leroy wrote:
> >
> > > Le Sat, 28 Nov 2009 13:31:14 +0200 (EET),
> > > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> > point out to yet another problem, however, I'm not sure what I can
> > atm trust in the logs. ...Timestamps would probably help me a bit
> > (I've changed also sleep to do 0.01 granularity):
>
> I made 2 other traces with 0.01 granularity, but it works normally. I
> suppose there are less interference in the evening.
>
> The .4 is a bad trace where I forgot to put timestamp. And when I
> realized it was copying successfully, I stopped it before it tooks too
> much space.
>
> It can be interesting because the stream had a little "pause".
>
> The .5 is the trace of a successfull copy. I limited packet capture size
> to 96 bytes. It has stalled once in the middle.
Could you compress such big ones. ...I only have 1Mbps downlink here :-).
--
i.
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-11-30 21:37 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091130213727.2f4047d2@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4574 bytes --]
On Mon, 30 Nov 2009, Frederic Leroy wrote:
> Le Mon, 30 Nov 2009 22:18:22 +0200 (EET),
> "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
>
> > On Mon, 30 Nov 2009, Frederic Leroy wrote:
> >
> > Thanks, at least ....3.... shows that cwnd (congestion window, the
> > 2nd to last field in /proc/net/tcp) goes to zero which it never ever
> > should. ...I'll start reading some code to figure out the cause for
> > that.
> >
> > How much is your RTT btw?
>
> The RTT is ~ 1.4ms.
> The following trace has a rtt as big as 5ms but most of the time, it's
> under 1.4ms and periodically grow to 3ms.
>
> -------------------------------------------
> 64 bytes from sg (192.168.1.19): icmp_seq=681 ttl=64 time=1.26 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=682 ttl=64 time=1.26 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=683 ttl=64 time=1.34 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=684 ttl=64 time=2.01 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=686 ttl=64 time=2.15 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=687 ttl=64 time=5.07 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=688 ttl=64 time=1.19 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=689 ttl=64 time=1.30 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=690 ttl=64 time=1.19 ms
> 64 bytes from sg (192.168.1.19): icmp_seq=691 ttl=64 time=1.14 ms
> -------------------------------------------
Thanks, quite much what I expected (a low one).
> > The RTO timeout easily goes up to 120
> > secods similar to what I found myself already. Thus I'm not sure if
> > this stall would be "infinite" after all.
>
> I notice that grep '":0016" /proc/net/tcp' stop to report something when
> it stalls. Is the connection closed ?
...that seems possible because of the reset in the end (however, the
earlier fin in .3. does not get reset as response for some reason).
Another option is that the socket is locked so long that grep has to wait
until read succeeds.
...I might have been wrong with this 120 seconds thing btw, I misread the
units.
> > I've some problem in .3. case in matching timing of the proc/net/tcp
> > dump and the tcpdump ... did you perhaps cut it somewhere?
>
> No, I didn't cut it.
Ok.
> > This might
> > point out to yet another problem, however, I'm not sure what I can
> > atm trust in the logs. ...Timestamps would probably help me a bit
> > (I've changed also sleep to do 0.01 granularity):
> >
> > while [ : ]; do date "+%s.%N"; grep ":0016" /proc/net/tcp; sleep
> > 0.01; done | tee scp_stall-houba.x.proc_net_tcp
>
> > (Please run start while loop before starting the transfer and all the
> > way until the connection is already killed and only then stop the
> > loop).
>
> I took care to timings this time. I did as you said.
>
> > What happened in .2. case I've very little idea, proc/net/tcp does
> > claim retransmission would have happened on TCP layer but that never
> > went into tcpdump log (the kind of thing might have happened in
> > the .3. case too which is why I asked for the timestamps for matching
> > captures more exactly but there were some retransmissions earlier in
> > the log so I cannot be sure). Can you also check that tcpdump doesn't
> > lose any packets, it should show: "0 packets dropped by kernel" when
> > you ctrl-c it.
>
> I still have the logs, O packet dropped :
>
> -------------------------------------------
> houba tmp # tcpdump -i wlan1 -s 1500 -w /tmp/ssh_stall-houba.1.pcap -vv
> ether host 00:40:45:09:3f:3f tcpdump: listening on wlan1, link-type
> EN10MB (Ethernet), capture size 1500 bytes ^C8923 packets captured
> 8923 packets received by filter
> 0 packets dropped by kernel
> houba tmp # tcpdump -i wlan1 -s 1500 -w /tmp/scp_stall-houba.3.pcap
> -vv ether host 00:40:45:09:3f:3f tcpdump: listening on wlan1, link-type
> EN10MB (Ethernet), capture size 1500 bytes ^C17045 packets captured
> 17045 packets received by filter
> 0 packets dropped by kernel
> houba tmp #
Ok. Just wanted to confirm since it can be that that not all packets are
in the tcpdump that TCP was sending. For what reason is unknown at the
moment. Any fancy firewall (iptables) rules on houba that could do such a
trick here? Also, have you changed sysctl settings from the defaults?
Could you try btw to disable frto (set tcp_frto sysctl to zero), in theory
it could cause zero cwnd if something else is wrong too (I haven't yet
read them all through so there might be other places where a zero cwnd
can be set). Also I'm interested what happens if you disable timestamps,
is the problem still reproducable.
--
i.
^ permalink raw reply
* Re: scp stalls mysteriously
From: Frederic Leroy @ 2009-11-30 21:54 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev, Asdo
In-Reply-To: <alpine.DEB.2.00.0911302325500.9826@melkinpaasi.cs.helsinki.fi>
Le Mon, 30 Nov 2009 23:26:55 +0200 (EET),
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> On Mon, 30 Nov 2009, Frederic Leroy wrote:
>
> > Le Mon, 30 Nov 2009 22:18:22 +0200 (EET),
> > "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> [...]
> > The .5 is the trace of a successfull copy. I limited packet capture
> > size to 96 bytes. It has stalled once in the middle.
>
> Could you compress such big ones. ...I only have 1Mbps downlink
> here :-).
Done ... and will do for the next :)
--
Frédéric Leroy
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-11-30 (security fixes too)
From: Linus Torvalds @ 2009-11-30 22:08 UTC (permalink / raw)
To: John W. Linville; +Cc: davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20091130194706.GE21401@tuxdriver.com>
On Mon, 30 Nov 2009, John W. Linville wrote:
>
> If a) you have already taken Dave's latest pull request; and, b) you
> don't want to wait for his next one to get the mac80211 security fixes
> from Johannes, then you can at your discretion pull from here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git security
Hmm. If I pull the 'security' branch, I get
drivers/net/wireless/iwlwifi/iwl-tx.c | 10 +++++++++-
include/net/mac80211.h | 6 ++++++
net/mac80211/agg-rx.c | 4 ----
net/mac80211/agg-tx.c | 17 ++++++++---------
net/mac80211/ht.c | 8 +++-----
net/mac80211/ieee80211_i.h | 2 ++
6 files changed, 28 insertions(+), 19 deletions(-)
which does not match what you then descibe in the rest of the email
(changelog and diffstat).
What you describe seems to be the master branch.
So I'm not going to pull either, and will wait for confirmation of exactly
what you wanted me to pull.
Linus
^ permalink raw reply
* Re: scp stalls mysteriously
From: Frederic Leroy @ 2009-11-30 22:19 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev, Asdo
In-Reply-To: <alpine.DEB.2.00.0911302244160.9826@melkinpaasi.cs.helsinki.fi>
Le Mon, 30 Nov 2009 23:37:56 +0200 (EET),
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> Ok. Just wanted to confirm since it can be that that not all packets
> are in the tcpdump that TCP was sending. For what reason is unknown
> at the moment. Any fancy firewall (iptables) rules on houba that
> could do such a trick here?
Nothing with netfilter or schedulers on houba, neither on sg ( no log
because no iproute installed ...)
http://www.starox.org/pub/scp_stall/houba.netfilter.log
> Also, have you changed sysctl settings from the defaults?
No but I could have change defaults in the linux config file.
I saved the current content of /proc/sys/net and proc/net :
http://www.starox.org/pub/scp_stall/sg-proc_net-proc_sys_net.tbz2
http://www.starox.org/pub/scp_stall/houba-proc_net-proc_sys_net.tbz2
I put also linux config files in the directory.
> Could you try btw to disable frto (set tcp_frto sysctl to zero), in
> theory it could cause zero cwnd if something else is wrong too (I
> haven't yet read them all through so there might be other places
> where a zero cwnd can be set). Also I'm interested what happens if
> you disable timestamps, is the problem still reproducable.
Ok, I'll try these tomorrow when it will fault again :)
--
Frédéric Leroy
^ permalink raw reply
* Re: dmfe/tulip device id overlap
From: Brandon Philips @ 2009-11-30 22:22 UTC (permalink / raw)
To: David Miller; +Cc: grundler, tobias, kyle, netdev, grundler
In-Reply-To: <20091130.122642.113956563.davem@davemloft.net>
On 12:26 Mon 30 Nov 2009, David Miller wrote:
> From: Grant Grundler <grundler@google.com>
> Date: Mon, 30 Nov 2009 09:14:01 -0800
> > Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
> > V100" motherboards?
> >
> > I'm asking because I'm hoping it's possible to disambiguate the add-on
> > cards from
> > LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
>
> subsystem-id: 0000434e
> subsystem-vendor-id: 00004554
>
> Hmmm, what vendor is '0x4554'? :-)
Whoever it is it is the same as the expansion card on non-sparc
boards: SubVendor: pci 0x4554 [1]
Hrm, dead end I guess.
Cheers,
Brandon
[1] https://bugzilla.novell.com/show_bug.cgi?id=537016#c5
^ permalink raw reply
* Re: dmfe/tulip device id overlap
From: David Miller @ 2009-11-30 22:29 UTC (permalink / raw)
To: brandon; +Cc: grundler, tobias, kyle, netdev, grundler
In-Reply-To: <20091130222219.GA8073@jenkins.domain_not_set.invalid>
From: Brandon Philips <brandon@ifup.org>
Date: Mon, 30 Nov 2009 14:22:20 -0800
> On 12:26 Mon 30 Nov 2009, David Miller wrote:
>> From: Grant Grundler <grundler@google.com>
>> Date: Mon, 30 Nov 2009 09:14:01 -0800
>> > Has anyone posted "lspci -v" output for the "Netra X1 and Sunfire
>> > V100" motherboards?
>> >
>> > I'm asking because I'm hoping it's possible to disambiguate the add-on
>> > cards from
>> > LAN-on-Motherboard cases by looking at subsystem vendor and device IDs as well.
>>
>> subsystem-id: 0000434e
>> subsystem-vendor-id: 00004554
>>
>> Hmmm, what vendor is '0x4554'? :-)
>
> Whoever it is it is the same as the expansion card on non-sparc
> boards: SubVendor: pci 0x4554 [1]
>
> Hrm, dead end I guess.
We still have the OF properties. So we can simply look for
merely the existence of a 'compatible' OF property on the
device and from that we'll know that it's a Sparc onboard
instance of this thing.
^ permalink raw reply
* Re: net 03/05: fib_rules: add oif classification
From: Jarek Poplawski @ 2009-11-30 22:31 UTC (permalink / raw)
To: Patrick McHardy; +Cc: netdev
In-Reply-To: <20091130175533.7555.35189.sendpatchset@x2.localnet>
Patrick McHardy wrote, On 11/30/2009 06:55 PM:
> commit b3fe9e6465a572e97dc1bb6222c1ec4224285817
> Author: Patrick McHardy <kaber@trash.net>
> Date: Mon Nov 30 16:00:51 2009 +0100
>
> net: fib_rules: add oif classification
...
> diff --git a/include/net/fib_rules.h b/include/net/fib_rules.h
> index 62bebcb..d4e875a 100644
> --- a/include/net/fib_rules.h
> +++ b/include/net/fib_rules.h
> @@ -11,6 +11,7 @@ struct fib_rule {
> struct list_head list;
> atomic_t refcnt;
> int iifindex;
> + int oifindex;
Doesn't it "break" the cacheline fix from 01/05?
Jarek P.
> u32 mark;
> u32 mark_mask;
> u32 pref;
> @@ -20,6 +21,7 @@ struct fib_rule {
> u32 target;
> struct fib_rule * ctarget;
> char iifname[IFNAMSIZ];
> + char oifname[IFNAMSIZ];
> struct rcu_head rcu;
> struct net * fr_net;
> };
^ permalink raw reply
* Re: [PATCH 01/20] net: NETDEV_UNREGISTER_PERNET -> NETDEV_UNREGISTER_BATCH
From: David Miller @ 2009-11-30 22:49 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, hadi, dlezcano, adobriyan, kaber, opurdila
In-Reply-To: <1259545577-7466-1-git-send-email-ebiederm@xmission.com>
From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Sun, 29 Nov 2009 17:45:58 -0800
> Additionally it appears that we moved the route cache flush after
> the final synchronize_net, which seems wrong and there was no
> explanation. So I have restored the original location of the final
> synchronize_net.
I think the idea was that it's important for all pending stale
RCU references to the device to be gone before we send out the
notifier. And that's why the synchronize_net() comes first.
This needs more thought.
^ permalink raw reply
* Re: [RFC PATCH 1/4] net: Add support to netdev ops for changing hardware queue MAC and VLAN filters
From: Simon Horman @ 2009-11-30 22:57 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Ben Hutchings, Kirsher, Jeffrey T, davem@davemloft.net,
shemminger@vyatta.com, netdev@vger.kernel.org, gospo@redhat.com
In-Reply-To: <EA929A9653AAE14F841771FB1DE5A1365FA6BFA040@rrsmsx501.amr.corp.intel.com>
On Mon, Nov 30, 2009 at 11:36:08AM -0700, Williams, Mitch A wrote:
> >From: Simon Horman [mailto:horms@verge.net.au]
> >Sent: Sunday, November 29, 2009 10:03 PM
>
> >> The issue of which VF goes with which PF device can be deduced in
> >> userspace via sysfs.
> >
> >Does this mean that the configuration of filtering for a VF needs
> >to be done where the interface for the VF exists - e.g. in a KVM
> >guest/Xen domU?
> >
>
> No, all of the configuration is done through the PF device. What I was
> saying was that, given a specific VF PCI device (which would be passed
> through to the VM), you can use sysfs to determine which PF owns it, and
> then run the ip command to tell the PF to configure the VF.
Understood, sorry I missed that the first time around.
> >In terms of dealing with interfaces and the way that tools such as ip work
> >that makes a lot of sense. But I wonder if it actually makes more sense
> >from an administrative point of view to have this configuration go through
> >the PF - e.g. the KVM host/Xen domO.
>
> >From a policy and security standpoint, you can't allow the VM to handle
> >its own hardware configuration. The host/hypervisor/VM Manager/boss has
> >to handle this or you lose many of the advantages of virtualization
> >(i.e. isolation, security, stability, etc).
Yes, agreed.
^ permalink raw reply
* SO_BINDTODEVICE and IP_TRANSPARENT (TPROXY)
From: Ashwani Wason @ 2009-11-30 23:15 UTC (permalink / raw)
To: netdev
It appears that SO_BINDTODEVICE is not working when used along with
IP_TRANSPARENT of TPROXY. The use case is for a transparent proxy that
has to handle clients with overlapping IP addresses coming in on
different interfaces (VLANs or physical). Each such interface has a
unique next hop gateway.
Setup: Kernel 2.6.30.9 built with required TPROXY configuration. A
system with three interfaces, eth0 (192.168.0.65/24), eth0.1
(10.0.7.65/16), and eth1 (192.168.1.65/24), each with its own default
router and a fairly standard set of TPROXY rules:
default via 192.168.1.62 dev eth1
default via 192.168.0.62 dev eth0
default via 10.0.0.9 dev eth0.1
iptables -t mangle -N DIVERT
iptables -t mangle -A DIVERT -j MARK --set-mark 1
iptables -t mangle -A DIVERT -j ACCEPT
iptables -t mangle -A PREROUTING -p tcp -m socket -j DIVERT
iptables -t mangle -A PREROUTING -p tcp --dport 80 -j TPROXY
--tproxy-mark 0x1/0x1 --on-port 4002
ip rule add fwmark 1 iif eth0 lookup 101
ip rule add fwmark 1 iif eth1 lookup 101
ip route add local 0.0.0.0/0 dev lo table 101
Additional information:
* The proxy has a separate listening socket for each interface.
* On each listening socket the proxy sets the IP_TRANSPARENT option.
It also sets the SO_BINDTODEVICE option (on each socket) to the
associated interface. (I have experimented with the ordering of these
options and setting one before the other has no change in behavior.)
* The proxy works perfectly fine in "transparent mode" when
SO_BINDTODEVICE is not used.
* The proxy works perfectly fine in "explicit mode" when
SO_BINDTODEVICE *is used*.
Now my test is very simple with the expectation that when a SYN comes
in on, say, interface eth0 then the SYN/ACK must go out back on that
interface to the MAC address of the designated next hop router. That
does not seem to happen however. The SYN/ACK is not being sent out at
all, from any interface. It seems that either the SYN or the SYN/ACK
is being eaten up somewhere. No one 'netstat -s' seems to be updated
either. (Since even 'netstat -ant' does not show the TCP connection
state, I suspect that the SYN is being eaten up.)
When I reconfigure the proxy to be in explicit mode, i.e. not set the
IP_TRANSPARENT option, and have the clients connect directly to the IP
address and port of the proxy then the system works as expected, i.e.
the SYN/ACK (and all subsequent packets) go out on the associated
interface.
Thank you,
Ashwani
^ permalink raw reply
* Re: [PATCH 01/20] net: NETDEV_UNREGISTER_PERNET -> NETDEV_UNREGISTER_BATCH
From: Eric W. Biederman @ 2009-11-30 23:42 UTC (permalink / raw)
To: David Miller; +Cc: netdev, hadi, dlezcano, adobriyan, kaber, opurdila
In-Reply-To: <20091130.144917.233710214.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: "Eric W. Biederman" <ebiederm@xmission.com>
> Date: Sun, 29 Nov 2009 17:45:58 -0800
>
>> Additionally it appears that we moved the route cache flush after
>> the final synchronize_net, which seems wrong and there was no
>> explanation. So I have restored the original location of the final
>> synchronize_net.
>
> I think the idea was that it's important for all pending stale
> RCU references to the device to be gone before we send out the
> notifier. And that's why the synchronize_net() comes first.
>
> This needs more thought.
The only case the affects (today) is the invalidation of the route/flow cache.
The routing table until the addition of NETDEV_UNREGISTER_PERNET happened
in the notifier NETDEV_UNREGISTER, which comes before the final synchronize_net.
The routing cache has rcu references to the network device.
So it appears to me that with the current pernet batched routing code cleanup we
can end up calling kfree before all of the call_rcu functions triggered by
rt_do_flush will be run.
netdev_run_todo()
kobject_put()
netdev_release()
kfree()
NETDEV_UNREGISTER_PERCPU
rt_cache_flush(xxx, 0)
rt_do_flush()
rt_free
call_rcu
So it appears to me that moving the final syncrhonize_net() back where it was before
the NETDEV_UNREGISTER_PERNET changes (as I did) is necessary for correctness.
Eric
^ permalink raw reply
* Re: [PATCH 01/20] net: NETDEV_UNREGISTER_PERNET -> NETDEV_UNREGISTER_BATCH
From: David Miller @ 2009-11-30 23:55 UTC (permalink / raw)
To: ebiederm; +Cc: netdev, hadi, dlezcano, adobriyan, kaber, opurdila
In-Reply-To: <m1d42zoa0a.fsf@fess.ebiederm.org>
From: ebiederm@xmission.com (Eric W. Biederman)
Date: Mon, 30 Nov 2009 15:42:13 -0800
> So it appears to me that moving the final syncrhonize_net() back
> where it was before the NETDEV_UNREGISTER_PERNET changes (as I did)
> is necessary for correctness.
Ok, it appears your right. Thanks for the analysis.
I'll look over the rest of your series now.
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device
From: Jay Vosburgh @ 2009-12-01 0:00 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev
In-Reply-To: <20091130201453.GF1639@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
>This allows a bond device to specify an arp_ip_target as a host that is
>not on the same vlan as the base bond device. A configuration like
>this, now works:
>
>1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> inet6 ::1/128 scope host
> valid_lft forever preferred_lft forever
>2: eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
> link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
>3: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 qlen 1000
> link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
>8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
> inet6 fe80::213:21ff:febe:33e9/64 scope link
> valid_lft forever preferred_lft forever
>9: bond0.100@bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue
> link/ether 00:13:21:be:33:e9 brd ff:ff:ff:ff:ff:ff
> inet 10.0.100.2/24 brd 10.0.100.255 scope global bond0.100
> inet6 fe80::213:21ff:febe:33e9/64 scope link
> valid_lft forever preferred_lft forever
I'm not quite clear here on exactly what it is that doesn't
work.
Putting the arp_ip_target on a VLAN destination already works
(and has for a long time); I just checked against a 2.6.32-rc to make
sure I wasn't misremembering.
Perhaps there's some nuance of "not on the same vlan as the base
bond device" that I'm missing. What I see working before me is, e.g., a
bond0.777 VLAN interface atop a regular bond0 active-backup with a
couple of slaves; bond0 may or may not have an IP address of its own.
The arp_ip_target destination is on VLAN 777 somewhere.
Is this what your patch is meant to enable, or is it something
different? I'm pulling down today's net-next to see if this is
something that broke recently.
-J
>Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008)
>
>Bonding Mode: fault-tolerance (active-backup)
>Primary Slave: None
>Currently Active Slave: eth1
>MII Status: up
>MII Polling Interval (ms): 0
>Up Delay (ms): 0
>Down Delay (ms): 0
>ARP Polling Interval (ms): 1000
>ARP IP target/s (n.n.n.n form): 10.0.100.1
>
>Slave Interface: eth1
>MII Status: up
>Link Failure Count: 1
>Permanent HW addr: 00:40:05:30:ff:30
>
>Slave Interface: eth0
>MII Status: up
>Link Failure Count: 0
>Permanent HW addr: 00:13:21:be:33:e9
>
>I've tested this on 2.6.31 with devices and support VLAN acceleration
>and those that do not as well as a backport on 2.6.18 with success.
>
>Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
>
>---
> drivers/net/bonding/bond_main.c | 3 +++
> net/8021q/vlan_core.c | 2 ++
> net/core/dev.c | 6 +++---
> 3 files changed, 8 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>index 726bd75..aee8973 100644
>--- a/drivers/net/bonding/bond_main.c
>+++ b/drivers/net/bonding/bond_main.c
>@@ -2691,6 +2691,9 @@ static int bond_arp_rcv(struct sk_buff *skb, struct net_device *dev, struct pack
> unsigned char *arp_ptr;
> __be32 sip, tip;
>
>+ while (dev->priv_flags & IFF_802_1Q_VLAN)
>+ dev = vlan_dev_real_dev(dev);
>+
> if (!(dev->priv_flags & IFF_BONDING) || !(dev->flags & IFF_MASTER))
> goto out;
>
>diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
>index e75a2f3..8d8a778 100644
>--- a/net/8021q/vlan_core.c
>+++ b/net/8021q/vlan_core.c
>@@ -14,6 +14,7 @@ int __vlan_hwaccel_rx(struct sk_buff *skb, struct vlan_group *grp,
> if (skb_bond_should_drop(skb))
> goto drop;
>
>+ skb->skb_iif = skb->dev->ifindex;
> __vlan_hwaccel_put_tag(skb, vlan_tci);
> skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
>
>@@ -85,6 +86,7 @@ vlan_gro_common(struct napi_struct *napi, struct vlan_group *grp,
> if (skb_bond_should_drop(skb))
> goto drop;
>
>+ skb->skb_iif = skb->dev->ifindex;
> __vlan_hwaccel_put_tag(skb, vlan_tci);
> skb->dev = vlan_group_get_device(grp, vlan_tci & VLAN_VID_MASK);
>
>diff --git a/net/core/dev.c b/net/core/dev.c
>index 5d131c2..eeee269 100644
>--- a/net/core/dev.c
>+++ b/net/core/dev.c
>@@ -2439,8 +2439,8 @@ int netif_receive_skb(struct sk_buff *skb)
> skb->skb_iif = skb->dev->ifindex;
>
> null_or_orig = NULL;
>- orig_dev = skb->dev;
>- if (orig_dev->master) {
>+ orig_dev = __dev_get_by_index(dev_net(skb->dev),skb->skb_iif);
>+ if (orig_dev->master && !(skb->dev->priv_flags & IFF_802_1Q_VLAN)) {
> if (skb_bond_should_drop(skb))
> null_or_orig = orig_dev; /* deliver only exact match */
> else
>@@ -2492,7 +2492,7 @@ ncls:
> &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
> if (ptype->type == type &&
> (ptype->dev == null_or_orig || ptype->dev == skb->dev ||
>- ptype->dev == orig_dev)) {
>+ ptype->dev == orig_dev || ptype->dev == orig_dev->master)) {
> if (pt_prev)
> ret = deliver_skb(skb, pt_prev, orig_dev);
> pt_prev = ptype;
>--
>1.6.2.5
>
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: Subject: [PATCH 3/6] bna: Brocade 10Gb Ethernet device driver
From: David Miller @ 2009-12-01 0:21 UTC (permalink / raw)
To: ddutt; +Cc: netdev
In-Reply-To: <200911260928.nAQ9SW9r003958@blc-10-10.brocade.com>
From: Debashis Dutt <ddutt@brocade.com>
Date: Thu, 26 Nov 2009 01:28:32 -0800
> +#define BNA_PAGE_SIZE PAGE_SIZE
> +#define BNA_PAGE_SHIFT PAGE_SHIFT
> +
> +#define BNA_ASSERT(x) BUG_ON(!(x))
> +
> +#define bna_dma_addr64(_x) cpu_to_be64((_x))
> +
> +#define bfa_addr_t char __iomem *
> +#define bfa_u32(__pa64) ((__pa64) >> 32)
> +
> +#define bfa_reg_read(_raddr) readl(_raddr)
> +#define bfa_reg_write(_raddr, _val) writel(_val, _raddr)
> +#define bfa_os_panic()
All of the definitions in this header file are inappropriate.
Use the standard types and interfaces the Linux kernel provides in the
actual source code.
I know what you're trying to do, but it's not appropriate.
You want a layer of abstract types and macros so you can compile the
same code in different environments and just swap out this one header
file and we've been trying to tell you over and over again that you
can't do that.
Also, the "version.h" file that contains just one macro definition is
excessive. This driver already has move than 30 (!!!!!) header files,
that's absolutely and completely rediculious.
Do you know that there are many modern network device drivers in the
kernel tree that exist in one single C and one single header file?
That's the model you should drift your driver towards, rather than
one that has on the order of 30+ source files.
This driver still needs a ton of work, sorry...
^ 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