Changli Gao | 1 Jun 02:28 2010
Picon

Re: DDoS attack causing bad effect on conntrack searches

On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
>
> I had a look at current conntrack and found the 'unconfirmed' list was
> maybe a candidate for a potential blackhole.
>
> That is, if a reader happens to hit an entry that is moved from regular
> hash table slot 'hash' to unconfirmed list,

Sorry, but I can't find where we do this things. unconfirmed list is
used to track the unconfirmed cts, whose corresponding skbs are still
in path from the first to the last netfilter hooks. As soon as the
skbs end their travel in netfilter, the corresponding cts will be
confirmed(moving ct from unconfirmed list to regular hash table).

unconfirmed list should be small, as networking receiving is in BH.
How about implementing unconfirmed list as a per cpu variable?

> reader might scan whole
> unconfirmed list to find out he is not anymore on the wanted hash chain.
>
> Problem is this unconfirmed list might be very very long in case of
> DDOS. It's really not designed to be scanned during a lookup.
>
> So I guess we should stop early if we find an unconfirmed entry ?
>
>
>
> diff --git a/include/net/netfilter/nf_conntrack.h b/include/net/netfilter/nf_conntrack.h
> index bde095f..0573641 100644
> --- a/include/net/netfilter/nf_conntrack.h
(Continue reading)

Grant Grundler | 1 Jun 03:00 2010

Re: [PATCH 1/2] tulip: explicity set to D0 power state during init

On Mon, May 31, 2010 at 06:34:42PM -0400, Steven Walter wrote:
> During the first suspend the chip would refuse to enter D3.  Subsequent
> suspends worked okay.  During resume the chip is commanded into D0.
> Doing so during initialization fixes the initial suspend.
> 
> Signed-off-by: Steven Walter <stevenrwalter <at> gmail.com>

Signed-off-by: Grant Grundler <grundler <at> parisc-linux.org>

