* Fw: Netpoll checksum issue
From: Stephen Hemminger @ 2006-04-19 17:15 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
Begin forwarded message:
Date: Thu, 20 Apr 2006 00:22:16 +0800
From: Aubrey <aubreylee@gmail.com>
Newsgroups: linux.dev.kernel
Subject: Netpoll checksum issue
Hi all,
I'm porting my network driver from 2.6.12 to 2.6.16. It almostly work
without any change, except the netpoll mode. When I use kgdb to debug
kernel, gdb client can not establish the connection with gdb server.
Then I digged into the code, and I found in the routine "__netpoll_rx"
in the file "net/core/netpoll.c", the "checksum_udp" call always
failed, but it works on 2.6.12.
Could you please give me some suggestions?
Thanks a lot.
Regards,
-Aubrey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [RFC] Netlink and user-space buffer pointers
From: Patrick McHardy @ 2006-04-19 17:16 UTC (permalink / raw)
To: James.Smart; +Cc: linux-scsi, netdev, linux-kernel
In-Reply-To: <44466EA7.3030206@emulex.com>
James Smart wrote:
>
>
> Patrick McHardy wrote:
>
>> This might be problematic, since there is a shared receive-queue in
>> the kernel netlink message might get processed in the context of
>> a different process. I didn't find any spots where ISCSI passes
>> pointers over netlink, can you point me to it?
>
>
> Please explain... Would the pid be set erroneously as well ? Ignoring
> the kernel-user space pointer issue, we're going to have a tight
> pid + request_id relationship being maintained across multiple messages.
> We'll also be depending on the pid events for clean up if an app dies.
> So I hope pid is consistent.
The PID contained in the netlink message itself is correct, current->pid
might not be.
^ permalink raw reply
* Re: I/OAT: Call for discussion
From: John Ronciak @ 2006-04-19 17:28 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Grover, Andrew, netdev
In-Reply-To: <20060419101217.0f5d84cf@localhost.localdomain>
On 4/19/06, Stephen Hemminger <shemminger@osdl.org> wrote:
> Off list lobbying usually has a negative impact.
The lobbying was for vendor inclusion and not necessarily for upstream
acceptance.
> The biggest barrier at this point seems to be hardware availability.
> People generally don't care unless they use or are going to get that hardware.
> Also the big benchmark data, although interesting, is usually only
> interesting to vendors.
The hardware is going to generally available in June. There are also
lots of OEMs, OSVs and hardware vendors that have the system to test
on today. The early rollout of hardware has been very large.
>
> You probably will have to suffer out of tree for a while until the hardware
> becomes more available. When the hardware is more common, then the implementation
> details will be sorted out. Also after the 2+ years of getting TSO to work
> right, maybe the developers are a little gun shy at this point.
Some OSVs (at least one very large one) is supporting it.
John
^ permalink raw reply
* Re: Netpoll checksum issue
From: Stephen Hemminger @ 2006-04-19 17:31 UTC (permalink / raw)
To: Aubrey, Herbert Xu; +Cc: netdev
In-Reply-To: <6d6a94c50604190922m189b9d99gdd428a870e12c2c3@mail.gmail.com>
The changes to how hardware receive checksums are handled broke
the netpoll checksum code (for CHECKSUM_HW). Since this is not at
all performance critical, try this patch. It changes to always to
normal software checksum.
--- linux-2.6.orig/net/core/netpoll.c 2006-03-22 09:30:56.000000000 -0800
+++ linux-2.6/net/core/netpoll.c 2006-04-19 10:30:13.000000000 -0700
@@ -102,20 +102,11 @@
static int checksum_udp(struct sk_buff *skb, struct udphdr *uh,
unsigned short ulen, u32 saddr, u32 daddr)
{
- unsigned int psum;
-
if (uh->check == 0 || skb->ip_summed == CHECKSUM_UNNECESSARY)
return 0;
- psum = csum_tcpudp_nofold(saddr, daddr, ulen, IPPROTO_UDP, 0);
-
- if (skb->ip_summed == CHECKSUM_HW &&
- !(u16)csum_fold(csum_add(psum, skb->csum)))
- return 0;
-
- skb->csum = psum;
-
- return __skb_checksum_complete(skb);
+ skb->csum = csum_tcpudp_nofold(saddr, daddr, ulen, IPPROTO_UDP, 0);
+ return (u16) csum_fold(skb_checksum(skb, 0, skb->len, skb->csum));
}
/*
^ permalink raw reply
* Fw: [Bugme-new] [Bug 6409] New: llc_rcv doesn't handle receives using nr_frags and frags[]
From: Andrew Morton @ 2006-04-19 18:38 UTC (permalink / raw)
To: netdev
Cc: Arnaldo Carvalho de Melo, Jesse Brandeburg,
bugme-daemon@kernel-bugs.osdl.org
Begin forwarded message:
Date: Wed, 19 Apr 2006 11:32:18 -0700
From: bugme-daemon@bugzilla.kernel.org
To: bugme-new@lists.osdl.org
Subject: [Bugme-new] [Bug 6409] New: llc_rcv doesn't handle receives using nr_frags and frags[]
http://bugzilla.kernel.org/show_bug.cgi?id=6409
Summary: llc_rcv doesn't handle receives using nr_frags and
frags[]
Kernel Version: 2.6.16
Status: NEW
Severity: normal
Owner: acme@conectiva.com.br
Submitter: jesse.brandeburg@intel.com
Most recent kernel where this bug did not occur:
Distribution: n/a
Hardware Environment: i686
Software Environment: n/a
Problem Description:
after hitting a *very hard to repro* BUG in a distro kernel I did some code
inspection that seems to show that llc_rcv does not handle receive packets using
skb->data *and* skb_shinfo(skb)->frags[]/nr_frags
Steps to reproduce:
Apparently receiving some netware (802_2) traffic when using one of the
PCI-Express e1000 adapters with packet splitting enabled. Even if the packet is
not split a large frame will use skb->data and ->frags[]
Analysis:
llc_rcv
does a skb_clone inside skb_share_check
llc_fixup_skb
skb_trim
__skb_trim
___pskb_trim(x,x,0) <-- realloc set to 0
___pskb_trim BUG on !realloc inside skb_cloned check
I'll attach the trace from the vendor kernel, I believe the problem is still
relevant to 2.6.16.
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply
* [PATCH] au1000_eth.c probe code straightened up
From: Sergei Shtylyov @ 2006-04-19 18:46 UTC (permalink / raw)
To: jgarzik; +Cc: Rodolfo Giometti, netdev, Linux-MIPS
In-Reply-To: <20060406155011.GC23424@enneenne.com>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
Straighten up the AMD Au1xx0 Ethernet probing code, make it print out (and
store in the 'net_device' structure) the physical address of the controller,
not the KSEG1-based virtual. Make the driver also claim/release the 4-byte MAC
enable registers and assign to the Ethernet ports two consecutive MAC
addresses to match those that are printed on their stickers.
Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
[-- Attachment #2: au1000_eth-probe-rewrite.patch --]
[-- Type: text/plain, Size: 10374 bytes --]
diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index 1363083..d5dfc78 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -2,7 +2,7 @@
*
* Alchemy Au1x00 ethernet driver
*
- * Copyright 2001,2002,2003 MontaVista Software Inc.
+ * Copyright 2001-2003, 2006 MontaVista Software Inc.
* Copyright 2002 TimeSys Corp.
* Added ethtool/mii-tool support,
* Copyright 2004 Matt Porter <mporter@kernel.crashing.org>
@@ -67,7 +67,7 @@ static int au1000_debug = 5;
static int au1000_debug = 3;
#endif
-#define DRV_NAME "au1000eth"
+#define DRV_NAME "au1000_eth"
#define DRV_VERSION "1.5"
#define DRV_AUTHOR "Pete Popov <ppopov@embeddedalley.com>"
#define DRV_DESC "Au1xxx on-chip Ethernet driver"
@@ -79,7 +79,7 @@ MODULE_LICENSE("GPL");
// prototypes
static void hard_stop(struct net_device *);
static void enable_rx_tx(struct net_device *dev);
-static struct net_device * au1000_probe(u32 ioaddr, int irq, int port_num);
+static struct net_device * au1000_probe(int port_num);
static int au1000_init(struct net_device *);
static int au1000_open(struct net_device *);
static int au1000_close(struct net_device *);
@@ -1159,12 +1159,27 @@ setup_hw_rings(struct au1000_private *au
}
static struct {
- int port;
u32 base_addr;
u32 macen_addr;
int irq;
struct net_device *dev;
-} iflist[2];
+} iflist[2] = {
+#ifdef CONFIG_SOC_AU1000
+ {AU1000_ETH0_BASE, AU1000_MAC0_ENABLE, AU1000_MAC0_DMA_INT},
+ {AU1000_ETH1_BASE, AU1000_MAC1_ENABLE, AU1000_MAC1_DMA_INT}
+#endif
+#ifdef CONFIG_SOC_AU1100
+ {AU1100_ETH0_BASE, AU1100_MAC0_ENABLE, AU1100_MAC0_DMA_INT}
+#endif
+#ifdef CONFIG_SOC_AU1500
+ {AU1500_ETH0_BASE, AU1500_MAC0_ENABLE, AU1500_MAC0_DMA_INT},
+ {AU1500_ETH1_BASE, AU1500_MAC1_ENABLE, AU1500_MAC1_DMA_INT}
+#endif
+#ifdef CONFIG_SOC_AU1550
+ {AU1550_ETH0_BASE, AU1550_MAC0_ENABLE, AU1550_MAC0_DMA_INT},
+ {AU1550_ETH1_BASE, AU1550_MAC1_ENABLE, AU1550_MAC1_DMA_INT}
+#endif
+};
static int num_ifs;
@@ -1175,58 +1190,14 @@ static int num_ifs;
*/
static int __init au1000_init_module(void)
{
- struct cpuinfo_mips *c = ¤t_cpu_data;
int ni = (int)((au_readl(SYS_PINFUNC) & (u32)(SYS_PF_NI2)) >> 4);
struct net_device *dev;
int i, found_one = 0;
- switch (c->cputype) {
-#ifdef CONFIG_SOC_AU1000
- case CPU_AU1000:
- num_ifs = 2 - ni;
- iflist[0].base_addr = AU1000_ETH0_BASE;
- iflist[1].base_addr = AU1000_ETH1_BASE;
- iflist[0].macen_addr = AU1000_MAC0_ENABLE;
- iflist[1].macen_addr = AU1000_MAC1_ENABLE;
- iflist[0].irq = AU1000_MAC0_DMA_INT;
- iflist[1].irq = AU1000_MAC1_DMA_INT;
- break;
-#endif
-#ifdef CONFIG_SOC_AU1100
- case CPU_AU1100:
- num_ifs = 1 - ni;
- iflist[0].base_addr = AU1100_ETH0_BASE;
- iflist[0].macen_addr = AU1100_MAC0_ENABLE;
- iflist[0].irq = AU1100_MAC0_DMA_INT;
- break;
-#endif
-#ifdef CONFIG_SOC_AU1500
- case CPU_AU1500:
- num_ifs = 2 - ni;
- iflist[0].base_addr = AU1500_ETH0_BASE;
- iflist[1].base_addr = AU1500_ETH1_BASE;
- iflist[0].macen_addr = AU1500_MAC0_ENABLE;
- iflist[1].macen_addr = AU1500_MAC1_ENABLE;
- iflist[0].irq = AU1500_MAC0_DMA_INT;
- iflist[1].irq = AU1500_MAC1_DMA_INT;
- break;
-#endif
-#ifdef CONFIG_SOC_AU1550
- case CPU_AU1550:
- num_ifs = 2 - ni;
- iflist[0].base_addr = AU1550_ETH0_BASE;
- iflist[1].base_addr = AU1550_ETH1_BASE;
- iflist[0].macen_addr = AU1550_MAC0_ENABLE;
- iflist[1].macen_addr = AU1550_MAC1_ENABLE;
- iflist[0].irq = AU1550_MAC0_DMA_INT;
- iflist[1].irq = AU1550_MAC1_DMA_INT;
- break;
-#endif
- default:
- num_ifs = 0;
- }
+ num_ifs = NUM_ETH_INTERFACES - ni;
+
for(i = 0; i < num_ifs; i++) {
- dev = au1000_probe(iflist[i].base_addr, iflist[i].irq, i);
+ dev = au1000_probe(i);
iflist[i].dev = dev;
if (dev)
found_one++;
@@ -1435,8 +1406,7 @@ static struct ethtool_ops au1000_ethtool
.get_link = au1000_get_link
};
-static struct net_device *
-au1000_probe(u32 ioaddr, int irq, int port_num)
+static struct net_device * au1000_probe(int port_num)
{
static unsigned version_printed = 0;
struct au1000_private *aup = NULL;
@@ -1444,94 +1414,95 @@ au1000_probe(u32 ioaddr, int irq, int po
db_dest_t *pDB, *pDBfree;
char *pmac, *argptr;
char ethaddr[6];
- int i, err;
+ int irq, i, err;
+ u32 base, macen;
+
+ if (port_num >= NUM_ETH_INTERFACES)
+ return NULL;
- if (!request_mem_region(CPHYSADDR(ioaddr), MAC_IOSIZE, "Au1x00 ENET"))
+ base = CPHYSADDR(iflist[port_num].base_addr );
+ macen = CPHYSADDR(iflist[port_num].macen_addr);
+ irq = iflist[port_num].irq;
+
+ if (!request_mem_region( base, MAC_IOSIZE, "Au1x00 ENET") ||
+ !request_mem_region(macen, 4, "Au1x00 ENET"))
return NULL;
- if (version_printed++ == 0)
+ if (version_printed++ == 0)
printk("%s version %s %s\n", DRV_NAME, DRV_VERSION, DRV_AUTHOR);
dev = alloc_etherdev(sizeof(struct au1000_private));
if (!dev) {
- printk (KERN_ERR "au1000 eth: alloc_etherdev failed\n");
+ printk(KERN_ERR "%s: alloc_etherdev failed\n", DRV_NAME);
return NULL;
}
- if ((err = register_netdev(dev))) {
- printk(KERN_ERR "Au1x_eth Cannot register net device err %d\n",
- err);
+ if ((err = register_netdev(dev)) != 0) {
+ printk(KERN_ERR "%s: Cannot register net device, error %d\n",
+ DRV_NAME, err);
free_netdev(dev);
return NULL;
}
- printk("%s: Au1x Ethernet found at 0x%x, irq %d\n",
- dev->name, ioaddr, irq);
+ printk("%s: Au1xx0 Ethernet found at 0x%x, irq %d\n",
+ dev->name, base, irq);
aup = dev->priv;
/* Allocate the data buffers */
/* Snooping works fine with eth on all au1xxx */
- aup->vaddr = (u32)dma_alloc_noncoherent(NULL,
- MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS),
- &aup->dma_addr,
- 0);
+ aup->vaddr = (u32)dma_alloc_noncoherent(NULL, MAX_BUF_SIZE *
+ (NUM_TX_BUFFS + NUM_RX_BUFFS),
+ &aup->dma_addr, 0);
if (!aup->vaddr) {
free_netdev(dev);
- release_mem_region(CPHYSADDR(ioaddr), MAC_IOSIZE);
+ release_mem_region( base, MAC_IOSIZE);
+ release_mem_region(macen, 4);
return NULL;
}
/* aup->mac is the base address of the MAC's registers */
- aup->mac = (volatile mac_reg_t *)((unsigned long)ioaddr);
+ aup->mac = (volatile mac_reg_t *)iflist[port_num].base_addr;
+
/* Setup some variables for quick register address access */
- if (ioaddr == iflist[0].base_addr)
- {
- /* check env variables first */
- if (!get_ethernet_addr(ethaddr)) {
+ aup->enable = (volatile u32 *)iflist[port_num].macen_addr;
+ aup->mac_id = port_num;
+ au_macs[port_num] = aup;
+
+ if (port_num == 0) {
+ /* Check the environment variables first */
+ if (get_ethernet_addr(ethaddr) == 0)
memcpy(au1000_mac_addr, ethaddr, sizeof(au1000_mac_addr));
- } else {
+ else {
/* Check command line */
argptr = prom_getcmdline();
- if ((pmac = strstr(argptr, "ethaddr=")) == NULL) {
- printk(KERN_INFO "%s: No mac address found\n",
- dev->name);
- /* use the hard coded mac addresses */
- } else {
+ if ((pmac = strstr(argptr, "ethaddr=")) == NULL)
+ printk(KERN_INFO "%s: No MAC address found\n",
+ dev->name);
+ /* Use the hard coded MAC addresses */
+ else {
str2eaddr(ethaddr, pmac + strlen("ethaddr="));
memcpy(au1000_mac_addr, ethaddr,
- sizeof(au1000_mac_addr));
+ sizeof(au1000_mac_addr));
}
}
- aup->enable = (volatile u32 *)
- ((unsigned long)iflist[0].macen_addr);
- memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr));
+
setup_hw_rings(aup, MAC0_RX_DMA_ADDR, MAC0_TX_DMA_ADDR);
- aup->mac_id = 0;
- au_macs[0] = aup;
- }
- else
- if (ioaddr == iflist[1].base_addr)
- {
- aup->enable = (volatile u32 *)
- ((unsigned long)iflist[1].macen_addr);
- memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr));
- dev->dev_addr[4] += 0x10;
+ } else if (port_num == 1)
setup_hw_rings(aup, MAC1_RX_DMA_ADDR, MAC1_TX_DMA_ADDR);
- aup->mac_id = 1;
- au_macs[1] = aup;
- }
- else
- {
- printk(KERN_ERR "%s: bad ioaddr\n", dev->name);
- }
- /* bring the device out of reset, otherwise probing the mii
- * will hang */
+ /*
+ * Assign to the Ethernet ports two consecutive MAC addresses
+ * to match those that are printed on their stickers
+ */
+ memcpy(dev->dev_addr, au1000_mac_addr, sizeof(au1000_mac_addr));
+ dev->dev_addr[5] += port_num;
+
+ /* Bring the device out of reset, otherwise probing the MII will hang */
*aup->enable = MAC_EN_CLOCK_ENABLE;
au_sync_delay(2);
- *aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 |
- MAC_EN_RESET2 | MAC_EN_CLOCK_ENABLE;
+ *aup->enable = MAC_EN_RESET0 | MAC_EN_RESET1 | MAC_EN_RESET2 |
+ MAC_EN_CLOCK_ENABLE;
au_sync_delay(2);
aup->mii = kmalloc(sizeof(struct mii_phy), GFP_KERNEL);
@@ -1580,7 +1551,7 @@ au1000_probe(u32 ioaddr, int irq, int po
}
spin_lock_init(&aup->lock);
- dev->base_addr = ioaddr;
+ dev->base_addr = base;
dev->irq = irq;
dev->open = au1000_open;
dev->hard_start_xmit = au1000_tx;
@@ -1614,13 +1585,12 @@ err_out:
if (aup->tx_db_inuse[i])
ReleaseDB(aup, aup->tx_db_inuse[i]);
}
- dma_free_noncoherent(NULL,
- MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS),
- (void *)aup->vaddr,
- aup->dma_addr);
+ dma_free_noncoherent(NULL, MAX_BUF_SIZE * (NUM_TX_BUFFS + NUM_RX_BUFFS),
+ (void *)aup->vaddr, aup->dma_addr);
unregister_netdev(dev);
free_netdev(dev);
- release_mem_region(CPHYSADDR(ioaddr), MAC_IOSIZE);
+ release_mem_region( base, MAC_IOSIZE);
+ release_mem_region(macen, 4);
return NULL;
}
@@ -1805,20 +1775,18 @@ static void __exit au1000_cleanup_module
aup = (struct au1000_private *) dev->priv;
unregister_netdev(dev);
kfree(aup->mii);
- for (j = 0; j < NUM_RX_DMA; j++) {
+ for (j = 0; j < NUM_RX_DMA; j++)
if (aup->rx_db_inuse[j])
ReleaseDB(aup, aup->rx_db_inuse[j]);
- }
- for (j = 0; j < NUM_TX_DMA; j++) {
+ for (j = 0; j < NUM_TX_DMA; j++)
if (aup->tx_db_inuse[j])
ReleaseDB(aup, aup->tx_db_inuse[j]);
- }
- dma_free_noncoherent(NULL,
- MAX_BUF_SIZE * (NUM_TX_BUFFS+NUM_RX_BUFFS),
- (void *)aup->vaddr,
- aup->dma_addr);
+ dma_free_noncoherent(NULL, MAX_BUF_SIZE *
+ (NUM_TX_BUFFS + NUM_RX_BUFFS),
+ (void *)aup->vaddr, aup->dma_addr);
+ release_mem_region(dev->base_addr, MAC_IOSIZE);
+ release_mem_region(CPHYSADDR(iflist[i].macen_addr), 4);
free_netdev(dev);
- release_mem_region(CPHYSADDR(iflist[i].base_addr), MAC_IOSIZE);
}
}
}
^ permalink raw reply related
* [PATCH] sockfd_lookup_light() returns random error for -EBADFD
From: Hua Zhong @ 2006-04-19 19:01 UTC (permalink / raw)
To: Linux-kernel, netdev, torvalds, davem, akpm
This applies to 2.6.17-rc2.
There is a missing initialization of err in sockfd_lookup_light() that could return random error for an invalid file handle.
Signed-off-by: Hua Zhong <hzhong@gmail.com>
diff --git a/net/socket.c b/net/socket.c
index 23898f4..0ce12df 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -490,6 +490,7 @@ static struct socket *sockfd_lookup_ligh
struct file *file;
struct socket *sock;
+ *err = -EBADF;
file = fget_light(fd, fput_needed);
if (file) {
sock = sock_from_file(file, err);
^ permalink raw reply related
* Re: [offlist] Re: [LARTC] how to do probabilistic packet loss in kernel?
From: Ian McDonald @ 2006-04-19 19:19 UTC (permalink / raw)
To: George Nychis; +Cc: Martin A. Brown, lartc, netdev
In-Reply-To: <44464167.40702@cmu.edu>
On 4/20/06, George Nychis <gnychis@cmu.edu> wrote:
> Hey Martin,
>
> I was able to do it with netem and its working great now.
>
> I've actually moved on to another challenge, I would like to drop
> packets at the hardware level such as to see rate control.
>
Have a look at:
http://linux-net.osdl.org/index.php/Netem#Rate_control
Works well for me...
Ian
--
Ian McDonald
Web: http://wand.net.nz/~iam4
Blog: http://imcdnzl.blogspot.com
WAND Network Research Group
Department of Computer Science
University of Waikato
New Zealand
^ permalink raw reply
* Re: [TCP]: Fix truesize underflow
From: David S. Miller @ 2006-04-19 20:07 UTC (permalink / raw)
To: shemminger
Cc: herbert, bb, kernel, nipsy, jesse.brandeburg, jrlundgren, cat,
djani22, yoseph.basri, mykleb, olel, michal, chris, netdev,
jesse.brandeburg, ak, jgarzik
In-Reply-To: <20060419095348.0de93eaf@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Wed, 19 Apr 2006 09:53:48 -0700
> Please put this in the next -stable load...
I already sent it to -stable.
^ permalink raw reply
* Re: [patch] ipv4: initialize arp_tbl rw lock
From: David S. Miller @ 2006-04-19 20:12 UTC (permalink / raw)
To: borntrae
Cc: akpm, heiko.carstens, shemminger, jgarzik, netdev, linux-kernel,
fpavlic, davem
In-Reply-To: <200604191245.48458.borntrae@de.ibm.com>
From: Christian Borntraeger <borntrae@de.ibm.com>
Date: Wed, 19 Apr 2006 12:45:48 +0200
> As spinlock debugging still does not work with the qeth driver I
> want to pick up the discussion.
Does something like the patch below work?
But this all begs the question, what happens if you want to
dig into the internals of a protocol which is built modular and
hasn't been loaded yet?
diff --git a/include/linux/init.h b/include/linux/init.h
index 93dcbe1..8169f25 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -95,8 +95,9 @@ #define postcore_initcall(fn) __define_
#define arch_initcall(fn) __define_initcall("3",fn)
#define subsys_initcall(fn) __define_initcall("4",fn)
#define fs_initcall(fn) __define_initcall("5",fn)
-#define device_initcall(fn) __define_initcall("6",fn)
-#define late_initcall(fn) __define_initcall("7",fn)
+#define net_initcall(fn) __define_initcall("6",fn)
+#define device_initcall(fn) __define_initcall("7",fn)
+#define late_initcall(fn) __define_initcall("8",fn)
#define __initcall(fn) device_initcall(fn)
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index dc206f1..9803a57 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1257,7 +1257,7 @@ out_unregister_udp_proto:
goto out;
}
-module_init(inet_init);
+net_initcall(inet_init);
/* ------------------------------------------------------------------------ */
^ permalink raw reply related
* Re: [Bugme-new] [Bug 6412] New: Kernel crashes randomly -- Unable to handle kernel NULL pointer dereference ...
From: Andrew Morton @ 2006-04-19 20:48 UTC (permalink / raw)
To: bugme-daemon; +Cc: webmatt000, netdev
In-Reply-To: <200604192034.k3JKYpxD007463@fire-2.osdl.org>
bugme-daemon@bugzilla.kernel.org wrote:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=6412
>
> Summary: Kernel crashes randomly -- Unable to handle kernel NULL
> pointer dereference ...
> Kernel Version: 2.6.16.5 - mainline, neither out of tree modules loaded
> nor comp
> Status: NEW
> Severity: normal
> Owner: acme@conectiva.com.br
> Submitter: webmatt000@arcor.de
>
>
> Most recent kernel where this bug did not occur:
> Unknown - My SMP machine keeps crashing scince kernel version 2.6.10 or so up to
> 7 times a day. Most of the time I am unable to tell you the cause of the
> crashes, because my syslogs do not contian any data about that.
>
> Distribution: Debian
>
> Hardware Environment: SMP, i386,
>
> Software Environment: root-nfs; SMP disabled in kernel in the hope to reduce the
> number the of kernel crashes; I was running X, KDE 3.5 and Mozilla
>
> Problem Description:
> Suddenly, my PC restarted X, started xdm and my screen, mouse and keyboard were
> frozen. I was able to log into the crashed machine from my nfs server via ssh
> and to produce this dmesg:
>
> IN=wan0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:80:77:48:f6:fa:08:00 SRC=192.168.2.2
> DST=192.168.2.255 LEN=229 TOS=0x00 PREC=0x00 TTL=60 ID=966 PROTO=UDP SPT=138
> DPT=138 LEN=209
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> printing eip:
> 00000000
> *pde = 5386a067
> Oops: 0000 [#1]
> PREEMPT
> Modules linked in: esp6 ah6 ipcomp esp4 ah4 xfrm_user arc4 af_packet lp autofs4
> tun ipx p8022 psnap llc p8023 bridge iptable_mangle ipt_TCPMSS xt_state
> ipt_REJECT ipt_LOG ipt_multiport iptable_filter ipt_MASQUERADE ipt_REDIRECT
> xt_tcpudp iptable_nat ip_tables ip6table_raw ip6table_mangle ip6t_hl xt_limit
> ip6t_multiport ip6t_LOG ip6table_filter ip6_tables x_tables ipv6 deflate
> zlib_deflate zlib_inflate sha1 crypto_null af_key binfmt_misc nfsd exportfs
> eeprom i2c_viapro ppdev ip_nat_ftp ip_nat ip_conntrack_ftp ip_conntrack
> nfnetlink ide_floppy ide_disk ide_cd snd_seq_dummy snd_seq_oss snd_seq_midi
> snd_seq_midi_event snd_seq snd_via82xx snd_ens1371 snd_pcm_oss snd_mixer_oss
> gameport snd_via82xx_modem snd_ac97_codec snd_ac97_bus snd_mpu401_uart snd_pcm
> snd_rawmidi snd_seq_device snd_timer snd via82cxxx generic psmouse
> snd_page_alloc ide_core serio_raw soundcore dl2k 8139too uhci_hcd via686a hwmon
> i2c_isa usbcore parport_pc parport unix
> CPU: 0
> EIP: 0060:[<00000000>] Not tainted VLI
> EFLAGS: 00213246 (2.6.16.5-d6vaa-1CPU #4)
> EIP is at run_init_process+0x3feffde0/0x29
> eax: f6bff340 ebx: f6bff340 ecx: 00000003 edx: 00000003
> esi: 00000000 edi: f748e000 ebp: 00000003 esp: f748ff70
> ds: 007b es: 007b ss: 0068
> Process Xorg (pid: 6506, threadinfo=f748e000 task=f7a02030)
> Stack: <0>f88161f5 f5c65bc0 00000022 086c2690 f748e000 c0266151 00000000 0000000c
> c0266b67 00000022 00000002 00000022 00000002 00000000 00000000 00000000
> 00000022 0000000d c0102a2d 0000000d bfd5c0e0 08700a38 00000022 086c2690
> Call Trace:
> [<f88161f5>] unix_shutdown+0x54/0x125 [unix]
> [<c0266151>] sys_shutdown+0x24/0x35
> [<c0266b67>] sys_socketcall+0x128/0x181
> [<c0102a2d>] syscall_call+0x7/0xb
> Code: Bad EIP value.
> <6>agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
> agpgart: Putting AGP V2 device at 0000:00:00.0 into 1x mode
> agpgart: Putting AGP V2 device at 0000:01:00.0 into 1x mode
>
> Finally I was able to reboot the system via ssh. ps -e |grep xdm was telling me,
> that no xdm was running, but xdm was showing on my frozen screen. top showed
> that the crshed machine was not under load. => no livelock
>
> Steps to reproduce: unknown, because my machine crashes randomly
>
The CPU has started execution at address 0x00000000. I'd assume that
sk->sk_state_change is zero in unix_shutdown().
Could you add this patch? If my theory is correct, it will prevent the
crashes and will give us the same info.
diff -puN net/unix/af_unix.c~a net/unix/af_unix.c
--- 25/net/unix/af_unix.c~a Wed Apr 19 13:45:05 2006
+++ 25-akpm/net/unix/af_unix.c Wed Apr 19 13:48:13 2006
@@ -1780,6 +1780,19 @@ out:
return copied ? : err;
}
+static void do_sk_state_change(struct sock *sk)
+{
+ void (*sk_state_change)(struct sock *sk);
+
+ sk_state_change = sk->sk_state_change;
+ if (!sk_state_change) {
+ printk(KERN_ERR "%s: sk_state_change=NULL\n", __FUNCTION__);
+ dump_stack();
+ } else {
+ sk_state_change(sk);
+ }
+}
+
static int unix_shutdown(struct socket *sock, int mode)
{
struct sock *sk = sock->sk;
@@ -1794,7 +1807,7 @@ static int unix_shutdown(struct socket *
if (other)
sock_hold(other);
unix_state_wunlock(sk);
- sk->sk_state_change(sk);
+ do_sk_state_change(sk);
if (other &&
(sk->sk_type == SOCK_STREAM || sk->sk_type == SOCK_SEQPACKET)) {
@@ -1808,7 +1821,7 @@ static int unix_shutdown(struct socket *
unix_state_wlock(other);
other->sk_shutdown |= peer_mode;
unix_state_wunlock(other);
- other->sk_state_change(other);
+ do_sk_state_change(other);
read_lock(&other->sk_callback_lock);
if (peer_mode == SHUTDOWN_MASK)
sk_wake_async(other,1,POLL_HUP);
_
^ permalink raw reply
* Re: [TCP]: Fix truesize underflow
From: Krzysztof Oledzki @ 2006-04-19 21:29 UTC (permalink / raw)
To: Jesse Brandeburg
Cc: bb, Herbert Xu, David S. Miller, kernel, nipsy, jrlundgren, cat,
djani22, yoseph.basri, mykleb, michal, chris, netdev,
jesse.brandeburg, ak, jgarzik
In-Reply-To: <44466024.9040800@intel.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 938 bytes --]
On Wed, 19 Apr 2006, Jesse Brandeburg wrote:
> Boris B. Zhmurov wrote:
>> Hello, Herbert Xu.
>>
>> On 19.04.2006 03:27 you said the following:
>>
>>> On Tue, Apr 18, 2006 at 01:22:56PM -0700, David S. Miller wrote:
>>>
>>>> I think it is deserving of some run time assertions, else these bugs
>>>> will elude us continually. Luckily there are only a few places that
>>>> would need the run time assertion checks on skb->truesize, and I'll
>>>> try to spend a few cycles on implementing this soon.
>>>
>>>
>>> Yes indeed. One place that comes to mind would be tcp_trim_head just
>>> before we munge truesize.
>>>
>>> Cheers,
>>
>>
>> I confirm, finally I don't see messages in dmesg about assertions. Nice
>> work :)
>>
> I can also confirm that both machines here had no problems after applying
> this patch. Good work!
Me too, me too. Thank you! :)
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: [RFC] Netlink and user-space buffer pointers
From: Mike Christie @ 2006-04-19 21:32 UTC (permalink / raw)
To: James.Smart; +Cc: linux-scsi, netdev, linux-kernel
In-Reply-To: <444633B5.5030208@emulex.com>
James Smart wrote:
> Folks,
>
> To take netlink to where we want to use it within the SCSI subsystem (as
> the mechanism of choice to replace ioctls), we're going to need to pass
> user-space buffer pointers.
>
> What is the best, portable manner to pass a pointer between user and kernel
> space within a netlink message ? The example I've seen is in the iscsi
> target code - and it's passed between user-kernel space as a u64, then
> typecast to a void *, and later within the bio_map_xxx functions, as an
> unsigned long. I assume we are going to continue with this method ?
>
I do not know if it is needed. For the target code, we use the
bio_map_xxx to avoid having to copy the command data which is needed for
decent performance. We have also been trying to figure out ways of
getting out of using netlink to send the command info (cdb, tag info,
etc) around, because in some of Tomo's tests using mmaped packet sockets
he was able to imporove performance by removing that copy from the
kernel to userspace. We had problems with that though and other nice
interfaces like relayfs only allowed us to pass data from the kernel to
userspace so we still need another interface to pass things from
userspace to the kernel. Still working on this though. If someone knows
a interface please let us know.
For the tasks you want to do for the fc class is performance critical?
If not, you could do what the iscsi class (for the netdev people this is
drivers/scsi/scsi_transport_iscsi.c) does and just suffer a couple
copies. For iscsi we do this in userspace to send down a login pdu:
/*
* xmitbuf is a buffer that is large enough for the iscsi_event,
* iscsi pdu (hdr_size) and iscsi pdu data (data_size)
*/
memset(xmitbuf, 0, sizeof(*ev) + hdr_size + data_size);
xmitlen = sizeof(*ev);
ev = xmitbuf;
ev->type = ISCSI_UEVENT_SEND_PDU;
ev->transport_handle = transport_handle;
ev->u.send_pdu.sid = sid;
ev->u.send_pdu.cid = cid;
ev->u.send_pdu.hdr_size = hdr_size;
ev->u.send_pdu.data_size = data_size;
then later we do sendmsg()to send down the xmitbuf to the kernel iscsi
driver. I think there may be issues with packing structs or 32 bit
userspace and 64 bit kernels and other fun things like this so the iscsi
pdu and iscsi event have to be defined correctly and I guess we are back
to some of the problems with ioctls :(
^ permalink raw reply
* Re: Netpoll checksum issue
From: Herbert Xu @ 2006-04-19 21:33 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Aubrey, netdev
In-Reply-To: <20060419103153.64ef0054@localhost.localdomain>
On Wed, Apr 19, 2006 at 10:31:53AM -0700, Stephen Hemminger wrote:
> The changes to how hardware receive checksums are handled broke
> the netpoll checksum code (for CHECKSUM_HW). Since this is not at
> all performance critical, try this patch. It changes to always to
> normal software checksum.
Hmm, why don't we try to find out what's actually broken? Papering over
this means that we could miss driver bugs in future.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Fw: Netpoll checksum issue
From: Herbert Xu @ 2006-04-19 21:34 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Aubrey
In-Reply-To: <20060419101557.30ac8461@localhost.localdomain>
> Date: Thu, 20 Apr 2006 00:22:16 +0800
> From: Aubrey <aubreylee@gmail.com>
> Newsgroups: linux.dev.kernel
> Subject: Netpoll checksum issue
>
> I'm porting my network driver from 2.6.12 to 2.6.16. It almostly work
> without any change, except the netpoll mode. When I use kgdb to debug
> kernel, gdb client can not establish the connection with gdb server.
> Then I digged into the code, and I found in the routine "__netpoll_rx"
> in the file "net/core/netpoll.c", the "checksum_udp" call always
> failed, but it works on 2.6.12.
> Could you please give me some suggestions?
Is your driver open source?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: I/OAT: Call for discussion
From: Christoph Hellwig @ 2006-04-19 21:44 UTC (permalink / raw)
To: John Ronciak; +Cc: Stephen Hemminger, Grover, Andrew, netdev
In-Reply-To: <56a8daef0604191028v7b3f501dm167a68709e8dea5f@mail.gmail.com>
On Wed, Apr 19, 2006 at 10:28:41AM -0700, John Ronciak wrote:
> The hardware is going to generally available in June. There are also
> lots of OEMs, OSVs and hardware vendors that have the system to test
> on today. The early rollout of hardware has been very large.
As a start to get people actually interested you should stop talking
like a jerk and kill all these silly three-letter acronyms from your language.
As for larget, I don't have one for sure :) And I haven't hard from any
kernel developer that he had hardware to play with, but maybe you gave
them a nasty nda to shut them up, which of course doesn't help getting things
merged either.
^ permalink raw reply
* Re: [patch 08/10] bcm43xx: sysfs code cleanup
From: Francois Romieu @ 2006-04-19 21:50 UTC (permalink / raw)
To: akpm; +Cc: jeff, linville, netdev, mb, greg
In-Reply-To: <200604190405.k3J457Zj008004@shell0.pdx.osdl.net>
akpm@osdl.org <akpm@osdl.org> :
>
> From: Michael Buesch <mb@bu3sch.de>
>
> This cleans up the bcm43xx sysfs code and makes it compliant with the
> unwritten sysfs rules (at least I hope so).
>
> Signed-off-by: Michael Buesch <mb@bu3sch.de>
> Cc: Jeff Garzik <jeff@garzik.org>
> Cc: Greg KH <greg@kroah.com>
> Signed-off-by: Andrew Morton <akpm@osdl.org>
[...]
> diff -puN drivers/net/wireless/bcm43xx/bcm43xx.h~bcm43xx-sysfs-code-cleanup drivers/net/wireless/bcm43xx/bcm43xx.h
> --- devel/drivers/net/wireless/bcm43xx/bcm43xx.h~bcm43xx-sysfs-code-cleanup 2006-04-12 18:11:12.000000000 -0700
> +++ devel-akpm/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-04-12 18:11:12.000000000 -0700
[...]
> @@ -772,6 +769,20 @@ struct bcm43xx_private * bcm43xx_priv(st
> return ieee80211softmac_priv(dev);
> }
>
> +struct device;
> +
> +static inline
> +struct bcm43xx_private * dev_to_bcm(struct device *dev)
> +{
> + struct net_device *net_dev;
> + struct bcm43xx_private *bcm;
> +
> + net_dev = dev_get_drvdata(dev);
> + bcm = bcm43xx_priv(net_dev);
> +
> + return bcm;
> +}
> +
It's used only in bcm43xx_sysfs.c. It could go there and avoid
an extra forward declaration.
[...]
> diff -puN drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c~bcm43xx-sysfs-code-cleanup drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
> --- devel/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c~bcm43xx-sysfs-code-cleanup 2006-04-12 18:11:12.000000000 -0700
> +++ devel-akpm/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c 2006-04-12 18:11:12.000000000 -0700
> @@ -71,14 +71,46 @@ static int get_boolean(const char *buf,
> return -EINVAL;
> }
>
> +static int sprom2hex(const u16 *sprom, char *buf, size_t buf_len)
> +{
> + int i, pos = 0;
> +
> + for (i = 0; i < BCM43xx_SPROM_SIZE; i++) {
> + pos += snprintf(buf + pos, buf_len - pos - 1,
> + "%04X", swab16(sprom[i]) & 0xFFFF);
> + }
> + pos += snprintf(buf + pos, buf_len - pos - 1, "\n");
> +
> + return pos + 1;
> +}
> +
> +static int hex2sprom(u16 *sprom, const char *dump, size_t len)
> +{
> + char tmp[5] = { 0 };
> + int cnt = 0;
> + unsigned long parsed;
> +
> + if (len < BCM43xx_SPROM_SIZE * sizeof(u16) * 2)
> + return -EINVAL;
> +
> + while (cnt < BCM43xx_SPROM_SIZE) {
> + memcpy(tmp, dump, 4);
> + dump += 4;
> + parsed = simple_strtoul(tmp, NULL, 16);
> + sprom[cnt++] = swab16((u16)parsed);
> + }
> +
> + return 0;
> +}
"4" suggests that the code walks dump -> dump + 4*BCM43xx_SPROM_SIZE
> static ssize_t bcm43xx_attr_sprom_store(struct device *dev,
> const char *buf, size_t count)
[...]
> - for (i = 0; i < BCM43xx_SPROM_SIZE; i++) {
> - sprom[i] = buf[i * 2] & 0xFF;
> - sprom[i] |= ((u16)(buf[i * 2 + 1] & 0xFF)) << 8;
> - }
> + err = hex2sprom(sprom, buf, count);
... whereas here it only parses buf -> buf + 2*BCM43xx_SPROM_SIZE
--
Ueimor
^ permalink raw reply
* Re: [patch 08/10] bcm43xx: sysfs code cleanup
From: Michael Buesch @ 2006-04-19 22:05 UTC (permalink / raw)
To: Francois Romieu; +Cc: jeff, linville, netdev, mb, greg, akpm
In-Reply-To: <20060419215035.GA29122@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 3427 bytes --]
On Wednesday 19 April 2006 23:50, you wrote:
> akpm@osdl.org <akpm@osdl.org> :
> >
> > From: Michael Buesch <mb@bu3sch.de>
> >
> > This cleans up the bcm43xx sysfs code and makes it compliant with the
> > unwritten sysfs rules (at least I hope so).
> >
> > Signed-off-by: Michael Buesch <mb@bu3sch.de>
> > Cc: Jeff Garzik <jeff@garzik.org>
> > Cc: Greg KH <greg@kroah.com>
> > Signed-off-by: Andrew Morton <akpm@osdl.org>
> [...]
> > diff -puN drivers/net/wireless/bcm43xx/bcm43xx.h~bcm43xx-sysfs-code-cleanup drivers/net/wireless/bcm43xx/bcm43xx.h
> > --- devel/drivers/net/wireless/bcm43xx/bcm43xx.h~bcm43xx-sysfs-code-cleanup 2006-04-12 18:11:12.000000000 -0700
> > +++ devel-akpm/drivers/net/wireless/bcm43xx/bcm43xx.h 2006-04-12 18:11:12.000000000 -0700
> [...]
> > @@ -772,6 +769,20 @@ struct bcm43xx_private * bcm43xx_priv(st
> > return ieee80211softmac_priv(dev);
> > }
> >
> > +struct device;
> > +
> > +static inline
> > +struct bcm43xx_private * dev_to_bcm(struct device *dev)
> > +{
> > + struct net_device *net_dev;
> > + struct bcm43xx_private *bcm;
> > +
> > + net_dev = dev_get_drvdata(dev);
> > + bcm = bcm43xx_priv(net_dev);
> > +
> > + return bcm;
> > +}
> > +
>
> It's used only in bcm43xx_sysfs.c. It could go there and avoid
> an extra forward declaration.
But it is a very generic helper, that does not have anything to do
with sysfs. It converts a struct device to struct bcm43xx_private.
bcm43xx_sysfs.h does only contain sysfs specific stuff for bcm.
> [...]
> > diff -puN drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c~bcm43xx-sysfs-code-cleanup drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c
> > --- devel/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c~bcm43xx-sysfs-code-cleanup 2006-04-12 18:11:12.000000000 -0700
> > +++ devel-akpm/drivers/net/wireless/bcm43xx/bcm43xx_sysfs.c 2006-04-12 18:11:12.000000000 -0700
> > @@ -71,14 +71,46 @@ static int get_boolean(const char *buf,
> > return -EINVAL;
> > }
> >
> > +static int sprom2hex(const u16 *sprom, char *buf, size_t buf_len)
> > +{
> > + int i, pos = 0;
> > +
> > + for (i = 0; i < BCM43xx_SPROM_SIZE; i++) {
> > + pos += snprintf(buf + pos, buf_len - pos - 1,
> > + "%04X", swab16(sprom[i]) & 0xFFFF);
> > + }
> > + pos += snprintf(buf + pos, buf_len - pos - 1, "\n");
> > +
> > + return pos + 1;
> > +}
> > +
> > +static int hex2sprom(u16 *sprom, const char *dump, size_t len)
> > +{
> > + char tmp[5] = { 0 };
> > + int cnt = 0;
> > + unsigned long parsed;
> > +
> > + if (len < BCM43xx_SPROM_SIZE * sizeof(u16) * 2)
> > + return -EINVAL;
> > +
> > + while (cnt < BCM43xx_SPROM_SIZE) {
> > + memcpy(tmp, dump, 4);
> > + dump += 4;
> > + parsed = simple_strtoul(tmp, NULL, 16);
> > + sprom[cnt++] = swab16((u16)parsed);
> > + }
> > +
> > + return 0;
> > +}
>
> "4" suggests that the code walks dump -> dump + 4*BCM43xx_SPROM_SIZE
>
> > static ssize_t bcm43xx_attr_sprom_store(struct device *dev,
> > const char *buf, size_t count)
> [...]
> > - for (i = 0; i < BCM43xx_SPROM_SIZE; i++) {
> > - sprom[i] = buf[i * 2] & 0xFF;
> > - sprom[i] |= ((u16)(buf[i * 2 + 1] & 0xFF)) << 8;
> > - }
> > + err = hex2sprom(sprom, buf, count);
>
> ... whereas here it only parses buf -> buf + 2*BCM43xx_SPROM_SIZE
the deleted code parses binary input. The
new code parses human readable hex input.
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [patch 08/10] bcm43xx: sysfs code cleanup
From: Francois Romieu @ 2006-04-19 22:17 UTC (permalink / raw)
To: Michael Buesch; +Cc: jeff, linville, netdev, greg, akpm
In-Reply-To: <200604200005.01087.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> :
[...]
> the deleted code parses binary input. The
> new code parses human readable hex input.
No offence intended but it was not clear from the description of
the patch.
<pavlov>
Does it imply an user space visible API change ?
</pavlov>
--
Ueimor
^ permalink raw reply
* Re: [PATCH] sockfd_lookup_light() returns random error for -EBADFD
From: David S. Miller @ 2006-04-19 22:25 UTC (permalink / raw)
To: hzhong; +Cc: linux-kernel, netdev, torvalds, akpm
In-Reply-To: <444688F2.5060909@gmail.com>
From: Hua Zhong <hzhong@gmail.com>
Date: Wed, 19 Apr 2006 12:01:06 -0700
> There is a missing initialization of err in sockfd_lookup_light() that could return random error for an invalid file handle.
>
> Signed-off-by: Hua Zhong <hzhong@gmail.com>
Applied, thanks a lot for this bug fix.
^ permalink raw reply
* Re: [patch 08/10] bcm43xx: sysfs code cleanup
From: Michael Buesch @ 2006-04-19 22:30 UTC (permalink / raw)
To: Francois Romieu; +Cc: jeff, linville, netdev, greg, akpm
In-Reply-To: <20060419221757.GA29110@electric-eye.fr.zoreil.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Thursday 20 April 2006 00:17, you wrote:
> Michael Buesch <mb@bu3sch.de> :
> [...]
> > the deleted code parses binary input. The
> > new code parses human readable hex input.
>
> No offence intended but it was not clear from the description of
> the patch.
>
> <pavlov>
> Does it imply an user space visible API change ?
> </pavlov>
Yes it does, but:
* We did not release a stable kernel with it in the meantime.
* There is no software using it at the moment.
(Well, the bcm43xx-sprom tool is kind of using it,
but it can handle both binary and hex input anyway)
--
Greetings Michael.
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [patch 08/10] bcm43xx: sysfs code cleanup
From: Francois Romieu @ 2006-04-19 22:33 UTC (permalink / raw)
To: Michael Buesch; +Cc: jeff, linville, netdev, greg, akpm
In-Reply-To: <200604200030.10218.mb@bu3sch.de>
Michael Buesch <mb@bu3sch.de> :
[...]
> Yes it does, but:
> * We did not release a stable kernel with it in the meantime.
> * There is no software using it at the moment.
> (Well, the bcm43xx-sprom tool is kind of using it,
> but it can handle both binary and hex input anyway)
Ok. Thanks for the explanation.
--
Ueimor
^ permalink raw reply
* Re: [Bugme-new] [Bug 6409] New: llc_rcv doesn't handle receives using nr_frags and frags[]
From: David S. Miller @ 2006-04-19 22:37 UTC (permalink / raw)
To: akpm; +Cc: netdev, acme, jesse.brandeburg, bugme-daemon
In-Reply-To: <20060419113806.29ba0d23.akpm@osdl.org>
From: Andrew Morton <akpm@osdl.org>
Date: Wed, 19 Apr 2006 11:38:06 -0700
> Analysis:
> llc_rcv
> does a skb_clone inside skb_share_check
> llc_fixup_skb
> skb_trim
> __skb_trim
> ___pskb_trim(x,x,0) <-- realloc set to 0
> ___pskb_trim BUG on !realloc inside skb_cloned check
I'll fix it like this:
diff-tree 5185db09f46ed64d520d09db6e93852e44106628 (from 3672558c6180ca28a7aa46765702467a37e58fc5)
Author: David S. Miller <davem@sunset.davemloft.net>
Date: Wed Apr 19 15:37:13 2006 -0700
[LLC]: Use pskb_trim_rcsum() in llc_fixup_skb().
Kernel Bugzilla #6409
If we use plain skb_trim(), that's wrong, because if
the SKB is cloned, and it can be because we unshared
it in the caller, we have to allow reallocation. The
pskb_trim*() family of routines is therefore the most
appropriate here.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/llc/llc_input.c b/net/llc/llc_input.c
index 8f3addf..d62e0f9 100644
--- a/net/llc/llc_input.c
+++ b/net/llc/llc_input.c
@@ -118,7 +118,8 @@ static inline int llc_fixup_skb(struct s
u16 pdulen = eth_hdr(skb)->h_proto,
data_size = ntohs(pdulen) - llc_len;
- skb_trim(skb, data_size);
+ if (unlikely(pskb_trim_rcsum(skb, data_size)))
+ return 0;
}
return 1;
}
^ permalink raw reply related
* Re: [RESEND][PATCH] ebtables: clean up vmalloc usage in net/bridge/netfilter/ebtables.c
From: David S. Miller @ 2006-04-19 22:41 UTC (permalink / raw)
To: jchandra; +Cc: bridge, bdschuym, netdev, akpm
In-Reply-To: <20060419065025.GE17192@random.pao.digeo.com>
An earlier variant of your patch was applied already, included below.
You'll need to submit the newer parts relative to the current tree.
diff-tree 7ad4d2f6901437ba4717a26d395a73ea362d25c6 (from b8282dcf0417bbc8a0786c129fdff9cc768f8f3c)
Author: Jayachandran C <c.jayachandran@gmail.com>
Date: Tue Apr 11 17:25:38 2006 -0700
[BRIDGE] ebtables: fix allocation in net/bridge/netfilter/ebtables.c
Allocate an array of 'struct ebt_chainstack *', the current code allocates
array of 'struct ebt_chainstack'.
akpm: converted to use the
foo = alloc(sizeof(*foo))
form. Which would have prevented this from happening in the first place.
akpm: also removed unneeded typecast.
akpm: what on earth is this code doing anyway? cpu_possible_map can be
sparse..
Signed-off-by: Jayachandran C. <c.jayachandran@gmail.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 66bd932..84b9af7 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -824,9 +824,9 @@ static int translate_table(struct ebt_re
if (udc_cnt) {
/* this will get free'd in do_replace()/ebt_register_table()
if an error occurs */
- newinfo->chainstack = (struct ebt_chainstack **)
- vmalloc((highest_possible_processor_id()+1)
- * sizeof(struct ebt_chainstack));
+ newinfo->chainstack =
+ vmalloc((highest_possible_processor_id()+1)
+ * sizeof(*(newinfo->chainstack)));
if (!newinfo->chainstack)
return -ENOMEM;
for_each_possible_cpu(i) {
^ permalink raw reply related
* RE: [PATCH 2.6.16-rc5] S2io: Receive packet classification and steering mechanisms
From: Ravinandan Arakali @ 2006-04-19 22:45 UTC (permalink / raw)
To: Andi Kleen; +Cc: jgarzik, netdev
In-Reply-To: <200604190259.14854.ak@suse.de>
Andi,
We would like to explain that this patch is tier-1 of a two
tiered approach. It implements all the steering
functionality at driver-only level, and it is fairly Neterion-specific.
The second upcoming submission will add a generic netlink-based
interface for channel data flow and configuration(including receive steering
parameters) on per-channel basis, that will utilize the lower level
implementation from the current patch.
Thanks,
Ravi
-----Original Message-----
From: Andi Kleen [mailto:ak@suse.de]
Sent: Tuesday, April 18, 2006 5:59 PM
To: ravinandan.arakali@neterion.com
Cc: jgarzik@pobox.com; netdev@vger.kernel.org
Subject: Re: [PATCH 2.6.16-rc5] S2io: Receive packet classification and
steering mechanisms
On Wednesday 19 April 2006 02:38, Ravinandan Arakali wrote:
> configuration: A mask(specified using loadable parameter rth_fn_and_mask)
> can be used to select a subset of TCP/UDP tuple for hash calculation.
> eg. To mask source port for TCP/IPv4 configuration,
> # insmod s2io.ko rx_steering_type=2 rth_fn_and_mask=0x0101
> LSB specifies RTH function type and MSB the mask. A full description
> is provided at the beginning of s2io.c
I don't think it's a good idea to introduce such weird and hard to
understand
module parameters for this. I would be better to define a generic
internal kernel interface between stack and driver. Perhaps starting
with a standard netlink interface for this might be a good start
until the stack learns how to use this on its own.
> 3. MAC address-based:
> Done based on destination MAC address of packet. Xframe can be
> configured with multiple unicast MAC addresses.
>
> configuration: Load-time parameters multi_mac_cnt and multi_macs
> can be used to specify no. of MAC addresses and list of unicast
> addresses.
> eg. insmod s2io.ko rx_steering_type=8 multi_mac_cnt=3
> multi_macs=00:0c:fc:00:00:22, 00:0c:fc:00:01:22, 00:0c:fc:00:02:22
> Packets received with default destination MAC address will be steered to
> ring0. Packets with destination MAC addresses specified by multi_macs are
> steered to ring1, ring2... respectively.
The obvious way to do this nicely would be to allow to define multiple
virtual interfaces where the mac addresses can be set using the usual
ioctls.
-Andi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox