[git patches] net driver fixes
Please pull from 'upstream-linus' branch of master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git upstream-linus to receive the following updates: drivers/net/myri10ge/myri10ge.c |2 - drivers/net/skge.c|5 drivers/net/via-velocity.c| 17 --- drivers/net/wireless/Kconfig |1 drivers/net/wireless/bcm43xx/bcm43xx_main.c |2 - drivers/net/wireless/orinoco.c|4 +-- drivers/net/wireless/zd1201.c |2 + net/ieee80211/Kconfig |1 net/ieee80211/softmac/ieee80211softmac_auth.c | 28 -- 9 files changed, 44 insertions(+), 18 deletions(-) Brice Goglin: myri10ge - Always do a dummy RDMA after loading the firmware Chuck Ebbert: ieee80211: TKIP requires CRC32 Dan Williams: orinoco: fix setting transmit key only Daniel Drake: softmac: do shared key auth in workqueue Jay Cliburn: via-velocity: fix speed and link status reported by ethtool Pavel Machek: zd1201: workaround interference problem Robert Schulze: airo: should select crypto_aes Stephen Hemminger: skge: chip clock rate typo diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c index 07ca948..c3e52c8 100644 --- a/drivers/net/myri10ge/myri10ge.c +++ b/drivers/net/myri10ge/myri10ge.c @@ -620,7 +620,7 @@ static int myri10ge_load_firmware(struct return -ENXIO; } dev_info(&mgp->pdev->dev, "handoff confirmed\n"); - myri10ge_dummy_rdma(mgp, mgp->tx.boundary != 4096); + myri10ge_dummy_rdma(mgp, 1); return 0; } diff --git a/drivers/net/skge.c b/drivers/net/skge.c index 82200bf..7de9a07 100644 --- a/drivers/net/skge.c +++ b/drivers/net/skge.c @@ -516,10 +516,7 @@ static int skge_set_pauseparam(struct ne /* Chip internal frequency for clock calculations */ static inline u32 hwkhz(const struct skge_hw *hw) { - if (hw->chip_id == CHIP_ID_GENESIS) - return 53215; /* or: 53.125 MHz */ - else - return 78215; /* or: 78.125 MHz */ + return (hw->chip_id == CHIP_ID_GENESIS) ? 53125 : 78125; } /* Chip HZ to microseconds */ diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c index f5b0078..aa9cd92 100644 --- a/drivers/net/via-velocity.c +++ b/drivers/net/via-velocity.c @@ -2742,7 +2742,7 @@ static u32 check_connection_type(struct if (PHYSR0 & PHYSR0_SPDG) status |= VELOCITY_SPEED_1000; - if (PHYSR0 & PHYSR0_SPD10) + else if (PHYSR0 & PHYSR0_SPD10) status |= VELOCITY_SPEED_10; else status |= VELOCITY_SPEED_100; @@ -2851,8 +2851,17 @@ static int velocity_get_settings(struct u32 status; status = check_connection_type(vptr->mac_regs); - cmd->supported = SUPPORTED_TP | SUPPORTED_Autoneg | SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full; - if (status & VELOCITY_SPEED_100) + cmd->supported = SUPPORTED_TP | + SUPPORTED_Autoneg | + SUPPORTED_10baseT_Half | + SUPPORTED_10baseT_Full | + SUPPORTED_100baseT_Half | + SUPPORTED_100baseT_Full | + SUPPORTED_1000baseT_Half | + SUPPORTED_1000baseT_Full; + if (status & VELOCITY_SPEED_1000) + cmd->speed = SPEED_1000; + else if (status & VELOCITY_SPEED_100) cmd->speed = SPEED_100; else cmd->speed = SPEED_10; @@ -2896,7 +2905,7 @@ static u32 velocity_get_link(struct net_ { struct velocity_info *vptr = netdev_priv(dev); struct mac_regs __iomem * regs = vptr->mac_regs; - return BYTE_REG_BITS_IS_ON(PHYSR0_LINKGD, ®s->PHYSR0) ? 0 : 1; + return BYTE_REG_BITS_IS_ON(PHYSR0_LINKGD, ®s->PHYSR0) ? 1 : 0; } static void velocity_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info) diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig index fa9d2c4..2e8ac99 100644 --- a/drivers/net/wireless/Kconfig +++ b/drivers/net/wireless/Kconfig @@ -447,6 +447,7 @@ config AIRO_CS tristate "Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards" depends on NET_RADIO && PCMCIA && (BROKEN || !M32R) select CRYPTO + select CRYPTO_AES ---help--- This is the standard Linux driver to support Cisco/Aironet PCMCIA 802.11 wireless cards. This driver is the same as the Aironet diff --git a/drivers/net/wireless/bcm43xx/bcm43xx_main.c b/drivers/net/wireless/bcm43xx/bcm43xx_main.c index 3889f79..df317c1 100644 --- a/drivers/net/wireless/bcm43xx/bcm43xx_main.c +++ b/drivers/net/wireless/bcm43xx/bcm43xx_main.c @@ -3701,7
Re: [PATCH 3/3] forcdeth: NAPI support (rev3)
Previous patches in this series were applied to netdev-2.6.git#upstream. Can you resend this one + patch #4 as a single patch? Jeff - 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/3] forcedeth: coding style cleanups
applied patches 1-2 - 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] via-velocity: fix reported speed and link detected status
Francois Romieu wrote: Jay Cliburn <[EMAIL PROTECTED]> : The via-velocity driver reports incorrect speed and link detected status as viewed by ethtool (and probably other tools). This patch fixes those incorrect reports and prettifies a long line. Looks fine. Fixed the whitespace/tabs damage, the 190 cols comment and taged as 'upstream-20060720-00' in branch 'upstream' at git://electric-eye.fr.zoreil.com/home/romieu/linux-2.6.git pulled - 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]: Audit all ip6_dst_lookup/ip6_dst_store calls
On Fri, Jul 28, 2006 at 07:45:31PM +, Matt Domsch wrote: > Triggered on Fedora rawhide kernel-2.6.17-1.2462.fc6 x86_64 which is > based on 2.6.18rc2-git6. IPv6 was in use at the time. > > = > [ INFO: inconsistent lock state ] > - > inconsistent {softirq-on-W} -> {in-softirq-R} usage. > swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes: > (&sk->sk_dst_lock){---?}, at: [] > sk_dst_check+0x26/0x12b > {softirq-on-W} state was registered at: > [] lock_acquire+0x4a/0x69 > [] _write_lock+0x24/0x31 > [] ip4_datagram_connect+0x2e1/0x350 > [] inet_dgram_connect+0x57/0x65 > [] sys_connect+0x7d/0xa4 > [] system_call+0x7d/0x83 Thanks for the report. This is actually a false positive because by these two paths can't intersect since one is a UDP while the other is TCP. However, here is a patch which should shut up the validator as well as removing unnecessary locking from most callers of ip6_dst_lookup. [IPV6]: Audit all ip6_dst_lookup/ip6_dst_store calls The current users of ip6_dst_lookup can be divided into two classes: 1) The caller holds no locks and is in user-context (UDP). 2) The caller does not want to lookup the dst cache at all. The second class covers everyone except UDP because most people do the cache lookup directly before calling ip6_dst_lookup. This patch adds ip6_sk_dst_lookup for the first class. Similarly ip6_dst_store users can be divded into those that need to take the socket dst lock and those that don't. This patch adds __ip6_dst_store for those (everyone except UDP/datagram) that don't need an extra lock. Signed-off-by: Herbert Xu <[EMAIL PROTECTED]> Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- diff --git a/include/net/ip6_route.h b/include/net/ip6_route.h index ab29daf..96b0e66 100644 --- a/include/net/ip6_route.h +++ b/include/net/ip6_route.h @@ -139,16 +139,22 @@ extern rwlock_t rt6_lock; /* * Store a destination cache entry in a socket */ -static inline void ip6_dst_store(struct sock *sk, struct dst_entry *dst, -struct in6_addr *daddr) +static inline void __ip6_dst_store(struct sock *sk, struct dst_entry *dst, + struct in6_addr *daddr) { struct ipv6_pinfo *np = inet6_sk(sk); struct rt6_info *rt = (struct rt6_info *) dst; - write_lock(&sk->sk_dst_lock); sk_setup_caps(sk, dst); np->daddr_cache = daddr; np->dst_cookie = rt->rt6i_node ? rt->rt6i_node->fn_sernum : 0; +} + +static inline void ip6_dst_store(struct sock *sk, struct dst_entry *dst, +struct in6_addr *daddr) +{ + write_lock(&sk->sk_dst_lock); + __ip6_dst_store(sk, dst, daddr); write_unlock(&sk->sk_dst_lock); } diff --git a/include/net/ipv6.h b/include/net/ipv6.h index a8fdf79..ece7e8a 100644 --- a/include/net/ipv6.h +++ b/include/net/ipv6.h @@ -468,6 +468,9 @@ extern void ip6_flush_pending_frames(s extern int ip6_dst_lookup(struct sock *sk, struct dst_entry **dst, struct flowi *fl); +extern int ip6_sk_dst_lookup(struct sock *sk, + struct dst_entry **dst, + struct flowi *fl); /* * skb processing functions diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c index 9f3d4d7..610c722 100644 --- a/net/dccp/ipv6.c +++ b/net/dccp/ipv6.c @@ -230,7 +230,7 @@ static int dccp_v6_connect(struct sock * ipv6_addr_copy(&np->saddr, saddr); inet->rcv_saddr = LOOPBACK4_IPV6; - ip6_dst_store(sk, dst, NULL); + __ip6_dst_store(sk, dst, NULL); icsk->icsk_ext_hdr_len = 0; if (np->opt != NULL) @@ -863,7 +863,7 @@ static struct sock *dccp_v6_request_recv * comment in that function for the gory details. -acme */ - ip6_dst_store(newsk, dst, NULL); + __ip6_dst_store(newsk, dst, NULL); newsk->sk_route_caps = dst->dev->features & ~(NETIF_F_IP_CSUM | NETIF_F_TSO); newdp6 = (struct dccp6_sock *)newsk; diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c index 5a0ba58..ac85e9c 100644 --- a/net/ipv6/af_inet6.c +++ b/net/ipv6/af_inet6.c @@ -658,7 +658,7 @@ int inet6_sk_rebuild_header(struct sock return err; } - ip6_dst_store(sk, dst, NULL); + __ip6_dst_store(sk, dst, NULL); } return 0; diff --git a/net/ipv6/inet6_connection_sock.c b/net/ipv6/inet6_connection_sock.c index 5c950cc..bf49107 100644 --- a/net/ipv6/inet6_connection_sock.c +++ b/net/ipv6/inet6_connection_
Re: Please pull 'upstream' branch of wireless-2.6
pulled - 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] mark sk98lin driver for removal
ACK, however [EMAIL PROTECTED] netdev-2.6]$ git-applymbox /g/tmp/mbox ~/info/signoff.txt 1 patch(es) to process. Applying 'mark sk98lin driver for removal' error: patch failed: Documentation/feature-removal-schedule.txt:258 error: Documentation/feature-removal-schedule.txt: patch does not apply - 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 1/4] kevent: core files.
On Fri, 2006-07-28 at 20:38 -0700, Ulrich Drepper wrote: > Zach Brown wrote: > > Ulrich, would you be satisfied if we didn't > > have the userspace mapped ring on the first pass and only had a > > collection syscall? > > I'm not the one to make a call but why rush things? Let's do it right > from the start. Later changes can only lead to problems with users of > the earlier interface. > Speaking of API design choices, I saw your OLS paper and was wondering if you were familiar with the Solaris port APIs* and, if so, you could please comment on how your proposed event channels are different/better. * http://docs.sun.com/app/docs/doc/816-5168/6mbb3hrir?a=view -- Nicholas Miell <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please pull 'upstream-fixes' branch of wireless-2.6
pulled - 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] Multiple IPV6 Routing Tables & Policy Routing
In article <[EMAIL PROTECTED]> (at Fri, 28 Jul 2006 12:32:29 +0200), Thomas Graf <[EMAIL PROTECTED]> says: > * YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-07-28 15:10 > > Well, as you stated, the code is based on the work of MIPL, > > which is being jointly developed by Helsinki University of Technology (HUT) > > and USAGI/WIDE Project. Please describe this on your commit logs. > > Please retain copyright information as well. > > Please tell me which copyright I missed? Please put these lines in net/ipv6/fib6_rules.c (and maybe, its derived files): Copyright (C)2003-2006 Helsinki University of Technology Copyright (C)2003-2006 USAGI/WIDE Project You can add your own copyright notice if you want, of course. Thank you. --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 2/5] [IPV6]: Multiple Routing Tables
In article <[EMAIL PROTECTED]> (at Fri, 28 Jul 2006 21:14:28 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > For now I would suggest we use Thomas's approach, and we > can make performance measurements to determine if it makes > to optimize this or consider other methods. Okay. --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 2/5] [IPV6]: Multiple Routing Tables
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Sat, 29 Jul 2006 13:13:06 +0900 (JST) > Previously, we directly use address, ifindex etc., not flowi, > in IPv6 routing code except for ip6_route_output(). > This patch changes them to use flowi. > I know this should work and it is a good way for abstraction. > However, initializing flowi for IPv6 is more expensive than > one for IPv4, and it would result in poor performance (especially > without CONFIG_IPV6_MULTIPLE_TABLES). > > Am I too cautious? > Should we eat this? I think it is a legitimate consideration. For now I would suggest we use Thomas's approach, and we can make performance measurements to determine if it makes to optimize this or consider other methods. - 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/3] forcedeth: fix NAPI hang in IRQ.
On Thu, 27 Jul 2006 19:01:14 -0700 Stephen Hemminger <[EMAIL PROTECTED]> wrote: > Fix for NAPI hanging in interrupt. With NAPI, we only need one > iteration over the IRQ. > > Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]> > > --- linux-2.6.orig/drivers/net/forcedeth.c2006-07-27 > 18:58:21.0 -0700 +++ linux-2.6/drivers/net/forcedeth.c > 2006-07-27 18:57:31.0 -0700 @@ -2422,10 +2422,11 @@ > dev->name, events); > } > #ifdef CONFIG_FORCEDETH_NAPI > - if (netif_rx_schedule_prep(dev)) { > - __netif_rx_schedule(dev); > + if (events & NVREG_IRQ_RX_ALL) { > + netif_rx_schedule(dev); > nv_disable_hw_interrupts(dev, > NVREG_IRQ_RX_ALL); } > + return IRQ_HANDLED; > #else > nv_rx_process(dev, dev->weight); > if (nv_alloc_rx(dev)) { > @@ -2434,7 +2435,6 @@ > mod_timer(&np->oom_kick, jiffies + > OOM_REFILL); spin_unlock(&np->lock); > } > -#endif > if (i > max_interrupt_work) { > spin_lock(&np->lock); > /* disable interrupts on the nic */ > @@ -2452,7 +2452,7 @@ > spin_unlock(&np->lock); > break; > } > - > +#endif > } > dprintk(KERN_DEBUG "%s: nv_nic_irq completed\n", dev->name); > What on earth happened to that? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] [IPV6]: Multiple Routing Tables
Hello. In article <[EMAIL PROTECTED]> (at Thu, 27 Jul 2006 00:00:02 +0200), Thomas Graf <[EMAIL PROTECTED]> says: > Adds the framework to support multiple IPv6 routing tables. Well, one design consideration that I have had for several months is performance impact. Previously, we directly use address, ifindex etc., not flowi, in IPv6 routing code except for ip6_route_output(). This patch changes them to use flowi. I know this should work and it is a good way for abstraction. However, initializing flowi for IPv6 is more expensive than one for IPv4, and it would result in poor performance (especially without CONFIG_IPV6_MULTIPLE_TABLES). Am I too cautious? Should we eat this? --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: [RFC 1/4] kevent: core files.
Zach Brown wrote: > Ulrich, would you be satisfied if we didn't > have the userspace mapped ring on the first pass and only had a > collection syscall? I'm not the one to make a call but why rush things? Let's do it right from the start. Later changes can only lead to problems with users of the earlier interface. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ signature.asc Description: OpenPGP digital signature
Re: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, Jul 28, 2006 at 05:24:40PM -0700, Greg KH wrote: > On Fri, Jul 28, 2006 at 05:04:49PM -0700, Brandeburg, Jesse wrote: > > The kernel driver advertises through our probe table and in our readme > > that we support this device (code is in e1000_main.c) but we don't load on > > it correctly due to an error when we submitted the patches (e1000_hw.c/h). > > > > Patch is very simple and low risk, but it is your call. > > Sorry, but for now, no. Users should be able to use the sysfs bind and > new_id interface to add new device support for your driver, if it's > written properly :) In this case it isn't an addition to the PCI ID table, but an actual added check in the code. You could make the argument that it is a bug since the PCI ID table says the device is supported, but it won't work w/o this additional check. Of course, the "if it's written properly" comment is still valid... :-) John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework
Martin Josefsson wrote: > As a somewhat related note, I've just digged a bit through RCU land, > talked to dipankar and mckenney, and discovered that rcu_read_lock() / > rcu_read_unlock() aren't strictly needed in softirqs since preempt is > already disabled in softirqs. This means that you can use the result of > the rcu read-side critical outside of the rcu_read_lock() / Thats true, but in this case the code is executed both in softirq- and user-context. Using rcu_read_lock and still relying on softirq properties outside the locked section is also very confusing in my opinion. - 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][SECURITY] secmark: nul-terminate secdata
James Morris wrote: > The patch below fixes a problem in the iptables SECMARK target, where the > user-supplied 'selctx' string may not be nul-terminated. > >>From initial analysis, it seems that the strlen() called from > selinux_string_to_sid() could run until it arbitrarily finds a zero, and > possibly cause a kernel oops before then. > > The impact of this appears limited because the operation requires > CAP_NET_ADMIN, which is essentially always root. Also, the module is not > yet in wide use. > > Please apply. > > Note: some other iptables modules which handle strings supplied from > userspace may require a similar fix (e.g. xt_string looks suspect at first > glance). I'll look into these, but it won't be the last of these problems. At the last netfilter workshop Rusty spent some time figuring out "how many iptables crashes (triggered by root) can I find in a few minutes", and it was quite a lot. So far we've hoped for pkttables to make everything better, but it looks like things like OpenVZ will beat us. - 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: SMSC LAN911x and LAN921x vendor driver
Could the tasklet be replaced by using NAPI (dev->poll) routine? - 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: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, Jul 28, 2006 at 05:04:49PM -0700, Brandeburg, Jesse wrote: > On Fri, 28 Jul 2006, Greg KH wrote: > > On Fri, Jul 28, 2006 at 03:06:17PM -0700, Auke Kok wrote: > > > > > > The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and > > > onward. Add the device ID so this card works with 2.6.17.y onward. This > > > device ID was accidentally omitted. > > > > Sorry, but we don't add new device support in the -stable kernel tree, > > it's "bugfixes only." > > In this case I believe it to be a bug in our code, instead of adding new > support. The driver code supports other device IDs for this same chip. Heh, that would be a slipery slope, as everyone who adds device ids feels that it is a "bug" that the driver does not support their device. If we were to allow this, there would be a _lot_ more -stable patches, which I don't think is a good thing to have. > The kernel driver advertises through our probe table and in our readme > that we support this device (code is in e1000_main.c) but we don't load on > it correctly due to an error when we submitted the patches (e1000_hw.c/h). > > Patch is very simple and low risk, but it is your call. Sorry, but for now, no. Users should be able to use the sysfs bind and new_id interface to add new device support for your driver, if it's written properly :) thanks, greg k-h - 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: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, 28 Jul 2006, Greg KH wrote: > On Fri, Jul 28, 2006 at 03:06:17PM -0700, Auke Kok wrote: > > > > The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and > > onward. Add the device ID so this card works with 2.6.17.y onward. This > > device ID was accidentally omitted. > > Sorry, but we don't add new device support in the -stable kernel tree, > it's "bugfixes only." In this case I believe it to be a bug in our code, instead of adding new support. The driver code supports other device IDs for this same chip. The kernel driver advertises through our probe table and in our readme that we support this device (code is in e1000_main.c) but we don't load on it correctly due to an error when we submitted the patches (e1000_hw.c/h). Patch is very simple and low risk, but it is your call. Thanks, Jesse - 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: [stable] [PATCH] e1000: add forgotten PCI ID for supported device
On Fri, Jul 28, 2006 at 03:06:17PM -0700, Auke Kok wrote: > > The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and > onward. Add the device ID so this card works with 2.6.17.y onward. This > device ID was accidentally omitted. Sorry, but we don't add new device support in the -stable kernel tree, it's "bugfixes only." thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
David Miller wrote: From: Christophe Devriese <[EMAIL PROTECTED]> Date: Sat, 29 Jul 2006 00:58:59 +0200 On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote: Christophe Devriese wrote: On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: Christophe Devriese wrote: I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. The patch looks sane this time. The skb_bond method assigns skb->dev when it does the 'keep', but the VLAN code immediately over-writes the skb->dev when searching for the vlan device. What is the purpose of assinging skb->dev to the master device? I don't know. The method was only moved by this patch, not changed. The contents of the method are exactly what they are in linux-2.6.17.7/net/core/dev.c I assume it has something to do with the other bonding methods. Ok, I don't know much about the bonding logic. Looks OK to me. Will you sign-off on it then ? Or how do I get this applied ? I'll apply this over the weekend unless I spot some problem with it, thanks. A sign off from Ben would be nice too :) I don't see any problems with the patch. The skb->dev assignment is redundant for the VLAN path, but may be useful elsewhere. At any rate, it doesn't seem like it would hurt anything. Signed-off-by Ben Greear <[EMAIL PROTECTED]> -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: PATCH Fix bonding active-backup behavior for VLAN interfaces
From: Christophe Devriese <[EMAIL PROTECTED]> Date: Sat, 29 Jul 2006 00:58:59 +0200 > On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote: > > Christophe Devriese wrote: > > >On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: > > > > > >>Christophe Devriese wrote: > > >> > > >>>I basically move the skb_bond method into if_bonding.h, include that file > > >>>in if_vlan ( and call it from the vlan forwarding path, and the netif_rx > > >>>routine ). > > >>> > > >>>Somehow this patch is very incomplete. Let me try again. > > >> > > >>The patch looks sane this time. > > >> > > >>The skb_bond method assigns skb->dev when it does the 'keep', > > >>but the VLAN code immediately over-writes the skb->dev when > > >>searching for the vlan device. > > >> > > >>What is the purpose of assinging skb->dev to the master device? > > > > > > > > >I don't know. The method was only moved by this patch, not changed. The > > >contents of the method are exactly what they are in > > >linux-2.6.17.7/net/core/dev.c > > > > > >I assume it has something to do with the other bonding methods. > > > > Ok, I don't know much about the bonding logic. Looks OK to me. > > Will you sign-off on it then ? Or how do I get this applied ? I'll apply this over the weekend unless I spot some problem with it, thanks. A sign off from Ben would be nice too :) - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Fri, Jul 28, 2006 at 03:08:49PM -0700, Ben Greear wrote: > Christophe Devriese wrote: > >On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: > > > >>Christophe Devriese wrote: > >> > >>>I basically move the skb_bond method into if_bonding.h, include that file > >>>in if_vlan ( and call it from the vlan forwarding path, and the netif_rx > >>>routine ). > >>> > >>>Somehow this patch is very incomplete. Let me try again. > >> > >>The patch looks sane this time. > >> > >>The skb_bond method assigns skb->dev when it does the 'keep', > >>but the VLAN code immediately over-writes the skb->dev when > >>searching for the vlan device. > >> > >>What is the purpose of assinging skb->dev to the master device? > > > > > >I don't know. The method was only moved by this patch, not changed. The > >contents of the method are exactly what they are in > >linux-2.6.17.7/net/core/dev.c > > > >I assume it has something to do with the other bonding methods. > > Ok, I don't know much about the bonding logic. Looks OK to me. Will you sign-off on it then ? Or how do I get this applied ? -- --- Christophe Devriese EURiD Network Adminstrator / Developer [EMAIL PROTECTED] http://www.eth1.org -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] e1000: add forgotten PCI ID for supported device
The Intel(R) PRO/1000 82572EI card is fully supported by 7.0.33-k2 and onward. Add the device ID so this card works with 2.6.17.y onward. This device ID was accidentally omitted. Signed-off-by: Auke Kok <[EMAIL PROTECTED]> diff --git a/drivers/net/e1000/e1000_hw.c b/drivers/net/e1000/e1000_hw.c index 523c2c9..c5e7023 100644 --- a/drivers/net/e1000/e1000_hw.c +++ b/drivers/net/e1000/e1000_hw.c @@ -353,6 +353,7 @@ e1000_set_mac_type(struct e1000_hw *hw) case E1000_DEV_ID_82572EI_COPPER: case E1000_DEV_ID_82572EI_FIBER: case E1000_DEV_ID_82572EI_SERDES: +case E1000_DEV_ID_82572EI: hw->mac_type = e1000_82572; break; case E1000_DEV_ID_82573E: diff --git a/drivers/net/e1000/e1000_hw.h b/drivers/net/e1000/e1000_hw.h index 150e45e..c01e5d2 100644 --- a/drivers/net/e1000/e1000_hw.h +++ b/drivers/net/e1000/e1000_hw.h @@ -462,6 +462,7 @@ #define E1000_DEV_ID_82571EB_SERDES #define E1000_DEV_ID_82572EI_COPPER 0x107D #define E1000_DEV_ID_82572EI_FIBER 0x107E #define E1000_DEV_ID_82572EI_SERDES 0x107F +#define E1000_DEV_ID_82572EI 0x10B9 #define E1000_DEV_ID_82573E 0x108B #define E1000_DEV_ID_82573E_IAMT 0x108C #define E1000_DEV_ID_82573L 0x109A
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
On Fri, Jul 28, 2006 at 02:55:17PM -0700, Ben Greear wrote: > Christophe Devriese wrote: > >I basically move the skb_bond method into if_bonding.h, include that file > >in if_vlan ( and call it from the vlan forwarding path, and the netif_rx > >routine ). > > > >Somehow this patch is very incomplete. Let me try again. > > The patch looks sane this time. > > The skb_bond method assigns skb->dev when it does the 'keep', > but the VLAN code immediately over-writes the skb->dev when > searching for the vlan device. > > What is the purpose of assinging skb->dev to the master device? I don't know. The method was only moved by this patch, not changed. The contents of the method are exactly what they are in linux-2.6.17.7/net/core/dev.c I assume it has something to do with the other bonding methods. -- --- Christophe Devriese EURiD Network Adminstrator / Developer [EMAIL PROTECTED] http://www.eth1.org -- - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
Christophe Devriese wrote: I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. The patch looks sane this time. The skb_bond method assigns skb->dev when it does the 'keep', but the VLAN code immediately over-writes the skb->dev when searching for the vlan device. What is the purpose of assinging skb->dev to the master device? Ben -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: SMSC LAN911x and LAN921x vendor driver
[...] > diff --git a/drivers/net/smsc911x.c b/drivers/net/smsc911x.c > new file mode 100644 > index 000..12bbe67 > --- /dev/null > +++ b/drivers/net/smsc911x.c [...] > +/* Tasklet declarations */ > +static unsigned long rx_tasklet_parameter; > +static void smsc911x_rx_tasklet(unsigned long data); > + > +DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 0); > +MODULE_LICENSE("GPL"); > + > +/* MAC */ [lots of forward declarations] Despite Jeff claiming otherwise, I see no added value in forward declarations. It adds bloat, it pollutes ctags and it is inferior to real kernel docbook documentation. [...] > +/* Linux network device interface */ > +static int smsc911x_open(struct net_device *dev); > +static int smsc911x_stop(struct net_device *dev); > +static int smsc911x_hard_start_xmit(struct sk_buff *skb, > + struct net_device *dev); > + > +static struct net_device_stats *smsc911x_get_stats(struct net_device *dev); > +static void smsc911x_set_multicast_list(struct net_device *dev); > +static irqreturn_t smsc911x_irqhandler(int irq, void *dev_id, > +struct pt_regs *regs); > + > +/* Module interface */ > +static int smsc911x_init_module(void); > +static void smsc911x_cleanup_module(void); > + > +/* Driver interface */ > +static int smsc911x_drv_probe(struct platform_device *pdev); > +static int smsc911x_drv_remove(struct platform_device *pdev); These one are completely useless. > +/* Entry point for starting/opening the interface */ > +static int smsc911x_open(struct net_device *dev) > +{ > + struct smsc911x_data *pdata; > + unsigned int mac_high16; > + unsigned int mac_low32; > + unsigned int timeout; > + unsigned int intcfg; > + int result; > + > + /* Set interrupt deassertion to 220uS */ > + intcfg = 22 << 24; > + timeout = 1000; > + result = -ENODEV; > + > + pdata = netdev_priv(dev); It is quite common to set pdata on flight, i.e.: struct smsc911x_data *pdata = netdev_priv(dev); Same thing for 'result'. > + > + /* Initialise smsc911x */ > + > + /* > + * dwIntCfg|=INT_CFG_IRQ_POL_; use this to set IRQ_POL bit > + * dwIntCfg|=INT_CFG_IRQ_TYPE_; use this to set IRQ_TYPE bit > + */ > + if (!smsc911x_lan_initialise(pdata, intcfg)) > + goto done; > + > + SMSC_TRACE("Testing irq handler using IRQ %d", dev->irq); > + pdata->request_irq_disable = 0; > + pdata->software_irq_signal = 0; > + smsc911x_reg_write((smsc911x_reg_read(pdata, INT_EN) | > + INT_EN_SW_INT_EN_), pdata, INT_EN); > + do { > + udelay(10); > + timeout--; > + } while (timeout && (!pdata->software_irq_signal)); > + > + if (!pdata->software_irq_signal) { > + printk("<1>ISR failed signaling test."); Should be printk(KERN_XYZ, ... It would be nice to display the device name too. > + result = -ENODEV; > + goto done; > + } > + SMSC_TRACE("IRQ handler passed test using IRQ %d", dev->irq); > + > + printk("%s: SMSC911x/921x identified at %#08x, IRQ: %d\n", dev->name, > +pdata->base, dev->irq); printk(KERN_XYZ, ... [...] > +static int smsc911x_stop(struct net_device *dev) > +{ > + unsigned long flags; > + unsigned long base; > + unsigned long idrev; > + struct smsc911x_data *pdata; > + struct net_device *pnetdev; > + > + pdata = netdev_priv(dev); > + > + pdata->stop_link_poll = 1; > + del_timer_sync(&pdata->link_poll_timer); > + > + spin_lock_irqsave(&dev->_xmit_lock, flags); If this is supposed to protect against hard_start_xmit, it is not needed. > + smsc911x_reg_write((smsc911x_reg_read(pdata, INT_CFG) & > + (~INT_CFG_IRQ_EN_)), pdata, INT_CFG); > + netif_stop_queue(pdata->dev); Any reason why 'pdata->dev' would be different from 'dev' ? pnetdev seems redundant with dev. > + spin_unlock_irqrestore(&dev->_xmit_lock, flags); > + > + /* At this point all Rx and Tx activity is stopped */ > + pdata->stats.rx_dropped += smsc911x_reg_read(pdata, RX_DROP); > + smsc911x_tx_update_txcounters(pdata); > + > + /* Preserve important fields */ > + base = pdata->base; > + idrev = pdata->idrev; > + pnetdev = pdata->dev; > + > + /* Clear all structure */ > + memset((void *)pdata, 0, sizeof(struct smsc911x_data)); Useless conversion to void * > +static int smsc911x_hard_start_xmit(struct sk_buff *skb, struct net_device > *dev) > +{ [...] > + return 0; s/0/NETDEV_TX_OK/ [...] > +/* Entry point for setting addressing modes */ > +static void smsc911x_set_multicast_list(struct net_device *dev) > +{ > + struct smsc911x_data *pdata; > + unsigned long flags; > + > + pdata = netdev_priv(dev); > + > + spin_lock_irqsave(&pdata->phy_lock, flags); > + > + if (dev->flags & IFF_PROMISC) { > + /* Enabling promiscuous mode */ > +
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
I basically move the skb_bond method into if_bonding.h, include that file in if_vlan ( and call it from the vlan forwarding path, and the netif_rx routine ). Somehow this patch is very incomplete. Let me try again. sorry for the trouble. (I'm new at this) Regards, Christophe > Christophe Devriese wrote: > >diff -rU3 linux-2.6.17.7/net/core/dev.c > >linux-2.6.17.7-wapper/net/core/dev.c > >--- linux-2.6.17.7/net/core/dev.c 2006-07-25 05:36:01.0 +0200 > >+++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 > >20:16:36.0 +0200 > >@@ -88,6 +88,7 @@ > > #include > > #include > > #include > >+#include > > #include > > #include > > #include > >@@ -1518,37 +1519,6 @@ > > > > EXPORT_SYMBOL(netif_rx_ni); > > > >-static inline struct net_device *skb_bond(struct sk_buff *skb) > >-{ > >- struct net_device *dev = skb->dev; > >- > >- if (dev->master) { > >- /* > >-* On bonding slaves other than the currently active > >-* slave, suppress duplicates except for 802.3ad > >-* ETH_P_SLOW and alb non-mcast/bcast. > >-*/ > >- if (dev->priv_flags & IFF_SLAVE_INACTIVE) { > >- if (dev->master->priv_flags & IFF_MASTER_ALB) { > >- if (skb->pkt_type != PACKET_BROADCAST && > >- skb->pkt_type != PACKET_MULTICAST) > >- goto keep; > >- } > >- > >- if (dev->master->priv_flags & IFF_MASTER_8023AD && > >- skb->protocol == __constant_htons(ETH_P_SLOW)) > >- goto keep; > >- > >- kfree_skb(skb); > >- return NULL; > >- } > >-keep: > >- skb->dev = dev->master; > >- } > >- > >- return dev; > >-} > >- > > static void net_tx_action(struct softirq_action *h) > > { > >struct softnet_data *sd = &__get_cpu_var(softnet_data); > > > > > -- > Ben Greear <[EMAIL PROTECTED]> > Candela Technologies Inc http://www.candelatech.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 -- --- Christophe Devriese EURiD Network Adminstrator / Developer [EMAIL PROTECTED] http://www.eth1.org -- diff -rU3 linux-2.6.17.7/include/linux/if_bonding.h linux-2.6.17.7-wapper/include/linux/if_bonding.h --- linux-2.6.17.7/include/linux/if_bonding.h 2006-07-25 05:36:01.0 +0200 +++ linux-2.6.17.7-wapper/include/linux/if_bonding.h2006-07-27 21:17:25.0 +0200 @@ -46,6 +46,7 @@ #include #include #include +#include /* userland - kernel ABI version (2003/05/08) */ #define BOND_ABI_VERSION 2 @@ -110,6 +111,37 @@ __u8 partner_system[ETH_ALEN]; }; +static inline struct net_device *skb_bond(struct sk_buff *skb) +{ + struct net_device *dev = skb->dev; + + if (dev->master) { + /* +* On bonding slaves other than the currently active +* slave, suppress duplicates except for 802.3ad +* ETH_P_SLOW and alb non-mcast/bcast. +*/ + if (dev->priv_flags & IFF_SLAVE_INACTIVE) { + if (dev->master->priv_flags & IFF_MASTER_ALB) { + if (skb->pkt_type != PACKET_BROADCAST && + skb->pkt_type != PACKET_MULTICAST) + goto keep; + } + + if (dev->master->priv_flags & IFF_MASTER_8023AD && + skb->protocol == __constant_htons(ETH_P_SLOW)) + goto keep; + + kfree_skb(skb); + return NULL; + } +keep: + skb->dev = dev->master; + } + + return dev; +} + #endif /* _LINUX_IF_BONDING_H */ /* diff -rU3 linux-2.6.17.7/include/linux/if_vlan.h linux-2.6.17.7-wapper/include/linux/if_vlan.h --- linux-2.6.17.7/include/linux/if_vlan.h 2006-07-25 05:36:01.0 +0200 +++ linux-2.6.17.7-wapper/include/linux/if_vlan.h 2006-07-27 20:16:36.0 +0200 @@ -24,6 +24,7 @@ struct hlist_node; #include /* for proc_dir_entry */ +#include /* for skb_bond */ #include #define VLAN_HLEN 4 /* The additional bytes (on top of the Ethernet header) @@ -154,6 +155,12 @@ unsigned short vlan_tag, int polling) { struct net_device_stats *stats; + struct net_device *orig_dev; + + orig_dev = skb_bond(skb); + + if (!orig_d
Re: [PATCH 2/7] NetLabel: core network changes
David Miller wrote: > From: Paul Moore <[EMAIL PROTECTED]> > Date: Fri, 28 Jul 2006 16:09:15 -0400 > >>Okay. I stated earlier today that I would push a new patchset out to >>the list this weekend or perhaps today, but in light of this I think >>I'll wait until I have had a chance to make this change which should be >>sometime next week. > > Thanks a lot Paul. > > I think once we flesh all of this out we can queue your code > into my net-2.6.19 tree. > > Thanks again. No problem, thanks for being open to some more of that "Commercial Security crap" :) -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][SECURITY] secmark: nul-terminate secdata
The patch below fixes a problem in the iptables SECMARK target, where the user-supplied 'selctx' string may not be nul-terminated. >From initial analysis, it seems that the strlen() called from selinux_string_to_sid() could run until it arbitrarily finds a zero, and possibly cause a kernel oops before then. The impact of this appears limited because the operation requires CAP_NET_ADMIN, which is essentially always root. Also, the module is not yet in wide use. Please apply. Note: some other iptables modules which handle strings supplied from userspace may require a similar fix (e.g. xt_string looks suspect at first glance). cc'd Chris Wright, as this patch seems like a candidate for the stable tree. Signed-off-by: James Morris <[EMAIL PROTECTED]> Signed-off-by: Stephen Smalley <[EMAIL PROTECTED]> --- diff -purN -X dontdiff linux-2.6.18-rc2-mm1.o/net/netfilter/xt_SECMARK.c linux-2.6.18-rc2-mm1.w/net/netfilter/xt_SECMARK.c --- linux-2.6.18-rc2-mm1.o/net/netfilter/xt_SECMARK.c 2006-07-28 11:01:46.0 -0400 +++ linux-2.6.18-rc2-mm1.w/net/netfilter/xt_SECMARK.c 2006-07-28 11:15:44.0 -0400 @@ -57,6 +57,8 @@ static int checkentry_selinux(struct xt_ { int err; struct xt_secmark_target_selinux_info *sel = &info->u.sel; + + sel->selctx[SECMARK_SELCTX_MAX - 1] = '\0'; err = selinux_string_to_sid(sel->selctx, &sel->selsid); if (err) { - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] NetLabel: core network changes
From: Paul Moore <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 16:09:15 -0400 > Okay. I stated earlier today that I would push a new patchset out to > the list this weekend or perhaps today, but in light of this I think > I'll wait until I have had a chance to make this change which should be > sometime next week. Thanks a lot Paul. I think once we flesh all of this out we can queue your code into my net-2.6.19 tree. Thanks again. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
* Francois Romieu <[EMAIL PROTECTED]> [2006-07-28 21:49]: > The (untested) patch below should apply to the source code that Realtek > included in linux-r1000(103).zip, wherence supporting the extraction > of the same info. Note quite. I also had to add the patch below but now it's working: Offset Value - 00 0x00 01 0x14 02 0xfd 03 0x10 04 0x27 05 0x74 06 0x00 07 0x00 08 0x00 09 0x00 10 0x00 11 0x80 12 0x00 13 0x00 14 0x00 15 0x00 16 0xc0 17 0xfe 18 0xbb 19 0xdf 20 0x7b 21 0xb6 22 0x74 23 0xff 24 0x00 25 0x00 26 0x00 27 0x00 28 0x00 29 0x00 30 0x00 31 0x00 32 0x00 33 0x80 34 0x20 35 0x07 36 0x00 37 0x00 38 0x00 39 0x00 40 0x00 41 0x3f 42 0xfc 43 0xff 44 0xac 45 0xf7 46 0xf7 47 0xfe 48 0x00 49 0x00 50 0x00 51 0x00 52 0x00 53 0x00 54 0x08 55 0x0c 56 0x00 57 0x00 58 0x00 59 0x00 60 0x7f 61 0x00 62 0x00 63 0x00 64 0x00 65 0x07 66 0x00 67 0x13 68 0x0e 69 0xe7 70 0x00 71 0x00 72 0x24 73 0x57 74 0xaf 75 0x31 76 0x00 77 0x00 78 0x00 79 0x00 80 0x00 81 0x04 82 0x1f 83 0x10 84 0x20 85 0x80 86 0x03 87 0x00 88 0x00 89 0x00 90 0x00 91 0x00 92 0x00 93 0x00 94 0x10 95 0x00 96 0x6d 97 0x79 98 0x01 99 0x80 100 0x00 101 0x00 102 0x00 103 0x00 104 0x00 105 0x00 106 0x00 107 0x00 108 0x6b 109 0x00 110 0x00 111 0x00 112 0xff 113 0xfd 114 0xfb 115 0xff 116 0xfc 117 0x03 118 0x00 119 0x00 120 0x00 121 0xff 122 0xff 123 0xff 124 0x00 125 0x00 126 0x00 127 0x00 128 0x00 129 0x00 130 0x00 131 0x00 132 0x7f 133 0xef 134 0xfe 135 0xfc 136 0x9f 137 0xfe 138 0xff 139 0xdf 140 0x3f 141 0xcf 142 0xf7 143 0xab 144 0xbf 145 0xdb 146 0xfb 147 0xff 148 0xdf 149 0xff 150 0xfa 151 0xdf 152 0xfd 153 0xbf 154 0xbf 155 0xbf 156 0xfc 157 0xbe 158 0x75 159 0xaa 160 0xf9 161 0xea 162 0x5f 163 0xcb 164 0xdf 165 0x6f 166 0xdf 167 0xfb 168 0xb7 169 0x75 170 0x7e 171 0xff 172 0xfd 173 0xfb 174 0xdf 175 0xbb 176 0xff 177 0xff 178 0x7c 179 0xff 180 0x9f 181 0xde 182 0x3b 183 0x7f 184 0x7f 185 0xfa 186 0xbf 187 0xbb 188 0xcd 189 0xfd 190 0x9f 191 0xae 192 0xff 193 0xbb 194 0xc8 195 0x36 196 0xef 197 0xda 198 0xff 199 0xff 200 0xff 201 0xae 202 0xfe 203 0x6a 204 0x2f 205 0xdc 206 0x00 207 0x00 208 0x00 209 0x00 210 0x00 211 0x00 212 0x00 213 0x00 214 0x00 215 0x00 216 0x00 217 0x00 218 0xf2 219 0x05 220 0x00 221 0x00 222 0x00 223 0x00 224 0x08 225 0x20 226 0x00 227 0x00 228 0x00 229 0x00 230 0x79 231 0x07 232 0x00 233 0x00 234 0x00 235 0x00 236 0x3f 237 0x00 238 0x00 239 0x00 240 0x00 241 0x80 242 0x00 243 0x00 244 0x00 245 0x00 246 0x00 247 0x00 248 0x02 249 0x00 250 0x00 251 0x00 252 0x00 253 0x00 254 0x00 255 0x00 --- r1000_ioctl.c~ 2006-07-28 20:32:58.027267250 + +++ r1000_ioctl.c 2006-07-28 20:33:18.600553000 + @@ -6,6 +6,16 @@ #define R1000_REGS_SIZE 256 +static void r1000_get_drvinfo(struct net_device *dev, + struct ethtool_drvinfo *info) +{ + struct r1000_private *priv = netdev_priv(dev); + + strcpy(info->driver, MODULENAME); + strcpy(info->version, R1000_VERSION); + strcpy(info->bus_info, pci_name(priv->pci_dev)); +} + static int r1000_get_regs_len(struct net_device *dev) { return R1000_REGS_SIZE; @@ -157,6 +167,7 @@ #if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,0) struct ethtool_ops r1000_ethtool_ops = { + .get_drvinfo= r1000_get_drvinfo, .get_regs_len = r1000_get_regs_len, .get_regs = r1000_get_regs, .get_settings = ethtool_get_settings, -- 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: [PATCH 2/7] NetLabel: core network changes
David Miller wrote: > From: Paul Moore <[EMAIL PROTECTED]> > Date: Fri, 28 Jul 2006 15:08:44 -0400 > >>Thanks for your feedback but unless I hear from others that this >>is a requirement I think I'm going to leave the code as written for the >>reasons I listed above. > > Please switch over to the scheme which Thomas has suggested. > Okay. I stated earlier today that I would push a new patchset out to the list this weekend or perhaps today, but in light of this I think I'll wait until I have had a chance to make this change which should be sometime next week. -- paul moore linux security @ hp - 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/7] NetLabel: core network changes
From: Paul Moore <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 15:08:44 -0400 > Thanks for your feedback but unless I hear from others that this > is a requirement I think I'm going to leave the code as written for the > reasons I listed above. Please switch over to the scheme which Thomas has suggested. There are real solid reasons for doing this, even if you think your API is complete today and won't run into some of the issues he mentioned. - 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/7] NetLabel: core network changes
From: Paul Moore <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 14:45:53 -0400 > I'm happy to drop this hook as it *looks* like the MLSXFRM patchset is > going to make it which has some of the accept hooks I was hoping to get, > but figured I stood a "snowballs chance in hell" trying to get it in > solely for use with CIPSO :) I'll drop this on the next release of the > NetLabel patchset and assuming both the NetLabel and the MLSXFRM > patchset make it into the 2.6.19 release I'll issue another small > patchset then to integrate into the new LSM hooks for accept. I'd do it > now but I think it would cause too much of a mess with patch > dependencies/collisions/etc. The MLSXFRM stuff is already queued up in my 2.6.19 tree at: master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6.19.git so you can make your work relative to that if you wish. - 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: tg3 module problem with suspend2
I have this problem since I first tried to use suspend. The first kernel I tried was 2.6.13 I guess. Since that time I reload the driver, then I do not know if it works with kernel 2.6.14, 2.6.15 or 2.6.16 without reloading. - Lamarque V. Souza http://www.geographicguide.com/brazil.htm Linux User #57137 - http://counter.li.org/ From: "Michael Chan" <[EMAIL PROTECTED]> To: "Lamarque Souza" <[EMAIL PROTECTED]>,netdev@vger.kernel.org CC: [EMAIL PROTECTED] Subject: Re: tg3 module problem with suspend2 Date: Thu, 27 Jul 2006 20:37:32 -0700 Lamarque Souza wrote: > > Do you have any idea why that happens? > Not yet. Did it use to work with an older tg3 driver or kernel? - 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: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
Martin Michlmayr <[EMAIL PROTECTED]> : [...] > Here's the output using the r8169 driver: > > RealTek RTL-8110 registers: > -- The (untested) patch below should apply to the source code that Realtek included in linux-r1000(103).zip, wherence supporting the extraction of the same info. --- r1000/src/r1000_ioctl.c 2006-07-28 21:35:25.0 +0200 +++ r1000/src/r1000_ioctl.c 2006-07-28 21:38:17.0 +0200 @@ -4,6 +4,27 @@ extern int R1000_READ_GMII_REG(unsigned extern int R1000_WRITE_GMII_REG(unsigned long ioaddr, int RegAddr, int value); extern int r1000_set_speed_duplex(unsigned long ioaddr, unsigned long anar, unsigned long gbcr, unsigned long bmcr); +#define R1000_REGS_SIZE 256 + +static int r1000_get_regs_len(struct net_device *dev) +{ + return R1000_REGS_SIZE; +} + +static void r1000_get_regs(struct net_device *dev, struct ethtool_regs *regs, + void *p) +{ + struct r1000_private *priv = netdev_priv(dev); + unsigned long flags; + + if (regs->len > R1000_REGS_SIZE) + regs->len = R1000_REGS_SIZE; + + spin_lock_irqsave(&priv->lock, flags); + memcpy_fromio(p, (void __iomem *)priv->ioaddr, regs->len); + spin_unlock_irqrestore(&priv->lock, flags); +} + static int ethtool_get_settings(struct net_device *netdev,struct ethtool_cmd *ecmd){ struct r1000_private *priv = (struct r1000_private *)(netdev->priv); unsigned long ioaddr = priv->ioaddr; @@ -136,6 +157,8 @@ int ethtool_ioctl(struct ifreq *ifr){ #if LINUX_VERSION_CODE > KERNEL_VERSION(2,5,0) struct ethtool_ops r1000_ethtool_ops = { + .get_regs_len = r1000_get_regs_len, + .get_regs = r1000_get_regs, .get_settings = ethtool_get_settings, .set_settings = ethtool_set_settings, }; - 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/7] NetLabel: core network changes
On Fri, Jul 28, 2006 at 03:08:44PM -0400, Paul Moore ([EMAIL PROTECTED]) wrote: > > Not a requirement but I would encourage it. Almost all netlink > > families are using attributes with a few exceptions. We just > > used to call them rtattr defined in rtnetlink.h before the new > > api was added. There is one huge advantage in using attributes > > which is that your protocol is extendable without breaking binary > > interfaces. > > > > What I'm refering to primarly are the existing functions to write > > netlink and genetlink headers etc. > > Okay. Thanks for your feedback but unless I hear from others that this > is a requirement I think I'm going to leave the code as written for the > reasons I listed above. I won't argue the fact that attributes may make > life easier when extending existing messages/interfaces but I think the > existing NetLabel message format as well as the generic netlinks > versioning of each message should allow plenty of room for growth in the > future (if needed). Attributes are usual for rtnetlink users way. It complicates code and reading, but allows to have a lot of commands inside your message (if one has not created special field himself), thus do not breaking existing interfaces. IT can be easily avoided by introducing new commands in your protocol, which is essentially the same as new attributes. It is just another way of representing the data. For example connector (idealogical parent of gennetlink) does not have such attributes, but has similar to your structures approach, so it is only the way you like to represent your data. > -- > paul moore > linux security @ hp -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
lockdep tcp_v6_rcv message
Triggered on Fedora rawhide kernel-2.6.17-1.2462.fc6 x86_64 which is based on 2.6.18rc2-git6. IPv6 was in use at the time. = [ INFO: inconsistent lock state ] - inconsistent {softirq-on-W} -> {in-softirq-R} usage. swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes: (&sk->sk_dst_lock){---?}, at: [] sk_dst_check+0x26/0x12b {softirq-on-W} state was registered at: [] lock_acquire+0x4a/0x69 [] _write_lock+0x24/0x31 [] ip4_datagram_connect+0x2e1/0x350 [] inet_dgram_connect+0x57/0x65 [] sys_connect+0x7d/0xa4 [] system_call+0x7d/0x83 irq event stamp: 3507830 hardirqs last enabled at (3507830): [] kmem_cache_alloc+0xd3/0xf7 hardirqs last disabled at (3507829): [] kmem_cache_alloc+0x4b/0xf7 softirqs last enabled at (3507808): [] __do_softirq+0xec/0xf5 softirqs last disabled at (3507811): [] call_softirq+0x1e/0x28 other info that might help us debug this: 1 lock held by swapper/0: #0: (slock-AF_INET6){-+..}, at: [] tcp_v6_rcv+0x30e/0x770 [ipv6] stack backtrace: Call Trace: [] show_trace+0xaa/0x23d [] dump_stack+0x15/0x17 [] print_usage_bug+0x259/0x26a [] mark_lock+0x1d5/0x3e3 [] __lock_acquire+0x427/0xa54 [] lock_acquire+0x4b/0x69 [] _read_lock+0x28/0x34 [] sk_dst_check+0x26/0x12b [] :ipv6:ip6_dst_lookup+0x3a/0x1a2 [] :ipv6:tcp_v6_send_synack+0x185/0x2ec [] :ipv6:tcp_v6_conn_request+0x291/0x2f3 [] tcp_rcv_state_process+0x5f/0xe7b [] :ipv6:tcp_v6_do_rcv+0x268/0x372 [] :ipv6:tcp_v6_rcv+0x71f/0x770 [] :ipv6:ip6_input+0x223/0x315 [] :ipv6:ipv6_rcv+0x254/0x2af [] netif_receive_skb+0x260/0x2dd [] :e1000:e1000_clean_rx_irq+0x423/0x4c2 [] :e1000:e1000_clean+0x88/0x15b [] net_rx_action+0xac/0x1c7 [] __do_softirq+0x68/0xf5 [] call_softirq+0x1e/0x28 Thanks, Matt -- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.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: [RFC 1/4] kevent: core files.
>>> Clearly we should port httpd to kevents and take some measurements :) oh, I see, I forgot the 't' in 'thttpd'. My mistake. - z - 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 1/4] kevent: core files.
Evgeniy Polyakov wrote: > On Fri, Jul 28, 2006 at 12:01:28PM -0700, Zach Brown ([EMAIL PROTECTED]) > wrote: >> Clearly we should port httpd to kevents and take some measurements :) > > One of my main kevent benchmarks (socket notifications for > accept/receive) is handmade http server. Yeah, so I noticed. That's a good starting point but I'm more interested in seeing the work integrated with servers that have to survive outside of benchmarking runs. - z - 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 1/4] kevent: core files.
On Fri, Jul 28, 2006 at 12:01:28PM -0700, Zach Brown ([EMAIL PROTECTED]) wrote: > Clearly we should port httpd to kevents and take some measurements :) One of my main kevent benchmarks (socket notifications for accept/receive) is handmade http server. I compared it with FreeBSD kqueue, epoll and kevent_poll (this is generic poll/select notifications ported to kevent) based (it is the same server but with different event functions. Client was httperf, I ran it with 30k connections in bursts of 3k connection with 1 second timeout between bursts. Here are results: kevent: more than 2600 requests/second epoll and kevent_poll: about 1600-1800 requests/second kqueue: enormous number of connection reset errors (only 62% of successfull connections) (likely misconfiguration, default FreeBSD 6-something does not allow such rates at all). More info can be found on kevent homepage: http://tservice.net.ru/~s0mbre/old/?section=projects&item=kevent > - z -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/4] kevent: core files.
> So, I'm going to create kevent_create/destroy/control and kevent_get_events() > Or any better names? Yeah, that sounds good. > Some events are impossible to create in userspace (like timer > notification, which requires timer start and check when timer > completed). We're not talking about *creating* events in userspace, we're talking about checking for their completion events in the ring. > and get ready), and I do not see how, for exmple, glibc can avoid them > when user requested POLLIN or similar event for network dataflow? There are events that can be generated by kernel code paths as the event completes. Network sockets have the hooks to do this with SIGIO, it's very natural for the storage completion paths, etc. So that kernel code would update the ring which userspace could check. AIO does this today. Userspace would still have to use the syscall to sleep waiting for new events when the ring is empty. > According to syscall speed on Linux, last time I checked empty syscall > took about 100ns on AMD Athlon 3500+. Oh, sure, but still nice to avoid. I'm mostly pursuing this because Ulrich seemed so insistent on it in his paper and talk. I will be very sad if we don't have aggressive glibc support for this generic event collection interface and so I want very much to keep him engaged. Ulrich, would you be satisfied if we didn't have the userspace mapped ring on the first pass and only had a collection syscall? - z - 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/7] NetLabel: core network changes
Thomas Graf wrote: > * Paul Moore <[EMAIL PROTECTED]> 2006-07-28 14:39 > >>It sounds like you main concern is that I'm not using the netlink >>attribute interfaces, yes? I looked at using those originally but >>decided not to use them for the following reasons: >> >> 1. They are listed as "optional" in the documents I read >> 2. They add at least an extra 32 bits to each attribute >> 3. There seems to be plenty of users in net/ipv4 who do not make >>use of attributes (a *quick* look again reveals none) >> 4. Since I'm reading messages from userspace I can't trust the >>message contents regardless of it's use of attributes >> 5. Harder to work with in userspace without using a netlink >>library, which would create an extra dependency for tools which >>talk to the NetLabel subsystem >> >>Basically, I saw no requirement to use the netlink attributes and no >>advantage so I didn't. Is this reasonable, or do you feel the use of >>attributes is a requirement? > > Not a requirement but I would encourage it. Almost all netlink > families are using attributes with a few exceptions. We just > used to call them rtattr defined in rtnetlink.h before the new > api was added. There is one huge advantage in using attributes > which is that your protocol is extendable without breaking binary > interfaces. > > What I'm refering to primarly are the existing functions to write > netlink and genetlink headers etc. Okay. Thanks for your feedback but unless I hear from others that this is a requirement I think I'm going to leave the code as written for the reasons I listed above. I won't argue the fact that attributes may make life easier when extending existing messages/interfaces but I think the existing NetLabel message format as well as the generic netlinks versioning of each message should allow plenty of room for growth in the future (if needed). -- paul moore linux security @ hp - 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/7] NetLabel: core network changes
* Paul Moore <[EMAIL PROTECTED]> 2006-07-28 14:39 > It sounds like you main concern is that I'm not using the netlink > attribute interfaces, yes? I looked at using those originally but > decided not to use them for the following reasons: > > 1. They are listed as "optional" in the documents I read > 2. They add at least an extra 32 bits to each attribute > 3. There seems to be plenty of users in net/ipv4 who do not make > use of attributes (a *quick* look again reveals none) > 4. Since I'm reading messages from userspace I can't trust the > message contents regardless of it's use of attributes > 5. Harder to work with in userspace without using a netlink > library, which would create an extra dependency for tools which > talk to the NetLabel subsystem > > Basically, I saw no requirement to use the netlink attributes and no > advantage so I didn't. Is this reasonable, or do you feel the use of > attributes is a requirement? Not a requirement but I would encourage it. Almost all netlink families are using attributes with a few exceptions. We just used to call them rtattr defined in rtnetlink.h before the new api was added. There is one huge advantage in using attributes which is that your protocol is extendable without breaking binary interfaces. What I'm refering to primarly are the existing functions to write netlink and genetlink headers etc. - 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 1/4] kevent: core files.
> Things were like that at one point in time, but file descriptors turn out > to introduce a huge gaping security hole with SUID programs. The problem > is that any event context is closely tied to the address space of the > thread issuing the syscalls, and file descriptors do not have this close > binding. Can you go into that hole in more detail? > Except that you're not usually pulling a full ring worth of events at a > time, more often just one. OK, but then to wait for it you were already sleeping in the kernel, right? Clearly we should port httpd to kevents and take some measurements :) - z - 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/7] NetLabel: documentation
David Miller wrote: > From: [EMAIL PROTECTED] > Date: Mon, 17 Jul 2006 11:52:25 -0400 > > >>+CIPSOv4 Variables: >>+ >>+cipso_cache_enable - BOOLEAN > > ... > >>+cipso_cache_bucket_size - INTEGER > > ... > >>+cipso_rbm_optfmt - BOOLEAN > > ... > >>+cipso_rbm_structvalid - BOOLEAN > > ... > > We need some more information for these entries. > > First, list the default value these sysctls will have. > This is consistent with other entries in this file. If > there is a compelling argument to support the default > value, please mention it. > > Second, cipso_cache_bucket_size is still opaque, there is > nothing in the description with describes the units this > value is specified in, nor in fact what it really controls. > Does it say how deep the hash chains of the hash table are > allowed to grow to? Otherwise, what does it control and what > are the consequences of using different values? > Okay, I'll work on the doc so to try and take care of these issues. -- paul moore linux security @ hp - 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/7] NetLabel: core network changes
David Miller wrote: > From: [EMAIL PROTECTED] > Date: Mon, 17 Jul 2006 11:52:26 -0400 >>@@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, str >> >> sock_graft(sk2, newsock); >> >>+ netlbl_socket_inet_accept(sock, newsock); >>+ >> newsock->state = SS_CONNECTED; >> err = 0; >> release_sock(sk2); > > This is only true wart I see in the patch set from my > perspective. > > You have security_post_accept_hook(), which gets the parent and > the child socket which is all the information you need, and it > seems to be invoked at the correct location. > > So can you please hook into this location using the security > level hook we already have? Just check sock->sk->sk_family is > PF_INET at the top of that hook if you only want to handle > ipv4 sockets, or something like that. > > Could this work? > > When preparing and argument stating why this won't work, please > suggest a nicer name for this af_inet.c hook or some way to make > it more generic and palatable to us. The only reason for having this new hook in inet_accept() is to catch all the in-kernel "daemons" who do not go through the LSM hooked accept() code path. I debated putting this hook into the patchset and in the end figured it was at least worth a shot. I'm happy to drop this hook as it *looks* like the MLSXFRM patchset is going to make it which has some of the accept hooks I was hoping to get, but figured I stood a "snowballs chance in hell" trying to get it in solely for use with CIPSO :) I'll drop this on the next release of the NetLabel patchset and assuming both the NetLabel and the MLSXFRM patchset make it into the 2.6.19 release I'll issue another small patchset then to integrate into the new LSM hooks for accept. I'd do it now but I think it would cause too much of a mess with patch dependencies/collisions/etc. >>- case 0x86: /* Another "Commercial Security" crap. */ >>+ case IPOPT_CIPSO: > > I am sad to see this comment disappear :-) ... and I was surprised you didn't comment about that change sooner ;) -- paul moore linux security @ hp - 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 1/4] kevent: core files.
On Fri, Jul 28, 2006 at 11:33:16AM -0700, Zach Brown ([EMAIL PROTECTED]) wrote: > > > I completely agree that existing kevent interface is not the best, so > > I'm opened for any suggestions. > > Should kevent creation/removing/modification be separated too? > > Yeah, I think so. So, I'm going to create kevent_create/destroy/control and kevent_get_events() Or any better names? > >>> Hmm, it looks like I'm lost here... > >> Yeah, it seems my description might not have sunk in :). We're giving > >> userspace a way to collect events without performing a system call. > > > > And why do we want this? > > So that event collection can be very efficient. > > > How glibc is supposed to determine, that some events already fired and > > such requests will return immediately, or for example how timer events > > will be managed? > > ... > > That was what my previous mail was all about! Some events are impossible to create in userspace (like timer notification, which requires timer start and check when timer completed). Actually all events are part of the kernel, since glibc does not have any knowledge about in-kernel state machines which are bound to appropriate kevents, so each kevent takes at least two syscall (create and get ready), and I do not see how, for exmple, glibc can avoid them when user requested POLLIN or similar event for network dataflow? According to syscall speed on Linux, last time I checked empty syscall took about 100ns on AMD Athlon 3500+. > - z -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/7] NetLabel: core network changes
Thomas Graf wrote: > * Paul Moore <[EMAIL PROTECTED]> 2006-07-28 13:58 > >>I'm a little confused by your comment, could you be a bit more >>specific? Are you basing your comment strictly on the text above? If >>so, the problem may be my poor excuse for documentation rather then my >>poor excuse for implementation :) >> >>I am using the generic netlink interface, in what I believe to be a >>"correct" fashion - please correct me if I'm wrong. > > The netlink bits are spread around all patches so I just quoted > on this comment. By adding functions like netlbl_align(), > netlbl_put_u8(), netlbl_put_hdr() writing a netlink header > etc. you are just duplicating the already existing interfaces > found in net/netlink.h and net/genetlink.h. Thanks for the clarification, I think I understand your point a bit better now. It sounds like you main concern is that I'm not using the netlink attribute interfaces, yes? I looked at using those originally but decided not to use them for the following reasons: 1. They are listed as "optional" in the documents I read 2. They add at least an extra 32 bits to each attribute 3. There seems to be plenty of users in net/ipv4 who do not make use of attributes (a *quick* look again reveals none) 4. Since I'm reading messages from userspace I can't trust the message contents regardless of it's use of attributes 5. Harder to work with in userspace without using a netlink library, which would create an extra dependency for tools which talk to the NetLabel subsystem Basically, I saw no requirement to use the netlink attributes and no advantage so I didn't. Is this reasonable, or do you feel the use of attributes is a requirement? -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH Round 5 2/3] Core net changes to generate netevents
Generate netevents for: - neighbour changes - routing redirects - pmtu changes --- net/core/Makefile|2 +- net/core/neighbour.c | 14 -- net/ipv4/route.c |8 net/ipv6/route.c |7 +++ 4 files changed, 24 insertions(+), 7 deletions(-) diff --git a/net/core/Makefile b/net/core/Makefile index e9bd246..2645ba4 100644 --- a/net/core/Makefile +++ b/net/core/Makefile @@ -7,7 +7,7 @@ obj-y := sock.o request_sock.o skbuff.o obj-$(CONFIG_SYSCTL) += sysctl_net_core.o -obj-y += dev.o ethtool.o dev_mcast.o dst.o \ +obj-y += dev.o ethtool.o dev_mcast.o dst.o netevent.o \ neighbour.o rtnetlink.o utils.o link_watch.o filter.o obj-$(CONFIG_XFRM) += flow.o diff --git a/net/core/neighbour.c b/net/core/neighbour.c index 7ad681f..5130d2e 100644 --- a/net/core/neighbour.c +++ b/net/core/neighbour.c @@ -29,6 +29,7 @@ #include #include #include #include +#include #include #include #include @@ -754,6 +755,7 @@ #endif neigh->nud_state = NUD_STALE; neigh->updated = jiffies; neigh_suspect(neigh); + notify = 1; } } else if (state & NUD_DELAY) { if (time_before_eq(now, @@ -762,6 +764,7 @@ #endif neigh->nud_state = NUD_REACHABLE; neigh->updated = jiffies; neigh_connect(neigh); + notify = 1; next = neigh->confirmed + neigh->parms->reachable_time; } else { NEIGH_PRINTK2("neigh %p is probed.\n", neigh); @@ -819,6 +822,8 @@ #endif out: write_unlock(&neigh->lock); } + if (notify) + call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh); #ifdef CONFIG_ARPD if (notify && neigh->parms->app_probes) @@ -926,9 +931,7 @@ int neigh_update(struct neighbour *neigh { u8 old; int err; -#ifdef CONFIG_ARPD int notify = 0; -#endif struct net_device *dev; int update_isrouter = 0; @@ -948,9 +951,7 @@ #endif neigh_suspect(neigh); neigh->nud_state = new; err = 0; -#ifdef CONFIG_ARPD notify = old & NUD_VALID; -#endif goto out; } @@ -1022,9 +1023,7 @@ #endif if (!(new & NUD_CONNECTED)) neigh->confirmed = jiffies - (neigh->parms->base_reachable_time << 1); -#ifdef CONFIG_ARPD notify = 1; -#endif } if (new == old) goto out; @@ -1056,6 +1055,9 @@ out: (neigh->flags & ~NTF_ROUTER); } write_unlock_bh(&neigh->lock); + + if (notify) + call_netevent_notifiers(NETEVENT_NEIGH_UPDATE, neigh); #ifdef CONFIG_ARPD if (notify && neigh->parms->app_probes) neigh_app_notify(neigh); diff --git a/net/ipv4/route.c b/net/ipv4/route.c index 2dc6dbb..19bd49d 100644 --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -104,6 +104,7 @@ #include #include #include #include +#include #ifdef CONFIG_SYSCTL #include #endif @@ -1125,6 +1126,7 @@ void ip_rt_redirect(u32 old_gw, u32 dadd struct rtable *rth, **rthp; u32 skeys[2] = { saddr, 0 }; int ikeys[2] = { dev->ifindex, 0 }; + struct netevent_redirect netevent; if (!in_dev) return; @@ -1216,6 +1218,11 @@ void ip_rt_redirect(u32 old_gw, u32 dadd rt_drop(rt); goto do_next; } + + netevent.old = &rth->u.dst; + netevent.new = &rt->u.dst; + call_netevent_notifiers(NETEVENT_REDIRECT, + &netevent); rt_del(hash, rth); if (!rt_intern_hash(hash, rt, &rt)) @@ -1452,6 +1459,7 @@ static void ip_rt_update_pmtu(struct dst } dst->metrics[RTAX_MTU-1] = mtu; dst_set_expires(dst, ip_rt_mtu_expires); + call_netevent_notifiers(NETEVENT_PMTU_UPDATE, dst); } } diff --git a/net/ipv6/route.c b/net/ipv6/route.c index 87c39c9..4b16371 100644 --- a/net/ipv6/route.c +++ b/net/ipv6/route.c @@ -53,6 +53,7 @@ #include #include #include #include +#include #include @@ -742,6 +743,7 @@ static void ip6_rt_update_pmtu(struct ds dst->metrics[RTAX_FEATURES-1] |= RTAX_FEATURE_ALLFRAG; } dst->metrics[RTAX_MTU-1] = mtu; + call_netevent_notifiers(NETEVENT_PMTU_UPDATE, dst); } } @@ -1155,6 +1157,7
[PATCH Round 5 3/3] Cleanup ib_addr module to use the netevents
--- drivers/infiniband/core/addr.c | 30 ++ 1 files changed, 14 insertions(+), 16 deletions(-) diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c index d294bbc..1205e80 100644 --- a/drivers/infiniband/core/addr.c +++ b/drivers/infiniband/core/addr.c @@ -35,6 +35,7 @@ #include #include #include #include +#include #include MODULE_AUTHOR("Sean Hefty"); @@ -326,25 +327,22 @@ void rdma_addr_cancel(struct rdma_dev_ad } EXPORT_SYMBOL(rdma_addr_cancel); -static int addr_arp_recv(struct sk_buff *skb, struct net_device *dev, -struct packet_type *pkt, struct net_device *orig_dev) +static int netevent_callback(struct notifier_block *self, unsigned long event, + void *ctx) { - struct arphdr *arp_hdr; + if (event == NETEVENT_NEIGH_UPDATE) { + struct neighbour *neigh = ctx; - arp_hdr = (struct arphdr *) skb->nh.raw; - - if (arp_hdr->ar_op == htons(ARPOP_REQUEST) || - arp_hdr->ar_op == htons(ARPOP_REPLY)) - set_timeout(jiffies); - - kfree_skb(skb); + if (neigh->dev->type == ARPHRD_INFINIBAND && + (neigh->nud_state & NUD_VALID)) { + set_timeout(jiffies); + } + } return 0; } -static struct packet_type addr_arp = { - .type = __constant_htons(ETH_P_ARP), - .func = addr_arp_recv, - .af_packet_priv = (void*) 1, +static struct notifier_block nb = { + .notifier_call = netevent_callback }; static int addr_init(void) @@ -353,13 +351,13 @@ static int addr_init(void) if (!addr_wq) return -ENOMEM; - dev_add_pack(&addr_arp); + register_netevent_notifier(&nb); return 0; } static void addr_cleanup(void) { - dev_remove_pack(&addr_arp); + unregister_netevent_notifier(&nb); destroy_workqueue(addr_wq); } - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH Round 5 0/3] Network Event Notifier Mechanism
Dave/Roland, is this patchset about ready to go? Round 5 Changes: - removed user-mode support - removed route add/del events. -- This patch implements a mechanism that allows interested clients to register for notification of certain network events. The intended use is to allow RDMA devices (linux/drivers/infiniband) to be notified of neighbour updates, ICMP redirects, and path MTU changes. RDMA devices need these network events because they typically cache this information in hardware and need to be notified when it changes. To learn about RDMA internet protocols, see: http://www.ietf.org/html.charters/rddp-charter.html. The key events of interest are: - neighbour mac address change - routing redirect (the next hop neighbour changes for a dst_entry) - path mtu change (the path mtu for a dst_entry changes). This patchset consists of 3 patches: 1) New files implementing the Network Event Notifier 2) Core network changes to generate netevents 3) Cleanup ib_addr modules to use the netevent patch Signed-off-by: Tom Tucker <[EMAIL PROTECTED]> Signed-off-by: Steve Wise <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH Round 5 1/3] Network Event Notifier Mechanism.
This patch uses notifier blocks to implement a network event notifier mechanism. Clients register their callback function by calling register_netevent_notifier() like this: static struct notifier_block nb = { .notifier_call = my_callback_func }; ... register_netevent_notifier(&nb); --- include/net/netevent.h | 33 +++ net/core/netevent.c| 69 2 files changed, 102 insertions(+), 0 deletions(-) diff --git a/include/net/netevent.h b/include/net/netevent.h new file mode 100644 index 000..e5d2162 --- /dev/null +++ b/include/net/netevent.h @@ -0,0 +1,33 @@ +#ifndef _NET_EVENT_H +#define _NET_EVENT_H + +/* + * Generic netevent notifiers + * + * Authors: + * Tom Tucker <[EMAIL PROTECTED]> + * Steve Wise <[EMAIL PROTECTED]> + * + * Changes: + */ +#ifdef __KERNEL__ + +#include + +struct netevent_redirect { + struct dst_entry *old; + struct dst_entry *new; +}; + +enum netevent_notif_type { + NETEVENT_NEIGH_UPDATE = 1, /* arg is struct neighbour ptr */ + NETEVENT_PMTU_UPDATE, /* arg is struct dst_entry ptr */ + NETEVENT_REDIRECT, /* arg is struct netevent_redirect ptr */ +}; + +extern int register_netevent_notifier(struct notifier_block *nb); +extern int unregister_netevent_notifier(struct notifier_block *nb); +extern int call_netevent_notifiers(unsigned long val, void *v); + +#endif +#endif diff --git a/net/core/netevent.c b/net/core/netevent.c new file mode 100644 index 000..35d02c3 --- /dev/null +++ b/net/core/netevent.c @@ -0,0 +1,69 @@ +/* + * Network event notifiers + * + * Authors: + * Tom Tucker <[EMAIL PROTECTED]> + * Steve Wise <[EMAIL PROTECTED]> + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License + * as published by the Free Software Foundation; either version + * 2 of the License, or (at your option) any later version. + * + * Fixes: + */ + +#include +#include + +static ATOMIC_NOTIFIER_HEAD(netevent_notif_chain); + +/** + * register_netevent_notifier - register a netevent notifier block + * @nb: notifier + * + * Register a notifier to be called when a netevent occurs. + * The notifier passed is linked into the kernel structures and must + * not be reused until it has been unregistered. A negative errno code + * is returned on a failure. + */ +int register_netevent_notifier(struct notifier_block *nb) +{ + int err; + + err = atomic_notifier_chain_register(&netevent_notif_chain, nb); + return err; +} + +/** + * netevent_unregister_notifier - unregister a netevent notifier block + * @nb: notifier + * + * Unregister a notifier previously registered by + * register_neigh_notifier(). The notifier is unlinked into the + * kernel structures and may then be reused. A negative errno code + * is returned on a failure. + */ + +int unregister_netevent_notifier(struct notifier_block *nb) +{ + return atomic_notifier_chain_unregister(&netevent_notif_chain, nb); +} + +/** + * call_netevent_notifiers - call all netevent notifier blocks + * @val: value passed unmodified to notifier function + * @v: pointer passed unmodified to notifier function + * + * Call all neighbour notifier blocks. Parameters and return value + * are as for notifier_call_chain(). + */ + +int call_netevent_notifiers(unsigned long val, void *v) +{ + return atomic_notifier_call_chain(&netevent_notif_chain, val, v); +} + +EXPORT_SYMBOL_GPL(register_netevent_notifier); +EXPORT_SYMBOL_GPL(unregister_netevent_notifier); +EXPORT_SYMBOL_GPL(call_netevent_notifiers); - 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 1/4] kevent: core files.
> I completely agree that existing kevent interface is not the best, so > I'm opened for any suggestions. > Should kevent creation/removing/modification be separated too? Yeah, I think so. >>> Hmm, it looks like I'm lost here... >> Yeah, it seems my description might not have sunk in :). We're giving >> userspace a way to collect events without performing a system call. > > And why do we want this? So that event collection can be very efficient. > How glibc is supposed to determine, that some events already fired and > such requests will return immediately, or for example how timer events > will be managed? ... That was what my previous mail was all about! - z - 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 6/8] NetLabel: CIPSOv4 integration
Jamal Hadi Salim wrote: > On Thu, 2006-22-06 at 18:49 -0400, [EMAIL PROTECTED] wrote: >>+/** >>+ * netlbl_cipsov4_rcv - Process incoming NetLabel packets >>+ * @skb: the NETLINK buffer >>+ * @msg: pointer to the start of the NetLabel data >>+ * >>+ * Description: >>+ * This function is reponsibile for reading all of the incoming CIPSO V4 >>+ * NetLabel traffic and dispatching it to the correct CIPSO V4 functions. >>+ * >>+ */ >>+void netlbl_cipsov4_rcv(const struct sk_buff *skb, const unsigned char *msg) >>+{ >>+ int ret_val; >>+ struct netlbl_cipsov4_msghdr *nl_cv4_hdr; >>+ >>+ if (nlmsg_len((struct nlmsghdr *)skb->data) < >>+ sizeof(struct netlbl_cipsov4_msghdr)) { >>+ netlbl_cipsov4_send_ack(skb, EINVAL); >>+ return; >>+ } >>+ >>+ nl_cv4_hdr = (struct netlbl_cipsov4_msghdr *)msg; >>+ switch (nl_cv4_hdr->opcode) { >>+ case NL_CV4_ADD: > > Could you not have had all these NL_CV4_CMDs as just TLVs? > This is just the classical way of how we do things. > This would allow you to send multiple cmds in one message as well as > very easily add new ones in the future. I think you are looking at an older patchset, which is most likely my fault for not clearly marking each patch set with a datestamp or version number. I will fix that in next release. Anyway, back to your comment - this function no longer exists in the current patchset. All of the different "commands" specified by NL_CV4_* are now "operations" registered with the genetlink interface. It's not the TLV solution you mention but it seems to be inline with how the generic netlink interface works. > BTW, can you please repost your latest changes to netdev? Yes I will, but not much has changed from my last patchset posted to netdev (although quite a bit has changed since the patchset you are looking at). I'm in the middle of moving/unpacking right now so it may not get posted until sometime this weekend, although I try for today. -- paul moore linux security @ hp - 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/7] NetLabel: core network changes
* Paul Moore <[EMAIL PROTECTED]> 2006-07-28 13:58 > I'm a little confused by your comment, could you be a bit more > specific? Are you basing your comment strictly on the text above? If > so, the problem may be my poor excuse for documentation rather then my > poor excuse for implementation :) > > I am using the generic netlink interface, in what I believe to be a > "correct" fashion - please correct me if I'm wrong. The netlink bits are spread around all patches so I just quoted on this comment. By adding functions like netlbl_align(), netlbl_put_u8(), netlbl_put_hdr() writing a netlink header etc. you are just duplicating the already existing interfaces found in net/netlink.h and net/genetlink.h. - 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/7] NetLabel: core network changes
Thomas Graf wrote: > * [EMAIL PROTECTED] <[EMAIL PROTECTED]> 2006-07-17 11:52 > >>+ * NetLabel makes use of the Generic NETLINK mechanism as a transport layer >>to >>+ * send messages between kernel and user space. The general format of a >>+ * NetLabel message is shown below: >>+ * >>+ * +-+---+- --- -- - >>+ * | struct nlmsghdr | struct genlmsghdr | payload >>+ * +-+---+- --- -- - >>+ * >>+ * The 'nlmsghdr' and 'genlmsghdr' structs should be dealt with like normal. >>+ * The payload is dependent on the subsystem specified in the >>+ * 'nlmsghdr->nlmsg_type' and should be defined below, supporting functions >>+ * should be defined in the corresponding net/netlabel/netlabel_.h|c >>+ * file. All of the fields in the NetLabel payload should be aligned using >>+ * the alignment functions provided. >>+ * >>+ */ >>+ >>+/* >>+ * NetLabel NETLINK protocol >>+ */ >>+ > > Is there a reason for not using any of the existing netlink and > genetlink interfaces in any of your patches? It's all duplicated > code. I'm a little confused by your comment, could you be a bit more specific? Are you basing your comment strictly on the text above? If so, the problem may be my poor excuse for documentation rather then my poor excuse for implementation :) I am using the generic netlink interface, in what I believe to be a "correct" fashion - please correct me if I'm wrong. -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PATCH Fix bonding active-backup behavior for VLAN interfaces
This patch by itself does nothing useful, other than remove a method. If we assume you did the patch backwards, and wanted to add the method instead, then where is this method ever called? Ben Christophe Devriese wrote: diff -rU3 linux-2.6.17.7/net/core/dev.c linux-2.6.17.7-wapper/net/core/dev.c --- linux-2.6.17.7/net/core/dev.c 2006-07-25 05:36:01.0 +0200 +++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 20:16:36.0 +0200 @@ -88,6 +88,7 @@ #include #include #include +#include #include #include #include @@ -1518,37 +1519,6 @@ EXPORT_SYMBOL(netif_rx_ni); -static inline struct net_device *skb_bond(struct sk_buff *skb) -{ - struct net_device *dev = skb->dev; - - if (dev->master) { - /* -* On bonding slaves other than the currently active -* slave, suppress duplicates except for 802.3ad -* ETH_P_SLOW and alb non-mcast/bcast. -*/ - if (dev->priv_flags & IFF_SLAVE_INACTIVE) { - if (dev->master->priv_flags & IFF_MASTER_ALB) { - if (skb->pkt_type != PACKET_BROADCAST && - skb->pkt_type != PACKET_MULTICAST) - goto keep; - } - - if (dev->master->priv_flags & IFF_MASTER_8023AD && - skb->protocol == __constant_htons(ETH_P_SLOW)) - goto keep; - - kfree_skb(skb); - return NULL; - } -keep: - skb->dev = dev->master; - } - - return dev; -} - static void net_tx_action(struct softirq_action *h) { struct softnet_data *sd = &__get_cpu_var(softnet_data); -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.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: Debugging kernel lockups during network activity
On 27-07-2006 20:19, Art Haas wrote: Hi. I've got Fedora Rawhide running on a SMP PIII machine, and the latest kernels from Fedora have been locking up when I run 'yum update' to get the latest packages. I also experience lock-ups when I use Firefox to do some web browsing. Not all my network usage results in a lockup, however. I can usually do 'git pull' and update git itself or my copy of Linus' kernel tree without problems, as well as update my GCC repo with subversion and Mozilla with cvs. I realize that running Fedora Rawhide means when things break I can keep the pieces, so the lockups or other occasional issues are not unexpected. I don't know the numbers of this kernels, but did you try linux-2.6.18-rc2. It has some great patch to queue scheduler by Hubert Xu. I think it is some Gnu/miracle that it has been working (mostly) under heavy load without this patch. But there are also other possibilities... Jarek P. - 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: SMSC LAN911x and LAN921x vendor driver
> +/* Tasklet declarations */ > +static unsigned long rx_tasklet_parameter; > +static void smsc911x_rx_tasklet(unsigned long data); > + > +DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 0); You can make this local with static DECLARE_TASKLET(rx_tasklet, smsc911x_rx_tasklet, 0); - 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/9] d80211: pull request
On Tue, 18 Jul 2006 17:45:20 +0200 (CEST), Jiri Benc wrote: > Please pull from > git://git.kernel.org/pub/scm/linux/kernel/git/jbenc/dscape.git master I renamed that branch to 'up'. Please pull from 'up' branch. > to obtain following patches: > > Jiri Benc: > d80211: do not receive through master interface when not scanning > d80211: host_gen_beacon_template flag > d80211: better deallocation of mdev > d80211: fix receiving through virtual interfaces > d80211: fix defragmentation > d80211: optimize defragmentation > d80211: SET_NETDEV_DEV for non-master devices > > Michael Wu: > d80211: Replace rc4 code with crypto api arc4 > d80211: Add sparse bitwise annotations -- Jiri Benc SUSE Labs - 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: fix kernel panic from no dev->hard_header_len space
Krzysztof Halasa <[EMAIL PROTECTED]> writes: > Are you sure about that? It would mean almost devices, including ^^ > Ethernet, are at risk: "almost all devices", of course. -- Krzysztof Halasa - 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: [3/4] kevent: AIO, aio_sendfile() implementation.
On Thu, 2006-07-27 at 14:02 -0700, Badari Pulavarty wrote: > On Thu, 2006-07-27 at 11:44 -0700, Ulrich Drepper wrote: > > Badari Pulavarty wrote: > > > Before we spend too much time cleaning up and merging into mainline - > > > I would like an agreement that what we add is good enough for glibc > > > POSIX AIO. > > > > I haven't seen a description of the interface so far. Would be good if > > it existed. But I briefly mentioned one quirk in the interface about > > which Suparna wasn't sure whether it's implemented/implementable in the > > current interface. > > Sebastien, could you provide a description of interfaces you are > adding ? Since you did all the work, it would be appropriate for > you to do it :) > Here are the descriptions for the AIO completion notification and listio patches. Hope I did not leave out too much. Sébastien. -- - Sébastien DuguéBULL/FREC:B1-247 phone: (+33) 476 29 77 70 Bullcom: 229-7770 mailto:[EMAIL PROTECTED] Linux POSIX AIO: http://www.bullopensource.org/posix http://sourceforge.net/projects/paiol - aio completion notification Summary: --- The current 2.6 kernel does not support notification of user space via an RT signal upon an asynchronous IO completion. The POSIX specification states that when an AIO request completes, a signal can be delivered to the application as notification. The aioevent patch adds a struct sigevent *aio_sigeventp to the iocb. The relevant fields (pid, signal number and value) are stored in the kiocb for use when the request completes. That sigevent structure is filled by the application as part of the AIO request preparation. Upon request completion, the kernel notifies the application using those sigevent parameters. If SIGEV_NONE has been specified, then the old behaviour is retained and the application must rely on polling the completion queue using io_getevents(). Details: --- A struct sigevent *aio_sigeventp is added to struct iocb in include/linux/aio_abi.h An enum {IO_NOTIFY_SIGNAL = 0, IO_NOTIFY_THREAD_ID = 1} is added in include/linux/aio.h: - IO_NOTIFY_SIGNAL means that the signal is to be sent to the requesting thread - IO_NOTIFY_THREAD_ID means that the signal is to be sent to a specifi thread. The following fields are added to struct kiocb in include/linux/aio.h: - pid_t ki_pid: target of the signal - __u16 ki_signo: signal number - __u16 ki_notify: kind of notification, IO_NOTIFY_SIGNAL or IO_NOTIFY_THREAD_ID - uid_t ki_uid, ki_euid: filled with the submitter credentials - sigval_t ki_sigev_value: value stuffed in siginfo these fields are only valid if ki_signo != 0. In io_submit_one(), if the application provided a sigevent then iocb_setup_sigevent() is called which does the following: - save current->uid and current->euid in the kiocb fields ki_uid and ki_euid for use in the completion path to check permissions - check access to the user sigevent - extract the needed fields from the sigevent (pid, signo, and value). If the signal number passed from userspace is 0 then no notification is to occur and ki_signo is set to 0 - check whether the submitting thread wants to be notified directly (sigevent->sigev_notify_thread_id is 0) or wants the signal to be sent to another thread. In the latter case a check is made to assert that the target thread is in the same thread group - fill in the kiocb fields (ki_pid, ki_signo, ki_notify and ki_sigev_value) for that request. Upon request completion, in aio_complete(), if ki_signo is not 0, then __aio_send_signal() is called which sends the signal as follows: - fill in the siginfo struct to be sent to the application - check whether we have permission to signal the given thread - send the signal listio support Summary: --- The lio patch adds POSIX listio completion notification support. It builds on support provided by the aio event patch and adds an IOCB_CMD_GROUP command to sys_io_submit(). The purpose of IOCB_CMD_GROUP is to group together the following requests in the list up to the end of the list. As part of listio submission, the user process prepends to a list of requests an empty special aiocb with an aio_lio_opcode of IOCB_CMD_GROUP, filling only the aio_sigevent fields. Details: --- An IOCB_CMD_GROUP is added to the IOCB_CMD enum in include/linux/aio_abi.h A struct lio_event is added in include/linux/aio.h A struct lio_event *ki_lio is added to struct iocb in include/linux/aio.h In sys_io_submit(), upon detecting such an IOCB_CMD
Re: Regarding offloading IPv6 addrconf and ndisc
On Fri, 2006-28-07 at 09:34 +0100, Hugo Santos wrote: > > 2. What if user process dies? or gets overwhelmed? > >One of the assumptions of the any well designed kernel is that the > > system should never > >hang because some user application died or waited for ever. > >Of course that this is a real problem. However, if the control daemon > dies the kernel won't die. Depending on the implementation -- you might > temporarily get out of addresses, if the addresses are flushed when the > control daemon dies, etc. But, just like a routing daemon is critical > to a router, this control application would also be critical to the > host's connectivity. And if it dies, it needs to be restarted. The > application might be itself complex, but in the end we moved this > complexity away from the kernel. > Hugo, The biggest challenge you will face is the view that people hate daemons - mostly from a usability perspective (is the gist of the arguements i have seen) but also because of concerns such as the one Stephen mentions above. I hold the same views as you do on the separation of control from the datapath and to respond to Stephens assertion on well designed kernel above: It is good kernel abstraction to separate policy management from mechanisms. The certificate issue only validates further this pov: that control tends to be feature-rich, swiss-army knife i.e more moving target than datapath. Such things typically belong to user-space. I have also seen talk of secure ARP; i wonder if there may be certificates involved there as well? If you look at the archives on netdev you may notice such discussions. Summary: I violently agree with you and i think if you address the "daemon" concerns, you will get other folks to agree as well. 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
Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
On Fri, 2006-28-07 at 13:15 +0200, Lennert Buytenhek wrote: > On Fri, Jul 28, 2006 at 12:49:46PM +0200, Francois Romieu wrote: > > > > The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work > > > initially, but they don't actually seem to transmit any packets on the > > > wire, nor do they receive any. > > > > > > Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC > > > address for eth1 being incorrect (boot loader bug, being worked on) > > > there don't seem to be any strange messages or errors. > > > > Can you send: > > - the output of 'lspci -vvx' > Since you mention an incorrect MAC address: The one thing that has bitten me in the past(twice) is misprograming of the eeprom (where typically the MAC address would sit as well). Vendor in a hurry to put out the NIC/board forgets to do something at manufacturing time. The most recent was about 9 months back where the same chip was used in the board but in one port copper was used and in another hooking up via serdes. The eeprom claimed both to be copper. It worked for sometime until you pulled a link and then plugged it back in. A little ethtool magic to change the device id to match 0x107B (E1000_DEV_ID_82546GB_SERDES) instead of 0x1079 (E1000_DEV_ID_82546GB_COPPER) fixed it. cheers, jamal PS:- That box looks interesting - priced correctly i may even buy one ;-> - 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 6/8] NetLabel: CIPSOv4 integration
On Thu, 2006-22-06 at 18:49 -0400, [EMAIL PROTECTED] wrote: > plain text document attachment (netlabel-cipsov4) > Add CIPSO/IPv4 support and management to the NetLabel subsystem. These > changes > integrate the CIPSO/IPv4 configuration into the existing NetLabel code and > enable the use of CIPSO/IPv4 within the overall NetLabel framework. > --- > net/netlabel/netlabel_cipso_v4.c | 583 > +++ > 1 files changed, 583 insertions(+) > > +/** > + * netlbl_cipsov4_rcv - Process incoming NetLabel packets > + * @skb: the NETLINK buffer > + * @msg: pointer to the start of the NetLabel data > + * > + * Description: > + * This function is reponsibile for reading all of the incoming CIPSO V4 > + * NetLabel traffic and dispatching it to the correct CIPSO V4 functions. > + * > + */ > +void netlbl_cipsov4_rcv(const struct sk_buff *skb, const unsigned char *msg) > +{ > + int ret_val; > + struct netlbl_cipsov4_msghdr *nl_cv4_hdr; > + > + if (nlmsg_len((struct nlmsghdr *)skb->data) < > + sizeof(struct netlbl_cipsov4_msghdr)) { > + netlbl_cipsov4_send_ack(skb, EINVAL); > + return; > + } > + > + nl_cv4_hdr = (struct netlbl_cipsov4_msghdr *)msg; > + switch (nl_cv4_hdr->opcode) { > + case NL_CV4_ADD: Could you not have had all these NL_CV4_CMDs as just TLVs? This is just the classical way of how we do things. This would allow you to send multiple cmds in one message as well as very easily add new ones in the future. BTW, can you please repost your latest changes to netdev? 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
Re: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
* Lennert Buytenhek <[EMAIL PROTECTED]> [2006-07-28 13:15]: > > - an ethtool dump of the registers. I don't know if Realtek's > > driver support but it can help even the in-kernel driver > > I'll ask someone else with the same board to do the test and will > post the results. Here's the output using the r8169 driver: RealTek RTL-8110 registers: -- 0x00: MAC Address 00:14:fd:10:27:74 0x08: Multicast Address Filter 0x 0x 0x10: Dump Tally Counter Command 0xd7bbfec0 0xfb74b6fb 0x20: Tx Normal Priority Ring Addr 0x 0x 0x28: Tx High Priority Ring Addr 0xfffc3f00 0xfef7f6ad 0x30: Flash memory read/write 0x 0x34: Early Rx Byte Count 0 0x36: Early Rx Status 0x00 0x37: Command 0x00 Rx off, Tx off 0x3C: Interrupt Mask 0x 0x3E: Interrupt Status0x 0x40: Tx Configuration0x1000 0x44: Rx Configuration0x0002 0x48: Timer count 0x95887845 0x4C: Missed packet counter 0x00 0x50: EEPROM Command0x00 0x51: Config 0 0x04 0x52: Config 1 0x1f 0x53: Config 2 0x10 0x54: Config 3 0x20 0x55: Config 4 0x80 0x56: Config 5 0x01 0x58: Timer interrupt 0x 0x5C: Multiple Interrupt Select 0x 0x60: PHY access 0x80001000 0x64: TBI control and status 0x 0x68: TBI Autonegotiation advertisement (ANAR)0x 0x6A: TBI Link partner ability (LPAR) 0x 0x6C: PHY status0x6b 0x84: PM wakeup frame 00xbcfeef7f 0xde9f 0x8C: PM wakeup frame 10xabf7cf3f 0xfffbdbbf 0x94: PM wakeup frame 2 (low) 0xdfbbfedf 0xbfbd 0x9C: PM wakeup frame 2 (high) 0xaa75befc 0xcb5feaf9 0xA4: PM wakeup frame 3 (low) 0xbbdf6fdf 0xff7e75b7 0xAC: PM wakeup frame 3 (high) 0xbbdffbf9 0xfbfc 0xB4: PM wakeup frame 4 (low) 0x7f3bde9f 0x3bbffa7f 0xBC: PM wakeup frame 4 (high) 0xae9fbdcd 0x32c8bbff 0xC4: Wakeup frame 0 CRC 0x9aff 0xC6: Wakeup frame 1 CRC 0xfdbf 0xC8: Wakeup frame 2 CRC 0xaeff 0xCA: Wakeup frame 3 CRC 0x6bfe 0xCC: Wakeup frame 4 CRC 0xdc2f 0xDA: RX packet maximum size 0x3fff 0xE0: C+ Command 0x2028 RX checksumming PCI Multiple RW 0xE2: Interrupt Mitigation0x TxTimer: 0 TxPackets: 0 RxTimer: 0 RxPackets: 0 0xE4: Rx Ring Addr 0x07bd4000 0x 0xEC: Early Tx threshold0x3f -- 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: [PATCH 2/7] NetLabel: core network changes
* [EMAIL PROTECTED] <[EMAIL PROTECTED]> 2006-07-17 11:52 > + * NetLabel makes use of the Generic NETLINK mechanism as a transport layer > to > + * send messages between kernel and user space. The general format of a > + * NetLabel message is shown below: > + * > + * +-+---+- --- -- - > + * | struct nlmsghdr | struct genlmsghdr | payload > + * +-+---+- --- -- - > + * > + * The 'nlmsghdr' and 'genlmsghdr' structs should be dealt with like normal. > + * The payload is dependent on the subsystem specified in the > + * 'nlmsghdr->nlmsg_type' and should be defined below, supporting functions > + * should be defined in the corresponding net/netlabel/netlabel_.h|c > + * file. All of the fields in the NetLabel payload should be aligned using > + * the alignment functions provided. > + * > + */ > + > +/* > + * NetLabel NETLINK protocol > + */ > + Is there a reason for not using any of the existing netlink and genetlink interfaces in any of your patches? It's all duplicated code. - 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] SNMPv2 tcpAttemptFails counter error
I have changed my patch with your advice and it looks more effective. On Monday 24 July 2006 17:22, David Miller wrote: > From: Wei Yongjun <[EMAIL PROTECTED]> > Date: Wed, 05 Jul 2006 05:19:54 -0400 > > > In my test, those direct state transition can not be counted to > > tcpAttemptFails. Following is my patch: > > > > Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]> > > This change can be implemented more simply, I believe. > > Except for the tcp_minisocks.c change, all the paths > changed go to tcp_done() which is what actually transfers > the state to TCP_CLOSE. Therefore, tcp_done() can > simply be modified to check if the current state is > TCP_SYN_RECV, and is so bump the counter. > > Once you implement it this way, please audit all call paths > to make sure we don't now bump this counter twice. Signed-off-by: Wei Yongjun <[EMAIL PROTECTED]> --- a/include/net/tcp.h 2006-07-28 16:19:14.492052104 -0400 +++ b/include/net/tcp.h 2006-07-28 16:22:03.414372008 -0400 @@ -904,6 +904,9 @@ static inline void tcp_set_state(struct static inline void tcp_done(struct sock *sk) { + if(sk->sk_state == TCP_SYN_SENT || sk->sk_state == TCP_SYN_RECV) + TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS); + tcp_set_state(sk, TCP_CLOSE); tcp_clear_xmit_timers(sk); --- a/net/ipv4/tcp_ipv4.c 2006-07-28 16:23:21.677474208 -0400 +++ b/net/ipv4/tcp_ipv4.c 2006-07-28 16:23:48.854342696 -0400 @@ -437,7 +437,6 @@ void tcp_v4_err(struct sk_buff *skb, u32 It can f.e. if SYNs crossed. */ if (!sock_owned_by_user(sk)) { - TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS); sk->sk_err = err; sk->sk_error_report(sk); @@ -855,7 +854,6 @@ int tcp_v4_conn_request(struct sock *sk, drop_and_free: reqsk_free(req); drop: - TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS); return 0; } --- a/net/ipv4/tcp_minisocks.c 2006-07-28 16:23:55.862277328 -0400 +++ b/net/ipv4/tcp_minisocks.c 2006-07-28 16:25:18.263750400 -0400 @@ -592,8 +592,10 @@ struct sock *tcp_check_req(struct sock * /* RFC793: "second check the RST bit" and * "fourth, check the SYN bit" */ - if (flg & (TCP_FLAG_RST|TCP_FLAG_SYN)) + if (flg & (TCP_FLAG_RST|TCP_FLAG_SYN)) { + TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS); goto embryonic_reset; + } /* ACK sequence verified above, just make sure ACK is * set. If ACK not set, just silently drop the packet. --- a/net/ipv6/tcp_ipv6.c 2006-07-28 16:25:36.651954968 -0400 +++ b/net/ipv6/tcp_ipv6.c 2006-07-28 16:26:00.808282648 -0400 @@ -429,7 +429,6 @@ static void tcp_v6_err(struct sk_buff *s case TCP_SYN_RECV: /* Cannot happen. It can, it SYNs are crossed. --ANK */ if (!sock_owned_by_user(sk)) { - TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS); sk->sk_err = err; sk->sk_error_report(sk);/* Wake people up to see the error (see connect in sock.c) */ @@ -815,7 +814,6 @@ drop: if (req) reqsk_free(req); - TCP_INC_STATS_BH(TCP_MIB_ATTEMPTFAILS); return 0; /* don't send reset */ } - 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: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
On Fri, Jul 28, 2006 at 12:49:46PM +0200, Francois Romieu wrote: > > The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work > > initially, but they don't actually seem to transmit any packets on the > > wire, nor do they receive any. > > > > Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC > > address for eth1 being incorrect (boot loader bug, being worked on) > > there don't seem to be any strange messages or errors. > > Can you send: > - the output of 'lspci -vvx' :00:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) Subsystem: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- - the content of /proc/interrupts CPU0 9: 560468 IOP32X Timer Tick 27: 76294 uhci_hcd:usb3, eth0 28: 0 uhci_hcd:usb2 29: 0 ehci_hcd:usb1 Err: 0 > - an ethtool dump of the registers. I don't know if Realtek's driver > support but it can help even the in-kernel driver I'm running with the Realtek driver right now which doesn't support ethtool, and I'm running off NFS root so I can't boot with r8169 for the moment (-ENOSATADISK.) I'll ask someone else with the same board to do the test and will post the results. > > It doesn't seem to be a PHY configuration issue -- with a custom program > > to dump the MDIO registers (is there any reason r8169 doesn't support > > mii-tool, by the way? will you take a patch to add that?), we get the > > I had written it once, with some rework of the mii functions in the > driver. It was hit by conflicts generated by various changes as well > as higher priority bugs/features requests. You can send your code or > I can resurrect it at your option. My 'code' is just a userland program that maps /dev/mem and does essentially this: static unsigned short phy_read(void *rtl, int reg) { volatile unsigned int *phyar; phyar = (volatile unsigned int *)(rtl + 0x60); *phyar = reg << 16; while (!(*phyar & 0x8000)) ; return *phyar & 0x; } If you have code for MII already, it would be great if you could merge that at some point. > > Just wondering if you've seen this kind of behavior before before I dig > > into it further? I'm pretty sure the hardware is okay, since r1000 works, > > and the on-board SATA and UHCI/EHCI USB work fine as well. > > I have had a few success reports with the 8110 (and failures too, see > http://bugzilla.kernel.org/show_bug.cgi?id=5284) but I have not received > reports for this behavior lately. Complete lack of Rx/Tx activity have > been observed due to some irq problems. It does not seem to be the issue > here. IRQ routing appears to be okay here. The relevant PCI INTx <-> CPU XINTx pin routing is specified by hand on this platform, see n2100_pci_map_irq() in the file: http://svn.wantstofly.org/iop3xx/99-thecus.diff I'll get back to you about the ethtool dump. Anything else I can do in the meanwhile? cheers, Lennert - 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: r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
Lennert Buytenhek <[EMAIL PROTECTED]> : [...] > We're currently working on getting the Thecus n2100 supported in 2.6. > > http://www.thecus.com/products_over.php?cid=1&pid=1 I should really write some wish-list one day... > Amongst other nice goodies, it has two on-board RTL8110SB gigabit > controllers. The realtek-supplied 'r1000' driver kind of sort of works, Ok. That's good to know. > The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work > initially, but they don't actually seem to transmit any packets on the > wire, nor do they receive any. > > Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC > address for eth1 being incorrect (boot loader bug, being worked on) > there don't seem to be any strange messages or errors. Can you send: - the output of 'lspci -vvx' - the content of /proc/interrupts - an ethtool dump of the registers. I don't know if Realtek's driver support but it can help even the in-kernel driver > It doesn't seem to be a PHY configuration issue -- with a custom program > to dump the MDIO registers (is there any reason r8169 doesn't support > mii-tool, by the way? will you take a patch to add that?), we get the I had written it once, with some rework of the mii functions in the driver. It was hit by conflicts generated by various changes as well as higher priority bugs/features requests. You can send your code or I can resurrect it at your option. [...] > Just wondering if you've seen this kind of behavior before before I dig > into it further? I'm pretty sure the hardware is okay, since r1000 works, > and the on-board SATA and UHCI/EHCI USB work fine as well. I have had a few success reports with the 8110 (and failures too, see http://bugzilla.kernel.org/show_bug.cgi?id=5284) but I have not received reports for this behavior lately. Complete lack of Rx/Tx activity have been observed due to some irq problems. It does not seem to be the issue here. -- 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
FACK and CWND
Hi there, A question related to TCP-FACK, which is a default in Linux: In FACK, the holes between SACK blocks are considered as loss. To a sender, when SACK comes in, loss_out would be non-zero. According to linux-2.6.17.7/net/ipv4/tcp_input.c, function tcp_time_to_recover(), this non-zero loss_out will send the sender into "Recovery" state, in which, CWND could be reduced. In one word, it seems that, FACK would allow SACK holes to reduce CWND. However, in the paper "Congestion Control in Linux TCP", Section 3, subsection Recovery, it says that Recovery state is triggered by "sufficient amount of successive duplicate ACK", to my understand, that means 3-dup. And in Section 3, subsection Disorder, it is also mentioned, SACK cause the sender move into this state. Therefore, I suppose it means SACK holes won't reduce CWND, they merely trigger fast_retrans and fast_recover. Even in the net/ipv4/tcp_input.c file, in the large block of comment right above the function tcp_time_to_recover(), it is also mentioned, CWND should only changed by "claasic VJ rules", which again means, CWND should only changes to 3-dup (or timeout). So, which is correct? The implementation, or the document? Or most probabally, am I wrong somewhere? Thank you guys! malin - 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] Multiple IPV6 Routing Tables & Policy Routing
* YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> 2006-07-28 15:10 > Well, as you stated, the code is based on the work of MIPL, > which is being jointly developed by Helsinki University of Technology (HUT) > and USAGI/WIDE Project. Please describe this on your commit logs. > Please retain copyright information as well. Please tell me which copyright I missed? - 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: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework
* Patrick McHardy <[EMAIL PROTECTED]> 2006-07-28 01:30 > > +int fib_rules_lookup(struct fib_rules_ops *ops, struct flowi *fl, > > +int flags, struct fib_lookup_arg *arg) > > +{ > > + struct fib_rule *rule; > > + int err; > > + > > + rcu_read_lock(); > > + > > + list_for_each_entry(rule, ops->rules_list, list) { > > + if (rule->ifname[0] && (rule->ifindex != fl->iif)) > > + continue; > > ifindex may be unset even if ifname is set (in case the interface > does not exist yet). In that case it will match falsely on > locally generated packets. Then rule->ifindex would be -1 and it shouldn't match but I changed it, it makes more sense. > > +static void notify_rule_change(int event, struct fib_rule *rule, > > + struct fib_rules_ops *ops) > > +{ > > + int size = nlmsg_total_size(sizeof(struct fib_rule_hdr) + 128); > > + struct sk_buff *skb = alloc_skb(size, GFP_KERNEL); > > + > > + if (skb == NULL) > > + netlink_set_err(rtnl, 0, RTNLGRP_IPV4_RULE, ENOBUFS); > > + else if (fib_nl_fill_rule(skb, rule, 0, 0, event, 0, ops) < 0) { > > + kfree_skb(skb); > > + netlink_set_err(rtnl, 0, RTNLGRP_IPV4_RULE, EINVAL); > > + } else > > + netlink_broadcast(rtnl, skb, 0, RTNLGRP_IPV4_RULE, GFP_KERNEL); > > +} > > Shouldn't different families use different groups? Userspace > might (rightfully, I think) expect not to see anything but > IPv4 rules on RTNLGRP_IPV4_RULE. Right, I've added ops->nlgroup to fix this. Naturally I also fixed all the other issues you brought up, I have the feeling that there are more bugs, will look at the code again with some distance in a few days. - 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] Create IP100A Driver
Jesse Huang wrote: Hi John: I will try mutt or mail when i want to send next patch. Most different of ip100a.c and sundance.c are almost same only fix some bugs. The different of ip100a and ip100 is in phy. We can use one driver to support those two device, I want to know what is better for kernel: 1. Only updata sundance.c to support IP100A 2. Release ip100a.c which support ip100(sundance) to kernel 2.6.x and ask to remove sundance.c. 3. Release ip100a.c with sundance.c both to kernel 2.6.x We hope to use IP100a.c as our product driver, so 2. and 3. will better for IC Plus. But we will still follow your suggestion, if you feel 1. was better for kernel. Although it is occasionally OK to duplicate a driver, I do not see a compelling case with ip100a. The stronger case for a single codebase is won on the strengths of lower long-term maintenance costs, increased strength of review, doesn't break existing sundance driver uses, and re-use of existing testing benefits. If you feel strongly about not showing "sundance" to your users, you can always submit a one-line MODULE_ALIAS() change which permits users to load "ip100a" (really sundance.c). Using MODULE_ALIAS() seems quite reasonable, given that IC Plus appears to be taking the lead in future Sundance-like chip development. So, please resubmit as changes to the existing sundance.c. This is better for the standard Linux kernel engineering process. Thanks, Jeff - 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
r8169 driver problem with RTL8110SB chip (on iop3xx ARM board)
Hi! We're currently working on getting the Thecus n2100 supported in 2.6. http://www.thecus.com/products_over.php?cid=1&pid=1 Amongst other nice goodies, it has two on-board RTL8110SB gigabit controllers. The realtek-supplied 'r1000' driver kind of sort of works, if you don't mind the machine hanging or crashing if you unplug the cable at the wrong moment. The in-kernel 'r8169' drivers in 2.6.17 and 2.6.18-rc2 appear to work initially, but they don't actually seem to transmit any packets on the wire, nor do they receive any. Boot logs from 2.6.17 and 2.6.18-rc2 attached. Apart from the MAC address for eth1 being incorrect (boot loader bug, being worked on) there don't seem to be any strange messages or errors. It doesn't seem to be a PHY configuration issue -- with a custom program to dump the MDIO registers (is there any reason r8169 doesn't support mii-tool, by the way? will you take a patch to add that?), we get the following results, with only minor differences that shouldn't be causing this issue: r1000 1000 796d 001c c913 0de1 45e1 0007 2001 0008 45e1 0300 1007 f880 3000 0010 0060 6c00 2d40 0060 0400 2108 0018 2740 8c00 0040 0162 846c 0123 r8169 1000 796d 001c c913 0de1 45e1 0007 2001 0008 45e1 0200 1007 f880 3000 0010 0060 6c00 2c40 0060 0400 2108 0018 2740 8c00 0040 0162 846c 0123 Just wondering if you've seen this kind of behavior before before I dig into it further? I'm pretty sure the hardware is okay, since r1000 works, and the on-board SATA and UHCI/EHCI USB work fine as well. cheers, Lennert 2.6.18-rc2, r8169 = Using base address 0x00218000 and length 0x0017e3a8 Uncompressing Linux. Linux version 2.6.18-rc2 ([EMAIL PROTECTED]) (gcc version 4.0.1) #6 We6 CPU: XScale-80219 [69052e30] revision 0 (ARMv5TE), cr=397f Machine: Thecus N2100 Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT undefined 5 cache CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets Built 1 zonelists. Total pages: 32768 Kernel command line: console=ttyS0,115200 root=/dev/nfs ip=bootp mem=128M PID hash table entries: 1024 (order: 10, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total Memory: 126592KB available (2681K code, 459K data, 104K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok NET: Registered protocol family 16 PCI: bus0: Fast back to back transfers disabled SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 4096 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 4096 bind 2048) TCP reno registered NetWinder Floating Point Emulator V0.97 (double precision) Installing knfsd (copyright (C) 1996 [EMAIL PROTECTED]). JFFS2 version 2.2. (NAND) (C) 2001-2006 Red Hat, Inc. SGI XFS with ACLs, security attributes, no debug enabled io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xfe80 (irq = 0) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Intel(R) PRO/1000 Network Driver - version 7.1.9-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI e100: Copyright(c) 1999-2005 Intel Corporation r8169 Gigabit Ethernet driver 2.2LK loaded eth0: RTL8169 at 0xc8850200, 00:14:fd:10:27:72, IRQ 27 r8169 Gigabit Ethernet driver 2.2LK loaded eth1: RTL8169 at 0xc8852300, 00:14:fd:10:00:00, IRQ 28 physmap platform flash device: 0100 at f000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank Intel/Sharp Extended Query Table at 0x0031 Using buffer write method cfi_cmdset_0001: Erase suspend on write enabled cmdlinepart partition parsing not available Searching for RedBoot partition table in physmap-flash.0 at offset 0xfe 6 RedBoot partitions found on MTD device physmap-flash.0 Creating 6 MTD partitions on "physmap-flash.0": 0x-0x0004 : "RedBoot" 0x0004-0x00d4 : "ramdisk" 0x00d4-0x00ea : "kernel" 0x00ea-0x00fc : "user" 0x00fc-0x00fc1000 : "RedBoot config" 0x00fe-0x0100 : "FIS directory" mice: PS/2 mouse device common for all mice i2c /dev entries driver md: raid0 personality registered for level 0 md: raid1 personality registered for level 1 md: md driver 0.90.3 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: bitmap version 4.39 device-mapper: ioctl: 4.7.0-ioctl (2006-06-2
PATCH Fix bonding active-backup behavior for VLAN interfaces
diff -rU3 linux-2.6.17.7/net/core/dev.c linux-2.6.17.7-wapper/net/core/dev.c --- linux-2.6.17.7/net/core/dev.c 2006-07-25 05:36:01.0 +0200 +++ linux-2.6.17.7-wapper/net/core/dev.c2006-07-27 20:16:36.0 +0200 @@ -88,6 +88,7 @@ #include #include #include +#include #include #include #include @@ -1518,37 +1519,6 @@ EXPORT_SYMBOL(netif_rx_ni); -static inline struct net_device *skb_bond(struct sk_buff *skb) -{ - struct net_device *dev = skb->dev; - - if (dev->master) { - /* -* On bonding slaves other than the currently active -* slave, suppress duplicates except for 802.3ad -* ETH_P_SLOW and alb non-mcast/bcast. -*/ - if (dev->priv_flags & IFF_SLAVE_INACTIVE) { - if (dev->master->priv_flags & IFF_MASTER_ALB) { - if (skb->pkt_type != PACKET_BROADCAST && - skb->pkt_type != PACKET_MULTICAST) - goto keep; - } - - if (dev->master->priv_flags & IFF_MASTER_8023AD && - skb->protocol == __constant_htons(ETH_P_SLOW)) - goto keep; - - kfree_skb(skb); - return NULL; - } -keep: - skb->dev = dev->master; - } - - return dev; -} - static void net_tx_action(struct softirq_action *h) { struct softnet_data *sd = &__get_cpu_var(softnet_data); -- --- Christophe Devriese EURiD Network Adminstrator / Developer [EMAIL PROTECTED] http://www.eth1.org -- - 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: [RESEND 3/5] [NET]: Protocol Independant Policy Routing Rules Framework
On Fri, 2006-07-28 at 00:58 +0200, Patrick McHardy wrote: > > +int fib_rules_lookup(struct fib_rules_ops *ops, struct flowi *fl, > > +int flags, struct fib_lookup_arg *arg) > > +{ > > + struct fib_rule *rule; > > + int err; > > + > > + rcu_read_lock(); > > + > > + list_for_each_entry(rule, ops->rules_list, list) { > > Shouldn't that be list_for_each_entry_rcu? Yes that's correct, it should. > > + if (rule->ifname[0] && (rule->ifindex != fl->iif)) > > + continue; > > + > > + if (!ops->match(rule, fl, flags)) > > + continue; > > + > > + rcu_read_unlock(); > > + > > + err = ops->action(rule, fl, flags, arg); > > + if (err != -EAGAIN) { > > + fib_rule_get(rule); > > + arg->rule = rule; > > + goto out; > > + } > > + } > > + > > + err = -ENETUNREACH; > > +out: > > + rcu_read_unlock(); > > rcu_read_unlock might get called multiple times in the list iteration > and once again here. Yes, the rcu_read_unlock() in the list iteration is misplaced, it shouldn't be there. Besides the unbalanced lock/unlocks it suffers from the general issue described below As a somewhat related note, I've just digged a bit through RCU land, talked to dipankar and mckenney, and discovered that rcu_read_lock() / rcu_read_unlock() aren't strictly needed in softirqs since preempt is already disabled in softirqs. This means that you can use the result of the rcu read-side critical outside of the rcu_read_lock() / rcu_read_unlock() section. BUT this changes with the -rt kernel where softirqs are preemptable and where rcu_read_lock() / rcu_read_unlock() doesn't disable/enable preempt anymore, which means the rcu read-side critical section is also preemptable. This means that we can get preempted in the read-side critical section but the resulting grace period won't occur until rcu_read_unlock() is called, which means that using results of an read-side critical section outside of the critical section is just not going to work in softirqs in -rt kernels. I'm sure Ingo has reviewed the RCU usage in softirqs but I don't know if there's been any changes in this area after his review. -- /Martin signature.asc Description: This is a digitally signed message part
Re: Hello, We have IP100A Linux driver need to submit to 2.6.x kernel
On Fri, 2006-07-28 at 09:55 +0800, Jesse Huang wrote: > Hi Francois: > > Sorry, I don't know this patch before. IP100A is a new version of IP100 > (sundance.c). I don't know what is you suggestion of IP100A driver? Should > I... > > 1. Only updata sundance.c to support IP100A > 2. Release ip100a.c which support ip100(sundance) to kernel 2.6.x and ask to > remove sundance.c. > 3. Release ip100a.c with sundance.c both to kernel 2.6.x > > We hope to use IP100a.c as our product driver, so 2. and 3. will better for > IC Plus. But we will still follow your suggestion, if you feel 1. was better > for kernel. Hello, in general the policy for Linux is that if adding support for a new device is only minor changes to an existing driver, it is better to update this existing driver with those changes. The reason for that is that this makes it possible to share bugfixes and testing between both devices. Now there is a point where it no longer makes sense to share, for example when the devices are really very, very different. Greetings, Arjan van de Ven - 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] [IPV6] ADDRCONF: Lifetime handling fixes
In article <[EMAIL PROTECTED]> (at Fri, 28 Jul 2006 17:18:18 +0900 (JST)), YOSHIFUJI Hideaki <[EMAIL PROTECTED]> says: > In article <[EMAIL PROTECTED]> (at Fri, 28 Jul 2006 01:11:03 -0700 (PDT)), > David Miller <[EMAIL PROTECTED]> says: > > > Besides this correction, the rest of the changes look fine to me. > > I think we should get these fixes into 2.6.18, if you don't mind. > > > > So please resubmit with the correction. > > Okay. I'll do this soon. Here it is. Changesets, on top of 2.6.18-rc2, are available on branch "addr-lifetime-20060728b" at: git://git.skbuff.net/gitroot/yoshfuji/linux-2.6.18-rc2-addr-lifetime Regards, HEADLINES - [IPV6] ADDRCONF: Check payload length for IFA_LOCAL attribute in RTM_{ADD,DEL}MSG message [IPV6] ADDRCONF: Allow user-space to specify address lifetime [IPV6] ADDRCONF: Do not verify an address with infinity lifetime [IPV6] ADDRCONF: Support get operation of single address [IPV6] ADDRCONF: NLM_F_REPLACE support for RTM_NEWADDR DIFFSTAT net/ipv6/addrconf.c | 174 +-- 1 files changed, 166 insertions(+), 8 deletions(-) CHANGESETS -- commit 27fb40230b30534bdc08736d64cab179038591bc Author: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Fri Jul 28 18:12:09 2006 +0900 [IPV6] ADDRCONF: Check payload length for IFA_LOCAL attribute in RTM_{ADD,DEL}MSG message Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 2316a43..81702b9 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -2853,7 +2853,8 @@ inet6_rtm_deladdr(struct sk_buff *skb, s pfx = RTA_DATA(rta[IFA_ADDRESS-1]); } if (rta[IFA_LOCAL-1]) { - if (pfx && memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]), sizeof(*pfx))) + if (RTA_PAYLOAD(rta[IFA_LOCAL-1]) < sizeof(*pfx) || + (pfx && memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]), sizeof(*pfx return -EINVAL; pfx = RTA_DATA(rta[IFA_LOCAL-1]); } @@ -2877,7 +2878,8 @@ inet6_rtm_newaddr(struct sk_buff *skb, s pfx = RTA_DATA(rta[IFA_ADDRESS-1]); } if (rta[IFA_LOCAL-1]) { - if (pfx && memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]), sizeof(*pfx))) + if (RTA_PAYLOAD(rta[IFA_LOCAL-1]) < sizeof(*pfx) || + (pfx && memcmp(pfx, RTA_DATA(rta[IFA_LOCAL-1]), sizeof(*pfx return -EINVAL; pfx = RTA_DATA(rta[IFA_LOCAL-1]); } --- commit 336f472519a05ea493c5ad24de2c39e2c80003a0 Author: Noriaki TAKAMIYA <[EMAIL PROTECTED]> Date: Fri Jul 28 18:12:10 2006 +0900 [IPV6] ADDRCONF: Allow user-space to specify address lifetime Based on MIPL2 kernel patch. Signed-off-by: Noriaki TAKAMIYA <[EMAIL PROTECTED]> Signed-off-by: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c index 81702b9..c064188 100644 --- a/net/ipv6/addrconf.c +++ b/net/ipv6/addrconf.c @@ -1869,15 +1869,21 @@ err_exit: /* * Manual configuration of address on an interface */ -static int inet6_addr_add(int ifindex, struct in6_addr *pfx, int plen) +static int inet6_addr_add(int ifindex, struct in6_addr *pfx, int plen, + __u32 prefered_lft, __u32 valid_lft) { struct inet6_ifaddr *ifp; struct inet6_dev *idev; struct net_device *dev; + __u8 ifa_flags = 0; int scope; ASSERT_RTNL(); + /* check the lifetime */ + if (!valid_lft || prefered_lft > valid_lft) + return -EINVAL; + if ((dev = __dev_get_by_index(ifindex)) == NULL) return -ENODEV; @@ -1889,10 +1895,29 @@ static int inet6_addr_add(int ifindex, s scope = ipv6_addr_scope(pfx); - ifp = ipv6_add_addr(idev, pfx, plen, scope, IFA_F_PERMANENT); + if (valid_lft == INFINITY_LIFE_TIME) + ifa_flags |= IFA_F_PERMANENT; + else if (valid_lft >= 0x7FFF/HZ) + valid_lft = 0x7FFF/HZ; + + if (prefered_lft == 0) + ifa_flags |= IFA_F_DEPRECATED; + else if ((prefered_lft >= 0x7FFF/HZ) && +(prefered_lft != INFINITY_LIFE_TIME)) + prefered_lft = 0x7FFF/HZ; + + ifp = ipv6_add_addr(idev, pfx, plen, scope, ifa_flags); + if (!IS_ERR(ifp)) { + spin_lock(&ifp->lock); + ifp->valid_lft = valid_lft; + ifp->prefered_lft = prefered_lft; + ifp->tstamp = jiffies; + spin_unlock(&ifp->lock); + addrconf_dad_start(ifp, 0); in6_ifa_put(ifp); + addrconf_verify(0); return 0; } @@ -1945,7 +1970,8 @@ int addrconf_add_ifaddr(void __user *arg return -EFAULT; rtnl_lock(); - err = in
Re: [PATCH 1/3] add netdev_alloc_skb
On Fri, Jul 28, 2006 at 01:28:32AM -0700, David Miller wrote: > From: Christoph Hellwig <[EMAIL PROTECTED]> > Date: Fri, 28 Jul 2006 10:27:12 +0200 > > > We need a fixup patch for the existing wrong comments on dev_alloc_skb > > anyway - but if you prefer to respin the netdev_alloc_skb and have > > another patch to fixup the original comments I can do that aswell. > > I intend to, for everyone's convenience, put the addition of > netdev_alloc_skb() into 2.6.18. Here is the requested fixed up version: Index: linux-2.6/include/linux/skbuff.h === --- linux-2.6.orig/include/linux/skbuff.h 2006-07-26 13:27:07.0 +0200 +++ linux-2.6/include/linux/skbuff.h2006-07-28 10:41:00.0 +0200 @@ -1104,6 +1104,28 @@ return __dev_alloc_skb(length, GFP_ATOMIC); } +extern struct sk_buff *__netdev_alloc_skb(struct net_device *dev, + unsigned int length, gfp_t gfp_mask); + +/** + * netdev_alloc_skb - allocate an skbuff for rx on a specific device + * @dev: network device to receive on + * @length: length to allocate + * + * Allocate a new &sk_buff and assign it a usage count of one. The + * buffer has unspecified headroom built in. Users should allocate + * the headroom they think they need without accounting for the + * built in space. The built in space is used for optimisations. + * + * %NULL is returned if there is no free memory. Although this function + * allocates memory it can be called from an interrupt. + */ +static inline struct sk_buff *netdev_alloc_skb(struct net_device *dev, + unsigned int length) +{ + return __netdev_alloc_skb(dev, length, GFP_ATOMIC); +} + /** * skb_cow - copy header of skb when it is required * @skb: buffer to cow Index: linux-2.6/net/core/skbuff.c === --- linux-2.6.orig/net/core/skbuff.c2006-07-26 13:27:07.0 +0200 +++ linux-2.6/net/core/skbuff.c 2006-07-28 10:41:09.0 +0200 @@ -256,6 +256,29 @@ goto out; } +/** + * __netdev_alloc_skb - allocate an skbuff for rx on a specific device + * @dev: network device to receive on + * @length: length to allocate + * @gfp_mask: get_free_pages mask, passed to alloc_skb + * + * Allocate a new &sk_buff and assign it a usage count of one. The + * buffer has unspecified headroom built in. Users should allocate + * the headroom they think they need without accounting for the + * built in space. The built in space is used for optimisations. + * + * %NULL is returned if there is no free memory. + */ +struct sk_buff *__netdev_alloc_skb(struct net_device *dev, + unsigned int length, gfp_t gfp_mask) +{ + struct sk_buff *skb; + + skb = alloc_skb(length + NET_SKB_PAD, gfp_mask); + if (likely(skb)) + skb_reserve(skb, NET_SKB_PAD); + return skb; +} static void skb_drop_list(struct sk_buff **listp) { @@ -2042,6 +2065,7 @@ EXPORT_SYMBOL(kfree_skb); EXPORT_SYMBOL(__pskb_pull_tail); EXPORT_SYMBOL(__alloc_skb); +EXPORT_SYMBOL(__netdev_alloc_skb); EXPORT_SYMBOL(pskb_copy); EXPORT_SYMBOL(pskb_expand_head); EXPORT_SYMBOL(skb_checksum); - 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: Regarding offloading IPv6 addrconf and ndisc
> A couple of basic questions: > 1. Can we just proceed assuming it is non-secure until a later time when >the certificate path is established? This is not something which is described in the standard. In fact, processing the RA without a certificate path to the router already assumes the host is configured to so do (assuming unverified messages are treated as normal non-secure ones). Treating it as non-secure would allow an attacker to temporarily receive packets from the host if it has no secure router to be used (in the same or other interfaces). This may allow it to retrieve some of the user's info (think web-login portal) and it just has to be on-link (typical NDP attack). A solution would be not to assume it is non-secure, but instead cache or drop the RA and initiate the process to obtain a certificate path. This however does not allow the kind of behaviour that Dave described in one of is earlier e-mails, where packets are processed in order. Also, the host cache needs to hold X.509v3 certificates, and even if a lighter crypto-hash based check is available (if CGAs are used as well, to make sure the packets come from the packet's source address), hosts will end up having to perform RSA signature checks. > 2. What if user process dies? or gets overwhelmed? >One of the assumptions of the any well designed kernel is that the system > should never >hang because some user application died or waited for ever. Of course that this is a real problem. However, if the control daemon dies the kernel won't die. Depending on the implementation -- you might temporarily get out of addresses, if the addresses are flushed when the control daemon dies, etc. But, just like a routing daemon is critical to a router, this control application would also be critical to the host's connectivity. And if it dies, it needs to be restarted. The application might be itself complex, but in the end we moved this complexity away from the kernel. Hugo signature.asc Description: Digital signature
Re: [PATCH 1/3] add netdev_alloc_skb
From: Christoph Hellwig <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 10:27:12 +0200 > We need a fixup patch for the existing wrong comments on dev_alloc_skb > anyway - but if you prefer to respin the netdev_alloc_skb and have > another patch to fixup the original comments I can do that aswell. I intend to, for everyone's convenience, put the addition of netdev_alloc_skb() into 2.6.18. - 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/3] add netdev_alloc_skb
On Fri, Jul 28, 2006 at 01:24:24AM -0700, David Miller wrote: > From: Christoph Hellwig <[EMAIL PROTECTED]> > Date: Fri, 28 Jul 2006 09:08:51 +0200 > > > Yes, Joe Perches already pointed that out in private. This typo is copy > > and pasted from the dev_alloc_skb kerneldoc, so this patch fixes up all > > four occurances: > > > > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> > > Please respin your original patch with this fixup, thanks > a lot Christoph. We need a fixup patch for the existing wrong comments on dev_alloc_skb anyway - but if you prefer to respin the netdev_alloc_skb and have another patch to fixup the original comments I can do that aswell. - 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: [PATCHv2 2.6.18-rc1-mm2 1/3] net: UDP-Lite generic support
From: Gerrit Renker <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 09:19:55 +0100 > I will start with the v4-side and post a small RFC patch to see whether > I got the concepts right. (Due to vacation, this will not before mid/end > of August.) Ok, I look forward to reviewing 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: Netchannles: first stage has been completed. Further ideas.
From: Stephen Hemminger <[EMAIL PROTECTED]> Date: Thu, 27 Jul 2006 11:54:19 -0700 > I think we sell our existing stack short. I agree. > There are lots of opportunities left to look more closely at actual > real performance bottlenecks and improve incrementally. But it > requires, tools, time, faster net hardware, and some creative > insight. I guess it just isn't as cool. We are in fact suggesting some ideas that address the current stack issues along the way. Witness the discussion we had about the tcp_ack() costs wrt. pruning the retransmit queue and tagging packets for SACK, I'm working on a new data structure and layout to cure all that stuff. But I think we can do better. Jamal said to me one email, "If even only half of Van's numbers are real, this is really exciting." Rusty and Alexey are looking at the problem from another direction. Go back to the unified flow cache, implement all the hair to do that, and then we can look at netchannels because they will be so much more straight forward at that 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: [RFC] Multiple IPV6 Routing Tables & Policy Routing
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 15:10:09 +0900 (JST) > Well, as you stated, the code is based on the work of MIPL, > which is being jointly developed by Helsinki University of Technology (HUT) > and USAGI/WIDE Project. Please describe this on your commit logs. > Please retain copyright information as well. Ok. Thomas could you please respin the patches with: 1) Updated credits, based upon Yoshifuji's feedback 2) Fixes for the small issues Patrick pointer out in his review 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/3] add netdev_alloc_skb
From: Christoph Hellwig <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2006 09:08:51 +0200 > Yes, Joe Perches already pointed that out in private. This typo is copy > and pasted from the dev_alloc_skb kerneldoc, so this patch fixes up all > four occurances: > > Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]> Please respin your original patch with this fixup, thanks a lot Christoph. - 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: [PATCHv2 2.6.18-rc1-mm2 1/3] net: UDP-Lite generic support
Hi David, thank you very much for taking time to revise the code and for the detailed comments. | The amount of code duplication is absolutely enormous and | totally unnecessary. You are right. So far I thought it better to keep UDP and UDP-Lite separate but an intelligent code integration does seem the better way. | It's mostly clerical work, but it will mean that we will have one | copy of all this code and as a result we won't even need a config | option for UDP-Lite. I will start with the v4-side and post a small RFC patch to see whether I got the concepts right. (Due to vacation, this will not before mid/end of August.) Best regards Gerrit - 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] [IPV6] ADDRCONF: Lifetime handling fixes
In article <[EMAIL PROTECTED]> (at Fri, 28 Jul 2006 01:11:03 -0700 (PDT)), David Miller <[EMAIL PROTECTED]> says: > Besides this correction, the rest of the changes look fine to me. > I think we should get these fixes into 2.6.18, if you don't mind. > > So please resubmit with the correction. Okay. I'll do this soon. --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: [RFC] [IPV6] ADDRCONF: Lifetime handling fixes
From: Noriaki TAKAMIYA <[EMAIL PROTECTED]> Date: Thu, 27 Jul 2006 19:49:29 +0900 (JST) > >> Thu, 27 Jul 2006 11:28:02 +0100 > >> [Subject: Re: [RFC] [IPV6] ADDRCONF: Lifetime handling fixes] wrote... > >> Hugo Santos <[EMAIL PROTECTED]> wrote... > > > > + ifp = ipv6_get_ifaddr(pfx, dev, 1); > > > + if (ifp == NULL) > > > + return -ENOENT; > > > + > > > + if (!valid_lft || (prefered_lft > valid_lft)) > > > + return -EINVAL; > > ^^^ > > > >Unreleased ifp? This test should go before ipv6_get_ifaddr. > > That's right. Thanks. Thank you Takamiya-san. Besides this correction, the rest of the changes look fine to me. I think we should get these fixes into 2.6.18, if you don't mind. So please resubmit with the correction. Thanks again. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sunlance: fix compilation on sparc-UP
From: Alexey Dobriyan <[EMAIL PROTECTED]> Date: Thu, 27 Jul 2006 13:35:20 +0400 > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Applied, thanks Alexey. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.18-rc2-mm1
On 27/07/2006 8:56 p.m., Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.18-rc2/2.6.18-rc2-mm1/ - git-klibc has been dropped due to very bad parallel-make problems. - Added a new line to the boilerplate, below! - Added Sam's lxdialog tree, as git-lxdialog.patch. You no longer need x-ray spectacles to read the menuconfig screens. - Lots of random patches. Many of them are bugfixes and I shall, as usual, go through them all identifying 2.6.18 material. But I can miss things, so please don't be afraid to point 2.6.18 candidates out to me. I also have, as usual, a number of bugfixes agains the git trees. I'll send these to the maintainers until they stick and then I lose track of them. So don't be afraid to send reminders to the subsystem maintainers either. Still seeing breakage with the e1000/NAT. Now the problem isn't so much that the bug exists, but that unlike in -rc1-mm2, the trace scrolls over and over and over (with some variation down into it) until the kernel completely panics and the box has to be rebooted. http://www.ussg.iu.edu/hypermail/linux/kernel/0607.1/2689.html from Herbert Xu talks about the original problem. It's a regression from the previous -mm whereby the trace would print out just once. Starting Dovecot Imap: [ OK ] Starting clamd: [ OK ] Starting amavisd: BUG: warning at net/core/dev.c:1168/skb_checksum_help() Call Trace: [] show_trace+0xb5/0x324 [] dump_stack+0x15/0x1c [] skb_checksum_help+0x63/0x13b [] :iptable_nat:ip_nat_fn+0x5f/0x1d2 [] :iptable_nat:ip_nat_local_fn+0x33/0xbc [] nf_iterate+0x5a/0x9b [] nf_hook_slow+0x60/0xcd [] ip_queue_xmit+0x444/0x4c0 [] tcp_transmit_skb+0x68f/0x6cf [] __tcp_push_pending_frames+0x867/0x95a [] tcp_rcv_established+0x72c/0x7c4 [] tcp_v4_do_rcv+0x2e/0x317 [] tcp_v4_rcv+0x9fc/0xa79 [] ip_local_deliver+0x199/0x270 [] ip_rcv+0x4d3/0x52b [] netif_receive_skb+0x1eb/0x27b [] e1000_clean_rx_irq_ps+0x5c1/0x6a0 [] e1000_clean+0x325/0x45b [] net_rx_action+0x8e/0x147 [] __do_softirq+0x78/0x105 [] call_softirq+0x1e/0x28 DWARF2 unwinder stuck at call_softirq+0x1e/0x28 Leftover inexact backtrace: [] do_softirq+0x39/0xa4 [] irq_exit+0x58/0x5a [] do_IRQ+0xb4/0xbe [] ret_from_intr+0x0/0xf <1>Unable to handle kernel paging request at 8280 RIP: [] show_trace+0x2bf/0x324 PGD 203027 PUD 205027 PMD 0 Oops: [1] SMP last sysfs file: /class/net/sit0/address CPU 0 Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1 RIP: 0010:[] [] show_trace+0x2bf/0x324 RSP: :806366f0 EFLAGS: 00010206 RAX: RBX: RCX: 0004 RDX: 0010 RSI: 81003d95c840 RDI: 81003d95c140 RBP: 806367f0 R08: 0001 R09: 0001 R10: 0002 R11: 0001 R12: 8279 R13: R14: R15: 80907000 FS: 2ab5ab544860() GS:808b2000() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 8280 CR3: 29dea000 CR4: 06e0 Process imap (pid: 2127, threadinfo 810029e62000, task 81003d95c140) Stack: 806cec48 80636fc0 0001 81002c9d78f8 7f571020 810029e63f58 80636f80 0046 Call Trace: [] dump_stack+0x15/0x1c [] skb_checksum_help+0x63/0x13b [] :iptable_nat:ip_nat_fn+0x5f/0x1d2 [] :iptable_nat:ip_nat_local_fn+0x33/0xbc [] nf_iterate+0x5a/0x9b [] nf_hook_slow+0x60/0xcd [] ip_queue_xmit+0x444/0x4c0 [] tcp_transmit_skb+0x68f/0x6cf [] __tcp_push_pending_frames+0x867/0x95a [] tcp_rcv_established+0x72c/0x7c4 [] tcp_v4_do_rcv+0x2e/0x317 [] tcp_v4_rcv+0x9fc/0xa79 [] ip_local_deliver+0x199/0x270 [] ip_rcv+0x4d3/0x52b [] netif_receive_skb+0x1eb/0x27b [] e1000_clean_rx_irq_ps+0x5c1/0x6a0 [] e1000_clean+0x325/0x45b [] net_rx_action+0x8e/0x147 [] __do_softirq+0x78/0x105 [] call_softirq+0x1e/0x28 DWARF2 unwinder stuck at call_softirq+0x1e/0x28 Leftover inexact backtrace: [] do_softirq+0x39/0xa4 [] irq_exit+0x58/0x5a [] do_IRQ+0xb4/0xbe [] ret_from_intr+0x0/0xf <1>Unable to handle kernel paging request at 8280 RIP: [] show_trace+0x2bf/0x324 PGD 203027 PUD 205027 PMD 0 Oops: [2] SMP last sysfs file: /class/net/sit0/address CPU 0 Modules linked in: hidp rfcomm l2cap bluetooth ipv6 ip_gre iptable_filter iptable_nat ip_nat ip_conntrack nfnetlink iptable_mangle ip_tables binfmt_misc iTCO_wdt i2c_i801 serio_raw Pid: 2127, comm: imap Not tainted 2.6.18-rc2-mm1 #1 RIP: 0010:[] [] show_trace+0x2bf/0x324 RSP: :80636378 EFLAGS: 00010006 RAX: RBX: RCX: 880a3808 RDX:
Re: [PATCH 3/7] NetLabel: CIPSOv4 engine
From: [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 11:52:27 -0400 > + cipso_v4_cache[iter].lock = SPIN_LOCK_UNLOCKED; Please use: "spin_lock_init(&cipso_v4_cache[iter].lock);" - 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/7] NetLabel: core network changes
From: [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 11:52:26 -0400 > @@ -617,6 +618,8 @@ int inet_accept(struct socket *sock, str > > sock_graft(sk2, newsock); > > + netlbl_socket_inet_accept(sock, newsock); > + > newsock->state = SS_CONNECTED; > err = 0; > release_sock(sk2); This is only true wart I see in the patch set from my perspective. You have security_post_accept_hook(), which gets the parent and the child socket which is all the information you need, and it seems to be invoked at the correct location. So can you please hook into this location using the security level hook we already have? Just check sock->sk->sk_family is PF_INET at the top of that hook if you only want to handle ipv4 sockets, or something like that. Could this work? When preparing and argument stating why this won't work, please suggest a nicer name for this af_inet.c hook or some way to make it more generic and palatable to us. Thanks. > - case 0x86: /* Another "Commercial Security" crap. */ > + case IPOPT_CIPSO: I am sad to see this comment disappear :-) - 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/7] NetLabel: documentation
From: [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 11:52:25 -0400 > +CIPSOv4 Variables: > + > +cipso_cache_enable - BOOLEAN ... > +cipso_cache_bucket_size - INTEGER ... > +cipso_rbm_optfmt - BOOLEAN ... > +cipso_rbm_structvalid - BOOLEAN ... We need some more information for these entries. First, list the default value these sysctls will have. This is consistent with other entries in this file. If there is a compelling argument to support the default value, please mention it. Second, cipso_cache_bucket_size is still opaque, there is nothing in the description with describes the units this value is specified in, nor in fact what it really controls. Does it say how deep the hash chains of the hash table are allowed to grow to? Otherwise, what does it control and what are the consequences of using different values? - 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: [3/4] kevent: AIO, aio_sendfile() implementation.
On Thu, 2006-07-27 at 14:02 -0700, Badari Pulavarty wrote: > On Thu, 2006-07-27 at 11:44 -0700, Ulrich Drepper wrote: > > Badari Pulavarty wrote: > > > Before we spend too much time cleaning up and merging into mainline - > > > I would like an agreement that what we add is good enough for glibc > > > POSIX AIO. > > > > I haven't seen a description of the interface so far. Would be good if > > it existed. But I briefly mentioned one quirk in the interface about > > which Suparna wasn't sure whether it's implemented/implementable in the > > current interface. > > Sebastien, could you provide a description of interfaces you are > adding ? Since you did all the work, it would be appropriate for > you to do it :) > I will clean up what description I have and send it soon. Sébastien. -- - Sébastien DuguéBULL/FREC:B1-247 phone: (+33) 476 29 77 70 Bullcom: 229-7770 mailto:[EMAIL PROTECTED] Linux POSIX AIO: http://www.bullopensource.org/posix http://sourceforge.net/projects/paiol - - 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