* Re: [PATCH] net: drop NETIF_F_GSO from hw_features without NETIF_F_SG
From: Roger Luethi @ 2011-03-20 18:56 UTC (permalink / raw)
To: Micha? Miros?aw; +Cc: netdev
In-Reply-To: <AANLkTinCdaEs=G=AC45ePA-J99Vik9fYE+ZyF1miCiVy@mail.gmail.com>
On Sat, 19 Mar 2011 17:18:17 +0100, Micha? Miros?aw wrote:
> > However, I still think the current, unpatched behavior is confusing users.
> > ethtool_get_features() will happily tell the user that GSO is available for
> > a NIC even if it is not (because the NIC does not support SG). Then, if the
> > user tries to enable GSO, the operation fails silently: ethtool won't get
> > an error code, so it looks as if the operation succeeded. The user needs to
> > look into the kernel log or actually verify the offload settings to realize
> > that something went wrong.
>
> Do you want to prepare a patch for this? Please remember about
> compatibility with per-offload ethtool ops if you do - this needs to
> be there until all drivers are converted to hw_features.
Something like this?
diff --git a/net/core/dev.c b/net/core/dev.c
index 0b88eba..5861a59 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5442,6 +5442,9 @@ int register_netdevice(struct net_device *dev)
if (!(dev->wanted_features & NETIF_F_SG)) {
dev->wanted_features &= ~NETIF_F_GSO;
dev->features &= ~NETIF_F_GSO;
+ if (!(dev->hw_features & NETIF_F_SG) &&
+ (!dev->ethtool_ops || !dev->ethtool_ops->set_sg))
+ dev->hw_features &= ~NETIF_F_GSO;
}
/* Enable GRO and NETIF_F_HIGHDMA for vlans by default,
^ permalink raw reply related
* Re: [PATCH 2/2] netfilter: get rid of atomic ops in fast path
From: Eric Dumazet @ 2011-03-20 19:06 UTC (permalink / raw)
To: Patrick McHardy
Cc: David Miller, Netfilter Development Mailinglist, netdev,
Jan Engelhardt
In-Reply-To: <4D86121C.7050503@trash.net>
Le dimanche 20 mars 2011 à 15:41 +0100, Patrick McHardy a écrit :
> Am 18.03.2011 18:07, schrieb Eric Dumazet:
> > We currently use a percpu spinlock to 'protect' rule bytes/packets
> > counters, after various attempts to use RCU instead.
> >
> > Lately we added a seqlock so that get_counters() can run without
> > blocking BH or 'writers'. But we really use the seqcount in it.
> >
> > Spinlock itself is only locked by the current/owner cpu, so we can
> > remove it completely.
> >
> > This cleanups api, using correct 'writer' vs 'reader' semantic.
> >
> > At replace time, the get_counters() call makes sure all cpus are done
> > using the old table.
>
> I think this will have to wait until net-next opens up again since
> its not a bugfix.
Sure :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* oops / kernel panic in bonding.
From: Nicolas de Pesloüan @ 2011-03-20 20:17 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jay Vosburgh, Andy Gospodarek, netdev@vger.kernel.org
Hi Jiri,
I suspect we have a race condition somewhere in the new bond_handle_frame function:
The following commands produce one of the following errors:
modprobe bonding max_bonds=0
echo +bond0>/sys/class/net/bonding_masters
echo +bond1>/sys/class/net/bonding_masters
echo +eth1>/sys/class/net/bond1/bonding/slaves
This is mostly reproducible, under VirtualBox.
All tests done with 08351fc6a75731226e1112fc7254542bd3a2912e at the top commit (current net-next-2.6).
Nicolas.
First try:
[ 42.478455] BUG: unable to handle kernel NULL pointer dereference at 0000000000000280
[ 42.480035] IP: [<ffffffffa040c9b0>] bond_handle_frame+0x1f/0x138 [bonding]
[ 42.480035] PGD 0
[ 42.480035] Oops: 0000 [#1] SMP
[ 42.480035] last sysfs file: /sys/devices/virtual/net/bond1/bonding/slaves
[ 42.480035] CPU 0
[ 42.480035] Modules linked in: bonding loop snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm
snd_timer tpm_tis tpm snd psmouse tpm_bios parport_pc processor evdev pcspkr parport battery
i2c_piix4 serio_raw ac i2c_core button thermal_sys soundcore snd_page_alloc ext3 jbd mbcache
ide_gd_mod ide_cd_mod cdrom ata_generic ata_piix libata scsi_mod ohci_hcd piix ide_core floppy
ehci_hcd usbcore e1000 nls_base [last unloaded: scsi_wait_scan]
[ 42.480035]
[ 42.480035] Pid: 206, comm: udevd Not tainted 2.6.38+ #5 innotek GmbH VirtualBox
[ 42.480035] RIP: 0010:[<ffffffffa040c9b0>] [<ffffffffa040c9b0>] bond_handle_frame+0x1f/0x138
[bonding]
[ 42.480035] RSP: 0018:ffff88003fc03c20 EFLAGS: 00010282
[ 42.480035] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88002ecb0608
[ 42.480035] RDX: ffff880023392600 RSI: ffff880023392600 RDI: ffff880023392600
[ 42.480035] RBP: ffffffffa040c991 R08: ffff880023392600 R09: 00000000ffffffff
[ 42.480035] R10: ffff88002322c740 R11: dead000000200200 R12: ffff88002ec0ea00
[ 42.480035] R13: ffff88003fc03c58 R14: 0000000000000000 R15: 0000000000000001
[ 42.480035] FS: 00007fbab75c57a0(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 42.480035] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 42.480035] CR2: 0000000000000280 CR3: 000000003defd000 CR4: 00000000000006f0
[ 42.480035] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 42.480035] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 42.480035] Process udevd (pid: 206, threadinfo ffff880030066000, task ffff8800231c5040)
[ 42.480035] Stack:
[ 42.480035] 00000000ffffffff 0000000000000000 ffffffffa040c991 ffff88002322c000
[ 42.480035] ffff88003fc03c68 ffffffff81267192 0000000000000000 ffff880023392600
[ 42.480035] 0000000000000080
[ 42.524186] bonding: bond1: enslaving eth1 as an active interface with an up link.
Another try:
[ 308.145200] BUG: unable to handle kernel NULL pointer dereference at 0000000000000280
[ 308.146140] IP: [<ffffffffa042c9b0>] bond_handle_frame+0x1f/0x138 [bonding]
[ 308.146993] PGD 0
[ 308.147249] Oops: 0000 [#1] SMP
[ 308.147669] last sysfs file: /sys/devices/virtual/net/bond0/uevent
[ 308.148024] CPU 0
[ 308.148024] Modules linked in: bonding loop snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm
snd_timer psmouse tpm_tis snd tpm tpm_bios serio_raw parport_pc i2c_piix4 pcspkr soundcore processor
evdev snd_page_alloc i2c_core parport battery ac button thermal_sys ext3 jbd mbcache ide_cd_mod
ide_gd_mod cdrom ata_generic ata_piix libata scsi_mod ohci_hcd piix ide_core ehci_hcd usbcore floppy
e1000 nls_base [last unloaded: bonding]
[ 308.148024]
[ 308.148024] Pid: 1291, comm: udevd Not tainted 2.6.38+ #5 innotek GmbH VirtualBox
[ 308.165445] RIP: 0010:[<ffffffffa042c9b0>] [<ffffffffa042c9b0>] bond_handle_frame+0x1f/0x138
[bonding]
[ 308.165445] RSP: 0000:ffff88003fc03c20 EFLAGS: 00010282
[ 308.165445] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000148
[ 308.165445] RDX: ffff880023246000 RSI: ffff880023246000 RDI: ffff880023246000
[ 308.165445] RBP: ffffffffa042c991 R08: ffff880023246000 R09: 0000000000000000
[ 308.165445] R10: ffff88002ee2e740 R11: ffffffff81051a61 R12: ffff880039e50800
[ 308.165445] R13: ffff88003fc03c58 R14: 0000000000000000 R15: 0000000000000001
[ 308.165445] FS: 00007f1f30e837a0(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 308.165445] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 308.165445] CR2: 0000000000000280 CR3: 000000002e582000 CR4: 00000000000006f0
[ 308.165445] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 308.165445] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 308.165445] Process udevd (pid: 1291, threadinfo ffff88002eea0000, task ffff88002f808d60)
[ 308.165445] Stack:
[ 308.165445] ffff88002f80eb00 0000000000000000 ffffffffa042c991 ffff88002ee2e000
[ 308.165445] ffff88003fc03c68 ffffffff81267192 ffffffff810345f4 ffff880023246000
[ 308.165445] 0000000000000000 ffffffff81679c20 ffff880023246000 ffff880023246000
[ 308.165445] Call Trace:
[ 308.165445] <IRQ>
[ 308.165445] [<ffffffffa042c991>] ? bond_handle_frame+0x0/0x138 [bonding]
[ 308.165445] [<ffffffff81267192>] ? __netif_receive_skb+0x2f9/0x4c5
[ 308.165445] [<ffffffff810345f4>] ? __wake_up_common+0x41/0x78
[ 308.165445] [<ffffffff81267656>] ? netif_receive_skb+0x67/0x6d
[ 308.165445] [<ffffffff81267b5d>] ? napi_gro_receive+0x1f/0x2d
[ 308.165445] [<ffffffff8126772b>] ? napi_skb_finish+0x1c/0x31
[ 308.165445] [<ffffffffa000b25c>] ? e1000_clean_rx_irq+0x2fd/0x3b0 [e1000]
[ 308.165445] [<ffffffffa000ab46>] ? e1000_clean+0x30f/0x490 [e1000]
[ 308.165445] [<ffffffff81020bf6>] ? ack_apic_level+0x6e/0x134
[ 308.165445] [<ffffffff81091a7f>] ? handle_fasteoi_irq+0x9c/0xb4
[ 308.165445] [<ffffffff8104aa01>] ? irq_exit+0x6e/0xa0
[ 308.165445] [<ffffffff81267c8a>] ? net_rx_action+0xa8/0x206
[ 308.165445] [<ffffffff8104abf3>] ? __do_softirq+0xc3/0x19e
[ 308.165445] [<ffffffff8108f6d0>] ? handle_irq_event_percpu+0x171/0x18f
[ 308.165445] [<ffffffff8104ac6b>] ? __do_softirq+0x13b/0x19e
[ 308.165445] [<ffffffff81323edc>] ? call_softirq+0x1c/0x30
[ 308.165445] [<ffffffff8100aa53>] ? do_softirq+0x3f/0x79
[ 308.165445] [<ffffffff8104a9d2>] ? irq_exit+0x3f/0xa0
[ 308.165445] [<ffffffff8100a39f>] ? do_IRQ+0x94/0xaa
[ 308.165445] [<ffffffff8131cbd3>] ? ret_from_intr+0x0/0x15
[ 308.165445] <EOI>
[ 308.165445] [<ffffffff810da903>] ? ptep_clear_flush+0x17/0x34
[ 308.165445] [<ffffffff810cb8ba>] ? copy_user_highpage+0x27/0x40
[ 308.165445] [<ffffffff810cf45c>] ? do_wp_page+0x5c1/0x689
[ 308.165445] [<ffffffff810d0155>] ? handle_pte_fault+0x8a5/0x8f2
[ 308.165445] [<ffffffff810d02c4>] ? handle_mm_fault+0x122/0x18b
[ 308.165445] [<ffffffff8131f9b7>] ? do_page_fault+0x32a/0x34c
[ 308.165445] [<ffffffff8131ce95>] ? page_fault+0x25/0x30
[ 308.165445] [<ffffffff81199b0d>] ? __put_user_4+0x1d/0x30
[ 308.165445] [<ffffffff8131ce95>] ? page_fault+0x25/0x30
[ 308.165445] Code: e8 ed fc e2 e0 5a 48 89 d8 5b 5d c3 41 55 49 89 fd 41 54 55 53 48 83 ec 08 48
8b 3f 48 8b 47 20 4c 8b a0 f0 02 00 00 49 8b 04 24
[ 308.165445] 8b a8 80 02 00 00 b8 03 00 00 00 48 85 ed 0f 84 fc 00 00 00
[ 308.165445] RIP [<ffffffffa042c9b0>] bond_handle_frame+0x1f/0x138 [bonding]
[ 308.165445] RSP <ffff88003fc03c20>
[ 308.165445] CR2: 0000000000000280
[ 308.246179] ---[ end trace 31773bac6ab820b4 ]---
[ 308.246897] Kernel panic - not syncing: Fatal exception in interrupt
[ 308.248076] Pid: 1291, comm: udevd Tainted: G D 2.6.38+ #5
[ 308.249089] Call Trace:
[ 308.249496] <IRQ> [<ffffffff8131abe8>] ? panic+0x92/0x197
[ 308.250396] [<ffffffff810457a5>] ? kmsg_dump+0x41/0xe3
[ 308.251211] [<ffffffff8131d9a6>] ? oops_end+0xa9/0xb6
[ 308.252077] [<ffffffff8102c9ff>] ? no_context+0x1f4/0x201
[ 308.252967] [<ffffffffa000a7ed>] ? e1000_xmit_frame+0xa5b/0xaa5 [e1000]
[ 308.254014] [<ffffffff8131f83c>] ? do_page_fault+0x1af/0x34c
[ 308.254915] [<ffffffff81264479>] ? dev_hard_start_xmit+0x3de/0x53c
[ 308.256937] [<ffffffffa042c991>] ? bond_handle_frame+0x0/0x138 [bonding]
[ 308.258683] [<ffffffff8131ce95>] ? page_fault+0x25/0x30
[ 308.260431] [<ffffffffa042c991>] ? bond_handle_frame+0x0/0x138 [bonding]
[ 308.262420] [<ffffffff81051a61>] ? __mod_timer+0x145/0x157
[ 308.264009] [<ffffffffa042c9b0>] ? bond_handle_frame+0x1f/0x138 [bonding]
[ 308.265944] [<ffffffffa042c991>] ? bond_handle_frame+0x0/0x138 [bonding]
[ 308.267404] bonding: bond1: enslaving eth1 as an active interface with an up link.
[ 308.269896] [<ffffffff81267192>] ? __netif_receive_skb+0x2f9/0x4c5
[ 308.271792] [<ffffffff810345f4>] ? __wake_up_common+0x41/0x78
[ 308.271795] [<ffffffff81267656>] ? netif_receive_skb+0x67/0x6d
[ 308.271797] [<ffffffff81267b5d>] ? napi_gro_receive+0x1f/0x2d
[ 308.271799] [<ffffffff8126772b>] ? napi_skb_finish+0x1c/0x31
[ 308.271811] [<ffffffffa000b25c>] ? e1000_clean_rx_irq+0x2fd/0x3b0 [e1000]
[ 308.271815] [<ffffffffa000ab46>] ? e1000_clean+0x30f/0x490 [e1000]
[ 308.271819] [<ffffffff81020bf6>] ? ack_apic_level+0x6e/0x134
[ 308.271822] [<ffffffff81091a7f>] ? handle_fasteoi_irq+0x9c/0xb4
^ permalink raw reply
* Re: [PATCH 0/4] netfilter: netfilter fixes
From: David Miller @ 2011-03-20 20:42 UTC (permalink / raw)
To: kaber; +Cc: netfilter-devel, netdev
In-Reply-To: <1300635148-22648-1-git-send-email-kaber@trash.net>
From: kaber@trash.net
Date: Sun, 20 Mar 2011 16:32:24 +0100
> the following patches fix a couple of netfilter bugs:
>
> - a bug in ipset which caused the hash:port set types to silently
> ignore address ranges when non-TCP/UDP entries were added, from
> Jozsef
>
> - a missing check for set type revision in ipset, from Jozsef
>
> - a fix for iptables reentrancy, from Eric
>
> - a fix for a buffer overflow in the ipt_CLUSTERIP proc handler,
> from Vasiliy Kulikov
>
> Please apply or pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
Pulled, thanks a lot Patrick.
^ permalink raw reply
* Re: [net-next 0/5] bnx2x enhancements and date update
From: David Miller @ 2011-03-20 20:47 UTC (permalink / raw)
To: dmitry; +Cc: netdev, eilong, vladz
In-Reply-To: <1300638963.17303.29.camel@lb-tlvb-dmitry>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Sun, 20 Mar 2011 18:36:03 +0200
> Please consider applying following patch series to the "net-next".
Please consider paying attention to announcements I make about
what is appropriate to submit at this point in time:
http://marc.info/?l=linux-netdev&m=130023005214910&w=2
By the time I open up the net-next-2.6 tree and am actually willing to
apply patches, something you submit now might not even apply cleanly.
That's why I don't want people submitting net-next-2.6 patches at this
time.
It also is distracting to submit such patches at this time. All
efforts should be placed on regression fixing and closing out the
merge window cleanly.
^ permalink raw reply
* Re: oops / kernel panic in bonding.
From: Nicolas de Pesloüan @ 2011-03-20 21:19 UTC (permalink / raw)
To: Jiri Pirko; +Cc: Jay Vosburgh, Andy Gospodarek, netdev@vger.kernel.org
In-Reply-To: <4D8660EC.6080102@gmail.com>
Le 20/03/2011 21:17, Nicolas de Pesloüan a écrit :
> Hi Jiri,
>
> I suspect we have a race condition somewhere in the new
> bond_handle_frame function:
>
> The following commands produce one of the following errors:
>
> modprobe bonding max_bonds=0
> echo +bond0>/sys/class/net/bonding_masters
> echo +bond1>/sys/class/net/bonding_masters
> echo +eth1>/sys/class/net/bond1/bonding/slaves
>
> This is mostly reproducible, under VirtualBox.
>
> All tests done with 08351fc6a75731226e1112fc7254542bd3a2912e at the top
> commit (current net-next-2.6).
I suspect netdev_rx_handler_register is called too early in bond_enslave.
I think it should be the last thing we do in bond_enslave, if we don't want to face the risk to have
bond_handle_frame being called before everything is properly setup.
Nicolas.
^ permalink raw reply
* RE: [net-next 0/5] bnx2x enhancements and date update
From: Dmitry Kravkov @ 2011-03-20 21:25 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, Eilon Greenstein, Vladislav Zolotarov
In-Reply-To: <20110320.134750.104058019.davem@davemloft.net>
> From: netdev-owner@vger.kernel.org [mailto:netdev-
> owner@vger.kernel.org] On Behalf Of David Miller
> Sent: Sunday, March 20, 2011 10:48 PM
>
> From: "Dmitry Kravkov" <dmitry@broadcom.com>
> Date: Sun, 20 Mar 2011 18:36:03 +0200
>
> > Please consider applying following patch series to the "net-next".
>
> Please consider paying attention to announcements I make about
> what is appropriate to submit at this point in time:
Oops, my bad! I will re-submit them when you re-open the window.
Please ignore them totally for now. Thanks.
^ permalink raw reply
* [PATCH 1/1] solos-pci: Use shared code for VCC management
From: Philip Prindeville @ 2011-03-20 22:30 UTC (permalink / raw)
To: Netdev; +Cc: linux-atm-general@lists.sourceforge.net
The solos-pci driver duplicates the net/atm/common.c function atm_dev_release_vccs() locally as the static function release_vccs(). Let's have the driver share code.
Signed-off-by: Philip A. Prindeville <philipp@redfish-solutions.com>
---
--- a/drivers/atm/solos-pci.c 2011-03-20 01:42:22.000000000 -0600
+++ b/drivers/atm/solos-pci.c 2011-03-20 14:23:26.000000000 -0600
@@ -165,7 +165,6 @@ static uint32_t fpga_tx(struct solos_car
static irqreturn_t solos_irq(int irq, void *dev_id);
static struct atm_vcc* find_vcc(struct atm_dev *dev, short vpi, int vci);
static int list_vccs(int vci);
-static void release_vccs(struct atm_dev *dev);
static int atm_init(struct solos_card *, struct device *);
static void atm_remove(struct solos_card *);
static int send_command(struct solos_card *card, int dev, const char *buf, size_t size);
@@ -384,7 +383,7 @@ static int process_status(struct solos_c
/* Anything but 'Showtime' is down */
if (strcmp(state_str, "Showtime")) {
atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
- release_vccs(card->atmdev[port]);
+ atm_dev_release_vccs(card->atmdev[port]);
dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
return 0;
}
@@ -837,28 +836,6 @@ static int list_vccs(int vci)
return num_found;
}
-static void release_vccs(struct atm_dev *dev)
-{
- int i;
-
- write_lock_irq(&vcc_sklist_lock);
- for (i = 0; i< VCC_HTABLE_SIZE; i++) {
- struct hlist_head *head =&vcc_hash[i];
- struct hlist_node *node, *tmp;
- struct sock *s;
- struct atm_vcc *vcc;
-
- sk_for_each_safe(s, node, tmp, head) {
- vcc = atm_sk(s);
- if (vcc->dev == dev) {
- vcc_release_async(vcc, -EPIPE);
- sk_del_node_init(s);
- }
- }
- }
- write_unlock_irq(&vcc_sklist_lock);
-}
-
static int popen(struct atm_vcc *vcc)
{
--- a/net/atm/common.c 2011-01-04 17:50:19.000000000 -0700
+++ b/net/atm/common.c 2011-03-20 15:22:59.000000000 -0600
@@ -252,6 +252,7 @@ void atm_dev_release_vccs(struct atm_dev
}
write_unlock_irq(&vcc_sklist_lock);
}
+EXPORT_SYMBOL(atm_dev_release_vccs);
static int adjust_tp(struct atm_trafprm *tp, unsigned char aal)
{
--- a/include/linux/atmdev.h 2011-01-04 17:50:19.000000000 -0700
+++ b/include/linux/atmdev.h 2011-03-20 15:25:08.000000000 -0600
@@ -443,6 +443,7 @@ void atm_dev_signal_change(struct atm_de
void vcc_insert_socket(struct sock *sk);
+void atm_dev_release_vccs(struct atm_dev *dev);
/*
* This is approximately the algorithm used by alloc_skb.
^ permalink raw reply
* [PATCH 1/2] socket: increase default maximum listen queue length
From: Hagen Paul Pfeifer @ 2011-03-20 23:04 UTC (permalink / raw)
To: netdev; +Cc: Hagen Paul Pfeifer, Eric Dumazet
In-Reply-To: <20110320121414.GC3038@nuttenaction>
sysctl_somaxconn (SOMAXCONN: 128) specifies the maximum number of
sockets in state SYN_RECV per listen socket queue. At listen(2) time the
backlog is adjusted to this limit if bigger then that.
Afterwards in reqsk_queue_alloc() the backlog value is checked again
(nr_table_entries == backlog):
nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
nr_table_entries = max_t(u32, nr_table_entries, 8);
nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
sysctl_max_syn_backlog on the other hand is dynamically adjusted,
depending on the memory characteristic of the system. Default is 256,
128 for small systems and up to 1024 for bigger systems.
For real server work the defacto sysctl_somaxconn limit seems inadequate:
Experiments with real servers show, that it is absolutely not enough
even at 100conn/sec. 256 cures most of problems.
Increase default sysctl_somaxconn from 128 to 256 to meet todays condition by
simultaneously limit nr_table_entries by sysctl_max_syn_backlog which is
based on memory condition (max(128, (tcp_hashinfo.ehash_mask + 1 / 256)).
Signed_off-by: Hagen Paul Pfeifer <hagen@jauu.net>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
---
include/linux/socket.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index edbb1d0..bf35ce2 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -237,7 +237,7 @@ struct ucred {
#define PF_MAX AF_MAX
/* Maximum queue length specifiable by listen. */
-#define SOMAXCONN 128
+#define SOMAXCONN 256
/* Flags we can use with send/ and recv.
Added those for 1003.1g not all are supported yet
--
1.7.4.1.57.g0466.dirty
^ permalink raw reply related
* [PATCH 2/2] socket: add minimum listen queue length sysctl
From: Hagen Paul Pfeifer @ 2011-03-20 23:04 UTC (permalink / raw)
To: netdev; +Cc: Hagen Paul Pfeifer
In-Reply-To: <1300662282-24741-1-git-send-email-hagen@jauu.net>
In the case that a server programmer misjudge network characteristic the
backlog parameter for listen(2) may not adequate to utilize hosts
capabilities and lead to unrequired SYN retransmission - a small backlog
value can form an artificial limitation. From Erics server setup, a
listen queue length of 8 is often a way to small):
ss -a | head
State Recv-Q Send-Q Local Address:Port Peer
Address:Port
LISTEN 0 8 *:imaps *:*
LISTEN 0 8 *:pop3s *:*
LISTEN 0 50 *:mysql *:*
LISTEN 0 8 *:pop3 *:*
LISTEN 0 8 *:imap2 *:*
LISTEN 0 511 *:www *:*
Until now it is not possible for the system (network) administrator to
increase this value. A bug report must be filled, the backlog increased,
a new version released or even worse: if using closed source software
you cannot make anything.
sysctl_min_syn_backlog provides the ability to increase the minimum
queue length. The default is 8.
Signed-off-by: Hagen Paul Pfeifer <hagen@jauu.net>
---
I will spin a second documentation patch if Davem accept this patch.
---
include/net/request_sock.h | 1 +
net/core/request_sock.c | 5 ++++-
net/ipv4/sysctl_net_ipv4.c | 7 +++++++
3 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/include/net/request_sock.h b/include/net/request_sock.h
index 99e6e19..3e8865f 100644
--- a/include/net/request_sock.h
+++ b/include/net/request_sock.h
@@ -89,6 +89,7 @@ static inline void reqsk_free(struct request_sock *req)
}
extern int sysctl_max_syn_backlog;
+extern int sysctl_min_syn_backlog;
/** struct listen_sock - listen state
*
diff --git a/net/core/request_sock.c b/net/core/request_sock.c
index 182236b..e937e9c 100644
--- a/net/core/request_sock.c
+++ b/net/core/request_sock.c
@@ -35,6 +35,9 @@
int sysctl_max_syn_backlog = 256;
EXPORT_SYMBOL(sysctl_max_syn_backlog);
+int sysctl_min_syn_backlog = 8;
+EXPORT_SYMBOL(sysctl_min_syn_backlog);
+
int reqsk_queue_alloc(struct request_sock_queue *queue,
unsigned int nr_table_entries)
{
@@ -42,7 +45,7 @@ int reqsk_queue_alloc(struct request_sock_queue *queue,
struct listen_sock *lopt;
nr_table_entries = min_t(u32, nr_table_entries, sysctl_max_syn_backlog);
- nr_table_entries = max_t(u32, nr_table_entries, 8);
+ nr_table_entries = max_t(u32, nr_table_entries, sysctl_min_syn_backlog);
nr_table_entries = roundup_pow_of_two(nr_table_entries + 1);
lopt_size += nr_table_entries * sizeof(struct request_sock *);
if (lopt_size > PAGE_SIZE)
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 1a45665..cc03c62 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -298,6 +298,13 @@ static struct ctl_table ipv4_table[] = {
.proc_handler = proc_dointvec
},
{
+ .procname = "tcp_min_syn_backlog",
+ .data = &sysctl_min_syn_backlog,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+ {
.procname = "ip_local_port_range",
.data = &sysctl_local_ports.range,
.maxlen = sizeof(sysctl_local_ports.range),
--
1.7.4.1.57.g0466.dirty
^ permalink raw reply related
* Re: [PATCH 1/2] socket: increase default maximum listen queue length
From: David Miller @ 2011-03-20 23:09 UTC (permalink / raw)
To: hagen; +Cc: netdev, eric.dumazet
In-Reply-To: <1300662282-24741-1-git-send-email-hagen@jauu.net>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Mon, 21 Mar 2011 00:04:41 +0100
> For real server work the defacto sysctl_somaxconn limit seems inadequate:
>
> Experiments with real servers show, that it is absolutely not enough
> even at 100conn/sec. 256 cures most of problems.
Absolutely no context is provided for this number.
What's the RTT? How fast are the cpus? etc.
You must tell the whole story in order to justify these changes
properly.
^ permalink raw reply
* [PATCH 1/1] solos-pci: Fix regression introduced by newest firmware
From: Philip Prindeville @ 2011-03-20 23:41 UTC (permalink / raw)
To: Netdev; +Cc: linux-atm-general@lists.sourceforge.net
The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.
The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.
Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's. It should not: only transitions from FOUND to LOST or UNKNOWN should do this (actually, it's bears examining if the VC's should be released at all).
So we add a check to the previous state on transitions for leaving FOUND state.
Signed-off-by: Philip A Prindeville <philipp@redfish-solutions.com>
---
--- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
+++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
@@ -382,8 +382,11 @@ static int process_status(struct solos_c
/* Anything but 'Showtime' is down */
if (strcmp(state_str, "Showtime")) {
+ char old_signal = card->atmdev[port]->signal;
+
atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
- atm_dev_release_vccs(card->atmdev[port]);
+ if (old_signal == ATM_PHY_SIG_FOUND)
+ atm_dev_release_vccs(card->atmdev[port]);
dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
return 0;
}
^ permalink raw reply
* Re: [PATCH 1/2] socket: increase default maximum listen queue length
From: Hagen Paul Pfeifer @ 2011-03-20 23:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.dumazet
In-Reply-To: <20110320.160906.112595807.davem@davemloft.net>
* David Miller | 2011-03-20 16:09:06 [-0700]:
>Absolutely no context is provided for this number.
>
>What's the RTT? How fast are the cpus? etc.
>
>You must tell the whole story in order to justify these changes
>properly.
(you can skip the first paragraphs and read the last one ;)
The number is somewhat magically - like many other values. I greped
tglx/history.git but the comment (at that time tcp_ipv4.c) seems pre 2002 era.
Providing context is a little bit artificial: I can construct an scenario with
a RTT of 200ms and 1000 connection request per second and the table will
overflow. This can happen, sure. On the other hand there are scenarios with a
RTT of 20ms and 10 connection requests per second - no problem there.
Increasing the number _has_ one essential advantage: it is aligned on
sysctl_max_syn_backlog which in turn is determined by memory characteristics.
Without patch (sysctl not modified, BUT sysctl_max_syn_backlog depending on memory characteristic):
listen-queue-length = max(8, min(userspace_backlog, min(128, sysctl_max_syn_backlog))
Wit patch (sysctl not modified, BUT sysctl_max_syn_backlog depending on memory characteristic):
listen-queue-length = max(8, min(userspace_backlog, min(256, sysctl_max_syn_backlog))
The point is now: sysctl_max_syn_backlog is per default 256, 128 for small
systems and up to 1024 for larger systems. But sysctl_somaxconn (128) will
_always_ restrict the queue length to 128 and make therefore
sysctl_max_syn_backlog defacto unfeasible - it will always restrict the value
to 128. IMHO sysctl_somaxconn should be removed, the overhead of the
listen-queue size per listening socket is insignificant. Especially because
sysctl_max_syn_backlog already consider the memory characteristic. There are a
bunch more connected sockets as these <10 listening sockets, but performance
lack because of will always be noticeable:
netstat -s | grep overflowed
2621 times the listen queue of a socket overflowed
Hagen
^ permalink raw reply
* Re: [PATCH 1/2] socket: increase default maximum listen queue length
From: Hagen Paul Pfeifer @ 2011-03-20 23:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, eric.dumazet
In-Reply-To: <20110320.160906.112595807.davem@davemloft.net>
* David Miller | 2011-03-20 16:09:06 [-0700]:
>You must tell the whole story in order to justify these changes
>properly.
BTW: the second patch is independent and provides a new feature, mentioned by
Eric.
Hagen
^ permalink raw reply
* Re: [PATCH 1/2] socket: increase default maximum listen queue length
From: David Miller @ 2011-03-21 0:18 UTC (permalink / raw)
To: hagen; +Cc: netdev, eric.dumazet
In-Reply-To: <20110320235253.GD3038@nuttenaction>
From: Hagen Paul Pfeifer <hagen@jauu.net>
Date: Mon, 21 Mar 2011 00:52:53 +0100
> The number is somewhat magically - like many other values. I greped
> tglx/history.git but the comment (at that time tcp_ipv4.c) seems pre 2002 era.
Then don't use that number as part of the justification for the
change.
Describe what matters, and only what matters. Providing magic and
arbitrary numbers doesn't help people reading your commit message.
^ permalink raw reply
* [PATCH] irda: validate peer name and attribute lengths
From: Dan Rosenberg @ 2011-03-21 1:32 UTC (permalink / raw)
To: Samuel Ortiz, David S. Miller; +Cc: netdev, security
Length fields provided by a peer for names and attributes may be longer
than the destination array sizes. Validate lengths to prevent stack
buffer overflows.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable@kernel.org
---
net/irda/iriap.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/irda/iriap.c b/net/irda/iriap.c
index 5b743bd..3647753 100644
--- a/net/irda/iriap.c
+++ b/net/irda/iriap.c
@@ -656,10 +656,16 @@ static void iriap_getvaluebyclass_indication(struct iriap_cb *self,
n = 1;
name_len = fp[n++];
+
+ IRDA_ASSERT(name_len < IAS_MAX_CLASSNAME + 1, return;);
+
memcpy(name, fp+n, name_len); n+=name_len;
name[name_len] = '\0';
attr_len = fp[n++];
+
+ IRDA_ASSERT(attr_len < IAS_MAX_ATTRIBNAME + 1, return;);
+
memcpy(attr, fp+n, attr_len); n+=attr_len;
attr[attr_len] = '\0';
^ permalink raw reply related
* [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: Philip Prindeville @ 2011-03-21 1:52 UTC (permalink / raw)
To: Netdev; +Cc: linux-atm-general@lists.sourceforge.net
The newest FPGA firmware on the Solos processors correctly signals carrier transitions, bitrate, etc.
The driver previously ignored these messages, and the physical state was always ATM_PHY_SIG_UNKNOWN.
Now that the board reports its state, we expose a bug whereby the transition from UNKNOWN to LOST causes us to release all VC's.
We don't delete any VC's, but instead just send an indication of carrier change.
Signed-off-by: Philip A Prindeville <philipp@redfish-solutions.com>
---
--- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
+++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
@@ -382,8 +382,10 @@ static int process_status(struct solos_c
/* Anything but 'Showtime' is down */
if (strcmp(state_str, "Showtime")) {
atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
+#if 0
atm_dev_release_vccs(card->atmdev[port]);
+#endif
dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
return 0;
}
^ permalink raw reply
* Re: [PULL net-2.6] vhost: cleanups and fixes
From: David Miller @ 2011-03-21 2:08 UTC (permalink / raw)
To: mst
Cc: kvm, virtualization, netdev, linux-kernel, eric.dumazet, jasowang,
krkumar2
In-Reply-To: <20110317140403.GA16390@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Thu, 17 Mar 2011 16:04:04 +0200
> The following changes since commit 1fc050a13473348f5c439de2bb41c8e92dba5588:
>
> ipv4: Cache source address in nexthop entries. (2011-03-07 20:54:48 -0800)
>
> are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next
>
> Jason Wang (3):
> vhost-net: check the support of mergeable buffer outside the receive loop
> vhost-net: Unify the code of mergeable and big buffer handling
> vhost: lock receive queue, not the socket
>
> Krishna Kumar (1):
> vhost: Cleanup vhost.c and net.c
>
> Michael S. Tsirkin (2):
> vhost: copy_from_user -> __copy_from_user
> vhost-net: remove unlocked use of receive_queue
Pulled, thanks.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2011-03-21 2:51 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) The R8169 PHY fix from Eric Dumazet, which I see you've added to
your tree too. :-)
2) NIU driver broken by OF layer changes, fix by eliminating platform
device name conflict.
3) Fix VHOST receive queue locking, from Michael S. Tsirkin.
4) Some gianfar chips are buggy wrt. checksums for certain packet
buffer alignments, fall back to sw checksumming in those cases.
From Alex Dubov.
5) ECONET leaks 4 uninitialized bytes to the network, fix from Vasiliy
Kulikov.
6) Fix blind deref of ethtool_ops->set_sg(), fix from Roger Luethi.
7) ethtool_rxnfc needs syscall compat handling, from Ben Hutchings.
8) VLAN broken over gre tunnels because it does not take
->needed_headroom into account. Fix from Eric Dumazet.
9) Bridging netfilter needs to init IPCB() of skb before injecting
packet into the IP stack, fix from Herbert Xu.
10) ftmac100 has off-by-one error, fix by using resource_size(). Fix
from Dan Carpenter.
11) IPSET fixes from Jozsef Kadlecsik.
12) Netfilter xtables has some reentrancy issues, fix from Eric Dumazet.
13) CLUSTERIP netfilter iptablesm module needs to check user buffer size
more carefully, fix from Vasiliy Kulikov.
Please pull, thanks a lot!
The following changes since commit a44f99c7efdb88fa41128065c9a9445c19894e34:
Merge branch 'trivial' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6 (2011-03-20 18:14:55 -0700)
are available in the git repository at:
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.git master
Alex Dubov (1):
gianfar: Fall back to software tcp/udp checksum on older controllers
Ben Hutchings (1):
ethtool: Compat handling for struct ethtool_rxnfc
Dan Carpenter (1):
ftmac100: use resource_size()
David S. Miller (3):
niu: Rename NIU parent platform device name to fix conflict.
Merge branch 'master' of git://git.kernel.org/.../kaber/nf-2.6
Merge branch 'vhost-net-next' of git://git.kernel.org/.../mst/vhost
Eric Dumazet (3):
vlan: should take into account needed_headroom
r8169: fix a bug in rtl8169_init_phy()
netfilter: xtables: fix reentrancy
Herbert Xu (1):
bridge: Reset IPCB when entering IP stack on NF_FORWARD
Jason Wang (3):
vhost-net: check the support of mergeable buffer outside the receive loop
vhost-net: Unify the code of mergeable and big buffer handling
vhost: lock receive queue, not the socket
Jozsef Kadlecsik (2):
netfilter: ipset: fix address ranges at hash:*port* types
netfilter: ipset: fix checking the type revision at create command
Krishna Kumar (1):
vhost: Cleanup vhost.c and net.c
Michael S. Tsirkin (2):
vhost: copy_from_user -> __copy_from_user
vhost-net: remove unlocked use of receive_queue
Mike Frysinger (1):
headers: use __aligned_xx types for userspace
Nicolas de Pesloüan (1):
bonding: fix a typo in a comment
Roger Luethi (1):
ethtool: __ethtool_set_sg: check for function pointer before using it
Vasiliy Kulikov (2):
econet: 4 byte infoleak to the network
netfilter: ipt_CLUSTERIP: fix buffer overflow
drivers/net/bonding/bond_main.c | 2 +-
drivers/net/ftmac100.c | 2 +-
drivers/net/gianfar.c | 16 ++-
drivers/net/gianfar.h | 1 +
drivers/net/niu.c | 2 +-
drivers/net/r8169.c | 4 +-
drivers/vhost/net.c | 159 ++++--------------------
drivers/vhost/vhost.c | 55 ++++++---
include/linux/ethtool.h | 34 +++++
include/linux/if_ppp.h | 16 ++--
include/linux/netfilter/ipset/ip_set_getport.h | 10 ++
include/linux/netfilter/nfnetlink_log.h | 4 +-
include/linux/netfilter/nfnetlink_queue.h | 4 +-
include/linux/netfilter/xt_connbytes.h | 4 +-
include/linux/netfilter/xt_quota.h | 2 +-
net/8021q/vlan_dev.c | 1 +
net/bridge/br_netfilter.c | 3 +
net/core/ethtool.c | 3 +
net/econet/af_econet.c | 2 +-
net/ipv4/netfilter/ip_tables.c | 4 +-
net/ipv4/netfilter/ipt_CLUSTERIP.c | 5 +-
net/ipv6/netfilter/ip6_tables.c | 4 +-
net/netfilter/ipset/ip_set_core.c | 22 +++-
net/netfilter/ipset/ip_set_hash_ipport.c | 34 ++----
net/netfilter/ipset/ip_set_hash_ipportip.c | 34 ++----
net/netfilter/ipset/ip_set_hash_ipportnet.c | 34 ++----
net/netfilter/ipset/ip_set_hash_netport.c | 30 ++----
net/socket.c | 114 ++++++++++++++++-
28 files changed, 321 insertions(+), 284 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: Ben Hutchings @ 2011-03-21 3:01 UTC (permalink / raw)
To: Philip Prindeville; +Cc: Netdev, linux-atm-general@lists.sourceforge.net
In-Reply-To: <4D86AF4F.5010203@redfish-solutions.com>
On Sun, 2011-03-20 at 18:52 -0700, Philip Prindeville wrote:
> The newest FPGA firmware on the Solos processors correctly signals
> carrier transitions, bitrate, etc.
>
> The driver previously ignored these messages, and the physical state
> was always ATM_PHY_SIG_UNKNOWN.
>
> Now that the board reports its state, we expose a bug whereby the
> transition from UNKNOWN to LOST causes us to release all VC's.
>
> We don't delete any VC's, but instead just send an indication of
> carrier change.
>
> Signed-off-by: Philip A Prindeville <philipp@redfish-solutions.com>
> ---
>
> --- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
> +++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>
> /* Anything but 'Showtime' is down */
> if (strcmp(state_str, "Showtime")) {
> atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
> +#if 0
> atm_dev_release_vccs(card->atmdev[port]);
> +#endif
Either remove it or don't. #if 0 is for people without version control.
Ben.
> dev_info(&card->dev->dev, "Port %d: %s\n", port, state_str);
> return 0;
> }
>
>
> --
> 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
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v2 1/1] solos-pci: Fix regression introduced by newest firmware
From: David Miller @ 2011-03-21 4:57 UTC (permalink / raw)
To: bhutchings; +Cc: philipp_subx, netdev, linux-atm-general
In-Reply-To: <1300676496.26693.318.camel@localhost>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 21 Mar 2011 03:01:36 +0000
> On Sun, 2011-03-20 at 18:52 -0700, Philip Prindeville wrote:
>> The newest FPGA firmware on the Solos processors correctly signals
>> carrier transitions, bitrate, etc.
>>
>> The driver previously ignored these messages, and the physical state
>> was always ATM_PHY_SIG_UNKNOWN.
>>
>> Now that the board reports its state, we expose a bug whereby the
>> transition from UNKNOWN to LOST causes us to release all VC's.
>>
>> We don't delete any VC's, but instead just send an indication of
>> carrier change.
>>
>> Signed-off-by: Philip A Prindeville <philipp@redfish-solutions.com>
>> ---
>>
>> --- a/drivers/atm/solos-pci.c 2011-03-20 15:27:40.000000000 -0600
>> +++ b/drivers/atm/solos-pci.c 2011-03-20 16:32:11.000000000 -0600
>> @@ -382,8 +382,10 @@ static int process_status(struct solos_c
>>
>> /* Anything but 'Showtime' is down */
>> if (strcmp(state_str, "Showtime")) {
>> atm_dev_signal_change(card->atmdev[port], ATM_PHY_SIG_LOST);
>> +#if 0
>> atm_dev_release_vccs(card->atmdev[port]);
>> +#endif
>
> Either remove it or don't. #if 0 is for people without version control.
Also, this would seem to break those using the older firmware.
^ permalink raw reply
* xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 5:45 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller, Steffen Klassert
Commit 'xfrm: Move IPsec replay detection functions to a separate file'
(9fdc4883d92d20842c5acea77a4a21bb1574b495)
introduce repl field to struct xfrm_state, and only initialize it
under SA's netlink create path, the other path, such as pf_key, the
repl field remaining uninitialize. So if the SA is created by pf_key,
any input packet with SA's encryption algorithm will cause panic.
int xfrm_input()
{
...
x->repl->advance(x, seq);
...
}
This patch fixed to init default xfrm_replay in xfrm_init_state().
Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
EIP is at xfrm_input+0x31c/0x4cc
EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
Stack:
00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
Call Trace:
[<c0786848>] xfrm4_rcv_encap+0x22/0x27
[<c0786868>] xfrm4_rcv+0x1b/0x1d
[<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074ef77>] ip_local_deliver+0x3e/0x44
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ec03>] ip_rcv_finish+0x30a/0x332
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074f188>] ip_rcv+0x20b/0x247
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c072797d>] __netif_receive_skb+0x373/0x399
[<c0727bc1>] netif_receive_skb+0x4b/0x51
[<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
[<c072818f>] net_rx_action+0x9a/0x17d
[<c0445b5c>] __do_softirq+0xa1/0x149
[<c0445abb>] ? __do_softirq+0x0/0x149
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/xfrm/xfrm_state.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index d575f05..4274e11 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1980,6 +1980,10 @@ int xfrm_init_state(struct xfrm_state *x)
if (x->outer_mode == NULL)
goto error;
+ err = xfrm_init_replay(x);
+ if (err)
+ goto error;
+
x->km.state = XFRM_STATE_VALID;
error:
--
1.6.5.2
^ permalink raw reply related
* RE: [PATCH net-next-2.6 2/6] be2net: fix to not drop unfiltered vlan pkts
From: Sathya.Perla @ 2011-03-21 5:41 UTC (permalink / raw)
To: jesse; +Cc: netdev
In-Reply-To: <AANLkTimNHmvFznX-XHmhdVmkRBBjrkEa1OyAB=gSCciu@mail.gmail.com>
Hi, can you pls clarify what you mean by the "new vlan model" below...
thanks,
-Sathya
-----Original Message-----
From: Jesse Gross [mailto:jesse@nicira.com]
Sent: Saturday, March 19, 2011 2:05 AM
To: Perla, Sathya
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH net-next-2.6 2/6] be2net: fix to not drop unfiltered vlan pkts
On Fri, Mar 18, 2011 at 6:20 AM, Sathya Perla <sathya.perla@emulex.com> wrote:
> When the device is in promiscuous mode, the driver can receive vlan packets
> (tag is always stripped by card) even when there is no vlan configuration.
> Such packets must be sent to the stack and not dropped.
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
> ---
> drivers/net/benet/be_main.c | 9 ++-------
> 1 files changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/benet/be_main.c b/drivers/net/benet/be_main.c
> index 97c5167..18c6da4 100644
> --- a/drivers/net/benet/be_main.c
> +++ b/drivers/net/benet/be_main.c
> @@ -1013,15 +1013,10 @@ static void be_rx_compl_process(struct be_adapter *adapter,
> skb->truesize = skb->len + sizeof(struct sk_buff);
> skb->protocol = eth_type_trans(skb, adapter->netdev);
>
> - if (unlikely(rxcp->vlanf)) {
> - if (!adapter->vlan_grp || adapter->vlans_added == 0) {
> - kfree_skb(skb);
> - return;
> - }
> + if (unlikely(rxcp->vlanf))
> vlan_hwaccel_receive_skb(skb, adapter->vlan_grp, rxcp->vid);
It would be better to use __vlan_hwaccel_put_tag() here - it's
equivalent but at least moves in the right direction. Under the old
vlan model (which vlan_hwaccel_receive_skb() is left over from)
passing in a NULL vlan group is illegal, so it's inconsistent anyways.
Of course even better would be to fully convert over to the new vlan
model. A quick skim through the code shows that there might be
similar issue with vlan_gro_frags() as above, so it could help catch
some of that.
^ permalink raw reply
* [PATCH] xfrm: Fix initialize repl field of struct xfrm_state
From: Wei Yongjun @ 2011-03-21 5:48 UTC (permalink / raw)
To: netdev@vger.kernel.org, David Miller, Steffen Klassert
In-Reply-To: <4D86E603.8080704@cn.fujitsu.com>
Commit 'xfrm: Move IPsec replay detection functions to a separate file'
(9fdc4883d92d20842c5acea77a4a21bb1574b495)
introduce repl field to struct xfrm_state, and only initialize it
under SA's netlink create path, the other path, such as pf_key, the
repl field remaining uninitialize. So if the SA is created by pf_key,
any input packet with SA's encryption algorithm will cause panic.
int xfrm_input()
{
...
x->repl->advance(x, seq);
...
}
This patch fixed to init default xfrm_replay in xfrm_init_state().
Pid: 0, comm: swapper Not tainted 2.6.38-next+ #14 Bochs Bochs
EIP: 0060:[<c078e5d5>] EFLAGS: 00010206 CPU: 0
EIP is at xfrm_input+0x31c/0x4cc
EAX: dd839c00 EBX: 00000084 ECX: 00000000 EDX: 01000000
ESI: dd839c00 EDI: de3a0780 EBP: dec1de88 ESP: dec1de64
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=dec1c000 task=c09c0f20 task.ti=c0992000)
Stack:
00000000 00000000 00000002 c0ba27c0 00100000 01000000 de3a0798 c0ba27c0
00000033 dec1de98 c0786848 00000000 de3a0780 dec1dea4 c0786868 00000000
dec1debc c074ee56 e1da6b8c de3a0780 c074ed44 de3a07a8 dec1decc c074ef32
Call Trace:
[<c0786848>] xfrm4_rcv_encap+0x22/0x27
[<c0786868>] xfrm4_rcv+0x1b/0x1d
[<c074ee56>] ip_local_deliver_finish+0x112/0x1b1
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074ef77>] ip_local_deliver+0x3e/0x44
[<c074ed44>] ? ip_local_deliver_finish+0x0/0x1b1
[<c074ec03>] ip_rcv_finish+0x30a/0x332
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c074ef32>] NF_HOOK.clone.1+0x3d/0x44
[<c074f188>] ip_rcv+0x20b/0x247
[<c074e8f9>] ? ip_rcv_finish+0x0/0x332
[<c072797d>] __netif_receive_skb+0x373/0x399
[<c0727bc1>] netif_receive_skb+0x4b/0x51
[<e0817e2a>] cp_rx_poll+0x210/0x2c4 [8139cp]
[<c072818f>] net_rx_action+0x9a/0x17d
[<c0445b5c>] __do_softirq+0xa1/0x149
[<c0445abb>] ? __do_softirq+0x0/0x149
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
---
net/xfrm/xfrm_state.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index d575f05..4274e11 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -1980,6 +1980,10 @@ int xfrm_init_state(struct xfrm_state *x)
if (x->outer_mode == NULL)
goto error;
+ err = xfrm_init_replay(x);
+ if (err)
+ goto error;
+
x->km.state = XFRM_STATE_VALID;
error:
--
1.6.5.2
^ permalink raw reply related
* Re: xfrm: Fix initialize repl field of struct xfrm_state
From: David Miller @ 2011-03-21 5:55 UTC (permalink / raw)
To: yjwei; +Cc: netdev, steffen.klassert
In-Reply-To: <4D86E603.8080704@cn.fujitsu.com>
From: Wei Yongjun <yjwei@cn.fujitsu.com>
Date: Mon, 21 Mar 2011 13:45:39 +0800
> Commit 'xfrm: Move IPsec replay detection functions to a separate file'
> (9fdc4883d92d20842c5acea77a4a21bb1574b495)
> introduce repl field to struct xfrm_state, and only initialize it
> under SA's netlink create path, the other path, such as pf_key, the
> repl field remaining uninitialize. So if the SA is created by pf_key,
> any input packet with SA's encryption algorithm will cause panic.
Please, either add an xfrm_init_replay() call to the appropriate spot
in net/key/af_key.c or, if possible, only have the one call in
xfrm_init_state(). Don't leave two calls, one in xfrm_user.c and one
in xfrm_state.c
Anyways, I don't think just making one call from xfrm_init_state() is
possible, because the replay settings need to be assigned before we
can properly call xfrm_init_replay().
Therefore, please fix this by adding the necessary call to af_key.c
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox