Re: [NETLINK]: Add netlink_has_listeners for avoiding unneccessary event message generation
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Thu, 16 Feb 2006 02:43:58 +0100 > This is a simplified version of the netlink_has_listeners patch > to let netlink multicast senders check for listeners before > generating messages. The last version also had a bug that made > the mask only contain the subscribed groups of the socket used > for the last bind operation. This version should be fine for > net-2.6.17, my upcoming netfilter patches will add the first > two users. Applied, 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 1/5] IrDA: nsc-ircc: ISAPnP support
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Tue, 14 Feb 2006 00:14:43 +0200 > This enables PnP support for the nsc-ircc chipset. > Since we can't fetch the chipset cfg_base from the PnP layer, we just use > the PnP information as one more hint when probing the chip. > > Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied, 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 2/5] IrDA: nsc-ircc: PM update
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Tue, 14 Feb 2006 00:15:09 +0200 > This patch brings the nsc-ircc code to a more up to date power management > scheme, following the current device model. > > Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]> > Signed-off-by: Rudolf Marek <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied. - 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 3/5] IrDA: nsc-ircc: support for yet another Thinkpad IrDA chipset
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Tue, 14 Feb 2006 00:15:21 +0200 > This patch simply adds support for a variation of the nsc-ircc PC8739x > chipset, found in some IBM Thinkpad laptops. > > Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied. - 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 4/5] IrDA: sti/cli removal from EP7211 IrDA driver
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Tue, 14 Feb 2006 00:15:38 +0200 > This patch replaces the deprecated sti/cli routines with the corresponding > spin_lock ones. > > Signed-off-by: David chosrova <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied. - 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/5] IrDA: pci_register_driver conversion
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Tue, 14 Feb 2006 00:15:48 +0200 > This patch converts 2 IrDA drivers pci_module_init() calls to > pci_register_driver(). > > Signed-off-by: Christophe Lucas <[EMAIL PROTECTED]> > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied. - 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: [PKT_SCHED 01/05]: Qdisc drop operation is optional
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 15 Feb 2006 09:54:53 +0100 (MET) > [PKT_SCHED]: Qdisc drop operation is optional > > The drop operation is optional and qdiscs must check if childs support it. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied, 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: [PKT_SCHED 02/05]: Dump child qdisc handle in sch_{atm,dsmark}
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 15 Feb 2006 09:54:54 +0100 (MET)
> [PKT_SCHED]: Dump child qdisc handle in sch_{atm,dsmark}
>
> A qdisc should set tcm_info to the child qdisc handle in its class dump
> function.
>
> Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
Applied.
-
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: [PKT_SCHED 05/05]: Keep backlog counter in sch_sfq
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 15 Feb 2006 09:54:59 +0100 (MET) > [PKT_SCHED]: Keep backlog counter in sch_sfq > > Keep backlog counter in SFQ qdisc to make it usable as child qdisc with > RED. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied. - 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: [PKT_SCHED 00/05]: net/sched patches for 2.6.17
From: jamal <[EMAIL PROTECTED]> Date: Thu, 16 Feb 2006 07:56:44 -0500 > [1]I have to put a disclaimer: I am always a stickler as far as RED > is concerned (Thomas can testify to that) because it is very > delicate (not the code rather the algorithm) and i have suffered a > lot in the past getting those parameters tuned. There was a gent who > was interested in putting together regression tests for RED but he > keeps disappearing on us. There is a limit to how far you can apply this limitation on other people. Nobody can touch RED in any significant way because of this roadblock. I would say it's justified if you had some full regression suite you were working on, but you're not and you won't be able to cook one up any time soon. There is a point at which the folks doing the work get to make the decisions, and that is leaning towards Patrick and others at this point. - 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 0/7] IPSEC: Sync series
From: jamal <[EMAIL PROTECTED]> Date: Fri, 03 Feb 2006 08:58:56 -0500 > Thanks for everyone who has provided comments thus far. If you have any > more comments please shoot, else Dave this is for 2.6.17 tree. All looks good Jamal, applied. 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] keep track of network interface renaming
On Sat, Feb 18, Jeff Garzik wrote: > Fix Xen network support not to do such stupid stuff... No Xen due to lack of A20 gates. - 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: [RFT] sky2 0.16
On Saturday 18 February 2006 18:00, Carl-Daniel Hailfinger wrote: > Hi, > > Stephen Hemminger schrieb: > > Could everyone who has problems with hangs try the > > following patch (against current 2.6.16-rc3 version) > > If Stephen's patch doesn't work for you, could you try replacing > sky2.c and sky2.h with the ones attached to this mail? I'd be very > interested in feedback for my version of the hangfix. Yes, your version cures my hangs. Btw, I have the same chip as mentioned in your code comment (0xb6, rev1). Your code comment also seems to fit my debug-output in Stephen's 0.16 (OP_PACKET in eth0 transmit ring). Diffing your code against 0.13 and 0.16, it seems that 0.16 just handles the (work_done < to_do) scenario, but not the "packets arrived since start of this function"? Well, I have to admit I have no real understanding of what all this magic driver code does ;-) Thank you, Wolfgang - 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
IPv6 setsockopt software MTU patch
Hi, In my precedent mails, i pointed out that IPV6_MTU setsockopt was ineffective because the field frag_size was not used further in the ipv6 fragment code of the kernel. You can check out that this is the case by this simple proof of concept code : http://clarinet.u-strasbg.fr/~hoerdt/mtu.c The fix is very simple, it only grab the value of frag_size and use it in ip6_fragment file, could you please review the patch which fix that problem at : http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch Thanks for the attention, Hoerdt Mickaël - 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: IPv6 setsockopt software MTU patch
In article <[EMAIL PROTECTED]> (at Sun, 19 Feb 2006 14:47:09 +0100), [EMAIL PROTECTED] says: > The fix is very simple, it only grab the value of frag_size and > use it in ip6_fragment file, could you please review the patch which > fix that problem at : > > http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch Thanks for the patch. I think even we have np->frag_size, we should consider dst_mtu(&rt->u.dst) as well. No? --yoshfuji - 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: [RFT] sky2 0.16
On Sun, 2006-02-19 at 14:20 +0100, Wolfgang Hoffmann wrote: > On Saturday 18 February 2006 18:00, Carl-Daniel Hailfinger wrote: > > Hi, > > > > Stephen Hemminger schrieb: > > > Could everyone who has problems with hangs try the > > > following patch (against current 2.6.16-rc3 version) > > > > If Stephen's patch doesn't work for you, could you try replacing > > sky2.c and sky2.h with the ones attached to this mail? I'd be very > > interested in feedback for my version of the hangfix. > > Yes, your version cures my hangs. Same here it seems... > Btw, I have the same chip as mentioned in your code comment (0xb6, rev1). > > Your code comment also seems to fit my debug-output in Stephen's 0.16 > (OP_PACKET in eth0 transmit ring). Diffing your code against 0.13 and 0.16, > it seems that 0.16 just handles the (work_done < to_do) scenario, but not the > "packets arrived since start of this function"? Well, I have to admit I have > no real understanding of what all this magic driver code does ;-) Couldn't that be added to 0.16/0.17 so we could try that with Stephens code... Imho, first it works, then we find out why it works =) -- Ian Kumlien -- http://pomac.netswarm.net signature.asc Description: This is a digitally signed message part
Re: (usagi-users 03610) Re: IPv6 setsockopt software MTU patch
Yes, Hugo Santos suggested me to use the minimum of both, the new patch is available there : http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch2 Thanks, Hoerdt Mickaël On Sun, Feb 19, 2006 at 11:13:44PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <[EMAIL PROTECTED]> (at Sun, 19 Feb 2006 14:47:09 +0100), [EMAIL > PROTECTED] says: > > > The fix is very simple, it only grab the value of frag_size and > > use it in ip6_fragment file, could you please review the patch which > > fix that problem at : > > > > http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch > > Thanks for the patch. > I think even we have np->frag_size, we should consider dst_mtu(&rt->u.dst) > as well. No? > > --yoshfuji > > - 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] keep track of network interface renaming
Christoph Hellwig <[EMAIL PROTECTED]> :
[...]
> the about to rename part is really noisy.
Yes.
@@ -730,7 +731,11 @@ int dev_change_name(struct net_device *d
else if (__dev_get_by_name(newname))
return -EEXIST;
else
+ {
-> a cleanup patch may be avoided if the "{" follows the "else"
+ if (strncmp(newname, dev->name, IFNAMSIZ))
+ printk(KERN_INFO "%s renamed to %s\n", dev->name,
newname);
-> I would rather do a quick return if (!strncmp(...)) (personnal taste).
--
Ueimor
-
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: (usagi-users 03611) Re: IPv6 setsockopt software MTU patch
In article <[EMAIL PROTECTED]> (at Sun, 19 Feb 2006 15:54:13 +0100), [EMAIL
PROTECTED] says:
> Yes, Hugo Santos suggested me to use the minimum of both, the new
> patch is available there :
>
> http://clarinet.u-strasbg.fr/~hoerdt/ip6_output.c.softfrag.patch2
Do you mean like this?
Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index efa3e72..3264740 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -494,6 +494,7 @@ static int ip6_fragment(struct sk_buff *
struct net_device *dev;
struct sk_buff *frag;
struct rt6_info *rt = (struct rt6_info*)skb->dst;
+ struct ipv6_pinfo *np = skb->sk ? inet6_sk(skb->sk) : NULL;
struct ipv6hdr *tmp_hdr;
struct frag_hdr *fh;
unsigned int mtu, hlen, left, len;
@@ -506,6 +507,8 @@ static int ip6_fragment(struct sk_buff *
nexthdr = *prevhdr;
mtu = dst_mtu(&rt->u.dst) - hlen - sizeof(struct frag_hdr);
+ if (np && np->frag_size && np->frag_size < dst_mtu(&rt->u.dst))
+ mtu = np->frag_size - hlen - sizeof(struct frag_hdr);
if (skb_shinfo(skb)->frag_list) {
int first_len = skb_pagelen(skb);
--
YOSHIFUJI Hideaki @ USAGI Project <[EMAIL PROTECTED]>
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
-
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: Merging Skylark's IOC3 patch
* Martin Michlmayr <[EMAIL PROTECTED]> [2006-02-19 21:15]:
> Can you please review and/or merge Skylark's IOC3 patch from
> ftp://ftp.linux-mips.org/pub/linux/mips/people/skylark/linux-mips-2.6.14-ioc3-r26.patch.bz2
>
> From my basic understanding I believe that this patch needs to be split up
> and submitted to different sub-system maintainers.
(netdev@vger.kernel.org, this is only a RFC for now since the main
support patch for IOC3 has not been merged yet.)
From: Stanislaw Skowronek <[EMAIL PROTECTED]>
[PATCH 3/5] net: Convert the SGI IOC3 Ethernet driver to use IOC3 meta driver
Convert the SGI IOC3 Ethernet driver to use the IOC3 meta driver.
Signed-off-by: Stanislaw Skowronek <[EMAIL PROTECTED]>
Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]>
---
Kconfig|2
ioc3-eth.c | 458 +++--
2 files changed, 55 insertions(+), 405 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 94ad74c..66c340d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -462,7 +462,7 @@ config MIPS_AU1X00_ENET
config SGI_IOC3_ETH
bool "SGI IOC3 Ethernet"
- depends on NET_ETHERNET && PCI && SGI_IP27
+ depends on NET_ETHERNET && SGI_IOC3
select CRC32
select MII
help
diff --git a/drivers/net/ioc3-eth.c b/drivers/net/ioc3-eth.c
index 9b8295e..8fadae6 100644
--- a/drivers/net/ioc3-eth.c
+++ b/drivers/net/ioc3-eth.c
@@ -5,6 +5,7 @@
*
* Driver for SGI's IOC3 based Ethernet cards as found in the PCI card.
*
+ * Copyright (C) 2005 Stanislaw Skowronek (port to meta-driver)
* Copyright (C) 1999, 2000, 2001, 2003 Ralf Baechle
* Copyright (C) 1995, 1999, 2000, 2001 by Silicon Graphics, Inc.
*
@@ -20,15 +21,13 @@
* o Use prefetching for large packets. What is a good lower limit for
*prefetching?
* o We're probably allocating a bit too much memory.
- * o Use hardware checksums.
- * o Convert to using a IOC3 meta driver.
* o Which PHYs might possibly be attached to the IOC3 in real live,
*which workarounds are required for them? Do we ever have Lucent's?
* o For the 2.5 branch kill the mii-tool ioctls.
*/
#define IOC3_NAME "ioc3-eth"
-#define IOC3_VERSION "2.6.3-3"
+#define IOC3_VERSION "2.6.4-s2"
#include
#include
@@ -45,11 +44,6 @@
#include
#include
-#ifdef CONFIG_SERIAL_8250
-#include
-#include
-#endif
-
#include
#include
#include
@@ -61,14 +55,19 @@
#include
#include
#include
+
+#ifdef CONFIG_SGI_IP30
+#include
+#else
#include
#include
#include
#include
#include
-#include
#include
+#endif
#include
+#include
/*
* 64 RX buffers. This is tunable in the range of 16 <= x < 512. The
@@ -81,6 +80,7 @@
/* Private per NIC data of the driver. */
struct ioc3_private {
+ struct ioc3_driver_data *idd;
struct ioc3 *regs;
unsigned long *rxr; /* pointer to receiver ring */
struct ioc3_etxd *txr;
@@ -149,8 +149,15 @@ static inline unsigned long ioc3_map(voi
return vdev | (0xaUL << PCI64_ATTR_TARG_SHFT) | PCI64_ATTR_PREF |
((unsigned long)ptr & TO_PHYS_MASK);
#else
+#ifdef CONFIG_SGI_IP30
+ vdev <<= 58; /* Shift to PCI64_ATTR_VIRTUAL */
+
+ return vdev | (0x8UL << PCI64_ATTR_TARG_SHFT) | PCI64_ATTR_PREF |
+ ((unsigned long)ptr & TO_PHYS_MASK);
+#else
return virt_to_bus(ptr);
#endif
+#endif
}
/* BEWARE: The IOC3 documentation documents the size of rx buffers as
@@ -226,219 +233,6 @@ static inline unsigned long ioc3_map(voi
#define ioc3_r_midr_w()be32_to_cpu(ioc3->midr_w)
#define ioc3_w_midr_w(v) do { ioc3->midr_w = cpu_to_be32(v); } while (0)
-static inline u32 mcr_pack(u32 pulse, u32 sample)
-{
- return (pulse << 10) | (sample << 2);
-}
-
-static int nic_wait(struct ioc3 *ioc3)
-{
- u32 mcr;
-
-do {
-mcr = ioc3_r_mcr();
-} while (!(mcr & 2));
-
-return mcr & 1;
-}
-
-static int nic_reset(struct ioc3 *ioc3)
-{
-int presence;
-
- ioc3_w_mcr(mcr_pack(500, 65));
- presence = nic_wait(ioc3);
-
- ioc3_w_mcr(mcr_pack(0, 500));
- nic_wait(ioc3);
-
-return presence;
-}
-
-static inline int nic_read_bit(struct ioc3 *ioc3)
-{
- int result;
-
- ioc3_w_mcr(mcr_pack(6, 13));
- result = nic_wait(ioc3);
- ioc3_w_mcr(mcr_pack(0, 100));
- nic_wait(ioc3);
-
- return result;
-}
-
-static inline void nic_write_bit(struct ioc3 *ioc3, int bit)
-{
- if (bit)
- ioc3_w_mcr(mcr_pack(6, 110));
- else
- ioc3_w_mcr(mcr_pack(80, 30));
-
- nic_wait(ioc3);
-}
-
-/*
- * Read a byte from an iButton device
- */
-static u32 nic_read_byte(struct ioc3 *ioc3)
-{
- u32 result = 0;
- int i;
-
- for (i = 0; i < 8; i++)
- result = (result >> 1) | (nic_read_bit(ioc3) << 7);
-
- return result;
-}
-
-/*
- * W
Re: [RFT] sky2 0.16
On Sun, 2006-02-19 at 14:20 +0100, Wolfgang Hoffmann wrote: > On Saturday 18 February 2006 18:00, Carl-Daniel Hailfinger wrote: > > Hi, > > > > Stephen Hemminger schrieb: > > > Could everyone who has problems with hangs try the > > > following patch (against current 2.6.16-rc3 version) > > > > If Stephen's patch doesn't work for you, could you try replacing > > sky2.c and sky2.h with the ones attached to this mail? I'd be very > > interested in feedback for my version of the hangfix. > > Yes, your version cures my hangs. It's official, it cures my hangs as well, but it doesn't do MSI, and MSI might add some additional complexity. I would like to hear some comments from Stephen about all this... And i would also like these changes to be properly merged with his latest version. And hear a statement about MSI complexity vs common APIC irqs... (I know that there was some MSI bugs before thats why i retried when they were fixed, running -rc4 since it was released now) -- Ian Kumlien -- http://pomac.netswarm.net signature.asc Description: This is a digitally signed message part
[PATCH] Improve wording of MV643XX_ETH in Kconfig
Slightly improve the wording of the description of MV643XX_ETH in Kconfig. This difference was found between the mainline and linux-mips kernel trees. Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]> --- linux-2.6.16-rc4/drivers/net/Kconfig2006-02-19 20:09:06.0 + +++ mips-2.6.16-rc4/drivers/net/Kconfig 2006-02-19 20:15:20.0 + @@ -2196,8 +2212,8 @@ depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || MOMENCO_OCELOT_3 || PPC_MULTIPLATFORM help This driver supports the gigabit Ethernet on the Marvell MV643XX - chipset which is used in the Momenco Ocelot C and Jaguar ATX and - Pegasos II, amongst other PPC and MIPS boards. + chipset which is used in the Momenco Ocelot C Ocelot, Jaguar ATX + and Pegasos II, amongst other PPC and MIPS boards. config MV643XX_ETH_0 bool "MV-643XX Port 0" -- Martin Michlmayr http://www.cyrius.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: Diff between Linus' and linux-mips git: declance
Remove delta between Linus' and linux-mips git trees in declance
There are two changes between the Linus' and linux-mips git trees
regarding the declaner driver. The first change is certainly correct
(as it is consistent with the rest of the file) and should be applied
to mainline; the other change seems correct too.
Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]>
--- linux-2.6.16-rc4/drivers/net/declance.c 2006-02-19 20:09:07.0
+
+++ mips-2.6.16-rc4/drivers/net/declance.c 2006-02-19 20:15:22.0
+
@@ -704,8 +704,8 @@
return IRQ_HANDLED;
}
-static irqreturn_t
-lance_interrupt(const int irq, void *dev_id, struct pt_regs *regs)
+static irqreturn_t lance_interrupt(const int irq, void *dev_id,
+ struct pt_regs *regs)
{
struct net_device *dev = (struct net_device *) dev_id;
struct lance_private *lp = netdev_priv(dev);
@@ -1255,7 +1255,7 @@
return 0;
err_out_free_dev:
- kfree(dev);
+ free_netdev(dev);
err_out:
return ret;
--
Martin Michlmayr
http://www.cyrius.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
[RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
From: John Bowler <[EMAIL PROTECTED]>
Some Ethernet hardware implementations have no built-in storage for
allocated MAC values - an example is the Intel IXP420 chip which has
support for Ethernet but no defined way of storing allocated MAC values.
With such hardware different board level implementations store the
allocated MAC (or MACs) in different ways. Rather than put board level
code into a specific Ethernet driver this driver provides a generally
accessible repository for the MACs which can be written by board level
code and read by the driver.
The implementation also allows user level programs to access the MAC
information in /proc/net/maclist. This is useful as it allows user space
code to use the MAC if it is not used by a built-in driver.
This driver has been used for several months on various IXP420 based
platforms within the NSLU2-Linux project, including the Linksys NSLU2.
A sample implementation of the use of maclist is sent as patch 2. This
one is for the Linksys NSLU2, but several more patches for other IXP420
based platforms are available.
Signed-off-by: John Bowler <[EMAIL PROTECTED]>
Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]>
Signed-off-by: Alessandro Zummo <[EMAIL PROTECTED]>
Signed-off-by: Rod Whitby <[EMAIL PROTECTED]>
---
drivers/net/Kconfig | 15 ++
drivers/net/Makefile |1
drivers/net/maclist.c | 314 ++
include/net/maclist.h | 23 +++
4 files changed, 353 insertions(+)
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-nslu2/include/net/maclist.h 2006-02-06 22:35:23.0 +0100
@@ -0,0 +1,23 @@
+#ifndef _MACLIST_H
+#define _MACLIST_H 1
+/*
+ * Interfaces to the MAC repository
+ */
+/*
+ * Add a single entry, returns 0 on success else an error
+ * code. Must *not* be called from an interrupt handler.
+ */
+extern int maclist_add(const u8 id_to_add[6]);
+
+/*
+ * Return the current entry count (valid in any context).
+ */
+extern int maclist_count(void);
+
+/*
+ * Return the ID from the n'th entry (valid in any context),
+ * returns 0 on success, -EINVAL if 'n' is out of range.
+ */
+extern int maclist_read(u8 (*buffer_for_id)[6], int index_of_id_to_return);
+
+#endif /*_MACLIST_H*/
--- /dev/null 1970-01-01 00:00:00.0 +
+++ linux-nslu2/drivers/net/maclist.c 2006-02-06 22:35:23.0 +0100
@@ -0,0 +1,314 @@
+/*
+ * drivers/net/maclist.c
+ *
+ * a simple driver to remember ethernet MAC values
+ *
+ * Some Ethernet hardware implementations have no built-in
+ * storage for allocated MAC values - an example is the Intel
+ * IXP420 chip which has support for Ethernet but no defined
+ * way of storing allocated MAC values. With such hardware
+ * different board level implementations store the allocated
+ * MAC (or MACs) in different ways. Rather than put board
+ * level code into a specific Ethernet driver this driver
+ * provides a generally accessible repository for the MACs
+ * which can be written by board level code and read by the
+ * driver.
+ *
+ * The implementation also allows user level programs to
+ * access the MAC information in /proc/net/maclist. This is
+ * useful as it allows user space code to use the MAC if it
+ * is not used by a built-in driver.
+ *
+ * Copyright (C) 2005 John Bowler
+ * Author: John Bowler <[EMAIL PROTECTED]>
+ * Maintainers: http://www.nslu2-linux.org/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * External interfaces:
+ * Interfaces to linux kernel (and modules)
+ * maclist_add: add a single MAC
+ * maclist_count: total number of MACs stored
+ * maclist_read: read a MAC 0..(maclist_count-1)
+ */
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define MACLIST_NAME "maclist"
+
+MODULE_AUTHOR("John Bowler <[EMAIL PROTECTED]>");
+MODULE_DESCRIPTION("MAC list repository");
+MODULE_LICENSE("GPL");
+
+typedef struct maclist_entry {
+ struct maclist_entry *next; /* Linked list, first first */
+ u8id[6]; /* 6 byte Ethernet MAC */
+} maclist_entry_t;
+
+/* Access to this list is possible at any time - entries in
+ * the list are never destroyed. Modification of the list is
+ * safe only from the init code (i.e. modification must be
+ * single threaded), but read from an interrupt at the same
+ * time is possible and safe.
+ */
+static maclist_entry_t *maclist_list = 0;
+
+/*
+ * External interfaces.
+ *
+ * Add a single entry, returns 0 on success else an error
+ * code. Must be single threaded.
+ */
+int maclist_add(const u8 new_id[6]) {
+ maclist_entry_t *new_entry, **tail;
+
+ if (new_id == 0 || !is_valid_ether_addr(new_id)) {
+ printk(KERN_ERR MACLIST_NAME ": invalid ethernet address\n");
+ return -EINVAL;
+ }
+ new_entry = kmalloc(sizeof *new_entry, GFP_KERNEL);
+
[RFC] [PATCH 2/2] Driver to remember ethernet MAC values: NSLU2 support
From: John Bowler <[EMAIL PROTECTED]>
Implement maclist support for the Linksys NSLU2. The MAC address is read
from the RedBoot partition in flash.
Signed-off-by: John Bowler <[EMAIL PROTECTED]>
Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]>
Signed-off-by: Alessandro Zummo <[EMAIL PROTECTED]>
Signed-off-by: Rod Whitby <[EMAIL PROTECTED]>
--
arch/arm/mach-ixp4xx/Kconfig |4 +--
arch/arm/mach-ixp4xx/nslu2-setup.c | 39 +
2 files changed, 41 insertions(+), 2 deletions(-)
--- linux-nslu2.orig/arch/arm/mach-ixp4xx/nslu2-setup.c 2006-02-06
22:34:55.0 +0100
+++ linux-nslu2/arch/arm/mach-ixp4xx/nslu2-setup.c 2006-02-06
22:35:31.0 +0100
@@ -16,11 +16,14 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
+
static struct flash_platform_data nslu2_flash_data = {
.map_name = "cfi_probe",
.width = 2,
@@ -117,6 +120,37 @@ static void nslu2_power_off(void)
gpio_line_set(NSLU2_PO_GPIO, IXP4XX_GPIO_HIGH);
}
+/*
+ * When the RedBoot partition is added the MAC address is read from
+ * it.
+ */
+static void nslu2_flash_add(struct mtd_info *mtd) {
+ if (strcmp(mtd->name, "RedBoot") == 0) {
+ size_t retlen;
+ u_char mac[6];
+
+ /* The MAC is at a known offset... */
+ if (mtd->read(mtd, 0x3FFB0, 6, &retlen, mac) == 0 && retlen ==
6) {
+ printk(KERN_INFO "NSLU2 MAC:
%.2x:%.2x:%.2x:%.2x:%.2x:%.2x\n",
+ mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
+ maclist_add(mac);
+ } else {
+ printk(KERN_ERR "NSLU2 MAC: read failed\n");
+ }
+ }
+}
+
+/*
+ * Nothing to do on remove at present.
+ */
+static void nslu2_flash_remove(struct mtd_info *mtd) {
+}
+
+static struct mtd_notifier nslu2_flash_notifier = {
+ .add = nslu2_flash_add,
+ .remove = nslu2_flash_remove,
+};
+
static void __init nslu2_init(void)
{
/* The NSLU2 has a 33MHz crystal on board - 1.01% different
@@ -124,6 +158,11 @@ static void __init nslu2_init(void)
*/
ixp4xx_set_board_tick_rate(6600);
+ /* The flash has an ethernet MAC embedded in it which we need,
+* that is all this notifier does.
+*/
+ register_mtd_user(&nslu2_flash_notifier);
+
ixp4xx_sys_init();
pm_power_off = nslu2_power_off;
--
Martin Michlmayr
http://www.cyrius.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: [PKT_SCHED 00/05]: net/sched patches for 2.6.17
On Sun, 2006-19-02 at 00:42 -0800, David S. Miller wrote: > From: jamal <[EMAIL PROTECTED]> > Date: Thu, 16 Feb 2006 07:56:44 -0500 > > > [1]I have to put a disclaimer: I am always a stickler as far as RED > > is concerned (Thomas can testify to that) because it is very > > delicate (not the code rather the algorithm) and i have suffered a > > lot in the past getting those parameters tuned. There was a gent who > > was interested in putting together regression tests for RED but he > > keeps disappearing on us. > > There is a limit to how far you can apply this limitation on other > people. Nobody can touch RED in any significant way because of this > roadblock. > > I would say it's justified if you had some full regression suite you > were working on, but you're not and you won't be able to cook one up > any time soon. > > There is a point at which the folks doing the work get to make the > decisions, and that is leaning towards Patrick and others at this > point. I think I have sufficiently expressed my views and progress needs to be made; therefore I ACK the patch. Note the definition of "work" is very highly debatable as to be just constrained to producing code but i think thats a different discussion that perhaps is better suited for a slot in netconf. cheers, jamal - 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
[DOC]: xfrm sync
Something i wrote around the time of coding the sync stuff.
Just so i dont loose it - here it is attached ;->
cheers,
jamal
The sync patches work is based on initial patches from
Krisztian <[EMAIL PROTECTED]> and others.
The end goal is to be able to insert attributes + generate events so that the
an SA can be safely moved from one machine to another for HA purposes.
The idea is to synchronize the SA so that the takeover machine can do
the processing of the SA as accurate as possible if it has access to it.
We already have the ability to generate SA add/del/upd events.
The next step (these patches) is to have accurate lifetime byte (to
ensure proper decay of SAs) and replay counters to avoid replay attacks
with as minimal loss at failover time.
This way a backup stays as closely uptodate as an active member.
Because the above items change for every packet the SA receives,
it is possible for a lot of the events to be generated.
For this reason, we also add a nagle-like algorithm to restrict
the events. i.e we are going to set thresholds to say "let me
know if the replay sequence threshold is reached or 10 secs have passed"
The identified items that need to be synchronized are:
- the lifetime byte counter
note that: lifetime time limit is not important if you assume the failover
machine is known ahead of time since the decay of the time countdown
is not driven by packet arrival.
- the replay sequence for both inbound and outbound
1) Message Structure
--
nlmsghdr:aevent_id:optional-TLVs.
The netlink message types are:
XFRM_MSG_NEWAE and XFRM_MSG_GETAE.
A XFRM_MSG_GETAE does not have TLVs.
A XFRM_MSG_NEWAE will have at least two TLVs (as is
discussed further below).
aevent_id structure looks like:
struct xfrm_aevent_id {
__u32 flags;
struct xfrm_usersa_id sa_id;
};
xfrm_usersa_id in this message layout identifies the SA.
flags are used to indicate different things. The possible
flags are:
XFRM_AE_RTHR=1, /* replay threshold*/
XFRM_AE_RVAL=2, /* replay value */
XFRM_AE_LVAL=4, /* lifetime value */
XFRM_AE_ETHR=8, /* expiry timer threshold */
XFRM_AE_CR=16, /* Event cause is replay update */
XFRM_AE_CE=32, /* Event cause is timer expiry */
XFRM_AE_CU=64, /* Event cause is policy update */
How these flags are used is dependent on the direction of the
message (kernel<->user) as well the cause (config, query or event).
This is described below in the different messages.
The pid will be set appropriately in netlink to recognize direction
(0 to the kernel and pid = processid that created the event
when going from kernel to user space)
A program needs to subscribe to multicast group XFRMNLGRP_AEVENTS
to get notified of these events.
2) TLVS reflect the different parameters:
-
a) byte value (XFRMA_LTIME_VAL)
This TLV carries the running/current counter for byte lifetime since
last event.
b)replay value (XFRMA_REPLAY_VAL)
This TLV carries the running/current counter for replay sequence since
last event.
c)replay threshold (XFRMA_REPLAY_THRESH)
This TLV carries the threshold being used by the kernel to trigger events
when the replay sequence is exceeded.
d) expiry timer (XFRMA_ETIMER_THRESH)
This is a timer value in milliseconds which is used as the nagle
value to rate limit the events.
3) Default configurations for the parameters:
--
By default these events should be turned off unless there is
at least one listener registered to listen to the multicast
group XFRMNLGRP_AEVENTS.
Programs installing SAs will need to specify the two thresholds, however,
in order to not change existing applications such as racoon
we also provide default threshold values for these different parameters
in case they are not specified.
the two sysctls/proc entries are:
a) /proc/sys/net/core/sysctl_xfrm_aevent_etime
used to provide default values for the XFRMA_ETIMER_THRESH in incremental
units of time of 100ms. The default is 10 (1 second)
b) /proc/sys/net/core/sysctl_xfrm_aevent_rseqth
used to provide default values for XFRMA_REPLAY_THRESH parameter
in incremental packet count. The default is two packets.
4) Message types
a) XFRM_MSG_GETAE issued by user-->kernel.
XFRM_MSG_GETAE does not carry any TLVs.
The response is a XFRM_MSG_NEWAE which is formatted based on what
XFRM_MSG_GETAE queried for.
The response will always have XFRMA_LTIME_VAL and XFRMA_REPLAY_VAL TLVs.
*if XFRM_AE_RTHR flag is set, then XFRMA_REPLAY_THRESH is also retrieved
*if XFRM_AE_ETHR flag is set, then XFRMA_ETIMER_THRESH is also retrieved
b) XFRM_MSG_NEWAE is issued by either user space to configure
or kernel to announce events or respond to a XFRM_MSG_GETAE.
i) user --> kernel to configure a specific SA.
any of the values or threshold parameters can be updated by passing the
app
Re: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
On Mon, Feb 20, 2006 at 01:01:13AM +, Martin Michlmayr wrote: > From: John Bowler <[EMAIL PROTECTED]> > > Some Ethernet hardware implementations have no built-in storage for > allocated MAC values - an example is the Intel IXP420 chip which has > support for Ethernet but no defined way of storing allocated MAC values. > With such hardware different board level implementations store the > allocated MAC (or MACs) in different ways. Rather than put board level > code into a specific Ethernet driver this driver provides a generally > accessible repository for the MACs which can be written by board level > code and read by the driver. > > The implementation also allows user level programs to access the MAC > information in /proc/net/maclist. This is useful as it allows user space > code to use the MAC if it is not used by a built-in driver. > > This driver has been used for several months on various IXP420 based > platforms within the NSLU2-Linux project, including the Linksys NSLU2. > A sample implementation of the use of maclist is sent as patch 2. This > one is for the Linksys NSLU2, but several more patches for other IXP420 > based platforms are available. >... Silly question: Why can't this be implemented in user space using the SIOCSIFHWADDR ioctl? > Martin Michlmayr cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
On Mon, 20 Feb 2006 02:47:35 +0100 Adrian Bunk <[EMAIL PROTECTED]> wrote: > > Some Ethernet hardware implementations have no built-in storage for > > allocated MAC values - an example is the Intel IXP420 chip which has > > support for Ethernet but no defined way of storing allocated MAC values. > > With such hardware different board level implementations store the > > allocated MAC (or MACs) in different ways. Rather than put board level > > c > Silly question: > > Why can't this be implemented in user space using the SIOCSIFHWADDR > ioctl? Because sometimes you need to have networking available well before userspace. (netconsole, root over nfs, ...) -- Best regards, Alessandro Zummo, Tower Technologies - Turin, Italy http://www.towertech.it - 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: [RFC] [PATCH 1/2] Driver to remember ethernet MAC values: maclist
On Mon, Feb 20, 2006 at 03:01:46AM +0100, Alessandro Zummo wrote: > On Mon, 20 Feb 2006 02:47:35 +0100 > Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > Some Ethernet hardware implementations have no built-in storage for > > > allocated MAC values - an example is the Intel IXP420 chip which has > > > support for Ethernet but no defined way of storing allocated MAC values. > > > With such hardware different board level implementations store the > > > allocated MAC (or MACs) in different ways. Rather than put board level > > > c > > Silly question: > > > > Why can't this be implemented in user space using the SIOCSIFHWADDR > > ioctl? > > Because sometimes you need to have networking available > well before userspace. > > (netconsole, root over nfs, ...) Why can't setting MAC addresses be done from initramfs? > Best regards, > Alessandro Zummo, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [PKT_SCHED 00/05]: net/sched patches for 2.6.17
From: jamal <[EMAIL PROTECTED]> Date: Sun, 19 Feb 2006 20:14:26 -0500 > I think I have sufficiently expressed my views and progress needs to be > made; therefore I ACK the patch. > > Note the definition of "work" is very highly debatable as to be just > constrained to producing code but i think thats a different discussion > that perhaps is better suited for a slot in netconf. Ok. - 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: [DOC]: xfrm sync
From: jamal <[EMAIL PROTECTED]> Date: Sun, 19 Feb 2006 20:43:33 -0500 > Something i wrote around the time of coding the sync stuff. > Just so i dont loose it - here it is attached ;-> Why don't we put this under Documentation/networking/ as "xfrm_sync.txt"? If you agree, please give me a Signed-off-by: line, thanks a lot Jamal. - 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: [PKT_SCHED 04/05]: Convert sch_red to a classful qdisc
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed, 15 Feb 2006 09:54:57 +0100 (MET) > [PKT_SCHED]: Convert sch_red to a classful qdisc > > Convert sch_red to a classful qdisc. All qdiscs that maintain accurate > backlog counters are eligible as child qdiscs. When a queue limit larger > than zero is given, a bfifo qdisc is used for backwards compatibility. > Current versions of tc enforce a limit larger than zero, other users > can avoid creating the default qdisc by using zero. > > Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> Applied, thanks 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
[XFRM 2.6.16]: Fix policy double put
[XFRM]: Fix policy double put The policy is put once immediately and once at the error label, which results in the following Oops: kernel BUG at net/xfrm/xfrm_policy.c:250! invalid opcode: [#2] PREEMPT [...] CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00210246 (2.6.16-rc3 #39) EIP is at __xfrm_policy_destroy+0xf/0x46 eax: d49f2000 ebx: d49f2000 ecx: f74bd880 edx: f74bd280 esi: d49f2000 edi: 0001 ebp: cd506dcc esp: cd506dc8 ds: 007b es: 007b ss: 0068 Process ssh (pid: 31970, threadinfo=cd506000 task=cfb04a70) Stack: <0>cd506000 cd506e34 c028e92b ebde7280 cd506e58 cd506ec0 f74bd280 0214 000a 000a 0002 f7ae6000 cd506e58 cd506e14 c0299e36 f74bd280 e873fe00 c02943fd cd506ec0 ebde7280 f271f440 Call Trace: [] show_stack_log_lvl+0xaa/0xb5 [] show_registers+0x126/0x18c [] die+0x14e/0x1db [] do_trap+0x7c/0x96 [] do_invalid_op+0x89/0x93 [] error_code+0x4f/0x54 [] xfrm_lookup+0x349/0x3c2 [] ip6_datagram_connect+0x317/0x452 [] inet_dgram_connect+0x49/0x54 [] sys_connect+0x51/0x68 [] sys_socketcall+0x6f/0x166 [] syscall_call+0x7/0xb Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]> --- commit 97bb1645f85a397f70b5f40c90a6bcf28ba674c2 tree 359003912402be28114d92cd5a9369bff8556d91 parent 219e70c402d40ae08442122550ad900e65fde1cf author Patrick McHardy <[EMAIL PROTECTED]> Mon, 20 Feb 2006 06:12:00 +0100 committer Patrick McHardy <[EMAIL PROTECTED]> Mon, 20 Feb 2006 06:12:00 +0100 net/xfrm/xfrm_policy.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c index 98ec53b..5e6b05a 100644 --- a/net/xfrm/xfrm_policy.c +++ b/net/xfrm/xfrm_policy.c @@ -885,8 +885,6 @@ restart: * We can't enlist stable bundles either. */ write_unlock_bh(&policy->lock); - - xfrm_pol_put(policy); if (dst) dst_free(dst);
Re: [Patch 1/6] IPSEC: core updates
In article <[EMAIL PROTECTED]> (at Fri, 27 Jan 2006 08:05:23 -0500), jamal
<[EMAIL PROTECTED]> says:
> diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
> index 82fbb75..b54a129 100644
> --- a/include/linux/xfrm.h
> +++ b/include/linux/xfrm.h
:
> @@ -235,6 +258,11 @@ struct xfrm_usersa_id {
> __u8proto;
> };
>
> +struct xfrm_aevent_id {
> + __u32 flags;
> + struct xfrm_usersa_id sa_id;
> +};
> +
> struct xfrm_userspi_info {
> struct xfrm_usersa_info info;
> __u32 min;
:
Maybe paranoid, but anyway...
Jamal, is this okay on 64/32 biarch, which means, there are no differenes
between 32bit arch and 64bit arch?
IMHO, because of alignment, it is better to swap flags and sa_id,
isn't it?
--yoshfuji
-
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
Can't pull updates from softmac-all branch
Hi, This was working before, but today it does not: # cg-update r-softmac-all Recovering from a previously interrupted fetch... WARNING: The rsync access method is DEPRECATED and will be REMOVED in the future! Fetching head... MOTD: MOTD: Welcome to the Linux Kernel Archive. MOTD: MOTD: Due to U.S. Exports Regulations, all cryptographic software on this MOTD: site is subject to the following legal notice: MOTD: MOTD: This site includes publicly available encryption source code MOTD: which, together with object code resulting from the compiling of MOTD: publicly available source code, may be exported from the United MOTD: States under License Exception "TSU" pursuant to 15 C.F.R. Section MOTD: 740.13(e). MOTD: MOTD: This legal notice applies to cryptographic software only. MOTD: Please see the Bureau of Industry and Security, MOTD: http://www.bis.doc.gov/ for more information about current MOTD: U.S. regulations. MOTD: receiving file list ... done sent 4 bytes received 9 bytes 2.36 bytes/sec total size is 0 speedup is 0.00 cg-fetch: unable to get the head pointer of branch softmac-all -- vda - 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: [XFRM 2.6.16]: Fix policy double put
On Mon, Feb 20, 2006 at 06:13:03AM +0100, Patrick McHardy wrote:
>
> [XFRM]: Fix policy double put
>
> The policy is put once immediately and once at the error label, which results
> in the following Oops:
Looks good to me. Thanks for catching this Patrick.
--
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: [XFRM 2.6.16]: Fix policy double put
Herbert Xu wrote: > On Mon, Feb 20, 2006 at 06:13:03AM +0100, Patrick McHardy wrote: > >>[XFRM]: Fix policy double put >> >>The policy is put once immediately and once at the error label, which results >>in the following Oops: > > > Looks good to me. Thanks for catching this Patrick. It caught me :) - 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: [XFRM 2.6.16]: Fix policy double put
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon, 20 Feb 2006 07:00:03 +0100 > Herbert Xu wrote: > > On Mon, Feb 20, 2006 at 06:13:03AM +0100, Patrick McHardy wrote: > > > >>[XFRM]: Fix policy double put > >> > >>The policy is put once immediately and once at the error label, which > >>results > >>in the following Oops: > > > > > > Looks good to me. Thanks for catching this Patrick. > > It caught me :) Applied, thanks. I think this is -stable material, agreed? - 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: [XFRM 2.6.16]: Fix policy double put
David S. Miller wrote: > Applied, thanks. > > I think this is -stable material, agreed? It was only introduced recently by the "[IPSEC]: Fix strange IPsec freeze." patch. - 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: [XFRM 2.6.16]: Fix policy double put
From: Patrick McHardy <[EMAIL PROTECTED]> Date: Mon, 20 Feb 2006 07:16:38 +0100 > David S. Miller wrote: > > Applied, thanks. > > > > I think this is -stable material, agreed? > > It was only introduced recently by the "[IPSEC]: Fix strange IPsec > freeze." patch. Ok, thanks for the clarification. - 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 1/6] IPSEC: core updates
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Mon, 20 Feb 2006 14:29:47 +0900 (JST)
> > +struct xfrm_aevent_id {
> > + __u32 flags;
> > + struct xfrm_usersa_id sa_id;
> > +};
> > +
> > struct xfrm_userspi_info {
> > struct xfrm_usersa_info info;
> > __u32 min;
> :
>
> Maybe paranoid, but anyway...
>
> Jamal, is this okay on 64/32 biarch, which means, there are no differenes
> between 32bit arch and 64bit arch?
> IMHO, because of alignment, it is better to swap flags and sa_id,
> isn't it?
I agree, this needs serious consideration.
-
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] IrDA: irda-usb bug fixes
From: Samuel Ortiz <[EMAIL PROTECTED]> Date: Sat, 18 Feb 2006 19:19:13 +0200 > This patch fixes 2 bugs in the USB-IrDA code. > > The first one is a buffer overrun in the RX path. We are now using > IRDA_SKB_MAX_MTU when initializing the Rx URB. > > The second one is a potential stack recursion when unplugging the USB dongle. > It seems that first we get the Rx URB with a generic error code, and after a > while the Rx URB comes again with a "disconnect" error code. > Since we are resubmitting the Rx URB immediately after receiving the first > error one, we might enter an endless loop. > > When getting an error Rx URB, the patch defers the Rx URB resubmitting so > that it gives us a chance to catch the disconnect one, in case the dongle has > juts been unplugged. > > Tested against 2.6.16-rc2. > > Patch from Jean Tourrilhes > > Signed-off-by: Jean Tourrilhes <[EMAIL PROTECTED]> > Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]> Applied, thanks Samuel. - 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]: NETFILTER: remove duplicated operation and fix order in skb_clone().
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Fri, 17 Feb 2006 21:51:01 +0900 (JST) > [NET]: NETFILTER: remove duplicated lines and fix order in skb_clone(). > > Some of netfilter-related members are initalized / copied twice in > skb_clone(). Remove one. Pointed out by Olivier MATZ <[EMAIL PROTECTED]>. > > And this patch also fixes order of copying / clearing members. > > Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Patch applied to net-2.6, thank you very much. - 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
[NETFILTER]: Fix skb->nf_bridge lifetime issues
Bart, can you please have a look at this patch and ACK/NACK it?
We have a bugreport in the netfilter bugzilla of broken conntrack
with tunnels on top of bridge devices (#448), which should be cured
by this patch.
There is also another report of broken conntrack with vlan on top
of bridge devices (#400) that looks related, but probably this
patch won't help.
[NETFILTER]: Fix skb->nf_bridge lifetime issues
The bridge netfilter code simulates the NF_IP_PRE_ROUTING hook and skips
the real hook by registering with high priority and returning NF_STOP if
skb->nf_bridge is present and the BRNF_NF_BRIDGE_PREROUTING flag is not
set. The flag is only set during the simulated hook.
Because skb->nf_bridge is only freed when the packet is destroyed, the
packet will not only skip the first invocation of NF_IP_PRE_ROUTING, but
in the case of tunnel devices on top of the bridge also all further ones.
Forwarded packets from a bridge encapsulated by a tunnel device and sent
as locally outgoing packet will also still have the incorrect bridge
information from the input path attached.
We already have nf_reset calls on all RX/TX paths of tunnel devices,
so simply reset the nf_bridge field there too. As an added bonus,
the bridge information for locally delivered packets is now also freed
when the packet is queued to a socket.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit 22e4dcb796d276db47a61c2382bdf2eaf76db32e
tree ccc5173acbe70506aa60e826e1881a4513f8c868
parent 337ba256a7e68f174a88ffba805b40622297fc22
author Patrick McHardy <[EMAIL PROTECTED]> Mon, 20 Feb 2006 08:41:48 +0100
committer Patrick McHardy <[EMAIL PROTECTED]> Mon, 20 Feb 2006 08:41:48 +0100
include/linux/skbuff.h | 24 ++--
net/ipv4/netfilter/ipt_REJECT.c |4
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 838ce0f..65bf1fa 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1351,16 +1351,6 @@ static inline void nf_conntrack_put_reas
kfree_skb(skb);
}
#endif
-static inline void nf_reset(struct sk_buff *skb)
-{
- nf_conntrack_put(skb->nfct);
- skb->nfct = NULL;
-#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
- nf_conntrack_put_reasm(skb->nfct_reasm);
- skb->nfct_reasm = NULL;
-#endif
-}
-
#ifdef CONFIG_BRIDGE_NETFILTER
static inline void nf_bridge_put(struct nf_bridge_info *nf_bridge)
{
@@ -1373,6 +1363,20 @@ static inline void nf_bridge_get(struct
atomic_inc(&nf_bridge->use);
}
#endif /* CONFIG_BRIDGE_NETFILTER */
+static inline void nf_reset(struct sk_buff *skb)
+{
+ nf_conntrack_put(skb->nfct);
+ skb->nfct = NULL;
+#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
+ nf_conntrack_put_reasm(skb->nfct_reasm);
+ skb->nfct_reasm = NULL;
+#endif
+#ifdef CONFIG_BRIDGE_NETFILTER
+ nf_bridge_put(skb->nfct);
+ skb->nfct = NULL;
+#endif
+}
+
#else /* CONFIG_NETFILTER */
static inline void nf_reset(struct sk_buff *skb) {}
#endif /* CONFIG_NETFILTER */
diff --git a/net/ipv4/netfilter/ipt_REJECT.c b/net/ipv4/netfilter/ipt_REJECT.c
index 26ea6c1..9d3b357 100644
--- a/net/ipv4/netfilter/ipt_REJECT.c
+++ b/net/ipv4/netfilter/ipt_REJECT.c
@@ -154,10 +154,6 @@ static void send_reset(struct sk_buff *o
/* This packet will not be the same as the other: clear nf fields */
nf_reset(nskb);
nskb->nfmark = 0;
-#ifdef CONFIG_BRIDGE_NETFILTER
- nf_bridge_put(nskb->nf_bridge);
- nskb->nf_bridge = NULL;
-#endif
tcph = (struct tcphdr *)((u_int32_t*)nskb->nh.iph + nskb->nh.iph->ihl);
