* Re: [PATCH 2/6] unicore32: add pkunity-v3 mac/net driver (umal)
From: Arnd Bergmann @ 2011-05-26 12:43 UTC (permalink / raw)
To: GuanXuetao; +Cc: linux-kernel, linux-arch, greg, netdev
In-Reply-To: <556924396ee34f4af94a2f03767973f1cec35e22.1306408804.git.gxt@mprc.pku.edu.cn>
On Thursday 26 May 2011, GuanXuetao wrote:
> From: Guan Xuetao <gxt@mprc.pku.edu.cn>
>
> Signed-off-by: Guan Xuetao <gxt@mprc.pku.edu.cn>
No objections to this driver, just remember that network drivers should
go through the netdev tree, and if it wasn't in there before the merge
window, you missed your chance for this time.
^ permalink raw reply
* [PATCH] fec driver multicast (and IPv6) problem
From: Zach Sadecki @ 2011-05-26 13:19 UTC (permalink / raw)
To: netdev; +Cc: davem
I noticed that sometimes I could not connect to my i.MX28 board over
IPv6. After some diagnosis I learned that it was not responding any NDP
requests. A simple "ip link set eth0 promisc off" would cause it to
respond properly to those requests. While that command didn't really do
anything (it wasn't in promisc mode to begin with), it did trigger a
call to set_multicast_list in the fec driver. It turns out that the
fec_restart function was zeroing out the multicast group hash registers
which breaks IPv6 NDP (amongst other things dependent on multicast
functionality). Changing the zeroing functionality into a call to
set_multicast_list fixed this problem for me. Note that simply removing
the calls that zero out the registers didn't work, as I believe the
reset call a few lines above had already cleared them. A patch is
inline below.
Zach
diff -ru linux-2.6.39/drivers/net/fec.c
linux-2.6.39-fecpatch/drivers/net/fec.c
--- linux-2.6.39/drivers/net/fec.c 2011-05-18 23:06:34.000000000 -0500
+++ linux-2.6.39-fecpatch/drivers/net/fec.c 2011-05-25
15:17:12.294339147 -0500
@@ -361,8 +361,7 @@
writel(0xffc00000, fep->hwp + FEC_IEVENT);
/* Reset all multicast. */
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_HIGH);
- writel(0, fep->hwp + FEC_GRP_HASH_TABLE_LOW);
+ set_multicast_list(dev);
#ifndef CONFIG_M5272
writel(0, fep->hwp + FEC_HASH_TABLE_HIGH);
writel(0, fep->hwp + FEC_HASH_TABLE_LOW);
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Neil Horman @ 2011-05-26 13:38 UTC (permalink / raw)
To: Américo Wang
Cc: Andy Gospodarek, Linux Kernel Network Developers, David Miller,
Jay Vosburgh
In-Reply-To: <BANLkTimEFg0Q=12z2_R4NNQ_VjRH=qhp2w@mail.gmail.com>
On Thu, May 26, 2011 at 05:11:35PM +0800, Américo Wang wrote:
> On Wed, May 25, 2011 at 11:01 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > While thats a fine rule to draw a distinction on, it also creates other
> > organizational oddities. By this reasoning, the loopback/tun-tap and xen
> > netfront drivers should also be moved to /net. While this might be an ok move
> > to make, I think we can all agree, that while they don't touch specific
> > hardware, they implement instances of the driver model, and as such are
> > reasonably placed in /drivers.
> >
>
> Hmm, after reading Andy's comments again, I think his point is
> probably bridge has STP management code which makes a difference
> with bonding, but you know, we have 802.3ad in bonding too.
>
Ok, pppe, slip, localtalk and wireless have code that, strictly speaking have
non-driver code in them to, should they also be moved to /net?
You seem stuck on this notion that theres a rule that squarely places code in
/net or /drivers. Nominally the choice is obvious, but in several cases, such
as this, its simply not. You have valid reasons for asserting bonding should be
in /net. There are just as many that assert it should be in /drivers.
> > This is really a false assertion. Theres nothing more or less hard about
> > finding bonding code in /drivers than there is in /net. grep and find let you
> > locate the code in either place equally well, and cscope really makes it all
> > moot anyway.
> >
>
> Sometimes cscope sucks, especially when you meet function pointers
> which are pretty common in net code. When I grep netpoll code, I have to
> do `grep ndo_netpoll_setup -nr net/ drivers/net`, if bonding were in net/
> `grep -nr net/` is enough. 'netdev_rx_handler_register' too.
>
Yes, sometimes cscope sucks. moving this code won't fix that. And if the major
advantage to this move is that you can remove a directory from a grep command,
thats really no advantage at all. To further illustrate this point, does the
fact that I could do this:
grep register_netdev\( -nr /drivers/net
instead of
grep register_netdev\( -nr /net /drivers/net
Justify the movement of the bridging code to /drivers? Of course not.
Neil
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Neil Horman @ 2011-05-26 13:50 UTC (permalink / raw)
To: Américo Wang
Cc: Andy Gospodarek, Linux Kernel Network Developers, David Miller,
Jay Vosburgh
In-Reply-To: <BANLkTin2HaYjHgGACkwvKwuY-Y_e3+r3JQ@mail.gmail.com>
On Thu, May 26, 2011 at 05:32:08PM +0800, Américo Wang wrote:
> On Wed, May 25, 2011 at 11:20 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Wed, May 25, 2011 at 08:43:21PM +0800, Américo Wang wrote:
> >> On Wed, May 25, 2011 at 12:33 AM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >> > This all sounds like change for the sake of change to me. I don't see any
> >> > compelling argument for moving bonding (or bridging or vlans, etc) around at
> >> > all. All of these software drivers have feet in multple subsystems, but that
> >> > just means that theres not going to be a compelling argument to move them any
> >> > place, at least not without an immediate subsequent argument that it really
> >> > belonged back where it was. Unless you can show a solid benefit to moving the
> >> > code, I don't see why any reorganization is needed.
> >>
> >> Well, as a people who worked on bonding code, I have no problem to know
> >> bonding code is under drivers/net/, but for people who don't know this, probably
> >> net/ is the first place they want to search.
> >>
> > you've asked them?
> >
> > cd git/net-next-2.6
> > find . -name '*bond*'
>
> No, somone asked me why bonding is not in net/ and after some thinking,
> I see no reasons myself (thus sent this patch).
>
"Why not" rarely seems like a good reason to change things to me :)
>
> >> The other similar thing is that pktgen is in net/core/ while netconsole is in
> >> drivers/net/, which seems a little strange too.
> >>
> > Its is, and loopback is in /drivers/net, as is tun-tap and xen-netfront (none of
> > which touch actual hardware), as is slip and ppp, which are net drivers, but
> > only operate on non net hardware. ppoe is another example which operates on
> > ethernet, but sits on top of a secondary physical device (and so has no real
> > hardware itself). These could all arguably be moved to /net, because they have
> > no real hardware, but are in drivers because they implement instances of the net
> > driver interface.
> >
> >> vlan vs macvlan is the third example.
> >>
> > yes, it is, macvlan, like you assert could be moved, but you could just as
> > easily move vlan to /drivers because it implements an instance of the net device
> > driver interface.
>
> Then I agree here.
>
> >
> > The bottom line is, sometimes things aren't black and white, they're gray. And
> > we put code where it makes the most sense at the time. We move it when it
> > makes sense to, but I don't hear any compelling argument to make that move.
> > Yes, we're not always consistent with where we put hardwareless drivers, but to
> > make a policy and shove everything to one place or another doesn't any more
> > sense. If we do that we either wind up with things that we think of as drivers
> > in the /net directory, or we wind up with stuff thats really protocol oriented
> > in the /drivers directory. And if the major problem we solve by doing so is
> > making life easier for someone who otherwise wouldn't be able to find said code
> > with a quick grep or find operation, it really doesn't seem like its worthwhile
> > to me
> >
>
> Well, the problem is our code organisation, if we could organize the code
> in a better way that would help grepping the code.
>
You've already demonstrated that its pretty easy. Do we really need to cater to
someone who can't figure out to look for something in two possible places when
it will just cause confusion for those of us do. And again, beyond that
tradeoff, I still don't see any advantage to doing this.
> >> In short, there are three callers of netdev_rx_handler_register(), macvlan,
> >> bonding and bridge, only bridge code stays in net/ directory.
> > Why is calling netdev_rx_handler_register a gating factor here?
> >
>
> I don't think other drivers are supposed to use this function to register
> a packet handler, which is an important difference from my view.
>
Note you just referred to the bridge/bond and vlan code as 'drivers' :). And
why is that function the gating factor? Why not register_netdev? or
netif_receive_skb or dev_add_pack? They all relate to the creation of device
interface and the reception of network data.
The fact is, bonding/bridging/vlans/tunnels/etc all have aspects that
make them more than just drivers. They are where they are for a myrriad of
reasons. Moving them around changes their location, but does _nothing_ about
the underlying fact that they're driver code plus other stuff, and as such
provides no real advantage in terms of organization.
Neil
^ permalink raw reply
* Re: [RFC Patch] bonding: move to net/ directory
From: Michał Mirosław @ 2011-05-26 14:25 UTC (permalink / raw)
To: Neil Horman
Cc: Américo Wang, Andy Gospodarek,
Linux Kernel Network Developers, David Miller, Jay Vosburgh
In-Reply-To: <20110526135053.GB12617@hmsreliant.think-freely.org>
2011/5/26 Neil Horman <nhorman@tuxdriver.com>:
> On Thu, May 26, 2011 at 05:32:08PM +0800, Américo Wang wrote:
>> I don't think other drivers are supposed to use this function to register
>> a packet handler, which is an important difference from my view.
> Note you just referred to the bridge/bond and vlan code as 'drivers' :). And
> why is that function the gating factor? Why not register_netdev? or
> netif_receive_skb or dev_add_pack? They all relate to the creation of device
> interface and the reception of network data.
>
> The fact is, bonding/bridging/vlans/tunnels/etc all have aspects that
> make them more than just drivers. They are where they are for a myrriad of
> reasons. Moving them around changes their location, but does _nothing_ about
> the underlying fact that they're driver code plus other stuff, and as such
> provides no real advantage in terms of organization.
If you want to draw a line between net/ and drivers/net I propose
following idea:
net/ - everything that is about networking (or library for it) and
interacts only within the system (kernel<->user, or in-kernel)
drivers/net/ - everything that is a connecting point between the
system and external world - be it hardware, other VMs or hypervisor.
net/ would include wireless stack, all kinds of loopback devices,
tunnels (incl. vlan), bridging, bonding, tuntap, etc.
drivers/net/ would keep only what is hardware or external ABI dependent
Just my 2 cents (3 grosze ;-).
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCH] net: davinci_emac: fix dev_err use at probe
From: Johan Hovold @ 2011-05-26 14:37 UTC (permalink / raw)
To: Cyril Chemparathy, David S. Miller, Sriramakrishnan A G
Cc: netdev, Johan Hovold
Use platform device rather than net device in dev_err calls before net
device has been registered to avoid messages such as
(null): DaVinci EMAC: Failed to get EMAC clock
Also replace remaining printks in probe with dev_{err,warn}.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
---
drivers/net/davinci_emac.c | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/davinci_emac.c b/drivers/net/davinci_emac.c
index 807b6bb..29a4f06 100644
--- a/drivers/net/davinci_emac.c
+++ b/drivers/net/davinci_emac.c
@@ -1772,7 +1772,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
/* obtain emac clock from kernel */
emac_clk = clk_get(&pdev->dev, NULL);
if (IS_ERR(emac_clk)) {
- printk(KERN_ERR "DaVinci EMAC: Failed to get EMAC clock\n");
+ dev_err(&pdev->dev, "failed to get EMAC clock\n");
return -EBUSY;
}
emac_bus_frequency = clk_get_rate(emac_clk);
@@ -1780,7 +1780,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
ndev = alloc_etherdev(sizeof(struct emac_priv));
if (!ndev) {
- printk(KERN_ERR "DaVinci EMAC: Error allocating net_device\n");
+ dev_err(&pdev->dev, "error allocating net_device\n");
clk_put(emac_clk);
return -ENOMEM;
}
@@ -1795,7 +1795,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
pdata = pdev->dev.platform_data;
if (!pdata) {
- printk(KERN_ERR "DaVinci EMAC: No platform data\n");
+ dev_err(&pdev->dev, "no platform data\n");
return -ENODEV;
}
@@ -1814,7 +1814,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
/* Get EMAC platform data */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
- dev_err(emac_dev, "DaVinci EMAC: Error getting res\n");
+ dev_err(&pdev->dev,"error getting res\n");
rc = -ENOENT;
goto probe_quit;
}
@@ -1822,14 +1822,14 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->emac_base_phys = res->start + pdata->ctrl_reg_offset;
size = res->end - res->start + 1;
if (!request_mem_region(res->start, size, ndev->name)) {
- dev_err(emac_dev, "DaVinci EMAC: failed request_mem_region() for regs\n");
+ dev_err(&pdev->dev, "failed request_mem_region() for regs\n");
rc = -ENXIO;
goto probe_quit;
}
priv->remap_addr = ioremap(res->start, size);
if (!priv->remap_addr) {
- dev_err(emac_dev, "Unable to map IO\n");
+ dev_err(&pdev->dev, "unable to map IO\n");
rc = -ENOMEM;
release_mem_region(res->start, size);
goto probe_quit;
@@ -1863,7 +1863,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
priv->dma = cpdma_ctlr_create(&dma_params);
if (!priv->dma) {
- dev_err(emac_dev, "DaVinci EMAC: Error initializing DMA\n");
+ dev_err(&pdev->dev, "error initializing DMA\n");
rc = -ENOMEM;
goto no_dma;
}
@@ -1879,7 +1879,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
- dev_err(emac_dev, "DaVinci EMAC: Error getting irq res\n");
+ dev_err(&pdev->dev, "error getting irq res\n");
rc = -ENOENT;
goto no_irq_res;
}
@@ -1888,8 +1888,8 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
if (!is_valid_ether_addr(priv->mac_addr)) {
/* Use random MAC if none passed */
random_ether_addr(priv->mac_addr);
- printk(KERN_WARNING "%s: using random MAC addr: %pM\n",
- __func__, priv->mac_addr);
+ dev_warn(&pdev->dev, "using random MAC addr: %pM\n",
+ priv->mac_addr);
}
ndev->netdev_ops = &emac_netdev_ops;
@@ -1902,7 +1902,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
SET_NETDEV_DEV(ndev, &pdev->dev);
rc = register_netdev(ndev);
if (rc) {
- dev_err(emac_dev, "DaVinci EMAC: Error in register_netdev\n");
+ dev_err(&pdev->dev, "error in register_netdev\n");
rc = -ENODEV;
goto netdev_reg_err;
}
--
1.7.5.rc3
^ permalink raw reply related
* can: convert to %pK for kptr_restrict support
From: Oliver Hartkopp @ 2011-05-26 14:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dan Rosenberg
As these pointers have been printed without using %p they were missed in the
big network kptr_restrict conversion patch %p -> %pK from Dan Rosenberg.
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
---
diff --git a/net/can/proc.c b/net/can/proc.c
index f4265cc..0016f73 100644
--- a/net/can/proc.c
+++ b/net/can/proc.c
@@ -204,12 +204,11 @@ static void can_print_rcvlist(struct seq_file *m, struct hlist_head *rx_list,
hlist_for_each_entry_rcu(r, n, rx_list, list) {
char *fmt = (r->can_id & CAN_EFF_FLAG)?
- " %-5s %08X %08x %08x %08x %8ld %s\n" :
- " %-5s %03X %08x %08lx %08lx %8ld %s\n";
+ " %-5s %08x %08x %pK %pK %8ld %s\n" :
+ " %-5s %03x %08x %pK %pK %8ld %s\n";
seq_printf(m, fmt, DNAME(dev), r->can_id, r->mask,
- (unsigned long)r->func, (unsigned long)r->data,
- r->matches, r->ident);
+ r->func, r->data, r->matches, r->ident);
}
}
^ permalink raw reply related
* Re: Kernel crash after using new Intel NIC (igb)
From: Ben Hutchings @ 2011-05-26 15:06 UTC (permalink / raw)
To: Eric Dumazet
Cc: Arun Sharma, Maximilian Engelhardt, linux-kernel, netdev,
StuStaNet Vorstand
In-Reply-To: <1306305331.3305.22.camel@edumazet-laptop>
On Wed, 2011-05-25 at 08:35 +0200, Eric Dumazet wrote:
> Le mardi 24 mai 2011 à 23:06 -0700, Arun Sharma a écrit :
> > On Wed, May 25, 2011 at 04:44:29AM +0200, Eric Dumazet wrote:
> > >
> > > Hmm, thanks for the report. Are you running x86 or another arch ?
> > >
> >
> > This was on x86.
> >
> > > We probably need some sort of memory barrier.
> > >
> > > However, locking this central lock makes the thing too slow, I'll try to
> > > use an atomic_inc_return on p->refcnt instead. (and then lock
> > > unused_peers.lock if we got a 0->1 transition)
> >
> > Another possibility is to do the list_empty() check twice. Once without
> > taking the lock and again with the spinlock held.
> >
>
> Why ?
>
> list_del_init(&p->unused); (done under lock of course) is safe, you can
> call it twice, no problem.
>
> No, the real problem is the (!list_empty(&p->unused) test : It seems to
> not always tell the truth if not done under lock.
Of course not; list modification operations are not atomic.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH V5 2/6 net-next] netdevice.h: Add zero-copy flag in netdevice
From: Shirley Ma @ 2011-05-26 15:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Michał Mirosław, Ben Hutchings, David Miller,
Eric Dumazet, Avi Kivity, Arnd Bergmann, netdev, kvm,
linux-kernel
In-Reply-To: <20110526084916.GA17928@redhat.com>
On Thu, 2011-05-26 at 11:49 +0300, Michael S. Tsirkin wrote:
> On Wed, May 25, 2011 at 03:49:40PM -0700, Shirley Ma wrote:
> > On Fri, 2011-05-20 at 02:41 +0300, Michael S. Tsirkin wrote:
> > > So the requirements are
> > > - data must be released in a timely fashion (e.g. unlike
> virtio-net
> > > tun or bridge)
> > The current patch doesn't enable tun zero-copy. tun will copy data
> It's
> > not an issue now.
> > We can disallow macvtap attach to bridge when
> > zero-copy is enabled.
>
> Attach macvtap to a tun device though. Or e.g. veth device ...
> So there should be so generic way to disable zerocopy.
> It can either be a whitelist or a blacklist.
> >
> > > - SG support
> > > - HIGHDMA support (on arches where this makes sense)
> >
> > This can be checked by device flags.
>
> OK, but pls note that SG can get turned off dynamically.
>
> > > - no filtering based on data (data is mapped in guest)
> >
> > > - on fast path no calls to skb_copy, skb_clone, pskb_copy,
> > > pskb_expand_head as these are slow
> >
> > Any calls to skb_copy, skb_clone, pskb_copy, pskb_expand_head will
> do a
> > copy. The performance should be the same as none zero-copy case
> before.
>
> I'm guessing a copy is cheaper than get_user_pages+copy+put_page.
> But maybe not by much. Care checking that?
That's I have done already. Patch is going out for review.
> > I have done/tested the patch V6, will send it out for review
> tomorrow.
> >
> > I am looking at where there are some cases, skb remains the same for
> > filtering.
>
> To reliably filter on data I think we'll need to copy it first,
> otherwise
> guest can change it. Most filters only look at the header though.
>
> > > First 2 requirements are a must, all other requirements
> > > are just dependencies to make sure zero copy will be faster
> > > than non zero copy.
> > > Using a new feature bit is probably the simplest approach to
> > > this. macvtap on top of most physical NICs most likely works
> > > correctly so it seems a bit more work than it needs to be,
> > > but it's also the safest one I think ...
> >
> > For "macvtap/vhost zero-copy" we can use SG & HIGHDMA to enable it,
> it
> > looks safe to me once patching skb_copy, skb_clone, pskb_copy,
> > pskb_expand_head.
> >
> > To extend zero-copy in other usages, we can have a new feature bit
> > later.
> >
> > Is that reasonable?
> >
> > Thanks
> > Shirley
>
> Is the problem is extra work needed to extend feature bits?
There is no problem to use it, Mahesh is working on this patch. I just
want to remove macvtap/vhost zero-copy patch dependency.
Thanks
Shirley
^ permalink raw reply
* Re: TCP funny-ness when over-driving a 1Gbps link (and wifi)
From: Chris Friesen @ 2011-05-26 15:28 UTC (permalink / raw)
To: Ben Greear; +Cc: rick.jones2, Stephen Hemminger, netdev
In-Reply-To: <4DD6DE1C.8090607@candelatech.com>
On 05/20/2011 03:33 PM, Ben Greear wrote:
> I tried a different test today: 3 TCP connections between two
> wifi station interfaces (using ath9k). Each connection is
> endpoint configured to send 100Mbps of traffic to the peer.
>
> With a single connection, it does OK (maybe 250ms round-trip time max).
> With 3 of them running, round-trip user-space to user-space latency
> often goes above 3 seconds.
<snip>
> So, seems a general issue with over-driving links with multiple TCP
> connections. Doesn't seem like a regression, and probably not really
> a bug, but maybe the buffer-bloat project will help this sort of
> thing...
Given that one rule of thumb for the send buffer size is twice the
bandwidth delay product, it seems clear that on a wifi connection 3
seconds worth of buffering is excessive. I think I'd classify that as a
bug.
Chris
--
Chris Friesen
Software Developer
GENBAND
chris.friesen@genband.com
www.genband.com
^ permalink raw reply
* Re: [patch] net/core/filter.c: Fix build error
From: Joe Perches @ 2011-05-26 15:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Ben Greear, linux-kernel, linux-arch, David S. Miller,
Arnd Bergmann, netdev
In-Reply-To: <20110526123153.GA16002@elte.hu>
On Thu, 2011-05-26 at 14:31 +0200, Ingo Molnar wrote:
> * Joe Perches <joe@perches.com> wrote:
> > A mis-configured filter can spam the logs with lots of stack traces.
> > Rate-limit the warnings and add printout of the bogus filter information.
> > Original-patch-by: Ben Greear <greearb@candelatech.com>
> > Signed-off-by: Joe Perches <joe@perches.com>
> > ---
> > net/core/filter.c | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/net/core/filter.c b/net/core/filter.c
> > index 0eb8c44..0e3622f 100644
> > --- a/net/core/filter.c
> > +++ b/net/core/filter.c
> > @@ -350,7 +350,9 @@ load_b:
> > continue;
> > }
> > default:
> > - WARN_ON(1);
> > + WARN_RATELIMIT(1, "Unknown code:%u jt:%u tf:%u k:%u\n",
> > + fentry->code, fentry->jt,
> > + fentry->jf, fentry->k);
> > return 0;
> > }
> This change (now upstream) fails to build in about 20% of all
> randconfigs. Fix is below.
We've had problems with ratelimit uses in the past
as well.
There's a logical separation issue with the #includes
of bug.h, printk.h, ratelimit.h kernel.h and the
spinlock includes.
My suggestion would be to see about again adding
#include <linux/ratelimit.h> somehow
back to kernel.h which commit 3fff4c42bd0a removed
in 2009 because of the spinlock issues.
Any suggestion on how best to fix it generically?
^ permalink raw reply
* [PERF RESULTS] virtio and vhost-net performance enhancements
From: Krishna Kumar2 @ 2011-05-26 15:32 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
lguest-uLR06cmDAlY/bJ5BZ2RsiQ, Shirley Ma,
kvm-u79uwXL29TY76Z2rM5mHXA, Carsten Otte,
linux-s390-u79uwXL29TY76Z2rM5mHXA, Heiko Carstens,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
steved-r/Jw6+rmf7HQT0dZR+AlfA, Christian Borntraeger,
Tom Lendacky, netdev-u79uwXL29TY76Z2rM5mHXA, Martin Schwidefsky,
linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <cover.1305846412.git.mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
"Michael S. Tsirkin" <mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote on 05/20/2011 04:40:07 AM:
> OK, here is the large patchset that implements the virtio spec update
> that I sent earlier (the spec itself needs a minor update, will send
> that out too next week, but I think we are on the same page here
> already). It supercedes the PUBLISH_USED_IDX patches I sent
> out earlier.
I was able to get this tested by applying the v2 patches
to git-next tree (somehow MST's git tree hung on my guest
which never got resolved). Testing was from Guest -> Remote
node, using an ixgbe 10g card. The test results are
*excellent* (table: #netperf sesssions, BW% improvement,
SD% improvement, CPU% improvement):
___________________________________
512 byte I/O
# BW% SD% CPU%
____________________________________
1 151.6 -65.1 -10.7
2 180.6 -66.6 -6.4
4 15.5 -35.8 -26.1
8 1.8 -28.4 -26.7
16 3.1 -29.0 -26.5
32 1.1 -27.4 -27.5
64 3.8 -30.9 -26.7
96 5.4 -21.7 -24.2
128 5.7 -24.4 -25.5
____________________________________
BW: 16.6% SD: -24.6% CPU: -25.5%
____________________________________
1K I/O
# BW% SD% CPU%
____________________________________
1 233.9 -76.5 -18.0
2 112.2 -64.0 -23.2
4 9.2 -31.6 -26.1
8 -1.7 -26.8 -30.3
16 3.5 -31.5 -30.6
32 4.8 -25.2 -30.5
64 5.7 -31.0 -28.9
96 5.3 -32.2 -31.7
128 4.6 -38.2 -33.6
____________________________________
BW: 16.4% SD: -35.% CPU: -31.5%
____________________________________
16K I/O
# BW% SD% CPU%
____________________________________
1 18.8 -27.2 -18.3
2 14.8 -36.7 -27.7
4 12.7 -45.2 -38.1
8 4.4 -56.4 -54.4
16 4.8 -38.3 -36.1
32 0 78.0 79.2
64 3.8 -38.1 -37.5
96 7.3 -35.2 -31.1
128 3.4 -31.1 -32.1
____________________________________
BW: 7.6% SD: -30.1% CPU: -23.7%
I plan to run some more tests tomorrow. Please let
me know if any other scenario will help.
Thanks,
- KK
^ permalink raw reply
* Re: [PERF RESULTS] virtio and vhost-net performance enhancements
From: Shirley Ma @ 2011-05-26 15:42 UTC (permalink / raw)
To: Krishna Kumar2
Cc: habanero, lguest, kvm, Carsten Otte, linux-s390,
Michael S. Tsirkin, Heiko Carstens, linux-kernel, virtualization,
Steve Dobbelstein, Christian Borntraeger, Tom Lendacky, netdev,
Martin Schwidefsky, linux390
In-Reply-To: <OF0EFA7BA9.BB2C2860-ON6525789C.0053EE3A-6525789C.005513CC@in.ibm.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 4977 bytes --]
Hello KK,
Could you please try TCP_RRs as well?
Thanks
Shirley
Krishna Kumar2
<krkumar2@in.ibm.
com> To
"Michael S. Tsirkin"
05/26/2011 08:32 <mst@redhat.com>
AM cc
Christian Borntraeger
<borntraeger@de.ibm.com>, Carsten
Otte <cotte@de.ibm.com>,
habanero@linux.vnet.ibm.com, Heiko
Carstens
<heiko.carstens@de.ibm.com>,
kvm@vger.kernel.org,
lguest@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-s390@vger.kernel.org,
linux390@de.ibm.com,
netdev@vger.kernel.org, Rusty
Russell <rusty@rustcorp.com.au>,
Martin Schwidefsky
<schwidefsky@de.ibm.com>, Steve
Dobbelstein/Austin/IBM@IBMUS, Tom
Lendacky <tahm@linux.vnet.ibm.com>,
virtualization@lists.linux-foundati
on.org, Shirley
Ma/Beaverton/IBM@IBMUS
Subject
[PERF RESULTS] virtio and vhost-net
performance enhancements
"Michael S. Tsirkin" <mst@redhat.com> wrote on 05/20/2011 04:40:07 AM:
> OK, here is the large patchset that implements the virtio spec update
> that I sent earlier (the spec itself needs a minor update, will send
> that out too next week, but I think we are on the same page here
> already). It supercedes the PUBLISH_USED_IDX patches I sent
> out earlier.
I was able to get this tested by applying the v2 patches
to git-next tree (somehow MST's git tree hung on my guest
which never got resolved). Testing was from Guest -> Remote
node, using an ixgbe 10g card. The test results are
*excellent* (table: #netperf sesssions, BW% improvement,
SD% improvement, CPU% improvement):
___________________________________
512 byte I/O
# BW% SD% CPU%
____________________________________
1 151.6 -65.1 -10.7
2 180.6 -66.6 -6.4
4 15.5 -35.8 -26.1
8 1.8 -28.4 -26.7
16 3.1 -29.0 -26.5
32 1.1 -27.4 -27.5
64 3.8 -30.9 -26.7
96 5.4 -21.7 -24.2
128 5.7 -24.4 -25.5
____________________________________
BW: 16.6% SD: -24.6% CPU: -25.5%
____________________________________
1K I/O
# BW% SD% CPU%
____________________________________
1 233.9 -76.5 -18.0
2 112.2 -64.0 -23.2
4 9.2 -31.6 -26.1
8 -1.7 -26.8 -30.3
16 3.5 -31.5 -30.6
32 4.8 -25.2 -30.5
64 5.7 -31.0 -28.9
96 5.3 -32.2 -31.7
128 4.6 -38.2 -33.6
____________________________________
BW: 16.4% SD: -35.% CPU: -31.5%
____________________________________
16K I/O
# BW% SD% CPU%
____________________________________
1 18.8 -27.2 -18.3
2 14.8 -36.7 -27.7
4 12.7 -45.2 -38.1
8 4.4 -56.4 -54.4
16 4.8 -38.3 -36.1
32 0 78.0 79.2
64 3.8 -38.1 -37.5
96 7.3 -35.2 -31.1
128 3.4 -31.1 -32.1
____________________________________
BW: 7.6% SD: -30.1% CPU: -23.7%
I plan to run some more tests tomorrow. Please let
me know if any other scenario will help.
Thanks,
- KK
[-- Attachment #1.1.2: Type: text/html, Size: 6741 bytes --]
[-- Attachment #1.2: graycol.gif --]
[-- Type: image/gif, Size: 105 bytes --]
[-- Attachment #1.3: pic17152.gif --]
[-- Type: image/gif, Size: 1255 bytes --]
[-- Attachment #1.4: ecblank.gif --]
[-- Type: image/gif, Size: 45 bytes --]
[-- Attachment #2: Type: text/plain, Size: 184 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [BUG] netconsole broken by scheduler updates
From: Laurent Riffard @ 2011-05-26 16:12 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: netdev
In-Reply-To: <alpine.DEB.2.02.1105261217240.5114@localhost6.localdomain6>
Le 26/05/2011 12:35, Laurent Riffard a écrit :
> On Thu, 26 May 2011, Peter Zijlstra wrote:
>> On Thu, 2011-05-26 at 11:21 +0200, Laurent Riffard wrote:
>>> Hi,
>>>
>>> Recently, netconsole was broken by some scheduler updates. Kernel hangs
>>> on boot near the network card initialization. I noticed that it does
>>> hang just where a "inconsistent lock state" message normally appears.
>>>
>>> I did a bisection : e4a52bcb9a18142d79e231b6733cabdbf2e67c1f is the
>>> first bad commit.
>>> commit e4a52bcb9a18142d79e231b6733cabdbf2e67c1f
>>> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
>>> Date: Tue Apr 5 17:23:54 2011 +0200
>>>
>>> sched: Remove rq->lock from the first half of ttwu()
>>>
>>>
>>> Before this commit, kernel was booting succesfully despite the
>>> "inconsistent lock state" message. After this commit, the kernel does
>>> hang on boot, I have to push the reset button.
>>
>> Do you have CONFIG_HARDLOCKUP_DETECTOR=y, and do you get an NMI splat
>> after some 10 seconds? It would be interesting to see where its stuck.
>
> CONFIG_HARDLOCKUP_DETECTOR is not set for now. I'll give it a try.
I activated CONFIG_HARDLOCKUP_DETECTOR, but failed to obtain more
information. During the boot, the kernel hangs just after bringing up
the NIC. I waited 2 minutes, without getting any more messages.
~~
laurent
^ permalink raw reply
* Re: [BUG] netconsole broken by scheduler updates
From: Peter Zijlstra @ 2011-05-26 16:17 UTC (permalink / raw)
To: Laurent Riffard; +Cc: netdev
In-Reply-To: <4DDE7BEB.1050507@free.fr>
On Thu, 2011-05-26 at 18:12 +0200, Laurent Riffard wrote:
> Le 26/05/2011 12:35, Laurent Riffard a écrit :
> > On Thu, 26 May 2011, Peter Zijlstra wrote:
> >> On Thu, 2011-05-26 at 11:21 +0200, Laurent Riffard wrote:
> >>> Hi,
> >>>
> >>> Recently, netconsole was broken by some scheduler updates. Kernel hangs
> >>> on boot near the network card initialization. I noticed that it does
> >>> hang just where a "inconsistent lock state" message normally appears.
> >>>
> >>> I did a bisection : e4a52bcb9a18142d79e231b6733cabdbf2e67c1f is the
> >>> first bad commit.
> >>> commit e4a52bcb9a18142d79e231b6733cabdbf2e67c1f
> >>> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> >>> Date: Tue Apr 5 17:23:54 2011 +0200
> >>>
> >>> sched: Remove rq->lock from the first half of ttwu()
> >>>
> >>>
> >>> Before this commit, kernel was booting succesfully despite the
> >>> "inconsistent lock state" message. After this commit, the kernel does
> >>> hang on boot, I have to push the reset button.
> >>
> >> Do you have CONFIG_HARDLOCKUP_DETECTOR=y, and do you get an NMI splat
> >> after some 10 seconds? It would be interesting to see where its stuck.
> >
> > CONFIG_HARDLOCKUP_DETECTOR is not set for now. I'll give it a try.
>
> I activated CONFIG_HARDLOCKUP_DETECTOR, but failed to obtain more
> information. During the boot, the kernel hangs just after bringing up
> the NIC. I waited 2 minutes, without getting any more messages.
OK, thanks for trying, I shall try and reproduce locally.
^ permalink raw reply
* Re: [PERF RESULTS] virtio and vhost-net performance enhancements
From: Krishna Kumar2 @ 2011-05-26 16:21 UTC (permalink / raw)
To: Shirley Ma
Cc: Christian Borntraeger, Carsten Otte, habanero, Heiko Carstens,
kvm, lguest, linux-kernel, linux-s390, linux390,
Michael S. Tsirkin, netdev, Rusty Russell, Martin Schwidefsky,
Steve Dobbelstein, Tom Lendacky, virtualization
In-Reply-To: <OFE30C8D78.526FF88D-ON8725789C.00563B8C-8825789C.0056469F@us.ibm.com>
Shirley Ma <xma@us.ibm.com> wrote on 05/26/2011 09:12:22 PM:
> Could you please try TCP_RRs as well?
Right. Here's the result for TCP_RR:
__________________________________
# RR% SD% CPU%
__________________________________
1 4.5 -31.4 -27.9
2 5.1 -9.7 -5.4
4 60.4 -13.4 38.8
8 67.8 -13.5 45.0
16 55.8 -8.0 43.2
32 66.9 -14.1 43.3
64 47.2 -23.7 12.2
96 29.7 -11.8 14.3
128 8.0 2.2 10.7
___________________________________
BW: 37.3% SD: -6.7% CPU: 15.7%
___________________________________
Thanks,
- KK
^ permalink raw reply
* [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
From: Dmitry Kravkov @ 2011-05-26 16:28 UTC (permalink / raw)
To: david Miller, netdev@vger.kernel.org; +Cc: Jacek Luczak
---
net/sctp/bind_addr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/sctp/bind_addr.c b/net/sctp/bind_addr.c
index 6338413..83e3011 100644
--- a/net/sctp/bind_addr.c
+++ b/net/sctp/bind_addr.c
@@ -145,7 +145,7 @@ static void sctp_bind_addr_clean(struct sctp_bind_addr *bp)
/* Empty the bind address list. */
list_for_each_entry_safe(addr, temp, &bp->address_list, list) {
list_del_rcu(&addr->list);
- call_rcu(&addr->rcu, sctp_local_addr_free);
+ kfree_rcu(addr, rcu);
SCTP_DBG_OBJCNT_DEC(addr);
}
}
--
1.7.2.2
^ permalink raw reply related
* Re: [PERF RESULTS] virtio and vhost-net performance enhancements
From: Krishna Kumar2 @ 2011-05-26 16:29 UTC (permalink / raw)
To: Krishna Kumar2
Cc: habanero-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
lguest-uLR06cmDAlY/bJ5BZ2RsiQ, Shirley Ma,
kvm-u79uwXL29TY76Z2rM5mHXA, Carsten Otte,
linux-s390-u79uwXL29TY76Z2rM5mHXA, Michael S. Tsirkin,
Heiko Carstens, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
virtualization-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
Steve Dobbelstein, Christian Borntraeger, Tom Lendacky,
netdev-u79uwXL29TY76Z2rM5mHXA, Martin Schwidefsky,
linux390-tA70FqPdS9bQT0dZR+AlfA
In-Reply-To: <OFF9D0E604.B865A006-ON6525789C.00597010-6525789C.0059987A@LocalDomain>
Krishna Kumar2/India/IBM wrote on 05/26/2011 09:51:32 PM:
> > Could you please try TCP_RRs as well?
>
> Right. Here's the result for TCP_RR:
The actual transaction rate/second numbers are:
_____________________________________________________________
# RR1 RR2 (%) SD1 SD2 (%)
_____________________________________________________________
1 9476 9903 (4.5) 28.9 19.8 (-31.4)
2 17337 18225 (5.1) 92.7 83.7 (-9.7)
4 17385 27902 (60.4) 364.8 315.8 (-13.4)
8 25560 42912 (67.8) 1428.1 1234.0 (-13.5)
16 35898 55934 (55.8) 4391.6 4038.1 (-8.0)
32 48048 80228 (66.9) 17391.4 14932.0 (-14.1)
64 60412 88929 (47.2) 71087.7 54230.1 (-23.7)
96 71263 92439 (29.7) 145434.1 128214.0 (-11.8)
128 84208 91014 (8.0) 233668.2 238888.6 (2.2)
_____________________________________________________________
RR: 37.3% SD: -6.7%
_____________________________________________________________
Thanks,
- KK
^ permalink raw reply
* Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
From: Dmitry Kravkov @ 2011-05-26 16:41 UTC (permalink / raw)
To: david Miller, Jacek Luczak; +Cc: netdev@vger.kernel.org
In-Reply-To: <1306427323.7510.2.camel@lb-tlvb-dmitry>
On Thu, 2011-05-26 at 09:28 -0700, Dmitry Kravkov wrote:
> ---
> net/sctp/bind_addr.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
It was easier to fix it like commit
1231f0baa547a541a7481119323b7f964dda4788 does, than to disable it in
kernel config :)
^ permalink raw reply
* Re: [PATCH v3 resend] netfilter: nf_conntrack_sip: Handle Cisco 7941/7945 IP phones
From: Pablo Neira Ayuso @ 2011-05-26 16:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Kevin Cernekee, Patrick McHardy, David S. Miller, netfilter-devel,
netfilter, coreteam, linux-kernel, netdev
In-Reply-To: <bc781b295b38241533a2d90c1aea15b3@localhost>
Hi Eric,
On 20/05/11 06:36, Kevin Cernekee wrote:
> Most SIP devices use a source port of 5060/udp on SIP requests, so the
> response automatically comes back to port 5060:
>
> phone_ip:5060 -> proxy_ip:5060 REGISTER
> proxy_ip:5060 -> phone_ip:5060 100 Trying
>
> The newer Cisco IP phones, however, use a randomly chosen high source
> port for the SIP request but expect the response on port 5060:
>
> phone_ip:49173 -> proxy_ip:5060 REGISTER
> proxy_ip:5060 -> phone_ip:5060 100 Trying
>
> Standard Linux NAT, with or without nf_nat_sip, will send the reply back
> to port 49173, not 5060:
>
> phone_ip:49173 -> proxy_ip:5060 REGISTER
> proxy_ip:5060 -> phone_ip:49173 100 Trying
>
> But the phone is not listening on 49173, so it will never see the reply.
>
> This patch modifies nf_*_sip to work around this quirk by extracting
> the SIP response port from the Via: header, iff the source IP in the
> packet header matches the source IP in the SIP request.
>
> Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> Cc: Patrick McHardy <kaber@trash.net>
@Eric: could you please confirm that you ack'ed this patch? I don't find
the email with your explicit ack.
^ permalink raw reply
* [ANNOUNCE]: Release of iptables-1.4.11
From: Patrick McHardy @ 2011-05-26 16:53 UTC (permalink / raw)
To: Netfilter Development Mailinglist, NetDev, netfilter-announce,
"'netfilter@vger.kernel.org'" <netfilter
[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]
The netfilter coreteam presents:
iptables version 1.4.10
the iptables release for the 2.6.39 kernels. Due to some mistakes
on my side we didn't have a release for longer than expected, so
this contains a rather large number of changes.
Changes include:
- various bugfixes, cleanups and documentation updates
- a new "guided option parser" from Jan, replacing a lot of the
open-coded option parsing by a data driven parser
- support for the current SET target as contained in 2.6.39
- support for the new devgroup match
- support for the new AUDIT target
- support for a new NFQUEUE bypass option, allowing to bypass the
queue if no userspace listener is present
- a new iptables option "-C" to check for existance of a rules
- a new xtables-multi binary which supports both IPv4 and IPv6
See the attached changelogs for the full list of changes.
Version 1.4.11 can be obtained from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
git://git.netfilter.org/iptables.git
On behalf of the Netfilter Core Team.
Happy firewalling!
[-- Attachment #2: changes-iptables-1.4.11.txt --]
[-- Type: text/plain, Size: 14922 bytes --]
Changli Gao (1):
iptables: fix the dead loop when meeting unknown options
Florian Westphal (3):
libxt_conntrack: fix --ctdir save/dump output format
libxt_time: fix random --datestart skips
extensions: libxt_NFQUEUE: add v2 revision with --queue-bypass option
JP Abgrall (1):
libxt_quota: make sure uint64 is not truncated
Jan Engelhardt (218):
libxtables: change option precedence order to be intuitive
libxt_TOS: avoid an undesired overflowing computation
iptables: fix longopt reecognition and workaround getopt(3) behavior
Revert "Revert "libxtables: change option precedence order to be intuitive""
Merge branch 'master' of git://dev.medozas.de/iptables into m2
iptables: reset options at the start of each command
iptables: do not emit orig_opts twice
include: update files with headers from Linux 2.6.37-rc1
TPROXY: add support for revision 1
socket: add support for revision 1
build: fix globbing of extensions in other locales
libxt_owner: output numeric IDs when save is requested
Merge commit 'v1.4.10'
build: stop on error in subcommand
src: const annotations
xt_comment: remove redundant cast
src: use C99/POSIX types
iptables: abort on empty interface specification
xtables: reorder num_old substraction for clarity
ip[6]tables: only call match's parse function when option char is in range
ip[6]tables: only call target's parse function when option char is in range
extensions: remove no longer necessary default: cases
libxt_sctp: fix a typo
libipt_CLUSTERIP: const annotations
libxtables: do some option structure checking
libxt_quota: print negation when it has been selected
libxt_connlimit: reword help text to say prefix length
libxt_connlimit: add a --connlimit-upto option
libxt_connlimit: support for dstaddr-supporting revision 1
libxt_connlimit: remove duplicate member that caused size change
libxt_quota: clarifications on matching
iptables: improve error reporting with extension loading troubles
libxt_u32: enclose argument in quotes
xtables: set custom opts to NULL on free
iptables: warn when parameter limit is exceeded
iptables: remove bogus address-of
iptables: remove more redundant casts
iptables: do not print trailing whitespaces
src: collect do_command variables in a struct
src: move large default: block from do_command6 into its own function
src: share iptables_command_state across the two programs
src: deduplicate find_proto function
src: move OPT_FRAGMENT to the end so the list can be shared
src: put shared option flags into xshared
src: deduplicate and simplify implicit protocol extension loading
src: unclutter command_default function
src: move jump option handling from do_command6 into its own function
src: move match option handling from do_command6 into its own functions
iptables: fix error message for unknown options
iptables: fix segfault target option parsing
ip6tables: spacing fixes for -o argument
libxt_devgroup: option whitespace update following v1.4.10-49-g7386635
extensions: fix indent of vtable
doc: fix wrong sentence about negation in xt_limit
doc: fix misspelling of "field"
extensions: remove redundant init functions
Remove unused CVS expanded keywords
libip6t_dst: remove unimplemented --dst-not-strict
libip6t_hbh: remove unimplemented --hbh-not-strict
extensions: add missing checks for specific flags
libipt_ECN: set proper option flags
doc: mention other possible nf_loggers for TRACE
doc: fix odd partial sentence in libipt_TTL
libxt_quota: require --quota to be specified
doc: rateest options can be optional
libxtables: fix memory scribble beyond end of array
iptables: fix an inversion
doc: add VERSION section to manpages
extensions: add missing checks for specific flags (2)
libxtables: guided option parser
libxt_CHECKSUM: use guided option parser
libxt_socket: use guided option parser
libxtables: provide better final_check
libxt_CONNSECMARK: use guided option parser
libxtables: XTTYPE_UINT32 support
libxt_cpu: use guided option parser
libxtables: min-max option support
libxt_cluster: use guided option parser
libxtables: XTTYPE_UINT8 support
libip[6]t_HL: use guided option parser
libip[6]t_hl: use guided option parser
libxtables: XTTYPE_UINT32RC support
libip[6]t_ah: use guided option parser
libip6t_frag: use guided option parser
libxt_esp: use guided option parser
libxtables: XTTYPE_STRING support
libip[6]t_REJECT: use guided option parser
libip6t_dst: use guided option parser
libip6t_hbh: use guided option parser
libip[6]t_icmp: use guided option parser
libip6t_ipv6header: use guided option parser
libipt_ECN: use guided option parser
libipt_addrtype: use guided option parser
libxt_AUDIT: use guided option parser
libxt_CLASSIFY: use guided option parser
libxt_DSCP: use guided option parser
libxt_LED: use guided option parser
libxt_SECMARK: use guided option parser
libxt_TCPOPTSTRIP: use guided option parser
libxt_comment: use guided option parser
libxt_helper: use guided option parser
libxt_physdev: use guided option parser
libxt_pkttype: use guided option parser
libxt_state: use guided option parser
libxt_time: use guided option parser
libxt_u32: use guided option parser
doc: avoid duplicate entries in manpage
libxtables: XTTYPE_MARKMASK32 support
libxt_MARK: use guided option parser
libxt_CONNMARK: use guided option parser
libxtables: XTTYPE_UINT64 support
libxt_quota: use guided option parser
libxtables: linked-list name<->id map
libxt_devgroup: use guided option parser
libipt_realm: use guided option parser
libxtables: XTTYPE_UINT16RC support
libxt_length: use guided option parser
libxt_tcpmss: use guided option parser
libxtables: XTTYPE_UINT8RC support
libxtables: XTTYPE_UINT64RC support
libxt_connbytes: use guided option parser
libxtables: XTTYPE_UINT16 support
libxt_CT: use guided option parser
libxt_NFQUEUE: use guided option parser
libxt_TCPMSS: use guided option parser
libxtables: pass struct xt_entry_{match,target} to x6 parser
libxt_string: use guided option parser
libxtables: XTTYPE_SYSLOGLEVEL support
libip[6]t_LOG: use guided option parser
libxtables: XTTYPE_ONEHOST support
libxtables: XTTYPE_PORT support
libxt_TPROXY: use guided option parser
libipt_ULOG: use guided option parser
build: bump libxtables ABI version
libxt_TEE: use guided option parser
xtoptions: respect return value in xtables_getportbyname
libxt_TOS: use guided option parser
libxt_tos: use guided option parser
extensions: remove unused TOS code
libxtables: XTTYPE_PORTRC support
libxt_udp: use guided option parser
libxt_dccp: use guided option parser
libxt_tos: add inversion support back again
libxtables: fix assignment in wrong offset (XTTYPE_UINT*RC)
libxt_u32: add missing call to xtables_option_parse
extensions: remove bogus use of XT_GETOPT_TABLEEND
libxt_owner: remove ifdef IPT_COMM_OWNER
libxtables: output name of extension on rev detect failure
extensions: const annotations
libxt_statistic: streamline and document possible placement of negation
libxt_statistic: increase precision on create and dump
libxtables: XTTYPE_DOUBLE support
libxt_statistic: use guided option parser
libxt_IDLETIMER: use guided option parser
libxt_NFLOG: use guided option parser
libxtables: support for XTTYPE_PLENMASK
libxt_connlimit: use guided option parser
libxt_recent: use guided option parser
libxtables: do not overlay addr and mask parts, and cleanup
libxtables: flag invalid uses of XTOPT_PUT
libxtables: XTTYPE_PLEN support
libxt_hashlimit: use guided option parser
libxtables: XTTYPE_HOSTMASK support
libxt_policy: use guided option parser
libxt_owner: use guided option parser
libxt_osf: use guided option parser
libxt_multiport: use guided option parser
libipt_NETMAP: use guided option parser
libxt_limit: use guided option parser
libxtables: XTTYPE_PROTOCOL support
libxt_ipvs: use guided option parser
doc: S/DNAT allows to omit IP addresses
libxt_conntrack: use guided option parser
libip6t_mh: use guided option parser
libip6t_rt: use guided option parser
libxtables: XTTYPE_ETHERMAC support
libxt_mac: use guided option parser
libipt_CLUSTERIP: use guided option parser
libxt_iprange: use guided option parser
libipt_DNAT: use guided option parser
libipt_SNAT: use guided option parser
libipt_MASQUERADE: use guided option parser
libipt_REDIRECT: use guided option parser
libipt_SAME: use guided option parser
src: replace old IP*T_ALIGN macros
src: combine default_command functions
libxt_policy: option table fixes, improved error tracking
libxtables: avoid running into .also checks when option not used
libxt_policy: use XTTYPE_PROTOCOL type
libxtables: collapse double protocol parsing
libipt_[SD]NAT: flag up module name on error
libipt_[SD]NAT: avoid false error about multiple destinations specified
libxt_conntrack: correct printed module name
libxt_conntrack: fix assignment to wrong member
libxt_conntrack: resolve erroneous rev-2 port range message
libip6t_rt: rt-0-not-strict should take no arg
libxtables: retract _NE types and use a flag instead
libxt_quota: readd missing XTOPT_PUT request
libxtables: check for negative numbers in xtables_strtou*
libxt_rateest: streamline case display of units
doc: add some coded option examples to libxt_hashlimit
doc: make usage of libxt_rateest more obvious
doc: clarify that -p all is a special keyword only
doc: use .IP list for TCPMSS
doc: remove redundant .IP calls in libxt_time
libxt_ipvs: restore network-byte order
libxt_u32: --u32 option is required
libip6t_rt: restore --rt-type storing
libxtables: more detailed error message on multi-int parsing
libxtables: use uintmax for xtables_strtoul
libxtables: make multiint parser have greater range
libxtables: unclutter xtopt_parse_mint
libxtables: have xtopt_parse_mint interpret partially-spec'd ranges
libxt_NFQUEUE: avoid double attempt at parsing
libxt_NFQUEUE: add mutual exclusion between qnum and qbal
libxt_time: always ignore libc timezone
libxt_time: --utc and --localtz are mutually exclusive
libxt_time: deprecate --localtz option, document kernel TZ caveats
Jozsef Kadlecsik (3):
Fix listing/saving the new revision of the SET target
Fix set match/target direction parser
SET target revision 2 added
Li Yewang (1):
xtables: fix typo in error message of xtables_register_match()
Lutz Jaenicke (2):
libipt_REDIRECT: "--to-ports" is not mandatory
libxt_devgroup: actually set XT_DEVGROUP_OPT_???GROUP flags
Maciej Zenczykowski (20):
man pages: allow underscores in match and target names
mark newly opened fds as FD_CLOEXEC (close on exec)
xtables_ip6addr_to_numeric: fix typo in comment
xtables: delay (statically built) match/target initialization
v4: rename init_extensions() to init_extensions4()
v6: rename init_extensions() to init_extensions6()
xtables.h: init_extensions() no longer exists
v4: rename for_each_chain() to for_each_chain4()
v6: rename for_each_chain() to for_each_chain6()
v4: rename flush_entries() to flush_entries4()
v6: rename flush_entries() to flush_entries6()
v4: rename delete_chain() to delete_chain4()
v6: rename delete_chain() to delete_chain6()
v4: rename print_rule() to print_rule4()
v6: rename print_rule() to print_rule6()
v4: rename do_command() to do_command4()
v6: rename do_command() to do_command6()
move 'int line' definition from ip6?tables.c into xtables.c
convert ip6?tables-multi to actually use their own header files
Don't load ip6?_tables module when already loaded
Maciej Żenczykowski (3):
Add --ipv4/-4 and --ipv6/-6 support to ip6?tables{,-restore}.
Move common parts of libext{4,6}.a into libext.a
combine ip6?tables-multi into xtables-multi
Mark Montague (1):
iptables: documentation for iptables and ip6tables "security" tables
Max Kellerman (1):
xtables: use strspn() to check if string needs to be quoted
Pablo Neira Ayuso (1):
libxt_cluster: fix inversion in the cluster match
Patrick McHardy (16):
Revert "libxtables: change option precedence order to be intuitive"
Merge branch 'master' of git://dev.medozas.de/iptables
extensions: libxt_conntrack: add support for specifying port ranges
extensions: add extension for devgroup match
Merge branch 'master' of git://dev.medozas.de/iptables
Merge branch 'master' of vishnu.netfilter.org:/data/git/iptables
Merge branch 'opts' of git://dev.medozas.de/iptables
Merge branch 'opts' of git://dev.medozas.de/iptables
Merge branch 'floating/opts' of git://dev.medozas.de/iptables
Merge branch 'opts' of git://dev.medozas.de/iptables
Merge branch 'opts' of git://dev.medozas.de/iptables
Merge branch 'master' of git://dev.medozas.de/iptables
Merge branch 'opts' of git://dev.medozas.de/iptables
Merge branch 'floating/opts' of git://dev.medozas.de/iptables
Merge branch 'master' of git://dev.medozas.de/iptables
Bump version to 1.4.11
Rob Leslie (1):
iptables-restore: resolve confusing policy error message
Stefan Tomanek (2):
ip(6)tables-multi: unify subcommand handling
iptables: add -C to check for existing rules
Stephen Beahm (1):
libipt_REDIRECT: avoid dereference of uninitialized pointer
Thomas Graf (2):
libxt_AUDIT: add AUDIT target
iptables: add manual page section for AUDIT target
Wes Campaigne (4):
libxtables: avoid confusing use of ai_protocol=IPPROTO_IPV6
xtables: fix excessive memory allocation in host_to_ipaddr
xtables: fix the broken detection/removal of redundant addresses
xtables: use all IPv6 addresses resolved from a hostname
^ permalink raw reply
* Re: [ANNOUNCE]: Release of iptables-1.4.11
From: Patrick McHardy @ 2011-05-26 17:04 UTC (permalink / raw)
To: Netfilter Development Mailinglist, NetDev, netfilter-announce,
"'netfilter@vger.kernel.org'" <netfilter
In-Reply-To: <4DDE857E.40807@trash.net>
Am 26.05.2011 18:53, schrieb Patrick McHardy:
> The netfilter coreteam presents:
>
> iptables version 1.4.10
That's supposed to read 1.4.11 of course :)
>
> the iptables release for the 2.6.39 kernels. Due to some mistakes
> on my side we didn't have a release for longer than expected, so
> this contains a rather large number of changes.
>
> Changes include:
>
> - various bugfixes, cleanups and documentation updates
>
> - a new "guided option parser" from Jan, replacing a lot of the
> open-coded option parsing by a data driven parser
>
> - support for the current SET target as contained in 2.6.39
>
> - support for the new devgroup match
>
> - support for the new AUDIT target
>
> - support for a new NFQUEUE bypass option, allowing to bypass the
> queue if no userspace listener is present
>
> - a new iptables option "-C" to check for existance of a rules
>
> - a new xtables-multi binary which supports both IPv4 and IPv6
>
> See the attached changelogs for the full list of changes.
>
> Version 1.4.11 can be obtained from:
>
> http://www.netfilter.org/projects/iptables/downloads.html
> ftp://ftp.netfilter.org/pub/iptables/
> git://git.netfilter.org/iptables.git
>
> On behalf of the Netfilter Core Team.
> Happy firewalling!
^ permalink raw reply
* Re: Setting shutdownspeed in r8169 driver
From: Ben Hutchings @ 2011-05-26 15:04 UTC (permalink / raw)
To: Bas Nedermeijer; +Cc: netdev
In-Reply-To: <201105242302.40221.bas@tcfaa.nl>
On Tue, 2011-05-24 at 23:02 +0200, Bas Nedermeijer wrote:
> Hello,
>
> I currently have an onboard nic, which allows me to use wake-on-lan. But link-
> speed goes to 10MBit when the system is shutdown. This causes a multicast/IPTV
> stream to be throttled back to 10Mbit. This is probably because the multicast
> stream actually a broadcast on my local network. I think some device is
> sending ethernet-pause frames (havent seem them, but not sure if they show up
> in tcpdump).
Pause frames are produced and consumed at the MAC control layer. Some
switches may forward pause frames, but I suspect that in this case the
switch is sending pause frames to the multicast sender because the
transmit queue for the 10M port is filling up.
For hardware that supports Ethernet flow control, there are usually
pause frame counters in the extended statistics (ethtool -S).
> I tried to disable flow-control on the sending device, but that
> didnt help, still the traffic is throttled when it has passed some switches. I
> read somewhere the windows driver has an option to specify the shutdown-
> linkspeed, so listening for WOL happens on 100mbit. I was wondering if it is
> possible at all with the linux-driver (maybe as default by modifying the
> driver locally as I cant seem to find a userspace program to modify the
> settings).
No, there is no such setting within the ethtool API for WOL
configuration on Linux. It seems like it would be a useful extension.
Ben.
> I am using the driver "r8169"
>
> According to 'lspci':
>
> Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet
> controller (rev 02)
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 1/1] IPVS : bug in ip_vs_ftp, same list heaad used in all netns.
From: Pablo Neira Ayuso @ 2011-05-26 17:17 UTC (permalink / raw)
To: Hans Schillstrom
Cc: horms, ja, wensong, lvs-devel, netdev, netfilter-devel, hans
In-Reply-To: <1306239065-17271-1-git-send-email-hans.schillstrom@ericsson.com>
On 24/05/11 14:11, Hans Schillstrom wrote:
> When ip_vs was adapted to netns the ftp application was not adapted
> in a correct way.
> However this is a fix to avoid kernel errors. In the long term another solution
> might be chosen. I.e the ports that the ftp appl, uses should be per netns.
applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp compilation failed due to lack of sctp_local_addr_free
From: David Miller @ 2011-05-26 17:39 UTC (permalink / raw)
To: dmitry; +Cc: netdev, difrost.kernel
In-Reply-To: <1306427323.7510.2.camel@lb-tlvb-dmitry>
This has been fixed for days.
^ 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