* Re: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior
From: Stephen Hemminger @ 2011-12-01 16:57 UTC (permalink / raw)
To: David Laight; +Cc: Hagen Paul Pfeifer, Eric Dumazet, netdev
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6D8AEFA@saturn3.aculab.com>
On Thu, 1 Dec 2011 16:38:51 -0000
"David Laight" <David.Laight@ACULAB.COM> wrote:
>
> > One idea to do small delays at higher speed is to insert
> > dummy pad frames into the device.
> > It would mean generating garbage, but would allow for
> > highly accurate fine grain delay.
>
> Not a good idea.
> They would have to be sent to a known MAC address
> otherwise all the ethernet switches would forward them
> on all output ports.
>
> David
>
>
Yes it would have to be a constant destination, not sure if there
is a discard value in Ethernet protocol spec.
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-01 16:56 UTC (permalink / raw)
To: David Lamparter; +Cc: netdev
In-Reply-To: <20111201165040.GL589422@jupiter.n2.diac24.net>
> # ip -4 a l eth0; ip r l match 0.0.0.0; ip r l exact 10.255.255.1
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
> state UNKNOWN qlen 1000
> inet 87.106.131.203/32 scope global eth0
> default via 10.255.255.1 dev eth0
> 10.255.255.1 dev eth0 scope link
Wow, how does that even work? Every time I think I know something, I
get challenged. I should make that a slogan.
- Greg
^ permalink raw reply
* Re: [PATCH v4 0/10] bql: Byte Queue Limits
From: Kirill Smelkov @ 2011-12-01 16:50 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, eric.dumazet, netdev
In-Reply-To: <CA+mtBx_-_4zzweT61vYKe-c8ngMO9jF5PoYa4gC1aNKREjbwgQ@mail.gmail.com>
On Tue, Nov 29, 2011 at 10:31:03AM -0800, Tom Herbert wrote:
> On Tue, Nov 29, 2011 at 9:47 AM, David Miller <davem@davemloft.net> wrote:
> > From: Eric Dumazet <eric.dumazet@gmail.com>
> > Date: Tue, 29 Nov 2011 17:46:24 +0100
> >
> >> I did sucessful tests with tg3 (I'll provide the patch for bnx2 shortly)
> >>
> >> Some details probably can be polished, but I believe your v4 is ready
> >> for inclusion.
> >>
> >> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> >
> > Agreed, all applied to net-next, thanks!
> >
> > Tom, please keep an eye out for regression or suggestion reports.
> >
>
> Will do. I am well aware of how invasive this is in the data path ;-)
> I'll add a doc describing BQL also.
>
> By the way, the way to disable BQL at runtime is the 'echo max >
> /sys/class/net/eth<n>/queues/tx-<m>/byte_queue_limits/limit_min
One "regression" is it is now not possible to disable BQL at compile time,
because CONFIG_BQL can't be set to "n" via usual ways.
Description and patch below. Thanks.
---- 8< ----
From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Thu, 1 Dec 2011 20:36:06 +0400
Subject: [PATCH] net: Allow users to set CONFIG_BQL=n
Commit 114cf580 (bql: Byte queue limits) added new config option without
description, which means neither `make oldconfig` nor `make menuconfig`
ask for it -- the option is simply set to default y automatically.
Make the option actually configurable via adding stub description.
Cc: Tom Herbert <therbert@google.com>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
net/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/Kconfig b/net/Kconfig
index 2d99873..c120631 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -240,7 +240,7 @@ config NETPRIO_CGROUP
a per-interface basis
config BQL
- boolean
+ boolean "Byte Queue Limits"
depends on SYSFS
select DQL
default y
--
1.7.8.rc4.327.g599a2
^ permalink raw reply related
* Re: ebtables on a stick
From: David Lamparter @ 2011-12-01 16:50 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A048F9@mail733.InfraSupportEtc.com>
On Thu, Dec 01, 2011 at 09:29:59AM -0600, Greg Scott wrote:
> > That /32 just means "on my ethernet segment i'm alone with that
> > address". If the windows box has /28 as subnet mask, it will try to
> ARP
> > for other hosts from that subnet, instead of going through the router.
> > So, that'll break connectivity to them...
>
> I never did get this. Right now, it's a test Windows box, but eventually
> it will be something else. It's connected to eth1 and needs to go
> through the router - right - so how does it find its gateway at
> 1.2.115.146 on eth0? And setting the mask to /32 makes it even
> stranger.
>
> As long as I can get to it - why don't I try setting it to /32 and let's
> see what happens. Worst case, I have to jump in the car I guess. Well,
> Windows won't allow a mask of 255.255.255.255. I wonder how the real
> stuff I'll eventually connect at that IP Address will behave with a /32
> mask?
The default gateway is always assumed to be on-link / arp-able. Because
if it wasn't, it wouldn't be an usable default gateway...
On the box I'm writing this mail from right now:
# ip -4 a l eth0; ip r l match 0.0.0.0; ip r l exact 10.255.255.1
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UNKNOWN qlen 1000
inet 87.106.131.203/32 scope global eth0
default via 10.255.255.1 dev eth0
10.255.255.1 dev eth0 scope link
(that config is pushed through DHCP)
> I wonder what happens with some of the stuff I'm NATing? There's a
> website at public IP 1.2.115.151, private 192.168.10.8. Pinging
> 1.2.115.151 and then arp -a; it shows the firewall eth1 MAC Address.
> Makes sense - it is NATed after all.
I don't work with windows and have no clue what's happening there :)
Well, as long as it works, I guess that's fine.
-David
^ permalink raw reply
* Re: Daughterboard Jetway JAD3RTLANG with three RTL-8110SC/8169SC Gigabit Ethernet is curious
From: Markus Feldmann @ 2011-12-01 16:41 UTC (permalink / raw)
To: netdev
In-Reply-To: <jb4m9i$j5c$1@dough.gmane.org>
Sorry, i posted the output from my client :-)
Here comes the one from my server:
> 04:04.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
> Subsystem: Jetway Information Co., Ltd. Device 10ec
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 10
> Region 0: I/O ports at de00 [size=256]
> Region 1: Memory at fdbff000 (32-bit, non-prefetchable) [size=256]
> Expansion ROM at fdbc0000 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: r8169
>
> 04:06.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
> Subsystem: Jetway Information Co., Ltd. Device 10ec
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 11
> Region 0: I/O ports at dc00 [size=256]
> Region 1: Memory at fdbfe000 (32-bit, non-prefetchable) [size=256]
> Expansion ROM at fda00000 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: r8169
>
> 04:07.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8110SC/8169SC Gigabit Ethernet (rev 10)
> Subsystem: Jetway Information Co., Ltd. Device 10ec
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
> Interrupt: pin A routed to IRQ 5
> Region 0: I/O ports at da00 [size=256]
> Region 1: Memory at fdbfd000 (32-bit, non-prefetchable) [size=256]
> Expansion ROM at fda20000 [disabled] [size=128K]
> Capabilities: [dc] Power Management version 2
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Kernel driver in use: r8169
regards Markus
^ permalink raw reply
* Re: [PATCH v4 06/10] e1000e: Support for byte queue limits
From: Eric Dumazet @ 2011-12-01 16:40 UTC (permalink / raw)
To: Tom Herbert; +Cc: Jesse Brandeburg, davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <CA+mtBx80aoWtDh3=gMnfVCi9r5E_bjqgreoa-yjwDc5+kcocjg@mail.gmail.com>
Le jeudi 01 décembre 2011 à 08:32 -0800, Tom Herbert a écrit :
> > OK, as stated on your other thread, its obvious this driver (and
> > probably other intel drivers) made assumptions that are now obsolete,
> > since skb head can contain some data payload, not only (MAC+IP+TCP)
> > headers.
> >
> Looks like similar is in several Intel drivers. Only other driver I
> found that is using the false assumption is tg3 IPv6 gso path.
>
> > If Intel guys cannot afford approximate the bytecount by skb->len, I
> > suggest to use same trick found in
> > drivers/net/ethernet/intel/igb/igb_main.c
> >
> > static int igb_tso(struct igb_ring *tx_ring,
> > ...
> > /* compute header lengths */
> > l4len = tcp_hdrlen(skb);
> > *hdr_len = skb_transport_offset(skb) + l4len;
> >
> I noticed a similar technique used by several drivers. it's fine if
> it already knew the packet was TCP. Just assuming that a GSO packet
> is TCP might be a new bug, so in the e1000e driver they would need to
> check the type (gso_type == SKB_GSO_TCPV4 or SKB_GSO_TCPV6).
>
> I'm not sure that tcp_hdrlen is even being used correctly in the other
> drivers. For instance in bnx2x, tcp_hdrlen is called after checking
> skb_is_gso_v6(skb) and skb_is_gso(skb). If the former is true then in
> fact it is a TCP packet (gso_type is SKB_GSO_TCPV6) , but the if the
> latter is true it only proves that is is GSO packet (gso_type not
> checked, only gso_size>0)-- the packet might be a fragment UDP packet
> for instance, so tcphdr_len is not valid on those skbs.
To my knowledge, only one NIC (neterion/s2io) supports NETIF_F_UFO.
So all others only receive tcp gso frames.
^ permalink raw reply
* RE: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior
From: David Laight @ 2011-12-01 16:38 UTC (permalink / raw)
To: Stephen Hemminger, Hagen Paul Pfeifer; +Cc: Eric Dumazet, netdev
In-Reply-To: <20111201082436.20f21e52@nehalam.linuxnetplumber.net>
> One idea to do small delays at higher speed is to insert
> dummy pad frames into the device.
> It would mean generating garbage, but would allow for
> highly accurate fine grain delay.
Not a good idea.
They would have to be sent to a known MAC address
otherwise all the ethernet switches would forward them
on all output ports.
David
^ permalink raw reply
* Re: [PATCH v4 06/10] e1000e: Support for byte queue limits
From: Tom Herbert @ 2011-12-01 16:32 UTC (permalink / raw)
To: Eric Dumazet
Cc: Jesse Brandeburg, davem@davemloft.net, netdev@vger.kernel.org
In-Reply-To: <1322734334.2335.20.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
> OK, as stated on your other thread, its obvious this driver (and
> probably other intel drivers) made assumptions that are now obsolete,
> since skb head can contain some data payload, not only (MAC+IP+TCP)
> headers.
>
Looks like similar is in several Intel drivers. Only other driver I
found that is using the false assumption is tg3 IPv6 gso path.
> If Intel guys cannot afford approximate the bytecount by skb->len, I
> suggest to use same trick found in
> drivers/net/ethernet/intel/igb/igb_main.c
>
> static int igb_tso(struct igb_ring *tx_ring,
> ...
> /* compute header lengths */
> l4len = tcp_hdrlen(skb);
> *hdr_len = skb_transport_offset(skb) + l4len;
>
I noticed a similar technique used by several drivers. it's fine if
it already knew the packet was TCP. Just assuming that a GSO packet
is TCP might be a new bug, so in the e1000e driver they would need to
check the type (gso_type == SKB_GSO_TCPV4 or SKB_GSO_TCPV6).
I'm not sure that tcp_hdrlen is even being used correctly in the other
drivers. For instance in bnx2x, tcp_hdrlen is called after checking
skb_is_gso_v6(skb) and skb_is_gso(skb). If the former is true then in
fact it is a TCP packet (gso_type is SKB_GSO_TCPV6) , but the if the
latter is true it only proves that is is GSO packet (gso_type not
checked, only gso_size>0)-- the packet might be a fragment UDP packet
for instance, so tcphdr_len is not valid on those skbs.
^ permalink raw reply
* Re: ipv4: broadcast sometimes leaves wrong interface (since commit e066008b38ca9ace1b6de8dbbac8ed460640791d)
From: Jeroen van Ingen @ 2011-12-01 16:25 UTC (permalink / raw)
To: Julian Anastasov; +Cc: David Miller, netdev
In-Reply-To: <alpine.LFD.2.00.1111300148400.2328@ja.ssi.bg>
Hi Julian, David,
> > > May be the solution is to convert inet_addr_lst
> > > from hlist to normal list, so that we can append new
> > > addresses at tail and __ip_dev_find to find the first
> > > device where IP was added.
> >
> > Sure, but do we really want to guarentee this behavior forever?
>
> I remember for such issue with ipsec%d interfaces
> years ago. May be the PPP servers should be configured
> to use another local IP for PPP devices because broadcasts
> and multicasts may need their own local address - they can use
> addresses to refer to output devices.
>
> Not sure what else we can do, now we have to waste
> 1-2KB for this to work before someone recreates the eth
> addresses and changes the ordering.
FYI: we successfully tested two scenarios that provide a workaround with
the current kernel versions:
1) Explicitly configuring Radius to use one of the secondary IPs as
source for the DHCP broadcast. Since the IP we chose is only bound to
eth0, this broadcast goes out the correct interface. Other
system-generated broadcast would probably still go out the wrong
interface, but at least it allows us to accept more than one PPTP
client.
2) Adding an option to the "pppd" config, so the ppp-devices it creates
do not use the primary IP from eth0 but rather one of the secondary
addresses. This way we don't have to modify any other software that
might generate a broadcast.
While the second option provides a workable solution for us, we're still
under the impression that this change in behavior might cause a problem
for other users and/or configurations as well. We'll leave the rest of
the considerations to the real experts, while remaining curious about
the outcome :)
Thanks again for your assistance.
Regards,
Jeroen van Ingen
ICT Service Centre
University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] netem: add cell concept to simulate special MAC behavior
From: Stephen Hemminger @ 2011-12-01 16:24 UTC (permalink / raw)
To: Hagen Paul Pfeifer; +Cc: Eric Dumazet, netdev
In-Reply-To: <61abe6ff1aa870d1b885ce88814920d4@localhost>
One idea to do small delays at higher speed is to insert dummy pad frames
into the device. It would mean generating garbage, but would allow for
highly accurate fine grain delay.
^ permalink raw reply
* Re: [PATCH 4/4] nfc: Remove function tracer like entry messages
From: Samuel Ortiz @ 2011-12-01 16:01 UTC (permalink / raw)
To: Joe Perches
Cc: Lauro Ramos Venancio, Aloisio Almeida Jr, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <038f52f06c7c878e0e2b4965f3a64ac72cf5196d.1322595343.git.joe@perches.com>
Hi Joe,
On Tue, Nov 29, 2011 at 11:37:35AM -0800, Joe Perches wrote:
> Logging messages that mimic function tracer enter/exit
> aren't necessary. Just remove them.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Samuel Ortiz <sameo@linux.intel.com>
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH 1/4] nfc: Use standard logging styles
From: Samuel Ortiz @ 2011-12-01 15:59 UTC (permalink / raw)
To: Joe Perches
Cc: Lauro Ramos Venancio, Aloisio Almeida Jr, David S. Miller,
linux-wireless, netdev, linux-kernel
In-Reply-To: <6c89a76ddb76926febe36fe5be514cb186e39a76.1322595343.git.joe@perches.com>
Hi Joe,
On Tue, Nov 29, 2011 at 11:37:32AM -0800, Joe Perches wrote:
> Using the normal logging styles is preferred over
> subsystem specific styles when the subsystem does
> not take a specific struct.
>
> Convert nfc_<level> specific messages to pr_<level>
> Add newlines to uses.
>
I would be fine with moving to pr_debug, but I'd like the pr_fmt() routine to
include the function name as well.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-01 15:29 UTC (permalink / raw)
To: David Lamparter; +Cc: netdev
In-Reply-To: <20111201144745.GK589422@jupiter.n2.diac24.net>
> That /32 just means "on my ethernet segment i'm alone with that
> address". If the windows box has /28 as subnet mask, it will try to
ARP
> for other hosts from that subnet, instead of going through the router.
> So, that'll break connectivity to them...
I never did get this. Right now, it's a test Windows box, but eventually
it will be something else. It's connected to eth1 and needs to go
through the router - right - so how does it find its gateway at
1.2.115.146 on eth0? And setting the mask to /32 makes it even
stranger.
As long as I can get to it - why don't I try setting it to /32 and let's
see what happens. Worst case, I have to jump in the car I guess. Well,
Windows won't allow a mask of 255.255.255.255. I wonder how the real
stuff I'll eventually connect at that IP Address will behave with a /32
mask?
Digging a little deeper...
>From Windows, arp -a shows both 1.2.114.146 and 192.168.10.1 with a MAC
Address of 00-0d-88-31-d8-24. Looking on the firewall with ip link show
- sure enough, that's the MAC Address of eth1.
I wonder what happens with some of the stuff I'm NATing? There's a
website at public IP 1.2.115.151, private 192.168.10.8. Pinging
1.2.115.151 and then arp -a; it shows the firewall eth1 MAC Address.
Makes sense - it is NATed after all.
Launching IE from that host - nope - that NATed website doesn't come up.
But it doesn't time out, it errors right away, suggesting it was
rejected instead of dropped. Well, OK - that's probably because I don't
have any firewall rules to handle this case (and probably don't need any
because this will never happen in production), so it went right to the
firewall itself and was properly rejected.
But the eventual box at this address will probably have its own built-in
management website. I wonder what happens with telnets on port 80 and
443 to it? They both work; the firewall forwards it and the Windows box
rejects it. So when there's a real website sitting there, it should be
OK.
So the /28 mask feels OK so far...
- Greg
^ permalink raw reply
* Re: ebtables on a stick
From: David Lamparter @ 2011-12-01 14:47 UTC (permalink / raw)
To: Greg Scott; +Cc: David Lamparter, netdev
In-Reply-To: <925A849792280C4E80C5461017A4B8A2A048F8@mail733.InfraSupportEtc.com>
On Thu, Dec 01, 2011 at 08:39:07AM -0600, Greg Scott wrote:
> I wonder what's different this morning? A bunch of firewall conntrack
> entries would have expired by now. I was changing rules fast and
> furious last night, maybe there were some stale conntrack entries that
> messed with my head. But this morning it's working as expected.
>
> Must be an important project, otherwise it wouldn't give me all this
> trouble.
Heh. Nice to see you got it to work.
A few last words about the subnet mask on the windows box:
The 1.2.115.144/28 subnet is on eth0 on your router. The windows host
with 1.2.115.157 is _not_ connected to that subnet. It is on eth1 on
your router, and it can't reach any hosts from 1.2.115.144/28 without
going through your router, so /32 is the correct configuration there.
That /32 just means "on my ethernet segment i'm alone with that
address". If the windows box has /28 as subnet mask, it will try to ARP
for other hosts from that subnet, instead of going through the router.
So, that'll break connectivity to them...
-David
^ permalink raw reply
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-01 14:39 UTC (permalink / raw)
To: David Lamparter; +Cc: netdev
In-Reply-To: <20111201071456.GJ589422@jupiter.n2.diac24.net>
Well now, this is interesting. Hopefully the emailer won't garble
below.
3.4.2.129 is me. I sent some pings from here to my public host.
Listening on eth0 on the firewall, here they come. But the interesting
part is trying again, this time listening on eth1 on the firewall. I
forwarded them! So why no echo reply? That makes me wonder if I did
something dumb on the test host I set up. I'll probably hop in the car
and drive over there and take a look.
[root@ehac-fw2011 firewall-scripts]#
[root@ehac-fw2011 firewall-scripts]# /usr/sbin/tcpdump -i eth0 net
3.4.2.128/27 and port not 22 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:18:29.653384 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
72, length 40
08:18:34.201405 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
73, length 40
08:18:39.209183 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
74, length 40
08:18:44.202242 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
75, length 40
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
[root@ehac-fw2011 firewall-scripts]# /usr/sbin/tcpdump -i eth1 net
3.4.2.128/27 and port not 22 -nn
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
08:18:58.871185 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
76, length 40
08:19:03.719756 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
77, length 40
08:19:08.727342 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
78, length 40
08:19:13.704391 IP 3.4.2.129 > 1.2.115.157: ICMP echo request, id 1, seq
79, length 40
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
[root@ehac-fw2011 firewall-scripts]#
Or - easier than hopping in the car - I did set it up to allow RDP in.
I wonder . . .
Yup, I can do an RDP session into it from here. And sure enough, the
Windows personal firewall is turned on. Turning it off - holy moley,
round trip pings from here! And now I can also ping google from that
test workstation.
I wonder what's different this morning? A bunch of firewall conntrack
entries would have expired by now. I was changing rules fast and
furious last night, maybe there were some stale conntrack entries that
messed with my head. But this morning it's working as expected.
Must be an important project, otherwise it wouldn't give me all this
trouble.
- Greg
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Konrad Rzeszutek Wilk @ 2011-12-01 14:35 UTC (permalink / raw)
To: Borislav Petkov
Cc: Linux SCSI List, Florian Mickler, Network Development,
Linux PM List, x86, Linux Wireless List,
Linux Kernel Mailing List, DRI, Linux ACPI, mingo, hpa, tglx,
Kernel Testers List, Linus Torvalds, Andrew Morton,
Maciej Rutecki
In-Reply-To: <20111201113919.GC31552@aftab>
> >From what I can see, you get the following callchain:
>
> start_kernel
> |-> setup_arch
> |-> x86_init.oem.arch_setup = xen_arch_setup
> ....
> |-> check_bugs
> |-> identify_boot_cpu
> |-> identify_cpu
> |-> select_idle_routine
>
>
> so xen_arch_setup will set pm_idle and select_idle_routine will honour
> it. I'm being told this is run either in the dom0 or the paravirt guest
> and if so, I don't see any issue with this for baremetal. So you can
> have my ACK provided this is tested on baremetal too.
Tested on baremetal and there were no abnormalities. Thanks!
^ permalink raw reply
* [PATCH iproute2] red: make burst optional
From: Eric Dumazet @ 2011-12-01 14:25 UTC (permalink / raw)
To: Dave Taht, Stephen Hemminger; +Cc: David Miller, netdev
In-Reply-To: <1322737471.2335.25.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Documentation advises to set burst to (min+min+max)/(3*avpkt)
Let tc do this automatically if user doesnt provide burst himself.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
tc/q_choke.c | 2 +-
tc/q_gred.c | 10 +++++++---
tc/q_red.c | 11 +++++++----
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/tc/q_choke.c b/tc/q_choke.c
index 04a864f..7816f62 100644
--- a/tc/q_choke.c
+++ b/tc/q_choke.c
@@ -133,7 +133,7 @@ static int choke_parse_opt(struct qdisc_util *qu, int argc, char **argv,
return -1;
}
if (wlog >= 10)
- fprintf(stderr, "CHOKE: WARNING. Burst %d seems to be to large.\n", burst);
+ fprintf(stderr, "CHOKE: WARNING. Burst %d seems to be too large.\n", burst);
opt.Wlog = wlog;
wlog = tc_red_eval_P(opt.qth_min*avpkt, opt.qth_max*avpkt, probability);
diff --git a/tc/q_gred.c b/tc/q_gred.c
index 59651d3..5fa0cc7 100644
--- a/tc/q_gred.c
+++ b/tc/q_gred.c
@@ -215,19 +215,23 @@ static int gred_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct n
if (rate == 0)
get_rate(&rate, "10Mbit");
- if (!opt.qth_min || !opt.qth_max || !burst || !opt.limit || !avpkt ||
+ if (!opt.qth_min || !opt.qth_max || !opt.limit || !avpkt ||
(opt.DP<0)) {
- fprintf(stderr, "Required parameter (min, max, burst, limit, "
+ fprintf(stderr, "Required parameter (min, max, limit, "
"avpkt, DP) is missing\n");
return -1;
}
+ if (!burst) {
+ burst = (2 * opt.qth_min + opt.qth_max) / (3 * avpkt);
+ fprintf(stderr, "GRED: set burst to %u\n", burst);
+ }
if ((wlog = tc_red_eval_ewma(opt.qth_min, burst, avpkt)) < 0) {
fprintf(stderr, "GRED: failed to calculate EWMA constant.\n");
return -1;
}
if (wlog >= 10)
- fprintf(stderr, "GRED: WARNING. Burst %d seems to be to "
+ fprintf(stderr, "GRED: WARNING. Burst %d seems to be too "
"large.\n", burst);
opt.Wlog = wlog;
if ((wlog = tc_red_eval_P(opt.qth_min, opt.qth_max, probability)) < 0) {
diff --git a/tc/q_red.c b/tc/q_red.c
index 4b1b889..6e58d7a 100644
--- a/tc/q_red.c
+++ b/tc/q_red.c
@@ -104,17 +104,20 @@ static int red_parse_opt(struct qdisc_util *qu, int argc, char **argv, struct nl
if (rate == 0)
get_rate(&rate, "10Mbit");
- if (!opt.qth_min || !opt.qth_max || !burst || !opt.limit || !avpkt) {
- fprintf(stderr, "Required parameter (min, max, burst, limit, avpkt) is missing\n");
+ if (!opt.qth_min || !opt.qth_max || !opt.limit || !avpkt) {
+ fprintf(stderr, "RED: Required parameter (min, max, limit, avpkt) is missing\n");
return -1;
}
-
+ if (!burst) {
+ burst = (2 * opt.qth_min + opt.qth_max) / (3 * avpkt);
+ fprintf(stderr, "RED: set burst to %u\n", burst);
+ }
if ((wlog = tc_red_eval_ewma(opt.qth_min, burst, avpkt)) < 0) {
fprintf(stderr, "RED: failed to calculate EWMA constant.\n");
return -1;
}
if (wlog >= 10)
- fprintf(stderr, "RED: WARNING. Burst %d seems to be to large.\n", burst);
+ fprintf(stderr, "RED: WARNING. Burst %d seems to be too large.\n", burst);
opt.Wlog = wlog;
if ((wlog = tc_red_eval_P(opt.qth_min, opt.qth_max, probability)) < 0) {
fprintf(stderr, "RED: failed to calculate probability.\n");
^ permalink raw reply related
* RE: ebtables on a stick
From: Greg Scott @ 2011-12-01 14:10 UTC (permalink / raw)
To: David Lamparter; +Cc: netdev
In-Reply-To: <20111201071456.GJ589422@jupiter.n2.diac24.net>
Oh - woops:
>> IP 1.2.115.157, default gw 1.2.115.146.
>
> Note that since the IP should be 1.2.115.157/_32_, it doesn't make any
> difference whether you use 1.2.115.146 for the defgw or 192.168.10.1,
> since both are out-of-subnet.
Right this second, the whole thing really is 1.2.115.157/28, or mask
255.255.255.240. So from that host's point of view the default gw makes
sense. You really want me to set that up as a /32? I don't get it.
.
.
.
>> As a troubleshooting step, I also put in:
>> /sbin/ip addr add 1.2.115.146/28 dev eth1; so now both eth0 and eth1
have the same IP Address. This feels >ugly and I think I'll take it out
because it made no difference.
>
>I agree, please remove.
I put it in last night because this was the "trick" I had to do years
ago when I used proxy ARP and that scary switch turning it on for
everything. Btw, there are still write-ups out there advocating that
approach.
.
.
.
>> $IPTABLES -A FORWARD -s 1.2.115.157 -j ACCEPT
>
> Where is the reverse rule of this? -d 1.2.115.157 -j ACCEPT
>
>> $IPTABLES -A FORWARD -s 192.168.10.0/24 -d 1.2.115.157 -j ACCEPT
>> $IPTABLES -A FORWARD -p TCP --dport 1720 -d $ADR -j allowed
>> $IPTABLES -A FORWARD -p TCP -s $MGMT_IP -d $ADR -j allowed
>
>(what's $ADR?)
I was having trouble keeping my eyes open last night. $ADR ends up being
1.2.115.157. That's the reverse rule you were looking for. And then
$MGMT_IP is the rule that lets me in no matter what protocol/port.
Allowed is a user defined chain that checks for the right TCP handshake.
I should probably change the $MGMT_IP rule to just ACCEPT. This won't
matter though - I did my ping tests last night physically sitting in
front of that XP host and trying to ping google.
> Firewall rules?
There are a bunch of 'em to handle a website and a few ftp sites and a
PPTP VPN and the H.323 stuff I'm trying to hook back up. I have a
little script named "allow-all-with-nat" that turns all the filtering
rules off, leaving all the NAT rules in place. Running that makes no
difference. The last time I posted a whole ruleset I was roundly
chastised because it was too complicated and we went off into a rathole
about H.323.
- Greg
^ permalink raw reply
* [PATCH v2] icplus: mdio_write(), remove unnecessary for loop
From: Patrick Kelle @ 2011-12-01 13:26 UTC (permalink / raw)
To: netdev; +Cc: davem, romieu, sorbica, Patrick Kelle
At this point the variable j is always set to 7 and the code within
the loop has to run only once anyway.
As suggested by David Miller:
"You can simply this even further since p[7] is what is used here,
and this means len is one, the inner loop therefore executes only
once, and the p[7].field value is not used (it's zero in the table)
and the write to it is completely thrown away."
Signed-off-by: Patrick Kelle <patrick.kelle81@gmail.com>
---
drivers/net/ethernet/icplus/ipg.c | 13 +++----------
1 files changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/icplus/ipg.c b/drivers/net/ethernet/icplus/ipg.c
index 8fd80a0..075451d 100644
--- a/drivers/net/ethernet/icplus/ipg.c
+++ b/drivers/net/ethernet/icplus/ipg.c
@@ -371,16 +371,9 @@ static void mdio_write(struct net_device *dev, int phy_id, int phy_reg, int val)
}
/* The last cycle is a tri-state, so read from the PHY. */
- for (j = 7; j < 8; j++) {
- for (i = 0; i < p[j].len; i++) {
- ipg_write_phy_ctl(ioaddr, IPG_PC_MGMTCLK_LO | polarity);
-
- p[j].field |= ((ipg_r8(PHY_CTRL) &
- IPG_PC_MGMTDATA) >> 1) << (p[j].len - 1 - i);
-
- ipg_write_phy_ctl(ioaddr, IPG_PC_MGMTCLK_HI | polarity);
- }
- }
+ ipg_write_phy_ctl(ioaddr, IPG_PC_MGMTCLK_LO | polarity);
+ ipg_r8(PHY_CTRL);
+ ipg_write_phy_ctl(ioaddr, IPG_PC_MGMTCLK_HI | polarity);
}
static void ipg_set_led_mode(struct net_device *dev)
--
1.7.7.1
^ permalink raw reply related
* [PATCH net] ipv4: flush route cache after change accept_local
From: Weiping Pan @ 2011-12-01 11:47 UTC (permalink / raw)
Cc: Weiping Pan, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy,
open list:NETWORKING [IPv4/..., open list
After reset ipv4_devconf->data[IPV4_DEVCONF_ACCEPT_LOCAL] to 0,
we should flash route cache, or it will continue receive packets with local
source address, which should be dropped.
Signed-off-by: Weiping Pan <panweiping3@gmail.com>
---
net/ipv4/devinet.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index c6b5092..de1a772 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1490,7 +1490,9 @@ static int devinet_conf_proc(ctl_table *ctl, int write,
void __user *buffer,
size_t *lenp, loff_t *ppos)
{
+ int old_value = *(int *)ctl->data;
int ret = proc_dointvec(ctl, write, buffer, lenp, ppos);
+ int new_value = *(int *)ctl->data;
if (write) {
struct ipv4_devconf *cnf = ctl->extra1;
@@ -1501,6 +1503,9 @@ static int devinet_conf_proc(ctl_table *ctl, int write,
if (cnf == net->ipv4.devconf_dflt)
devinet_copy_dflt_conf(net, i);
+ if ((i == IPV4_DEVCONF_ACCEPT_LOCAL - 1))
+ if ((new_value == 0) && (old_value != 0))
+ rt_cache_flush(net, 0);
}
return ret;
--
1.7.4
^ permalink raw reply related
* Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Patrick McHardy @ 2011-12-01 11:46 UTC (permalink / raw)
To: Hans Schillstrom
Cc: pablo, jengelh, netfilter-devel, netdev, hans.schillstrom
In-Reply-To: <jec613b.2c905808e36d8b8192d285d691c5499b@obelix.schillstrom.com>
On 12/01/2011 12:39 PM, Hans Schillstrom wrote:
> t: Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
>> On 12/01/2011 12:05 PM, Hans Schillstrom wrote:
>>>>>> And final question, why not simply use ipv6_skip_exthdr()?
>>>>> problems with fragments...
>>>> So the probem is that it will return the transport layer protocol
>>>> header for fragments with frag_off == 0? We also have ipv6_find_hdr()
>>>> which we could modify to indicate this in the frag_off pointer.
>>> ipv6_find_hdr() will do the trick with a light modification
>>> What about a wrapper like:
>>>
>>> int __ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
>>> int target, unsigned short *fragoff, int *fragflg)
>>> {
>>> ...
>>> if (nexthdr == NEXTHDR_FRAGMENT) {
>>> unsigned short _frag_off;
>>> __be16 *fp;
>>>
>>> if (fragflg)
>>> fragflg = 1;
>>> fp = skb_header_pointer(skb,
>>> start+offsetof(struct frag_hdr,
>>> frag_off),
>>> sizeof(_frag_off),
>>> &_frag_off);
>>>
>>> ...
>>> }
>>>
>>> int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
>>> int target, unsigned short *fragoff)
>>> {
>>> return __ipv6_find_hdr(skb, offset, terget, fragoff, NULL);
>>> }
>> Hmm that would require to change all current callers.
> Nope, ipv6_find_hdr() looks the same,
> __ipv6_find_hdr() have an extra param.
Ah, right, apparently need more coffee :)
>> I was more thinking of unconditionally setting *frag_off in case of
>> fragments, then you can initialize it to some impossible value
>> like 0xffff and determine the presence of a fragment header
>> based on its value after calling ipv6_find_hdr().
> That's another way :-)
>
> Which one do you prefer ?
You way seems cleaner to me, lets do that.
^ permalink raw reply
* RE: Thanks
From: Song Li @ 2011-12-02 3:29 UTC (permalink / raw)
To: Recipients
l am a Staff of Hang Seng Bank HongKong, I do not know if we can work together in transferring $19,500,000.USD from my bank. Finally if you are interested I shall provide you with more details. my private Email: mrsong.lile@yahoo.cn
^ permalink raw reply
* Re[2]: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Hans Schillstrom @ 2011-12-01 11:39 UTC (permalink / raw)
To: Patrick McHardy; +Cc: pablo, jengelh, netfilter-devel, netdev, hans.schillstrom
t: Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
>
>On 12/01/2011 12:05 PM, Hans Schillstrom wrote:
>>>>> And final question, why not simply use ipv6_skip_exthdr()?
>>>> problems with fragments...
>>> So the probem is that it will return the transport layer protocol
>>> header for fragments with frag_off == 0? We also have ipv6_find_hdr()
>>> which we could modify to indicate this in the frag_off pointer.
>> ipv6_find_hdr() will do the trick with a light modification
>> What about a wrapper like:
>>
>> int __ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
>> int target, unsigned short *fragoff, int *fragflg)
>> {
>> ...
>> if (nexthdr == NEXTHDR_FRAGMENT) {
>> unsigned short _frag_off;
>> __be16 *fp;
>>
>> if (fragflg)
>> fragflg = 1;
>> fp = skb_header_pointer(skb,
>> start+offsetof(struct frag_hdr,
>> frag_off),
>> sizeof(_frag_off),
>> &_frag_off);
>>
>> ...
>> }
>>
>> int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
>> int target, unsigned short *fragoff)
>> {
>> return __ipv6_find_hdr(skb, offset, terget, fragoff, NULL);
>> }
>
>Hmm that would require to change all current callers.
Nope, ipv6_find_hdr() looks the same,
__ipv6_find_hdr() have an extra param.
> I was more thinking of unconditionally setting *frag_off in case of
>fragments, then you can initialize it to some impossible value
>like 0xffff and determine the presence of a fragment header
>based on its value after calling ipv6_find_hdr().
That's another way :-)
Which one do you prefer ?
^ permalink raw reply
* Re: 3.2-rc2+: Reported regressions from 3.0 and 3.1
From: Borislav Petkov @ 2011-12-01 11:39 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: Rafael J. Wysocki, tglx-hfZtesqFncYOwBW4kG4KsQ,
mingo-H+wXaHxf7aLQT0dZR+AlfA, hpa-YMNOUZJC4hwAvxtiuMwx3w,
x86-DgEjT+Ai2ygdnm+yROfE0A, Linux Kernel Mailing List,
Linux SCSI List, Linux ACPI, Network Development,
Linux Wireless List, DRI, Florian Mickler, Andrew Morton,
Kernel Testers List, Linus Torvalds, Linux PM List,
Maciej Rutecki, deepthi-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <20111130175936.GA15168-6K5HmflnPlqSPmnEAIUT9EEOCMrvLtNR@public.gmane.org>
On Wed, Nov 30, 2011 at 12:59:36PM -0500, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 29, 2011 at 07:34:28PM +0100, Borislav Petkov wrote:
> > On Tue, Nov 29, 2011 at 01:04:14PM -0500, Konrad Rzeszutek Wilk wrote:
> > > This patch:
>
>
> Borislav,
>
> Thanks for your review comments. How does this patch look? I believe
> I touched upon all of the things you mentioned.
>
> From eb6dbd80078312c428dde69e9313606b7513a2e6 Mon Sep 17 00:00:00 2001
> From: Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> Date: Mon, 21 Nov 2011 18:02:02 -0500
> Subject: [PATCH] xen/pm_idle: Make pm_idle be default_idle under Xen.
>
> This patch:
>
> commit d91ee5863b71e8c90eaf6035bff3078a85e2e7b5
> Author: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Date: Fri Apr 1 18:28:35 2011 -0400
>
> cpuidle: replace xen access to x86 pm_idle and default_idle
>
> ..scribble on pm_idle and access default_idle,
> have it simply disable_cpuidle() so acpi_idle will not load and
> architecture default HLT will be used.
>
> idea was to have one call - disable_cpuidle() which would make
> pm_idle not be molested by other code. It disallows cpuidle_idle_call
> to be set to pm_idle (which is excellent). But in the select_idle_routine()
> and idle_setup(), the pm_idle can still be set to either:
> amd_e400_idle, mwait_idle or default_idle. This depends on some
> CPU flags (MWAIT) and in AMD case on the type of CPU.
>
> In case of mwait_idle we can hit some instances where the hypervisor
> (Amazon EC2 specifically) sets the MWAIT and we get:
>
> Brought up 2 CPUs
> invalid opcode: 0000 [#1] SMP
> CPU 1
> Modules linked in:
>
> Pid: 0, comm: swapper Not tainted 3.1.0-0.rc6.git0.3.fc16.x86_64 #1
> RIP: e030:[<ffffffff81015d1d>] [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
> RSP: e02b:ffff8801d28ddf10 EFLAGS: 00010082
> RAX: ffff8801d28dc010 RBX: ffff8801d28ddfd8 RCX: 0000000000000000
> RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
> RBP: ffff8801d28ddf10 R08: 0000000000000000 R09: 0000000000000001
> R10: 0000000000000001 R11: ffff8801d28ddfd8 R12: ffffffff81b590d0
> R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
> FS: 0000000000000000(0000) GS:ffff8801dff81000(0000) knlGS:0000000000000000
> CS: e033 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: 0000000000000000 CR3: 0000000001a05000 CR4: 0000000000002660
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000
> Process swapper (pid: 0, threadinfo ffff8801d28dc000, task ffff8801d28cae60)
> Stack:
> ffff8801d28ddf40 ffffffff8100e2ed ffff8801dff8e390 c136dfe72feab515
> 0000000000000000 0000000000000000 ffff8801d28ddf50 ffffffff8149ee78
> 0000000000000000 0000000000000000 0000000000000000 0000000000000000
> Call Trace:
> [<ffffffff8100e2ed>] cpu_idle+0xae/0xe8
> [<ffffffff8149ee78>] cpu_bringup_and_idle+0xe/0x10
> RIP [<ffffffff81015d1d>] mwait_idle+0x6f/0xb4
> RSP <ffff8801d28ddf10>
>
> In case of amd_e400_idle we don't get so spectacular crashes, but
> we do end up making an MSR which is trapped in the hypervisor,
> and then follow it up with a yield hypercall. Meaning we end up
> going to hypervisor twice instead of just once.
>
> The previous behavior before v3.0 was that pm_idle was set
> to default_idle irregardless of select_idle_routine/idle_setup.
>
> We want to do that, but only for one specific case: Xen.
> This patch does that.
>
> Fixes RH BZ #739499 and Ubuntu #881076
> Reported-by: Stefan Bader <stefan.bader-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
> ---
> arch/x86/include/asm/system.h | 1 +
> arch/x86/kernel/process.c | 8 ++++++++
> arch/x86/xen/setup.c | 2 +-
> 3 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
> index c2ff2a1..2d2f01c 100644
> --- a/arch/x86/include/asm/system.h
> +++ b/arch/x86/include/asm/system.h
> @@ -401,6 +401,7 @@ extern unsigned long arch_align_stack(unsigned long sp);
> extern void free_init_pages(char *what, unsigned long begin, unsigned long end);
>
> void default_idle(void);
> +bool set_pm_idle_to_default(void);
>
> void stop_this_cpu(void *dummy);
>
> diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
> index 1f7f8c8..31f47ba 100644
> --- a/arch/x86/kernel/process.c
> +++ b/arch/x86/kernel/process.c
> @@ -404,6 +404,14 @@ void default_idle(void)
> EXPORT_SYMBOL(default_idle);
> #endif
>
> +bool set_pm_idle_to_default(void)
> +{
> + bool ret = !!pm_idle;
> +
> + pm_idle = default_idle;
> +
> + return ret;
> +}
> void stop_this_cpu(void *dummy)
> {
> local_irq_disable();
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 46d6d21..79dfb57 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -448,6 +448,6 @@ void __init xen_arch_setup(void)
> #endif
> disable_cpuidle();
> boot_option_idle_override = IDLE_HALT;
> -
> + WARN_ON(set_pm_idle_to_default());
> fiddle_vdso();
> }
>From what I can see, you get the following callchain:
start_kernel
|-> setup_arch
|-> x86_init.oem.arch_setup = xen_arch_setup
....
|-> check_bugs
|-> identify_boot_cpu
|-> identify_cpu
|-> select_idle_routine
so xen_arch_setup will set pm_idle and select_idle_routine will honour
it. I'm being told this is run either in the dom0 or the paravirt guest
and if so, I don't see any issue with this for baremetal. So you can
have my ACK provided this is tested on baremetal too.
Thanks.
--
Regards/Gruss,
Boris.
Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
^ permalink raw reply
* Re: [v4 PATCH 1/2] NETFILTER module xt_hmark, new target for HASH based fwmark
From: Patrick McHardy @ 2011-12-01 11:24 UTC (permalink / raw)
To: Hans Schillstrom
Cc: pablo, jengelh, netfilter-devel, netdev, hans.schillstrom
In-Reply-To: <jec613b.4edd5c40857133156bf40cef475e9234@obelix.schillstrom.com>
On 12/01/2011 12:05 PM, Hans Schillstrom wrote:
>>>> And final question, why not simply use ipv6_skip_exthdr()?
>>> problems with fragments...
>> So the probem is that it will return the transport layer protocol
>> header for fragments with frag_off == 0? We also have ipv6_find_hdr()
>> which we could modify to indicate this in the frag_off pointer.
> ipv6_find_hdr() will do the trick with a light modification
> What about a wrapper like:
>
> int __ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
> int target, unsigned short *fragoff, int *fragflg)
> {
> ...
> if (nexthdr == NEXTHDR_FRAGMENT) {
> unsigned short _frag_off;
> __be16 *fp;
>
> if (fragflg)
> fragflg = 1;
> fp = skb_header_pointer(skb,
> start+offsetof(struct frag_hdr,
> frag_off),
> sizeof(_frag_off),
> &_frag_off);
>
> ...
> }
>
> int ipv6_find_hdr(const struct sk_buff *skb, unsigned int *offset,
> int target, unsigned short *fragoff)
> {
> return __ipv6_find_hdr(skb, offset, terget, fragoff, NULL);
> }
Hmm that would require to change all current callers. I was more
thinking of unconditionally setting *frag_off in case of
fragments, then you can initialize it to some impossible value
like 0xffff and determine the presence of a fragment header
based on its value after calling ipv6_find_hdr().
^ 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