* Re: [PATCH] net: Fix RPF to work with policy routing
From: jamal @ 2009-10-23 10:51 UTC (permalink / raw)
To: David Miller; +Cc: netdev, atis, eric.dumazet, zenczykowski
In-Reply-To: <20091022.214943.105371652.davem@davemloft.net>
On Thu, 2009-10-22 at 21:49 -0700, David Miller wrote:
> Such a change has a built-in assumption, I think, that
> marks are symmetric.
Only if the admin said they are symetric (by jumping
a few hoops). In otherwise, I may intentionaly want
them to be symetric and use policy routing. I cant today.
> Just because we ended up with mark X on input doesn't mean
> that the reverse path route exists with mark X too.
>
> In fact I can't even see a valid way to specify a mark for
> the RPF lookup.
with the ipt or skbedit actions or via netfilter i could
set marks which could be as trivial as "set mark X if packet
came in via eth0 or eth1 and mark Y if they came in via gre0"
> Maybe you can convince me otherwise :-)
Ok, let me try ;->
First let me say that it is _non-trivial_ for a packet to be
policy-routing-RPF-dropped even with this patch. Youd have to do at
least 3 things to achieve that goal:
a) mark the packet on ingress
b) have a blackhole route in the policy routing table as the fall
through match and
c) turn on rpf.
If someone goes that far to install policies, their intent could be
judged to mean they are serious about using RPF with policy routing.
If any of the above 3 conditions are not true then things continue to
work as is today.
IOW, if i set all those 3 conditions above then my expectation is the
system should not let in a packet if the policy routing table says no.
My intent is not to use the main table or some default route in the main
table; i really meant to use that policy routing table.
cheers,
jamal
^ permalink raw reply
* [PATCH] e1000: the power down when running ifdown command
From: Naohiro Ooiwa @ 2009-10-23 10:29 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, PJ Waskiewicz, Joh
Cc: netdev@vger.kernel.org, svaidy, e1000-devel, linux-kernel-owner,
akpm
I resend the mail to maintainers of the e1000 driver.
and Andrew CC-ed.
-------- Original Message --------
Hi all
I'm trying to modify e1000 driver for power saving.
The e1000 driver doesn't let the power down when running ifdown command.
So, I set to the D3hot state of a PCI device at the end of e1000_close().
With this modification, e1000 driver reduces power by ifdown
to the same level as link-down case.
I spoke it in Collaboration Summit 2009.
For details and result of power measurement,
please refer the 36-38 page of following document.
http://events.linuxfoundation.org/archive/lfcs09_ooiwa.pdf
Could you please check the my patch ?
Should I consider WOL ?
Dosen't E1000_PCI_POWER_SAVE need ?
Thanks you.
Naohiro Ooiwa
Signed-off-by: Naohiro Ooiwa <nooiwa@miraclelinux.com>
---
drivers/net/e1000/e1000_main.c | 32 ++++++++++++++++++++++++++++++++
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index bcd192c..12e1a42 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -26,6 +26,11 @@
*******************************************************************************/
+/*
+ * define this if you want pci save power while ifdown.
+ */
+#define E1000_PCI_POWER_SAVE
+
#include "e1000.h"
#include <net/ip6_checksum.h>
@@ -1248,6 +1253,23 @@ static int e1000_open(struct net_device *netdev)
struct e1000_hw *hw = &adapter->hw;
int err;
+#ifdef E1000_PCI_POWER_SAVE
+ struct pci_dev *pdev = adapter->pdev;
+
+ pci_set_power_state(pdev, PCI_D0);
+ pci_restore_state(pdev);
+
+ if (adapter->need_ioport)
+ err = pci_enable_device(pdev);
+ else
+ err = pci_enable_device_mem(pdev);
+ if (err) {
+ printk(KERN_ERR "e1000: Cannot enable PCI device from power-save\n");
+ return err;
+ }
+ pci_set_master(pdev);
+#endif
+
/* disallow open during test */
if (test_bit(__E1000_TESTING, &adapter->flags))
return -EBUSY;
@@ -1265,6 +1287,7 @@ static int e1000_open(struct net_device *netdev)
goto err_setup_rx;
e1000_power_up_phy(adapter);
+ e1000_reset(adapter);
adapter->mng_vlan_id = E1000_MNG_VLAN_NONE;
if ((hw->mng_cookie.status &
@@ -1341,6 +1364,15 @@ static int e1000_close(struct net_device *netdev)
e1000_vlan_rx_kill_vid(netdev, adapter->mng_vlan_id);
}
+#ifdef E1000_PCI_POWER_SAVE
+#ifdef CONFIG_PM
+ pci_save_state(adapter->pdev);
+#endif
+ pci_disable_device(adapter->pdev);
+ pci_wake_from_d3(adapter->pdev, true);
+ pci_set_power_state(adapter->pdev, PCI_D3hot);
+#endif
+
return 0;
}
--
1.5.4.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* DM9000: Fix revision ID for DM9000B
From: Ben Dooks @ 2009-10-23 10:26 UTC (permalink / raw)
To: netdev; +Cc: Simtec Linux Team
[-- Attachment #1: dm9000-fix-revb-id.patch --]
[-- Type: text/plain, Size: 841 bytes --]
The DM9000B revision ID is 0x1A, not 0x1B as set in the curernt dm9000.h
header.
Fix bug reported by Paolo Zebelloni.
Signed-off-by: Ben Dooks <ben@simtec.co.uk>
Signed-off-by: Simtec Linux Team <linux@simtec.co.uk>
---
drivers/net/dm9000.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: b/drivers/net/dm9000.h
===================================================================
--- a/drivers/net/dm9000.h 2009-10-22 12:33:48.000000000 +0100
+++ b/drivers/net/dm9000.h 2009-10-22 12:33:53.000000000 +0100
@@ -50,7 +50,7 @@
#define DM9000_RCSR 0x32
#define CHIPR_DM9000A 0x19
-#define CHIPR_DM9000B 0x1B
+#define CHIPR_DM9000B 0x1A
#define DM9000_MRCMDX 0xF0
#define DM9000_MRCMD 0xF2
--
Ben (ben@fluff.org, http://www.fluff.org/)
'a smiley only costs 4 bytes'
^ permalink raw reply
* Re: [PATCH 2/5] page allocator: Do not allow interrupts to use ALLOC_HARDER
From: Stephan von Krawczynski @ 2009-10-23 9:57 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Jiri Kosina, Sven Geggus, Karol Lewandowski,
Tobias Oetiker, Rafael J. Wysocki, David Miller, Reinette Chatre,
Kalle Valo, David Rientjes, KOSAKI Motohiro, Mohamed Abbas,
Jens Axboe, John W. Linville, Pekka Enberg,
Bartlomiej Zolnierkiewicz, Greg Kroah-Hartman,
Kernel Testers List, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
In-Reply-To: <20091022163752.GU11778-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org>
On Thu, 22 Oct 2009 17:37:52 +0100
Mel Gorman <mel-wPRd99KPJ+uzQB+pC5nmwQ@public.gmane.org> wrote:
> In this case, it's ok. It's just a harmless heads-up that the kernel
> looks slightly different than expected. I posted a 2.6.31.4 version of
> the two patches that cause real problems.
After around 12 hours of runtime with patch 1/5 and 2/5 on 2.6.31.4 I can see
no page allocation failure messages so far. I'll keep you informed.
--
Regards,
Stephan
^ permalink raw reply
* Re: bridging + load balancing bonding
From: Eric Dumazet @ 2009-10-23 9:54 UTC (permalink / raw)
To: Jasper Spaans; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091023095137.GA22424@spaans.fox.local>
Jasper Spaans a écrit :
> On Fri, Oct 23, 2009 at 10:55:31AM +0200, Eric Dumazet wrote:
>
>> Dont you think special attention is needed for multicast/broadcast trafic
>> (they should be sent to both IDS) ?
>
> Not really -- AFAIK we're currently not using the information encapsulated
> in broadcast traffic to judge the unicast packets. Besides, we're
> aggregating the results from the IDSes, so it shouldn't matter on which node
> a packet is processed.
>
> But if the need arises, this could be added quite easily to the code.
>
OK
I found following very interesting article that can give pretty good advices
http://lwn.net/Articles/145406/
^ permalink raw reply
* Re: bridging + load balancing bonding
From: Jasper Spaans @ 2009-10-23 9:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <4AE16F83.7080400@gmail.com>
On Fri, Oct 23, 2009 at 10:55:31AM +0200, Eric Dumazet wrote:
> Dont you think special attention is needed for multicast/broadcast trafic
> (they should be sent to both IDS) ?
Not really -- AFAIK we're currently not using the information encapsulated
in broadcast traffic to judge the unicast packets. Besides, we're
aggregating the results from the IDSes, so it shouldn't matter on which node
a packet is processed.
But if the need arises, this could be added quite easily to the code.
Jasper
--
Fox-IT Experts in IT Security!
T: +31 (0) 15 284 79 99
KvK Haaglanden 27301624
^ permalink raw reply
* [PATCH 23/10] Optimize the upload speed for PPP connection.
From: fangxiaozhi 00110321 @ 2009-10-23 9:47 UTC (permalink / raw)
To: netdev; +Cc: kernel, zihan, greg, haegar
From: fangxiaozhi <huananhu@huawei.com>
1. This patch is based on the kernel of 2.6.32-rc4
2. In this patch, we enlarge the out buffer size to optimize the upload speed for the ppp connection. Then it can support the upload of HSUPA data cards.
Signed-off-by: fangxiaozhi <huananhu@huawei.com>
-----------------------------------------------------------------------------------------
--- a/drivers/net/ppp_async.c 2009-10-12 05:43:56.000000000 +0800
+++ b/drivers/net/ppp_async.c 2009-10-15 16:29:56.000000000 +0800
@@ -36,7 +36,7 @@
#define PPP_VERSION "2.4.2"
-#define OBUFSIZE 256
+#define OBUFSIZE 2048
/* Structure for storing local state. */
struct asyncppp {
******************************************************************************************
This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained here in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this email in error, please notify the sender by phone or email
immediately and delete it!
*****************************************************************************************
^ permalink raw reply
* Re: VLAN and ARP failure on tg3 drivers
From: Benny Amorsen @ 2009-10-23 9:12 UTC (permalink / raw)
To: Gertjan Hofman; +Cc: netdev
In-Reply-To: <93821.71108.qm@web32607.mail.mud.yahoo.com>
Gertjan Hofman <gertjan_hofman@yahoo.com> writes:
> Dear Kernel developers,
>
> A couple of weeks ago we tried to migrate from a 2.6.24 kernel to a
> 2.6.29 kernel and noticed our VLAN application no longer works. The
> problem is easy to replicate:
>
> 1. connect 2 PC's with a cross-over cable
> 2. set up a fixed IP address to both PC's (say 192.168.0.[1,2])
> 3. create a vlan: vconfig add eth0 0.
VLAN 0 is a special case ("priority tag only"). If you're just trying to
use VLAN's, pick a different number. Also avoid 1001-1024 and 4095 if
you add switches to the mix, because some vendors have odd ideas.
/Benny
^ permalink raw reply
* Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit
From: David Rientjes @ 2009-10-23 9:36 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Jiri Kosina, Sven Geggus, Karol Lewandowski,
Tobias Oetiker, Rafael J. Wysocki, David Miller, Reinette Chatre,
Kalle Valo, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev, linux-kernel
In-Reply-To: <20091023091334.GV11778@csn.ul.ie>
On Fri, 23 Oct 2009, Mel Gorman wrote:
> > Hmm, is this really supposed to be added to __alloc_pages_high_priority()?
> > By the patch description I was expecting kswapd to be woken up
> > preemptively whenever the preferred zone is below ALLOC_WMARK_LOW and
> > we're known to have just allocated at a higher order, not just when
> > current was oom killed (when we should already be freeing a _lot_ of
> > memory soon) or is doing a higher order allocation during direct reclaim.
> >
>
> It was a somewhat arbitrary choice to have it trigger in the event high
> priority allocations were happening frequently.
>
I don't quite understand, users of PF_MEMALLOC shouldn't be doing these
higher order allocations and if ALLOC_NO_WATERMARKS is by way of the oom
killer, we should be freeing a substantial amount of memory imminently
when it exits that waking up kswapd would be irrelevant.
> > If this is moved to the fastpath, why is this wake_all_kswapd() and not
> > wakeup_kswapd(preferred_zone, order)? Do we need to kick kswapd in all
> > zones even though they may be free just because preferred_zone is now
> > below the watermark?
> >
>
> It probably makes no difference as zones are checked for their watermarks
> before any real work happens. However, even if this patch makes a difference,
> I don't want to see it merged. At best, it is an extremely heavy-handed
> hack which is why I asked for it to be tested in isolation. It shouldn't
> be necessary at all because sort of pre-emptive waking of kswapd was never
> necessary before.
>
Ahh, that makes a ton more sense: this particular patch is a debugging
effort while the first two are candidates for 2.6.32 and -stable. Gotcha.
> > Wouldn't it be better to do this on page_zone(page) instead of
> > preferred_zone anyway?
> >
>
> No. The preferred_zone is the zone we should be allocating from. If we
> failed to allocate from it, it implies the watermarks are not being met
> so we want to wake it.
>
Oops, I'm even more confused now :) I thought the existing
wake_all_kswapd() in the slowpath was doing that and that this patch was
waking them prematurely because it speculates that a subsequent high
order allocation will fail unless memory is reclaimed. I thought we'd
want to reclaim from the zone we just did a high order allocation from so
that the fastpath could find the memory next time with ALLOC_WMARK_LOW.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH 4/5] page allocator: Pre-emptively wake kswapd when high-order watermarks are hit
From: Mel Gorman @ 2009-10-23 9:13 UTC (permalink / raw)
To: David Rientjes
Cc: Frans Pop, Jiri Kosina, Sven Geggus, Karol Lewandowski,
Tobias Oetiker, Rafael J. Wysocki, David Miller, Reinette Chatre,
Kalle Valo, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org
In-Reply-To: <alpine.DEB.2.00.0910221227010.21601-X6Q0R45D7oAcqpCFd4KODRPsWskHk0ljAL8bYrjMMd8@public.gmane.org>
On Thu, Oct 22, 2009 at 12:41:42PM -0700, David Rientjes wrote:
> On Thu, 22 Oct 2009, Mel Gorman wrote:
>
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 7f2aa3e..851df40 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1596,6 +1596,17 @@ try_next_zone:
> > return page;
> > }
> >
> > +static inline
> > +void wake_all_kswapd(unsigned int order, struct zonelist *zonelist,
> > + enum zone_type high_zoneidx)
> > +{
> > + struct zoneref *z;
> > + struct zone *zone;
> > +
> > + for_each_zone_zonelist(zone, z, zonelist, high_zoneidx)
> > + wakeup_kswapd(zone, order);
> > +}
> > +
> > static inline int
> > should_alloc_retry(gfp_t gfp_mask, unsigned int order,
> > unsigned long pages_reclaimed)
> > @@ -1730,18 +1741,18 @@ __alloc_pages_high_priority(gfp_t gfp_mask, unsigned int order,
> > congestion_wait(BLK_RW_ASYNC, HZ/50);
> > } while (!page && (gfp_mask & __GFP_NOFAIL));
> >
> > - return page;
> > -}
> > -
> > -static inline
> > -void wake_all_kswapd(unsigned int order, struct zonelist *zonelist,
> > - enum zone_type high_zoneidx)
> > -{
> > - struct zoneref *z;
> > - struct zone *zone;
> > + /*
> > + * If after a high-order allocation we are now below watermarks,
> > + * pre-emptively kick kswapd rather than having the next allocation
> > + * fail and have to wake up kswapd, potentially failing GFP_ATOMIC
> > + * allocations or entering direct reclaim
> > + */
> > + if (unlikely(order) && page && !zone_watermark_ok(preferred_zone, order,
> > + preferred_zone->watermark[ALLOC_WMARK_LOW],
> > + zone_idx(preferred_zone), ALLOC_WMARK_LOW))
> > + wake_all_kswapd(order, zonelist, high_zoneidx);
> >
> > - for_each_zone_zonelist(zone, z, zonelist, high_zoneidx)
> > - wakeup_kswapd(zone, order);
> > + return page;
> > }
> >
> > static inline int
>
> Hmm, is this really supposed to be added to __alloc_pages_high_priority()?
> By the patch description I was expecting kswapd to be woken up
> preemptively whenever the preferred zone is below ALLOC_WMARK_LOW and
> we're known to have just allocated at a higher order, not just when
> current was oom killed (when we should already be freeing a _lot_ of
> memory soon) or is doing a higher order allocation during direct reclaim.
>
It was a somewhat arbitrary choice to have it trigger in the event high
priority allocations were happening frequently.
> For the best coverage, it would have to be add the branch to the fastpath.
Agreed - specifically at the end of __alloc_pages_nodemask()
> That seems fine for a debugging aid and to see if progress is being made
> on the GFP_ATOMIC allocation issues, but doesn't seem like it should make
> its way to mainline, the subsequent GFP_ATOMIC allocation could already be
> happening and in the page allocator's slowpath at this point that this
> wakeup becomes unnecessary.
>
> If this is moved to the fastpath, why is this wake_all_kswapd() and not
> wakeup_kswapd(preferred_zone, order)? Do we need to kick kswapd in all
> zones even though they may be free just because preferred_zone is now
> below the watermark?
>
It probably makes no difference as zones are checked for their watermarks
before any real work happens. However, even if this patch makes a difference,
I don't want to see it merged. At best, it is an extremely heavy-handed
hack which is why I asked for it to be tested in isolation. It shouldn't
be necessary at all because sort of pre-emptive waking of kswapd was never
necessary before.
> Wouldn't it be better to do this on page_zone(page) instead of
> preferred_zone anyway?
>
No. The preferred_zone is the zone we should be allocating from. If we
failed to allocate from it, it implies the watermarks are not being met
so we want to wake it.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: bridging + load balancing bonding
From: Eric Dumazet @ 2009-10-23 8:55 UTC (permalink / raw)
To: Jasper Spaans; +Cc: netdev@vger.kernel.org
In-Reply-To: <20091023083851.GA18457@spaans.fox.local>
Jasper Spaans a écrit :
> Hi Eric,
>
> On Thu, Oct 22, 2009 at 05:41:48PM +0200, Eric Dumazet wrote:
>
>> Very nice setup, and nice finding.
>>
>> Dont locally generated (or outed) packets have h_source set to bond_dev->dev_addr anyway ?
>>
>> So your solution might be the right fix...
>>
>> About other ideas... I was thinking of TEE target (not in mainline unfortunatly) :
>>
>> iptables -t mangle -A PREROUTING -i eth0 <some hash on mac addr> -j TEE --gateway 192.168.99.1 # IDS1
>> iptables -t mangle -A PREROUTING -i eth0 !<some hash on mac addr> -j TEE --gateway 192.168.99.2 # IDS2
>
> Unfortunately, this won't work: the TEE target works at IP-level, and
> changes mac-addresses, which is a no-go thing for us.. (and we won't be able
> to see non-IP traffic such as ARP on the IDS machines)
>
Of course, iptables / TEE works at IP level, so you'll need some ebtables analogy to work at ethernet level.
Dont you think special attention is needed for multicast/broadcast trafic (they should be sent to both IDS) ?
^ permalink raw reply
* Re: bridging + load balancing bonding
From: Jasper Spaans @ 2009-10-23 8:38 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev@vger.kernel.org
In-Reply-To: <4AE07D3C.3040702@gmail.com>
Hi Eric,
On Thu, Oct 22, 2009 at 05:41:48PM +0200, Eric Dumazet wrote:
> Very nice setup, and nice finding.
>
> Dont locally generated (or outed) packets have h_source set to bond_dev->dev_addr anyway ?
>
> So your solution might be the right fix...
>
> About other ideas... I was thinking of TEE target (not in mainline unfortunatly) :
>
> iptables -t mangle -A PREROUTING -i eth0 <some hash on mac addr> -j TEE --gateway 192.168.99.1 # IDS1
> iptables -t mangle -A PREROUTING -i eth0 !<some hash on mac addr> -j TEE --gateway 192.168.99.2 # IDS2
Unfortunately, this won't work: the TEE target works at IP-level, and
changes mac-addresses, which is a no-go thing for us.. (and we won't be able
to see non-IP traffic such as ARP on the IDS machines)
Jasper
--
Fox-IT Experts in IT Security!
T: +31 (0) 15 284 79 99
KvK Haaglanden 27301624
^ permalink raw reply
* Re: Irq architecture for multi-core network driver.
From: Eric W. Biederman @ 2009-10-23 7:59 UTC (permalink / raw)
To: David Daney; +Cc: Chris Friesen, netdev, Linux Kernel Mailing List, linux-mips
In-Reply-To: <4AE0DB98.1000101@caviumnetworks.com>
David Daney <ddaney@caviumnetworks.com> writes:
> Chris Friesen wrote:
>> On 10/22/2009 03:40 PM, David Daney wrote:
>>
>>> The main problem I have encountered is how to fit the interrupt
>>> management into the kernel framework. Currently the interrupt source
>>> is connected to a single irq number. I request_irq, and then manage
>>> the masking and unmasking on a per cpu basis by directly manipulating
>>> the interrupt controller's affinity/routing registers. This goes
>>> behind the back of all the kernel's standard interrupt management
>>> routines. I am looking for a better approach.
>>>
>>> One thing that comes to mind is that I could assign a different
>>> interrupt number per cpu to the interrupt signal. So instead of
>>> having one irq I would have 32 of them. The driver would then do
>>> request_irq for all 32 irqs, and could call enable_irq and disable_irq
>>> to enable and disable them. The problem with this is that there isn't
>>> really a single packets-ready signal, but instead 16 of them. So If I
>>> go this route I would have 16(lines) x 32(cpus) = 512 interrupt
>>> numbers just for the networking hardware, which seems a bit excessive.
>>
>> Does your hardware do flow-based queues? In this model you have
>> multiple rx queues and the hardware hashes incoming packets to a single
>> queue based on the addresses, ports, etc. This ensures that all the
>> packets of a single connection always get processed in the order they
>> arrived at the net device.
>>
>
> Indeed, this is exactly what we have.
>
>
>> Typically in this model you have as many interrupts as queues
>> (presumably 16 in your case). Each queue is assigned an interrupt and
>> that interrupt is affined to a single core.
>
> Certainly this is one mode of operation that should be supported, but I would
> also like to be able to go for raw throughput and have as many cores as possible
> reading from a single queue (like I currently have).
I believe will detect false packet drops and ask for unnecessary
retransmits if you have multiple cores processing a single queue,
because you are processing the packets out of order.
Eric
^ permalink raw reply
* Re: [PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
From: Sven Geggus @ 2009-10-23 7:31 UTC (permalink / raw)
To: Mel Gorman
Cc: Frans Pop, Jiri Kosina, Karol Lewandowski, Tobias Oetiker,
Rafael J. Wysocki, David Miller, Reinette Chatre, Kalle Valo,
David Rientjes, KOSAKI Motohiro, Mohamed Abbas, Jens Axboe,
John W. Linville, Pekka Enberg, Bartlomiej Zolnierkiewicz,
Greg Kroah-Hartman, Stephan von Krawczynski, Kernel Testers List,
netdev, linux-kernel, linux-mm@kvack.org
In-Reply-To: <1256221356-26049-1-git-send-email-mel@csn.ul.ie>
Mel Gorman schrieb am Donnerstag, den 22. Oktober um 16:22 Uhr:
> [No BZ ID] Kernel crash on 2.6.31.x (kcryptd: page allocation failure..)
> This apparently is easily reproducible, particular in comparison to
> the other reports. The point of greatest interest is that this is
> order-0 GFP_ATOMIC failures. Sven, I'm hoping that you in particular
> will be able to follow the tests below as you are the most likely
> person to have an easily reproducible situation.
I will see what I can do on the weekend. Unfortunately the crash happens on
a somewhat important machine and afterwards the Software-RAID needs a resync
which takes a few hours.
Sven
--
"Those who do not understand Unix are condemned to reinvent it, poorly"
(Henry Spencer)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCHv2 2.6.32-rc5] r8169: fix Ethernet Hangup for RTL8110SC rev d
From: Simon Wunderlich @ 2009-10-23 6:57 UTC (permalink / raw)
To: netdev, simon.wunderlich, David Miller, bernhard.schmidt, romieu
[-- Attachment #1: Type: text/plain, Size: 2308 bytes --]
The 8110SC rev d chip on our board shows a regression which the 8110SB chip
did not have. When inbound traffic is overflowing the receive descriptor queue,
"holes" in the ring buffer may occur which lead to a hangup until the buffer
is filled again. The packets are than completely processed, but the ring
remains porous and no packets are processed until the next overflow. Setting
the interface down and up can fix the problem temporary from userspace.
For some reason we don't know, this behaviour is not occuring if the RxVlan
bit for hardware VLAN untagging is set. There is another "Work around for
AMD plateform" in the current code which checks the VLAN status
word in receive descriptors, but does never come to effect when hardware
VLAN support is enabled. We assume that this is a bug in the chip.
The following patch fixes the problem. Without the patch we could reproduce
the hang within minutes (given other devices also generating lots of
interrupts), without we couldn't reproduce within a few days of long term
testing.
This version contains minor style adjustments and is sent with mutt which
will hopefully not destroy the formatting again.
Signed-off-by: Bernhard Schmidt <bernhard.schmidt@saxnet.de>
Signed-off-by: Simon Wunderlich <simon.wunderlich@saxnet.de>
Acked-by: Francois Romieu <romieu@zoreil.com>
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 83c47d9..f98ef52 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1029,7 +1029,10 @@ static void rtl8169_vlan_rx_register(struct net_device *dev,
spin_lock_irqsave(&tp->lock, flags);
tp->vlgrp = grp;
- if (tp->vlgrp)
+ /*
+ * Do not disable RxVlan on 8110SCd.
+ */
+ if (tp->vlgrp || (tp->mac_version == RTL_GIGA_MAC_VER_05))
tp->cp_cmd |= RxVlan;
else
tp->cp_cmd &= ~RxVlan;
@@ -3197,6 +3200,14 @@ rtl8169_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
}
rtl8169_init_phy(dev, tp);
+
+ /*
+ * Pretend we are using VLANs; This bypasses a nasty bug where
+ * Interrupts stop flowing on high load on 8110SCd controllers.
+ */
+ if (tp->mac_version == RTL_GIGA_MAC_VER_05)
+ RTL_W16(CPlusCmd, RTL_R16(CPlusCmd) | RxVlan);
+
device_set_wakeup_enable(&pdev->dev, tp->features & RTL_FEATURE_WOL);
out:
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* Re: [PATCH] net: Fix RPF to work with policy routing
From: Maciej Żenczykowski @ 2009-10-23 6:30 UTC (permalink / raw)
To: David Miller; +Cc: hadi, netdev, atis, eric.dumazet
In-Reply-To: <20091022.214943.105371652.davem@davemloft.net>
In most of the use cases I've seen marking packets has been far from
symmetric (of course: not that this is representative of anything).
Although, to be fair, most of the time this is because packets in only
direction (usually trasmit) were even being marked in the first place.
However, I do agree that .mark should be explicitly initialized (or a
comment about it being left =0 inserted in the same location).
On Thu, Oct 22, 2009 at 21:49, David Miller <davem@davemloft.net> wrote:
> From: jamal <hadi@cyberus.ca>
> Date: Sun, 18 Oct 2009 08:13:39 -0400
>
>> On Sun, 2009-10-18 at 08:12 -0400, jamal wrote:
>>> policy routing never worked with mark.
>>
>> I meant policy routing, mark and RPF never worked together ;->
>
> Is this actually valid?
>
> Such a change has a built-in assumption, I think, that
> marks are symmetric.
>
> Just because we ended up with mark X on input doesn't mean
> that the reverse path route exists with mark X too.
>
> In fact I can't even see a valid way to specify a mark for
> the RPF lookup.
>
> Maybe you can convince me otherwise :-)
>
^ permalink raw reply
* Re: [patch next 3/4] netxen: fix bonding support
From: Eric W. Biederman @ 2009-10-23 5:57 UTC (permalink / raw)
To: Dhananjay Phadke; +Cc: netdev
In-Reply-To: <1241586309-12112-4-git-send-email-dhananjay@netxen.com>
Dhananjay Phadke <dhananjay@netxen.com> writes:
> o Pause traffic during mac addr change.
> o Enable setting mac address for NX3031.
In 2.6.31 when I try and use bonding with the netxen or
even simply set the mac address after the driver has
first loaded but before the nic is brought up I get:
As I read that oops. The problem is that netxen_send_cmd_descs
is being called before tx_ring->txq has been initialized.
tx_ring->txq happens in open, when the device is brought up.
Any chance you can look at the problem?
Eric
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: [<ffffffffa0128942>] netxen_send_cmd_descs.clone.2+0x26/0xfe [netxen_nic]
PGD 1fe76067 PUD b4d05067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
CPU 2
Modules linked in: ipt_REDIRECT vfat fat loop appletalk ipx p8023 rose ax25 tulip xt_hl ipt_LOG xt_limit ipt_REJECT xt_state xt_tcpudp dummy iptable_filter veth macvlan nfsd lockd nfs_acl auth_rpcgss exportfs sco bridge stp bnep l2cap bluetooth sunrpc cpufreq_ondemand acpi_cpufreq freq_table ext4 jbd2 crc16 dm_mirror dm_region_hash dm_log dm_multipath dm_mod uinput bonding ipv6 kvm_intel kvm fuse xt_multiport iptable_nat ip_tables nf_nat x_tables nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 tun 8021q i2c_i801 igb i2c_core i5k_amb hwmon i5400_edac edac_core iTCO_wdt iTCO_vendor_support pcspkr shpchp myri10ge floppy netxen_nic sr_mod cdrom serio_raw sg ata_generic pata_acpi ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
Pid: 22313, comm: ip Not tainted 2.6.31.2-193574.2006Arora.fc11.x86_64 #1 X7DWU
RIP: 0010:[<ffffffffa0128942>] [<ffffffffa0128942>] netxen_send_cmd_descs.clone.2+0x26/0xfe [netxen_nic]
RSP: 0018:ffff88005753d638 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff88005753d688 RDI: ffff88012dc8f580
RBP: ffff88005753d678 R08: ffff88012dc8f580 R09: ffff88005753d688
R10: 00000000a388069b R11: 0000000000000246 R12: ffff88012dc8f580
R13: ffff88001fcb6c00 R14: ffff88005753d738 R15: 0000000000000020
FS: 00007f4360f656f0(0000) GS:ffff88002805a000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000020 CR3: 00000000b4de5000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process ip (pid: 22313, threadinfo ffff88005753c000, task ffff88002fbdb700)
Stack:
0000000000000000 00000000a388069b ffffea000136a578 00000000a388069b
<0> ffff88005753d778 ffff88012dc8f580 ffff88012e2cf910 ffff88001fcb6c00
<0> ffff88005753d6d8 ffffffffa0128ae5 000000000a000000 0000000000010001
Call Trace:
[<ffffffffa0128ae5>] nx_p3_sre_macaddr_change+0x60/0x76 [netxen_nic]
[<ffffffffa0128ca8>] nx_p3_nic_add_mac+0x129/0x14c [netxen_nic]
[<ffffffffa0128d57>] netxen_p3_nic_set_multi+0x8c/0x169 [netxen_nic]
[<ffffffffa0128e54>] netxen_p3_nic_set_mac_addr+0x20/0x38 [netxen_nic]
[<ffffffffa0129ed2>] netxen_nic_set_mac+0x96/0xd6 [netxen_nic]
[<ffffffff813128b1>] do_setlink+0x17c/0x360
[<ffffffff81312e97>] rtnl_newlink+0x2e1/0x4e6
[<ffffffff81312c53>] ? rtnl_newlink+0x9d/0x4e6
[<ffffffff810ec697>] ? page_add_new_anon_rmap+0x4d/0x73
[<ffffffff812f8920>] ? sock_rmalloc+0x39/0xa8
[<ffffffff810fdc8c>] ? virt_to_head_page+0x1c/0x51
[<ffffffff813122fe>] rtnetlink_rcv_msg+0x1d0/0x201
[<ffffffff81327856>] ? netlink_sendmsg+0x18f/0x2ac
[<ffffffff8131212e>] ? rtnetlink_rcv_msg+0x0/0x201
[<ffffffff81327b7d>] netlink_rcv_skb+0x4d/0xb4
[<ffffffff81312113>] rtnetlink_rcv+0x30/0x4b
[<ffffffff8132764a>] netlink_unicast+0x12f/0x1ac
[<ffffffff81327950>] netlink_sendmsg+0x289/0x2ac
[<ffffffff812f4146>] __sock_sendmsg+0x6b/0x8a
[<ffffffff812f4abf>] sock_sendmsg+0xd6/0x103
[<ffffffff812f494b>] ? sock_recvmsg+0xd9/0x106
[<ffffffff8106a257>] ? autoremove_wake_function+0x0/0x5a
[<ffffffff812ff6b4>] ? verify_iovec+0x5b/0xaf
[<ffffffff812f4d08>] sys_sendmsg+0x21c/0x2a0
[<ffffffff810e3711>] ? handle_mm_fault+0x2d6/0x681
[<ffffffff811ced89>] ? __up_read+0x9c/0xbb
[<ffffffff8106e264>] ? up_read+0x1c/0x32
[<ffffffff813a9c3f>] ? do_page_fault+0x260/0x2a4
[<ffffffff8100bdc2>] system_call_fastpath+0x16/0x1b
Code: 5b 41 5c c9 c3 55 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 28 65 48 8b 04 25 28 00 00 00 48 89 45 d8 31 c0 48 8b 9f 28 01 00 00 <4c> 8b 6b 20 48 89 75 c8 49 8d 7d 40 e8 5e e9 27 e1 65 8b 04 25
RIP [<ffffffffa0128942>] netxen_send_cmd_descs.clone.2+0x26/0xfe [netxen_nic]
RSP <ffff88005753d638>
CR2: 0000000000000020
^ permalink raw reply
* Re: VLAN and ARP failure on tg3 drivers
From: Eric Dumazet @ 2009-10-23 5:23 UTC (permalink / raw)
To: Gertjan Hofman; +Cc: netdev
In-Reply-To: <93821.71108.qm@web32607.mail.mud.yahoo.com>
Gertjan Hofman a écrit :
> Dear Kernel developers,
>
> A couple of weeks ago we tried to migrate from a 2.6.24 kernel to a 2.6.29 kernel and noticed our VLAN application no longer works. The problem is easy to replicate:
>
> 1. connect 2 PC's with a cross-over cable
> 2. set up a fixed IP address to both PC's (say 192.168.0.[1,2])
> 3. create a vlan: vconfig add eth0 0.
> 4. set IP addresses on the VLAN devices (say 192.168.1.[1,2])
> 5. try ping one machine from the other.
>
> I tried to dig into the problem by using un-patched kernel.org kernels with Ubuntu .config files. Kernels up to 2.6.26 work fine, kernels after and including 2.6.27 fail. The problem is that ARP messages are being dropped. If the ARP table is updated by hand on each machine, the communication across the VLAN works fine.
>
> At first I thought the kernel VLAN code was the problem (we had an earlier issue with a regression in 2.6.24) but it looks like the problem is actually with the tg3 driver. Our system uses Broadcom ethernet chips. I tried the same experiments with combination of boards that have Broadcom and none-Broadcom and the only time I see it fail is with the tg3 driver loaded.
>
> Snooping with WireShark shows that a ARP request from the non-Broadcom machine is seen and even answered, but never appears back on the network. If the Broadcom machine orginates the ARP message, it never arrives at the destination. I tried lowering the size of the MTU to 1492 as well as giving each VLAN device a different MAC. No deal.
>
> I tried to look at tg3 patch changes from 2.6.26 to 2.6.27 but I am not familiar enough with the Git system to extract the appropiate changes. I am a bit surprised that I am not seeing any references to this on the web, the combination of >2.6.27 kernels, Broadcom and VLAN cant be that uncommon.
>
> I would be happy to provide more information and to try tests if any one can suggest them.
>
> Sincerely,
>
> Gertjan
Hello Gertjan
I'll take a look at this problem and try to reproduce it, but I use VLAN + tg3 +
bonding without noticing a regression yet.
Only difference is I use "ip link add link" command to setup VLANS, not vconfig,
a bit deprecated.
Could you try something like this setup
ip link set eth1 up
ip link add link eth1 vlan.103 type vlan id 103
ip addr add 192.168.20.110/24 dev vlan.103
ip link set vlan.103 up
^ permalink raw reply
* Re: [RFC][PATCH] pkt_sched: skbedit add support for setting mark
From: David Miller @ 2009-10-23 4:57 UTC (permalink / raw)
To: hadi; +Cc: denys, alexander.h.duyck, netdev
In-Reply-To: <1255612159.5033.1.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Thu, 15 Oct 2009 09:09:18 -0400
> On Wed, 2009-10-14 at 15:08 -0700, David Miller wrote:
>
>> This patch doesn't apply.
>
> Ok, Ive tested this on a separate machine - it applies and compiles.
Applied, thanks Jamal.
^ permalink raw reply
* Re: [PATCH] ifb: should not use __dev_get_by_index() without locks
From: David Miller @ 2009-10-23 4:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4ADDAEA6.2040903@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 20 Oct 2009 14:35:50 +0200
> [PATCH] ifb: should not use __dev_get_by_index() without locks
>
> At this point (ri_tasklet()), RTNL or dev_base_lock are not held,
> we must use dev_get_by_index() instead of __dev_get_by_index()
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks.
^ permalink raw reply
* VLAN and ARP failure on tg3 drivers
From: Gertjan Hofman @ 2009-10-23 4:52 UTC (permalink / raw)
To: netdev
Dear Kernel developers,
A couple of weeks ago we tried to migrate from a 2.6.24 kernel to a 2.6.29 kernel and noticed our VLAN application no longer works. The problem is easy to replicate:
1. connect 2 PC's with a cross-over cable
2. set up a fixed IP address to both PC's (say 192.168.0.[1,2])
3. create a vlan: vconfig add eth0 0.
4. set IP addresses on the VLAN devices (say 192.168.1.[1,2])
5. try ping one machine from the other.
I tried to dig into the problem by using un-patched kernel.org kernels with Ubuntu .config files. Kernels up to 2.6.26 work fine, kernels after and including 2.6.27 fail. The problem is that ARP messages are being dropped. If the ARP table is updated by hand on each machine, the communication across the VLAN works fine.
At first I thought the kernel VLAN code was the problem (we had an earlier issue with a regression in 2.6.24) but it looks like the problem is actually with the tg3 driver. Our system uses Broadcom ethernet chips. I tried the same experiments with combination of boards that have Broadcom and none-Broadcom and the only time I see it fail is with the tg3 driver loaded.
Snooping with WireShark shows that a ARP request from the non-Broadcom machine is seen and even answered, but never appears back on the network. If the Broadcom machine orginates the ARP message, it never arrives at the destination. I tried lowering the size of the MTU to 1492 as well as giving each VLAN device a different MAC. No deal.
I tried to look at tg3 patch changes from 2.6.26 to 2.6.27 but I am not familiar enough with the Git system to extract the appropiate changes. I am a bit surprised that I am not seeing any references to this on the web, the combination of >2.6.27 kernels, Broadcom and VLAN cant be that uncommon.
I would be happy to provide more information and to try tests if any one can suggest them.
Sincerely,
Gertjan
^ permalink raw reply
* Re: [PATCH] net: Fix RPF to work with policy routing
From: David Miller @ 2009-10-23 4:49 UTC (permalink / raw)
To: hadi; +Cc: netdev, atis, eric.dumazet, zenczykowski
In-Reply-To: <1255868019.4815.27.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Sun, 18 Oct 2009 08:13:39 -0400
> On Sun, 2009-10-18 at 08:12 -0400, jamal wrote:
>> policy routing never worked with mark.
>
> I meant policy routing, mark and RPF never worked together ;->
Is this actually valid?
Such a change has a built-in assumption, I think, that
marks are symmetric.
Just because we ended up with mark X on input doesn't mean
that the reverse path route exists with mark X too.
In fact I can't even see a valid way to specify a mark for
the RPF lookup.
Maybe you can convince me otherwise :-)
^ permalink raw reply
* Re: [PATCH][RESEND] myri10ge: improve port type reporting in ethtool
From: David Miller @ 2009-10-23 4:43 UTC (permalink / raw)
To: brice; +Cc: netdev, bhutchings
In-Reply-To: <4ADD5702.80804@myri.com>
From: Brice Goglin <brice@myri.com>
Date: Tue, 20 Oct 2009 08:21:54 +0200
> Improve the reporting of myri10ge port type in ethtool,
> and update for new boards.
>
> Signed-off-by: Brice Goglin <brice@myri.com>
> Signed-off-by: Andrew Gallatin <gallatin@myri.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: use WARN() for the WARN_ON in commit b6b39e8f3fbbb
From: David Miller @ 2009-10-23 4:38 UTC (permalink / raw)
To: arjan; +Cc: herbert, netdev
In-Reply-To: <20091022203512.1d714d5a@infradead.org>
From: Arjan van de Ven <arjan@infradead.org>
Date: Thu, 22 Oct 2009 20:35:12 -0700
> Commit b6b39e8f3fbbb (tcp: Try to catch MSG_PEEK bug) added a printk()
> to the WARN_ON() that's in tcp.c. This patch changes this combination
> to WARN(); the advantage of WARN() is that the printk message shows up
> inside the message, so that kerneloops.org will collect the message.
>
> In addition, this gets rid of an extra if() statement.
>
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Applied, thanks.
^ permalink raw reply
* [PATCH iproute2] ip: speedup store_nlmsg()
From: Eric Dumazet @ 2009-10-23 4:37 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Linux Netdev List
ip link show command has O(N^2) complexity, because it loops until list end.
Adding pointer to last elements avoids this loop.
Before patch :
# time ip -o link | wc
15013 240212 2136365
real 0m0.738s
user 0m0.770s
sys 0m0.035s
# time ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1e:0b:ec:d3:dc brd ff:ff:ff:ff:ff:ff
real 0m0.565s
user 0m0.540s
sys 0m0.025s
After patch :
# time ip/ip -o link | wc
15013 210192 2031310
real 0m0.189s
user 0m0.221s
sys 0m0.032s
# time ip/ip link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:1e:0b:ec:d3:dc brd ff:ff:ff:ff:ff:ff
real 0m0.032s
user 0m0.006s
sys 0m0.026s
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index cadc1a3..7674256 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -570,13 +570,16 @@ static int print_selected_addrinfo(int ifindex, struct nlmsg_list *ainfo, FILE *
return 0;
}
+struct nlmsg_list_info {
+ struct nlmsg_list *first;
+ struct nlmsg_list *last;
+};
static int store_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
void *arg)
{
- struct nlmsg_list **linfo = (struct nlmsg_list**)arg;
+ struct nlmsg_list_info *linfo = (struct nlmsg_list_info *)arg;
struct nlmsg_list *h;
- struct nlmsg_list **lp;
h = malloc(n->nlmsg_len+sizeof(void*));
if (h == NULL)
@@ -585,8 +588,11 @@ static int store_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
memcpy(&h->h, n, n->nlmsg_len);
h->next = NULL;
- for (lp = linfo; *lp; lp = &(*lp)->next) /* NOTHING */;
- *lp = h;
+ if (linfo->first)
+ linfo->last->next = h;
+ else
+ linfo->first = h;
+ linfo->last = h;
ll_remember_index(who, n, NULL);
return 0;
@@ -594,8 +600,8 @@ static int store_nlmsg(const struct sockaddr_nl *who, struct nlmsghdr *n,
static int ipaddr_list_or_flush(int argc, char **argv, int flush)
{
- struct nlmsg_list *linfo = NULL;
- struct nlmsg_list *ainfo = NULL;
+ struct nlmsg_list_info linfo = {0};
+ struct nlmsg_list_info ainfo = {0};
struct nlmsg_list *l, *n;
char *filter_dev = NULL;
int no_link = 0;
@@ -750,7 +756,7 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
if (filter.family && filter.family != AF_PACKET) {
struct nlmsg_list **lp;
- lp=&linfo;
+ lp = &linfo.first;
if (filter.oneline)
no_link = 1;
@@ -760,7 +766,7 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
struct ifinfomsg *ifi = NLMSG_DATA(&l->h);
struct nlmsg_list *a;
- for (a=ainfo; a; a=a->next) {
+ for (a = ainfo.first; a; a = a->next) {
struct nlmsghdr *n = &a->h;
struct ifaddrmsg *ifa = NLMSG_DATA(n);
@@ -807,12 +813,12 @@ static int ipaddr_list_or_flush(int argc, char **argv, int flush)
}
}
- for (l=linfo; l; l = n) {
+ for (l = linfo.first; l; l = n) {
n = l->next;
if (no_link || print_linkinfo(NULL, &l->h, stdout) == 0) {
struct ifinfomsg *ifi = NLMSG_DATA(&l->h);
if (filter.family != AF_PACKET)
- print_selected_addrinfo(ifi->ifi_index, ainfo, stdout);
+ print_selected_addrinfo(ifi->ifi_index, ainfo.first, stdout);
}
fflush(stdout);
free(l);
^ permalink raw reply related
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