* Re: Stable regression with 'tcp: allow splice() to build full TSO packets'
From: Willy Tarreau @ 2012-05-17 22:30 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120517.182545.91312407467980757.davem@davemloft.net>
On Thu, May 17, 2012 at 06:25:45PM -0400, David Miller wrote:
> From: Willy Tarreau <w@1wt.eu>
> Date: Fri, 18 May 2012 00:24:31 +0200
>
> > On Fri, May 18, 2012 at 12:22:31AM +0200, Eric Dumazet wrote:
> >> Hmm... I believe I prefer your prior patch ( the one I Acked)
> >
> > I too, less changes are better :-)
>
> And I think that's the one I'm going to apply after I audit this
> code a little bit myself.
>
> Thanks!
Sorry for the double mail, I didn't know if you were following the thread
when I forwarded it to you.
Cheers,
Willy
^ permalink raw reply
* Re: [net] e1000: Prevent reset task killing itself.
From: David Miller @ 2012-05-17 22:33 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: tushar.n.dave, netdev, gospo, sassmann, stable
In-Reply-To: <1337252690-29687-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 17 May 2012 04:04:50 -0700
> From: Tushar Dave <tushar.n.dave@intel.com>
>
> Killing reset task while adapter is resetting causes deadlock.
> Only kill reset task if adapter is not resetting.
> Ref bug #43132 on bugzilla.kernel.org
>
> CC: stable@vger.kernel.org
> Signed-off-by: Tushar Dave <tushar.n.dave@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks.
^ permalink raw reply
* Re: Stable regression with 'tcp: allow splice() to build full TSO packets'
From: David Miller @ 2012-05-17 22:35 UTC (permalink / raw)
To: w; +Cc: eric.dumazet, netdev
In-Reply-To: <20120517223028.GV14498@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Fri, 18 May 2012 00:30:28 +0200
> On Thu, May 17, 2012 at 06:25:45PM -0400, David Miller wrote:
>> From: Willy Tarreau <w@1wt.eu>
>> Date: Fri, 18 May 2012 00:24:31 +0200
>>
>> > On Fri, May 18, 2012 at 12:22:31AM +0200, Eric Dumazet wrote:
>> >> Hmm... I believe I prefer your prior patch ( the one I Acked)
>> >
>> > I too, less changes are better :-)
>>
>> And I think that's the one I'm going to apply after I audit this
>> code a little bit myself.
>>
>> Thanks!
>
> Sorry for the double mail, I didn't know if you were following the thread
> when I forwarded it to you.
No problem.
BTW, this issue goes back all the way to the original implementation
of do_tcp_sendpages().
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2012-05-17 22:44 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Thanks to Willy Tarreau and Eric Dumazet, we've unlocked a bug that's
been present in do_tcp_sendpages() since that function was written in
2002.
When we block to wait for memory we have to unconditionally try and
push out pending TCP data, otherwise we can block for an
unreasonably long amount of time.
2) Fix deadlock in e1000, fixes kernel bugzilla 43132
From Tushar Dave.
Please pull, thanks a lot!
The following changes since commit 1be5f0b7575e090fd100a98b303860879b5800de:
Merge branch 'fixes' of git://git.infradead.org/users/vkoul/slave-dma (2012-05-17 09:57:13 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net master
for you to fetch changes up to 8ce6909f77ba1b7bcdea65cc2388fd1742b6d669:
e1000: Prevent reset task killing itself. (2012-05-17 18:32:41 -0400)
----------------------------------------------------------------
Tushar Dave (1):
e1000: Prevent reset task killing itself.
Willy Tarreau (1):
tcp: do_tcp_sendpages() must try to push data out on oom conditions
drivers/net/ethernet/intel/e1000/e1000_main.c | 6 +++++-
net/ipv4/tcp.c | 3 +--
2 files changed, 6 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next] lapb: Neaten debugging
From: David Miller @ 2012-05-17 22:45 UTC (permalink / raw)
To: joe; +Cc: linux-x25, netdev, linux-kernel
In-Reply-To: <1337286349.17726.58.camel@joe2Laptop>
From: Joe Perches <joe@perches.com>
Date: Thu, 17 May 2012 13:25:49 -0700
> Enable dynamic debugging and remove a bunch of #ifdef/#endifs.
>
> Add a lapb_dbg(level, fmt, ...) macro and replace the
> printk(KERN_DEBUG uses.
> Add pr_fmt and remove embedded prefixes.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied, thanks Joe.
^ permalink raw reply
* Re: Stable regression with 'tcp: allow splice() to build full TSO packets'
From: Willy Tarreau @ 2012-05-17 22:49 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev
In-Reply-To: <20120517.183520.1377234710702090939.davem@davemloft.net>
On Thu, May 17, 2012 at 06:35:20PM -0400, David Miller wrote:
> BTW, this issue goes back all the way to the original implementation
> of do_tcp_sendpages().
I'm not surprized, I remember about tux on 2.4 sometimes leaving frozen
connections behind it when pushed to extreme speeds back in the days where
it was audacious to pull 2 Gbps out of a Pentium3.
I like it when we find very old issues when improving the code, it generally
means we're stressing it a bit more and making more efficient use of it.
Cheers,
Willy
^ permalink raw reply
* Re: [RFC PATCH net-next] hp100: delete VG/AnyLAN hp100
From: Joe Perches @ 2012-05-17 22:50 UTC (permalink / raw)
To: Francois Romieu, Joel Soete
Cc: Paul Gortmaker, linux-kernel, JBottomley, David S. Miller, netdev,
Joel Soete
In-Reply-To: <20120517222843.GA30680@electric-eye.fr.zoreil.com>
On Fri, 2012-05-18 at 00:28 +0200, Francois Romieu wrote:
> Joe Perches <joe@perches.com> :
> > On Thu, 2012-05-17 at 17:20 -0400, Paul Gortmaker wrote:
> > > [Re: [PATCH 2/5] drivers/net: delete all code/drivers depending on CONFIG_MCA
> >
> > If we're removing really old and unused stuff,
> > how about the VG/AnyLAN driver too?
>
> Joel Soete appeared to actively use a PCI one with recent kernels back
> in 2007.
I saw people using TR adapters with Linux as of 2008/9.
That doesn't mean it's common or make it desirable to
keep TR in the current kernel tree though.
Is VG/AnyLAN different?
^ permalink raw reply
* [PATCH] e1000: Reset rx ring index on receive overrun
From: Samuel Thibault @ 2012-05-17 23:01 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, David S. Miller, Jiri Pirko, Dean Nelson,
e1000-devel, netdev
Cc: linux-kernel
At high traffic rate, the rx ring may get completely filled before we
manage to consume it. After it is filled, the kernel and device indexes
are not synchronized any more, so we have to reset them, otherwise the
kernel will be stuck waiting for the wrong slot to be filled.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
---
This is just a patch suggestion, I'm not an expert in network drivers, I
leave to actual driver authors to bake a better version.
diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c b/drivers/net/ethernet/intel/e1000/e1000_main.c
index 37caa88..77c8dbc 100644
--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
@@ -3759,6 +3759,21 @@ static irqreturn_t e1000_intr(int irq, void *data)
if (unlikely(test_bit(__E1000_DOWN, &adapter->flags)))
return IRQ_HANDLED;
+ if (unlikely(icr & E1000_ICR_RXO)) {
+ /* Receive Overrun */
+ u32 rctl;
+ int i;
+ rctl = er32(RCTL);
+ ew32(RCTL, rctl & ~E1000_RCTL_EN);
+ for (i = 0; i < adapter->num_rx_queues; i++) {
+ memset(adapter->rx_ring[i].desc, 0, adapter->rx_ring[i].size);
+ adapter->rx_ring[i].next_to_clean = 0;
+ }
+ ew32(RDH, 0);
+ ew32(RCTL, rctl);
+ adapter->netdev->stats.rx_fifo_errors++;
+ }
+
if (unlikely(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))) {
hw->get_link_status = 1;
/* guard against interrupt when we're going down */
^ permalink raw reply related
* Re: [PATCH V3] CS89x0 : Use ioread16/iowrite16 on all platforms
From: David Miller @ 2012-05-17 23:03 UTC (permalink / raw)
To: jaccon.bastiaansen
Cc: arnd, netdev, s.hauer, romieu, joe, gfm, festevam,
linux-arm-kernel
In-Reply-To: <1337274702-19536-1-git-send-email-jaccon.bastiaansen@gmail.com>
From: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Date: Thu, 17 May 2012 19:11:42 +0200
> The use of the inw/outw functions by the cs89x0 platform driver
> results in NULL pointer references on ARM platforms and
> platforms that do not provide ISA-style programmed I/O accessors.
>
> Using inw/outw also accesses the wrong address space on platforms
> that have a PCI I/O space that is not identity-mapped into the
> physical address space.
>
> Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
I could nit-pick more on this patch, but it's such a significant
improvement I'm just going to apply this V3 as-is to net-next.
Thanks.
^ permalink raw reply
* Re: [PATCH] e1000: Reset rx ring index on receive overrun
From: Dave, Tushar N @ 2012-05-17 23:22 UTC (permalink / raw)
To: Samuel Thibault, Kirsher, Jeffrey T, Brandeburg, Jesse,
Allan, Bruce W, Wyborny, Carolyn, Skidmore, Donald C,
Rose, Gregory V, Waskiewicz Jr, Peter P, Duyck, Alexander H,
Ronciak, John, David S. Miller, Jiri Pirko, Dean Nelson,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20120517230140.GZ683@type.famille.thibault.fr>
I am interested in to see if you have actual test case and more importantly test data that shows that kernel and device indexes are not synchronized any more.
-Tushar
>-----Original Message-----
>From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
>On Behalf Of Samuel Thibault
>Sent: Thursday, May 17, 2012 4:02 PM
>To: Kirsher, Jeffrey T; Brandeburg, Jesse; Allan, Bruce W; Wyborny,
>Carolyn; Skidmore, Donald C; Rose, Gregory V; Waskiewicz Jr, Peter P;
>Duyck, Alexander H; Ronciak, John; David S. Miller; Jiri Pirko; Dean
>Nelson; e1000-devel@lists.sourceforge.net; netdev@vger.kernel.org
>Cc: linux-kernel@vger.kernel.org
>Subject: [PATCH] e1000: Reset rx ring index on receive overrun
>
>At high traffic rate, the rx ring may get completely filled before we
>manage to consume it. After it is filled, the kernel and device indexes
>are not synchronized any more, so we have to reset them, otherwise the
>kernel will be stuck waiting for the wrong slot to be filled.
>
>Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
>
>---
>This is just a patch suggestion, I'm not an expert in network drivers, I
>leave to actual driver authors to bake a better version.
>
>diff --git a/drivers/net/ethernet/intel/e1000/e1000_main.c
>b/drivers/net/ethernet/intel/e1000/e1000_main.c
>index 37caa88..77c8dbc 100644
>--- a/drivers/net/ethernet/intel/e1000/e1000_main.c
>+++ b/drivers/net/ethernet/intel/e1000/e1000_main.c
>@@ -3759,6 +3759,21 @@ static irqreturn_t e1000_intr(int irq, void *data)
> if (unlikely(test_bit(__E1000_DOWN, &adapter->flags)))
> return IRQ_HANDLED;
>
>+ if (unlikely(icr & E1000_ICR_RXO)) {
>+ /* Receive Overrun */
>+ u32 rctl;
>+ int i;
>+ rctl = er32(RCTL);
>+ ew32(RCTL, rctl & ~E1000_RCTL_EN);
>+ for (i = 0; i < adapter->num_rx_queues; i++) {
>+ memset(adapter->rx_ring[i].desc, 0, adapter-
>>rx_ring[i].size);
>+ adapter->rx_ring[i].next_to_clean = 0;
>+ }
>+ ew32(RDH, 0);
>+ ew32(RCTL, rctl);
>+ adapter->netdev->stats.rx_fifo_errors++;
>+ }
>+
> if (unlikely(icr & (E1000_ICR_RXSEQ | E1000_ICR_LSC))) {
> hw->get_link_status = 1;
> /* guard against interrupt when we're going down */
>--
>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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] e1000: Reset rx ring index on receive overrun
From: Samuel Thibault @ 2012-05-17 23:28 UTC (permalink / raw)
To: Dave, Tushar N
Cc: Jiri Pirko, e1000-devel@lists.sourceforge.net, Dean Nelson,
Allan, Bruce W, Brandeburg, Jesse, linux-kernel@vger.kernel.org,
Ronciak, John, netdev@vger.kernel.org, David S. Miller
In-Reply-To: <061C8A8601E8EE4CA8D8FD6990CEA891188439E0@ORSMSX102.amr.corp.intel.com>
Dave, Tushar N, le Thu 17 May 2012 23:22:31 +0000, a écrit :
> I am interested in to see if you have actual test case and more importantly test data that shows that kernel and device indexes are not synchronized any more.
Well, it's not with an actual physical device, but with the kvm
emulation. Printing indexes from the clean_rx handler, I'm getting:
(status linux index/total size/device index)
status 7 2/256/19
status 7 3/256/19
...
status 7 18/256/19
status 7 19/256/19
status 7 20/256/19
status 7 21/256/19
...
since the status is still 7, linux continues on.
...
status 7 254/256/19
status 7 255/256/19
status 7 0/256/19
status 7 1/256/19
status 0 2/256/19
here it stops, and on next interrupts,
status 0 2/256/20
status 0 2/256/21
etc. and no progress is made any more, until
status 0 2/256/253
status 0 2/256/254
and it gets stuck there:
status 0 2/256/254
status 0 2/256/254
status 0 2/256/254
Samuel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] e1000: Reset rx ring index on receive overrun
From: Samuel Thibault @ 2012-05-17 23:31 UTC (permalink / raw)
To: Dave, Tushar N, Kirsher, Jeffrey T, Brandeburg, Jesse,
Allan, Bruce W, Wyborny, Carolyn, Skidmore, Donald C,
Rose, Gregory V, Waskiewicz Jr, Peter P, Duyck, Alexander H,
Ronciak, John, David S. Miller, Jiri Pirko, Dean Nelson,
e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20120517232821.GJ683@type.famille.thibault.fr>
Samuel Thibault, le Fri 18 May 2012 01:28:21 +0200, a écrit :
> Dave, Tushar N, le Thu 17 May 2012 23:22:31 +0000, a écrit :
> > I am interested in to see if you have actual test case and more importantly test data that shows that kernel and device indexes are not synchronized any more.
>
> Well, it's not with an actual physical device, but with the kvm
> emulation.
BTW, it also happens easily when request_irq takes some time to
complete: since we enable E1000_TCTL_EN before that, the card can have
time to fill the ring before irqs are processed.
Samuel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] e1000: Reset rx ring index on receive overrun
From: Brandeburg, Jesse @ 2012-05-18 0:04 UTC (permalink / raw)
To: Samuel Thibault
Cc: Jiri Pirko, e1000-devel@lists.sourceforge.net, Dean Nelson,
Allan, Bruce W, linux-kernel@vger.kernel.org, David S. Miller,
Ronciak, John, netdev@vger.kernel.org
In-Reply-To: <20120517233124.GK683@type.famille.thibault.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 736 bytes --]
On Thu, 17 May 2012, Samuel Thibault wrote:
> Samuel Thibault, le Fri 18 May 2012 01:28:21 +0200, a écrit :
> > Dave, Tushar N, le Thu 17 May 2012 23:22:31 +0000, a écrit :
> > > I am interested in to see if you have actual test case and more
> > > importantly test data that shows that kernel and device indexes are
> > > not synchronized any more.
> >
> > Well, it's not with an actual physical device, but with the kvm
> > emulation.
>
> BTW, it also happens easily when request_irq takes some time to
> complete: since we enable E1000_TCTL_EN before that, the card can have
> time to fill the ring before irqs are processed.
I think there may well be a bug in the implementation in kvm. The
hardware doesn't have this bug.
[-- Attachment #2: Type: text/plain, Size: 395 bytes --]
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH v3] xfrm: take iphdr size into account for esp payload size calculation
From: David Miller @ 2012-05-18 0:05 UTC (permalink / raw)
To: bpoirier
Cc: netdev, kuznet, jmorris, yoshfuji, kaber, linux-kernel,
steffen.klassert
In-Reply-To: <1337196925-4919-1-git-send-email-bpoirier@suse.de>
From: Benjamin Poirier <bpoirier@suse.de>
Date: Wed, 16 May 2012 15:35:25 -0400
> Corrects the function that determines the esp payload size.
> The calculations done in esp4_get_mtu lead to overlength frames in transport
> mode for certain mtu values and suboptimal frames for others.
>
> According to what is done, mainly in esp_output(), net_header_len aka
> sizeof(struct iphdr) must be taken into account before doing the alignment
> calculation.
>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
This looks great.
Could you please fix net/ipv6/esp6.c too, it seems to have the same
exact bug.
Once you respin this patch with both ipv4 and ipv6 fixed, I'll apply
it.
Thank you.
^ permalink raw reply
* Re: [PATCH] bonding: only send arp monitor packets if no other traffic
From: David Miller @ 2012-05-18 0:08 UTC (permalink / raw)
To: chris.friesen; +Cc: fubar, netdev
In-Reply-To: <4FB3F67C.6000401@genband.com>
From: Chris Friesen <chris.friesen@genband.com>
Date: Wed, 16 May 2012 12:48:28 -0600
> + if (IS_UP(slave->dev)) {
> + if (time_after_eq(jiffies, dev_trans_start(slave->dev) + delta_in_ticks) ||
> + time_after_eq(jiffies, slave->dev->last_rx + delta_in_ticks)) {
> + bond_arp_send_all(bond, slave);
> + }
These lines are very long, and instead of just reformatting them I'd suggest
that you simply make the test a static helper function.
Also, you should not use braces to enclose a single line of code.
Thanks.
^ permalink raw reply
* Re: [PATCH] e1000: Reset rx ring index on receive overrun
From: Samuel Thibault @ 2012-05-18 0:12 UTC (permalink / raw)
To: Brandeburg, Jesse
Cc: Jiri Pirko, e1000-devel@lists.sourceforge.net, Dean Nelson,
Allan, Bruce W, linux-kernel@vger.kernel.org, David S. Miller,
Ronciak, John, netdev@vger.kernel.org
In-Reply-To: <alpine.WNT.2.00.1205171702590.7900@jbrandeb-mobl2.amr.corp.intel.com>
Brandeburg, Jesse, le Thu 17 May 2012 17:04:04 -0700, a écrit :
> On Thu, 17 May 2012, Samuel Thibault wrote:
>
> > Samuel Thibault, le Fri 18 May 2012 01:28:21 +0200, a écrit :
> > > Dave, Tushar N, le Thu 17 May 2012 23:22:31 +0000, a écrit :
> > > > I am interested in to see if you have actual test case and more
> > > > importantly test data that shows that kernel and device indexes are
> > > > not synchronized any more.
> > >
> > > Well, it's not with an actual physical device, but with the kvm
> > > emulation.
> >
> > BTW, it also happens easily when request_irq takes some time to
> > complete: since we enable E1000_TCTL_EN before that, the card can have
> > time to fill the ring before irqs are processed.
>
> I think there may well be a bug in the implementation in kvm. The
> hardware doesn't have this bug.
How does it avoid filling the ring? What is the purpose of the RXO flag
if it does avoid them?
Samuel
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH] e1000: Reset rx ring index on receive overrun
From: Brandeburg, Jesse @ 2012-05-18 0:26 UTC (permalink / raw)
To: Samuel Thibault
Cc: Jiri Pirko, e1000-devel@lists.sourceforge.net, Dean Nelson,
Allan, Bruce W, linux-kernel@vger.kernel.org, David S. Miller,
Ronciak, John, netdev@vger.kernel.org
In-Reply-To: <20120518001202.GN683@type.famille.thibault.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1195 bytes --]
On Thu, 17 May 2012, Samuel Thibault wrote:
> Brandeburg, Jesse, le Thu 17 May 2012 17:04:04 -0700, a écrit :
> > > BTW, it also happens easily when request_irq takes some time to
> > > complete: since we enable E1000_TCTL_EN before that, the card can have
> > > time to fill the ring before irqs are processed.
> >
> > I think there may well be a bug in the implementation in kvm. The
> > hardware doesn't have this bug.
>
> How does it avoid filling the ring? What is the purpose of the RXO flag
> if it does avoid them?
RXO is only used to let the driver know "information" that the rx fifo is
overflowing. As it turns out the flag isn't very useful and none of our
drivers currently use it for anything.
If the hardware fills all the available receive *descriptors* then the
hardware's RDH (head) register will advance all the way to the RDT (tail)
value. The tail always points one past the rx descriptors available to
hardware to use. RDH==RDT means there are no software provided
descriptors in the ring available to be used by the hardware. Our drivers
typically allow for 1-2 descriptors to be unused in the ring to help avoid
any confusion.
Hope this helps,
Jesse
[-- Attachment #2: Type: text/plain, Size: 395 bytes --]
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* [ANNOUNCE] libnetfilter_conntrack 1.0.1 release
From: Pablo Neira Ayuso @ 2012-05-18 0:35 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, netfilter, netfilter-announce, lwn
[-- Attachment #1: Type: text/plain, Size: 606 bytes --]
Hi!
The Netfilter project proudly presents:
libnetfilter_conntrack 1.0.1
libnetfilter_conntrack is a userspace library providing a programming
interface (API) to the in-kernel connection tracking state table.
This library is currently used by conntrack-tools among many other
applications.
This release includes important improvements for the expectation
support.
See ChangeLog that comes attached to this email for more details.
You can download it from:
http://www.netfilter.org/projects/libnetfilter_conntrack/downloads.html
ftp://ftp.netfilter.org/pub/libnetfilter_conntrack/
Have fun!
[-- Attachment #2: changes-libnetfilter_conntrack-1.0.1.txt --]
[-- Type: text/plain, Size: 908 bytes --]
Kelvie Wong (1):
expect: support NFCT_Q_CREATE_UPDATE in nfexp_query
Pablo Neira Ayuso (15):
expect: add XML support for nfexp_snprintf()
expect: add class support
expect: add NAT support
expect: add expectfn support
expect: CTA_EXPECT_HELP_NAME must be NULL-terminated
expect: fix comparison of expectation class and flags
expect: fix missing whitespace after expectation flags in nfexp_snprintf
conntrack: add support for CTA_MARK_MASK and filtered dumping
qa: add some stress tools to test conntrack via ctnetlink
qa: several improvements for the ct_stress tools
conntrack: fix wrong building of ICMP reply tuple
conntrack: add new ATTR_GRP_[ORIG|REPL]_ADDR_[SRC|DST] attribute
conntrack: fix new ATTR_GRP_[ORIG|REPL]_ADDR_[SRC|DST]
qa: add test case for get/set ATTR_GRP_* API
build: bump version to 1.0.1
^ permalink raw reply
* Re: [PATCH 00/17] Swap-over-NBD without deadlocking V11
From: Eric B Munson @ 2012-05-18 1:11 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Linux-MM, Linux-Netdev, LKML, David Miller,
Neil Brown, Peter Zijlstra, Mike Christie
In-Reply-To: <1337266231-8031-1-git-send-email-mgorman@suse.de>
[-- Attachment #1: Type: text/plain, Size: 775 bytes --]
On Thu, 17 May 2012, Mel Gorman wrote:
> Mostly addressing feedback from David Miller.
>
> Changeloc since V10
> o Rebase to 3.4-rc5
> o Coding style fixups (davem)
> o API consistency (davem)
> o Rename sk_allocation to sk_gfp_atomic and use only when necessary (davem)
> o Use static branches for sk_memalloc_socks (davem)
> o Use static branch checks in fast paths (davem)
> o Document concerns about PF_MEMALLOC leaking flags (davem)
> o Locking fix in slab (mel)
<snip>
I am attempting to test these, but when they are applied on top of mainline
head my laptop hangs about 60-90 seconds after boot. I am trying mainline
without these sets now and will post results.
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/6] net: sh_eth: use NAPI
From: Shimoda, Yoshihiro @ 2012-05-18 1:44 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, SH-Linux
In-Reply-To: <20120517103308.GA15830@electric-eye.fr.zoreil.com>
2012/05/17 19:33, Francois Romieu wrote:
> Shimoda, Yoshihiro <yoshihiro.shimoda.uh@renesas.com> :
> [...]
>> diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
>> index c64a31c..edc7dfe 100644
>> --- a/drivers/net/ethernet/renesas/sh_eth.c
>> +++ b/drivers/net/ethernet/renesas/sh_eth.c
> [...]
< snip >
>> @@ -1678,19 +1710,15 @@ static int sh_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
>> struct sh_eth_private *mdp = netdev_priv(ndev);
>> struct sh_eth_txdesc *txdesc;
>> u32 entry;
>> - unsigned long flags;
>>
>> - spin_lock_irqsave(&mdp->lock, flags);
>> if ((mdp->cur_tx - mdp->dirty_tx) >= (mdp->num_tx_ring - 4)) {
>> if (!sh_eth_txfree(ndev)) {
>
> There are now two racing sh_eth_txfree and there is no [PATCH v4 7/6].
>
> If I may suggest a slightly different approach, I would apply the patch
> below before anything NAPI related:
Thank you very much for the suggestion. I will modify the NAPI patch to fix
the racing using your suggestion.
(Because the original driver (before NAPI) was already locked by mdp->lock
in sh_eth_interrupt(), I think that the original driver doesn't have the
racing issue.)
Best regards,
Yoshihiro Shimoda
^ permalink raw reply
* Re: [PATCH 00/17] Swap-over-NBD without deadlocking V11
From: Eric B Munson @ 2012-05-18 1:46 UTC (permalink / raw)
To: Mel Gorman
Cc: Andrew Morton, Linux-MM, Linux-Netdev, LKML, David Miller,
Neil Brown, Peter Zijlstra, Mike Christie
In-Reply-To: <1337266231-8031-1-git-send-email-mgorman@suse.de>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On Thu, 17 May 2012, Mel Gorman wrote:
> Mostly addressing feedback from David Miller.
>
> Changeloc since V10
> o Rebase to 3.4-rc5
> o Coding style fixups (davem)
> o API consistency (davem)
> o Rename sk_allocation to sk_gfp_atomic and use only when necessary (davem)
> o Use static branches for sk_memalloc_socks (davem)
> o Use static branch checks in fast paths (davem)
> o Document concerns about PF_MEMALLOC leaking flags (davem)
> o Locking fix in slab (mel)
The hang happens without these sets. Unfortunately because my beagle board is
busy and will be through the weekend, I won't be able to test these sets until
the hang is fixed.
Eric
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH net-next v4] be2net: Fix to allow get/set of debug levels in the firmware.
From: Somnath.Kotur @ 2012-05-18 1:47 UTC (permalink / raw)
To: davem; +Cc: netdev, bhutchings, Suresh.Reddy
In-Reply-To: <20120517.162116.881586126577077171.davem@davemloft.net>
Hi David,
>
> This doesn't apply cleanly to net-next, please respin.
>
OK, need to figure out how did that happen and will respin
> Also, you should convert your driver now to use ->msg_enable to gate all of
> your driver's kernel message logging, not just this firmware stuff.
At the moment our driver does not have any extensive logging facility, but yes
going forward we will use this infrastructure to gate all our driver's logging and will send
separate patch(es) for that in future.
Does that sound good for now? A respin for this current patch
Thanks
Som
^ permalink raw reply
* [PATCH v5 6/6] net: sh_eth: use NAPI
From: Shimoda, Yoshihiro @ 2012-05-18 1:58 UTC (permalink / raw)
To: netdev; +Cc: SH-Linux
This patch modifies the driver to use NAPI.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
---
about v5:
- fix two racing sh_eth_txfree() in sh_eth_start_xmit() and sh_eth_poll()
drivers/net/ethernet/renesas/sh_eth.c | 109 +++++++++++++++++++++------------
drivers/net/ethernet/renesas/sh_eth.h | 3 +
2 files changed, 73 insertions(+), 39 deletions(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.c b/drivers/net/ethernet/renesas/sh_eth.c
index c64a31c..1dc9b6e 100644
--- a/drivers/net/ethernet/renesas/sh_eth.c
+++ b/drivers/net/ethernet/renesas/sh_eth.c
@@ -1035,7 +1035,7 @@ static int sh_eth_txfree(struct net_device *ndev)
}
/* Packet receive function */
-static int sh_eth_rx(struct net_device *ndev)
+static int sh_eth_rx(struct net_device *ndev, int *work, int budget)
{
struct sh_eth_private *mdp = netdev_priv(ndev);
struct sh_eth_rxdesc *rxdesc;
@@ -1047,7 +1047,8 @@ static int sh_eth_rx(struct net_device *ndev)
u32 desc_status;
rxdesc = &mdp->rx_ring[entry];
- while (!(rxdesc->status & cpu_to_edmac(mdp, RD_RACT))) {
+ while (!(rxdesc->status & cpu_to_edmac(mdp, RD_RACT)) &&
+ *work < budget) {
desc_status = edmac_to_cpu(mdp, rxdesc->status);
pkt_len = rxdesc->frame_length;
@@ -1087,13 +1088,17 @@ static int sh_eth_rx(struct net_device *ndev)
skb_reserve(skb, NET_IP_ALIGN);
skb_put(skb, pkt_len);
skb->protocol = eth_type_trans(skb, ndev);
- netif_rx(skb);
- ndev->stats.rx_packets++;
- ndev->stats.rx_bytes += pkt_len;
+ if (netif_receive_skb(skb) == NET_RX_DROP) {
+ ndev->stats.rx_dropped++;
+ } else {
+ ndev->stats.rx_packets++;
+ ndev->stats.rx_bytes += pkt_len;
+ }
}
rxdesc->status |= cpu_to_edmac(mdp, RD_RACT);
entry = (++mdp->cur_rx) % mdp->num_rx_ring;
rxdesc = &mdp->rx_ring[entry];
+ (*work)++;
}
/* Refill the Rx ring buffers. */
@@ -1125,7 +1130,7 @@ static int sh_eth_rx(struct net_device *ndev)
/* Restart Rx engine if stopped. */
/* If we don't need to check status, don't. -KDU */
- if (!(sh_eth_read(ndev, EDRRR) & EDRRR_R)) {
+ if (*work < budget && !(sh_eth_read(ndev, EDRRR) & EDRRR_R)) {
/* fix the values for the next receiving */
mdp->cur_rx = mdp->dirty_rx = (sh_eth_read(ndev, RDFAR) -
sh_eth_read(ndev, RDLAR)) >> 4;
@@ -1281,38 +1286,61 @@ static irqreturn_t sh_eth_interrupt(int irq, void *netdev)
/* Get interrpt stat */
intr_status = sh_eth_read(ndev, EESR);
- /* Clear interrupt */
if (intr_status & (EESR_FRC | EESR_RMAF | EESR_RRF |
EESR_RTLF | EESR_RTSF | EESR_PRE | EESR_CERF |
cd->tx_check | cd->eesr_err_check)) {
- sh_eth_write(ndev, intr_status, EESR);
+ if (napi_schedule_prep(&mdp->napi)) {
+ /* Disable interrupts of the channel */
+ sh_eth_write(ndev, 0, EESIPR);
+ __napi_schedule(&mdp->napi);
+ }
ret = IRQ_HANDLED;
- } else
- goto other_irq;
-
- if (intr_status & (EESR_FRC | /* Frame recv*/
- EESR_RMAF | /* Multi cast address recv*/
- EESR_RRF | /* Bit frame recv */
- EESR_RTLF | /* Long frame recv*/
- EESR_RTSF | /* short frame recv */
- EESR_PRE | /* PHY-LSI recv error */
- EESR_CERF)){ /* recv frame CRC error */
- sh_eth_rx(ndev);
}
- /* Tx Check */
- if (intr_status & cd->tx_check) {
- sh_eth_txfree(ndev);
- netif_wake_queue(ndev);
+ spin_unlock(&mdp->lock);
+
+ return ret;
+}
+
+static int sh_eth_poll(struct napi_struct *napi, int budget)
+{
+ struct sh_eth_private *mdp = container_of(napi, struct sh_eth_private,
+ napi);
+ struct net_device *ndev = mdp->ndev;
+ struct sh_eth_cpu_data *cd = mdp->cd;
+ int work_done = 0, txfree_num;
+ u32 intr_status = sh_eth_read(ndev, EESR);
+
+ /* Clear interrupt flags */
+ sh_eth_write(ndev, intr_status, EESR);
+
+ /* check txdesc */
+ txfree_num = sh_eth_txfree(ndev);
+ if (txfree_num) {
+ netif_tx_lock(ndev);
+ if (netif_queue_stopped(ndev))
+ netif_wake_queue(ndev);
+ netif_tx_unlock(ndev);
}
+ /* check rxdesc */
+ sh_eth_rx(ndev, &work_done, budget);
+
+ /* check error flags */
if (intr_status & cd->eesr_err_check)
sh_eth_error(ndev, intr_status);
-other_irq:
- spin_unlock(&mdp->lock);
+ /* get current interrupt flags */
+ intr_status = sh_eth_read(ndev, EESR);
- return ret;
+ /* check whether this driver should call napi_complete() */
+ if (work_done < budget) {
+ napi_complete(napi);
+ /* Enable all interrupts */
+ sh_eth_write(ndev, cd->eesipr_value, EESIPR);
+ }
+
+ return work_done;
}
/* PHY state control function */
@@ -1545,6 +1573,7 @@ static int sh_eth_set_ringparam(struct net_device *ndev,
/* Stop the chip's Tx and Rx processes. */
sh_eth_write(ndev, 0, EDTRR);
sh_eth_write(ndev, 0, EDRRR);
+ napi_disable(&mdp->napi);
synchronize_irq(ndev->irq);
}
@@ -1569,6 +1598,7 @@ static int sh_eth_set_ringparam(struct net_device *ndev,
}
if (netif_running(ndev)) {
+ napi_enable(&mdp->napi);
sh_eth_write(ndev, mdp->cd->eesipr_value, EESIPR);
/* Setting the Rx mode will start the Rx process. */
sh_eth_write(ndev, EDRRR_R, EDRRR);
@@ -1600,6 +1630,8 @@ static int sh_eth_open(struct net_device *ndev)
pm_runtime_get_sync(&mdp->pdev->dev);
+ napi_enable(&mdp->napi);
+
ret = request_irq(ndev->irq, sh_eth_interrupt,
#if defined(CONFIG_CPU_SUBTYPE_SH7763) || \
defined(CONFIG_CPU_SUBTYPE_SH7764) || \
@@ -1678,19 +1710,6 @@ static int sh_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
struct sh_eth_private *mdp = netdev_priv(ndev);
struct sh_eth_txdesc *txdesc;
u32 entry;
- unsigned long flags;
-
- spin_lock_irqsave(&mdp->lock, flags);
- if ((mdp->cur_tx - mdp->dirty_tx) >= (mdp->num_tx_ring - 4)) {
- if (!sh_eth_txfree(ndev)) {
- if (netif_msg_tx_queued(mdp))
- dev_warn(&ndev->dev, "TxFD exhausted.\n");
- netif_stop_queue(ndev);
- spin_unlock_irqrestore(&mdp->lock, flags);
- return NETDEV_TX_BUSY;
- }
- }
- spin_unlock_irqrestore(&mdp->lock, flags);
entry = mdp->cur_tx % mdp->num_tx_ring;
mdp->tx_skbuff[entry] = skb;
@@ -1716,6 +1735,13 @@ static int sh_eth_start_xmit(struct sk_buff *skb, struct net_device *ndev)
if (!(sh_eth_read(ndev, EDTRR) & sh_eth_get_edtrr_trns(mdp)))
sh_eth_write(ndev, sh_eth_get_edtrr_trns(mdp), EDTRR);
+ if ((mdp->cur_tx - mdp->dirty_tx) >= (mdp->num_tx_ring - 4)) {
+ if (netif_msg_tx_queued(mdp)) {
+ dev_warn(&ndev->dev, "TxFD exhausted.\n");
+ netif_stop_queue(ndev);
+ }
+ }
+
return NETDEV_TX_OK;
}
@@ -1739,6 +1765,8 @@ static int sh_eth_close(struct net_device *ndev)
phy_disconnect(mdp->phydev);
}
+ napi_disable(&mdp->napi);
+
free_irq(ndev->irq, ndev);
/* Free all the skbuffs in the Rx queue. */
@@ -2368,6 +2396,9 @@ static int sh_eth_drv_probe(struct platform_device *pdev)
#endif
sh_eth_set_default_cpu_data(mdp->cd);
+ mdp->ndev = ndev;
+ netif_napi_add(ndev, &mdp->napi, sh_eth_poll, SH_ETH_NAPI_WEIGHT);
+
/* set function */
ndev->netdev_ops = &sh_eth_netdev_ops;
SET_ETHTOOL_OPS(ndev, &sh_eth_ethtool_ops);
diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
index f1dbc27..93dad7b 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -35,6 +35,7 @@
#define PKT_BUF_SZ 1538
#define SH_ETH_TSU_TIMEOUT_MS 500
#define SH_ETH_TSU_CAM_ENTRIES 32
+#define SH_ETH_NAPI_WEIGHT 32
enum {
/* E-DMAC registers */
@@ -728,6 +729,8 @@ struct sh_eth_private {
int duplex;
int port; /* for TSU */
int vlan_num_ids; /* for VLAN tag filter */
+ struct napi_struct napi;
+ struct net_device *ndev;
unsigned no_ether_link:1;
unsigned ether_link_active_low:1;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH net-next v4] be2net: Fix to allow get/set of debug levels in the firmware.
From: David Miller @ 2012-05-18 2:45 UTC (permalink / raw)
To: Somnath.Kotur; +Cc: netdev, bhutchings, Suresh.Reddy
In-Reply-To: <80fb6a42-aa9a-4288-aa96-c6aa5972bc03@exht1.ad.emulex.com>
From: <Somnath.Kotur@Emulex.Com>
Date: Thu, 17 May 2012 18:47:50 -0700
> At the moment our driver does not have any extensive logging
> facility, but yes going forward we will use this infrastructure to
> gate all our driver's logging and will send separate patch(es) for
> that in future.
>
> Does that sound good for now? A respin for this current patch
Yes.
^ permalink raw reply
* [PATCH net-next] ip_frag: struct inet_frags match() method returns a bool
From: Eric Dumazet @ 2012-05-18 3:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
- match() method returns a boolean
- return (A && B && C && D) -> return A && B && C && D
- fix indentation
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/inet_frag.h | 3 +--
include/net/ipv6.h | 2 +-
net/ipv4/ip_fragment.c | 10 +++++-----
net/ipv6/reassembly.c | 9 +++++----
4 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index 16ff29a..2431cf8 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -46,8 +46,7 @@ struct inet_frags {
void *arg);
void (*destructor)(struct inet_frag_queue *);
void (*skb_free)(struct sk_buff *);
- int (*match)(struct inet_frag_queue *q,
- void *arg);
+ bool (*match)(struct inet_frag_queue *q, void *arg);
void (*frag_expire)(unsigned long data);
};
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 4332e9a..5f65e7c 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -387,7 +387,7 @@ struct ip6_create_arg {
};
void ip6_frag_init(struct inet_frag_queue *q, void *a);
-int ip6_frag_match(struct inet_frag_queue *q, void *a);
+bool ip6_frag_match(struct inet_frag_queue *q, void *a);
static inline int ipv6_addr_any(const struct in6_addr *a)
{
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 9f9bd13..695b27f 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -148,17 +148,17 @@ static unsigned int ip4_hashfn(struct inet_frag_queue *q)
return ipqhashfn(ipq->id, ipq->saddr, ipq->daddr, ipq->protocol);
}
-static int ip4_frag_match(struct inet_frag_queue *q, void *a)
+static bool ip4_frag_match(struct inet_frag_queue *q, void *a)
{
struct ipq *qp;
struct ip4_create_arg *arg = a;
qp = container_of(q, struct ipq, q);
return qp->id == arg->iph->id &&
- qp->saddr == arg->iph->saddr &&
- qp->daddr == arg->iph->daddr &&
- qp->protocol == arg->iph->protocol &&
- qp->user == arg->user;
+ qp->saddr == arg->iph->saddr &&
+ qp->daddr == arg->iph->daddr &&
+ qp->protocol == arg->iph->protocol &&
+ qp->user == arg->user;
}
/* Memory Tracking Functions. */
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index f1b86fd..5d32dfa 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -134,15 +134,16 @@ static unsigned int ip6_hashfn(struct inet_frag_queue *q)
return inet6_hash_frag(fq->id, &fq->saddr, &fq->daddr, ip6_frags.rnd);
}
-int ip6_frag_match(struct inet_frag_queue *q, void *a)
+bool ip6_frag_match(struct inet_frag_queue *q, void *a)
{
struct frag_queue *fq;
struct ip6_create_arg *arg = a;
fq = container_of(q, struct frag_queue, q);
- return (fq->id == arg->id && fq->user == arg->user &&
- ipv6_addr_equal(&fq->saddr, arg->src) &&
- ipv6_addr_equal(&fq->daddr, arg->dst));
+ return fq->id == arg->id &&
+ fq->user == arg->user &&
+ ipv6_addr_equal(&fq->saddr, arg->src) &&
+ ipv6_addr_equal(&fq->daddr, arg->dst);
}
EXPORT_SYMBOL(ip6_frag_match);
^ 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