Re: [IPSEC]: Fix ip_local_out when NETFILTER is off
From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 15:34:25 +0800 > [IPSEC]: Fix ip_local_out when NETFILTER is off > > Thanks for testing with NETFILTER off because I obviously didn't :) > The code for ip_local_out/ip6_local_out is completely broken in > that case. > > This patch fixes and also makes the IPsec path use the correct > local_out function so that the loop executes properly and we > don't end up nesting too deep and overrun the stack. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Applied, thanks Herbert. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10 REV5] [E1000] Implement batching
Hi Auke, "Kok, Auke" <[EMAIL PROTECTED]> wrote on 11/14/2007 02:58:14 AM: > this doesn't apply anymore and it would help if you could re-spin this for e1000e. > I don't know what the status for merging of the batched xmit patches is right now > but it would help if you could rewrite them against e1000e, which I assume is what > most people want to test with. There are also significant changes upstream right > now in jgarzik/netdev-2.6 #upstream... > > I'm still very interested in these patches BTW. I will make a latest version and test it out for some numbers and try to send it this week. Thanks, - KK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 06:27:00PM -0800, Andrew Morton wrote: > On Tue, 13 Nov 2007 17:55:51 -0800 (PST) David Miller <[EMAIL PROTECTED]> > wrote: > > > I've created [EMAIL PROTECTED] > > Let me just say - I'm astonished at how little spam gets though the vger > lists. Considering how many times those email addresses must have been > added to spam databases. > > It must be a lot of work, and whoever is doing it does it well. > > I don't even know. Is it Matti? You? > > Martin's changed the owner for ARM bugs last night to the mailing list so the whole issue is now redundant. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PATCH 1/2 [SCHED 2.6.24]: Check subqueue status before calling hard_start_xmit
> > You could optimize this by getting HARD_TX_LOCK after the check. I > > assume that netif_stop_subqueue (from another CPU) would always be > > called by the driver xmit, and that is not possible since we hold > > the __LINK_STATE_QDISC_RUNNING bit. Does that sound correct? > > I don't think this is a critical optimization at this time, > but something to certainly do along with the surgery > we'll undoubtedly be doing here in the future :-) Apologies for the spam... I guess this check can be completely removed once other qdiscs are modified to support subqueue. Essentially sch_prio and sch_rr executes subqueue_stopped twice for every skb while this check is required only for other qdiscs (and really belongs in the individual qdisc dequeue handlers). Thanks, - KK - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/24] [IPSEC]: Merge most of the output path
David Miller wrote: From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 8 Nov 2007 19:29:21 +0800 On Thu, Nov 08, 2007 at 12:23:29PM +0100, Patrick McHardy wrote: We have a few places that go though the trouble of selecting the "correct" hook value for the address family, even though the numerical values are identical. How about we just get rid of the different naming and use NF_INET_... for both IPv4 and IPv6? Nice work! Thanks Patrick. Yeah I like it too, applied to net-2.6.25 I had to do some minor rediffing to make it go in cleanly after Herbert's work, so I'm doing some build testing before I push this bit onto kernel.org Thanks Dave. As luck would have it, my HIFN card should arrive within the next few hours, so I'll try to convert esp over to async crypto and give this all some good testing :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug in using inet_lookup ()
Dear All,
I need to use the inet_lookup function to find the sock structure of a TCP
connection in a SYN_RECV state.
Here is what I used to do so:
/* The kernel TCP hashtable */
struct inet_hashinfo __cacheline_aligned tcp_hashinfo = {
.lhash_lock = __RW_LOCK_UNLOCKED (tcp_hashinfo.lhash_lock),
.lhash_users = ATOMIC_INIT (0),
.lhash_wait = __WAIT_QUEUE_HEAD_INITIALIZER (tcp_hashinfo.lhash_wait),
};
...
struct sock *sk;
struct sk_buff *skb;
skb = alloc_skb (MAX_TCP_HEADER + 15, GFP_KERNEL);
if (skb == NULL)
printk ("%s: Unable to allocate memory \n", __FUNCTION__);
sk = inet_lookup (&tcp_hashinfo, ip_src, src_port, ip_dst, dst_port, inet_iif
(skb));
if (!sk)
...
This portion of code seems to cause the kernel to panic due to dereferencing a
NULL pointer.
Can anyone please tell me what is the error above?
Best Regards,
_
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X local entry memories when vector allocation fails
- Fixed memory leak by freeing MSI-X local entry memories when vector allocation
fails in s2io_add_isr.
- Added two utility functions remove_msix_isr and remove_inta_isr to eliminate
code duplication.
- Incorporated following review comments from Jeff
- Removed redundant stats->mem_freed and synchronize_irq call
- do_rem_msix_isr is renamed as remove_msix_isr
- do_rem_inta_isr is renamed as remove_inta_isr
- (Resubmit third time)
Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]>
---
diff -Nurp org/drivers/net/s2io.c patch1/drivers/net/s2io.c
--- org/drivers/net/s2io.c 2007-11-12 22:00:23.0 +0530
+++ patch1/drivers/net/s2io.c 2007-11-12 23:53:19.0 +0530
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.5"
+#define DRV_VERSION "2.0.26.6"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
@@ -3775,6 +3775,40 @@ static int __devinit s2io_test_msi(struc
return err;
}
+
+static void remove_msix_isr(struct s2io_nic *sp)
+{
+ int i;
+ u16 msi_control;
+
+ for (i = 0; i < MAX_REQUESTED_MSI_X; i++) {
+ if (sp->s2io_entries[i].in_use ==
+ MSIX_REGISTERED_SUCCESS) {
+ int vector = sp->entries[i].vector;
+ void *arg = sp->s2io_entries[i].arg;
+ free_irq(vector, arg);
+ }
+ }
+
+ kfree(sp->entries);
+ kfree(sp->s2io_entries);
+ sp->entries = NULL;
+ sp->s2io_entries = NULL;
+
+ pci_read_config_word(sp->pdev, 0x42, &msi_control);
+ msi_control &= 0xFFFE; /* Disable MSI */
+ pci_write_config_word(sp->pdev, 0x42, msi_control);
+
+ pci_disable_msix(sp->pdev);
+}
+
+static void remove_inta_isr(struct s2io_nic *sp)
+{
+ struct net_device *dev = sp->dev;
+
+ free_irq(sp->pdev->irq, dev);
+}
+
/* * *
* Functions defined below concern the OS part of the driver *
* * */
@@ -3809,28 +3843,9 @@ static int s2io_open(struct net_device *
int ret = s2io_enable_msi_x(sp);
if (!ret) {
- u16 msi_control;
-
ret = s2io_test_msi(sp);
-
/* rollback MSI-X, will re-enable during add_isr() */
- kfree(sp->entries);
- sp->mac_control.stats_info->sw_stat.mem_freed +=
- (MAX_REQUESTED_MSI_X *
- sizeof(struct msix_entry));
- kfree(sp->s2io_entries);
- sp->mac_control.stats_info->sw_stat.mem_freed +=
- (MAX_REQUESTED_MSI_X *
- sizeof(struct s2io_msix_entry));
- sp->entries = NULL;
- sp->s2io_entries = NULL;
-
- pci_read_config_word(sp->pdev, 0x42, &msi_control);
- msi_control &= 0xFFFE; /* Disable MSI */
- pci_write_config_word(sp->pdev, 0x42, msi_control);
-
- pci_disable_msix(sp->pdev);
-
+ remove_msix_isr(sp);
}
if (ret) {
@@ -6719,15 +6734,22 @@ static int s2io_add_isr(struct s2io_nic
}
}
if (err) {
+ remove_msix_isr(sp);
DBG_PRINT(ERR_DBG,"%s:MSI-X-%d registration "
"failed\n", dev->name, i);
- DBG_PRINT(ERR_DBG, "Returned: %d\n", err);
- return -1;
+ DBG_PRINT(ERR_DBG, "%s: defaulting to INTA\n",
+dev->name);
+ sp->config.intr_type = INTA;
+ break;
}
sp->s2io_entries[i].in_use = MSIX_REGISTERED_SUCCESS;
}
- printk("MSI-X-TX %d entries enabled\n",msix_tx_cnt);
- printk("MSI-X-RX %d entries enabled\n",msix_rx_cnt);
+ if (!err) {
+ printk(KERN_INFO "MSI-X-TX %d entries enabled\n",
+ msix_tx_cnt);
+ printk(KERN_INFO "MSI-X-RX %d entries enabled\n",
+ msix_rx_cnt);
+ }
}
if (sp->config.intr_type == INTA) {
err = request_irq((int) sp->pdev->irq, s2io_isr, IRQF_SHARED,
@@ -6742,40 +6764,10 @@ static int s2io_add_isr(struct s2io_nic
}
static void s2io_rem_isr(struct s2io_nic * sp)
{
- struct net_device *dev = sp->dev;
- struct swStat *stats = &sp->mac_control.stats_info->sw_s
Re: [PATCH 2/2] [IPSEC]: Add async resume support on input
David Miller wrote: From: Herbert Xu <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 14:28:34 +0800 [IPSEC]: Add async resume support on input This patch adds support for async resumptions on input. To do so, the transform would return -EINPROGRESS and subsequently invoke the function xfrm_input_resume to resume processing. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Also applied to net-2.6.25, thanks. I'll work on integrating Patrick's NF_INET_* patch next. I'm rebasing my netfilter tree to net-2.6.25, so unless you're already working on this, I can take care of that. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipconfig.c : implement DHCP Class-identifier
Rainer Jochem wrote:
Corrected version below.
+ printk(KERN_INFO "Sending class identifier \"%s\"\n",
+ vendor_class_identifier);
Seems like useless noise.
This information is only sent in the case that the option is actually used.
And in this case it might be useful for the user to see to which string the
option was set.
I don't think its very useful since you can simply get this information
from /proc/cmdline in case something goes wrong, but if you insist at
least give it a meaningful prefix.
@@ -580,6 +582,7 @@ ic_dhcp_init_options(u8 *options)
u8 mt = ((ic_servaddr == NONE)
? DHCPDISCOVER : DHCPREQUEST);
u8 *e = options;
+ int len = 0;
The initialization is unnecessary.
#ifdef IPCONFIG_DEBUG
printk("DHCP: Sending message type %d\n", mt);
@@ -620,6 +623,16 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+ if (*vendor_class_identifier) {
+ printk(KERN_INFO "Sending class identifier \"%s\"\n",
+ vendor_class_identifier);
+ *e++ = 60; /* Class-identifier */
+ len = strlen(vendor_class_identifier);
+ *e++ = len;
+ memcpy(e, vendor_class_identifier, len);
+ e += len;
+ }
}
*e++ = 255; /* End of the list */
@@ -1507,5 +1520,16 @@ static int __init nfsaddrs_config_setup(
return ip_auto_config_setup(addrs);
}
+static int __init vendor_class_identifier_setup(char *addrs)
+{
+ if (strlcpy(vendor_class_identifier, addrs,
+ sizeof(vendor_class_identifier))
+ > sizeof(vendor_class_identifier))
+ printk(KERN_WARNING "vendorclass too long, truncated to \"%s\"",
+ vendor_class_identifier);
Should be >= I think.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipconfig.c : implement DHCP Class-identifier
Corrected version below.
> >+printk(KERN_INFO "Sending class identifier \"%s\"\n",
> >+ vendor_class_identifier);
>
> Seems like useless noise.
This information is only sent in the case that the option is actually used.
And in this case it might be useful for the user to see to which string the
option was set.
--- net/ipv4/ipconfig.c.orig2007-11-14 09:16:15.800566536 +0100
+++ net/ipv4/ipconfig.c 2007-11-14 09:16:20.200403710 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE; /* Boot serve
__be32 root_server_addr = NONE;/* Address of NFS server */
u8 root_server_path[256] = { 0, }; /* Path to mount as root */
+static char vendor_class_identifier[253]; /* vendor class identifier */
+
/* Persistent data: */
static int ic_proto_used; /* Protocol used, if any */
@@ -580,6 +582,7 @@ ic_dhcp_init_options(u8 *options)
u8 mt = ((ic_servaddr == NONE)
? DHCPDISCOVER : DHCPREQUEST);
u8 *e = options;
+ int len = 0;
#ifdef IPCONFIG_DEBUG
printk("DHCP: Sending message type %d\n", mt);
@@ -620,6 +623,16 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+ if (*vendor_class_identifier) {
+ printk(KERN_INFO "Sending class identifier \"%s\"\n",
+ vendor_class_identifier);
+ *e++ = 60; /* Class-identifier */
+ len = strlen(vendor_class_identifier);
+ *e++ = len;
+ memcpy(e, vendor_class_identifier, len);
+ e += len;
+ }
}
*e++ = 255; /* End of the list */
@@ -1507,5 +1520,16 @@ static int __init nfsaddrs_config_setup(
return ip_auto_config_setup(addrs);
}
+static int __init vendor_class_identifier_setup(char *addrs)
+{
+ if (strlcpy(vendor_class_identifier, addrs,
+ sizeof(vendor_class_identifier))
+ > sizeof(vendor_class_identifier))
+ printk(KERN_WARNING "vendorclass too long, truncated to \"%s\"",
+ vendor_class_identifier);
+ return 1;
+}
+
__setup("ip=", ip_auto_config_setup);
__setup("nfsaddrs=", nfsaddrs_config_setup);
+__setup("dhcpclass=", vendor_class_identifier_setup);
--- ../linux-2.6.23.1/Documentation/kernel-parameters.txt 2007-10-12
18:43:44.0 +0200
+++ Documentation/kernel-parameters.txt 2007-10-24 17:02:22.441454955 +0200
@@ -533,6 +533,10 @@ and is between 256 and 4096 characters.
dhash_entries= [KNL]
Set number of hash buckets for dentry cache.
+ dhcpclass= [IP_PNP]
+ Set DHCP Vendor Class Identifier to be sent
+ by the client.
+
digi= [HW,SERIAL]
IO parameters + enable/disable command.
Signed-off-by: Rainer Jochem <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/24] [IPSEC]: Merge most of the output path
From: Herbert Xu <[EMAIL PROTECTED]> Date: Thu, 8 Nov 2007 19:29:21 +0800 > On Thu, Nov 08, 2007 at 12:23:29PM +0100, Patrick McHardy wrote: > > > > We have a few places that go though the trouble of selecting the > > "correct" hook value for the address family, even though the numerical > > values are identical. How about we just get rid of the different > > naming and use NF_INET_... for both IPv4 and IPv6? > > Nice work! Thanks Patrick. Yeah I like it too, applied to net-2.6.25 I had to do some minor rediffing to make it go in cleanly after Herbert's work, so I'm doing some build testing before I push this bit onto kernel.org Thanks again Patrick. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/24] [IPSEC]: Merge most of the output path
On Wed, Nov 14, 2007 at 10:14:27AM +0100, Patrick McHardy wrote:
>
> Thanks Dave. As luck would have it, my HIFN card should arrive
> within the next few hours, so I'll try to convert esp over to
> async crypto and give this all some good testing :)
Actually I'm already working on that :)
I'm not just converting ESP over to async, I'm also changing
it to use the AEAD interface which is needed for it to properly
support algorithms such as CCM.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 19/24] [IPSEC]: Merge most of the output path
Herbert Xu wrote: On Wed, Nov 14, 2007 at 10:14:27AM +0100, Patrick McHardy wrote: Thanks Dave. As luck would have it, my HIFN card should arrive within the next few hours, so I'll try to convert esp over to async crypto and give this all some good testing :) Actually I'm already working on that :) I'm not just converting ESP over to async, I'm also changing it to use the AEAD interface which is needed for it to properly support algorithms such as CCM. Great. If you're looking for testers, just send it over :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore ethernet addresses
- Support to add/delete/store/restore 64 and 128 Ethernet addresses for Xframe
I and Xframe II respectively.
- (Resubmit third time)
Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]>
---
diff -Nurp org/drivers/net/s2io.c patch1/drivers/net/s2io.c
--- org/drivers/net/s2io.c 2007-11-13 00:22:13.0 +0530
+++ patch1/drivers/net/s2io.c 2007-11-13 03:31:29.0 +0530
@@ -84,7 +84,7 @@
#include "s2io.h"
#include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.6"
+#define DRV_VERSION "2.0.26.7"
/* S2io Driver name & version. */
static char s2io_driver_name[] = "Neterion";
@@ -3365,6 +3365,9 @@ static void s2io_reset(struct s2io_nic *
/* Set swapper to enable I/O register access */
s2io_set_swapper(sp);
+ /* restore mac_addr entries */
+ do_s2io_restore_unicast_mc(sp);
+
/* Restore the MSIX table entries from local variables */
restore_xmsi_data(sp);
@@ -3423,9 +3426,6 @@ static void s2io_reset(struct s2io_nic *
writeq(val64, &bar0->pcc_err_reg);
}
- /* restore the previously assigned mac address */
- do_s2io_prog_unicast(sp->dev, (u8 *)&sp->def_mac_addr[0].mac_addr);
-
sp->device_enabled_once = FALSE;
}
@@ -3913,8 +3913,19 @@ hw_init_failed:
static int s2io_close(struct net_device *dev)
{
struct s2io_nic *sp = dev->priv;
+ struct config_param *config = &sp->config;
+ u64 tmp64;
+ int offset;
netif_stop_queue(dev);
+
+ /* delete all populated mac entries */
+ for (offset = 1; offset < config->max_mc_addr; offset++) {
+ tmp64 = do_s2io_read_unicast_mc(sp, offset);
+ if (tmp64 != S2IO_DISABLE_MAC_ENTRY)
+ do_s2io_delete_unicast_mc(sp, tmp64);
+ }
+
napi_disable(&sp->napi);
/* Reset card, kill tasklet and free Tx and Rx buffers. */
s2io_card_down(sp);
@@ -4716,8 +4727,9 @@ static void s2io_set_multicast(struct ne
struct XENA_dev_config __iomem *bar0 = sp->bar0;
u64 val64 = 0, multi_mac = 0x010203040506ULL, mask =
0xfeffULL;
- u64 dis_addr = 0xULL, mac_addr = 0;
+ u64 dis_addr = S2IO_DISABLE_MAC_ENTRY, mac_addr = 0;
void __iomem *add;
+ struct config_param *config = &sp->config;
if ((dev->flags & IFF_ALLMULTI) && (!sp->m_cast_flg)) {
/* Enable all Multicast addresses */
@@ -4727,7 +4739,7 @@ static void s2io_set_multicast(struct ne
&bar0->rmac_addr_data1_mem);
val64 = RMAC_ADDR_CMD_MEM_WE |
RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD |
- RMAC_ADDR_CMD_MEM_OFFSET(MAC_MC_ALL_MC_ADDR_OFFSET);
+ RMAC_ADDR_CMD_MEM_OFFSET(config->max_mc_addr - 1);
writeq(val64, &bar0->rmac_addr_cmd_mem);
/* Wait till command completes */
wait_for_cmd_complete(&bar0->rmac_addr_cmd_mem,
@@ -4735,7 +4747,7 @@ static void s2io_set_multicast(struct ne
S2IO_BIT_RESET);
sp->m_cast_flg = 1;
- sp->all_multi_pos = MAC_MC_ALL_MC_ADDR_OFFSET;
+ sp->all_multi_pos = config->max_mc_addr - 1;
} else if ((dev->flags & IFF_ALLMULTI) && (sp->m_cast_flg)) {
/* Disable all Multicast addresses */
writeq(RMAC_ADDR_DATA0_MEM_ADDR(dis_addr),
@@ -4804,7 +4816,7 @@ static void s2io_set_multicast(struct ne
/* Update individual M_CAST address list */
if ((!sp->m_cast_flg) && dev->mc_count) {
if (dev->mc_count >
- (MAX_ADDRS_SUPPORTED - MAC_MC_ADDR_START_OFFSET - 1)) {
+ (config->max_mc_addr - config->max_mac_addr)) {
DBG_PRINT(ERR_DBG, "%s: No more Rx filters ",
dev->name);
DBG_PRINT(ERR_DBG, "can be added, please enable ");
@@ -4824,7 +4836,7 @@ static void s2io_set_multicast(struct ne
val64 = RMAC_ADDR_CMD_MEM_WE |
RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD |
RMAC_ADDR_CMD_MEM_OFFSET
- (MAC_MC_ADDR_START_OFFSET + i);
+ (config->mc_start_offset + i);
writeq(val64, &bar0->rmac_addr_cmd_mem);
/* Wait for command completes */
@@ -4856,7 +4868,7 @@ static void s2io_set_multicast(struct ne
val64 = RMAC_ADDR_CMD_MEM_WE |
RMAC_ADDR_CMD_MEM_STROBE_NEW_CMD |
RMAC_ADDR_CMD_MEM_OFFSET
- (i + MAC_MC_ADDR_START_OFFSET);
+ (i + config->mc_start_offset);
writeq(val64, &bar0->rmac_addr_cmd_mem);
/* Wait for command completes */
@@ -4872,8 +4884,78 @@ static void s2io_set_multicast(struc
Re: [PATCH 2.6.24 1/1]S2io: Fixed memory leak by freeing MSI-X local entry memories when vector allocation fails
From: Sreenivasa Honnur <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 04:29:07 -0500 (EST) > - Fixed memory leak by freeing MSI-X local entry memories when vector > allocation > fails in s2io_add_isr. > - Added two utility functions remove_msix_isr and remove_inta_isr to eliminate > code duplication. > - Incorporated following review comments from Jeff > - Removed redundant stats->mem_freed and synchronize_irq call > - do_rem_msix_isr is renamed as remove_msix_isr > - do_rem_inta_isr is renamed as remove_inta_isr > > - (Resubmit third time) > > Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]> Applied to net-2.6, thanks! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix net-2.6.25 compiler error
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 10:52:53 +0100 > Fix a missed NF_IP6_LOCAL_OUT conversion. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied, my allmodconfig test build just hit this one too. Thanks again! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
From: Russell King <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 09:55:07 + > On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > > I've created [EMAIL PROTECTED] > > By doing so you've just said (implicitly) that you can not tolerate > someone having a different opinion from your own. I created a mailing list on a machine where I provide such services. People can choose to use or not use the new list, it is their choice. > While I accept *your* right to run *your* lists how you please, you > are unable to accept *my* right to run *my* lists how I see fit. I didn't tell you to take your list down or to run it in some other way. I didn't tell you to unsubscribe everyone and move them over to the new list either. I've provided an alternative, and people can pick and choose how they see fit. I'm letting natural selection run it's course. Are you able to cope with the fact that people might not want to use your list any longer? Perhaps that is what bugs you so much about my giving people a alternative choice. > So, when are you creating a replacement alsa-devel mailing list on > vger? That's also subscribers-only. The operative term is "alternative" rather than "replacement". Perhaps this misunderstanding is what you're so upset about. And yes, that alsa list bugs the crap out of me too. I'm more than happy to provide an alternative for that one as well. In fact, *poof*, there it is, [EMAIL PROTECTED] is there and available for anyone who wants to use it. Have a nice day Russell. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [IPSEC]: Add async resume support on input
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 14:36:58 +0800
> On Tue, Nov 13, 2007 at 10:33:56PM -0800, David Miller wrote:
> >
> > Also applied to net-2.6.25, thanks.
> >
> > I'll work on integrating Patrick's NF_INET_* patch next.
>
> Thanks! With that you would be able to remove the nf_post_routing
> field from xfrm_state_afinfo.
Done, and checked into net-2.6.25:
>From d15f51674f6e9985c84f221a7fd1026eafbe42c8 Mon Sep 17 00:00:00 2001
From: David S. Miller <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 01:57:47 -0800
Subject: [PATCH] [IPSEC]: Kill afinfo->nf_post_routing
After changeset:
[NETFILTER]: Introduce NF_INET_ hook values
It always evaluates to NF_INET_POST_ROUTING.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
---
include/net/xfrm.h |1 -
net/ipv4/xfrm4_state.c |1 -
net/ipv6/xfrm6_state.c |1 -
net/xfrm/xfrm_output.c |2 +-
4 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index e184c11..99251b7 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -259,7 +259,6 @@ struct xfrm_state_afinfo {
unsigned intfamily;
unsigned intproto;
unsigned inteth_proto;
- unsigned intnf_post_routing;
struct module *owner;
struct xfrm_type*type_map[IPPROTO_MAX];
struct xfrm_mode*mode_map[XFRM_MODE_MAX];
diff --git a/net/ipv4/xfrm4_state.c b/net/ipv4/xfrm4_state.c
index 2961135..fdeebe6 100644
--- a/net/ipv4/xfrm4_state.c
+++ b/net/ipv4/xfrm4_state.c
@@ -66,7 +66,6 @@ static struct xfrm_state_afinfo xfrm4_state_afinfo = {
.family = AF_INET,
.proto = IPPROTO_IPIP,
.eth_proto = htons(ETH_P_IP),
- .nf_post_routing= NF_INET_POST_ROUTING,
.owner = THIS_MODULE,
.init_flags = xfrm4_init_flags,
.init_tempsel = __xfrm4_init_tempsel,
diff --git a/net/ipv6/xfrm6_state.c b/net/ipv6/xfrm6_state.c
index 29e0d25..a7a7e8f 100644
--- a/net/ipv6/xfrm6_state.c
+++ b/net/ipv6/xfrm6_state.c
@@ -188,7 +188,6 @@ static struct xfrm_state_afinfo xfrm6_state_afinfo = {
.family = AF_INET6,
.proto = IPPROTO_IPV6,
.eth_proto = htons(ETH_P_IPV6),
- .nf_post_routing= NF_INET_POST_ROUTING,
.owner = THIS_MODULE,
.init_tempsel = __xfrm6_init_tempsel,
.tmpl_sort = __xfrm6_tmpl_sort,
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 048d240..3c277a4 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -113,7 +113,7 @@ int xfrm_output_resume(struct sk_buff *skb, int err)
return dst_output(skb);
err = nf_hook(x->inner_mode->afinfo->family,
- x->inner_mode->afinfo->nf_post_routing, skb,
+ NF_INET_POST_ROUTING, skb,
NULL, skb->dst->dev, xfrm_output2);
if (unlikely(err != 1))
goto out;
--
1.5.3.5
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] RFC3484 Configurable Policy Table.
From: YOSHIFUJI Hideaki / 吉藤英明 <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 16:37:28 +0900 (JST) > Please consider pulling from > inet6-2.6.25 > branch at > > which contains the following commits on top of your net-2.6.25 tree. ... > [IPV6] ADDRCONF: Rename ipv6_saddr_label() to ipv6_addr_label(). > [IPV6] ADDRCONF: Allow address selection policy with ifindex. > [IPV6] ADDRCONF: Support RFC3484 configurable address selection policy > table. Pulled and pushed back out to net-2.6.25, thanks a lot! - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] NET : move Qdisc_class_ops and Qdisc_ops in appropriate sections
From: Eric Dumazet <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 08:39:24 +0100 > [PATCH] NET : move Qdisc_class_ops and Qdisc_ops in appropriate sections > > Qdisc_class_ops are const, and Qdisc_ops are mostly read. > > Using "const" and "__read_mostly" qualifiers helps to reduce false sharing. > > Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]> Applied to net-2.6.25, thanks Eric. Keep up the good work. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
Kok, Auke wrote: Patrick McHardy wrote: Kok, Auke wrote: Patrick McHardy wrote: I already posted a patch for this, not sure what happened to it. Auke, any news on merging the secondary unicast address support? I dropped the ball on that one. Care to resend it and send me one for e1000e as well? Patch for e1000 attached. Does e1000e also work with PCI cards if I add the proper IDs? Otherwise I could only send an untested patch. no, e1000e will only work with pci-e adapters. The code however is largely the same, so if you can dish me out (off-list) some test cases I can have our labs do the testing and add this to our test repertoire. Actually that part of the code is quite different. I'm not sure I understand the entire intent behind the differences, why does it use a packed array of addresses instead of simply passing the netdev pointer to the callback? That would be necessary for secondary unicast support since we have to disable unicast filtering if either the address count exceeds the number of filter slots or the device is in promiscous mode. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore ethernet addresses
From: Sreenivasa Honnur <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 04:30:34 -0500 (EST) > - Support to add/delete/store/restore 64 and 128 Ethernet addresses for > Xframe I and Xframe II respectively. > > - (Resubmit third time) > > Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]> No, this is a feature patch, so I'm not going to queue this up for 2.6.24, that is not appropriate at all. Instead I've added this patch to netdev-2.6 which will schedule it for the 2.6.25 merge window. I had to remove the DRV_VERSION part of your changes as a result. Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipconfig.c : implement DHCP Class-identifier
> I don't think its very useful since you can simply get this information
> from /proc/cmdline in case something goes wrong, but if you insist at
> least give it a meaningful prefix.
Added.
> The initialization is unnecessary.
Removed.
> Should be >= I think.
Fixed.
Regards,
Rainer
--- net/ipv4/ipconfig.c.orig2007-11-14 09:16:15.800566536 +0100
+++ net/ipv4/ipconfig.c 2007-11-14 10:34:22.471219274 +0100
@@ -139,6 +139,8 @@ __be32 ic_servaddr = NONE; /* Boot serve
__be32 root_server_addr = NONE;/* Address of NFS server */
u8 root_server_path[256] = { 0, }; /* Path to mount as root */
+static char vendor_class_identifier[253]; /* vendor class identifier */
+
/* Persistent data: */
static int ic_proto_used; /* Protocol used, if any */
@@ -580,6 +582,7 @@ ic_dhcp_init_options(u8 *options)
u8 mt = ((ic_servaddr == NONE)
? DHCPDISCOVER : DHCPREQUEST);
u8 *e = options;
+ int len;
#ifdef IPCONFIG_DEBUG
printk("DHCP: Sending message type %d\n", mt);
@@ -620,6 +623,16 @@ ic_dhcp_init_options(u8 *options)
*e++ = sizeof(ic_req_params);
memcpy(e, ic_req_params, sizeof(ic_req_params));
e += sizeof(ic_req_params);
+
+ if (*vendor_class_identifier) {
+ printk(KERN_INFO "DHCP: sending class identifier
\"%s\"\n",
+ vendor_class_identifier);
+ *e++ = 60; /* Class-identifier */
+ len = strlen(vendor_class_identifier);
+ *e++ = len;
+ memcpy(e, vendor_class_identifier, len);
+ e += len;
+ }
}
*e++ = 255; /* End of the list */
@@ -1507,5 +1520,16 @@ static int __init nfsaddrs_config_setup(
return ip_auto_config_setup(addrs);
}
+static int __init vendor_class_identifier_setup(char *addrs)
+{
+ if (strlcpy(vendor_class_identifier, addrs,
+ sizeof(vendor_class_identifier))
+ >= sizeof(vendor_class_identifier))
+ printk(KERN_WARNING "DHCP: vendorclass too long, truncated to
\"%s\"",
+ vendor_class_identifier);
+ return 1;
+}
+
__setup("ip=", ip_auto_config_setup);
__setup("nfsaddrs=", nfsaddrs_config_setup);
+__setup("dhcpclass=", vendor_class_identifier_setup);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipconfig.c : implement DHCP Class-identifier
Rainer Jochem wrote: I don't think its very useful since you can simply get this information from /proc/cmdline in case something goes wrong, but if you insist at least give it a meaningful prefix. Added. The initialization is unnecessary. Removed. Should be >= I think. Fixed. Looks fine, thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fix net-2.6.25 compiler error
Fix a missed NF_IP6_LOCAL_OUT conversion.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
diff --git a/net/ipv6/netfilter/ip6t_REJECT.c b/net/ipv6/netfilter/ip6t_REJECT.c
index 201e251..960ba17 100644
--- a/net/ipv6/netfilter/ip6t_REJECT.c
+++ b/net/ipv6/netfilter/ip6t_REJECT.c
@@ -164,7 +164,7 @@ static void send_reset(struct sk_buff *oldskb)
static inline void
send_unreach(struct sk_buff *skb_in, unsigned char code, unsigned int hooknum)
{
- if (hooknum == NF_IP6_LOCAL_OUT && skb_in->dev == NULL)
+ if (hooknum == NF_INET_LOCAL_OUT && skb_in->dev == NULL)
skb_in->dev = init_net.loopback_dev;
icmpv6_send(skb_in, ICMPV6_DEST_UNREACH, code, 0, NULL);
Re: [BUG] New Kernel Bugs
On Tue, Nov 13, 2007 at 05:55:51PM -0800, David Miller wrote: > From: Andrew Morton <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 14:32:01 -0800 > > > On Tue, 13 Nov 2007 22:18:01 + Russell King <[EMAIL PROTECTED]> wrote: > > > > > Find some other mailing list; I'm not hosting *nor* am I willing to run a > > > non-subscribers only mailing list. Period. Not negotiable, so don't even > > > try to change my mind. > > > > Making a list subscribers-only will cause some bug reports to be lost. > > > > Tradeoffs are involved, against which decisions must be made. You have > > made yours. > > Russell doesn't have to worry any more, he doesn't have to > host it, and he doesn't have to be willing to run a > non-subscribers-only mailing list. > > Because I am. > > I've created [EMAIL PROTECTED] By doing so you've just said (implicitly) that you can not tolerate someone having a different opinion from your own. While I accept *your* right to run *your* lists how you please, you are unable to accept *my* right to run *my* lists how I see fit. Time will tell which lists will survive. Whatever, I suspect that by doing what you've just done, you're going to create more confusion and problems. Instead of having one focused place for discussions and bug reports, they're going to be spread more thinly, meaning less people looking at such things, meaning more bugs get ignored. Thus making the issue worse. So, when are you creating a replacement alsa-devel mailing list on vger? That's also subscribers-only. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Wednesday 14 November 2007 17:37, David Miller wrote: > From: Nick Piggin <[EMAIL PROTECTED]> > > I'm doing some oprofile runs now to see if I can get any more info. OK, in vanilla kernels, the page allocator definitely shows higher in the results (than with Herbert's patch reverted). 27516 2.7217 get_page_from_freelist 21677 2.1442 __rmqueue_smallest 20513 2.0290 __free_pages_ok 18725 1.8522 get_pageblock_flags_group Just these account for nearly 10% of cycles. __alloc_skb shows up higher too. free_hot_cold_page() shows a lot lower though, which might indicate that actually there is more higher order allocation activity (I'll check that next). SLUB, avg throughput 1548 CPU: AMD64 family10, speed 1900 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 samples %symbol name 94636 9.3609 copy_user_generic_string 38932 3.8509 ipt_do_table 34746 3.4369 tcp_v4_rcv 29539 2.9218 skb_release_data 27516 2.7217 get_page_from_freelist 26046 2.5763 tcp_sendmsg 24482 2.4216 local_bh_enable 22910 2.2661 ip_queue_xmit 22113 2.1873 ktime_get 21677 2.1442 __rmqueue_smallest 20513 2.0290 __free_pages_ok 18725 1.8522 get_pageblock_flags_group 18580 1.8378 tcp_recvmsg 18108 1.7911 __napi_schedule 17593 1.7402 schedule 16998 1.6813 tcp_ack 16102 1.5927 dev_hard_start_xmit 15751 1.5580 system_call 15707 1.5536 net_rx_action 15150 1.4986 __switch_to 14988 1.4825 tcp_transmit_skb 13921 1.3770 kmem_cache_free 13398 1.3253 __mod_timer 13243 1.3099 tcp_rcv_established 13109 1.2967 __tcp_select_window 11022 1.0902 __tcp_push_pending_frames 10732 1.0615 set_normalized_timespec 10561 1.0446 netif_rx 8840 0.8744 netif_receive_skb 7816 0.7731 nf_iterate 7300 0.7221 __update_rq_clock 6683 0.6610 _read_lock_bh 6504 0.6433 sys_recvfrom 6283 0.6215 nf_hook_slow 6188 0.6121 release_sock 6172 0.6105 loopback_xmit 5927 0.5863 __alloc_skb 5707 0.5645 tcp_cleanup_rbuf 5538 0.5478 tcp_event_data_recv 5517 0.5457 tcp_v4_do_rcv 5516 0.5456 process_backlog SLUB, net patch reverted. Avg throughput 1933MB/s Counted CPU_CLK_UNHALTED , count 10 samples %symbol name 95895 9.5094 copy_user_generic_string 50259 4.9839 ipt_do_table 39408 3.9079 skb_release_data 37296 3.6984 tcp_v4_rcv 31309 3.1047 ip_queue_xmit 31308 3.1046 local_bh_enable 24052 2.3851 net_rx_action 23786 2.3587 __napi_schedule 21426 2.1247 tcp_recvmsg 21075 2.0899 schedule 20938 2.0763 dev_hard_start_xmit 20222 2.0053 tcp_sendmsg 19775 1.9610 tcp_ack 19717 1.9552 system_call 19495 1.9332 set_normalized_timespec 18584 1.8429 __switch_to 17022 1.6880 tcp_rcv_established 14655 1.4533 tcp_transmit_skb 14466 1.4345 __mod_timer 13820 1.3705 loopback_xmit 13776 1.3661 get_page_from_freelist 13288 1.3177 netif_receive_skb 9718 0.9637 _read_lock_bh 9625 0.9545 nf_iterate 9440 0.9361 netif_rx 9148 0.9072 free_hot_cold_page 8633 0.8561 __update_rq_clock 7668 0.7604 sys_recvfrom 7578 0.7515 __tcp_push_pending_frames 7311 0.7250 find_pid_ns 7178 0.7118 nf_hook_slow 6655 0.6599 sysret_check 6313 0.6260 release_sock 6290 0.6237 tcp_cleanup_rbuf 6263 0.6211 __tcp_select_window 6235 0.6183 process_backlog 5920 0.5871 ip_local_deliver_finish 5651 0.5604 ip_rcv 5239 0.5195 ip_finish_output 5058 0.5016 kmem_cache_free 5016 0.4974 thread_return > Here are some other things you can play around with: > > 1) Monitor the values of skb->len and skb->data_len for packets >going over loopback. OK, I've taken a log2 histogram of ->len and ->data_len sizes. I'll attach the plots (xaxis is byte value of most significant bit set, y axis is number of occurances, logscale on X so 0 isn't there :( ). If you want to see the patch or raw data, let me know. len looks very similar for both kernels, although the reverted kernel has significantly higher frequency at most points. tbench unfortunately is only possible to do it time-based, so this is rougly expected. data_len has a spike that shifts up to 512-1023, from 256-511, when reverting Herbert's patch. Again, I believe the magnitudes of the spikes should actually be pretty close if we were doing an equal amount of work. I can't see that these numbers show much useful, unfortunately. > 2) Try removing NETIF_F_SG in drivers/net/loopback.c's dev->feastures >setting. Will try that now. <><>
Re: [PATCH 2/2] [IPSEC]: Add async resume support on input
On Wed, Nov 14, 2007 at 01:58:12AM -0800, David Miller wrote:
>
> >From d15f51674f6e9985c84f221a7fd1026eafbe42c8 Mon Sep 17 00:00:00 2001
> From: David S. Miller <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 01:57:47 -0800
> Subject: [PATCH] [IPSEC]: Kill afinfo->nf_post_routing
>
> After changeset:
>
> [NETFILTER]: Introduce NF_INET_ hook values
>
> It always evaluates to NF_INET_POST_ROUTING.
>
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
Thank you!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [NFS] [PATCH 00/25] RFC: AF_INET6 family support for the NFS client
On Tue, Nov 13, 2007 at 01:30:59PM -0500, Chuck Lever wrote: > These 25 patches add support for AF_INET6 addresses to the NFS client. > This is a request for review of the proposed changes. > > This series does not add support for AF_INET6 addresses to the Linux > NLM or NSM implementations, nor does it add support in the NFS server. This is awesome. I can't wait for the server support :-) /* Steinar */ -- Homepage: http://www.sesse.net/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipconfig.c : implement DHCP Class-identifier
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 10:48:43 +0100 > Rainer Jochem wrote: > > > >> I don't think its very useful since you can simply get this information > >> from /proc/cmdline in case something goes wrong, but if you insist at > >> least give it a meaningful prefix. > > > > Added. > > > >> The initialization is unnecessary. > > > > Removed. > > > >> Should be >= I think. > > > > Fixed. > > Looks fine, thanks. Applied to net-2.6.25, thanks everyone. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug in using inet_lookup ()
On Wed, Nov 14, 2007 at 09:26:18AM +, Nj A ([EMAIL PROTECTED]) wrote:
> /* The kernel TCP hashtable */
> struct inet_hashinfo __cacheline_aligned tcp_hashinfo = {
> .lhash_lock = __RW_LOCK_UNLOCKED (tcp_hashinfo.lhash_lock),
> .lhash_users = ATOMIC_INIT (0),
> .lhash_wait = __WAIT_QUEUE_HEAD_INITIALIZER (tcp_hashinfo.lhash_wait),
> };
> ...
> struct sock *sk;
> struct sk_buff *skb;
> skb = alloc_skb (MAX_TCP_HEADER + 15, GFP_KERNEL);
> if (skb == NULL)
> printk ("%s: Unable to allocate memory \n", __FUNCTION__);
> sk = inet_lookup (&tcp_hashinfo, ip_src, src_port, ip_dst, dst_port, inet_iif
> (skb));
> if (!sk)
> ...
> This portion of code seems to cause the kernel to panic due to dereferencing
> a NULL pointer.
> Can anyone please tell me what is the error above?
> Best Regards,
Where exactly? Likely in inet_iif(), since it dereferences dst (routing
info), which is not presented after simple alloc_skb().
You have to setup skb correctly, check how ip_rcv() does it.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
From: Nick Piggin <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 09:27:39 +1100
> OK, in vanilla kernels, the page allocator definitely shows higher
> in the results (than with Herbert's patch reverted).
...
> I can't see that these numbers show much useful, unfortunately.
Thanks for all of this data Nick.
So the thing that's being effected here in TCP is
net/ipv4/tcp.c:select_size(), specifically the else branch:
int tmp = tp->mss_cache;
...
else {
int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER);
if (tmp >= pgbreak &&
tmp <= pgbreak + (MAX_SKB_FRAGS - 1) * PAGE_SIZE)
tmp = pgbreak;
}
This is deciding, in 'tmp', how much linear sk_buff space to
allocate. 'tmp' is initially set to the path MSS, which
for loopback is 16K - the space necessary for packet headers.
The SKB_MAX_HEAD() value has changed as a result of Herbert's
bug fix. I suspect this 'if' test is passing both with and
without the patch.
But pgbreak is now smaller, and thus the skb->data linear
data area size we choose to use is smaller as well.
You can test if this is precisely what is causing the performance
regression by using the old calculation just here in select_size().
Add something like this local to net/ipv4/tcp.c:
#define OLD_SKB_WITH_OVERHEAD(X)\
(((X) - sizeof(struct skb_shared_info)) & \
~(SMP_CACHE_BYTES - 1))
#define OLD_SKB_MAX_ORDER(X, ORDER) \
OLD_SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
#define OLD_SKB_MAX_HEAD(X) (OLD_SKB_MAX_ORDER((X), 0))
And then use OLD_SKB_MAX_HEAD() in select_size().
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Wednesday 14 November 2007 09:27, Nick Piggin wrote: > > 2) Try removing NETIF_F_SG in drivers/net/loopback.c's dev->feastures > >setting. > > Will try that now. Doesn't help (with vanilla kernel -- Herbert's patch applied). data_len histogram drops to 0 and goes to len (I guess that's not surprising). Performance is pretty similar (ie. not good). I'll look at allocator patterns next. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Wednesday 14 November 2007 22:10, David Miller wrote:
> From: Nick Piggin <[EMAIL PROTECTED]>
> Date: Wed, 14 Nov 2007 09:27:39 +1100
>
> > OK, in vanilla kernels, the page allocator definitely shows higher
> > in the results (than with Herbert's patch reverted).
>
> ...
>
> > I can't see that these numbers show much useful, unfortunately.
>
> Thanks for all of this data Nick.
>
> So the thing that's being effected here in TCP is
> net/ipv4/tcp.c:select_size(), specifically the else branch:
>
> int tmp = tp->mss_cache;
> ...
> else {
> int pgbreak = SKB_MAX_HEAD(MAX_TCP_HEADER);
>
> if (tmp >= pgbreak &&
> tmp <= pgbreak + (MAX_SKB_FRAGS - 1) * PAGE_SIZE)
> tmp = pgbreak;
> }
>
> This is deciding, in 'tmp', how much linear sk_buff space to
> allocate. 'tmp' is initially set to the path MSS, which
> for loopback is 16K - the space necessary for packet headers.
>
> The SKB_MAX_HEAD() value has changed as a result of Herbert's
> bug fix. I suspect this 'if' test is passing both with and
> without the patch.
>
> But pgbreak is now smaller, and thus the skb->data linear
> data area size we choose to use is smaller as well.
OK, that makes sense. BTW, are you taking advantage of kmalloc's
"quantization" into slabs WRT the linear data area? I wonder if
it would be at all useful...
> You can test if this is precisely what is causing the performance
> regression by using the old calculation just here in select_size().
>
> Add something like this local to net/ipv4/tcp.c:
>
> #define OLD_SKB_WITH_OVERHEAD(X) \
> (((X) - sizeof(struct skb_shared_info)) & \
>~(SMP_CACHE_BYTES - 1))
> #define OLD_SKB_MAX_ORDER(X, ORDER) \
> OLD_SKB_WITH_OVERHEAD((PAGE_SIZE << (ORDER)) - (X))
> #define OLD_SKB_MAX_HEAD(X) (OLD_SKB_MAX_ORDER((X), 0))
>
> And then use OLD_SKB_MAX_HEAD() in select_size().
That brings performance back up!
I wonder why it isn't causing a problem for SLAB...
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode
> "AK" == Kok, Auke <[EMAIL PROTECTED]> writes: AK> actually the impact can be quite negative, imagine doing a tcpdump AK> on a 10gig interface with vlan's enabled - all of a sudden you AK> might accidentally flood the system with a 100-fold increase in AK> traffic and force the stack to dump all those packets for you. Why is the switch sending you all that traffic for VLAN's you don't care about? I have a hard time imagining such a scenario. Sure, you could have forgotten to limit the VLAN range sent to a particular host, or even have decided that it's administratively easier to just allow everything, but the switch still won't send unicast traffic out that port unless the destination MAC matches. If broadcast or non-solicited multicast takes up most of your bandwidth, you have other problems. /Benny - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Wed, Nov 14, 2007 at 03:10:22AM -0800, David Miller wrote:
>
> So the thing that's being effected here in TCP is
> net/ipv4/tcp.c:select_size(), specifically the else branch:
Thanks for the pointer. Indeed there is a bug in that area.
I'm not sure whether it's causing the problem at hand but it's
certainly suboptimal.
[TCP]: Fix size calculation in sk_stream_alloc_pskb
We round up the header size in sk_stream_alloc_pskb so that
TSO packets get zero tail room. Unfortunately this rounding
up is not coordinated with the select_size() function used by
TCP to calculate the second parameter of sk_stream_alloc_pskb.
As a result, we may allocate more than a page of data in the
non-TSO case when exactly one page is desired.
In fact, rounding up the head room is detrimental in the non-TSO
case because it makes memory that would otherwise be available to
the payload head room. TSO doesn't need this either, all it wants
is the guarantee that there is no tail room.
So this patch fixes this by adjusting the skb_reserve call so that
exactly the requested amount (which all callers have calculated in
a precise way) is made available as tail room.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/include/net/sock.h b/include/net/sock.h
index 5504fb9..567e468 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1235,14 +1235,16 @@ static inline struct sk_buff
*sk_stream_alloc_pskb(struct sock *sk,
gfp_t gfp)
{
struct sk_buff *skb;
- int hdr_len;
- hdr_len = SKB_DATA_ALIGN(sk->sk_prot->max_header);
- skb = alloc_skb_fclone(size + hdr_len, gfp);
+ skb = alloc_skb_fclone(size + sk->sk_prot->max_header, gfp);
if (skb) {
skb->truesize += mem;
if (sk_stream_wmem_schedule(sk, skb->truesize)) {
- skb_reserve(skb, hdr_len);
+ /*
+* Make sure that we have exactly size bytes
+* available to the caller, no more, no less.
+*/
+ skb_reserve(skb, skb_tailroom(skb) - size);
return skb;
}
__kfree_skb(skb);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] powerpc: Fix fs_enet module build
Hi David, > This is truly ugly and creates an unnecessarily hard to > maintain and complex driver. > > Please find a way to fix this for real, so that the > PPC_CPM_NEW_BINDING ifdef is not necessary at all and > things get built modular or not naturally as we handle > things for other cases like this. I know it's ugly, however, module building is completely broken right now and I just want to provide a quick and ugly fix until both that ppc->powerpc transition and the new binding transition are over. Noone wants to touch the old stuff any more as it's a pita and it's already scheduled for removal in a couple of months. Thanks, Jochen - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 14-11-07 11:07, David Miller wrote: Added Jaroslav and Takashi to the already extensive CC From: Russell King <[EMAIL PROTECTED]> So, when are you creating a replacement alsa-devel mailing list on vger? That's also subscribers-only. The operative term is "alternative" rather than "replacement". Perhaps this misunderstanding is what you're so upset about. And yes, that alsa list bugs the crap out of me too. I'm more than happy to provide an alternative for that one as well. [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, it's _moderated_ for non-subscribers and given that I and other moderators have been doing our best to moderate quickly (I tend to stay logged in to the moderation interface all day for example) what specifically bugged the crap out of you? It's not something a poster needs to concern himself with. Also for alsa-devel the moderators tend to add any valid non-subcribers to a whitelist after landing in the queue the first time meaning even a delay is just a one-time thing normally. So what's the trouble? Basically, noone need even notice... In fact, *poof*, there it is, [EMAIL PROTECTED] is there and available for anyone who wants to use it. Not that I think that moving alsa-devel over to vger wouldn't be a good idea mind you; when the list moved from sourceforge, asking you to host it was my preferred option. I do somewhat suspect that Jaroslav would like to keep the alsa-devel@ name (and I'd like to ask you to then also host alsa-user@) and would then rewrite mail to those lists @alsa-project.org to vger. But what is the problem you speak of with the alsa-devel list? While I would not mind loosing it, moderation hasn't been overly laborious and I'm not aware of any serious problems. Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Remove notifier block from chain when register_netdevice_notifier fails
Commit fcc5a03ac42564e9e255c1134dda47442289e466 makes the register_netdevice_notifier() handle the error from the NETDEV_REGISTER event, sent to the registering block. The bad news is that in this case the notifier block is not removed from the list, but the error is returned to the caller. In case the caller is in module init function and handles this error this can abort the module loading. The notifier block will be then removed from the kernel, but will be left in the list. Oops :( I think that the notifier block should be removed from the chain in case of error, regardless whether this error is handled by the caller or not. In the worst case (the error is _not_ handled) module will not receive the events any longer. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/net/core/dev.c b/net/core/dev.c index dd40b35..86d6261 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -1171,6 +1171,8 @@ rollback: nb->notifier_call(nb, NETDEV_UNREGISTER, dev); } } + + raw_notifier_chain_unregister(&netdev_chain, nb); goto unlock; } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
From: Nick Piggin <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 11:02:11 +1100 > On Wednesday 14 November 2007 22:48, Herbert Xu wrote: > > On Wed, Nov 14, 2007 at 03:10:22AM -0800, David Miller wrote: > > > So the thing that's being effected here in TCP is > > > net/ipv4/tcp.c:select_size(), specifically the else branch: > > > > Thanks for the pointer. Indeed there is a bug in that area. > > I'm not sure whether it's causing the problem at hand but it's > > certainly suboptimal. > > > > [TCP]: Fix size calculation in sk_stream_alloc_pskb > > This looks like it fixes the problem! Great, thanks for testing. I'll apply Herbert's patch tomorrow as I've already sent Linus a bug fix pull request tonight. > Still interested to know why SLAB didn't see the same thing... Yes, I wonder why too. I bet objects just got packed differently. There is this fugly "LOOPBACK_OVERHEAD" macro define in drivers/net/loopback.c that is trying to figure out the various overheads that we should subtract from the loopback MTU we use by default. It's almost guarenteed to be wrong for the way the allocators work now. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
From: Rene Herman <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 12:46:24 +0100 > [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, > it's _moderated_ for non-subscribers and given that I and other moderators > have been doing our best to moderate quickly (I tend to stay logged in to > the moderation interface all day for example) what specifically bugged the > crap out of you? It's not something a poster needs to concern himself with. The fact that it farts at me every time I post to this thread. That's rude and annoying. > Also for alsa-devel the moderators tend to add any valid non-subcribers to > a whitelist after landing in the queue the first time meaning even a delay > is just a one-time thing normally. So what's the trouble? Basically, noone > need even notice... That sucks for new people taking part in the conversation. There is no reason for moderation at all, it isn't necessary for spam prevention and it does nothing but annoy new posters and make work for the moderator. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
From: David Miller <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) > The fact that it farts at me every time I post to this thread. See? I got another one and I have received at least 10 of the following over the past 2 days. That's rediculious. And because a human adds the whitelist this is always going to happen to someone when they start posting to the alsa list for the first time. /me gets ready for the 11th copy in response to this one... Subject: Your message to Alsa-devel awaits moderator approval From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Wed, 14 Nov 2007 12:57:06 +0100 Sender: [EMAIL PROTECTED] Your mail to 'Alsa-devel' with the subject Re: [alsa-devel] [BUG] New Kernel Bugs Is being held until the list moderator can review it for approval. The reason it is being held: Too many recipients to the message Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://mailman.alsa-project.org/mailman/confirm/alsa-devel/12dd3bd077bbf9cd142f214beae6d22ae43b53aa - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench
On Wednesday 14 November 2007 22:48, Herbert Xu wrote: > On Wed, Nov 14, 2007 at 03:10:22AM -0800, David Miller wrote: > > So the thing that's being effected here in TCP is > > net/ipv4/tcp.c:select_size(), specifically the else branch: > > Thanks for the pointer. Indeed there is a bug in that area. > I'm not sure whether it's causing the problem at hand but it's > certainly suboptimal. > > [TCP]: Fix size calculation in sk_stream_alloc_pskb This looks like it fixes the problem! Still interested to know why SLAB didn't see the same thing... > We round up the header size in sk_stream_alloc_pskb so that > TSO packets get zero tail room. Unfortunately this rounding > up is not coordinated with the select_size() function used by > TCP to calculate the second parameter of sk_stream_alloc_pskb. > > As a result, we may allocate more than a page of data in the > non-TSO case when exactly one page is desired. > > In fact, rounding up the head room is detrimental in the non-TSO > case because it makes memory that would otherwise be available to > the payload head room. TSO doesn't need this either, all it wants > is the guarantee that there is no tail room. > > So this patch fixes this by adjusting the skb_reserve call so that > exactly the requested amount (which all callers have calculated in > a precise way) is made available as tail room. > > Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> > > Cheers, - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] CAN: Add maintainer entries
This patch adds entries in the CREDITS and MAINTAINERS file for CAN. Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]> --- CREDITS | 16 MAINTAINERS |9 + 2 files changed, 25 insertions(+) Index: net-2.6.25/CREDITS === --- net-2.6.25.orig/CREDITS 2007-11-14 13:04:23.0 +0100 +++ net-2.6.25/CREDITS 2007-11-14 13:04:55.0 +0100 @@ -1353,6 +1353,14 @@ S: 5623 HZ Eindhoven S: The Netherlands +N: Oliver Hartkopp +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Andrew Haylett E: [EMAIL PROTECTED] D: Selection mechanism @@ -3306,6 +3314,14 @@ S: F-35042 Rennes Cedex S: France +N: Urs Thuermann +E: [EMAIL PROTECTED] +W: http://www.volkswagen.de +D: Controller Area Network (network layer core) +S: Brieffach 1776 +S: 38436 Wolfsburg +S: Germany + N: Jon Tombs E: [EMAIL PROTECTED] W: http://www.esi.us.es/~jon Index: net-2.6.25/MAINTAINERS === --- net-2.6.25.orig/MAINTAINERS 2007-11-14 13:04:23.0 +0100 +++ net-2.6.25/MAINTAINERS 2007-11-14 13:04:56.0 +0100 @@ -981,6 +981,15 @@ L: [EMAIL PROTECTED] S: Maintained +CAN NETWORK LAYER +P: Urs Thuermann +M: [EMAIL PROTECTED] +P: Oliver Hartkopp +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://developer.berlios.de/projects/socketcan/ +S: Maintained + CALGARY x86-64 IOMMU P: Muli Ben-Yehuda M: [EMAIL PROTECTED] -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] CAN: Add documentation
This patch adds documentation for the PF_CAN protocol family. Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]> --- Documentation/networking/00-INDEX |2 Documentation/networking/can.txt | 637 ++ 2 files changed, 639 insertions(+) Index: net-2.6.25/Documentation/networking/can.txt === --- /dev/null 1970-01-01 00:00:00.0 + +++ net-2.6.25/Documentation/networking/can.txt 2007-11-14 13:04:57.0 +0100 @@ -0,0 +1,637 @@ + + +can.txt + +Readme file for the Controller Area Network Protocol Family (aka Socket CAN) + +This file contains + + 1 Overview / What is Socket CAN + + 2 Motivation / Why using the socket API + + 3 Socket CAN concept +3.1 receive lists +3.2 local loopback of sent frames +3.3 network security issues (capabilities) +3.4 network problem notifications + + 4 How to use Socket CAN +4.1 RAW protocol sockets with can_filters (SOCK_RAW) + 4.1.1 RAW socket option CAN_RAW_FILTER + 4.1.2 RAW socket option CAN_RAW_ERR_FILTER + 4.1.3 RAW socket option CAN_RAW_LOOPBACK + 4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS +4.2 Broadcast Manager protocol sockets (SOCK_DGRAM) +4.3 connected transport protocols (SOCK_SEQPACKET) +4.4 unconnected transport protocols (SOCK_DGRAM) + + 5 Socket CAN core module +5.1 can.ko module params +5.2 procfs content +5.3 writing own CAN protocol modules + + 6 CAN network drivers +6.1 general settings +6.2 local loopback of sent frames +6.3 CAN controller hardware filters +6.4 currently supported CAN hardware +6.5 todo + + 7 Credits + + + +1. Overview / What is Socket CAN + + +The socketcan package is an implementation of CAN protocols +(Controller Area Network) for Linux. CAN is a networking technology +which has widespread use in automation, embedded devices, and +automotive fields. While there have been other CAN implementations +for Linux based on character devices, Socket CAN uses the Berkeley +socket API, the Linux network stack and implements the CAN device +drivers as network interfaces. The CAN socket API has been designed +as similar as possible to the TCP/IP protocols to allow programmers, +familiar with network programming, to easily learn how to use CAN +sockets. + +2. Motivation / Why using the socket API + + +There have been CAN implementations for Linux before Socket CAN so the +question arises, why we have started another project. Most existing +implementations come as a device driver for some CAN hardware, they +are based on character devices and provide comparatively little +functionality. Usually, there is only a hardware-specific device +driver which provides a character device interface to send and +receive raw CAN frames, directly to/from the controller hardware. +Queueing of frames and higher-level transport protocols like ISO-TP +have to be implemented in user space applications. Also, most +character-device implementations support only one single process to +open the device at a time, similar to a serial interface. Exchanging +the CAN controller requires employment of another device driver and +often the need for adaption of large parts of the application to the +new driver's API. + +Socket CAN was designed to overcome all of these limitations. A new +protocol family has been implemented which provides a socket interface +to user space applications and which builds upon the Linux network +layer, so to use all of the provided queueing functionality. A device +driver for CAN controller hardware registers itself with the Linux +network layer as a network device, so that CAN frames from the +controller can be passed up to the network layer and on to the CAN +protocol family module and also vice-versa. Also, the protocol family +module provides an API for transport protocol modules to register, so +that any number of transport protocols can be loaded or unloaded +dynamically. In fact, the can core module alone does not provide any +protocol and cannot be used without loading at least one additional +protocol module. Multiple sockets can be opened at the same time, +on different or the same protocol module and they can listen/send +frames on different or the same CAN IDs. Several sockets listening on +the same interface for frames with the same CAN ID are all passed the +same received matching CAN frames. An application wishing to +communicate using a specific transport protocol, e.g. ISO-TP, just +selects that protocol when opening the socket, and then can read and +write application data byte streams, without having to deal with +CAN-IDs, frames, etc. + +Sim
[PATCH 4/7] CAN: Add broadcast manager (bcm) protocol
This patch adds the CAN broadcast manager (bcm) protocol.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/bcm.h | 65 +
net/can/Kconfig | 13
net/can/Makefile|3
net/can/bcm.c | 1763
4 files changed, 1844 insertions(+)
Index: net-2.6.25/include/linux/can/bcm.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/include/linux/can/bcm.h 2007-11-14 13:04:52.0 +0100
@@ -0,0 +1,65 @@
+/*
+ * linux/can/bcm.h
+ *
+ * Definitions for CAN Broadcast Manager (BCM)
+ *
+ * Author: Oliver Hartkopp <[EMAIL PROTECTED]>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef CAN_BCM_H
+#define CAN_BCM_H
+
+/**
+ * struct bcm_msg_head - head of messages to/from the broadcast manager
+ * @opcode:opcode, see enum below.
+ * @flags: special flags, see below.
+ * @count: number of frames to send before changing interval.
+ * @ival1: interval for the first @count frames.
+ * @ival2: interval for the following frames.
+ * @can_id:CAN ID of frames to be sent or received.
+ * @nframes: number of frames appended to the message head.
+ * @frames:array of CAN frames.
+ */
+struct bcm_msg_head {
+ int opcode;
+ int flags;
+ int count;
+ struct timeval ival1, ival2;
+ canid_t can_id;
+ int nframes;
+ struct can_frame frames[0];
+};
+
+enum {
+ TX_SETUP = 1, /* create (cyclic) transmission task */
+ TX_DELETE, /* remove (cyclic) transmission task */
+ TX_READ,/* read properties of (cyclic) transmission task */
+ TX_SEND,/* send one CAN frame */
+ RX_SETUP, /* create RX content filter subscription */
+ RX_DELETE, /* remove RX content filter subscription */
+ RX_READ,/* read properties of RX content filter subscription */
+ TX_STATUS, /* reply to TX_READ request */
+ TX_EXPIRED, /* notification on performed transmissions (count=0) */
+ RX_STATUS, /* reply to RX_READ request */
+ RX_TIMEOUT, /* cyclic message is absent */
+ RX_CHANGED /* updated CAN frame (detected content change) */
+};
+
+#define SETTIMER0x0001
+#define STARTTIMER 0x0002
+#define TX_COUNTEVT 0x0004
+#define TX_ANNOUNCE 0x0008
+#define TX_CP_CAN_ID0x0010
+#define RX_FILTER_ID0x0020
+#define RX_CHECK_DLC0x0040
+#define RX_NO_AUTOTIMER 0x0080
+#define RX_ANNOUNCE_RESUME 0x0100
+#define TX_RESET_MULTI_IDX 0x0200
+#define RX_RTR_FRAME0x0400
+
+#endif /* CAN_BCM_H */
Index: net-2.6.25/net/can/Kconfig
===
--- net-2.6.25.orig/net/can/Kconfig 2007-11-14 13:04:51.0 +0100
+++ net-2.6.25/net/can/Kconfig 2007-11-14 13:04:52.0 +0100
@@ -27,6 +27,19 @@
socket has several filter options e.g. ID masking / error frames.
To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
+config CAN_BCM
+ tristate "Broadcast Manager CAN Protocol (with content filtering)"
+ depends on CAN
+ default N
+ ---help---
+ The Broadcast Manager offers content filtering, timeout monitoring,
+ sending of RTR frames, and cyclic CAN messages without permanent user
+ interaction. The BCM can be 'programmed' via the BSD socket API and
+ informs you on demand e.g. only on content updates / timeouts.
+ You probably want to use the bcm socket in most cases where cyclic
+ CAN messages are used on the bus (e.g. in automotive environments).
+ To use the Broadcast Manager, use AF_CAN with protocol CAN_BCM.
+
config CAN_DEBUG_CORE
bool "CAN Core debugging messages"
depends on CAN
Index: net-2.6.25/net/can/Makefile
===
--- net-2.6.25.orig/net/can/Makefile2007-11-14 13:04:51.0 +0100
+++ net-2.6.25/net/can/Makefile 2007-11-14 13:04:52.0 +0100
@@ -7,3 +7,6 @@
obj-$(CONFIG_CAN_RAW) += can-raw.o
can-raw-objs := raw.o
+
+obj-$(CONFIG_CAN_BCM) += can-bcm.o
+can-bcm-objs := bcm.o
Index: net-2.6.25/net/can/bcm.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/net/can/bcm.c2007-11-14 13:04:52.0 +0100
@@ -0,0 +1,1763 @@
+/*
+ * bcm.c - Broadcast Manager to filter/send (cyclic) CAN content
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provid
Re: Moderated list (Was: Re: [BUG] New Kernel Bugs)
On 14-11-07 09:25, Takashi Iwai wrote:
At Wed, 14 Nov 2007 04:01:31 -0800 (PST),
David Miller wrote:
From: David Miller <[EMAIL PROTECTED]>
Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
The fact that it farts at me every time I post to this thread.
See? I got another one and I have received at least 10 of the
following over the past 2 days.
That's rediculious.
And because a human adds the whitelist this is always going to
happen to someone when they start posting to the alsa list for
the first time.
... if you give too many recipients in your post. That is often
really annoying thing to me, together with keeping the unrelated
subject line ;)
I personally don't care whether it's a moderated or open list.
We chose it simply due to too bad S/N ratio at that time. So, if the
current list annoys your or many others and the list management on
vger is so good, it'd be basically a good move, of course. I'll
appreciate it.
The only confusion would be the change of ML address, but we can do it
slowly, too.
I'd love the lists at vger. Amazing spam-filtering. I'd like to request the
name [EMAIL PROTECTED] (and [EMAIL PROTECTED] if at all
possible so we can open that one up as well) though.
There wouldn't need to be a forced ML address change if Jaroslov would then
just rewrite alsa-{devel,[EMAIL PROTECTED] to vger.kernel.org same as
he did for alsa-devel and does for alsa-user to @lists.sf.net.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] CAN: Add virtual CAN netdevice driver
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>
---
drivers/net/Makefile |1
drivers/net/can/Kconfig | 25 +
drivers/net/can/Makefile |5 +
drivers/net/can/vcan.c | 207 +++
net/can/Kconfig |3
5 files changed, 241 insertions(+)
Index: net-2.6.25/drivers/net/Makefile
===
--- net-2.6.25.orig/drivers/net/Makefile2007-11-14 13:04:24.0
+0100
+++ net-2.6.25/drivers/net/Makefile 2007-11-14 13:04:54.0 +0100
@@ -12,6 +12,7 @@
obj-$(CONFIG_CHELSIO_T1) += chelsio/
obj-$(CONFIG_CHELSIO_T3) += cxgb3/
obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
obj-$(CONFIG_BONDING) += bonding/
obj-$(CONFIG_ATL1) += atl1/
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.25/drivers/net/can/Kconfig
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/drivers/net/can/Kconfig 2007-11-14 13:04:54.0 +0100
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+ depends on CAN
+
+config CAN_VCAN
+ tristate "Virtual Local CAN Interface (vcan)"
+ depends on CAN
+ default N
+ ---help---
+ Similar to the network loopback devices, vcan offers a
+ virtual local CAN interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called vcan.
+
+config CAN_DEBUG_DEVICES
+ bool "CAN devices debugging messages"
+ depends on CAN
+ default N
+ ---help---
+ Say Y here if you want the CAN device drivers to produce a bunch of
+ debug messages to the system log. Select this if you are having
+ a problem with CAN support and want to see more of what is going
+ on.
+
+endmenu
Index: net-2.6.25/drivers/net/can/Makefile
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/drivers/net/can/Makefile 2007-11-14 13:04:54.0 +0100
@@ -0,0 +1,5 @@
+#
+# Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN) += vcan.o
Index: net-2.6.25/drivers/net/can/vcan.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/drivers/net/can/vcan.c 2007-11-14 13:04:54.0 +0100
@@ -0,0 +1,207 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static __initdata const char banner[] =
+ KERN_INFO "vcan: Virtual CAN interface driver\n"
[PATCH 3/7] CAN: Add raw protocol
This patch adds the CAN raw protocol.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>
---
include/linux/can/raw.h | 31 +
net/can/Kconfig | 11
net/can/Makefile|3
net/can/raw.c | 811
4 files changed, 856 insertions(+)
Index: net-2.6.25/include/linux/can/raw.h
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/include/linux/can/raw.h 2007-11-14 13:04:51.0 +0100
@@ -0,0 +1,31 @@
+/*
+ * linux/can/raw.h
+ *
+ * Definitions for raw CAN sockets
+ *
+ * Authors: Oliver Hartkopp <[EMAIL PROTECTED]>
+ * Urs Thuermann <[EMAIL PROTECTED]>
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Send feedback to <[EMAIL PROTECTED]>
+ *
+ */
+
+#ifndef CAN_RAW_H
+#define CAN_RAW_H
+
+#include
+
+#define SOL_CAN_RAW (SOL_CAN_BASE + CAN_RAW)
+
+/* for socket options affecting the socket (not the global system) */
+
+enum {
+ CAN_RAW_FILTER = 1, /* set 0 .. n can_filter(s) */
+ CAN_RAW_ERR_FILTER, /* set filter for error frames */
+ CAN_RAW_LOOPBACK, /* local loopback (default:on) */
+ CAN_RAW_RECV_OWN_MSGS /* receive my own msgs (default:off) */
+};
+
+#endif
Index: net-2.6.25/net/can/Kconfig
===
--- net-2.6.25.orig/net/can/Kconfig 2007-11-14 13:04:49.0 +0100
+++ net-2.6.25/net/can/Kconfig 2007-11-14 13:04:51.0 +0100
@@ -16,6 +16,17 @@
If you want CAN support you should say Y here and also to the
specific driver for your controller(s) below.
+config CAN_RAW
+ tristate "Raw CAN Protocol (raw access with CAN-ID filtering)"
+ depends on CAN
+ default N
+ ---help---
+ The raw CAN protocol option offers access to the CAN bus via
+ the BSD socket API. You probably want to use the raw socket in
+ most cases where no higher level protocol is being used. The raw
+ socket has several filter options e.g. ID masking / error frames.
+ To receive/send raw CAN messages, use AF_CAN with protocol CAN_RAW.
+
config CAN_DEBUG_CORE
bool "CAN Core debugging messages"
depends on CAN
Index: net-2.6.25/net/can/Makefile
===
--- net-2.6.25.orig/net/can/Makefile2007-11-14 13:04:49.0 +0100
+++ net-2.6.25/net/can/Makefile 2007-11-14 13:04:51.0 +0100
@@ -4,3 +4,6 @@
obj-$(CONFIG_CAN) += can.o
can-objs := af_can.o proc.o
+
+obj-$(CONFIG_CAN_RAW) += can-raw.o
+can-raw-objs := raw.o
Index: net-2.6.25/net/can/raw.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/net/can/raw.c2007-11-14 13:04:51.0 +0100
@@ -0,0 +1,811 @@
+/*
+ * raw.c - Raw sockets for protocol family CAN
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
[PATCH 0/7] CAN: New PF_CAN protocol family for 2.6.25
Hello Dave, hello Patrick,
this patch series that adds the PF_CAN protocol family for the
Controller Area Network. Since our last post we have changed:
* Fix a bug causing NULL pointer dereference when module autoloading fails.
* Initialize skb using skb_reset_{transport,network}_header().
* Use sock_alloc_send_skb() instead of alloc_skb().
* Adapt to changes in sk_alloc() parameter list.
* Rename some local variables for readability.
This patch series applies against net-2.6.25 and is derived from Subversion
revision r542 of http://svn.berlios.de/svnroot/repos/socketcan.
It can be found in the directory
http://svn.berlios.de/svnroot/repos/socketcan/trunk/patch-series/.
Thanks very much for your work!
Best regards,
Urs Thuermann
Oliver Hartkopp
The changes in try #10 were:
* Rename our static debug variables to {can,raw,bcm,vcan}_debug.
* Use module_param_named() so that the module option names remain.
* Remove raw_poll() and bcm_poll() functions and use datagram_poll instead.
* Cleanup of can_addr union in sockaddr_can.
* Change type of echo module parameter to boolean.
The changes in try #9 were:
* Changes suggested by Arnaldo Carvalho de Melo:
- Use gfp_any() instead of checking in_interrupt().
- Don't kfree() the sk_protinfo field.
* Fixed licence text as pointed out by Yoshifuji Hideaki and Patrick McHardy.
* Added IFF_ECHO to include/linux/if.h and use that instead of IFF_LOOPBACK,
as suggested by Eric W. Biederman. IFF_LOOPBACK is only for the normal
loopback interface.
The changes in try #8 were:
* Some changes in debug code, following suggestions from Joe Perches:
- Remove dynamically allocated buffer for debug output.
- Use kernel functions for hexdumps.
- Don't interpret printf-style %-sequences in can_debug_cframe().
- Specify the fixed argument "fmt" to DBG() macro and use
GCC ## mechanism to remove , when args is empty.
* Removed CAN_RAW_USER and CAN_BCM_USER Kconfig options following a
suggestion from Patrick.
* Prevent overflow in statistics calculation.
* Minor optimization.
The changes in try #7 were:
* Changes suggested by Patrick:
- protect proto_tab[] by a lock.
- add _rcu to some hlist traversals.
- use printk_ratelimit() for module autoload failures.
- make can_proto_unregister() and can_rx_unregister() return void.
- use return value of can_proto_register() and can_rx_register()
(this also removed a flaw in behavior of raw_bind() and raw_setsockopt()
in case of failure to can_rx_register() their filters).
- call kzalloc() with GFP_KERNEL in case NETDEV_REGISTER.
- use round_jiffies() to calculate expiration times.
- make some variables static and/or __read_mostly.
- in can_create() check for net namespace before auto loading modules.
- add build time check for struct sizes.
- use skb_share_chack() in vcan.
- fixed some comments.
* Typos in documentation as pointed out by Randy Dunlap and Bill Fink.
The changes in try #6 were:
* Update code to work with namespaces in net-2.6.24.
* Remove SET_MODULE_OWNER() from vcan.
The changes in try #5 were:
* Remove slab destructor from calls to kmem_cache_alloc().
* Add comments about types defined in can.h.
* Update comment on vcan loopback module parameter.
* Fix typo in documentation.
The changes in try #4 were:
* Change vcan network driver to use the new RTNL API, as suggested by
Patrick.
* Revert our change to use skb->iif instead of skb->cb. After
discussion with Patrick and Jamal it turned out, our first
implementation was correct.
* Use skb_tail_pointer() instead of skb->tail directly.
* Coding style changes to satisfy linux/scripts/checkpatch.pl.
* Minor changes for 64-bit-cleanliness.
* Minor cleanup of #include's
The changes in try #3 were:
* Use sbk->sk and skb->pkt_type instead of skb->cb to pass loopback
flags and originating socket down to the driver and back to the
receiving socket. Thanks to Patrick McHardy for pointing out our
wrong use of sbk->cb.
* Use skb->iif instead of skb->cb to pass receiving interface from
raw_rcv() and bcm_rcv() up to raw_recvmsg() and bcm_recvmsg().
* Set skb->protocol when sending CAN frames to netdevices.
* Removed struct raw_opt and struct bcm_opt and integrated these
directly into struct raw_sock and bcm_sock resp., like most other
proto implementations do.
* We have found and fixed race conditions between raw_bind(),
raw_{set,get}sockopt() and raw_notifier(). This resulted in
- complete removal of our own notifier list infrastructure in
af_can.c. raw.c and bcm.c now use normal netdevice notifiers.
- removal of ro->lock spinlock. We use lock_sock(sk) now.
- changed deletion of dev_rcv_lists, which are now marked for
deletion in the netdevice notifier in af_can.c and are actually
deleted when all entries have been deleted using can_rx_unregister().
* Follow changes in 2.6.22 (e.g. ktime_t timestamps in skb).
* Removed obsolete code from vcan.c, as pointed out by Stephen Hemmin
[PATCH 1/7] CAN: Allocate protocol numbers for PF_CAN
This patch adds a protocol/address family number, ARP hardware type, ethernet packet type, and a line discipline number for the SocketCAN implementation. Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]> Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]> --- include/linux/if.h |4 +++- include/linux/if_arp.h |1 + include/linux/if_ether.h |1 + include/linux/socket.h |2 ++ include/linux/tty.h |3 ++- net/core/sock.c |4 ++-- 6 files changed, 11 insertions(+), 4 deletions(-) Index: net-2.6.25/include/linux/if_arp.h === --- net-2.6.25.orig/include/linux/if_arp.h 2007-11-14 13:04:26.0 +0100 +++ net-2.6.25/include/linux/if_arp.h 2007-11-14 13:04:46.0 +0100 @@ -52,6 +52,7 @@ #define ARPHRD_ROSE270 #define ARPHRD_X25 271 /* CCITT X.25 */ #define ARPHRD_HWX25 272 /* Boards with X.25 in firmware */ +#define ARPHRD_CAN 280 /* Controller Area Network */ #define ARPHRD_PPP 512 #define ARPHRD_CISCO 513 /* Cisco HDLC */ #define ARPHRD_HDLCARPHRD_CISCO Index: net-2.6.25/include/linux/if_ether.h === --- net-2.6.25.orig/include/linux/if_ether.h2007-11-14 13:04:26.0 +0100 +++ net-2.6.25/include/linux/if_ether.h 2007-11-14 13:04:46.0 +0100 @@ -90,6 +90,7 @@ #define ETH_P_WAN_PPP 0x0007 /* Dummy type for WAN PPP frames*/ #define ETH_P_PPP_MP0x0008 /* Dummy type for PPP MP frames */ #define ETH_P_LOCALTALK 0x0009 /* Localtalk pseudo type*/ +#define ETH_P_CAN 0x000C /* Controller Area Network */ #define ETH_P_PPPTALK 0x0010 /* Dummy type for Atalk over PPP*/ #define ETH_P_TR_802_2 0x0011 /* 802.2 frames */ #define ETH_P_MOBITEX 0x0015 /* Mobitex ([EMAIL PROTECTED]) */ Index: net-2.6.25/include/linux/socket.h === --- net-2.6.25.orig/include/linux/socket.h 2007-11-14 13:04:26.0 +0100 +++ net-2.6.25/include/linux/socket.h 2007-11-14 13:04:46.0 +0100 @@ -185,6 +185,7 @@ #define AF_PPPOX 24 /* PPPoX sockets*/ #define AF_WANPIPE 25 /* Wanpipe API Sockets */ #define AF_LLC 26 /* Linux LLC*/ +#define AF_CAN 29 /* Controller Area Network */ #define AF_TIPC30 /* TIPC sockets */ #define AF_BLUETOOTH 31 /* Bluetooth sockets*/ #define AF_IUCV32 /* IUCV sockets */ @@ -220,6 +221,7 @@ #define PF_PPPOX AF_PPPOX #define PF_WANPIPE AF_WANPIPE #define PF_LLC AF_LLC +#define PF_CAN AF_CAN #define PF_TIPCAF_TIPC #define PF_BLUETOOTH AF_BLUETOOTH #define PF_IUCVAF_IUCV Index: net-2.6.25/include/linux/tty.h === --- net-2.6.25.orig/include/linux/tty.h 2007-11-14 13:04:26.0 +0100 +++ net-2.6.25/include/linux/tty.h 2007-11-14 13:04:46.0 +0100 @@ -23,7 +23,7 @@ */ #define NR_UNIX98_PTY_DEFAULT 4096 /* Default maximum for Unix98 ptys */ #define NR_UNIX98_PTY_MAX (1 << MINORBITS) /* Absolute limit */ -#define NR_LDISCS 17 +#define NR_LDISCS 18 /* line disciplines */ #define N_TTY 0 @@ -44,6 +44,7 @@ #define N_SYNC_PPP 14 /* synchronous PPP */ #define N_HCI 15 /* Bluetooth HCI UART */ #define N_GIGASET_M101 16 /* Siemens Gigaset M101 serial DECT adapter */ +#define N_SLCAN17 /* Serial / USB serial CAN Adaptors */ /* * This character is the same as _POSIX_VDISABLE: it cannot be used as Index: net-2.6.25/net/core/sock.c === --- net-2.6.25.orig/net/core/sock.c 2007-11-14 13:04:26.0 +0100 +++ net-2.6.25/net/core/sock.c 2007-11-14 13:04:47.0 +0100 @@ -154,7 +154,7 @@ "sk_lock-AF_ASH" , "sk_lock-AF_ECONET" , "sk_lock-AF_ATMSVC" , "sk_lock-21" , "sk_lock-AF_SNA" , "sk_lock-AF_IRDA" , "sk_lock-AF_PPPOX" , "sk_lock-AF_WANPIPE" , "sk_lock-AF_LLC" , - "sk_lock-27" , "sk_lock-28" , "sk_lock-29" , + "sk_lock-27" , "sk_lock-28" , "sk_lock-AF_CAN" , "sk_lock-AF_TIPC" , "sk_lock-AF_BLUETOOTH", "sk_lock-IUCV", "sk_lock-AF_RXRPC" , "sk_lock-AF_MAX" }; @@ -168,7 +168,7 @@ "slock-AF_ASH" , "slock-AF_ECONET" , "slock-AF_ATMSVC" , "slock-21" , "slock-AF_SNA" , "slock-AF_IRDA" , "slock-AF_PPPOX" , "slock-AF_WANPIPE" , "slock-AF_LLC" , - "slock-27" , "slock-28" , "slock-29"
Re: [BUG] New Kernel Bugs
On Tue, 13 Nov 2007, Andrew Morton wrote: > > HID > > > > Kernel NULL pointer dereference at :usbhid:hiddev_ioctl+0x2f/0xabc > > http://bugzilla.kernel.org/show_bug.cgi?id=9216 > > Kernel: 2.6.23.1 > > Looks like this is a regression > No response from developers Hi, it is assigned to '[EMAIL PROTECTED]', so I didn't notice, it's as simple as that. -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 14-11-07 12:56, David Miller wrote: From: Rene Herman <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 12:46:24 +0100 [EMAIL PROTECTED] is not subscriber-only. Same as that arm list, it's _moderated_ for non-subscribers and given that I and other moderators have been doing our best to moderate quickly (I tend to stay logged in to the moderation interface all day for example) what specifically bugged the crap out of you? It's not something a poster needs to concern himself with. The fact that it farts at me every time I post to this thread. That's rude and annoying. It certainly is. I only experienced that now due to the "too many recipients to message" moderation notice that I got from my own message. Jaroslav -- please disable that junk or if possible, make it a "at most once per address per month" thing or somesuch. This is complete crap. Also for alsa-devel the moderators tend to add any valid non-subcribers to a whitelist after landing in the queue the first time meaning even a delay is just a one-time thing normally. So what's the trouble? Basically, noone need even notice... That sucks for new people taking part in the conversation. There is no reason for moderation at all, it isn't necessary for spam prevention and it does nothing but annoy new posters and make work for the moderator. Yes there is. It's necessary for lists that do not have the human and other resouces behind it that vger does. alsa-devel was drowning in spam and dying as a result back when it was at sourceforge. Upon moving, my preference was to ask the lists to be hosted at vger but given that (it seems) Jaroslav wanted to keep them locally, moderation was very necessary. I moderate out quite a bit of spam every day. vger is doing an amazing job at spam filtering -- if it's an option to move to vger, than sure, no need. But otherwise, the "no need" needs a list admin with enough bandwidth and skill. As to the "new people": it's not optimal, but (upto this thread I'll admit -- I woke up to a huge number of posts in the queue) it's not been a _real_ problem. alsa-devel is not high-volume enough for it to be. Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Urs Thuermann wrote:
> +static int vcan_open(struct net_device *dev)
> +{
> + DBG("%s: interface up\n", dev->name);
> +
> + netif_start_queue(dev);
> + return 0;
> +}
> +
> +static int vcan_stop(struct net_device *dev)
> +{
> + DBG("%s: interface down\n", dev->name);
> +
> + netif_stop_queue(dev);
> + return 0;
> +}
These two functions look unnecessary, there's no need to manage
the queue for pure software devices.
> +static int vcan_tx(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct net_device_stats *stats = &dev->stats;
> + int loop;
> +
> + DBG("sending skbuff on interface %s\n", dev->name);
> +
> + stats->tx_packets++;
> + stats->tx_bytes += skb->len;
> +
> + /* set flag whether this packet has to be looped back */
> + loop = skb->pkt_type == PACKET_LOOPBACK;
> +
> + if (!echo) {
> + /* no echo handling available inside this driver */
> +
> + if (loop) {
> + /*
> + * only count the packets here, because the
> + * CAN core already did the echo for us
> + */
> + stats->rx_packets++;
> + stats->rx_bytes += skb->len;
> + }
> + kfree_skb(skb);
> + return 0;
Please use the NETDEV_TX codes.
Besides these minor issues, looks fine.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Moderated list (Was: Re: [BUG] New Kernel Bugs)
At Wed, 14 Nov 2007 04:01:31 -0800 (PST), David Miller wrote: > > From: David Miller <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) > > > The fact that it farts at me every time I post to this thread. > > See? I got another one and I have received at least 10 of the > following over the past 2 days. > > That's rediculious. > > And because a human adds the whitelist this is always going to > happen to someone when they start posting to the alsa list for > the first time. ... if you give too many recipients in your post. That is often really annoying thing to me, together with keeping the unrelated subject line ;) I personally don't care whether it's a moderated or open list. We chose it simply due to too bad S/N ratio at that time. So, if the current list annoys your or many others and the list management on vger is so good, it'd be basically a good move, of course. I'll appreciate it. The only confusion would be the change of ML address, but we can do it slowly, too. Takashi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: > Finally they replied and asked to rediff it against their > git tree. I did that and sent patches back. No reply since then. > > And mind you, the patch is not trying to do anything > complex, it mostly moves code around, removes 'inline', > adds 'const'. What should I think about it? I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I do? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re : Bug in using inet_lookup ()
On Wed, Nov 14, 2007 at 01:12:11PM +, Nj A ([EMAIL PROTECTED]) wrote:
> I suspected it could be that. However, can't see in ip_rcv the right portion
> that can help.
> Any further tip please?
It is ip_rcv_finish() called from ip_rcv():
if (skb->dst == NULL) {
int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
skb->dev);
if (unlikely(err)) {
if (err == -EHOSTUNREACH)
IP_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS);
else if (err == -ENETUNREACH)
IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
goto drop;
}
}
So you will have to specify device, you got your skb via.
Actually it is not exactly needed in some cases, you will need interface
index (dev->ifindex). You can find socket by using that number instead
of dereferencing dst.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re : Oops preceded by WARNING: at net/ipv4/tcp_input.c:1571 tcp_remove_reno_sacks()
On Tue, 13 Nov 2007, David Miller wrote:
> From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
> Date: Tue, 13 Nov 2007 23:35:39 +0200 (EET)
>
> > [PATCH] [TCP] FRTO: Plug potential LOST-bit leak
> >
> > It might be possible that, in some extreme scenario that
> > I just cannot now construct in my mind, end_seq <=
> > frto_highmark check does not match causing the lost_out
> > and LOST bits become out-of-sync due to clearing and
> > recounting in the loop.
> >
> > This may fix LOST-bit leak reported by Chazarain Guillaume
> > <[EMAIL PROTECTED]>.
> >
> > Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
>
> This patch looks correct to me, so I added it to net-2.6
>
> Chazarain please let us know if it does indeed cure your
> problem.
Ok, now after one night more, I think I know what it was, this
indeed "cured" it (and IMHO we can leave it there too).
...But here's a fix that very well explains why the frto_highmark
check could give a bit strange results :-).
--
[PATCH] [TCP] FRTO: Clear frto_highmark only after process_frto that uses it
I broke this in commit 3de96471bd7fb76406e975ef6387abe3a0698149.
tcp_process_frto should always see a valid frto_highmark. An
invalid frto_highmark (zero) is very likely what ultimately
caused a seqno compare in tcp_frto_enter_loss to do the wrong
leading to the LOST-bit leak.
Having LOST-bits integry ensured like done after commit
23aeeec365dcf8bc87fae44c533e50d0bb4f23cc won't hurt. It may
still be useful in some other, possibly legimate, scenario.
Reported by Chazarain Guillaume <[EMAIL PROTECTED]>.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
net/ipv4/tcp_input.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 3f126ec..0f0c1c9 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3113,11 +3113,11 @@ static int tcp_ack(struct sock *sk, struct sk_buff
*skb, int flag)
/* See if we can take anything off of the retransmit queue. */
flag |= tcp_clean_rtx_queue(sk, &seq_rtt, prior_fackets);
+ if (tp->frto_counter)
+ frto_cwnd = tcp_process_frto(sk, flag);
/* Guarantee sacktag reordering detection against wrap-arounds */
if (before(tp->frto_highmark, tp->snd_una))
tp->frto_highmark = 0;
- if (tp->frto_counter)
- frto_cwnd = tcp_process_frto(sk, flag);
if (tcp_ack_is_dubious(sk, flag)) {
/* Advance CWND, if state allows this. */
--
1.5.0.6
Re: [PATCH 00/25] RFC: AF_INET6 family support for the NFS client
On Nov 13, 2007, at 8:14 PM, David Miller wrote: From: Chuck Lever <[EMAIL PROTECTED]> Date: Tue, 13 Nov 2007 13:30:59 -0500 These 25 patches add support for AF_INET6 addresses to the NFS client. This is a request for review of the proposed changes. Please start using the [EMAIL PROTECTED] mailing list for future submissions instead of the sourceforge one. Thank you. Hi David- Neil Brown has discussed a transition plan. There were no objections to moving to vger, but we don't have a timeframe yet. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Matthew Wilcox wrote: > On Wed, Nov 14, 2007 at 12:46:20AM -0700, Denys Vlasenko wrote: >> Finally they replied and asked to rediff it against their >> git tree. I did that and sent patches back. No reply since then. >> >> And mind you, the patch is not trying to do anything >> complex, it mostly moves code around, removes 'inline', >> adds 'const'. What should I think about it? > > I'm waiting for an ACK/NAK from Hannes, the maintainer. What should I > do? > I haven't actually been able to test it here (too busy, sorry). If someone else confirms it does it's job then Acked-by: Hannes Reinecke <[EMAIL PROTECTED]> Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage [EMAIL PROTECTED] +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove notifier block from chain when register_netdevice_notifier fails
On Wed, Nov 14, 2007 at 03:08:03PM +0300, Pavel Emelyanov wrote:
> Commit fcc5a03ac42564e9e255c1134dda47442289e466 makes the
> register_netdevice_notifier() handle the error from the
> NETDEV_REGISTER event, sent to the registering block.
>
> The bad news is that in this case the notifier block is
> not removed from the list, but the error is returned to the
> caller. In case the caller is in module init function and
> handles this error this can abort the module loading. The
> notifier block will be then removed from the kernel, but
> will be left in the list. Oops :(
>
> I think that the notifier block should be removed from the
> chain in case of error, regardless whether this error is
> handled by the caller or not. In the worst case (the error
> is _not_ handled) module will not receive the events any
> longer.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Good catch. Thanks Pavel!
Acked-by: Herbert Xu <[EMAIL PROTECTED]>
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [BUG] New Kernel Bugs
On 14-11-07 13:01, David Miller wrote: From: David Miller <[EMAIL PROTECTED]> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST) The fact that it farts at me every time I post to this thread. See? I got another one and I have received at least 10 of the following over the past 2 days. Nah, in this case you are not even getting them to not being a non-subcriber but due to too many CCs. I got one as well. That just needs to be disabled, does not have anything to do with non-subscribers (and you're in the white list) but is just a retarted bit of list configuration... (no, I can't personally change it, needs Jaroslav Kysela) Rene. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re : Bug in using inet_lookup ()
I suspected it could be that. However, can't see in ip_rcv the right portion
that can help.
Any further tip please?
Regards,
- Message d'origine
> De : Evgeniy Polyakov <[EMAIL PROTECTED]>
> À : Nj A <[EMAIL PROTECTED]>
> Cc : netdev@vger.kernel.org
> Envoyé le : Mercredi, 14 Novembre 2007, 12h13mn 05s
> Objet : Re: Bug in using inet_lookup ()
>
> On Wed, Nov 14, 2007 at 09:26:18AM +, Nj A ([EMAIL PROTECTED]) wrote:
> > /* The kernel TCP hashtable */
> > struct inet_hashinfo __cacheline_aligned tcp_hashinfo = {
> > .lhash_lock = __RW_LOCK_UNLOCKED (tcp_hashinfo.lhash_lock),
> > .lhash_users = ATOMIC_INIT (0),
> > .lhash_wait = __WAIT_QUEUE_HEAD_INITIALIZER (tcp_hashinfo.lhash_wait),
> > };
> > ...
> > struct sock *sk;
> > struct sk_buff *skb;
> > skb = alloc_skb (MAX_TCP_HEADER + 15, GFP_KERNEL);
> > if (skb == NULL)
> > printk ("%s: Unable to allocate memory \n", __FUNCTION__);
> > sk = inet_lookup (&tcp_hashinfo, ip_src, src_port, ip_dst, dst_port,
> > inet_iif
> (skb));
> > if (!sk)
> > ...
> > This portion of code seems to cause the kernel to panic due to
> > dereferencing a
> NULL pointer.
> > Can anyone please tell me what is the error above?
> > Best Regards,
>
> Where exactly? Likely in inet_iif(), since it dereferences dst (routing
> info), which is not presented after simple alloc_skb().
> You have to setup skb correctly, check how ip_rcv() does it.
>
> --
> Evgeniy
> Polyakov
>
_
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Patrick McHardy <[EMAIL PROTECTED]> writes:
> > +static int vcan_open(struct net_device *dev)
> > +static int vcan_stop(struct net_device *dev)
> These two functions look unnecessary, there's no need to manage
> the queue for pure software devices.
OK, removed.
> Please use the NETDEV_TX codes.
OK, replaced return 0 by NETDEV_TX_OK.
The new patch is below.
urs
This patch adds the virtual CAN bus (vcan) network driver.
The vcan device is just a loopback device for CAN frames, no
real CAN hardware is involved.
Signed-off-by: Oliver Hartkopp <[EMAIL PROTECTED]>
Signed-off-by: Urs Thuermann <[EMAIL PROTECTED]>
---
drivers/net/Makefile |1
drivers/net/can/Kconfig | 25 ++
drivers/net/can/Makefile |5 +
drivers/net/can/vcan.c | 189 +++
net/can/Kconfig |3
5 files changed, 223 insertions(+)
Index: net-2.6.25/drivers/net/Makefile
===
--- net-2.6.25.orig/drivers/net/Makefile2007-11-14 13:04:24.0
+0100
+++ net-2.6.25/drivers/net/Makefile 2007-11-14 13:04:54.0 +0100
@@ -12,6 +12,7 @@
obj-$(CONFIG_CHELSIO_T1) += chelsio/
obj-$(CONFIG_CHELSIO_T3) += cxgb3/
obj-$(CONFIG_EHEA) += ehea/
+obj-$(CONFIG_CAN) += can/
obj-$(CONFIG_BONDING) += bonding/
obj-$(CONFIG_ATL1) += atl1/
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
Index: net-2.6.25/drivers/net/can/Kconfig
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/drivers/net/can/Kconfig 2007-11-14 13:04:54.0 +0100
@@ -0,0 +1,25 @@
+menu "CAN Device Drivers"
+ depends on CAN
+
+config CAN_VCAN
+ tristate "Virtual Local CAN Interface (vcan)"
+ depends on CAN
+ default N
+ ---help---
+ Similar to the network loopback devices, vcan offers a
+ virtual local CAN interface.
+
+ This driver can also be built as a module. If so, the module
+ will be called vcan.
+
+config CAN_DEBUG_DEVICES
+ bool "CAN devices debugging messages"
+ depends on CAN
+ default N
+ ---help---
+ Say Y here if you want the CAN device drivers to produce a bunch of
+ debug messages to the system log. Select this if you are having
+ a problem with CAN support and want to see more of what is going
+ on.
+
+endmenu
Index: net-2.6.25/drivers/net/can/Makefile
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/drivers/net/can/Makefile 2007-11-14 13:04:54.0 +0100
@@ -0,0 +1,5 @@
+#
+# Makefile for the Linux Controller Area Network drivers.
+#
+
+obj-$(CONFIG_CAN_VCAN) += vcan.o
Index: net-2.6.25/drivers/net/can/vcan.c
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ net-2.6.25/drivers/net/can/vcan.c 2007-11-14 14:17:43.0 +0100
@@ -0,0 +1,189 @@
+/*
+ * vcan.c - Virtual CAN interface
+ *
+ * Copyright (c) 2002-2007 Volkswagen Group Electronic Research
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of Volkswagen nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ *
+ * Alternatively, provided that this notice is retained in full, this
+ * software may be distributed under the terms of the GNU General
+ * Public License ("GPL") version 2, in which case the provisions of the
+ * GPL apply INSTEAD OF those given above.
+ *
+ * The provided data structures and external interfaces from this code
+ * are not restricted to be used by modules with a GPL compatible license.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INC
Re: Moderated list (Was: Re: [BUG] New Kernel Bugs)
At Wed, 14 Nov 2007 13:21:30 +0100,
Rene Herman wrote:
>
> On 14-11-07 09:25, Takashi Iwai wrote:
>
> > At Wed, 14 Nov 2007 04:01:31 -0800 (PST),
> > David Miller wrote:
> >> From: David Miller <[EMAIL PROTECTED]>
> >> Date: Wed, 14 Nov 2007 03:56:57 -0800 (PST)
> >>
> >>> The fact that it farts at me every time I post to this thread.
> >> See? I got another one and I have received at least 10 of the
> >> following over the past 2 days.
> >>
> >> That's rediculious.
> >>
> >> And because a human adds the whitelist this is always going to
> >> happen to someone when they start posting to the alsa list for
> >> the first time.
> >
> > ... if you give too many recipients in your post. That is often
> > really annoying thing to me, together with keeping the unrelated
> > subject line ;)
> >
> > I personally don't care whether it's a moderated or open list.
> > We chose it simply due to too bad S/N ratio at that time. So, if the
> > current list annoys your or many others and the list management on
> > vger is so good, it'd be basically a good move, of course. I'll
> > appreciate it.
> >
> > The only confusion would be the change of ML address, but we can do it
> > slowly, too.
>
> I'd love the lists at vger. Amazing spam-filtering. I'd like to request the
> name [EMAIL PROTECTED] (and [EMAIL PROTECTED] if at all
> possible so we can open that one up as well) though.
I think alsa-user can stay as is. It's no place for dragging many
other addresses like alsa-devel.
BTW, I also prefer keeping the name [EMAIL PROTECTED] It's been so.
> There wouldn't need to be a forced ML address change if Jaroslov would then
> just rewrite alsa-{devel,[EMAIL PROTECTED] to vger.kernel.org same as
> he did for alsa-devel and does for alsa-user to @lists.sf.net.
If it works, then I'm for it, too.
thanks,
Takashi
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] using mii-bitbang on different processor ports - update the booting-without-of.txt-file
The patch updates the booting-without-of.txt-file. There is a description for the case if mdio data and clock pins are on different processor ports. It extends the "[PATCH v3] using mii-bitbang on different processor ports". Signed-off-by: Sergej Stepanov <[EMAIL PROTECTED]> Signed-off-by: Scott Wood <[EMAIL PROTECTED]> -- diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 497d8d8..084d31b 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -1936,11 +1936,15 @@ platforms are moved over to use the flattened-device-tree model. Currently defined compatibles: fsl,pq1-fec-mdio (reg is same as first resource of FEC device) - fsl,cpm2-mdio-bitbang (reg is port C registers) + fsl,cpm2-mdio-bitbang Properties for fsl,cpm2-mdio-bitbang: - fsl,mdio-pin : pin of port C controlling mdio data - fsl,mdc-pin : pin of port C controlling mdio clock + The first reg resource is the I/O port register block on which MDIO + resides. The second reg resource is the I/O port register block on + which MDC resides. If there is only one reg resource, it is used for + both MDIO and MDC. + fsl,mdio-pin : pin of chosen port for controlling mdio data + fsl,mdc-pin : pin of chosen port for controlling mdio clock Example: - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/7] CAN: Add virtual CAN netdevice driver
Urs Thuermann wrote: > The new patch is below. Thanks. I'll look over the other patches later. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove notifier block from chain when register_netdevice_notifier fails
Herbert Xu wrote: > On Wed, Nov 14, 2007 at 03:08:03PM +0300, Pavel Emelyanov wrote: >> Commit fcc5a03ac42564e9e255c1134dda47442289e466 makes the >> register_netdevice_notifier() handle the error from the >> NETDEV_REGISTER event, sent to the registering block. >> >> The bad news is that in this case the notifier block is >> not removed from the list, but the error is returned to the >> caller. In case the caller is in module init function and >> handles this error this can abort the module loading. The >> notifier block will be then removed from the kernel, but >> will be left in the list. Oops :( >> >> I think that the notifier block should be removed from the >> chain in case of error, regardless whether this error is >> handled by the caller or not. In the worst case (the error >> is _not_ handled) module will not receive the events any >> longer. >> >> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> > > Good catch. Thanks Pavel! > > Acked-by: Herbert Xu <[EMAIL PROTECTED]> Thanks :) BTW, I have one more question I can't find the answer to by myself. Why the unregister_netdevice_notifier doesn't produce the GOING_DOWN-DOWN-UNREGISTER event sequence for the notifier block which is being unregistered? Was this made deliberately? Pavel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove notifier block from chain when register_netdevice_notifier fails
On Wed, Nov 14, 2007 at 04:47:24PM +0300, Pavel Emelyanov wrote:
>
> BTW, I have one more question I can't find the answer to by
> myself. Why the unregister_netdevice_notifier doesn't produce
> the GOING_DOWN-DOWN-UNREGISTER event sequence for the notifier
> block which is being unregistered? Was this made deliberately?
I think it's more of an oversight :)
Although it has no real impact because the only user that matters
here is IPv6 and it can't be unloaded.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Hi! > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > Kernel: 2.6.23 > > This is HP notebook nc6320 T2400 945GM > > No response from developers Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz problems. nohz=off highres=off fixes more than one suspend problem... ...stuff I've seen with NOHZ even without suspend (cursor blinking irregulary) make me think that nohz perhaps should not be used in production just yet... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
FWIW, I see the same problem with another HP notebook, DV4378EA with radeon X700 video card. It does not happen frequently but I can say that since I disabled the tickless feature I can't reproduce the problem anymore. On Nov 14, 2007 2:24 PM, Pavel Machek <[EMAIL PROTECTED]> wrote: > Hi! > > > > Suspend to RAM resume hangs on a tickless (NO_HZ) kernel > > > http://bugzilla.kernel.org/show_bug.cgi?id=9275 > > > Kernel: 2.6.23 > > > This is HP notebook nc6320 T2400 945GM > > > > No response from developers > > Maybe I'm optimistic, but I expected Ingo/Thomas to look after nohz > problems. nohz=off highres=off fixes more than one suspend problem... > > ...stuff I've seen with NOHZ even without suspend (cursor blinking > irregulary) make me think that nohz perhaps should not be used in > production just yet... > > Pavel > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* Randy Dunlap <[EMAIL PROTECTED]> wrote: > > (and this is in no way directed at the networking folks - it holds > > for all of us. I have one main complaint about networking: the > > separate netdev list is a bad idea - networking regressions should > > be discussed and fixed on lkml, like most other subsystems are. Any > > artificial split of the lk discussion space is bad.) > > but here I disagree. LKML is already too busy and noisy. Major > subsystems need their own discussion areas. That's a stupid argument. We lose much more by forced isolation of discussion than what we win by having less traffic! It's _MUCH_ easier to narrow down information (by filter by threads, by topics, by people, etc.) than it is to gobble information together from various fractured sources. We learned it _again and again_ that isolation of kernel discussions causes bad things. In fact this thread is the very example: David points out that on netdev some of those bugs were already discussed and resolved. Had it been all on lkml we'd all be aware of it. this is a single kernel project that is released together as one codebase, so a central place of discussion is obvious and common-sense. so please stop this "too busy and too noisy" nonsense already. It was nonsense 10 years ago and it's nonsense today. In 10 years the kernel grew from a 1 million lines codebase to an 8 million lines codebase, so what? Deal with it and be intelligent about filtering your information influx instead of imposing a hard pre-filtering criteria that restricts intelligent processing of information. Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
* Mark Lord <[EMAIL PROTECTED]> wrote: >> You're assuming that everything in linux-2.6 was downloaded; that's >> not true. Everything in linux-2.6/.git was downloaded; but then you >> do a checkout which happens to approximately double the size of the >> linux-2.6 directory. > .. > > Ah, I wondered why it took only half an hour to download. and you can get even lower than the 260MB by downloading a shallow clone of v2.6.23 and then populating the git tree from tht point on. (see the --depth parameter of git-clone) [because most of the time you want to bisect back to the last stable release, not back to 2 years of git history.] Ingo - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
Ingo Molnar wrote: > * Mark Lord <[EMAIL PROTECTED]> wrote: > >>> You're assuming that everything in linux-2.6 was downloaded; that's >>> not true. Everything in linux-2.6/.git was downloaded; but then you >>> do a checkout which happens to approximately double the size of the >>> linux-2.6 directory. >> .. >> >> Ah, I wondered why it took only half an hour to download. > > and you can get even lower than the 260MB by downloading a shallow clone > of v2.6.23 and then populating the git tree from tht point on. (see the > --depth parameter of git-clone) [because most of the time you want to > bisect back to the last stable release, not back to 2 years of git > history.] When creating additional git trees (Linville's wireless-2.6 tree, for example) for driver development, you can save a lot of download bandwidth by using the --reference parameter of git-clone. Larry - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPVS: Fix sysctl warnings about missing strategy
On Tue, Nov 13, 2007 at 02:45:00AM -0800, David Miller wrote: > From: Christian Borntraeger <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 11:29:58 +0100 > > > Running the latest git code I get the following messages during boot: > > sysctl table check failed: /net/ipv4/vs/drop_entry .3.5.21.4 Missing > > strategy > > [...] > > sysctl table check failed: /net/ipv4/vs/drop_packet .3.5.21.5 Missing > > strategy > > [...] > > sysctl table check failed: /net/ipv4/vs/secure_tcp .3.5.21.6 Missing > > strategy > > [...] > > sysctl table check failed: /net/ipv4/vs/sync_threshold .3.5.21.24 Missing > > strategy > > > > I removed the binary sysctl handler for those messages and also removed > > the definitions in ip_vs.h. The alternative would be to implement a > > proper strategy handler, but syscall sysctl is deprecated. > > > > There are other sysctl definitions that are commented out or work with > > the default sysctl_data strategy. I did not touch these. > > > > Eric, IPVS team, are you ok with that change? > > > > CC: Eric W. Biederman <[EMAIL PROTECTED]> > > CC: Wensong Zhang <[EMAIL PROTECTED]> > > CC: Simon Horman <[EMAIL PROTECTED]> > > CC: Julian Anastasov <[EMAIL PROTECTED]> > > Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]> > > Simon planned to make a similar change to dice all of this > stuff up. He is travelling currently, and I think it's > reasonable to give him some time to get to it. Hi Christian, Hi Dave, I have indeed been looking into this of late. Assuming that you use of CTL_UNNUMBERED is correct, this patch looks fine to me. Acked. I was planning to do the same and also switch over all the other entries over to use CTL_UNNUMBERED, as its hard to imagine that anyone is using the sys_sysctl interface to IPVS. As for the commented out entries. They are supposed to be exposed by some other means - I believe the thinking was to comply with the don't expose stuff in proc any more idea. Where is the best place to expose this kind of stuff? Lastly, as Dave mentions, I'm travelling this week, so please excuse any slowness. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] netfilter : struct xt_table_info diet
Hi David & Patrick
Please find a patch against net-2.6.25
Thank you
[PATCH] netfilter : struct xt_table_info diet
Instead of using a big array of NR_CPUS entries, we can compute the size needed
at runtime, using nr_cpu_ids
This should save some ram (especially on David's machines where NR_CPUS=4096 :
32 KB can be saved per table, and 64KB for dynamically allocated ones (because
of slab/slub alignements) )
In particular, the 'bootstrap' tables are not any more static (in data section)
but on stack as their
size is now very small.
This also should reduce the size used on stack in compat functions
(get_info() declares an automatic variable, that could be bigger than kernel
stack size for big NR_CPUS)
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
include/linux/netfilter/x_tables.h |5 -
net/ipv4/netfilter/arp_tables.c|4 ++--
net/ipv4/netfilter/ip_tables.c | 23 ++-
net/ipv6/netfilter/ip6_tables.c|4 ++--
net/netfilter/x_tables.c |2 +-
5 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/include/linux/netfilter/x_tables.h
b/include/linux/netfilter/x_tables.h
index 9657c4e..e305f2d 100644
--- a/include/linux/netfilter/x_tables.h
+++ b/include/linux/netfilter/x_tables.h
@@ -269,9 +269,12 @@ struct xt_table_info
unsigned int underflow[NF_INET_NUMHOOKS];
/* ipt_entry tables: one per CPU */
- char *entries[NR_CPUS];
+ /* Note : this field MUST be the last one, see XT_TABLE_INFO_SZ */
+ char *entries[1];
};
+#define XT_TABLE_INFO_SZ (offsetof(struct xt_table_info, entries) \
+ + nr_cpu_ids * sizeof(char *))
extern int xt_register_target(struct xt_target *target);
extern void xt_unregister_target(struct xt_target *target);
extern int xt_register_targets(struct xt_target *target, unsigned int n);
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index 2909c92..ed3bd0b 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -811,7 +811,7 @@ static int do_replace(void __user *user, unsigned int len)
return -ENOPROTOOPT;
/* overflow check */
- if (tmp.size >= (INT_MAX - sizeof(struct xt_table_info)) / NR_CPUS -
+ if (tmp.size >= (INT_MAX - XT_TABLE_INFO_SZ) / NR_CPUS -
SMP_CACHE_BYTES)
return -ENOMEM;
if (tmp.num_counters >= INT_MAX / sizeof(struct xt_counters))
@@ -1090,7 +1090,7 @@ int arpt_register_table(struct arpt_table *table,
{
int ret;
struct xt_table_info *newinfo;
- static struct xt_table_info bootstrap
+ struct xt_table_info bootstrap
= { 0, 0, 0, { 0 }, { 0 }, { } };
void *loc_cpu_entry;
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index a99fe89..a2b1ec2 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -1090,7 +1090,8 @@ compat_calc_match(struct ipt_entry_match *m, int * size)
return 0;
}
-static int compat_calc_entry(struct ipt_entry *e, struct xt_table_info *info,
+static int compat_calc_entry(struct ipt_entry *e,
+ const struct xt_table_info *info,
void *base, struct xt_table_info *newinfo)
{
struct ipt_entry_target *t;
@@ -1118,7 +1119,7 @@ static int compat_calc_entry(struct ipt_entry *e, struct
xt_table_info *info,
return 0;
}
-static int compat_table_info(struct xt_table_info *info,
+static int compat_table_info(const struct xt_table_info *info,
struct xt_table_info *newinfo)
{
void *loc_cpu_entry;
@@ -1127,13 +1128,9 @@ static int compat_table_info(struct xt_table_info *info,
if (!newinfo || !info)
return -EINVAL;
- memset(newinfo, 0, sizeof(struct xt_table_info));
- newinfo->size = info->size;
- newinfo->number = info->number;
- for (i = 0; i < NF_INET_NUMHOOKS; i++) {
- newinfo->hook_entry[i] = info->hook_entry[i];
- newinfo->underflow[i] = info->underflow[i];
- }
+ /* we dont care about newinfo->entries[] */
+ memcpy(newinfo, info, offsetof(struct xt_table_info, entries));
+ newinfo->initial_entries = 0;
loc_cpu_entry = info->entries[raw_smp_processor_id()];
return IPT_ENTRY_ITERATE(loc_cpu_entry, info->size,
compat_calc_entry, info, loc_cpu_entry, newinfo);
@@ -1327,7 +1324,7 @@ do_replace(void __user *user, unsigned int len)
return -ENOPROTOOPT;
/* overflow check */
- if (tmp.size >= (INT_MAX - sizeof(struct xt_table_info)) / NR_CPUS -
+ if (tmp.size >= (INT_MAX - XT_TABLE_INFO_SZ) / NR_CPUS -
SMP_CACHE_BYTES)
return -ENOMEM;
if (tmp.num_counters >= INT_MAX / sizeof(struct xt_counters))
@@ -1861,7 +1858,7 @@ compat_do_replace(void __user *user, unsigned int len)
[PATCH net-2.6.25 3/4] net/ipv4 - Convert IP4 address class macros to inline functions
Change LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and ZERONET
macros to inline functions is_ip4_[type](__be32 addr)
Adds some type safety and maybe some readability
No change in compiled image size
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
net/ipv4/arp.c |2 +-
net/ipv4/datagram.c |2 +-
net/ipv4/devinet.c |4 ++--
net/ipv4/fib_frontend.c |6 +++---
net/ipv4/igmp.c | 12 ++--
net/ipv4/ip_gre.c | 20 ++--
net/ipv4/ipmr.c |6 +++---
net/ipv4/raw.c |2 +-
net/ipv4/route.c| 44 ++--
net/ipv4/udp.c |2 +-
10 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 36d6798..aa76b98 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -797,7 +797,7 @@ static int arp_process(struct sk_buff *skb)
* Check for bad requests for 127.x.x.x and requests for multicast
* addresses. If this is one such, delete it.
*/
- if (LOOPBACK(tip) || MULTICAST(tip))
+ if (is_ip4_loopback(tip) || is_ip4_multicast(tip))
goto out;
/*
diff --git a/net/ipv4/datagram.c b/net/ipv4/datagram.c
index 0301dd4..303fca7 100644
--- a/net/ipv4/datagram.c
+++ b/net/ipv4/datagram.c
@@ -40,7 +40,7 @@ int ip4_datagram_connect(struct sock *sk, struct sockaddr
*uaddr, int addr_len)
oif = sk->sk_bound_dev_if;
saddr = inet->saddr;
- if (MULTICAST(usin->sin_addr.s_addr)) {
+ if (is_ip4_multicast(usin->sin_addr.s_addr)) {
if (!oif)
oif = inet->mc_index;
if (!saddr)
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index 55d199e..f82a8b0 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -408,7 +408,7 @@ static int inet_set_ifa(struct net_device *dev, struct
in_ifaddr *ifa)
in_dev_hold(in_dev);
ifa->ifa_dev = in_dev;
}
- if (LOOPBACK(ifa->ifa_local))
+ if (is_ip4_loopback(ifa->ifa_local))
ifa->ifa_scope = RT_SCOPE_HOST;
return inet_insert_ifa(ifa);
}
@@ -580,7 +580,7 @@ static __inline__ int inet_abc_len(__be32 addr)
{
int rc = -1;/* Something else, probably a multicast. */
- if (ZERONET(addr))
+ if (is_ip4_zeronet(addr))
rc = 0;
else {
__u32 haddr = ntohl(addr);
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index 732d8f0..db549d0 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -162,9 +162,9 @@ unsigned inet_addr_type(__be32 addr)
unsigned ret = RTN_BROADCAST;
struct fib_table *local_table;
- if (ZERONET(addr) || BADCLASS(addr))
+ if (is_ip4_zeronet(addr) || is_ip4_badclass(addr))
return RTN_BROADCAST;
- if (MULTICAST(addr))
+ if (is_ip4_multicast(addr))
return RTN_MULTICAST;
#ifdef CONFIG_IP_MULTIPLE_TABLES
@@ -682,7 +682,7 @@ void fib_add_ifaddr(struct in_ifaddr *ifa)
if (ifa->ifa_broadcast && ifa->ifa_broadcast != htonl(0x))
fib_magic(RTM_NEWROUTE, RTN_BROADCAST, ifa->ifa_broadcast, 32,
prim);
- if (!ZERONET(prefix) && !(ifa->ifa_flags&IFA_F_SECONDARY) &&
+ if (!is_ip4_zeronet(prefix) && !(ifa->ifa_flags&IFA_F_SECONDARY) &&
(prefix != addr || ifa->ifa_prefixlen < 32)) {
fib_magic(RTM_NEWROUTE, dev->flags&IFF_LOOPBACK ? RTN_LOCAL :
RTN_UNICAST, prefix, ifa->ifa_prefixlen, prim);
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index c560a93..b0f8905 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1742,7 +1742,7 @@ int ip_mc_join_group(struct sock *sk , struct ip_mreqn
*imr)
int ifindex;
int count = 0;
- if (!MULTICAST(addr))
+ if (!is_ip4_multicast(addr))
return -EINVAL;
rtnl_lock();
@@ -1855,7 +1855,7 @@ int ip_mc_source(int add, int omode, struct sock *sk,
struct
int leavegroup = 0;
int i, j, rv;
- if (!MULTICAST(addr))
+ if (!is_ip4_multicast(addr))
return -EINVAL;
rtnl_lock();
@@ -1985,7 +1985,7 @@ int ip_mc_msfilter(struct sock *sk, struct ip_msfilter
*msf, int ifindex)
struct ip_sf_socklist *newpsl, *psl;
int leavegroup = 0;
- if (!MULTICAST(addr))
+ if (!is_ip4_multicast(addr))
return -EINVAL;
if (msf->imsf_fmode != MCAST_INCLUDE &&
msf->imsf_fmode != MCAST_EXCLUDE)
@@ -2068,7 +2068,7 @@ int ip_mc_msfget(struct sock *sk, struct ip_msfilter *msf,
struct inet_sock *inet = inet_sk(sk);
struct ip_sf_socklist *psl;
- if (!MULTICAST(addr))
+ if (!is_ip4_multicast(addr))
return -EINVAL;
rtnl_lock();
@@ -2130,7 +2130,7 @@ int ip_mc_gsfget(struct sock *sk, struct group_filter
*gsf,
if (psin->sin_family
Re: [PATCH 2/5] accounting unit and variable
David Miller wrote:
From: Hideo AOKI <[EMAIL PROTECTED]>
Date: Tue, 13 Nov 2007 22:27:13 -0500
Herbert Xu wrote:
On Mon, Oct 29, 2007 at 05:23:10PM -0400, Hideo AOKI wrote:
+#define SK_DATAGRAM_MEM_QUANTUM ((int)PAGE_SIZE)
+
+static inline int sk_datagram_pages(int amt)
+{
+ return DIV_ROUND_UP(amt, SK_DATAGRAM_MEM_QUANTUM);
+}
Does this really have to be int? Unsigned would let the compiler
optimise this to a simple shift.
Thank you for the comment.
This inline function is used to calculate the first argument of atomic_add()
and atomic_sub(). Since the argument is int, I believe that using int is
better than using unsigned int.
If you know the values will always be positive, as you will know here,
it is OK to us unsigned int here and avoids the unacceptable expensive
divide instruction.
Please fix this.
Hello,
Thanks for your comments. I finally understood.
I'll fix it and resubmit the patch as soon as possible.
Regards,
Hideo
--
Hitachi Computer Products (America) Inc.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: sky2: hw csum failure with dual-port copper NIC on SMP
>> Do you want the test program I am using? It is a pretty basic >> send()/recv() program, ~650 lines of C. >> >> Tony >> >> > > Not really, iperf drives the problem fine. > > Thanks for the tip; I hadn't tried iperf before today. I can reproduce the problem with "iperf -s" on the system with the dual-port SysKonnect NIC and "iperf -c host -t 120" on the two Intel PRO/1000 (e1000 driver) client systems. The problem doesn't seem to happen the other way around though (running the server on the two Intel PRO/1000 systems and two iperf clients on the SysKonnect system). So the problem appears to be triggered by recv() on the SysKonnect side but not send(). Tony - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] IPVS: Fix sysctl warnings about missing strategy
Simon Horman <[EMAIL PROTECTED]> writes: > > Hi Christian, Hi Dave, > > I have indeed been looking into this of late. Assuming that you use of > CTL_UNNUMBERED is correct, this patch looks fine to me. Acked. > > I was planning to do the same and also switch over all the other entries > over to use CTL_UNNUMBERED, as its hard to imagine that anyone is using > the sys_sysctl interface to IPVS. > > As for the commented out entries. They are supposed to be exposed by > some other means - I believe the thinking was to comply with the don't > expose stuff in proc any more idea. Where is the best place to expose > this kind of stuff? > > Lastly, as Dave mentions, I'm travelling this week, so please > excuse any slowness. Looking at this patch it looks sane enough. Either removing ctl_name or explicitly using CTL_UNNUMBERED is fine. It may be wise to leave the binary entries in ip_vs.h and sysctl_check.c as documentation, but even there it doesn't much matter since we don't plan on adding more. Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix warning for token-ring from sysctl checker
David Miller <[EMAIL PROTECTED]> writes: > From: Olof Johansson <[EMAIL PROTECTED]> > Date: Tue, 13 Nov 2007 01:23:13 -0600 > >> As seen when booting ppc64_defconfig: >> >> sysctl table check failed: /net/token-ring .3.14 procname does not match > binary path procname >> >> >> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > > Patch applied, thanks Olof. No objections but I think we already have this fixed in the -mm tree. Eric - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 4/4] net/netfilter - Convert IP4 address class macros to inline functions
Change LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and ZERONET macros to inline functions is_ip4_[type](__be32 addr) Adds some type safety and maybe some readability No change in compiled image size Signed-off-by: Joe Perches <[EMAIL PROTECTED]> --- net/netfilter/xt_pkttype.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/netfilter/xt_pkttype.c b/net/netfilter/xt_pkttype.c index a52925f..18c54ce 100644 --- a/net/netfilter/xt_pkttype.c +++ b/net/netfilter/xt_pkttype.c @@ -34,7 +34,7 @@ static bool match(const struct sk_buff *skb, const struct xt_pkttype_info *info = matchinfo; if (skb->pkt_type == PACKET_LOOPBACK) - type = MULTICAST(ip_hdr(skb)->daddr) + type = is_ip4_multicast(ip_hdr(skb)->daddr) ? PACKET_MULTICAST : PACKET_BROADCAST; else - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 1/4] include - Convert IP4 address class macros to inline functions
Change LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and ZERONET
macros to inline functions is_ip4_[type](__be32 addr)
Adds some type safety and maybe some readability
No change in compiled image size
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
include/linux/in.h | 45 -
1 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/include/linux/in.h b/include/linux/in.h
index 3975cbf..ac6eff1 100644
--- a/include/linux/in.h
+++ b/include/linux/in.h
@@ -246,12 +246,47 @@ struct sockaddr_in {
#include
#ifdef __KERNEL__
+
+static inline __be32 ip4_addr_octets(unsigned char a, unsigned char b,
unsigned char c, unsigned char d)
+{
+ return htonl__u32)(a & 0xff)) << 24) |
+(((__u32)(b & 0xff)) << 16) |
+(((__u32)(c & 0xff)) << 8) |
+(((__u32)(d & 0xff)) << 0));
+}
+
+static inline bool is_ip4_loopback(__be32 addr)
+{
+ return (addr & ip4_addr_octets(255,0,0,0)) ==
ip4_addr_octets(127,0,0,0);
+}
+
+static inline bool is_ip4_multicast(__be32 addr)
+{
+ return (addr & ip4_addr_octets(240,0,0,0)) ==
ip4_addr_octets(224,0,0,0);
+}
+
+static inline bool is_ip4_local_multicast(__be32 addr)
+{
+ return (addr & ip4_addr_octets(255,255,255,0)) ==
ip4_addr_octets(224,0,0,0);
+}
+
+static inline bool is_ip4_badclass(__be32 addr)
+{
+ return (addr & ip4_addr_octets(240,0,0,0)) ==
ip4_addr_octets(240,0,0,0);
+}
+
+static inline bool is_ip4_zeronet(__be32 addr)
+{
+ return (addr & ip4_addr_octets(255,0,0,0)) == ip4_addr_octets(0,0,0,0);
+}
+
/* Some random defines to make it easier in the kernel.. */
-#define LOOPBACK(x)(((x) & htonl(0xff00)) == htonl(0x7f00))
-#define MULTICAST(x) (((x) & htonl(0xf000)) == htonl(0xe000))
-#define BADCLASS(x)(((x) & htonl(0xf000)) == htonl(0xf000))
-#define ZERONET(x) (((x) & htonl(0xff00)) == htonl(0x))
-#define LOCAL_MCAST(x) (((x) & htonl(0xFF00)) == htonl(0xE000))
+
+#define LOOPBACK(x)is_ip4_loopback(x)
+#define MULTICAST(x) is_ip4_multicast(x)
+#define LOCAL_MCAST(x) is_ip4_local_multicast(x)
+#define BADCLASS(x)is_ip4_badclass(x)
+#define ZERONET(x) is_ip4_zeronet(x)
#endif
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 0/4] Convert IP4 address class macros to inline functions
Change LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and ZERONET macros to inline functions is_ip4_[type](__be32 addr) Adds some type safety and maybe some readability No change in compiled image size Signed-off-by: Joe Perches <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25 2/4] net/core - Convert IP4 address class macros to inline functions
Change LOOPBACK MULTICAST LOCAL_MCAST BADCLASS and ZERONET
macros to inline functions is_ip4_[type](__be32 addr)
Adds some type safety and maybe some readability
No change in compiled image size
Signed-off-by: Joe Perches <[EMAIL PROTECTED]>
---
net/core/netpoll.c |2 +-
net/core/pktgen.c |6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index c499b5c..bf9b4db 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -418,7 +418,7 @@ static void arp_reply(struct sk_buff *skb)
memcpy(&tip, arp_ptr, 4);
/* Should we ignore arp? */
- if (tip != htonl(np->local_ip) || LOOPBACK(tip) || MULTICAST(tip))
+ if (tip != htonl(np->local_ip) || is_ip4_loopback(tip) ||
is_ip4_multicast(tip))
return;
size = sizeof(struct arphdr) + 2 * (skb->dev->addr_len + 4);
diff --git a/net/core/pktgen.c b/net/core/pktgen.c
index de33f36..0d5ef00 100644
--- a/net/core/pktgen.c
+++ b/net/core/pktgen.c
@@ -2358,9 +2358,9 @@ static void mod_cur_headers(struct pktgen_dev *pkt_dev)
t = random32() % (imx - imn) + imn;
s = htonl(t);
- while (LOOPBACK(s) || MULTICAST(s)
- || BADCLASS(s) || ZERONET(s)
- || LOCAL_MCAST(s)) {
+ while (is_ip4_loopback(s) ||
is_ip4_multicast(s)
+ || is_ip4_badclass(s) ||
is_ip4_zeronet(s)
+ || is_ip4_local_multicast(s)) {
t = random32() % (imx - imn) +
imn;
s = htonl(t);
}
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
network protocol stack
I was going through a study of Linux TCP/IP stack performance analysis.I wanted to know more details about the link layer processing of packets--like amount of data transferred in one access from device buffer to main memory and stuff.Any suggestions or resources?? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore ethernet addresses
Scheduling for the 2.6.25 merge window is fine. Curious - why did you have to remove the driver version? We use it to keep track of our changes submitted. Thanks, Ram > -Original Message- > From: David Miller [mailto:[EMAIL PROTECTED] > Sent: Wednesday, November 14, 2007 1:43 AM > To: Sreenivasa Honnur > Cc: netdev@vger.kernel.org; [EMAIL PROTECTED]; support > Subject: Re: [PATCH 2.6.24 1/1]S2io: Support for add/delete/store/restore > ethernet addresses > > From: Sreenivasa Honnur <[EMAIL PROTECTED]> > Date: Wed, 14 Nov 2007 04:30:34 -0500 (EST) > > > - Support to add/delete/store/restore 64 and 128 Ethernet addresses for > Xframe I and Xframe II respectively. > > > > - (Resubmit third time) > > > > Signed-off-by: Sreenivasa Honnur <[EMAIL PROTECTED]> > > No, this is a feature patch, so I'm not going to queue this > up for 2.6.24, that is not appropriate at all. > > Instead I've added this patch to netdev-2.6 which will > schedule it for the 2.6.25 merge window. > > I had to remove the DRV_VERSION part of your changes as > a result. > > Thanks. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re : Re : Bug in using inet_lookup ()
By setting the ID of the ingress device to the inet_lookup() to 0, the machine
reboots automatically.
Setting proc/sys/kernel/panic* to non zero values dosn't help more..
Cheers,
- Message d'origine
> De : Evgeniy Polyakov <[EMAIL PROTECTED]>
> À : Nj A <[EMAIL PROTECTED]>
> Cc : netdev@vger.kernel.org
> Envoyé le : Mercredi, 14 Novembre 2007, 14h31mn 18s
> Objet : Re: Re : Bug in using inet_lookup ()
>
> On Wed, Nov 14, 2007 at 01:12:11PM +, Nj A ([EMAIL PROTECTED]) wrote:
> > I suspected it could be that. However, can't see in ip_rcv the right portion
> that can help.
> > Any further tip please?
>
> It is ip_rcv_finish() called from ip_rcv():
> if (skb->dst == NULL) {
> int err = ip_route_input(skb, iph->daddr, iph->saddr, iph->tos,
> skb->dev);
> if (unlikely(err)) {
> if (err == -EHOSTUNREACH)
> IP_INC_STATS_BH(IPSTATS_MIB_INADDRERRORS);
> else if (err == -ENETUNREACH)
> IP_INC_STATS_BH(IPSTATS_MIB_INNOROUTES);
> goto drop;
> }
> }
>
> So you will have to specify device, you got your skb via.
> Actually it is not exactly needed in some cases, you will need interface
> index (dev->ifindex). You can find socket by using that number instead
> of dereferencing dst.
>
> --
> Evgeniy
> Polyakov
>
_
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Use sockfd_lookup_light in the rest of the net/socket.c
Some time ago a sockfd_lookup_light was introduced and most of the socket.c file was patched to use it. However two routines were left - sys_sendto and sys_recvfrom. Patch them as well, since this helper does exactly what these two need. Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]> --- diff --git a/net/socket.c b/net/socket.c index 74784df..f8ec651 100644 --- a/net/socket.c +++ b/net/socket.c @@ -1581,16 +1581,11 @@ asmlinkage long sys_sendto(int fd, void __user *buff, size_t len, struct msghdr msg; struct iovec iov; int fput_needed; - struct file *sock_file; - sock_file = fget_light(fd, &fput_needed); - err = -EBADF; - if (!sock_file) + sock = sockfd_lookup_light(fd, &err, &fput_needed); + if (!sock) goto out; - sock = sock_from_file(sock_file, &err); - if (!sock) - goto out_put; iov.iov_base = buff; iov.iov_len = len; msg.msg_name = NULL; @@ -1612,7 +1607,7 @@ asmlinkage long sys_sendto(int fd, void __user *buff, size_t len, err = sock_sendmsg(sock, &msg, len); out_put: - fput_light(sock_file, fput_needed); + fput_light(sock->file, fput_needed); out: return err; } @@ -1641,17 +1636,11 @@ asmlinkage long sys_recvfrom(int fd, void __user *ubuf, size_t size, struct msghdr msg; char address[MAX_SOCK_ADDR]; int err, err2; - struct file *sock_file; int fput_needed; - sock_file = fget_light(fd, &fput_needed); - err = -EBADF; - if (!sock_file) - goto out; - - sock = sock_from_file(sock_file, &err); + sock = sockfd_lookup_light(fd, &err, &fput_needed); if (!sock) - goto out_put; + goto out; msg.msg_control = NULL; msg.msg_controllen = 0; @@ -1670,8 +1659,8 @@ asmlinkage long sys_recvfrom(int fd, void __user *ubuf, size_t size, if (err2 < 0) err = err2; } -out_put: - fput_light(sock_file, fput_needed); + + fput_light(sock->file, fput_needed); out: return err; } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix warning for token-ring from sysctl checker
On Wed, 14 Nov 2007 08:56:20 -0700 Eric W. Biederman wrote: > David Miller <[EMAIL PROTECTED]> writes: > > > From: Olof Johansson <[EMAIL PROTECTED]> > > Date: Tue, 13 Nov 2007 01:23:13 -0600 > > > >> As seen when booting ppc64_defconfig: > >> > >> sysctl table check failed: /net/token-ring .3.14 procname does not match > > binary path procname > >> > >> > >> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > > > > Patch applied, thanks Olof. > > No objections but I think we already have this fixed in the -mm tree. Yes, I patched it several weeks ago and it's been in -mm for a while now. Apparently too long. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25 1/4] include - Convert IP4 address class macros to inline functions
Maybe I'm more used to hex, but I personally don't think those are more readable. It replaces 1-line macroes with 4-line functions, and I think more vgrepping to pick out the relevant constant data. +-DLS - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/25] NFS: eliminate NIPQUAD(clp->cl_addr.sin_addr)
YOSHIFUJI Hideaki / 吉藤英明 wrote: In article <[EMAIL PROTECTED]> (at Tue, 13 Nov 2007 13:31:27 -0500), Chuck Lever <[EMAIL PROTECTED]> says: clp->rpc_ops->version, - NIPQUAD(clp->cl_addr.sin_addr), - ntohs(clp->cl_addr.sin_port), + rpc_peeraddr2str(clp->cl_rpcclient, RPC_DISPLAY_HEX_ADDR), + rpc_peeraddr2str(clp->cl_rpcclient, RPC_DISPLAY_HEX_PORT), atomic_read(&clp->cl_count), Is this really safe? What's unsafe about it? rpc_peeraddr2str() is designed to be called this way. begin:vcard fn:Chuck Lever n:Lever;Chuck org:Oracle Corporation;Corporate Architecture: Linux Projects Group adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA title:Principal Member of Staff tel;work:+1 248 614 5091 x-mozilla-html:FALSE version:2.1 end:vcard
Re: [PATCH] netfilter : struct xt_table_info diet
[netfilter-devel CCed] Eric Dumazet wrote: > Hi David & Patrick > > Please find a patch against net-2.6.25 > > Thank you > > > [PATCH] netfilter : struct xt_table_info diet > > Instead of using a big array of NR_CPUS entries, we can compute the size > needed at runtime, using nr_cpu_ids > > This should save some ram (especially on David's machines where NR_CPUS=4096 > : 32 KB can be saved per table, and 64KB for dynamically allocated ones > (because of slab/slub alignements) ) > > In particular, the 'bootstrap' tables are not any more static (in data > section) but on stack as their > size is now very small. > > This also should reduce the size used on stack in compat functions > (get_info() declares an automatic variable, that could be bigger than kernel > stack size for big NR_CPUS) Thanks, this looks good. One question: > diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c > index 2909c92..ed3bd0b 100644 > --- a/net/ipv4/netfilter/arp_tables.c > +++ b/net/ipv4/netfilter/arp_tables.c > @@ -811,7 +811,7 @@ static int do_replace(void __user *user, unsigned int len) > return -ENOPROTOOPT; > > /* overflow check */ > - if (tmp.size >= (INT_MAX - sizeof(struct xt_table_info)) / NR_CPUS - > + if (tmp.size >= (INT_MAX - XT_TABLE_INFO_SZ) / NR_CPUS - > SMP_CACHE_BYTES) Shouldn't NR_CPUs be replaced by nr_cpu_ids here? I'm wondering why we still include NR_CPUs in the calculation at all though, unlike in 2.4, we don't allocate one huge area of memory anymore but do one allocation per CPU. IIRC it even was you who changed that. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] New Kernel Bugs
On Wed, 14 Nov 2007 15:08:47 +0100 Ingo Molnar wrote: > > * Randy Dunlap <[EMAIL PROTECTED]> wrote: > > > > (and this is in no way directed at the networking folks - it holds > > > for all of us. I have one main complaint about networking: the > > > separate netdev list is a bad idea - networking regressions should > > > be discussed and fixed on lkml, like most other subsystems are. Any > > > artificial split of the lk discussion space is bad.) > > > > but here I disagree. LKML is already too busy and noisy. Major > > subsystems need their own discussion areas. > > That's a stupid argument. We lose much more by forced isolation of > discussion than what we win by having less traffic! It's _MUCH_ easier > to narrow down information (by filter by threads, by topics, by people, > etc.) than it is to gobble information together from various fractured > sources. We learned it _again and again_ that isolation of kernel > discussions causes bad things. > > In fact this thread is the very example: David points out that on netdev > some of those bugs were already discussed and resolved. Had it been all > on lkml we'd all be aware of it. or had been on netdev. > this is a single kernel project that is released together as one > codebase, so a central place of discussion is obvious and common-sense. Central doesn't have to mean one-and-only-one-list-for-everything. > so please stop this "too busy and too noisy" nonsense already. It was > nonsense 10 years ago and it's nonsense today. In 10 years the kernel > grew from a 1 million lines codebase to an 8 million lines codebase, so > what? Deal with it and be intelligent about filtering your information > influx instead of imposing a hard pre-filtering criteria that restricts > intelligent processing of information. So you have a preferred method of handling email. Please don't force it on the rest of us. I'll plan to use lkml-list-only when you have convinced DaveM to drop all of the other mailing lists at vger.kernel.org. Yeah, sure. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Null pointer dereference in nf_nat_move_storage(), kernel 2.6.23.1
https://bugzilla.redhat.com/show_bug.cgi?id=259501#c14 BUG: unable to handle kernel NULL pointer dereference at virtual address 064 printing eip: f8ae1087 *pde = 39644067 Oops: [#1] SMP CPU:1 EIP:0060:[]Not tainted VLI EFLAGS: 00010202 (2.6.23.1-21.fc7 #1) EIP is at nf_nat_move_storage+0x23/0x69 [nf_nat] eax: 0004 ebx: d73a1bc4 ecx: f8ae1064 edx: d73a1bc0 esi: d73a1bc0 edi: ebp: dfcb6b40 esp: c0786c74 ds: 007b es: 007b fs: 00d8 gs: ss: 0068 Process swapper (pid: 0, ti=c0786000 task=f7d02c20 task.ti=c18fd000) Stack:d657fd80 0001 f8b61643 004c 0028 f8b81260 dfcb6b40 f8c0af20 f8b5f7a5 f8b5dd73 c0786cd8 f8ae4180 130aa8c0 f8ae19dd dfcb6b40 f34b6000 dfcb6b40 0001 c0786d14 Call Trace: [] __nf_ct_ext_add+0x12f/0x1c4 [nf_conntrack] [] nf_ct_helper_ext_add+0x9/0x15 [nf_conntrack] [] nf_conntrack_alter_reply+0x73/0x96 [nf_conntrack] [] nf_nat_setup_info+0x3f3/0x54e [nf_nat] [] ipt_dnat_target+0x0/0x14c [iptable_nat] [] ipt_dnat_target+0x144/0x14c [iptable_nat] [] tcp_packet+0xa1c/0xa4b [nf_conntrack] [] skb_checksum+0x4f/0x29a [] ipt_dnat_target+0x0/0x14c [iptable_nat] [] ipt_do_table+0x3f0/0x482 [ip_tables] [] nf_conntrack_alloc+0x16d/0x1c5 [nf_conntrack] [] tcp_new+0xd1/0x1a4 [nf_conntrack] [] ipt_do_table+0x425/0x482 [ip_tables] [] nf_nat_rule_find+0x21/0x5c [iptable_nat] [] nf_nat_fn+0x165/0x189 [iptable_nat] [] nf_nat_in+0x29/0x9c [iptable_nat] [] ip_rcv_finish+0x0/0x291 [] nf_iterate+0x38/0x6a [] ip_rcv_finish+0x0/0x291 [] nf_hook_slow+0x4d/0xb5 [] ip_rcv_finish+0x0/0x291 [] ip_rcv+0x20b/0x4ba [] ip_rcv_finish+0x0/0x291 [] ktime_get_real+0xf/0x2b [] netif_receive_skb+0x2e1/0x346 [] __wake_up+0x32/0x43 [] e100_poll+0x166/0x2b5 [e100] [] __slab_free+0x5c/0x216 [] net_rx_action+0x9a/0x196 [] __do_softirq+0x66/0xd3 [] do_softirq+0x6c/0xce [] tick_do_update_jiffies64+0x93/0xa8 [] handle_fasteoi_irq+0x0/0xa6 [] irq_exit+0x38/0x6b [] do_IRQ+0x9f/0xb9 [] default_idle+0x0/0x55 [] common_interrupt+0x23/0x28 [] default_idle+0x0/0x55 [] save_v86_state+0x19/0x12b [] native_safe_halt+0x2/0x3 [] default_idle+0x39/0x55 [] cpu_idle+0xab/0xcc === Code: 64 0f fe ff ff 31 c0 c3 57 56 89 d6 53 8b 90 ec 00 00 00 85 d2 74 0f 8a 42 01 84 c0 74 08 0f b6 c0 8d 1c 02 eb 02 31 db 8b 7e 18 47 64 80 01 00 00 74 39 b8 40 41 ae f8 e8 fd b7 b3 c7 8b 16 nf_nat_move_storage(): /usr/src/debug/kernel-2.6.23/linux-2.6.23.i686/net/ipv4/netfilter/nf_nat_core.c:612 87: f7 47 64 80 01 00 00testl $0x180,0x64(%edi) 8e: 74 39 je c9 line 612: if (!(ct->status & IPS_NAT_DONE_MASK)) return; ct is NULL - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] netfilter : struct xt_table_info diet
On Wed, 14 Nov 2007 18:19:41 +0100 Patrick McHardy <[EMAIL PROTECTED]> wrote: > [netfilter-devel CCed] > > Eric Dumazet wrote: > > Hi David & Patrick > > > > Please find a patch against net-2.6.25 > > > > Thank you > > > > > > [PATCH] netfilter : struct xt_table_info diet > > > > Instead of using a big array of NR_CPUS entries, we can compute the size > > needed at runtime, using nr_cpu_ids > > > > This should save some ram (especially on David's machines where > > NR_CPUS=4096 : 32 KB can be saved per table, and 64KB for dynamically > > allocated ones (because of slab/slub alignements) ) > > > > In particular, the 'bootstrap' tables are not any more static (in data > > section) but on stack as their > > size is now very small. > > > > This also should reduce the size used on stack in compat functions > > (get_info() declares an automatic variable, that could be bigger than > > kernel stack size for big NR_CPUS) > > > Thanks, this looks good. One question: > > > diff --git a/net/ipv4/netfilter/arp_tables.c > > b/net/ipv4/netfilter/arp_tables.c > > index 2909c92..ed3bd0b 100644 > > --- a/net/ipv4/netfilter/arp_tables.c > > +++ b/net/ipv4/netfilter/arp_tables.c > > @@ -811,7 +811,7 @@ static int do_replace(void __user *user, unsigned int > > len) > > return -ENOPROTOOPT; > > > > /* overflow check */ > > - if (tmp.size >= (INT_MAX - sizeof(struct xt_table_info)) / NR_CPUS - > > + if (tmp.size >= (INT_MAX - XT_TABLE_INFO_SZ) / NR_CPUS - > > SMP_CACHE_BYTES) > > > Shouldn't NR_CPUs be replaced by nr_cpu_ids here? I'm wondering > why we still include NR_CPUs in the calculation at all though, > unlike in 2.4, we don't allocate one huge area of memory anymore > but do one allocation per CPU. IIRC it even was you who changed > that. > Yes, doing an allocation per possible cpu was better than one giant allocation (memory savings and NUMA aware) Well, technically speaking you are right, we may also replace these divides per NR_CPUS by nr_cpu_ids (or even better : num_possible_cpus()) Because with NR_CPUS=4096, we actually limit tmp.size to about 524000, what a shame ! :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: Documentation update
12. Configuring Bonding for Maximum Throughput == @@ -1684,7 +1757,7 @@ balance-rr: This mode is the only mode that will permit a single interfaces. It is therefore the only mode that will allow a single TCP/IP stream to utilize more than one interface's worth of throughput. This comes at a cost, however: the - striping often results in peer systems receiving packets out + striping generally results in peer systems receiving packets out of order, causing TCP/IP's congestion control system to kick in, often by retransmitting segments. @@ -1696,22 +1769,20 @@ balance-rr: This mode is the only mode that will permit a single interface's worth of throughput, even after adjusting tcp_reordering. - Note that this out of order delivery occurs when both the - sending and receiving systems are utilizing a multiple - interface bond. Consider a configuration in which a - balance-rr bond feeds into a single higher capacity network - channel (e.g., multiple 100Mb/sec ethernets feeding a single - gigabit ethernet via an etherchannel capable switch). In this - configuration, traffic sent from the multiple 100Mb devices to - a destination connected to the gigabit device will not see - packets out of order. However, traffic sent from the gigabit - device to the multiple 100Mb devices may or may not see - traffic out of order, depending upon the balance policy of the - switch. Many switches do not support any modes that stripe - traffic (instead choosing a port based upon IP or MAC level - addresses); for those devices, traffic flowing from the - gigabit device to the many 100Mb devices will only utilize one - interface. + Note that the fraction of packets that will be delivered out of + order is highly variable, and is unlikely to be zero. The level + of reordering depends upon a variety of factors, including the + networking interfaces, the switch, and the topology of the + configuration. Speaking in general terms, higher speed network + cards produce more reordering (due to factors such as packet + coalescing), and a "many to many" topology will reorder at a + higher rate than a "many slow to one fast" configuration. Not quibbling with the wording, but when you have a chance I would be curious to see the data for the percentages of many to many vs many to one. + Many switches do not support any modes that stripe traffic + (instead choosing a port based upon IP or MAC level addresses); + for those devices, traffic for a particular connection flowing + through the switch to a balance-rr bond will not utilize greater + than one interface's worth of bandwidth. Shouldn't that be "Many switches do not support any modes that stripe traffic of a single flow?" Shame that port is such an overloaded term. If you are utilizing protocols other than TCP/IP, UDP for example, and your application can tolerate out of order @@ -1911,6 +1982,10 @@ Failover may be delayed via the downdelay bonding module option. 13.2 Duplicated Incoming Packets + NOTE: Starting with version 3.0.2, the bonding driver has logic to +suppress duplicate packets, which should largely eliminate this problem. +The following description is kept for reference. + It is not uncommon to observe a short burst of duplicated traffic when the bonding device is first used, or after it has been idle for some period of time. This is most easily observed by issuing @@ -2071,6 +2146,9 @@ The new driver was designed to be SMP safe from the start. EtherExpress PRO/100 and a 3com 3c905b, for example). For most modes, devices need not be of the same speed. + Starting with version 3.2.1, bonding also supports Infiniband +slaves in active-backup mode. + 3. How many bonding devices can I have? There is no limit. @@ -2129,11 +2207,15 @@ switches currently available support 802.3ad. 8. Where does a bonding device get its MAC address from? Not part of your change, but since you are editing the section, drop the "from" in the section title, or perhaps put it at the beginning so we don't have a dangling whatchamacallit. rick jones - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/3] IPVS: Use CTL_UNNUMBERED
Hi, this series of three patches, the first of which is by Christian Borntraeger, switches IPVS over to use CTL_UNNUMBERED, removing a lot of unused cruft. -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/3] IPVS: Fix sysctl warnings about missing strategy in schedulers
sysctl table check failed: /net/ipv4/vs/lblc_expiration .3.5.21.19 Missing
strategy
[...]
sysctl table check failed: /net/ipv4/vs/lblcr_expiration .3.5.21.20 Missing
strategy
Switch these entried over to use CTL_UNNUMBERED as clearly
the sys_syscal portion wasn't working.
This is along the same lines as Christian Borntraeger's patch that fixes
up entries with no stratergy in net/ipv4/ipvs/ip_vs_ctl.c
Cc: Eric W. Biederman <[EMAIL PROTECTED]>
Cc: Wensong Zhang <[EMAIL PROTECTED]>
Cc: Julian Anastasov <[EMAIL PROTECTED]>
Cc: Christian Borntraeger <[EMAIL PROTECTED]>
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
---
include/net/ip_vs.h |2 --
kernel/sysctl_check.c |2 --
net/ipv4/ipvs/ip_vs_lblc.c |1 -
net/ipv4/ipvs/ip_vs_lblcr.c |1 -
4 files changed, 6 deletions(-)
Index: net-2.6/include/net/ip_vs.h
===
--- net-2.6.orig/include/net/ip_vs.h2007-11-14 09:37:57.0 -0800
+++ net-2.6/include/net/ip_vs.h 2007-11-14 09:38:07.0 -0800
@@ -348,8 +348,6 @@ enum {
NET_IPV4_VS_TO_SA=16,
NET_IPV4_VS_TO_UDP=17,
NET_IPV4_VS_TO_ICMP=18,
- NET_IPV4_VS_LBLC_EXPIRE=19,
- NET_IPV4_VS_LBLCR_EXPIRE=20,
NET_IPV4_VS_CACHE_BYPASS=22,
NET_IPV4_VS_EXPIRE_NODEST_CONN=23,
NET_IPV4_VS_NAT_ICMP_SEND=25,
Index: net-2.6/kernel/sysctl_check.c
===
--- net-2.6.orig/kernel/sysctl_check.c 2007-11-14 09:36:10.0 -0800
+++ net-2.6/kernel/sysctl_check.c 2007-11-14 09:37:50.0 -0800
@@ -258,8 +258,6 @@ static struct trans_ctl_table trans_net_
{ NET_IPV4_VS_EXPIRE_NODEST_CONN, "expire_nodest_conn" },
{ NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE,
"expire_quiescent_template" },
{ NET_IPV4_VS_NAT_ICMP_SEND,"nat_icmp_send" },
- { NET_IPV4_VS_LBLC_EXPIRE, "lblc_expiration" },
- { NET_IPV4_VS_LBLCR_EXPIRE, "lblcr_expiration" },
{}
};
Index: net-2.6/net/ipv4/ipvs/ip_vs_lblc.c
===
--- net-2.6.orig/net/ipv4/ipvs/ip_vs_lblc.c 2007-11-14 09:35:17.0
-0800
+++ net-2.6/net/ipv4/ipvs/ip_vs_lblc.c 2007-11-14 09:36:01.0 -0800
@@ -114,7 +114,6 @@ struct ip_vs_lblc_table {
static ctl_table vs_vars_table[] = {
{
- .ctl_name = NET_IPV4_VS_LBLC_EXPIRE,
.procname = "lblc_expiration",
.data = &sysctl_ip_vs_lblc_expiration,
.maxlen = sizeof(int),
Index: net-2.6/net/ipv4/ipvs/ip_vs_lblcr.c
===
--- net-2.6.orig/net/ipv4/ipvs/ip_vs_lblcr.c2007-11-14 09:35:19.0
-0800
+++ net-2.6/net/ipv4/ipvs/ip_vs_lblcr.c 2007-11-14 09:35:48.0 -0800
@@ -302,7 +302,6 @@ struct ip_vs_lblcr_table {
static ctl_table vs_vars_table[] = {
{
- .ctl_name = NET_IPV4_VS_LBLCR_EXPIRE,
.procname = "lblcr_expiration",
.data = &sysctl_ip_vs_lblcr_expiration,
.maxlen = sizeof(int),
--
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/3] IPVS: Fix sysctl warnings about missing strategy
From: Christian Borntraeger <[EMAIL PROTECTED]>
Running the latest git code I get the following messages during boot:
sysctl table check failed: /net/ipv4/vs/drop_entry .3.5.21.4 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/drop_packet .3.5.21.5 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/secure_tcp .3.5.21.6 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/sync_threshold .3.5.21.24 Missing
strategy
I removed the binary sysctl handler for those messages and also removed
the definitions in ip_vs.h. The alternative would be to implement a
proper strategy handler, but syscall sysctl is deprecated.
There are other sysctl definitions that are commented out or work with
the default sysctl_data strategy. I did not touch these.
Eric, IPVS team, are you ok with that change?
CC: Eric W. Biederman <[EMAIL PROTECTED]>
CC: Wensong Zhang <[EMAIL PROTECTED]>
CC: Julian Anastasov <[EMAIL PROTECTED]>
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
Acked-by: Simon Horman <[EMAIL PROTECTED]>
---
include/net/ip_vs.h |4
kernel/sysctl_check.c |4
net/ipv4/ipvs/ip_vs_ctl.c |4
3 files changed, 12 deletions(-)
Index: linux-2.6/include/net/ip_vs.h
===
--- linux-2.6.orig/include/net/ip_vs.h
+++ linux-2.6/include/net/ip_vs.h
@@ -336,9 +336,6 @@ enum {
NET_IPV4_VS_DEBUG_LEVEL=1,
NET_IPV4_VS_AMEMTHRESH=2,
NET_IPV4_VS_AMDROPRATE=3,
- NET_IPV4_VS_DROP_ENTRY=4,
- NET_IPV4_VS_DROP_PACKET=5,
- NET_IPV4_VS_SECURE_TCP=6,
NET_IPV4_VS_TO_ES=7,
NET_IPV4_VS_TO_SS=8,
NET_IPV4_VS_TO_SR=9,
@@ -355,7 +352,6 @@ enum {
NET_IPV4_VS_LBLCR_EXPIRE=20,
NET_IPV4_VS_CACHE_BYPASS=22,
NET_IPV4_VS_EXPIRE_NODEST_CONN=23,
- NET_IPV4_VS_SYNC_THRESHOLD=24,
NET_IPV4_VS_NAT_ICMP_SEND=25,
NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE=26,
NET_IPV4_VS_LAST
Index: linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
===
--- linux-2.6.orig/net/ipv4/ipvs/ip_vs_ctl.c
+++ linux-2.6/net/ipv4/ipvs/ip_vs_ctl.c
@@ -1451,7 +1451,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_dointvec,
},
{
- .ctl_name = NET_IPV4_VS_DROP_ENTRY,
.procname = "drop_entry",
.data = &sysctl_ip_vs_drop_entry,
.maxlen = sizeof(int),
@@ -1459,7 +1458,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_do_defense_mode,
},
{
- .ctl_name = NET_IPV4_VS_DROP_PACKET,
.procname = "drop_packet",
.data = &sysctl_ip_vs_drop_packet,
.maxlen = sizeof(int),
@@ -1467,7 +1465,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_do_defense_mode,
},
{
- .ctl_name = NET_IPV4_VS_SECURE_TCP,
.procname = "secure_tcp",
.data = &sysctl_ip_vs_secure_tcp,
.maxlen = sizeof(int),
@@ -1597,7 +1594,6 @@ static struct ctl_table vs_vars[] = {
.proc_handler = &proc_dointvec,
},
{
- .ctl_name = NET_IPV4_VS_SYNC_THRESHOLD,
.procname = "sync_threshold",
.data = &sysctl_ip_vs_sync_threshold,
.maxlen = sizeof(sysctl_ip_vs_sync_threshold),
Index: linux-2.6/kernel/sysctl_check.c
===
--- linux-2.6.orig/kernel/sysctl_check.c
+++ linux-2.6/kernel/sysctl_check.c
@@ -242,9 +242,6 @@ static struct trans_ctl_table trans_net_
{ NET_IPV4_VS_AMEMTHRESH, "amemthresh" },
{ NET_IPV4_VS_DEBUG_LEVEL, "debug_level" },
{ NET_IPV4_VS_AMDROPRATE, "am_droprate" },
- { NET_IPV4_VS_DROP_ENTRY, "drop_entry" },
- { NET_IPV4_VS_DROP_PACKET, "drop_packet" },
- { NET_IPV4_VS_SECURE_TCP, "secure_tcp" },
{ NET_IPV4_VS_TO_ES,"timeout_established" },
{ NET_IPV4_VS_TO_SS,"timeout_synsent" },
{ NET_IPV4_VS_TO_SR,"timeout_synrecv" },
@@ -260,7 +257,6 @@ static struct trans_ctl_table trans_net_
{ NET_IPV4_VS_CACHE_BYPASS, "cache_bypass" },
{ NET_IPV4_VS_EXPIRE_NODEST_CONN, "expire_nodest_conn" },
{ NET_IPV4_VS_EXPIRE_QUIESCENT_TEMPLATE,
"expire_quiescent_template" },
- { NET_IPV4_VS_SYNC_THRESHOLD, "sync_threshold" },
{ NET_IPV4_VS_NAT_ICMP_SEND,"nat_icmp_send" },
{ NET_IPV4_VS_LBLC_EXPIRE, "lblc_expiration" },
{ NET_IPV4_VS_LBLCR_EXPIRE, "lblcr_expiration" },
--
--
Horms
H: http://www.verge