> ---
>  drivers/net/tulip/tulip_core.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
> index 3810db9..bb8c0ee 100644
> --- a/drivers/net/tulip/tulip_core.c
> +++ b/drivers/net/tulip/tulip_core.c
>  <at>  <at>  -1380,6 +1380,13  <at>  <at>  static int __devinit tulip_init_one (struct pci_dev *pdev,
>  		return i;
>  	}
>  
> +	/* The chip will fail to enter a low-power state later unless
> +	 * first explicitly commanded into D0 */
> +	if (pci_set_power_state(pdev, PCI_D0)) {
> +		printk (KERN_ERR PFX

My only quibble is this message really isn't "KERN_ERR" worthy.
Can you explain why you think this should be ERR and not say, KERN_NOTICE?

(I'm looking at the definitions in include/linux/kernel.h of 2.6 source tree.)
(Continue reading)

Ben Hutchings | 1 Jun 03:45 2010
Picon

Re: Bug#583935: linux-image-2.6.32-5-amd64: kernel trace in net/ipv4/tcp_input.c:2540 tcp_ack

On Mon, 2010-05-31 at 23:25 +0530, Ritesh Raj Sarraf wrote:
> Package: linux-2.6
> Version: 2.6.32-14
> Severity: normal
> Tags: squeeze
> 
> I haven't noticed a stability issue as such but saw this kernel trace
> logged into dmesg.

I'm forwarding this to the 'netdev' list to see if the upstream
developers can debug it.

Debian kernel version 2.6.32-14 is closely based on stable kernel
2.6.32.14.

Ben.

> -- Package-specific info:
> ** Version:
> Linux version 2.6.32-5-amd64 (Debian 2.6.32-14) (ben <at> decadent.org.uk) (gcc version 4.3.5 (Debian
4.3.5-1) ) #1 SMP Sun May 30 17:20:42 UTC 2010
> 
> ** Command line:
> BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/LocalDisk-ROOT ro quiet security=tomoyo splash
> 
> ** Tainted: W (512)
>  * Taint on warning.
> 
> ** Kernel log:
> [   28.406886] iwlagn 0000:03:00.0: firmware: requesting iwlwifi-5000-2.ucode
(Continue reading)

Steven Walter | 1 Jun 05:11 2010
Picon

[PATCH 1/2] tulip: explicity set to D0 power state during init

During the first suspend the chip would refuse to enter D3.  Subsequent
suspends worked okay.  During resume the chip is commanded into D0.
Doing so during initialization fixes the initial suspend.

Signed-off-by: Steven Walter <stevenrwalter <at> gmail.com>
Signed-off-by: Grant Grundler <grundler <at> parisc-linux.org>
---
 drivers/net/tulip/tulip_core.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c
index 3810db9..ec013c2 100644
--- a/drivers/net/tulip/tulip_core.c
+++ b/drivers/net/tulip/tulip_core.c
 <at>  <at>  -1380,6 +1380,13  <at>  <at>  static int __devinit tulip_init_one (struct pci_dev *pdev,
 		return i;
 	}

+	/* The chip will fail to enter a low-power state later unless
+	 * first explicitly commanded into D0 */
+	if (pci_set_power_state(pdev, PCI_D0)) {
+		printk (KERN_NOTICE PFX
+			"Failed to set power state to D0\n");
+	}
+
 	irq = pdev->irq;

 	/* alloc_etherdev ensures aligned and zeroed private structures */
--

-- 
1.6.3.3
(Continue reading)

Joe Perches | 1 Jun 05:23 2010

[PATCH 20/21] net/ipv6/mcast.c: Remove unnecessary kmalloc casts

Signed-off-by: Joe Perches <joe <at> perches.com>
---
 net/ipv6/mcast.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
index 59f1881..7b5fb43 100644
--- a/net/ipv6/mcast.c
+++ b/net/ipv6/mcast.c
 <at>  <at>  -1995,8 +1995,7  <at>  <at>  static int sf_setstate(struct ifmcaddr6 *pmc)
 				    &psf->sf_addr))
 					break;
 			if (!dpsf) {
-				dpsf = (struct ip6_sf_list *)
-					kmalloc(sizeof(*dpsf), GFP_ATOMIC);
+				dpsf = kmalloc(sizeof(*dpsf), GFP_ATOMIC);
 				if (!dpsf)
 					continue;
 				*dpsf = *psf;
--

-- 
1.7.0.3.311.g6a6955

Joe Perches | 1 Jun 05:23 2010

[PATCH 19/21] net/ipv4/igmp.c: Remove unnecessary kmalloc casts

Signed-off-by: Joe Perches <joe <at> perches.com>
---
 net/ipv4/igmp.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index 5fff865..250cb5e 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
 <at>  <at>  -1646,8 +1646,7  <at>  <at>  static int sf_setstate(struct ip_mc_list *pmc)
 				if (dpsf->sf_inaddr == psf->sf_inaddr)
 					break;
 			if (!dpsf) {
-				dpsf = (struct ip_sf_list *)
-					kmalloc(sizeof(*dpsf), GFP_ATOMIC);
+				dpsf = kmalloc(sizeof(*dpsf), GFP_ATOMIC);
 				if (!dpsf)
 					continue;
 				*dpsf = *psf;
--

-- 
1.7.0.3.311.g6a6955

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Joe Perches | 1 Jun 05:23 2010

[PATCH 10/21] drivers/net/gianfar.c: Remove unnecessary kmalloc casts

Signed-off-by: Joe Perches <joe <at> perches.com>
---
 drivers/net/gianfar.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/gianfar.c b/drivers/net/gianfar.c
index 1830f31..ab54821 100644
--- a/drivers/net/gianfar.c
+++ b/drivers/net/gianfar.c
 <at>  <at>  -681,8 +681,8  <at>  <at>  static int gfar_of_init(struct of_device *ofdev, struct net_device **pdev)
 		priv->rx_queue[i] = NULL;

 	for (i = 0; i < priv->num_tx_queues; i++) {
-		priv->tx_queue[i] =  (struct gfar_priv_tx_q *)kzalloc(
-				sizeof (struct gfar_priv_tx_q), GFP_KERNEL);
+		priv->tx_queue[i] = kzalloc(sizeof(struct gfar_priv_tx_q),
+					    GFP_KERNEL);
 		if (!priv->tx_queue[i]) {
 			err = -ENOMEM;
 			goto tx_alloc_failed;
 <at>  <at>  -694,8 +694,8  <at>  <at>  static int gfar_of_init(struct of_device *ofdev, struct net_device **pdev)
 	}

 	for (i = 0; i < priv->num_rx_queues; i++) {
-		priv->rx_queue[i] = (struct gfar_priv_rx_q *)kzalloc(
-					sizeof (struct gfar_priv_rx_q), GFP_KERNEL);
+		priv->rx_queue[i] = kzalloc(sizeof(struct gfar_priv_rx_q),
+					    GFP_KERNEL);
 		if (!priv->rx_queue[i]) {
 			err = -ENOMEM;
(Continue reading)

Joe Perches | 1 Jun 05:23 2010

[PATCH 11/21] drivers/net/tulip/eeprom.c: Remove unnecessary kmalloc casts

Signed-off-by: Joe Perches <joe <at> perches.com>
---
 drivers/net/tulip/eeprom.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/tulip/eeprom.c b/drivers/net/tulip/eeprom.c
index 6002e65..3031ed9 100644
--- a/drivers/net/tulip/eeprom.c
+++ b/drivers/net/tulip/eeprom.c
 <at>  <at>  -120,8 +120,8  <at>  <at>  static void __devinit tulip_build_fake_mediatable(struct tulip_private *tp)
 			  0x00, 0x06  /* ttm bit map */
 			};

-		tp->mtable = (struct mediatable *)
-			kmalloc(sizeof(struct mediatable) + sizeof(struct medialeaf), GFP_KERNEL);
+		tp->mtable = kmalloc(sizeof(struct mediatable) +
+				     sizeof(struct medialeaf), GFP_KERNEL);

 		if (tp->mtable == NULL)
 			return; /* Horrible, impossible failure. */
 <at>  <at>  -227,9 +227,9  <at>  <at>  subsequent_board:
 		        return;
 		}

-		mtable = (struct mediatable *)
-			kmalloc(sizeof(struct mediatable) + count*sizeof(struct medialeaf),
-					GFP_KERNEL);
+		mtable = kmalloc(sizeof(struct mediatable) +
+				 count * sizeof(struct medialeaf),
+				 GFP_KERNEL);
(Continue reading)

Eric Dumazet | 1 Jun 07:05 2010
Picon

Re: DDoS attack causing bad effect on conntrack searches

Le mardi 01 juin 2010 à 08:28 +0800, Changli Gao a écrit :
> On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
> >
> > I had a look at current conntrack and found the 'unconfirmed' list was
> > maybe a candidate for a potential blackhole.
> >
> > That is, if a reader happens to hit an entry that is moved from regular
> > hash table slot 'hash' to unconfirmed list,
> 
> Sorry, but I can't find where we do this things. unconfirmed list is
> used to track the unconfirmed cts, whose corresponding skbs are still
> in path from the first to the last netfilter hooks. As soon as the
> skbs end their travel in netfilter, the corresponding cts will be
> confirmed(moving ct from unconfirmed list to regular hash table).
> 

So netfilter is a monolithic thing.

When a packet begins its travel into netfilter, you guarantee that no
other packet can also begin its travel and find an unconfirmed
conntrack ?

I wonder why we use atomic ops then to track the confirmed bit :)

> unconfirmed list should be small, as networking receiving is in BH.

So according to you, netfilter/ct runs only in input path ?

So I assume a packet is handled by CPU X, creates a new conntrack
(possibly early droping an old entry that was previously in a standard
(Continue reading)

Changli Gao | 1 Jun 07:48 2010
Picon

Re: DDoS attack causing bad effect on conntrack searches

On Tue, Jun 1, 2010 at 1:05 PM, Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
> Le mardi 01 juin 2010 à 08:28 +0800, Changli Gao a écrit :
>> On Tue, Jun 1, 2010 at 5:21 AM, Eric Dumazet <eric.dumazet <at> gmail.com> wrote:
>> >
>> > I had a look at current conntrack and found the 'unconfirmed' list was
>> > maybe a candidate for a potential blackhole.
>> >
>> > That is, if a reader happens to hit an entry that is moved from regular
>> > hash table slot 'hash' to unconfirmed list,
>>
>> Sorry, but I can't find where we do this things. unconfirmed list is
>> used to track the unconfirmed cts, whose corresponding skbs are still
>> in path from the first to the last netfilter hooks. As soon as the
>> skbs end their travel in netfilter, the corresponding cts will be
>> confirmed(moving ct from unconfirmed list to regular hash table).
>>
>
> So netfilter is a monolithic thing.
>
> When a packet begins its travel into netfilter, you guarantee that no
> other packet can also begin its travel and find an unconfirmed
> conntrack ?
>
> I wonder why we use atomic ops then to track the confirmed bit :)

seems no need.

>
>
>> unconfirmed list should be small, as networking receiving is in BH.
(Continue reading)


Gmane