Re: sky2: error reporting
Stephen Hemminger wrote: Try this, it limits the console output and attempts to handle more errors. Of course, I see no errors on my systems (that would make this problem too easy)... No luck, the output now freezes after: ACPI: PCI Interrupt :03:00.0[A] - Link [LNKB] - GSI 10 (level, low) - IRQ 10 sky2 v0.11 addr 0xd2efc000 irq 10 Yukon-EC (0xb6) rev 1 sky2 eth1: addr 00:11: (I removed the end of his MAC addr) Magic sysrq does nothing at this point. Daniel - 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: iproute2 - prio qdisc, fix priomap
On Mon, 2006-16-01 at 06:51 +0100, Patrick McHardy wrote: jamal wrote: On Mon, 2006-16-01 at 05:56 +0100, Patrick McHardy wrote: This is a dead horse since I ACKed the patch, but that patch is _wrong_ without the user space fix. What's wrong with this: tc qdisc add dev dummy0 root handle 1: prio bands 5 for i in $(seq 1 5); do tc filter add dev dummy0 parent 1: handle $i fw classid 1:$i done Clearly nothing in the kernel patch fixed anything for the above. [dummy by default just blackholes packets - so it doesnt matter if you have noop or fifo or red qdiscs attached on all 5 classes]. But in the case you are using some other netdevice like eth0, you oughta specify the priomap otherwise 3 of those bands are valid. ;- so in your opinion was it fine for tc to send it anyways or does tc need fixing? ;- It shouldn't use the default mapping if its known to be invalid. ;- what is invalid is to use a priomap for 3 bands when there is infact X bands - where X !=3. Would you agree? Then why bother sending a priomap at all? Lets just use the one in the kernel For the default that would be fine, but it doesn't have a seperate attribute. I believe it is easier to just do it from user space. IIIRC, at one point the default map was in the kernel and caused all sorts of issues with users. Ok Patrick, we can discuss this until the cows come home, for simplicity sake: just answer the question above if you think it is ok for tc to behave the way it does (then the debate on the patch is resolved while we can still disagree at the latte-philosophical level). i.e: tc always assumes a map to 3 queues regardless of whether you have 15 or 2. I say it should not - what says you? 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: linux networking kernel layer and STREAMS
On Mon, 2006-16-01 at 09:21 +0100, Willem de Bruijn wrote: The reason I ended up with it was purely practical and even grew out of a single-module system. Streams fitted our use-case, which is to run code in userspace, kernelspace and on the network-card. Communicating across 3 environments breaks function-calling as a viable method -- e.g., from context-switching. Ok, that does seem different and valuable. It seemed to me your motto was flexibility first, performance next thats why i suggested to use Java instead ;- (*) one problem with streams-like abstractions is that they don't fit the real world al that well. For example, IP and TCP handling cannot easily be separated, since TCP needs to look at IP headers again. In extremis you end up with 1 big functional module again. John: Have a look at the xKernel for some pros and cons of streams. I forgot to mention that before. In the meantime I'll read through the netfilter sourcecode :) I dont think you need to look at the sources. You could look at examples and usage; look at tc filter/actions 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
[PATCH] WLAN acx100: OOPS fix, KERN_xxx, misc.
Hi all (and especially Denis),
acx-20060116_misc.diff:
- fix OOPS in acx_l_rxmonitor() (wrong ndev-type setting leading to memcpy
of negative size) by reworking monitor mode type setup and adding
missing sanity checks
- rename acx1XX_ie_powermgmt_t to more correct acx1XX_ie_powersave_t
- fix format string compile warnings
- add linux/compiler.h include apparently required for __iomem define
around Linux 2.6.8
- rework eCPU init by replacing static msleep with faster, more intelligent
(hopefully) busy-wait
acx-20060116_KERN_xxx.diff (too large: gzipped):
- add proper KERN_xxx prefixes to printk() as requested recently
Note that both patches are based on acx-20060116 proper (rediffed from
acx-20060113), smallish conflicts may result; apply acx-20060116_KERN_xxx.diff
after acx-20060116_misc.diff.
Andreas Mohr
diff -urN acx-20060116.orig/acx_struct.h acx-20060116_misc/acx_struct.h
--- acx-20060116.orig/acx_struct.h 2006-01-15 12:03:38.0 +0100
+++ acx-20060116_misc/acx_struct.h 2006-01-16 14:12:04.0 +0100
@@ -1202,6 +1202,7 @@
u8 ap[ETH_ALEN]; /* The AP we want,
FF:FF:FF:FF:FF:FF is any */
u16 aid;/* The Association ID sent from
the AP / last used AID if we're an AP */
u16 mode; /* mode from iwconfig */
+ int monitor_type; /* ARPHRD_IEEE80211 or
ARPHRD_IEEE80211_PRISM */
u16 status; /* 802.11 association status */
u8 essid_active; /* specific ESSID active, or
select any? */
u8 essid_len; /* to avoid dozens of strlen()
*/
@@ -1623,7 +1624,7 @@
#define PS_OPT_TX_PSPOLL 0x02 /* send PSPoll frame to fetch waiting
frames from AP (on frame with matching AID) */
#define PS_OPT_STILL_RCV_BCASTS0x01
-typedef struct acx100_ie_powermgmt {
+typedef struct acx100_ie_powersave {
u16 type ACX_PACKED;
u16 len ACX_PACKED;
u8 wakeup_cfg ACX_PACKED;
@@ -1631,9 +1632,9 @@
u8 options ACX_PACKED;
u8 hangover_period ACX_PACKED; /* remaining wake time after Tx
MPDU w/ PS bit, in values of 1/1024 seconds */
u16 enhanced_ps_transition_time ACX_PACKED; /* rem. wake time for
Enh. PS */
-} acx100_ie_powermgmt_t;
+} acx100_ie_powersave_t;
-typedef struct acx111_ie_powermgmt {
+typedef struct acx111_ie_powersave {
u16 type ACX_PACKED;
u16 len ACX_PACKED;
u8 wakeup_cfg ACX_PACKED;
@@ -1642,7 +1643,7 @@
u8 hangover_period ACX_PACKED; /* remaining wake time after Tx
MPDU w/ PS bit, in values of 1/1024 seconds */
u32 beacon_rx_time ACX_PACKED;
u32 enhanced_ps_transition_time ACX_PACKED; /* rem. wake time for
Enh. PS */
-} acx111_ie_powermgmt_t;
+} acx111_ie_powersave_t;
/***
diff -urN acx-20060116.orig/common.c acx-20060116_misc/common.c
--- acx-20060116.orig/common.c 2006-01-15 12:38:43.0 +0100
+++ acx-20060116_misc/common.c 2006-01-16 14:22:02.0 +0100
@@ -183,7 +183,7 @@
diff -= adev-lock_time;
if (diff max_lock_time) {
where = sanitize_str(where);
- printk(max lock hold time %d CPU ticks from %s
+ printk(max lock hold time %ld CPU ticks from %s
to %s\n, diff, adev-last_lock, where);
max_lock_time = diff;
}
@@ -230,7 +230,7 @@
unsigned long diff = jiffies - adev-sem_time;
if (diff max_sem_time) {
where = sanitize_str(where);
- printk(max sem hold time %d jiffies from %s
+ printk(max sem hold time %ld jiffies from %s
to %s\n, diff, adev-last_sem, where);
max_sem_time = diff;
}
@@ -838,7 +838,7 @@
acx100_ie_len[] = {
0,
ACX100_IE_ACX_TIMER_LEN,
- sizeof(acx100_ie_powermgmt_t)-4, /* is that 6 or 8??? */
+ sizeof(acx100_ie_powersave_t)-4, /* is that 6 or 8??? */
ACX1xx_IE_QUEUE_CONFIG_LEN,
ACX100_IE_BLOCK_SIZE_LEN,
ACX1xx_IE_MEMORY_CONFIG_OPTIONS_LEN,
@@ -889,7 +889,7 @@
acx111_ie_len[] = {
0,
ACX100_IE_ACX_TIMER_LEN,
- sizeof(acx111_ie_powermgmt_t)-4,
+ sizeof(acx111_ie_powersave_t)-4,
ACX1xx_IE_QUEUE_CONFIG_LEN,
ACX100_IE_BLOCK_SIZE_LEN,
ACX1xx_IE_MEMORY_CONFIG_OPTIONS_LEN,
@@ -2156,6 +2156,7 @@
adev-listen_interval = 100;
adev-beacon_interval = DEFAULT_BEACON_INTERVAL;
adev-mode = ACX_MODE_2_STA;
+ adev-monitor_type = ARPHRD_IEEE80211_PRISM;
adev-dtim_interval = DEFAULT_DTIM_INTERVAL;
adev-msdu_lifetime
Re: wireless: recap of current issues (configuration)
On Fri, 13 Jan 2006 23:32:02 +0100, Johannes Berg wrote: IMHO there's not much point in allowing changes. I have a feeling that might create icky issues you don't want to have to tackle when the solution is easy by just not allowing it. Part of my thinking is that different virtual types have different structures associated, so changing it needs re-creating structures anyway. You are right. But it breaks compatibility with iwconfig unless we emulate 'iwconfig mode' command by deleting and adding interface. This means some events are generated, hotplug/udev gets involved etc. In the worst case it can mean that we end up with interface with a different name. And different virtual device types might even be provided by different kernel modules so you don't carry around AP mode if you don't need it. I'm not sure about your concept of softmac modules. I wrote an e-mail some time ago explaining why I don't think it is useful and I haven't got any reply. Please, could you answer that e-mail first? (See http://marc.theaimsgroup.com/?l=linux-netdevm=113404158202233w=2) Could you also explain how would you implement separate module for AP mode? How would you bind that module to the rest of ieee80211, especially in the rx path? Thanks, -- 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: wireless: recap of current issues (actions)
On Sat, 2006-01-14 at 19:56 -0500, John W. Linville wrote: Yes, someone (Johannes? Jiri?) had the beginnings of this a few days ago, but I seem to have lost the link. Could someone repost it? http://johannes.sipsolutions.net/802.11_stacks/ Someone should start a new page to collect all the info we're talking about at the moment on the netdev wiki and then also move this content there. I don't think I'll get to it in the next few days. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] fix mv643xx compilation
2.6.16 needs ip.h and in.h. linux-2.6.15/drivers/net/mv643xx_eth.c: In function `mv643xx_eth_start_xmit': linux-2.6.15/drivers/net/mv643xx_eth.c:1159: error: dereferencing pointer to incomplete type linux-2.6.15/drivers/net/mv643xx_eth.c:1161: error: dereferencing pointer to incomplete type linux-2.6.15/drivers/net/mv643xx_eth.c:1161: error: `IPPROTO_UDP' undeclared (first use in this function) linux-2.6.15/drivers/net/mv643xx_eth.c:1161: error: (Each undeclared identifier is reported only once linux-2.6.15/drivers/net/mv643xx_eth.c:1161: error: for each function it appears in.) linux-2.6.15/drivers/net/mv643xx_eth.c:1164: error: dereferencing pointer to incomplete type linux-2.6.15/drivers/net/mv643xx_eth.c:1164: error: `IPPROTO_TCP' undeclared (first use in this function) linux-2.6.15/drivers/net/mv643xx_eth.c:1222: error: dereferencing pointer to incomplete type linux-2.6.15/drivers/net/mv643xx_eth.c:1224: error: dereferencing pointer to incomplete type linux-2.6.15/drivers/net/mv643xx_eth.c:1227: error: dereferencing pointer to incomplete type Signed-off-by: Olaf Hering [EMAIL PROTECTED] drivers/net/mv643xx_eth.c |1 + 1 files changed, 1 insertion(+) Index: linux-2.6.15/drivers/net/mv643xx_eth.c === --- linux-2.6.15.orig/drivers/net/mv643xx_eth.c +++ linux-2.6.15/drivers/net/mv643xx_eth.c @@ -35,6 +35,8 @@ #include linux/tcp.h #include linux/udp.h #include linux/etherdevice.h +#include linux/in.h +#include linux/ip.h #include linux/bitops.h #include linux/delay.h -- short story of a lazy sysadmin: alias appserv=wotan - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [NETFILTER] ip6tables: remove unused definitions
[NETFILTER] ip6tables: remove unused definitions These definitions ware used for only internal use in kernel = 2.6.13, which had not introduced the unified parser of IPv6 extension header yet. Signed-off-by: Yasuyuki Kozakai [EMAIL PROTECTED] Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit de63a83ad960be726fd487ce8f8a7115ecd015d5 tree 6499aea0dd46054b92a4393b4365d8b87b602cd1 parent 396728c2753f13781973532b4074bfdb398ad675 author Yasuyuki Kozakai [EMAIL PROTECTED] Mon, 16 Jan 2006 17:46:49 +0100 committer Harald Welte [EMAIL PROTECTED] Mon, 16 Jan 2006 17:46:49 +0100 include/linux/netfilter_ipv6/ip6t_ah.h |9 - include/linux/netfilter_ipv6/ip6t_esp.h |9 - include/linux/netfilter_ipv6/ip6t_frag.h |9 - include/linux/netfilter_ipv6/ip6t_opts.h |9 - include/linux/netfilter_ipv6/ip6t_rt.h |9 - 5 files changed, 0 insertions(+), 45 deletions(-) diff --git a/include/linux/netfilter_ipv6/ip6t_ah.h b/include/linux/netfilter_ipv6/ip6t_ah.h index c4f0793..8531879 100644 --- a/include/linux/netfilter_ipv6/ip6t_ah.h +++ b/include/linux/netfilter_ipv6/ip6t_ah.h @@ -18,13 +18,4 @@ struct ip6t_ah #define IP6T_AH_INV_LEN0x02/* Invert the sense of length. */ #define IP6T_AH_INV_MASK 0x03/* All possible flags. */ -#define MASK_HOPOPTS128 -#define MASK_DSTOPTS64 -#define MASK_ROUTING32 -#define MASK_FRAGMENT 16 -#define MASK_AH 8 -#define MASK_ESP4 -#define MASK_NONE 2 -#define MASK_PROTO 1 - #endif /*_IP6T_AH_H*/ diff --git a/include/linux/netfilter_ipv6/ip6t_esp.h b/include/linux/netfilter_ipv6/ip6t_esp.h index 01142b9..a91b6ab 100644 --- a/include/linux/netfilter_ipv6/ip6t_esp.h +++ b/include/linux/netfilter_ipv6/ip6t_esp.h @@ -7,15 +7,6 @@ struct ip6t_esp u_int8_t invflags; /* Inverse flags */ }; -#define MASK_HOPOPTS128 -#define MASK_DSTOPTS64 -#define MASK_ROUTING32 -#define MASK_FRAGMENT 16 -#define MASK_AH 8 -#define MASK_ESP4 -#define MASK_NONE 2 -#define MASK_PROTO 1 - /* Values for invflags field in struct ip6t_esp. */ #define IP6T_ESP_INV_SPI 0x01/* Invert the sense of spi. */ #define IP6T_ESP_INV_MASK 0x01/* All possible flags. */ diff --git a/include/linux/netfilter_ipv6/ip6t_frag.h b/include/linux/netfilter_ipv6/ip6t_frag.h index 449a57e..66070a0 100644 --- a/include/linux/netfilter_ipv6/ip6t_frag.h +++ b/include/linux/netfilter_ipv6/ip6t_frag.h @@ -21,13 +21,4 @@ struct ip6t_frag #define IP6T_FRAG_INV_LEN 0x02/* Invert the sense of length. */ #define IP6T_FRAG_INV_MASK 0x03/* All possible flags. */ -#define MASK_HOPOPTS128 -#define MASK_DSTOPTS64 -#define MASK_ROUTING32 -#define MASK_FRAGMENT 16 -#define MASK_AH 8 -#define MASK_ESP4 -#define MASK_NONE 2 -#define MASK_PROTO 1 - #endif /*_IP6T_FRAG_H*/ diff --git a/include/linux/netfilter_ipv6/ip6t_opts.h b/include/linux/netfilter_ipv6/ip6t_opts.h index e259b62..a07e363 100644 --- a/include/linux/netfilter_ipv6/ip6t_opts.h +++ b/include/linux/netfilter_ipv6/ip6t_opts.h @@ -20,13 +20,4 @@ struct ip6t_opts #define IP6T_OPTS_INV_LEN 0x01/* Invert the sense of length. */ #define IP6T_OPTS_INV_MASK 0x01/* All possible flags. */ -#define MASK_HOPOPTS128 -#define MASK_DSTOPTS64 -#define MASK_ROUTING32 -#define MASK_FRAGMENT 16 -#define MASK_AH 8 -#define MASK_ESP4 -#define MASK_NONE 2 -#define MASK_PROTO 1 - #endif /*_IP6T_OPTS_H*/ diff --git a/include/linux/netfilter_ipv6/ip6t_rt.h b/include/linux/netfilter_ipv6/ip6t_rt.h index f1070fb..5215602 100644 --- a/include/linux/netfilter_ipv6/ip6t_rt.h +++ b/include/linux/netfilter_ipv6/ip6t_rt.h @@ -30,13 +30,4 @@ struct ip6t_rt #define IP6T_RT_INV_LEN0x04/* Invert the sense of length. */ #define IP6T_RT_INV_MASK 0x07/* All possible flags. */ -#define MASK_HOPOPTS128 -#define MASK_DSTOPTS64 -#define MASK_ROUTING32 -#define MASK_FRAGMENT 16 -#define MASK_AH 8 -#define MASK_ESP4 -#define MASK_NONE 2 -#define MASK_PROTO 1 - #endif /*_IP6T_RT_H*/ -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie - 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 3/3] [NETFILTER] ip6tables: whitespace and indent cosmetic cleanup
[NETFILTER] ip6tables: whitespace and indent cosmetic cleanup
Signed-off-by: Yasuyuki Kozakai [EMAIL PROTECTED]
Signed-off-by: Harald Welte [EMAIL PROTECTED]
---
commit 663dafd271c08d6cf69ecaa1daf34380276b9945
tree 6194991675051520a186f40f587c1a55827a5081
parent de63a83ad960be726fd487ce8f8a7115ecd015d5
author Yasuyuki Kozakai [EMAIL PROTECTED] Mon, 16 Jan 2006 17:47:39 +0100
committer Harald Welte [EMAIL PROTECTED] Mon, 16 Jan 2006 17:47:39 +0100
net/ipv6/netfilter/ip6t_dst.c| 147
net/ipv6/netfilter/ip6t_eui64.c | 64 +-
net/ipv6/netfilter/ip6t_frag.c | 153 -
net/ipv6/netfilter/ip6t_hbh.c| 147
net/ipv6/netfilter/ip6t_ipv6header.c | 79 ++---
net/ipv6/netfilter/ip6t_owner.c | 28 ++---
net/ipv6/netfilter/ip6t_rt.c | 211 ++
7 files changed, 417 insertions(+), 412 deletions(-)
diff --git a/net/ipv6/netfilter/ip6t_dst.c b/net/ipv6/netfilter/ip6t_dst.c
index 80fe826..b4c153a 100644
--- a/net/ipv6/netfilter/ip6t_dst.c
+++ b/net/ipv6/netfilter/ip6t_dst.c
@@ -36,19 +36,19 @@ MODULE_AUTHOR(Andras Kis-Szabo [EMAIL PROTECTED]
#endif
/*
- * (Type 0xC0) 6
- * 0 - ignorable
- * 1 - must drop the packet
- * 2 - send ICMP PARM PROB regardless and drop packet
- * 3 - Send ICMP if not a multicast address and drop packet
+ * (Type 0xC0) 6
+ * 0 - ignorable
+ * 1 - must drop the packet
+ * 2 - send ICMP PARM PROB regardless and drop packet
+ * 3 - Send ICMP if not a multicast address and drop packet
* (Type 0x20) 5
- * 0 - invariant
- * 1 - can change the routing
+ * 0 - invariant
+ * 1 - can change the routing
* (Type 0x1F) Type
- * 0 - Pad1 (only 1 byte!)
- * 1 - PadN LENGTH info (total length = length + 2)
- * C0 | 2 - JUMBO 4 x x x x ( 64k )
- * 5 - RTALERT 2 x x
+ * 0 - Pad1 (only 1 byte!)
+ * 1 - PadN LENGTH info (total length = length + 2)
+ * C0 | 2 - JUMBO 4 x x x x ( 64k )
+ * 5 - RTALERT 2 x x
*/
static int
@@ -60,16 +60,16 @@ match(const struct sk_buff *skb,
unsigned int protoff,
int *hotdrop)
{
- struct ipv6_opt_hdr _optsh, *oh;
- const struct ip6t_opts *optinfo = matchinfo;
- unsigned int temp;
- unsigned int ptr;
- unsigned int hdrlen = 0;
- unsigned int ret = 0;
- u8 _opttype, *tp = NULL;
- u8 _optlen, *lp = NULL;
- unsigned int optlen;
-
+ struct ipv6_opt_hdr _optsh, *oh;
+ const struct ip6t_opts *optinfo = matchinfo;
+ unsigned int temp;
+ unsigned int ptr;
+ unsigned int hdrlen = 0;
+ unsigned int ret = 0;
+ u8 _opttype, *tp = NULL;
+ u8 _optlen, *lp = NULL;
+ unsigned int optlen;
+
#if HOPBYHOP
if (ipv6_find_hdr(skb, ptr, NEXTHDR_HOP, NULL) 0)
#else
@@ -77,42 +77,41 @@ match(const struct sk_buff *skb,
#endif
return 0;
- oh = skb_header_pointer(skb, ptr, sizeof(_optsh), _optsh);
- if (oh == NULL){
- *hotdrop = 1;
- return 0;
- }
-
- hdrlen = ipv6_optlen(oh);
- if (skb-len - ptr hdrlen){
- /* Packet smaller than it's length field */
- return 0;
- }
-
- DEBUGP(IPv6 OPTS LEN %u %u , hdrlen, oh-hdrlen);
-
- DEBUGP(len %02X %04X %02X ,
- optinfo-hdrlen, hdrlen,
- (!(optinfo-flags IP6T_OPTS_LEN) ||
- ((optinfo-hdrlen == hdrlen) ^
- !!(optinfo-invflags IP6T_OPTS_INV_LEN;
-
- ret = (oh != NULL)
-
- (!(optinfo-flags IP6T_OPTS_LEN) ||
- ((optinfo-hdrlen == hdrlen) ^
- !!(optinfo-invflags IP6T_OPTS_INV_LEN)));
-
- ptr += 2;
- hdrlen -= 2;
- if ( !(optinfo-flags IP6T_OPTS_OPTS) ){
- return ret;
+ oh = skb_header_pointer(skb, ptr, sizeof(_optsh), _optsh);
+ if (oh == NULL) {
+ *hotdrop = 1;
+ return 0;
+ }
+
+ hdrlen = ipv6_optlen(oh);
+ if (skb-len - ptr hdrlen) {
+ /* Packet smaller than it's length field */
+ return 0;
+ }
+
+ DEBUGP(IPv6 OPTS LEN %u %u , hdrlen, oh-hdrlen);
+
+ DEBUGP(len %02X %04X %02X ,
+ optinfo-hdrlen, hdrlen,
+ (!(optinfo-flags IP6T_OPTS_LEN) ||
+ ((optinfo-hdrlen == hdrlen) ^
+!!(optinfo-invflags IP6T_OPTS_INV_LEN;
+
+ ret = (oh != NULL)
+ (!(optinfo-flags IP6T_OPTS_LEN) ||
+ ((optinfo-hdrlen == hdrlen) ^
+ !!(optinfo-invflags IP6T_OPTS_INV_LEN)));
+
+ ptr += 2;
+ hdrlen
[PATCH 1/3] [NETFILTER] Makefile cleanup
[NETFILTER] Makefile cleanup These are replaced with x_tables matches and no longer exist. Signed-off-by: Yasuyuki Kozakai [EMAIL PROTECTED] Signed-off-by: Harald Welte [EMAIL PROTECTED] --- commit 396728c2753f13781973532b4074bfdb398ad675 tree cefbd947576c9ec4511153242109a6566079ebdf parent 78dbb647a1b797fcda30a65557ca21b3b73ee097 author Yasuyuki Kozakai [EMAIL PROTECTED] Mon, 16 Jan 2006 17:45:12 +0100 committer Harald Welte [EMAIL PROTECTED] Mon, 16 Jan 2006 17:45:12 +0100 net/ipv4/netfilter/Makefile |1 - net/ipv6/netfilter/Makefile |1 - 2 files changed, 0 insertions(+), 2 deletions(-) diff --git a/net/ipv4/netfilter/Makefile b/net/ipv4/netfilter/Makefile index bcefe64..e5c5b32 100644 --- a/net/ipv4/netfilter/Makefile +++ b/net/ipv4/netfilter/Makefile @@ -46,7 +46,6 @@ obj-$(CONFIG_IP_NF_NAT) += iptable_nat.o obj-$(CONFIG_IP_NF_RAW) += iptable_raw.o # matches -obj-$(CONFIG_IP_NF_MATCH_HELPER) += ipt_helper.o obj-$(CONFIG_IP_NF_MATCH_HASHLIMIT) += ipt_hashlimit.o obj-$(CONFIG_IP_NF_MATCH_IPRANGE) += ipt_iprange.o obj-$(CONFIG_IP_NF_MATCH_MULTIPORT) += ipt_multiport.o diff --git a/net/ipv6/netfilter/Makefile b/net/ipv6/netfilter/Makefile index 663b474..db6073c 100644 --- a/net/ipv6/netfilter/Makefile +++ b/net/ipv6/netfilter/Makefile @@ -4,7 +4,6 @@ # Link order matters here. obj-$(CONFIG_IP6_NF_IPTABLES) += ip6_tables.o -obj-$(CONFIG_IP6_NF_MATCH_LENGTH) += ip6t_length.o obj-$(CONFIG_IP6_NF_MATCH_RT) += ip6t_rt.o obj-$(CONFIG_IP6_NF_MATCH_OPTS) += ip6t_hbh.o ip6t_dst.o obj-$(CONFIG_IP6_NF_MATCH_IPV6HEADER) += ip6t_ipv6header.o -- - Harald Welte [EMAIL PROTECTED] http://netfilter.org/ Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed.-- Paul Vixie - 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: wireless: recap of current issues (configuration)
On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote: Regarding 802.11d and regulatory domains, the stack should also be able to stick to one regulatory domain if asked so by userspace, whatever the APs around tell us. ...and in doing so, violate the local regulatory constraints. :) Although I believe 802.11d specifies that the 802.11d beacons should trump whatever the user specifies. (of course, 802.11d doesn't say what to do when there are APs out there that disagree...) While I feel it should be *posisble* to do so, the default should be to query the hardware for its factory default, and go with that. Allowing the user to change the regulatory domain at will.. is a rather fuzzy legal area, to say the least. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpDp0Oue64XB.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote: The above is a great synopsis but there is more. For example to support roaming (and sometimes for ap operation) you want to do background scanning; this ties in to power save mode if operating as a station. Opportunistic roaming is one of those things that has many knobs to twiddle, and depends a lot on the needs of the users. But we're not actually in powersave mode -- the 802.11 stack can spit out the NULL frames to tell the AP to buffer traffic for us. This is trivial to do. Scans should be specified as non-distruptive so the hardware driver has to twiddle whatever bits are necessary to return the hardware to the same state that it was in before the scan kicked in. Beyond that, the scanning smarts are all in the 802.11 stack. The driver should be as dumb as possible. :) Background scanning, yes -- but there are all sorts of different thresholds and types of 'scanning' to be done, depending on how disruptive you are willing to be, and how capable the hardware is. Most thin MACs don't filter out foreign BSSIDs on the same channel when you're joined, which makes some things a lot easier. Further you want to order your channel list to hit the most likely channels first in case you are scanning for a specific ap--e.g. so you can stop the foreground scan and start to associate. With my scenarios, the driver performs the sweep in the order it was given -- if the hardware supports it, naturally. In terms of beacon miss processing some parts have a hardware beacon miss interrupt based on missed consecutive beacons but others require you to detect beacon miss in software. Other times you need s/w bmiss detection because you're doing something like build a repeater when the station virtual device can't depend on the hardware to deliver a bmiss interrupt. Of course. The stack is going to need a set of timers regardless of the hardware's capabilities, but having (sane) hardware beacon miss detection capabilities makes it a bit more robust. Scanning (and roaming) is really a big can 'o worms. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpAD1yPYoAut.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote: I really don't see why a plain STA mode card should be required to carry around all the code required for AP operation -- handling associations of clients, powersave management wrt. buffering, ... Sure, fragmentation From the perspective of the hardware driver, there is little AP or STA-specific code, especially when IBSS is thrown in. Thick MACs excepted, there's little more than frame tx/rx, and hardware control twiddling. The AP/STA smarts happen in the 802.11 stack. And, speaking from experience, it is very hard to separate them cleanly, at least not without incurring even more overall complexity and bloat. It's far simpler to build them intertwined, then add a bunch of #ifdefs if you want to disable AP or STA mode individually to save space. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgp5uPDYtJwb5.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote: The above is a great synopsis but there is more. For example to support roaming (and sometimes for ap operation) you want to do background scanning; this ties in to power save mode if operating as a station. Opportunistic roaming is one of those things that has many knobs to twiddle, and depends a lot on the needs of the users. But we're not actually in powersave mode -- the 802.11 stack can spit out the NULL frames to tell the AP to buffer traffic for us. This is trivial to do. The way you implement bg scanning is to notify the ap you are going into power save mode before you leave the channel (in sta mode). Hence bg scanning and power save operation interact. Scans should be specified as non-distruptive so the hardware driver has to twiddle whatever bits are necessary to return the hardware to the same state that it was in before the scan kicked in. Beyond that, the scanning smarts are all in the 802.11 stack. The driver should be as dumb as possible. :) See above. Doing bg scanning well is a balancing act and restoring hardware state is the least of your worries (hopefully); e.g. what's the right thing to do when you get a frame to transmit while off-channel scanning, how often should you return to the bss channel? Background scanning, yes -- but there are all sorts of different thresholds and types of 'scanning' to be done, depending on how disruptive you are willing to be, and how capable the hardware is. Most thin MACs don't filter out foreign BSSIDs on the same channel when you're joined, which makes some things a lot easier. Er, you need to listen to at least beacons from other ap's if you're in 11g so you can detect overlapping bss and enable protection. There are other ways to handle this but that's one. Further you want to order your channel list to hit the most likely channels first in case you are scanning for a specific ap--e.g. so you can stop the foreground scan and start to associate. With my scenarios, the driver performs the sweep in the order it was given -- if the hardware supports it, naturally. Channel ordering is useful no matter who specifies it. If you offload the ordering to the upper layers then they need to be aware of the regdomain constraints. Probably not a big deal but then you need to synchronize info between layers or export it. And there's other regdomain-related info that may want to be considered such as max txpower. I'm just saying if you want to do a good job there's lots of work here. In terms of beacon miss processing some parts have a hardware beacon miss interrupt based on missed consecutive beacons but others require you to detect beacon miss in software. Other times you need s/w bmiss detection because you're doing something like build a repeater when the station virtual device can't depend on the hardware to deliver a bmiss interrupt. Of course. The stack is going to need a set of timers regardless of the hardware's capabilities, but having (sane) hardware beacon miss detection capabilities makes it a bit more robust. Scanning (and roaming) is really a big can 'o worms. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. I don't recall seeing well-developed scanning code in either of the proposed stacks. Sam - 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote: I really don't see why a plain STA mode card should be required to carry around all the code required for AP operation -- handling associations of clients, powersave management wrt. buffering, ... Sure, fragmentation From the perspective of the hardware driver, there is little AP or STA-specific code, especially when IBSS is thrown in. Thick MACs excepted, there's little more than frame tx/rx, and hardware control twiddling. The AP/STA smarts happen in the 802.11 stack. And, speaking from experience, it is very hard to separate them cleanly, at least not without incurring even more overall complexity and bloat. It's far simpler to build them intertwined, then add a bunch of #ifdefs if you want to disable AP or STA mode individually to save space. Perhaps you haven't hit some of the more recent standards that place more of a burden on the ap implementation? Also some vendor-specific protocol features suck up space for ap mode only and it is nice to be able to include them only as needed. There are several advantages to splitting up the code such as reduced audit complexity and real space savings but I agree that it is an open question whethere there's a big gain to modularizing the code by operating mode. Sam - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote: On Mon, 16 Jan 2006, ext Stuffed Crust wrote: On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote: Regarding 802.11d and regulatory domains, the stack should also be able to stick to one regulatory domain if asked so by userspace, whatever the APs around tell us. ...and in doing so, violate the local regulatory constraints. :) The other option is to conform to whatever the AP you associate with advertises. In fact, this is how it should be done according to 802.11d. Unfortunately, this doesn't ensure local regulatory constraints compliance unless you expect each and every APs to do the Right Thing ;-) If regulators come down on someone, it seems like common sense that they would be more lenient on mobile stations complying with a misconfigured AP than they would be with a mobile station ignoring a properly configured AP? I know expecting common sense from government regulators is optimistic, but still... :-) Of course when we are the AP, the ability to adjust these parameters could be very important. No? 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote: The way you implement bg scanning is to notify the ap you are going into power save mode before you leave the channel (in sta mode). Hence bg scanning and power save operation interact. That is not powersave operation -- that is telling the AP we are going into powersave, but not actually going into powersave -- Actual powersave operation would need to be disabled if we go into a scan, as we need to have the rx path powered up and ready to hear anything out there for the full channel dwell time. See above. Doing bg scanning well is a balancing act and restoring hardware state is the least of your worries (hopefully); e.g. what's the right thing to do when you get a frame to transmit while off-channel scanning, how often should you return to the bss channel? Disallow all other transmits (either by failing them altogether, or by buffering them up, which I think is better) while performing the scan. If we are (continually) scanning because we don't have an association, then we shouldn't be allowing any traffic through the stack anyway. At the end of each scan pass, you return to the original channel, then return scan complete to the stack/userspace. at this point any pending transmits can go out, and if another scan pass is desired, it will happen then. Er, you need to listen to at least beacons from other ap's if you're in 11g so you can detect overlapping bss and enable protection. There are other ways to handle this but that's one. If you can't hear the traffic, then it doesn't count for purposes of ER protection -- but that said, this only matters for AP operation, so APs shouldn't filter out anyone else's becacons. STAs should respect the use ER Protection bit in the AP's beacon, so can filter out traffic that doesn't match the configured BSSID. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. I don't recall seeing well-developed scanning code in either of the proposed stacks. I've only looked into the pre-2.6-merged HostAP stack, so I can't comment on what's publically available. I'll have a look at the GPL'ed DeviceScape stack when I have more time. Most of what I've going on about is derived from my experience from commercial 802.11 work I've done over the past few years. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpftRIsaAE60.pgp Description: PGP signature
Re: [patch] 3c59x: improve usage of netif_carrier_{on,off}
On Fri, 2006-01-13 at 18:09 +0100, Steffen Klassert wrote:
...
I still have a patch in queue to improve usage of netif_carrier_{on,off}
but I had no possibility to test yet, so I did not send.
I'd be happy to test it out if you'd like.
Dan
Hi Dan,
here is the patch for testing.
The patch _should_ do the following:
1. Set the polling intervall for media changes to 5 seconds if link is down
and 60 seconds if link is up.
2. Handle netif_carrier_{on,of} and check for media changes in
proper way by using mii_check_media() in the mii case.
3. Handle netif_carrier_{on,of} also if media is forced to 10baseT/100baseTx.
4. Use ethtool_op_get_link instead of vortex_get_link.
So it is possible to test with ethtool.
The patch appears to work correctly and does notice links quite a bit
sooner. The only issue I noticed was that if no cable is plugged in, it
starts off with the carrier on (/sys/class/net/eth0/carrier == 1) but
a second later switches the carrier off. How do I track that down?
Dan
-
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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 09:07:52PM +0200, Samuel Ortiz wrote: That is true, thin MACs usually don't filter beacons on the same channel. But in some cases (mainly power saving), you really want to avoid receiving useless beacons and having the host woken up for each of them. You may even want to not receive all the useful ones (the ones coming from the AP you're joined with) if your softmac allows that. BSSID filtering doesn't matter as far as 802.11 powersave is concerned -- the power savings come from disabling the RF/BBP components. In other words, you can't receive or transmit traffic. If you're respecting the AP's beacon interval/DTIM settings, you only wake up every couple of beacon intervals and listen for a beacon. IF there's traffic waiting for you, then you wake up your transmitter, send out a PSPOLL (or NULL/PSEnd) frame, get your traffic, then go back to sleep again. You may hear another beacon when the STA is awake, you may not. BSSID filtering has nothing to do with 802.11 power save, but rather is intented to reduce the host load (interrupts, processing overhead) and thus the host power consumption. This kind of beacon filtering is a big power saver, which is one of the most important requirement for some platforms (phones, PDA, etc...). You need to be clear if you're talking about 802.11 powersave, versus power savings stemming from reducing the load on the host system, which is where BSSID filtering is beneficial. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpCscV5MHtpv.pgp Description: PGP signature
[patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
Printing the total number of sockets used in /proc/net/sockstat is out
of place in a file that is supposed to contain information related to
ipv4 sockets. Removed output for total socket usage.
Signed-off-by: Andy Gospodarek [EMAIL PROTECTED]
---
proc.c |1 -
1 files changed, 1 deletion(-)
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -60,7 +60,6 @@ static int fold_prot_inuse(struct proto
*/
static int sockstat_seq_show(struct seq_file *seq, void *v)
{
- socket_seq_show(seq);
seq_printf(seq, TCP: inuse %d orphan %d tw %d alloc %d mem %d\n,
fold_prot_inuse(tcp_prot), atomic_read(tcp_orphan_count),
tcp_death_row.tw_count, atomic_read(tcp_sockets_allocated),
-
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] networking ipv4: remove total socket usage count from /proc/net/sockstat
On Mon, 2006-01-16 at 15:04 -0500, Andy Gospodarek wrote: Printing the total number of sockets used in /proc/net/sockstat is out of place in a file that is supposed to contain information related to ipv4 sockets. Removed output for total socket usage. Um, you can't do that, it will break userspace. Lee - 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: wireless: recap of current issues (configuration)
On Mon, 16 Jan 2006, ext Stuffed Crust wrote: You may hear another beacon when the STA is awake, you may not. BSSID filtering has nothing to do with 802.11 power save, but rather is intented to reduce the host load (interrupts, processing overhead) and thus the host power consumption. I know that and I know a bit about 802.11 PS as well. I was talking about host powersaving, not 802.11. Sorry for the confusion. What I meant is that having an 802.11 stack capable of living with less than a beacon every couple of beacon intervals would be nice as well. Cheers, Samuel. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote: The way you implement bg scanning is to notify the ap you are going into power save mode before you leave the channel (in sta mode). Hence bg scanning and power save operation interact. That is not powersave operation -- that is telling the AP we are going into powersave, but not actually going into powersave -- Actual powersave operation would need to be disabled if we go into a scan, as we need to have the rx path powered up and ready to hear anything out there for the full channel dwell time. Please read what I wrote again. Station mode power save work involves communicating with the ap and managing the hardware. The first interacts with bg scanning. We haven't even talked about how to handle sta mode power save. See above. Doing bg scanning well is a balancing act and restoring hardware state is the least of your worries (hopefully); e.g. what's the right thing to do when you get a frame to transmit while off-channel scanning, how often should you return to the bss channel? Disallow all other transmits (either by failing them altogether, or by buffering them up, which I think is better) while performing the scan. Not necessarily in my experience. If we are (continually) scanning because we don't have an association, then we shouldn't be allowing any traffic through the stack anyway. If you do not have an association you are not doing bg scanning. At the end of each scan pass, you return to the original channel, then return scan complete to the stack/userspace. at this point any pending transmits can go out, and if another scan pass is desired, it will happen then. If you wait until the end of the scan to return to the bss channel then you potentially miss buffered mcast frames. You can up the station's listen interval but that only gets you so far. As I said there are tradeoffs in doing this. Er, you need to listen to at least beacons from other ap's if you're in 11g so you can detect overlapping bss and enable protection. There are other ways to handle this but that's one. If you can't hear the traffic, then it doesn't count for purposes of ER protection -- but that said, this only matters for AP operation, so APs shouldn't filter out anyone else's becacons. STAs should respect the use ER Protection bit in the AP's beacon, so can filter out traffic that doesn't match the configured BSSID. Sorry I meant this was needed for ap operation. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. I don't recall seeing well-developed scanning code in either of the proposed stacks. I've only looked into the pre-2.6-merged HostAP stack, so I can't comment on what's publically available. I'll have a look at the GPL'ed DeviceScape stack when I have more time. Most of what I've going on about is derived from my experience from commercial 802.11 work I've done over the past few years. Ditto. Sam - 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: wireless: recap of current issues (configuration)
On Mon, 16 Jan 2006, ext John W. Linville wrote: On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote: On Mon, 16 Jan 2006, ext Stuffed Crust wrote: On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote: Regarding 802.11d and regulatory domains, the stack should also be able to stick to one regulatory domain if asked so by userspace, whatever the APs around tell us. ...and in doing so, violate the local regulatory constraints. :) The other option is to conform to whatever the AP you associate with advertises. In fact, this is how it should be done according to 802.11d. Unfortunately, this doesn't ensure local regulatory constraints compliance unless you expect each and every APs to do the Right Thing ;-) If regulators come down on someone, it seems like common sense that they would be more lenient on mobile stations complying with a misconfigured AP than they would be with a mobile station ignoring a properly configured AP? I know expecting common sense from government regulators is optimistic, but still... :-) Well, I'd rather trust a governement regulated network than my neighbour's AP ;-) In fact, some phones set their 802.11 regulatory domain based on the information they received from a somehow government regulated network, e.g. a GSM one. Cheers, Samuel. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
On 1/16/06, Andy Gospodarek [EMAIL PROTECTED] wrote: What userspace app will break because of this? On 1/16/06, Lee Revell [EMAIL PROTECTED] wrote: On Mon, 2006-01-16 at 15:04 -0500, Andy Gospodarek wrote: Printing the total number of sockets used in /proc/net/sockstat is out of place in a file that is supposed to contain information related to ipv4 sockets. Removed output for total socket usage. Um, you can't do that, it will break userspace. That's not the point. The point is you can't go around changing things exported to usersace - that has the potential to break apps. Even if no app is known to the people on this list there may still be apps out there depending on it - and we don't break userspace without *very* good reasons, and even then it's announced for several months (years sometimes) in Documentation/feature-removal.txt and elsewhere. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
Jesper, Thanks for the explanation. Your reasoning makes sense. I will consider other ways to solve my current problem and post a patch that doesn't break userspace if necessary. -andy On 1/16/06, Jesper Juhl [EMAIL PROTECTED] wrote: On 1/16/06, Andy Gospodarek [EMAIL PROTECTED] wrote: What userspace app will break because of this? On 1/16/06, Lee Revell [EMAIL PROTECTED] wrote: On Mon, 2006-01-16 at 15:04 -0500, Andy Gospodarek wrote: Printing the total number of sockets used in /proc/net/sockstat is out of place in a file that is supposed to contain information related to ipv4 sockets. Removed output for total socket usage. Um, you can't do that, it will break userspace. That's not the point. The point is you can't go around changing things exported to usersace - that has the potential to break apps. Even if no app is known to the people on this list there may still be apps out there depending on it - and we don't break userspace without *very* good reasons, and even then it's announced for several months (years sometimes) in Documentation/feature-removal.txt and elsewhere. -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 12:14:08PM -0800, Sam Leffler wrote: Please read what I wrote again. Station mode power save work involves communicating with the ap and managing the hardware. The first interacts with bg scanning. We haven't even talked about how to handle sta mode power save. I think we're arguing over semantics; what's important here is that the STA tells the AP to buffer frames while we're performing a scan, correct? If you wait until the end of the scan to return to the bss channel then you potentially miss buffered mcast frames. You can up the station's listen interval but that only gets you so far. As I said there are tradeoffs in doing this. An excellent point. This is particularly relevant for APs that have a DTIM interval of 1 -- if you're doing a passive scan, the dwell time on that other channel (you need at least one beacon interval) could cause you to miss bufferend MCAST frames. In all fairness I don't think I've seen any implementations that handle this cleanly. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpC0Fzdhpy7E.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 10:16:06PM +0200, Samuel Ortiz wrote: Well, I'd rather trust a governement regulated network than my neighbour's AP ;-) In fact, some phones set their 802.11 regulatory domain based on the information they received from a somehow government regulated network, e.g. a GSM one. The asumption is that 802.11d information, like current regdomain settings, is fixed and not user-configurable. If the regdomain is changeable by the user, that unit would not be approved for sale in that particular locale. (Now 802.11d doesn't specify what to do when you hear two conflicting 802.11d beacons there go those assumptions again..) Stations respecting 802.11d rules are not allowed to transmit on any supported frequency until they hear an AP on that frequency first. This essentially means that all scans are passive until we hear an AP, and we can't transmit on any other (presumably still silent) frequencies unless we hear an 802.11d beacon that says we can. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpVn6NjQ023S.pgp Description: PGP signature
Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
On 1/16/06, Andy Gospodarek [EMAIL PROTECTED] wrote: [could you *please* not top post? It's pretty annoying] Jesper, Thanks for the explanation. Your reasoning makes sense. I will I'm glad you found it useful. consider other ways to solve my current problem and post a patch that doesn't break userspace if necessary. Maybe if you described your current problem someone could suggest a solution... -- Jesper Juhl [EMAIL PROTECTED] Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [TRIVIAL] prism54/islpci_eth.c: dev_kfree_skb in irq context
On Wed, Jan 04, 2006 at 09:33:27AM +1030, Graham Gower wrote: On 03/01/06, Patrick McHardy [EMAIL PROTECTED] wrote: Graham Gower wrote: My logs were starting to fill with messages exatcly like that mentioned here: http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=2840 In any event, the patch at the end of that link was never applied (it doesn't fix the other call to dev_kfree_skb). After applying my patch, I've not had any more messages in the logs. The patch has been applied to 2.6.15-rc. Only the first hunk of your patch is still required, but it doesn't apply anymore. Can you send a new patch against 2.6.15 please? Ok, here's a new one. Hope I got it right this time. Signed-off-by: Graham Gower [EMAIL PROTECTED] --- linux-2.6.15/drivers/net/wireless/prism54/islpci_eth.c.orig +++ linux-2.6.15/drivers/net/wireless/prism54/islpci_eth.c @@ -177,7 +177,7 @@ #endif newskb-dev = skb-dev; - dev_kfree_skb(skb); + dev_kfree_skb_irq(skb); skb = newskb; } } - I'm planning to apply this patch with the following changelog commentary: [PATCH] prism54/islpci_eth.c: dev_kfree_skb used with interrupts disabled dev_kfree_skb should not be used with interrupts disabled. Change to use dev_kfree_skb_irq instead. Is that alright w/ everyone? 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: wireless: recap of current issues (configuration)
On Llu, 2006-01-16 at 14:06 -0500, John W. Linville wrote: If regulators come down on someone, it seems like common sense that they would be more lenient on mobile stations complying with a misconfigured AP than they would be with a mobile station ignoring a properly configured AP? I know expecting common sense from government regulators is optimistic, but still... :-) I can't guess on the subject of US regulators but for the UK experience in other communities (eg amateur radio), and public statements indicate that their high priorities are interference with emergency services and the like. Concerns of direct relevance are - transmitting on unlicensed frequencies (and 802.11 channel allocations are dependant on nation - even within the EU) - power violation - anything else causing interference to other legitimate users at a radio level I would expect equipment to honour the subset of configurations that meet BOTH the regulatory domain the system believes it exists within (which may change dynamically!) AND the AP advertisement. If I have told my equipment to obey UK law I expect it to do so. If I hop on the train to France and forget to revise my configuration I'd prefer it also believed the APs Alan - 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] networking ipv4: remove total socket usage count from /proc/net/sockstat
On 1/16/06, Jesper Juhl [EMAIL PROTECTED] wrote: Maybe if you described your current problem someone could suggest a solution... Sure, I'd be glad to. If I add up all the entries from the procfiles (in /proc/net) on my system packet = 1 netlink = 6 raw = 0 raw6 = 0 tcp = 5 tcp6 = 3 udp = 9 udp6 = 1 unix = 29 I find there are a total of 54 sockets open on my system. Now this seems to differ from the value in /proc/net/sockstat: # cat sockstat sockets: used 59 TCP: inuse 5 orphan 0 tw 0 alloc 8 mem 1 UDP: inuse 9 RAW: inuse 0 FRAG: inuse 0 memory 0 So we are off by 5. I added some code around the stat collection used in sockstat to get more detailed info about those sockets and the output is here. The values are family[protocol family][socket family]. family[1][1] = 17(UNIX/LOCAL,STREAM) family[1][2] = 12(UNIX/LOCAL,DGRAM) family[2][1] = 5 (INET,STREAM) family[2][2] = 9 (INET,DGRAM) family[2][3] = 2 (INET,RAW) family[10][1] = 3(INET6,STREAM) family[10][2] = 1(INET6,DGRAM) family[10][3] = 3(INET6,RAW) family[16][2] = 6(NETLINK/ROUTE,DGRAM) family[17][10] = 1 (PACKET,PACKET) Total = 59 All of these numbers match up with what we saw above, except the INET/RAW and INET6/RAW sockets. It seems they aren't being counted correctly -- which accounts for the 5 missing sockets. The decrementing of these values is in sock_release() and seems to get done correctly other times RAW sockets are created, but not for the 5 sockets in question. Since the total socket usage seems out of place in that file -- and quite possibly wrong, it seemed like a nice idea to get rid of it (prior to understanding the reasoning behind keeping it). Now it seems the goal will be to fix the discrepancy between these files. -andy - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] LSM-IPsec SELinux Authorize
This patch contains a fix for the previous patch that adds security
contexts to IPsec policies and security associations. In the previous
patch, no authorization (besides the check for write permissions to
SAD and SPD) is required to delete IPsec policies and security
assocations with security contexts. Thus a user authorized to change
SAD and SPD can bypass the IPsec policy authorization by simply
deleteing policies with security contexts. To fix this security hole,
an additional authorization check is added for removing security
policies and security associations with security contexts.
Note that if no security context is supplied on add or present on
policy to be deleted, the SELinux module allows the change
unconditionally. The hook is called on deletion when no context is
present, which we may want to change. At present, I left it up to the
module.
LSM changes:
The patch adds two new LSM hooks: xfrm_policy_delete and
xfrm_state_delete. The new hooks are necessary to authorize deletion
of IPsec policies that have security contexts. The existing hooks
xfrm_policy_free and xfrm_state_free lack the context to do the
authorization, so I decided to split authorization of deletion and
memory management of security data, as is typical in the LSM
interface.
Use:
The new delete hooks are checked when xfrm_policy or xfrm_state are
deleted by either the xfrm_user interface (xfrm_get_policy,
xfrm_del_sa) or the pfkey interface (pfkey_spddelete, pfkey_delete).
Note that the line that adds a free to xfrm_add_policy addresses a
memory leak. The security context must be freed when the insertion
fails also.
SELinux changes:
The new policy_delete and state_delete functions are added.
Signed-off-by: Trent Jaeger [EMAIL PROTECTED]
---
include/linux/security.h| 40
+--
net/key/af_key.c|5
net/xfrm/xfrm_user.c|6 +
security/dummy.c| 12 +++
security/selinux/hooks.c|2 +
security/selinux/include/xfrm.h |2 +
security/selinux/xfrm.c | 41
7 files changed, 98 insertions(+), 10 deletions(-)
diff -puN include/linux/security.h~lsm-labels-nethooks
include/linux/security.h
--- linux-2.6.15-mm3/include/linux/security.h~lsm-labels-nethooks
2006-01-13 16:00:39.0 -0500
+++ linux-2.6.15-mm3-cxzhang/include/linux/security.h2006-01-13
18:35:28.0 -0500
@@ -805,31 +805,37 @@ struct swap_info_struct;
*used by the XFRM system.
*@sec_ctx contains the security context information being provided by
*the user-level policy update program (e.g., setkey).
- *Allocate a security structure to the xp-selector.security field.
+ *Allocate a security structure to the xp-security field.
*The security field is initialized to NULL when the xfrm_policy is
*allocated.
*Return 0 if operation was successful (memory to allocate, legal
context)
* @xfrm_policy_clone_security:
*@old contains an existing xfrm_policy in the SPD.
*@new contains a new xfrm_policy being cloned from old.
- *Allocate a security structure to the new-selector.security field
- *that contains the information from the old-selector.security field.
+ *Allocate a security structure to the new-security field
+ *that contains the information from the old-security field.
*Return 0 if operation was successful (memory to allocate).
* @xfrm_policy_free_security:
*@xp contains the xfrm_policy
- *Deallocate xp-selector.security.
+ *Deallocate xp-security.
+ * @xfrm_policy_delete_security:
+ *@xp contains the xfrm_policy
+ *Authorize deleteion of xp-security.
* @xfrm_state_alloc_security:
*@x contains the xfrm_state being added to the Security Association
*Database by the XFRM system.
*@sec_ctx contains the security context information being provided by
*the user-level SA generation program (e.g., setkey or racoon).
- *Allocate a security structure to the x-sel.security field. The
+ *Allocate a security structure to the x-security field. The
*security field is initialized to NULL when the xfrm_state is
*allocated.
*Return 0 if operation was successful (memory to allocate, legal
context).
* @xfrm_state_free_security:
*@x contains the xfrm_state.
- *Deallocate xsel.security.
+ *Deallocate x-security.
+ * @xfrm_state_delete_security:
+ *@x contains the xfrm_state.
+ *Authorize deleteion of x-security.
* @xfrm_policy_lookup:
*@xp contains the xfrm_policy for which the access control is being
*checked.
@@ -1303,8 +1309,10 @@ struct security_operations {
int (*xfrm_policy_alloc_security) (struct xfrm_policy *xp, struct
xfrm_user_sec_ctx *sec_ctx);
int (*xfrm_policy_clone_security) (struct xfrm_policy *old, struct
xfrm_policy *new);
void (*xfrm_policy_free_security) (struct xfrm_policy *xp);
+int
Re: [patch] 3c59x: improve usage of netif_carrier_{on,off}
On Mon, Jan 16, 2006 at 02:43:30PM -0500, Dan Williams wrote: ... The patch appears to work correctly and does notice links quite a bit sooner. The only issue I noticed was that if no cable is plugged in, it starts off with the carrier on (/sys/class/net/eth0/carrier == 1) but a second later switches the carrier off. How do I track that down? Dan The patch should not affect the set up of the NIC that early. vortex_up() calls netif_carrier_off() before the patch interfere. Perhaps you can see this behavior before the old status is cleared by reading MII_BMSR register. How is it without the patch? Steffen - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote: I would expect equipment to honour the subset of configurations that meet BOTH the regulatory domain the system believes it exists within (which may change dynamically!) AND the AP advertisement. If I have told my equipment to obey UK law I expect it to do so. If I hop on the train to France and forget to revise my configuration I'd prefer it also believed the APs Yes, this is an excellent point. I suppose this could result in a non-functional configuration, but that is probably better than conflicting w/ the local authorities... :-) 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
[PATCH 2/4 - 2.6.15]net: 32 bit (socket layer) ioctl emulation for 64 bit kernels
Provides a 32 bit conversion function for SIOCGSTAMP
diff -uprN -X dontdiff linux-2.6.15-vanilla/include/net/compat.h
linux-2.6.15/include/net/compat.h
--- linux-2.6.15-vanilla/include/net/compat.h 2006-01-03
14:21:10.0 +1100
+++ linux-2.6.15/include/net/compat.h 2006-01-17 09:52:50.0
+1100
@@ -23,6 +23,8 @@ struct compat_cmsghdr {
compat_int_tcmsg_type;
};
+extern int compat_sock_get_timestamp(struct sock *, struct timeval
__user *);
+
#else /* defined(CONFIG_COMPAT) */
#define compat_msghdr msghdr /* to avoid compiler warnings */
#endif /* defined(CONFIG_COMPAT) */
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/compat.c
linux-2.6.15/net/compat.c
--- linux-2.6.15-vanilla/net/compat.c 2006-01-03 14:21:10.0
+1100
+++ linux-2.6.15/net/compat.c 2006-01-17 09:52:50.0 +1100
@@ -503,6 +503,23 @@ static int do_get_sock_timeout(int fd, i
return err;
}
+int compat_sock_get_timestamp(struct sock *sk, struct timeval __user
*userstamp)
+{
+ struct compat_timeval __user *ctv
+ = (struct compat_timeval __user*) userstamp;
+ int err = -ENOENT;
+ if(!sock_flag(sk, SOCK_TIMESTAMP))
+ sock_enable_timestamp(sk);
+ if(sk-sk_stamp.tv_sec == -1)
+ return err;
+ if(sk-sk_stamp.tv_sec == 0)
+ do_gettimeofday(sk-sk_stamp);
+ if (put_user(sk-sk_stamp.tv_sec, ctv-tv_sec) |
+ put_user(sk-sk_stamp.tv_usec, ctv-tv_usec))
+ err = -EFAULT;
+ return err;
+}
+
asmlinkage long compat_sys_getsockopt(int fd, int level, int optname,
char __user *optval, int __user *optlen)
{
@@ -602,3 +619,5 @@ asmlinkage long compat_sys_socketcall(in
}
return ret;
}
+
+EXPORT_SYMBOL(compat_sock_get_timestamp);
-
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 4/4]x25: 32 bit (socket layer) ioctl emulation for 64 bit kernels
A small fix for the following error, when trying to run a 64 bit x25
server application.
T2 kernel: schedule_timeout:
wrong timeout value from 88164796
diff -uprN -X dontdiff linux-2.6.15-vanilla/net/x25/af_x25.c
linux-2.6.15/net/x25/af_x25.c
--- linux-2.6.15-vanilla/net/x25/af_x25.c 2006-01-17 09:57:38.0
+1100
+++ linux-2.6.15/net/x25/af_x25.c 2006-01-17 09:58:04.0 +1100
@@ -747,7 +747,7 @@ out:
return rc;
}
-static int x25_wait_for_data(struct sock *sk, int timeout)
+static int x25_wait_for_data(struct sock *sk, long timeout)
{
DECLARE_WAITQUEUE(wait, current);
int rc = 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
[Patch 00/13] mv643xx_eth: Bug Fixes
This patch series for the Marvell mv643xx ethernet controller contains primarily bug fixes. 1. Add Dale Farnsworth as a maintainer 2. 2.6.16 needs ip.h and in.h Bug fix, from Olaf Hering [EMAIL PROTECTED] 3. Fix dma_map/dma_unmap relations Bug fix, from Paolo Galtieri [EMAIL PROTECTED] 4. Fix a NULL pointer dereference Bug fix, from Paolo Galtieri [EMAIL PROTECTED] 5. Add multicast support Feature addition 6. Receive buffers require 8 byte alignment Bug fix, reported by David Woodhouse [EMAIL PROTECTED] 7. Fix handling of small, unaligned fragments Bug fix, from Paul Janzen [EMAIL PROTECTED] 8. iounmap the correct SRAM buffer Bug fix 9. Hold spinlocks only where needed Bug fix 10. Request HW checksum generation only for IPv4 Bug fix, from Wolfram Joost [EMAIL PROTECTED] 11. Fix transmit skb accounting Bug fix 12. Merge open and stop helper functions Bug fix 13. Remove needless mask of extended intr register Bug fix - 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 02/13] mv643xx_eth: 2.6.16 needs ip.h and in.h
From: Olaf Hering [EMAIL PROTECTED] Signed-off-by: Olaf Hering [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] mv643xx_eth.c |2 ++ 1 file changed, 2 insertions(+) Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c === --- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16 10:48:49.0 -0700 +++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16 10:49:27.0 -0700 @@ -35,6 +35,8 @@ #include linux/tcp.h #include linux/udp.h #include linux/etherdevice.h +#include linux/in.h +#include linux/ip.h #include linux/bitops.h #include linux/delay.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
[Patch 03/13] mv643xx_eth: Fix dma_map/dma_unmap relations
From: Paolo Galtieri [EMAIL PROTECTED]
If you do a dma_map_single you must do dma_unmap_single and if you do
a dma_map_page you must do a dma_unmap_page.
Signed-off-by: Paolo Galtieri [EMAIL PROTECTED]
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 51 +--
1 file changed, 21 insertions(+), 30 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
10:49:27.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
10:49:29.0 -0700
@@ -353,27 +353,19 @@
stats-tx_errors++;
}
- /*
-* If return_info is different than 0, release the skb.
-* The case where return_info is not 0 is only in case
-* when transmitted a scatter/gather packet, where only
-* last skb releases the whole chain.
-*/
- if (pkt_info.return_info) {
- if (skb_shinfo(pkt_info.return_info)-nr_frags)
- dma_unmap_page(NULL, pkt_info.buf_ptr,
- pkt_info.byte_cnt,
- DMA_TO_DEVICE);
- else
- dma_unmap_single(NULL, pkt_info.buf_ptr,
- pkt_info.byte_cnt,
- DMA_TO_DEVICE);
+ if (pkt_info.cmd_sts ETH_TX_FIRST_DESC)
+ dma_unmap_single(NULL, pkt_info.buf_ptr,
+ pkt_info.byte_cnt,
+ DMA_TO_DEVICE);
+ else
+ dma_unmap_page(NULL, pkt_info.buf_ptr,
+ pkt_info.byte_cnt,
+ DMA_TO_DEVICE);
+ if (pkt_info.return_info) {
dev_kfree_skb_irq(pkt_info.return_info);
released = 0;
- } else
- dma_unmap_page(NULL, pkt_info.buf_ptr,
- pkt_info.byte_cnt, DMA_TO_DEVICE);
+ }
}
spin_unlock(mp-lock);
@@ -1024,20 +1016,17 @@
struct pkt_info pkt_info;
while (eth_tx_return_desc(mp, pkt_info) == ETH_OK) {
- if (pkt_info.return_info) {
- if (skb_shinfo(pkt_info.return_info)-nr_frags)
- dma_unmap_page(NULL, pkt_info.buf_ptr,
- pkt_info.byte_cnt,
- DMA_TO_DEVICE);
- else
- dma_unmap_single(NULL, pkt_info.buf_ptr,
- pkt_info.byte_cnt,
- DMA_TO_DEVICE);
+ if (pkt_info.cmd_sts ETH_TX_FIRST_DESC)
+ dma_unmap_single(NULL, pkt_info.buf_ptr,
+ pkt_info.byte_cnt,
+ DMA_TO_DEVICE);
+ else
+ dma_unmap_page(NULL, pkt_info.buf_ptr,
+ pkt_info.byte_cnt,
+ DMA_TO_DEVICE);
+ if (pkt_info.return_info)
dev_kfree_skb_irq(pkt_info.return_info);
- } else
- dma_unmap_page(NULL, pkt_info.buf_ptr,
- pkt_info.byte_cnt, DMA_TO_DEVICE);
}
if (netif_queue_stopped(dev)
-
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 05/13] mv643xx_eth: Add multicast support
From: Dale Farnsworth [EMAIL PROTECTED]
This code is adapted from code in a ppc-specific version of the driver.
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 201 --
1 file changed, 197 insertions(+), 4 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
10:49:29.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
10:49:30.0 -0700
@@ -80,6 +80,7 @@
static int eth_port_link_is_up(unsigned int eth_port_num);
static void eth_port_uc_addr_get(struct net_device *dev,
unsigned char *MacAddr);
+static void eth_port_set_multicast_list(struct net_device *);
static int mv643xx_eth_real_open(struct net_device *);
static int mv643xx_eth_real_stop(struct net_device *);
static int mv643xx_eth_change_mtu(struct net_device *, int);
@@ -269,6 +270,8 @@
mp-port_config = ~(u32) MV643XX_ETH_UNICAST_PROMISCUOUS_MODE;
mv_write(MV643XX_ETH_PORT_CONFIG_REG(mp-port_num), mp-port_config);
+
+ eth_port_set_multicast_list(dev);
}
/*
@@ -2045,6 +2048,196 @@
}
/*
+ * The entries in each table are indexed by a hash of a packet's MAC
+ * address. One bit in each entry determines whether the packet is
+ * accepted. There are 4 entries (each 8 bits wide) in each register
+ * of the table. The bits in each entry are defined as follows:
+ * 0 Accept=1, Drop=0
+ * 3-1 Queue (ETH_Q0=0)
+ * 7-4 Reserved = 0;
+ */
+static void eth_port_set_filter_table_entry(int table, unsigned char entry)
+{
+ unsigned int table_reg;
+ unsigned int tbl_offset;
+ unsigned int reg_offset;
+
+ tbl_offset = (entry / 4) * 4; /* Register offset of DA table entry */
+ reg_offset = entry % 4; /* Entry offset within the register */
+
+ /* Set accepts frame bit at specified table entry */
+ table_reg = mv_read(table + tbl_offset);
+ table_reg |= 0x01 (8 * reg_offset);
+ mv_write(table + tbl_offset, table_reg);
+}
+
+/*
+ * eth_port_mc_addr - Multicast address settings.
+ *
+ * The MV device supports multicast using two tables:
+ * 1) Special Multicast Table for MAC addresses of the form
+ *0x01-00-5E-00-00-XX (where XX is between 0x00 and 0x_FF).
+ *The MAC DA[7:0] bits are used as a pointer to the Special Multicast
+ *Table entries in the DA-Filter table.
+ * 2) Other Multicast Table for multicast of another type. A CRC-8bit
+ *is used as an index to the Other Multicast Table entries in the
+ *DA-Filter table. This function calculates the CRC-8bit value.
+ * In either case, eth_port_set_filter_table_entry() is then called
+ * to set to set the actual table entry.
+ */
+static void eth_port_mc_addr(unsigned int eth_port_num, unsigned char *p_addr)
+{
+ unsigned int mac_h;
+ unsigned int mac_l;
+ unsigned char crc_result = 0;
+ int table;
+ int mac_array[48];
+ int crc[8];
+ int i;
+
+ if ((p_addr[0] == 0x01) (p_addr[1] == 0x00)
+ (p_addr[2] == 0x5E) (p_addr[3] == 0x00) (p_addr[4] == 0x00)) {
+ table = MV643XX_ETH_DA_FILTER_SPECIAL_MULTICAST_TABLE_BASE
+ (eth_port_num);
+ eth_port_set_filter_table_entry(table, p_addr[5]);
+ return;
+ }
+
+ /* Calculate CRC-8 out of the given address */
+ mac_h = (p_addr[0] 8) | (p_addr[1]);
+ mac_l = (p_addr[2] 24) | (p_addr[3] 16) |
+ (p_addr[4] 8) | (p_addr[5] 0);
+
+ for (i = 0; i 32; i++)
+ mac_array[i] = (mac_l i) 0x1;
+ for (i = 32; i 48; i++)
+ mac_array[i] = (mac_h (i - 32)) 0x1;
+
+ crc[0] = mac_array[45] ^ mac_array[43] ^ mac_array[40] ^ mac_array[39] ^
+mac_array[35] ^ mac_array[34] ^ mac_array[31] ^ mac_array[30] ^
+mac_array[28] ^ mac_array[23] ^ mac_array[21] ^ mac_array[19] ^
+mac_array[18] ^ mac_array[16] ^ mac_array[14] ^ mac_array[12] ^
+mac_array[8] ^ mac_array[7] ^ mac_array[6] ^ mac_array[0];
+
+ crc[1] = mac_array[46] ^ mac_array[45] ^ mac_array[44] ^ mac_array[43] ^
+mac_array[41] ^ mac_array[39] ^ mac_array[36] ^ mac_array[34] ^
+mac_array[32] ^ mac_array[30] ^ mac_array[29] ^ mac_array[28] ^
+mac_array[24] ^ mac_array[23] ^ mac_array[22] ^ mac_array[21] ^
+mac_array[20] ^ mac_array[18] ^ mac_array[17] ^ mac_array[16] ^
+mac_array[15] ^ mac_array[14] ^ mac_array[13] ^ mac_array[12] ^
+mac_array[9] ^ mac_array[6] ^ mac_array[1] ^ mac_array[0];
+
+ crc[2] = mac_array[47] ^ mac_array[46] ^ mac_array[44]
[Patch 06/13] mv643xx_eth: Receive buffers require 8 byte alignment
From: Dale Farnsworth [EMAIL PROTECTED]
The Marvell mv643xx ethernet hardware requires that DMA buffers be
aligned to 8-byte boundaries. This patch satisfies this requirement.
Buffers allocated by dev_alloc_skb() only have 4-byte alignment when
slab debugging is enabled.
Also, document that the 2-byte offset to align the IP packets on
receive is a hardware feature and is not tied to NET_IP_ALIGN.
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
10:49:30.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
10:49:31.0 -0700
@@ -57,7 +57,9 @@
/* Constants */
#define VLAN_HLEN 4
#define FCS_LEN4
-#define WRAP NET_IP_ALIGN + ETH_HLEN + VLAN_HLEN + FCS_LEN
+#define DMA_ALIGN 8 /* hw requires 8-byte alignment */
+#define HW_IP_ALIGN2 /* hw aligns IP header */
+#define WRAP HW_IP_ALIGN + ETH_HLEN + VLAN_HLEN + FCS_LEN
#define RX_SKB_SIZE((dev-mtu + WRAP + 7) ~0x7)
#define INT_CAUSE_UNMASK_ALL 0x0007
@@ -173,15 +175,19 @@
struct mv643xx_private *mp = netdev_priv(dev);
struct pkt_info pkt_info;
struct sk_buff *skb;
+ int unaligned;
if (test_and_set_bit(0, mp-rx_task_busy))
panic(%s: Error in test_set_bit / clear_bit, dev-name);
while (mp-rx_ring_skbs (mp-rx_ring_size - 5)) {
- skb = dev_alloc_skb(RX_SKB_SIZE);
+ skb = dev_alloc_skb(RX_SKB_SIZE + DMA_ALIGN);
if (!skb)
break;
mp-rx_ring_skbs++;
+ unaligned = (u32)skb-data (DMA_ALIGN - 1);
+ if (unaligned)
+ skb_reserve(skb, DMA_ALIGN - unaligned);
pkt_info.cmd_sts = ETH_RX_ENABLE_INTERRUPT;
pkt_info.byte_cnt = RX_SKB_SIZE;
pkt_info.buf_ptr = dma_map_single(NULL, skb-data, RX_SKB_SIZE,
@@ -192,7 +198,7 @@
%s: Error allocating RX Ring\n, dev-name);
break;
}
- skb_reserve(skb, 2);
+ skb_reserve(skb, HW_IP_ALIGN);
}
clear_bit(0, mp-rx_task_busy);
/*
-
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 07/13] mv643xx_eth: Fix handling of small, unaligned fragments
From: Paul Janzen [EMAIL PROTECTED]
Fix handling of small, unaligned fragments.
It also solves a potential deadlock if skb_linearize() returns -ENOMEM.
Signed-off-by: Paul Janzen [EMAIL PROTECTED]
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 54 +++---
1 file changed, 31 insertions(+), 23 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
10:49:31.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
10:49:32.0 -0700
@@ -1093,6 +1093,25 @@
}
#endif
+/* Hardware can't handle unaligned fragments smaller than 9 bytes.
+ * This helper function detects that case.
+ */
+
+static inline unsigned int has_tiny_unaligned_frags(struct sk_buff *skb)
+{
+unsigned int frag;
+skb_frag_t *fragp;
+
+for (frag = 0; frag skb_shinfo(skb)-nr_frags; frag++) {
+fragp = skb_shinfo(skb)-frags[frag];
+if (fragp-size = 8 fragp-page_offset 0x7)
+return 1;
+
+}
+return 0;
+}
+
+
/*
* mv643xx_eth_start_xmit
*
@@ -1136,12 +1155,19 @@
return 1;
}
+#ifdef MV643XX_CHECKSUM_OFFLOAD_TX
+ if (has_tiny_unaligned_frags(skb)) {
+ if ((skb_linearize(skb, GFP_ATOMIC) != 0)) {
+ stats-tx_dropped++;
+ printk(KERN_DEBUG %s: failed to linearize tiny
+ unaligned fragment\n, dev-name);
+ return 1;
+ }
+ }
+
spin_lock_irqsave(mp-lock, flags);
- /* Update packet info data structure -- DMA owned, first last */
-#ifdef MV643XX_CHECKSUM_OFFLOAD_TX
if (!skb_shinfo(skb)-nr_frags) {
-linear:
if (skb-ip_summed != CHECKSUM_HW) {
/* Errata BTS #50, IHL must be 5 if no HW checksum */
pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT |
@@ -1183,26 +1209,6 @@
} else {
unsigned int frag;
- /* Since hardware can't handle unaligned fragments smaller
-* than 9 bytes, if we find any, we linearize the skb
-* and start again. When I've seen it, it's always been
-* the first frag (probably near the end of the page),
-* but we check all frags to be safe.
-*/
- for (frag = 0; frag skb_shinfo(skb)-nr_frags; frag++) {
- skb_frag_t *fragp;
-
- fragp = skb_shinfo(skb)-frags[frag];
- if (fragp-size = 8 fragp-page_offset 0x7) {
- skb_linearize(skb, GFP_ATOMIC);
- printk(KERN_DEBUG %s: unaligned tiny fragment
- %d of %d, fixed\n,
- dev-name, frag,
- skb_shinfo(skb)-nr_frags);
- goto linear;
- }
- }
-
/* first frag which is skb header */
pkt_info.byte_cnt = skb_headlen(skb);
pkt_info.buf_ptr = dma_map_single(NULL, skb-data,
@@ -1288,6 +1294,8 @@
}
}
#else
+ spin_lock_irqsave(mp-lock, flags);
+
pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT | ETH_TX_FIRST_DESC |
ETH_TX_LAST_DESC;
pkt_info.l4i_chk = 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
[Patch 08/13] mv643xx_eth: iounmap the correct SRAM buffer
From: Dale Farnsworth [EMAIL PROTECTED] Signed-off-by: Dale Farnsworth [EMAIL PROTECTED] mv643xx_eth.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c === --- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16 10:49:32.0 -0700 +++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16 10:49:32.0 -0700 @@ -877,7 +877,7 @@ printk(KERN_ERR %s: Freeing previously allocated TX queues..., dev-name); if (mp-rx_sram_size) - iounmap(mp-p_rx_desc_area); + iounmap(mp-p_tx_desc_area); else dma_free_coherent(NULL, mp-tx_desc_area_size, mp-p_tx_desc_area, mp-tx_desc_dma); - 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 09/13] mv643xx_eth: Hold spinlocks only where needed
From: Dale Farnsworth [EMAIL PROTECTED]
This driver has historically held a spin_lock during the entire open
and stop functions and while receiving multiple packets. This is
unecessarily long and holds locks during calls that may sleep.
This patch reduces the size of windows where locks are held.
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 172 ++
1 file changed, 91 insertions(+), 81 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
15:06:40.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
15:32:59.0 -0700
@@ -129,15 +129,8 @@
*/
static int mv643xx_eth_change_mtu(struct net_device *dev, int new_mtu)
{
- struct mv643xx_private *mp = netdev_priv(dev);
- unsigned long flags;
-
- spin_lock_irqsave(mp-lock, flags);
-
- if ((new_mtu 9500) || (new_mtu 64)) {
- spin_unlock_irqrestore(mp-lock, flags);
+ if ((new_mtu 9500) || (new_mtu 64))
return -EINVAL;
- }
dev-mtu = new_mtu;
/*
@@ -157,7 +150,6 @@
dev-name);
}
- spin_unlock_irqrestore(mp-lock, flags);
return 0;
}
@@ -353,8 +345,6 @@
if (!(eth_int_cause_ext (BIT0 | BIT8)))
return released;
- spin_lock(mp-lock);
-
/* Check only queue 0 */
while (eth_tx_return_desc(mp, pkt_info) == ETH_OK) {
if (pkt_info.cmd_sts BIT0) {
@@ -377,8 +367,6 @@
}
}
- spin_unlock(mp-lock);
-
return released;
}
@@ -518,6 +506,8 @@
mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), 0);
mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG
(port_num), 0);
+ /* ensure previous writes have taken effect */
+
mv_read(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num));
__netif_rx_schedule(dev);
}
#else
@@ -533,6 +523,9 @@
/* Unmask all interrupts on ethernet port */
mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num),
INT_CAUSE_MASK_ALL);
+ /* wait for previous write to take effect */
+ mv_read(MV643XX_ETH_INTERRUPT_MASK_REG(port_num));
+
queue_task(mp-rx_task, tq_immediate);
mark_bh(IMMEDIATE_BH);
#else
@@ -657,34 +650,20 @@
unsigned int port_num = mp-port_num;
int err;
- spin_lock_irq(mp-lock);
-
err = request_irq(dev-irq, mv643xx_eth_int_handler,
SA_SHIRQ | SA_SAMPLE_RANDOM, dev-name, dev);
-
if (err) {
printk(KERN_ERR Can not assign IRQ number to MV643XX_eth%d\n,
port_num);
- err = -EAGAIN;
- goto out;
+ return -EAGAIN;
}
if (mv643xx_eth_real_open(dev)) {
printk(%s: Error opening interface\n, dev-name);
+ free_irq(dev-irq, dev);
err = -EBUSY;
- goto out_free;
}
- spin_unlock_irq(mp-lock);
-
- return 0;
-
-out_free:
- free_irq(dev-irq, dev);
-
-out:
- spin_unlock_irq(mp-lock);
-
return err;
}
@@ -790,18 +769,6 @@
/* Stop RX Queues */
mv_write(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), 0xff00);
- /* Clear the ethernet port interrupts */
- mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), 0);
- mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0);
-
- /* Unmask RX buffer and TX end interrupt */
- mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num),
- INT_CAUSE_UNMASK_ALL);
-
- /* Unmask phy and link status changes interrupts */
- mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num),
- INT_CAUSE_UNMASK_ALL_EXT);
-
/* Set the MAC Address */
memcpy(mp-port_mac_addr, dev-dev_addr, 6);
@@ -903,8 +870,17 @@
mp-tx_int_coal =
eth_port_set_tx_coal(port_num, 13300, MV643XX_TX_COAL);
- netif_start_queue(dev);
+ /* Clear any pending ethernet port interrupts */
+ mv_write(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num), 0);
+ mv_write(MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num), 0);
+
+ /* Unmask phy and link status changes interrupts */
+ mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num),
+ INT_CAUSE_UNMASK_ALL_EXT);
+ /*
[Patch 10/13] mv643xx_eth: Request HW checksum generation only for IPv4
From: Wolfram Joost [EMAIL PROTECTED]
This patch removes the NETIF_F_HW_CSUM flag to be able to use other protocols
than IPv4. Hardware checksums for IPv4 should continue to work because
NETIF_F_IP_CSUM is still set. The sanity-check has been enhanced to check
the used protocol and to not access skb-iph for non-ipv4-packets.
Signed-off-by: Wolfram Joost [EMAIL PROTECTED]
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
10:49:33.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
10:49:35.0 -0700
@@ -1148,7 +1148,6 @@
5 ETH_TX_IHL_SHIFT;
pkt_info.l4i_chk = 0;
} else {
-
pkt_info.cmd_sts = ETH_TX_ENABLE_INTERRUPT |
ETH_TX_FIRST_DESC |
ETH_TX_LAST_DESC |
@@ -1156,14 +1155,16 @@
ETH_GEN_IP_V_4_CHECKSUM |
skb-nh.iph-ihl ETH_TX_IHL_SHIFT;
/* CPU already calculated pseudo header checksum. */
- if (skb-nh.iph-protocol == IPPROTO_UDP) {
+ if ((skb-protocol == ETH_P_IP)
+ (skb-nh.iph-protocol == IPPROTO_UDP) ) {
pkt_info.cmd_sts |= ETH_UDP_FRAME;
pkt_info.l4i_chk = skb-h.uh-check;
- } else if (skb-nh.iph-protocol == IPPROTO_TCP)
+ } else if ((skb-protocol == ETH_P_IP)
+ (skb-nh.iph-protocol == IPPROTO_TCP))
pkt_info.l4i_chk = skb-h.th-check;
else {
printk(KERN_ERR
- %s: chksum proto != TCP or UDP\n,
+ %s: chksum proto != IPv4 TCP or UDP\n,
dev-name);
spin_unlock_irqrestore(mp-lock, flags);
return 1;
@@ -1199,14 +1200,16 @@
ETH_GEN_IP_V_4_CHECKSUM |
skb-nh.iph-ihl ETH_TX_IHL_SHIFT;
/* CPU already calculated pseudo header checksum. */
- if (skb-nh.iph-protocol == IPPROTO_UDP) {
+ if ((skb-protocol == ETH_P_IP)
+ (skb-nh.iph-protocol == IPPROTO_UDP)) {
pkt_info.cmd_sts |= ETH_UDP_FRAME;
pkt_info.l4i_chk = skb-h.uh-check;
- } else if (skb-nh.iph-protocol == IPPROTO_TCP)
+ } else if ((skb-protocol == ETH_P_IP)
+ (skb-nh.iph-protocol == IPPROTO_TCP))
pkt_info.l4i_chk = skb-h.th-check;
else {
printk(KERN_ERR
- %s: chksum proto != TCP or UDP\n,
+ %s: chksum proto != IPv4 TCP or UDP\n,
dev-name);
spin_unlock_irqrestore(mp-lock, flags);
return 1;
@@ -1421,7 +1424,7 @@
* Zero copy can only work if we use Discovery II memory. Else, we will
* have to map the buffers to ISA memory which is only 16 MB
*/
- dev-features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_HW_CSUM;
+ dev-features = NETIF_F_SG | NETIF_F_IP_CSUM;
#endif
#endif
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 11/13] mv643xx_eth: Fix transmit skb accounting
From: Dale Farnsworth [EMAIL PROTECTED]
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
15:33:10.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
15:33:11.0 -0700
@@ -889,14 +889,17 @@
struct mv643xx_private *mp = netdev_priv(dev);
unsigned int port_num = mp-port_num;
unsigned int curr;
+ struct sk_buff *skb;
/* Stop Tx Queues */
mv_write(MV643XX_ETH_TRANSMIT_QUEUE_COMMAND_REG(port_num), 0xff00);
/* Free outstanding skb's on TX rings */
for (curr = 0; mp-tx_ring_skbs curr mp-tx_ring_size; curr++) {
- if (mp-tx_skb[curr]) {
- dev_kfree_skb(mp-tx_skb[curr]);
+ skb = mp-tx_skb[curr];
+ if (skb) {
+ mp-tx_ring_skbs -= skb_shinfo(skb)-nr_frags;
+ dev_kfree_skb(skb);
mp-tx_ring_skbs--;
}
}
-
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 12/13] mv643xx_eth: Merge open and stop helper functions
From: Dale Farnsworth [EMAIL PROTECTED]
Move code from helper functions mv643xx_eth_real_open and mv643xx_eth_real_stop
as they are no longer needed.
Signed-off-by Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 109 +++---
1 file changed, 45 insertions(+), 64 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
15:33:11.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
15:33:18.0 -0700
@@ -83,8 +83,8 @@
static void eth_port_uc_addr_get(struct net_device *dev,
unsigned char *MacAddr);
static void eth_port_set_multicast_list(struct net_device *);
-static int mv643xx_eth_real_open(struct net_device *);
-static int mv643xx_eth_real_stop(struct net_device *);
+static int mv643xx_eth_open(struct net_device *);
+static int mv643xx_eth_stop(struct net_device *);
static int mv643xx_eth_change_mtu(struct net_device *, int);
static struct net_device_stats *mv643xx_eth_get_stats(struct net_device *);
static void eth_port_init_mac_tables(unsigned int eth_port_num);
@@ -140,11 +140,8 @@
* to memory is full, which might fail the open function.
*/
if (netif_running(dev)) {
- if (mv643xx_eth_real_stop(dev))
- printk(KERN_ERR
- %s: Fatal error on stopping device\n,
- dev-name);
- if (mv643xx_eth_real_open(dev))
+ mv643xx_eth_stop(dev);
+ if (mv643xx_eth_open(dev))
printk(KERN_ERR
%s: Fatal error on opening device\n,
dev-name);
@@ -632,42 +629,6 @@
}
/*
- * mv643xx_eth_open
- *
- * This function is called when openning the network device. The function
- * should initialize all the hardware, initialize cyclic Rx/Tx
- * descriptors chain and buffers and allocate an IRQ to the network
- * device.
- *
- * Input : a pointer to the network device structure
- *
- * Output :zero of success , nonzero if fails.
- */
-
-static int mv643xx_eth_open(struct net_device *dev)
-{
- struct mv643xx_private *mp = netdev_priv(dev);
- unsigned int port_num = mp-port_num;
- int err;
-
- err = request_irq(dev-irq, mv643xx_eth_int_handler,
- SA_SHIRQ | SA_SAMPLE_RANDOM, dev-name, dev);
- if (err) {
- printk(KERN_ERR Can not assign IRQ number to MV643XX_eth%d\n,
- port_num);
- return -EAGAIN;
- }
-
- if (mv643xx_eth_real_open(dev)) {
- printk(%s: Error opening interface\n, dev-name);
- free_irq(dev-irq, dev);
- err = -EBUSY;
- }
-
- return err;
-}
-
-/*
* ether_init_rx_desc_ring - Curve a Rx chain desc list and buffer in memory.
*
* DESCRIPTION:
@@ -759,12 +720,33 @@
mp-port_tx_queue_command |= 1;
}
-/* Helper function for mv643xx_eth_open */
-static int mv643xx_eth_real_open(struct net_device *dev)
+/*
+ * mv643xx_eth_open
+ *
+ * This function is called when openning the network device. The function
+ * should initialize all the hardware, initialize cyclic Rx/Tx
+ * descriptors chain and buffers and allocate an IRQ to the network
+ * device.
+ *
+ * Input : a pointer to the network device structure
+ *
+ * Output :zero of success , nonzero if fails.
+ */
+
+static int mv643xx_eth_open(struct net_device *dev)
{
struct mv643xx_private *mp = netdev_priv(dev);
unsigned int port_num = mp-port_num;
unsigned int size;
+ int err;
+
+ err = request_irq(dev-irq, mv643xx_eth_int_handler,
+ SA_SHIRQ | SA_SAMPLE_RANDOM, dev-name, dev);
+ if (err) {
+ printk(KERN_ERR Can not assign IRQ number to MV643XX_eth%d\n,
+ port_num);
+ return -EAGAIN;
+ }
/* Stop RX Queues */
mv_write(MV643XX_ETH_RECEIVE_QUEUE_COMMAND_REG(port_num), 0xff00);
@@ -788,14 +770,15 @@
GFP_KERNEL);
if (!mp-rx_skb) {
printk(KERN_ERR %s: Cannot allocate Rx skb ring\n, dev-name);
- return -ENOMEM;
+ err = -ENOMEM;
+ goto out_free_irq;
}
mp-tx_skb = kmalloc(sizeof(*mp-tx_skb) * mp-tx_ring_size,
GFP_KERNEL);
if (!mp-tx_skb) {
printk(KERN_ERR %s: Cannot allocate Tx skb ring\n, dev-name);
- kfree(mp-rx_skb);
- return -ENOMEM;
+ err = -ENOMEM;
+
[Patch 13/13] mv643xx_eth: Remove needless mask of extended intr register
From: Dale Farnsworth [EMAIL PROTECTED]
All interrupts controlled by the extended mask register are also
masked by a bit in the main mask register, so there is no need to
directly manipulate the extended mask register.
Signed-off-by: Dale Farnsworth [EMAIL PROTECTED]
mv643xx_eth.c | 81 ++
1 file changed, 26 insertions(+), 55 deletions(-)
Index: linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c
===
--- linux-2.6-mv643xx_enet.orig/drivers/net/mv643xx_eth.c 2006-01-16
15:33:18.0 -0700
+++ linux-2.6-mv643xx_enet/drivers/net/mv643xx_eth.c2006-01-16
15:33:23.0 -0700
@@ -62,10 +62,10 @@
#define WRAP HW_IP_ALIGN + ETH_HLEN + VLAN_HLEN + FCS_LEN
#define RX_SKB_SIZE((dev-mtu + WRAP + 7) ~0x7)
-#define INT_CAUSE_UNMASK_ALL 0x0007
-#define INT_CAUSE_UNMASK_ALL_EXT 0x0011
-#define INT_CAUSE_MASK_ALL 0x
-#define INT_CAUSE_MASK_ALL_EXT 0x
+#define INT_UNMASK_ALL 0x0007
+#define INT_UNMASK_ALL_EXT 0x0011
+#define INT_MASK_ALL 0x
+#define INT_MASK_ALL_EXT 0x
#define INT_CAUSE_CHECK_BITS INT_CAUSE_UNMASK_ALL
#define INT_CAUSE_CHECK_BITS_EXT INT_CAUSE_UNMASK_ALL_EXT
@@ -205,7 +205,7 @@
else {
/* Return interrupts */
mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(mp-port_num),
- INT_CAUSE_UNMASK_ALL);
+ INT_UNMASK_ALL);
}
#endif
}
@@ -470,12 +470,12 @@
/* Read interrupt cause registers */
eth_int_cause = mv_read(MV643XX_ETH_INTERRUPT_CAUSE_REG(port_num))
- INT_CAUSE_UNMASK_ALL;
+ INT_UNMASK_ALL;
if (eth_int_cause BIT1)
eth_int_cause_ext = mv_read(
MV643XX_ETH_INTERRUPT_CAUSE_EXTEND_REG(port_num))
- INT_CAUSE_UNMASK_ALL_EXT;
+ INT_UNMASK_ALL_EXT;
#ifdef MV643XX_NAPI
if (!(eth_int_cause 0x0007fffd)) {
@@ -500,11 +500,10 @@
} else {
if (netif_rx_schedule_prep(dev)) {
/* Mask all the interrupts */
- mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), 0);
- mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG
- (port_num), 0);
- /* ensure previous writes have taken effect */
-
mv_read(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num));
+ mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num),
+ INT_MASK_ALL);
+ /* wait for previous write to complete */
+ mv_read(MV643XX_ETH_INTERRUPT_MASK_REG(port_num));
__netif_rx_schedule(dev);
}
#else
@@ -517,9 +516,9 @@
* with skb's.
*/
#ifdef MV643XX_RX_QUEUE_FILL_ON_TASK
- /* Unmask all interrupts on ethernet port */
+ /* Mask all interrupts on ethernet port */
mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num),
- INT_CAUSE_MASK_ALL);
+ INT_MASK_ALL);
/* wait for previous write to take effect */
mv_read(MV643XX_ETH_INTERRUPT_MASK_REG(port_num));
@@ -857,11 +856,10 @@
/* Unmask phy and link status changes interrupts */
mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num),
- INT_CAUSE_UNMASK_ALL_EXT);
+ INT_UNMASK_ALL_EXT);
/* Unmask RX buffer and TX end interrupt */
- mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num),
- INT_CAUSE_UNMASK_ALL);
+ mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), INT_UNMASK_ALL);
return 0;
out_free_tx_skb:
@@ -950,13 +948,9 @@
struct mv643xx_private *mp = netdev_priv(dev);
unsigned int port_num = mp-port_num;
- /* Mask RX buffer and TX end interrupt */
- mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), 0);
-
- /* Mask phy and link status changes interrupts */
- mv_write(MV643XX_ETH_INTERRUPT_EXTEND_MASK_REG(port_num), 0);
-
- /* ensure previous writes have taken effect */
+ /* Mask all interrupts on ethernet port */
+ mv_write(MV643XX_ETH_INTERRUPT_MASK_REG(port_num), INT_MASK_ALL);
+
Re: [PATCH 1/1] LSM-IPsec SELinux Authorize
On Mon, Jan 16, 2006 at 06:10:53PM -0500, cxzhang wrote:
This patch contains a fix for the previous patch that adds security
contexts to IPsec policies and security associations. In the previous
patch, no authorization (besides the check for write permissions to
SAD and SPD) is required to delete IPsec policies and security
assocations with security contexts. Thus a user authorized to change
SAD and SPD can bypass the IPsec policy authorization by simply
deleteing policies with security contexts. To fix this security hole,
an additional authorization check is added for removing security
policies and security associations with security contexts.
Perhaps I'm missing something. But I thought only root can modify
the SAD/SPD?
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] tg3: Refine nvram locking
Add nvram lock count so that calls to tg3_nvram_lock()/unlock() can
be nested. Add error checking to all callers of tg3_nvram_lock()
where appropriate. To prevent nvram lock failures after halting the
firmware, it is also necessary to release firmware's nvram lock in
tg3_halt_cpu().
Update version to 3.48.
Based on David Miller's initial patch.
Signed-off-by: Michael Chan [EMAIL PROTECTED]
diff --git a/drivers/net/tg3.c b/drivers/net/tg3.c
index eb86b05..f2d1daf 100644
--- a/drivers/net/tg3.c
+++ b/drivers/net/tg3.c
@@ -69,8 +69,8 @@
#define DRV_MODULE_NAMEtg3
#define PFX DRV_MODULE_NAME:
-#define DRV_MODULE_VERSION 3.47
-#define DRV_MODULE_RELDATE Dec 28, 2005
+#define DRV_MODULE_VERSION 3.48
+#define DRV_MODULE_RELDATE Jan 16, 2006
#define TG3_DEF_MAC_MODE 0
#define TG3_DEF_RX_MODE0
@@ -1325,10 +1325,12 @@ static int tg3_set_power_state(struct tg
val = ~((1 16) | (1 4) | (1 2) | (1 1) | 1);
tw32(0x7d00, val);
if (!(tp-tg3_flags TG3_FLAG_ENABLE_ASF)) {
- tg3_nvram_lock(tp);
+ int err;
+
+ err = tg3_nvram_lock(tp);
tg3_halt_cpu(tp, RX_CPU_BASE);
- tw32_f(NVRAM_SWARB, SWARB_REQ_CLR0);
- tg3_nvram_unlock(tp);
+ if (!err)
+ tg3_nvram_unlock(tp);
}
}
@@ -4193,14 +4195,19 @@ static int tg3_nvram_lock(struct tg3 *tp
if (tp-tg3_flags TG3_FLAG_NVRAM) {
int i;
- tw32(NVRAM_SWARB, SWARB_REQ_SET1);
- for (i = 0; i 8000; i++) {
- if (tr32(NVRAM_SWARB) SWARB_GNT1)
- break;
- udelay(20);
+ if (tp-nvram_lock_cnt == 0) {
+ tw32(NVRAM_SWARB, SWARB_REQ_SET1);
+ for (i = 0; i 8000; i++) {
+ if (tr32(NVRAM_SWARB) SWARB_GNT1)
+ break;
+ udelay(20);
+ }
+ if (i == 8000) {
+ tw32(NVRAM_SWARB, SWARB_REQ_CLR1);
+ return -ENODEV;
+ }
}
- if (i == 8000)
- return -ENODEV;
+ tp-nvram_lock_cnt++;
}
return 0;
}
@@ -4208,8 +4215,12 @@ static int tg3_nvram_lock(struct tg3 *tp
/* tp-lock is held. */
static void tg3_nvram_unlock(struct tg3 *tp)
{
- if (tp-tg3_flags TG3_FLAG_NVRAM)
- tw32_f(NVRAM_SWARB, SWARB_REQ_CLR1);
+ if (tp-tg3_flags TG3_FLAG_NVRAM) {
+ if (tp-nvram_lock_cnt 0)
+ tp-nvram_lock_cnt--;
+ if (tp-nvram_lock_cnt == 0)
+ tw32_f(NVRAM_SWARB, SWARB_REQ_CLR1);
+ }
}
/* tp-lock is held. */
@@ -4320,8 +4331,13 @@ static int tg3_chip_reset(struct tg3 *tp
void (*write_op)(struct tg3 *, u32, u32);
int i;
- if (!(tp-tg3_flags2 TG3_FLG2_SUN_570X))
+ if (!(tp-tg3_flags2 TG3_FLG2_SUN_570X)) {
tg3_nvram_lock(tp);
+ /* No matching tg3_nvram_unlock() after this because
+* chip reset below will undo the nvram lock.
+*/
+ tp-nvram_lock_cnt = 0;
+ }
/*
* We must avoid the readl() that normally takes place.
@@ -4717,6 +4733,10 @@ static int tg3_halt_cpu(struct tg3 *tp,
(offset == RX_CPU_BASE ? RX : TX));
return -ENODEV;
}
+
+ /* Clear firmware's nvram arbitration. */
+ if (tp-tg3_flags TG3_FLAG_NVRAM)
+ tw32(NVRAM_SWARB, SWARB_REQ_CLR0);
return 0;
}
@@ -4736,7 +4756,7 @@ struct fw_info {
static int tg3_load_firmware_cpu(struct tg3 *tp, u32 cpu_base, u32
cpu_scratch_base,
int cpu_scratch_size, struct fw_info *info)
{
- int err, i;
+ int err, lock_err, i;
void (*write_op)(struct tg3 *, u32, u32);
if (cpu_base == TX_CPU_BASE
@@ -4755,9 +4775,10 @@ static int tg3_load_firmware_cpu(struct
/* It is possible that bootcode is still loading at this point.
* Get the nvram lock first before halting the cpu.
*/
- tg3_nvram_lock(tp);
+ lock_err = tg3_nvram_lock(tp);
err = tg3_halt_cpu(tp, cpu_base);
- tg3_nvram_unlock(tp);
+ if (!lock_err)
+ tg3_nvram_unlock(tp);
if (err)
goto out;
@@ -8182,7 +8203,7 @@ static void tg3_self_test(struct net_dev
data[1] = 1;
}
if (etest-flags ETH_TEST_FL_OFFLINE) {
- int irq_sync = 0;
+ int err, irq_sync = 0;
if (netif_running(dev)) {
Re: [PATCH 3/4 -2.6.15]:x25: 32 bit (socket layer) ioctl emulation for 64 bit kernels
Am Dienstag, 17. Januar 2006 00:12 schrieb Shaun Pereira:
+static int compat_x25_subscr_ioctl(unsigned int cmd,
+ struct compat_x25_subscrip_struct __user *x25_subscr32)
+{
+ struct x25_subscrip_struct x25_subscr;
+ struct x25_neigh *nb;
+ struct net_device *dev;
+ int rc = -EINVAL;
+
+ if (cmd != SIOCX25GSUBSCRIP cmd != SIOCX25SSUBSCRIP)
+ goto out;
btw, the above check is not needed here, but that's not my point.
+
+ rc = -EFAULT;
+ if(copy_from_user(x25_subscr, x25_subscr32, sizeof(*x25_subscr32)))
+ goto out;
Unfortunately, I just found another bug in this code, similar to one you
already fixed in the sock_get_timestamp handler:
You can't do the copy_from_user like this if the arguments have different
types. Changing the declaration 'struct x25_subscrip_struct x25_subscr;'
to 'struct compat_x25_subscrip_struct x25_subscr;' should fix this problem,
but please verify that it really works with a test case that relies on the
contents of x25_subscr-extended.
Arnd
-
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
Pull request for wireless-2.6
The following changes since commit 4a8e4a270b89030bdeb09d2f8cef7cfe9a50e54d:
Linus Torvalds:
Merge git://oss.sgi.com:8090/oss/git/xfs-2.6
are found in the git repository at:
git://git.tuxdriver.com/git/wireless-2.6.git
Adrian Bunk:
ipw2100: remove code for WIRELESS_EXT 18
hostap: don't #include C files in hostap_main.c
Dan Williams:
drivers/net/wireless: correct reported ssid lengths
Graham Gower:
prism54/islpci_eth.c: dev_kfree_skb used with interrupts disabled
Olaf Kirch:
ipw2200: do not sleep in ipw_request_direct_scan
Pavel Roskin:
hostap: allow flashing firmware
Pete Zaitcev:
iw_handler.h: SIOCSIWNAME - SIOCSIWCOMMIT in comment
drivers/net/wireless/airo.c |2
drivers/net/wireless/atmel.c |4
drivers/net/wireless/hostap/Kconfig | 22 +
drivers/net/wireless/hostap/Makefile |3
drivers/net/wireless/hostap/hostap.h | 37 ++
drivers/net/wireless/hostap/hostap_80211.h|3
drivers/net/wireless/hostap/hostap_80211_rx.c | 11 +
drivers/net/wireless/hostap/hostap_80211_tx.c | 15 +
drivers/net/wireless/hostap/hostap_ap.c | 36 +-
drivers/net/wireless/hostap/hostap_ap.h |2
drivers/net/wireless/hostap/hostap_common.h |3
drivers/net/wireless/hostap/hostap_config.h | 13 -
drivers/net/wireless/hostap/hostap_info.c |3
drivers/net/wireless/hostap/hostap_ioctl.c| 12 -
drivers/net/wireless/hostap/hostap_main.c | 60 ---
drivers/net/wireless/hostap/hostap_proc.c |7
drivers/net/wireless/hostap/hostap_wlan.h |4
drivers/net/wireless/ipw2100.c| 434 -
drivers/net/wireless/ipw2200.c| 14 -
drivers/net/wireless/prism54/isl_ioctl.c |2
drivers/net/wireless/prism54/islpci_eth.c |2
drivers/net/wireless/ray_cs.c |2
drivers/net/wireless/wavelan_cs.c |2
include/net/ieee80211_crypt.h |1
include/net/iw_handler.h |2
25 files changed, 156 insertions(+), 540 deletions(-)
diff --git a/drivers/net/wireless/airo.c b/drivers/net/wireless/airo.c
index ee866fd..6505734 100644
--- a/drivers/net/wireless/airo.c
+++ b/drivers/net/wireless/airo.c
@@ -5783,7 +5783,7 @@ static int airo_get_essid(struct net_dev
/* If none, we may want to get the one that was set */
/* Push it out ! */
- dwrq-length = status_rid.SSIDlen + 1;
+ dwrq-length = status_rid.SSIDlen;
dwrq-flags = 1; /* active */
return 0;
diff --git a/drivers/net/wireless/atmel.c b/drivers/net/wireless/atmel.c
index f0ccfef..98a76f1 100644
--- a/drivers/net/wireless/atmel.c
+++ b/drivers/net/wireless/atmel.c
@@ -1718,11 +1718,11 @@ static int atmel_get_essid(struct net_de
if (priv-new_SSID_size != 0) {
memcpy(extra, priv-new_SSID, priv-new_SSID_size);
extra[priv-new_SSID_size] = '\0';
- dwrq-length = priv-new_SSID_size + 1;
+ dwrq-length = priv-new_SSID_size;
} else {
memcpy(extra, priv-SSID, priv-SSID_size);
extra[priv-SSID_size] = '\0';
- dwrq-length = priv-SSID_size + 1;
+ dwrq-length = priv-SSID_size;
}
dwrq-flags = !priv-connect_to_any_BSS; /* active */
diff --git a/drivers/net/wireless/hostap/Kconfig
b/drivers/net/wireless/hostap/Kconfig
index 56f41c7..c8f6286 100644
--- a/drivers/net/wireless/hostap/Kconfig
+++ b/drivers/net/wireless/hostap/Kconfig
@@ -26,11 +26,25 @@ config HOSTAP_FIRMWARE
depends on HOSTAP
---help---
Configure Host AP driver to include support for firmware image
- download. Current version supports only downloading to volatile, i.e.,
- RAM memory. Flash upgrade is not yet supported.
+ download. This option by itself only enables downloading to the
+ volatile memory, i.e. the card RAM. This option is required to
+ support cards that don't have firmware in flash, such as D-Link
+ DWL-520 rev E and D-Link DWL-650 rev P.
+
+ Firmware image downloading needs a user space tool, prism2_srec.
+ It is available from http://hostap.epitest.fi/.
+
+config HOSTAP_FIRMWARE_NVRAM
+ bool Support for non-volatile firmware download
+ depends on HOSTAP_FIRMWARE
+ ---help---
+ Allow Host AP driver to write firmware images to the non-volatile
+ card memory, i.e. flash memory that survives power cycling.
+ Enable this option if you want to be able to change card firmware
+ permanently.
- Firmware image downloading needs user space tool, prism2_srec. It is
- available from http://hostap.epitest.fi/.
+ Firmware image downloading needs a user space tool, prism2_srec.
+ It is available from http://hostap.epitest.fi/.
config HOSTAP_PLX
tristate
Re: [PATCH] [TRIVIAL] prism54/islpci_eth.c: dev_kfree_skb in irq context
On 17/01/06, John W. Linville [EMAIL PROTECTED] wrote: On Wed, Jan 04, 2006 at 09:33:27AM +1030, Graham Gower wrote: On 03/01/06, Patrick McHardy [EMAIL PROTECTED] wrote: Graham Gower wrote: My logs were starting to fill with messages exatcly like that mentioned here: http://patchwork.netfilter.org/netfilter-devel/patch.pl?id=2840 In any event, the patch at the end of that link was never applied (it doesn't fix the other call to dev_kfree_skb). After applying my patch, I've not had any more messages in the logs. The patch has been applied to 2.6.15-rc. Only the first hunk of your patch is still required, but it doesn't apply anymore. Can you send a new patch against 2.6.15 please? Ok, here's a new one. Hope I got it right this time. Signed-off-by: Graham Gower [EMAIL PROTECTED] --- linux-2.6.15/drivers/net/wireless/prism54/islpci_eth.c.orig +++ linux-2.6.15/drivers/net/wireless/prism54/islpci_eth.c @@ -177,7 +177,7 @@ #endif newskb-dev = skb-dev; - dev_kfree_skb(skb); + dev_kfree_skb_irq(skb); skb = newskb; } } - I'm planning to apply this patch with the following changelog commentary: [PATCH] prism54/islpci_eth.c: dev_kfree_skb used with interrupts disabled dev_kfree_skb should not be used with interrupts disabled. Change to use dev_kfree_skb_irq instead. Is that alright w/ everyone? Fine by me. - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] networking ipv4: remove total socket usage count from /proc/net/sockstat
In article [EMAIL PROTECTED] (at Mon, 16 Jan 2006 17:33:59 -0500), Andy Gospodarek [EMAIL PROTECTED] says: On 1/16/06, Jesper Juhl [EMAIL PROTECTED] wrote: Maybe if you described your current problem someone could suggest a solution... Sure, I'd be glad to. If I add up all the entries from the procfiles (in /proc/net) on my system : I find there are a total of 54 sockets open on my system. Now this seems to differ from the value in /proc/net/sockstat: # cat sockstat sockets: used 59 : So we are off by 5. I added some code around the stat collection used in sockstat to get more detailed info about those sockets and the output is here. The values are family[protocol family][socket family]. : Total = 59 All of these numbers match up with what we saw above, except the INET/RAW and INET6/RAW sockets. It seems they aren't being counted correctly -- which accounts for the 5 missing sockets. The decrementing of these values is in sock_release() and seems to get done correctly other times RAW sockets are created, but not for the 5 sockets in question. This is because we have several internal unhashed raw sockets in kernel, which are not counted in the raw entry, but in sockets. --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: Pull request for wireless-2.6
John W. Linville wrote: The following changes since commit 4a8e4a270b89030bdeb09d2f8cef7cfe9a50e54d: Linus Torvalds: Merge git://oss.sgi.com:8090/oss/git/xfs-2.6 are found in the git repository at: git://git.tuxdriver.com/git/wireless-2.6.git Is it on a branch? [EMAIL PROTECTED] netdev-2.6]$ git pull git://git.tuxdriver.com/git/wireless-2.6.git Already up-to-date. - 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: State of the Union: Wireless
On Wed, Jan 11, 2006 at 07:25:11PM +0100, Krzysztof Halasa wrote: 3. To have a master device which isn't represented by a network device (ifconfig doesn't show it etc.) but can be accessed only by the wireless tools. Or just using sysfs, echo and cat can be best tools. The slaves (netdevs) can be created and deleted at will. No obscure netdev with no apparent functionality and nothing special in the first, last or whichever netdev. Actually, there is a use for the master device. It can be used to monitor what is going on over the radio from all virtual APs/STAs, e.g., by running Ethereal on it. Isn't VLANs implemented in the same way with the netdev added by the driver (master device). The low-level wireless driver could do the same thing and then user space tools can add whatever virtual interfaces are needed. -- Jouni MalinenPGP id EFC895FA - 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/1] LSM-IPsec SELinux Authorize
On Mon, 16 Jan 2006, cxzhang wrote: +++ linux-2.6.15-mm3-cxzhang/net/key/af_key.c2006-01-13 18:41:02.0 -0500 @@ -1454,6 +1454,9 @@ static int pfkey_delete(struct sock *sk, if (x == NULL) return -ESRCH; +if ((err = security_xfrm_state_delete(x))) +return err; + Missing xfrm_state_put(). @@ -2273,6 +2276,8 @@ static int pfkey_spddelete(struct sock * err = 0; +if ((err = security_xfrm_policy_delete(xp))) +return err; Missing xfrm_pol_put(). In these cases, use a goto so you have a single cleanup path. +++ linux-2.6.15-mm3-cxzhang/net/xfrm/xfrm_user.c2006-01-13 18:44:27.0 -0500 @@ -370,6 +370,9 @@ static int xfrm_del_sa(struct sk_buff *s if (x == NULL) return -ESRCH; +if (err = security_xfrm_state_delete(x)) +return err; + Missing xfrm_state_put(). - James -- James Morris [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: linux networking kernel layer and STREAMS
From: Willem de Bruijn [EMAIL PROTECTED] Date: Mon, 16 Jan 2006 09:21:18 +0100 true, it's not new. The reason I ended up with it was purely practical and even grew out of a single-module system. Streams fitted our use-case, which is to run code in userspace, kernelspace and on the network-card. Communicating across 3 environments breaks function-calling as a viable method -- e.g., from context-switching. It can be used as a method to implement stream hand-off within the kernel, ofcourse. The stacked destination cache system we have for supporting IPSEC (which is btw a perfect streams application) can be used for this kind of task quite perfectly. In fact it was even used to support IPSEC offload onto a card supporting IPSEC hw assist by a set of patches posted here about a year ago. But you haven't even studied how the Linux networking works, so how would you know? I guess time is better spent reinventing the wheel. Since you don't know, by definition you're spewing. You don't know the Linux networking, and therefore you don't know whether existing mechanisms can solve your problem or not. Is research funding that hard to obtain these 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
