Re: Question about tcp hash function tcp_hashfn()
On Wed, May 31, 2006 at 11:41:27AM -0700, David Miller ([EMAIL PROTECTED])
wrote:
Worse: he folded the jenkins algorith result with
h ^= h 16;
h ^= h 8;
Destroying the coverage of the function.
It was done to simulate socket code which uses the same folding.
Leaving 32bit space is just wrong, consider hash table size with that
index.
You absolutely show not do this shifting on the jenkins hash
result, you destroy the distribution entirely. Just mask
it with the hash mask and that's all you need to do.
Brian is right, this is absolutely critical to using the Jenkins hash
correctly. You're unmixing the bits it worked so hard to mix.
That is wrong. And I have a code and picture to show that,
and you dont - prove me wrong :)
Attached code and picture which shows _exactly_ the same distribution for
folded and not folded Jenkins hash distribution, and it's artifact
compared to XOR hash.
Fairly distributed values being XORed produce still fairly distributed
value.
--
Evgeniy Polyakov
hash_comparison.png
Description: PNG image
#include stdlib.h
#include stdio.h
#include errno.h
typedef unsigned int u32;
typedef unsigned short u16;
typedef unsigned char u8;
typedef unsigned int __u32;
typedef unsigned short __u16;
typedef unsigned char __u8;
#include jhash.h
struct hash_entry
{
unsigned long counter;
};
static inline num2ip(__u8 a1, __u8 a2, __u8 a3, __u8 a4)
{
__u32 a = 0;
a |= a1;
a 8;
a |= a2;
a 8;
a |= a3;
a 8;
a |= a4;
return a;
}
static inline __u8 get_random_byte(void)
{
return 1 + (int) (255.0 * (rand() / (RAND_MAX + 1.0)));
}
static inline __u16 get_random_word(void)
{
return 1 + (int) (65536.0 * (rand() / (RAND_MAX + 1.0)));
}
unsigned int hash_addr(__u32 faddr, __u16 fport, __u32 laddr, __u16 lport)
{
unsigned int h = (laddr ^ lport) ^ (faddr ^ fport);
h ^= h 16;
h ^= h 8;
return h;
}
unsigned int hash_addr1(__u32 faddr, __u16 fport, __u32 laddr, __u16 lport)
{
u32 ports;
unsigned int h;
ports = lport;
ports = 16;
ports |= fport;
h = jhash_2words(faddr, laddr, ports);
//h ^= h 16;
//h ^= h 8;
return h;
}
int main()
{
struct hash_entry *table;
__u32 saddr, daddr;
__u16 sport, dport;
unsigned int hash, i, *results;
unsigned int hash_size = 65536, iter_num = 100;
table = malloc(hash_size * sizeof(struct hash_entry));
if (!table)
return -ENOMEM;
results = malloc(hash_size * sizeof(unsigned int));
if (!results)
return -ENOMEM;
for (i=0; ihash_size; ++i) {
results[i] = 0;
table[i].counter = 0;
}
srand(time(NULL));
daddr = num2ip(192, 168, 0, 1);
dport = htons(80);
for (i=0; ihash_size*iter_num; ++i) {
saddr = num2ip(get_random_byte(), get_random_byte(),
get_random_byte(), get_random_byte());
sport = get_random_word();
hash = hash_addr(saddr, sport, daddr, dport);
hash = (hash_size - 1);
table[hash].counter++;
}
for (i=0; ihash_size; ++i)
results[table[i].counter]++;
for (i=0; ihash_size; ++i)
printf(%u %u\n, i, results[i]);
//printf(%u %u\n, i, table[i].counter);
}
Re: Question about tcp hash function tcp_hashfn()
On Wed, May 31, 2006 at 12:29:55PM -0600, Brian F. G. Bidulock ([EMAIL PROTECTED]) wrote: Evgeniy, On Wed, 31 May 2006, Evgeniy Polyakov wrote: Worse: he folded the jenkins algorith result with h ^= h 16; h ^= h 8; Destroying the coverage of the function. It was done to simulate socket code which uses the same folding. Leaving 32bit space is just wrong, consider hash table size with that index. Btw, that probably requires some clarification. Since hash table size is definitely less than returned hash value, so higher bits are removed, for that case above folding is done both in XOR hash and my test case. It is possible to just remove higher bits, but fairly ditributed parts being xored produce still fairly distributed value. h ^= h 16; h ^= h 8; This does not remove high order bits in either function. Your comparison results are simply invalid with these two lines in place. It is hash function, but not function which creates index inside hash table. Index is created by removing high order bits with ( 0x). I've present the new simple code and test results which show that folded and not folded Jenkins hashes _do_ produce _exactly_ the same distribution. I think I've already said that fairly distributed values being xored produce still fairly distributed value, so parts of 32bit fairly distributed hash after being xored with each other still produce fairly distributed 32bit space. --brian -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Question about tcp hash function tcp_hashfn()
From: Evgeniy Polyakov [EMAIL PROTECTED] Date: Thu, 1 Jun 2006 10:12:36 +0400 I've present the new simple code and test results which show that folded and not folded Jenkins hashes _do_ produce _exactly_ the same distribution. Ok I believe you now :) I think I've already said that fairly distributed values being xored produce still fairly distributed value, so parts of 32bit fairly distributed hash after being xored with each other still produce fairly distributed 32bit space. It would make a good research paper for someone mathmatically inclined enough :) - 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: Question about tcp hash function tcp_hashfn()
Evgeniy,
On Thu, 01 Jun 2006, Evgeniy Polyakov wrote:
for (i=0; ihash_size*iter_num; ++i) {
saddr = num2ip(get_random_byte(), get_random_byte(),
get_random_byte(), get_random_byte());
sport = get_random_word();
You still have a problem: you cannot use a pseudo-random number
generator to generate the sample set as the pseudo-random number
generator function itself can interact with the hash.
Try iterating through all 2**48 values or at least a sizeable
representative subset.
-
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: Question about tcp hash function tcp_hashfn()
David, On Wed, 31 May 2006, David Miller wrote: Ok I believe you now :) I'll believe it if he interates through a subset and gets the same results instead of using a pseudo-random number generator. I thought you said you were considering jenkins_3word(), not jenkins_2word()? - 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: Question about tcp hash function tcp_hashfn()
From: Brian F. G. Bidulock [EMAIL PROTECTED] Date: Thu, 1 Jun 2006 00:22:21 -0600 I thought you said you were considering jenkins_3word(), not jenkins_2word()? We could xor some of the inputs in order to use jenkins_2word(). - 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: Question about tcp hash function tcp_hashfn()
On Thu, Jun 01, 2006 at 12:18:25AM -0600, Brian F. G. Bidulock ([EMAIL
PROTECTED]) wrote:
Evgeniy,
On Thu, 01 Jun 2006, Evgeniy Polyakov wrote:
for (i=0; ihash_size*iter_num; ++i) {
saddr = num2ip(get_random_byte(), get_random_byte(),
get_random_byte(), get_random_byte());
sport = get_random_word();
You still have a problem: you cannot use a pseudo-random number
generator to generate the sample set as the pseudo-random number
generator function itself can interact with the hash.
Try iterating through all 2**48 values or at least a sizeable
representative subset.
Since pseudo-randomness affects both folded and not folded hash
distribution, it can not end up in different results.
You are right that having test with 2^48 values is really interesting,
but it will take ages on my test machine :)
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc5-mm1 lockdep output
On Wed, 2006-05-31 at 17:04 -0700, Jesse Brandeburg wrote:
well, when running e1000 through some code paths on FC4 +
2.6.17-rc5-mm1 + ingo's latest rollup patch, with this lockdep debug
option enabled I got this:
e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex
==
[ BUG: bad unlock ordering detected! ]
--
mDNSResponder/2361 is trying to release lock (in_dev-mc_list_lock) at:
[81233f5a] ip_mc_add_src+0x85/0x1f8
but the next lock to release is:
(im-lock){-+..}, at: [81233f52] ip_mc_add_src+0x7d/0x1f8
other info that might help us debug this:
2 locks held by mDNSResponder/2361:
#0: (rtnl_mutex){--..}, at: [81253741] mutex_lock+0x27/0x2c
#1: (in_dev-mc_list_lock){-.-?}, at: [81233f14]
ip_mc_add_src+0x3f/0x1f8
ok another out of order one in igmp ...
Signed-off-by: Arjan van de Ven [EMAIL PROTECTED]
---
net/ipv4/igmp.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.17-rc5-mm1.5/net/ipv4/igmp.c
===
--- linux-2.6.17-rc5-mm1.5.orig/net/ipv4/igmp.c
+++ linux-2.6.17-rc5-mm1.5/net/ipv4/igmp.c
@@ -1646,7 +1646,7 @@ static int ip_mc_add_src(struct in_devic
return -ESRCH;
}
spin_lock_bh(pmc-lock);
- read_unlock(in_dev-mc_list_lock);
+ read_unlock_non_nested(in_dev-mc_list_lock);
#ifdef CONFIG_IP_MULTICAST
sf_markstate(pmc);
-
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, -rc5-mm1] lock validator: special locking: net/ipv4/igmp.c #2
* Jesse Brandeburg [EMAIL PROTECTED] wrote: well, when running e1000 through some code paths on FC4 + 2.6.17-rc5-mm1 + ingo's latest rollup patch, with this lockdep debug option enabled I got this: e1000: eth1: e1000_watchdog_task: NIC Link is Up 1000 Mbps Full Duplex == [ BUG: bad unlock ordering detected! ] -- mDNSResponder/2361 is trying to release lock (in_dev-mc_list_lock) at: [81233f5a] ip_mc_add_src+0x85/0x1f8 ok, could you try the patch below? (i also updated the rollup with this fix) Ingo - Subject: lock validator: special locking: net/ipv4/igmp.c #2 From: Ingo Molnar [EMAIL PROTECTED] another case of non-nested unlocking igmp.c. Signed-off-by: Ingo Molnar [EMAIL PROTECTED] --- net/ipv4/igmp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/net/ipv4/igmp.c === --- linux.orig/net/ipv4/igmp.c +++ linux/net/ipv4/igmp.c @@ -1646,7 +1646,7 @@ static int ip_mc_add_src(struct in_devic return -ESRCH; } spin_lock_bh(pmc-lock); - read_unlock(in_dev-mc_list_lock); + read_unlock_non_nested(in_dev-mc_list_lock); #ifdef CONFIG_IP_MULTICAST sf_markstate(pmc); - 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: Question about tcp hash function tcp_hashfn()
Evgeniy, On Thu, 01 Jun 2006, Evgeniy Polyakov wrote: Since pseudo-randomness affects both folded and not folded hash distribution, it can not end up in different results. Yes it would, so to rule out pseudo-random effects the pseudo- random number generator must be removed. You are right that having test with 2^48 values is really interesting, but it will take ages on my test machine :) Try a usable subset; no pseudo-random number generator. - 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: Question about tcp hash function tcp_hashfn()
On Thu, Jun 01, 2006 at 12:46:08AM -0600, Brian F. G. Bidulock ([EMAIL PROTECTED]) wrote: Since pseudo-randomness affects both folded and not folded hash distribution, it can not end up in different results. Yes it would, so to rule out pseudo-random effects the pseudo- random number generator must be removed. You are right that having test with 2^48 values is really interesting, but it will take ages on my test machine :) Try a usable subset; no pseudo-random number generator. I've run it for 2^30 - the same result: folded and not folded Jenkins hash behave the same and still both results produce exactly the same artifacts compared to XOR hash. Btw, XOR hash, as completely stateless, can be used to show how Linux pseudo-random generator works for given subset - it's average of distribution is very good. -- Evgeniy Polyakov - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
modprobe iptable_filter (errors out with Invalid Argument) iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -j SNAT --to 192.168.1.1 (usually errors out with Invalid Argument, sometimes succeeds, when succeeds then the rule works fine) Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. Have not gotten 2.6.15 to work with one evening of tinkering - the irq patch was not sufficent, there is something more broken in booting that I dodn't figure out yet. So no test results for 2.6.15 yet. -- Meelis Roos ([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: Question about tcp hash function tcp_hashfn()
Evgeniy, On Thu, 01 Jun 2006, Evgeniy Polyakov wrote: On Thu, Jun 01, 2006 at 12:46:08AM -0600, Brian F. G. Bidulock ([EMAIL PROTECTED]) wrote: Since pseudo-randomness affects both folded and not folded hash distribution, it can not end up in different results. Yes it would, so to rule out pseudo-random effects the pseudo- random number generator must be removed. You are right that having test with 2^48 values is really interesting, but it will take ages on my test machine :) Try a usable subset; no pseudo-random number generator. I've run it for 2^30 - the same result: folded and not folded Jenkins hash behave the same and still both results produce exactly the same artifacts compared to XOR hash. But not without the pseudo-random number generation... ? Btw, XOR hash, as completely stateless, can be used to show how Linux pseudo-random generator works for given subset - it's average of distribution is very good. But its distribution might auto-correlate with the Jenkins function. The only way to be sure is to remove the pseudo-random number generator. Just try incrementing from, say, 10.0.0.0:1 up, resetting port number to 1 at 16000, and just incrementing the IP address when the port number wraps, instead of pseudo-random, through 2^30 loops for both. If the same artifacts emerge, I give in. Can you show the same artifacts for jenkins_3word? - 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 netdev-2.6#upstream] net: au1000_eth: PHY framework conversion
convert au1000_eth driver to use PHY framework and garbage collected
functions and identifiers that became unused/obsolete in the process
Signed-off-by: Herbert Valerio Riedel [EMAIL PROTECTED]
---
this is a resend of
http://marc.theaimsgroup.com/?l=linux-netdevm=114746547301867w=2
rebasedhandmerged to netdev-2.6#upstream (i.e. on top of sergei's
probe code cleanup patch)
drivers/net/Kconfig |1
drivers/net/au1000_eth.c | 1602 +++---
drivers/net/au1000_eth.h | 134
3 files changed, 378 insertions(+), 1359 deletions(-)
616e5a012a927d401befcbed37b77c3ea42da5a5
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index f499a3b..520765d 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -447,6 +447,7 @@ config MIPS_GT96100ETH
config MIPS_AU1X00_ENET
bool MIPS AU1000 Ethernet support
depends on NET_ETHERNET SOC_AU1X00
+ select PHYLIB
select CRC32
help
If you have an Alchemy Semi AU1X00 based system
diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index e1fe960..038d5fc 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -9,6 +9,9 @@
* Update: 2004 Bjoern Riemer, [EMAIL PROTECTED]
* or [EMAIL PROTECTED]: fixed the link beat detection with
* ioctls (SIOCGMIIPHY)
+ * Copyright 2006 Herbert Valerio Riedel [EMAIL PROTECTED]
+ * converted to use linux-2.6.x's PHY framework
+ *
* Author: MontaVista Software, Inc.
* [EMAIL PROTECTED] or [EMAIL PROTECTED]
*
@@ -53,6 +56,7 @@ #include linux/mii.h
#include linux/skbuff.h
#include linux/delay.h
#include linux/crc32.h
+#include linux/phy.h
#include asm/mipsregs.h
#include asm/irq.h
#include asm/io.h
@@ -88,17 +92,15 @@ static int au1000_tx(struct sk_buff *, s
static int au1000_rx(struct net_device *);
static irqreturn_t au1000_interrupt(int, void *, struct pt_regs *);
static void au1000_tx_timeout(struct net_device *);
-static int au1000_set_config(struct net_device *dev, struct ifmap *map);
static void set_rx_mode(struct net_device *);
static struct net_device_stats *au1000_get_stats(struct net_device *);
-static void au1000_timer(unsigned long);
static int au1000_ioctl(struct net_device *, struct ifreq *, int);
static int mdio_read(struct net_device *, int, int);
static void mdio_write(struct net_device *, int, int, u16);
-static void dump_mii(struct net_device *dev, int phy_id);
+static void au1000_adjust_link(struct net_device *);
+static void enable_mac(struct net_device *, int);
// externs
-extern void ack_rise_edge_irq(unsigned int);
extern int get_ethernet_addr(char *ethernet_addr);
extern void str2eaddr(unsigned char *ea, unsigned char *str);
extern char * __init prom_getcmdline(void);
@@ -126,705 +128,83 @@ static unsigned char au1000_mac_addr[6]
0x00, 0x50, 0xc2, 0x0c, 0x30, 0x00
};
-#define nibswap(x) x) 4) 0x0f) | (((x) 4) 0xf0))
-#define RUN_AT(x) (jiffies + (x))
-
-// For reading/writing 32-bit words from/to DMA memory
-#define cpu_to_dma32 cpu_to_be32
-#define dma32_to_cpu be32_to_cpu
-
struct au1000_private *au_macs[NUM_ETH_INTERFACES];
-/* FIXME
- * All of the PHY code really should be detached from the MAC
- * code.
+/*
+ * board-specific configurations
+ *
+ * PHY detection algorithm
+ *
+ * If AU1XXX_PHY_STATIC_CONFIG is undefined, the PHY setup is
+ * autodetected:
+ *
+ * mii_probe() first searches the current MAC's MII bus for a PHY,
+ * selecting the first (or last, if AU1XXX_PHY_SEARCH_HIGHEST_ADDR is
+ * defined) PHY address not already claimed by another netdev.
+ *
+ * If nothing was found that way when searching for the 2nd ethernet
+ * controller's PHY and AU1XXX_PHY1_SEARCH_ON_MAC0 is defined, then
+ * the first MII bus is searched as well for an unclaimed PHY; this is
+ * needed in case of a dual-PHY accessible only through the MAC0's MII
+ * bus.
+ *
+ * Finally, if no PHY is found, then the corresponding ethernet
+ * controller is not registered to the network subsystem.
*/
-/* Default advertise */
-#define GENMII_DEFAULT_ADVERTISE \
- ADVERTISED_10baseT_Half | ADVERTISED_10baseT_Full | \
- ADVERTISED_100baseT_Half | ADVERTISED_100baseT_Full | \
- ADVERTISED_Autoneg
-
-#define GENMII_DEFAULT_FEATURES \
- SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full | \
- SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full | \
- SUPPORTED_Autoneg
-
-int bcm_5201_init(struct net_device *dev, int phy_addr)
-{
- s16 data;
-
- /* Stop auto-negotiation */
- data = mdio_read(dev, phy_addr, MII_CONTROL);
- mdio_write(dev, phy_addr, MII_CONTROL, data ~MII_CNTL_AUTO);
-
- /* Set advertisement to 10/100 and Half/Full duplex
-* (full capabilities) */
- data = mdio_read(dev, phy_addr, MII_ANADV);
- data |= MII_NWAY_TX | MII_NWAY_TX_FDX | MII_NWAY_T_FDX | MII_NWAY_T;
- mdio_write(dev, phy_addr, MII_ANADV, data);
-
- /*
Re: Question about tcp hash function tcp_hashfn()
On Thu, Jun 01, 2006 at 01:11:25AM -0600, Brian F. G. Bidulock ([EMAIL
PROTECTED]) wrote:
Evgeniy,
On Thu, 01 Jun 2006, Evgeniy Polyakov wrote:
On Thu, Jun 01, 2006 at 12:46:08AM -0600, Brian F. G. Bidulock ([EMAIL
PROTECTED]) wrote:
Since pseudo-randomness affects both folded and not folded hash
distribution, it can not end up in different results.
Yes it would, so to rule out pseudo-random effects the pseudo-
random number generator must be removed.
You are right that having test with 2^48 values is really interesting,
but it will take ages on my test machine :)
Try a usable subset; no pseudo-random number generator.
I've run it for 2^30 - the same result: folded and not folded Jenkins
hash behave the same and still both results produce exactly the same
artifacts compared to XOR hash.
But not without the pseudo-random number generation... ?
How can I obtain (2^30)*6 bytes of truly random bytes?
Btw, XOR hash, as completely stateless, can be used to show how
Linux pseudo-random generator works for given subset - it's average of
distribution is very good.
But its distribution might auto-correlate with the Jenkins function.
The only way to be sure is to remove the pseudo-random number generator.
Just try incrementing from, say, 10.0.0.0:1 up, resetting port number
to 1 at 16000, and just incrementing the IP address when the port
number wraps, instead of pseudo-random, through 2^30 loops for both.
If the same artifacts emerge, I give in.
I've run it with following source ip/port selection algo:
if (++sport == 0) {
saddr++;
sport++;
}
Starting IP was 1.1.1.1 and sport was 1.
Destination IP and port are the same 192.168.0.1:80
Jenkins hash started to show different behaviour:
it does not have previous artefacts, but instead it's dispersion is
_much_ wider than in XOR case.
With following ip/port selection algo:
if (++sport == 0) {
//saddr++;
sport += 123;
}
I see yet another jenkins artefacts, but again different from previous
two.
But each time both folded and not folded hashes behave exactly the same.
Can you show the same artifacts for jenkins_3word?
What should be used as starting point there?
If I use 0 it is the same as jhash_2words().
If I use 123123 - artefacts are the same, just slighly shifted (I tested
only the latest test above though).
Looking into the code we can see that jhash_2words() is jhash_3words()
with zero C value, so it will show the same nature.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.17-rc4: netfilter LOG messages truncated via NETCONSOLE
On Wed, May 31, 2006 at 07:46:20PM +0200, Patrick McHardy wrote: [...] ip -s link doesn't show any dropped packets so far with any patch and I don't use traffic control that I'm aware of. But I'm not sure what to make of tc output, maybe because CONFIG_SHAPER is not set: # tc -s -d qdisc show RTNETLINK answers: Invalid argument Dump terminated Thats because you're missing CONFIG_NET_SCHED. Please enable it and try the tc command again, without it we can't see whether the qdisc (which is present even without CONFIG_NET_SCHED) just dropped the packets. ok, now tc -s -d qdisc show says (after noticing missing netconsole packets): qdisc pfifo_fast 0: dev eth0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 155031 bytes 2067 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 -- Frank - 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: Question about tcp hash function tcp_hashfn()
Evgeniy,
On Thu, 01 Jun 2006, Evgeniy Polyakov wrote:
For purely random numbers you could amplify thermal noise off an
open transitor junction (the audiofile's white noise generator)
and feed it into an analog to digital converter.
I've run it with following source ip/port selection algo:
if (++sport == 0) {
saddr++;
sport++;
}
Starting IP was 1.1.1.1 and sport was 1.
Destination IP and port are the same 192.168.0.1:80
Jenkins hash started to show different behaviour:
it does not have previous artefacts, but instead it's dispersion is
_much_ wider than in XOR case.
Aha! But perhaps this is too easy a data set. HTTP clients typically
dynamically allocate port numbers within a range and source address
are typically not less than a certain value. That is why I suggested
something like:
sport = 1;
saddr = 0x0a00; /* 10.0.0.0 */
...
if (++sport == 16000) {
sport = 1;
saddr++;
}
If this shows artifacts worse than XOR then more realistic gaps in the
input values will cause artifacts.
With following ip/port selection algo:
if (++sport == 0) {
//saddr++;
sport += 123;
}
I see yet another jenkins artefacts, but again different from previous
two.
Adding primes. Again, the arithmetic series of primes might auto-correlate
with the Jenkins function. Or it plain might not like gaps.
But each time both folded and not folded hashes behave exactly the same.
Can you show the same artifacts for jenkins_3word?
What should be used as starting point there?
If I use 0 it is the same as jhash_2words().
If I use 123123 - artefacts are the same, just slighly shifted (I tested
only the latest test above though).
Looking into the code we can see that jhash_2words() is jhash_3words()
with zero C value, so it will show the same nature.
Skip that then.
-
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: Refactor Netlink connector?
* James Morris [EMAIL PROTECTED] 2006-05-31 11:42
On Wed, 31 May 2006, jamal wrote:
To also answer your other email:
Look at security/selinux/nlmsgtab.c for example for NETLINK_ROUTE
and compare with NETLINK_GENERIC to see the hole. I was suggesting if
we started by just adding checks for NETLINK_GENERIC first in those
tables (currently lacking), that would be a good start.
They're currently mediated as a generic netlink socket type at a higher
level: they're not unmediated, just not fine grained enough to know what
kind of message is being sent.
It shouldn't be hard to split what is implemented in nlmsg_route_perms[]
for NETLINK_ROUTE into the definitions of the generic netlink
operations, could look like this:
struct genl_ops some_op = {
[...]
.perm= NETLINK_GENERIC_SOCKET__NLMSG_READ,
};
int genl_lookup_perm(u16 nlmsg_type, u8 cmd)
{
struct genl_family *family;
struct genl_ops *ops;
family = genl_family_find_byid(nlmsg_type);
ops = genl_get_cmd(cmd, family);
return ops-perm;
}
int genl_peek_cmd(struct nlmsghdr *nlh)
{
struct genlmsghdr *hdr = nlmsg_data(nlh);
if (nlh-nlmsglen nlmsg_msg_sizeo(GENL_HDRLEN))
return -EINVAL;
return hdr-cmd;
}
selinux_lookup() must take struct nlmsghdr as an additional argument
case SECCLASS_NETLINK_GENERIC_SOCKET:
cmd = genl_peek_cmd(nlh)
*perm = genl_lookup_perm(nlmsg_type, cmd);
break;
-
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: Question about tcp hash function tcp_hashfn()
On Thu, Jun 01, 2006 at 04:24:57AM -0600, Brian F. G. Bidulock ([EMAIL
PROTECTED]) wrote:
For purely random numbers you could amplify thermal noise off an
open transitor junction (the audiofile's white noise generator)
and feed it into an analog to digital converter.
It is also possible to look into window and count how many times sun
hides and shines... It is quite cloudy in Moscow though.
As Acrypto asynchronous crypto layer author I can use different hardware
crypto accelerators, but it is a topic for another discussion.
I've run it with following source ip/port selection algo:
if (++sport == 0) {
saddr++;
sport++;
}
Starting IP was 1.1.1.1 and sport was 1.
Destination IP and port are the same 192.168.0.1:80
Jenkins hash started to show different behaviour:
it does not have previous artefacts, but instead it's dispersion is
_much_ wider than in XOR case.
Aha! But perhaps this is too easy a data set. HTTP clients typically
dynamically allocate port numbers within a range and source address
are typically not less than a certain value. That is why I suggested
something like:
sport = 1;
saddr = 0x0a00; /* 10.0.0.0 */
...
if (++sport == 16000) {
sport = 1;
saddr++;
}
If this shows artifacts worse than XOR then more realistic gaps in the
input values will cause artifacts.
Specially for you :)
It does not have artifacts, but it's dispersion is wider than XOR one.
_Much_ wider, which tends to creation of some specially crafted source
distribution which ends up in totally broken fairness.
As usual folded and not folded versions behave exactly the same.
With following ip/port selection algo:
if (++sport == 0) {
//saddr++;
sport += 123;
}
I see yet another jenkins artefacts, but again different from previous
two.
Adding primes. Again, the arithmetic series of primes might auto-correlate
with the Jenkins function. Or it plain might not like gaps.
I want to confirm three things and one state:
1. Jenkins hash has some unacceptible artefacts in some source
address/port distributions, no matter if it has some law embedded or it
is (pseudo)-random set.
If there are bugs, bugs exist.
2. If it does not have artifacts it has unacceptible dispersion.
3. It is 3 times slower than XOR one (28 seconds for XOR for 2^29
iterations vs. 101 seconds jhash nonfolded and 109 jhash folded on my AMD64
3500+ 2.2 Ghz desktop).
4. I believe it can be tuned or has some gaps inside refactoring logic,
which can be fixed, but as is it can not be used for fair hash creation.
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[NET]: Add netif_tx_lock
On Thu, Jun 01, 2006 at 10:25:25AM +1000, herbert wrote:
I think this netpoll wrinkle means we also have to make
sure to set the xmit_lock_owner across the board.
You're right. In fact this can deadlock today for those drivers that
already make use of xmit_lock without setting the owner. So I suppose
something like net_xmit_lock to obtain xmit_lock is called for.
OK, here is a patch which does this.
[NET]: Add netif_tx_lock
Various drivers use xmit_lock internally to synchronise with their
transmission routines. They do so without setting xmit_lock_owner.
This is fine as long as netpoll is not in use.
With netpoll it is possible for deadlocks to occur if xmit_lock_owner
isn't set. This is because if a printk occurs while xmit_lock is held
and xmit_lock_owner is not set can cause netpoll to attempt to take
xmit_lock recursively.
While it is possible to resolve this by getting netpoll to use trylock,
it is suboptimal because netpoll's sole objective is to maximise the
chance of getting the printk out on the wire. So delaying or dropping
the message is to be avoided as much as possible.
So the only alternative is to always set xmit_lock_owner. The following
patch does this by introducing the netif_tx_lock family of functions that
take care of setting/unsetting xmit_lock_owner.
I renamed xmit_lock to _xmit_lock to indicate that it should not be used
directly. I didn't provide irq versions of the netif_tx_lock functions
since xmit_lock is meant to be a BH-disabling lock.
This is pretty much a straight text substitution except for a small bug
fix in winbond. It currently uses netif_stop_queue/spin_unlock_wait to
stop transmission. This is unsafe as an IRQ can potentially wake up the
queue. So it is safer to use netif_tx_disable.
The hamradio bits used spin_lock_irq but it is unnecessary as xmit_lock
must never be taken in an IRQ handler.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
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
diff --git a/Documentation/networking/netdevices.txt
b/Documentation/networking/netdevices.txt
index 3c0a5ba..847cedb 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -42,9 +42,9 @@ dev-get_stats:
Context: nominally process, but don't sleep inside an rwlock
dev-hard_start_xmit:
- Synchronization: dev-xmit_lock spinlock.
+ Synchronization: netif_tx_lock spinlock.
When the driver sets NETIF_F_LLTX in dev-features this will be
- called without holding xmit_lock. In this case the driver
+ called without holding netif_tx_lock. In this case the driver
has to lock by itself when needed. It is recommended to use a try lock
for this and return -1 when the spin lock fails.
The locking there should also properly protect against
@@ -62,12 +62,12 @@ dev-hard_start_xmit:
Only valid when NETIF_F_LLTX is set.
dev-tx_timeout:
- Synchronization: dev-xmit_lock spinlock.
+ Synchronization: netif_tx_lock spinlock.
Context: BHs disabled
Notes: netif_queue_stopped() is guaranteed true
dev-set_multicast_list:
- Synchronization: dev-xmit_lock spinlock.
+ Synchronization: netif_tx_lock spinlock.
Context: BHs disabled
dev-poll:
diff --git a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
index 1dae4b2..1d917ed 100644
--- a/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
+++ b/drivers/infiniband/ulp/ipoib/ipoib_multicast.c
@@ -821,7 +821,8 @@ void ipoib_mcast_restart_task(void *dev_
ipoib_mcast_stop_thread(dev, 0);
- spin_lock_irqsave(dev-xmit_lock, flags);
+ local_irq_save(flags);
+ netif_tx_lock(dev);
spin_lock(priv-lock);
/*
@@ -896,7 +897,8 @@ void ipoib_mcast_restart_task(void *dev_
}
spin_unlock(priv-lock);
- spin_unlock_irqrestore(dev-xmit_lock, flags);
+ netif_tx_unlock(dev);
+ local_irq_restore(flags);
/* We have to cancel outside of the spinlock */
list_for_each_entry_safe(mcast, tmcast, remove_list, list) {
diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
b/drivers/media/dvb/dvb-core/dvb_net.c
index 2f0f358..9fd8752 100644
--- a/drivers/media/dvb/dvb-core/dvb_net.c
+++ b/drivers/media/dvb/dvb-core/dvb_net.c
@@ -1052,7 +1052,7 @@ static void wq_set_multicast_list (void
dvb_net_feed_stop(dev);
priv-rx_mode = RX_MODE_UNI;
- spin_lock_bh(dev-xmit_lock);
+ netif_tx_lock_bh(dev);
if (dev-flags IFF_PROMISC) {
dprintk(%s: promiscuous mode\n, dev-name);
@@ -1077,7 +1077,7 @@ static void wq_set_multicast_list (void
}
}
- spin_unlock_bh(dev-xmit_lock);
+ netif_tx_unlock_bh(dev);
[RFT] r8169: MAC address change support
It works fine here (x86 so far) but I would welcome more testers.
The patch applies against 2.6.17-rcX.
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 0ad3310..4208d9a 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1381,6 +1381,41 @@ static void rtl8169_netpoll(struct net_d
}
#endif
+static void __rtl8169_set_mac_addr(struct net_device *dev, void __iomem
*ioaddr)
+{
+ unsigned int i, j;
+
+ RTL_W8(Cfg9346, Cfg9346_Unlock);
+ for (i = 0; i 2; i++) {
+ __le32 l = 0;
+
+ for (j = 0; j 4; j++) {
+ l = 8;
+ l |= dev-dev_addr[4*i + j];
+ }
+ RTL_W32(MAC0 + 4*i, cpu_to_be32(l));
+ }
+ RTL_W8(Cfg9346, Cfg9346_Lock);
+}
+
+static int rtl8169_set_mac_addr(struct net_device *dev, void *p)
+{
+ struct rtl8169_private *tp = netdev_priv(dev);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr-sa_data))
+ return -EINVAL;
+
+ memcpy(dev-dev_addr, addr-sa_data, dev-addr_len);
+
+ if (netif_running(dev)) {
+ spin_lock_irq(tp-lock);
+ __rtl8169_set_mac_addr(dev, tp-mmio_addr);
+ spin_unlock_irq(tp-lock);
+ }
+ return 0;
+}
+
static void rtl8169_release_board(struct pci_dev *pdev, struct net_device *dev,
void __iomem *ioaddr)
{
@@ -1616,6 +1651,7 @@ rtl8169_init_one(struct pci_dev *pdev, c
dev-stop = rtl8169_close;
dev-tx_timeout = rtl8169_tx_timeout;
dev-set_multicast_list = rtl8169_set_rx_mode;
+ dev-set_mac_address = rtl8169_set_mac_addr;
dev-watchdog_timeo = RTL8169_TX_TIMEOUT;
dev-irq = pdev-irq;
dev-base_addr = (unsigned long) ioaddr;
@@ -1849,6 +1885,8 @@ rtl8169_hw_start(struct net_device *dev)
/* Enable all known interrupts by setting the interrupt mask. */
RTL_W16(IntrMask, rtl8169_intr_mask);
+ __rtl8169_set_mac_addr(dev, ioaddr);
+
netif_start_queue(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
monitor_during_oper on rt*pci (or any other pcmcia card)?
Hey, Florian approached me with a project where you need a pcmcia card that can have monitor_during_oper. I'd use bcm43xx but unfortunately the signal strength calculations are way off right now, and that's another requirement. Can the rt family of cards be made to support this with reliable signal strength readings? Or maybe I should rephrase the questions: which pcmcia cards can support this in their hardware? I might be willing to port their drivers over to d80211 just to get some more familiarity with the stack... Now, if no one can point me to ones that do have working signal strength, I'll probably have to do more reverse engineering on bcm43xx to get some reliable readings :/ Thanks, johannes signature.asc Description: This is a digitally signed message part
[PATCH 3/7] AMSO1100 WR / Event Definitions.
Sorry for this, but patch 3 is apparently getting eaten by the list servers for linux-kernel and netdev. Here is patch 3 as a tarball to see if it goes through... Steve. [PATCH 3/7] AMSO1100 WR / Event Definitions. amso1100_wr.tgz Description: application/compressed-tar
Re: Refactor Netlink connector?
On Thu, 1 Jun 2006, Thomas Graf wrote:
It shouldn't be hard to split what is implemented in nlmsg_route_perms[]
for NETLINK_ROUTE into the definitions of the generic netlink
operations, could look like this:
struct genl_ops some_op = {
[...]
.perm= NETLINK_GENERIC_SOCKET__NLMSG_READ,
};
We wouldn't need the socket class outside of SELinux, just the perm, so
something like:
NL_PERM_READ
int genl_peek_cmd(struct nlmsghdr *nlh)
{
struct genlmsghdr *hdr = nlmsg_data(nlh);
if (nlh-nlmsglen nlmsg_msg_sizeo(GENL_HDRLEN))
return -EINVAL;
return hdr-cmd;
}
Unless I'm mistaken, people are already multiplexing commands inside genl
commands (and if so, why even bother with registerable ops?).
I'll look at it in more detail soon.
--
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
[PATCH] softmac: complete shared key authentication
This patch finishes of the partially-complete shared key authentication
implementation in softmac.
The complication here is that we need to encrypt a management frame during
the authentication process. I don't think there are any other scenarios where
this would have to happen.
To get around this without causing too many headaches, we decided to just use
software encryption for this frame. The softmac config option now selects
IEEE80211_CRYPT_WEP so that we can ensure this available. This also involved
a modification to some otherwise unused ieee80211 API.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Acked-by: Johannes Berg [EMAIL PROTECTED]
Index: linux/net/ieee80211/softmac/ieee80211softmac_auth.c
===
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_auth.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_auth.c
@@ -107,6 +107,7 @@ ieee80211softmac_auth_queue(void *data)
printkl(KERN_WARNING PFX Authentication timed out with MAC_FMT\n,
MAC_ARG(net-bssid));
/* Remove this item from the queue */
spin_lock_irqsave(mac-lock, flags);
+ net-authenticating = 0;
ieee80211softmac_call_events_locked(mac,
IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT, net);
cancel_delayed_work(auth-work); /* just to make sure... */
list_del(auth-list);
@@ -212,13 +213,13 @@ ieee80211softmac_auth_resp(struct net_de
aq-state = IEEE80211SOFTMAC_AUTH_SHARED_RESPONSE;
spin_unlock_irqrestore(mac-lock, flags);
- /* Switch to correct channel for this network */
- mac-set_channel(mac-dev, net-channel);
-
- /* Send our response (How to encrypt?) */
+ /* Send our response */
ieee80211softmac_send_mgt_frame(mac, aq-net,
IEEE80211_STYPE_AUTH, aq-state);
- break;
+ return 0;
case IEEE80211SOFTMAC_AUTH_SHARED_PASS:
+ kfree(net-challenge);
+ net-challenge = NULL;
+ net-challenge_len = 0;
/* Check the status code of the response */
switch(auth-status) {
case WLAN_STATUS_SUCCESS:
@@ -229,6 +230,7 @@ ieee80211softmac_auth_resp(struct net_de
spin_unlock_irqrestore(mac-lock, flags);
printkl(KERN_NOTICE PFX Shared Key
Authentication completed with MAC_FMT\n,
MAC_ARG(net-bssid));
+ ieee80211softmac_call_events(mac,
IEEE80211SOFTMAC_EVENT_AUTHENTICATED, net);
break;
default:
printkl(KERN_NOTICE PFX Shared Key
Authentication with MAC_FMT failed, error code: %i\n,
Index: linux/net/ieee80211/softmac/ieee80211softmac_io.c
===
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_io.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_io.c
@@ -268,26 +268,27 @@ ieee80211softmac_reassoc_req(struct ieee
static u32
ieee80211softmac_auth(struct ieee80211_auth **pkt,
struct ieee80211softmac_device *mac, struct ieee80211softmac_network
*net,
- u16 transaction, u16 status)
+ u16 transaction, u16 status, int *encrypt_mpdu)
{
u8 *data;
+ int auth_mode = mac-ieee-sec.auth_mode;
+ int is_shared_response = (auth_mode == WLAN_AUTH_SHARED_KEY
+transaction == IEEE80211SOFTMAC_AUTH_SHARED_RESPONSE);
+
/* Allocate Packet */
(*pkt) = (struct ieee80211_auth *)ieee80211softmac_alloc_mgt(
2 + /* Auth Algorithm */
2 + /* Auth Transaction Seq */
2 + /* Status Code */
/* Challenge Text IE */
- mac-ieee-open_wep ? 0 :
- 1 + 1 + WLAN_AUTH_CHALLENGE_LEN
- );
+ is_shared_response ? 0 : 1 + 1 + net-challenge_len
+ );
if (unlikely((*pkt) == NULL))
return 0;
ieee80211softmac_hdr_3addr(mac, ((*pkt)-header),
IEEE80211_STYPE_AUTH, net-bssid, net-bssid);
/* Algorithm */
- (*pkt)-algorithm = mac-ieee-open_wep ?
- cpu_to_le16(WLAN_AUTH_OPEN) :
- cpu_to_le16(WLAN_AUTH_SHARED_KEY);
+ (*pkt)-algorithm = cpu_to_le16(auth_mode);
/* Transaction */
(*pkt)-transaction = cpu_to_le16(transaction);
/* Status */
@@ -295,18 +296,20 @@ ieee80211softmac_auth(struct ieee80211_a
data = (u8 *)(*pkt)-info_element;
/* Challenge Text */
- if(!mac-ieee-open_wep){
+ if (is_shared_response) {
*data = MFIE_TYPE_CHALLENGE;
[PATCH] softmac: Fix handling of authentication failure
My router blew up earlier, but exhibited some interesting behaviour during
its dying moments. It was broadcasting beacons but wouldn't respond to
any authentication requests.
I noticed that softmac wasn't playing nice with this, as I couldn't make it try
to connect to other networks after it had timed out authenticating to my ill
router.
To resolve this, I modified the softmac event/notify API to pass the event
code to the callback, so that callbacks being notified from
IEEE80211SOFTMAC_EVENT_ANY masks can make some judgement. In this case, the
ieee80211softmac_assoc callback needs to make a decision based upon whether
the association passed or failed.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Acked-by: Johannes Berg [EMAIL PROTECTED]
---
This may be worth considering for 2.6.17. The current code does not check the
response to an authentication request before associating, it just assumes it
was successful. This patch adds validation on that.
Index: linux/include/net/ieee80211softmac.h
===
--- linux.orig/include/net/ieee80211softmac.h
+++ linux/include/net/ieee80211softmac.h
@@ -359,7 +359,7 @@ extern void ieee80211softmac_stop(struct
* - context set to the context data you want passed
* The return value is 0, or an error.
*/
-typedef void (*notify_function_ptr)(struct net_device *dev, void *context);
+typedef void (*notify_function_ptr)(struct net_device *dev, int event_type,
void *context);
#define ieee80211softmac_notify(dev, event, fun, context)
ieee80211softmac_notify_gfp(dev, event, fun, context, GFP_KERNEL);
#define ieee80211softmac_notify_atomic(dev, event, fun, context)
ieee80211softmac_notify_gfp(dev, event, fun, context, GFP_ATOMIC);
Index: linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -164,12 +164,28 @@ network_matches_request(struct ieee80211
}
static void
-ieee80211softmac_assoc_notify(struct net_device *dev, void *context)
+ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
ieee80211softmac_assoc_work((void*)mac);
}
+static void
+ieee80211softmac_assoc_notify_auth(struct net_device *dev, int event_type,
void *context)
+{
+ struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+
+ switch (event_type) {
+ case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
+ ieee80211softmac_assoc_work((void*)mac);
+ break;
+ case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
+ case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
+ ieee80211softmac_disassoc(mac);
+ break;
+ }
+}
+
/* This function is called to handle userspace requests (asynchronously) */
void
ieee80211softmac_assoc_work(void *d)
@@ -249,7 +265,7 @@ ieee80211softmac_assoc_work(void *d)
* Maybe we can hope to have more memory after scanning
finishes ;)
*/
dprintk(KERN_INFO PFX Associate: Scanning for networks
first.\n);
- ieee80211softmac_notify(mac-dev,
IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify, NULL);
+ ieee80211softmac_notify(mac-dev,
IEEE80211SOFTMAC_EVENT_SCAN_FINISHED, ieee80211softmac_assoc_notify_scan, NULL);
if (ieee80211softmac_start_scan(mac))
dprintk(KERN_INFO PFX Associate: failed to
initiate scan. Is device up?\n);
return;
@@ -284,7 +300,7 @@ ieee80211softmac_assoc_work(void *d)
* otherwise adding the notification would be racy. */
if (!ieee80211softmac_auth_req(mac, found)) {
dprintk(KERN_INFO PFX cannot associate without being
authenticated, requested authentication\n);
- ieee80211softmac_notify_internal(mac,
IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify, NULL,
GFP_KERNEL);
+ ieee80211softmac_notify_internal(mac,
IEEE80211SOFTMAC_EVENT_ANY, found, ieee80211softmac_assoc_notify_auth, NULL,
GFP_KERNEL);
} else {
printkl(KERN_WARNING PFX Not authenticated, but
requesting authentication failed. Giving up to associate\n);
ieee80211softmac_call_events(mac,
IEEE80211SOFTMAC_EVENT_ASSOCIATE_FAILED, found);
Index: linux/net/ieee80211/softmac/ieee80211softmac_event.c
===
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_event.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_event.c
@@ -77,7 +77,7 @@ ieee80211softmac_notify_callback(void *d
struct ieee80211softmac_event event
[PATCH] softmac: unified capabilities computation
From: Joseph Jezak [EMAIL PROTECTED]
This patch moves the capabilities field computation to a function for clarity
and adds some previously unimplemented bits.
Signed off by Joseph Jezak [EMAIL PROTECTED]
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Acked-By: Johannes Berg [EMAIL PROTECTED]
---
Index: linux/net/ieee80211/softmac/ieee80211softmac_io.c
===
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_io.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_io.c
@@ -149,6 +149,56 @@ ieee80211softmac_hdr_3addr(struct ieee80
* shouldn't the sequence number be in ieee80211? */
}
+static u16
+ieee80211softmac_capabilities(struct ieee80211softmac_device *mac,
+ struct ieee80211softmac_network *net)
+{
+ u16 capability = 0;
+
+ /* ESS and IBSS bits are set according to the current mode */
+ switch (mac-ieee-iw_mode) {
+ case IW_MODE_INFRA:
+ capability = cpu_to_le16(WLAN_CAPABILITY_ESS);
+ break;
+ case IW_MODE_ADHOC:
+ capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
+ break;
+ case IW_MODE_AUTO:
+ capability = net-capabilities
+ (WLAN_CAPABILITY_ESS|WLAN_CAPABILITY_IBSS);
+ break;
+ default:
+ /* bleh. we don't ever go to these modes */
+ printk(KERN_ERR PFX invalid iw_mode!\n);
+ break;
+ }
+
+ /* CF Pollable / CF Poll Request */
+ /* Needs to be implemented, for now, the 0's == not supported */
+
+ /* Privacy Bit */
+ capability |= mac-ieee-sec.level ?
+ cpu_to_le16(WLAN_CAPABILITY_PRIVACY) : 0;
+
+ /* Short Preamble */
+ /* Always supported: we probably won't ever be powering devices which
+* dont support this... */
+ capability |= WLAN_CAPABILITY_SHORT_PREAMBLE;
+
+ /* PBCC */
+ /* Not widely used */
+
+ /* Channel Agility */
+ /* Not widely used */
+
+ /* Short Slot */
+ /* Will be implemented later */
+
+ /* DSSS-OFDM */
+ /* Not widely used */
+
+ return capability;
+}
/*
* Create Management packets
@@ -179,27 +229,6 @@ ieee80211softmac_assoc_req(struct ieee80
return 0;
ieee80211softmac_hdr_3addr(mac, ((*pkt)-header),
IEEE80211_STYPE_ASSOC_REQ, net-bssid, net-bssid);
- /* Fill in capability Info */
- switch (mac-ieee-iw_mode) {
- case IW_MODE_INFRA:
- (*pkt)-capability = cpu_to_le16(WLAN_CAPABILITY_ESS);
- break;
- case IW_MODE_ADHOC:
- (*pkt)-capability = cpu_to_le16(WLAN_CAPABILITY_IBSS);
- break;
- case IW_MODE_AUTO:
- (*pkt)-capability = net-capabilities
(WLAN_CAPABILITY_ESS|WLAN_CAPABILITY_IBSS);
- break;
- default:
- /* bleh. we don't ever go to these modes */
- printk(KERN_ERR PFX invalid iw_mode!\n);
- break;
- }
- /* Need to add this
- (*pkt)-capability |= mac-ieee-short_slot ?
- cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT_TIME) : 0;
-*/
- (*pkt)-capability |= mac-ieee-sec.level ?
cpu_to_le16(WLAN_CAPABILITY_PRIVACY) : 0;
/* Fill in Listen Interval (?) */
(*pkt)-listen_interval = cpu_to_le16(10);
@@ -239,17 +268,9 @@ ieee80211softmac_reassoc_req(struct ieee
return 0;
ieee80211softmac_hdr_3addr(mac, ((*pkt)-header),
IEEE80211_STYPE_REASSOC_REQ, net-bssid, net-bssid);
- /* Fill in capability Info */
- (*pkt)-capability = mac-ieee-iw_mode == IW_MODE_MASTER ?
- cpu_to_le16(WLAN_CAPABILITY_ESS) :
- cpu_to_le16(WLAN_CAPABILITY_IBSS);
- /*
- (*pkt)-capability |= mac-ieee-short_slot ?
- cpu_to_le16(WLAN_CAPABILITY_SHORT_SLOT_TIME) : 0;
-*/
- (*pkt)-capability |= mac-ieee-sec.level ?
- cpu_to_le16(WLAN_CAPABILITY_PRIVACY) : 0;
-
+ /* Fill in the capabilities */
+ (*pkt)-capability = ieee80211softmac_capabilities(mac, net);
+
/* Fill in Listen Interval (?) */
(*pkt)-listen_interval = cpu_to_le16(10);
/* Fill in the current AP MAC */
-
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/2] iWARP Connection Manager.
On Wed, 2006-05-31 at 15:22 -0700, Sean Hefty wrote:
Steve Wise wrote:
+/*
+ * Release a reference on cm_id. If the last reference is being removed
+ * and iw_destroy_cm_id is waiting, wake up the waiting thread.
+ */
+static int iwcm_deref_id(struct iwcm_id_private *cm_id_priv)
+{
+ int ret = 0;
+
+ BUG_ON(atomic_read(cm_id_priv-refcount)==0);
+ if (atomic_dec_and_test(cm_id_priv-refcount)) {
+ BUG_ON(!list_empty(cm_id_priv-work_list));
+ if (waitqueue_active(cm_id_priv-destroy_wait)) {
+ BUG_ON(cm_id_priv-state != IW_CM_STATE_DESTROYING);
+ BUG_ON(test_bit(IWCM_F_CALLBACK_DESTROY,
+ cm_id_priv-flags));
+ ret = 1;
+ wake_up(cm_id_priv-destroy_wait);
We recently changed the RDMA CM, IB CM, and a couple of other modules from
using
wait objects to completions. This avoids a race condition between
decrementing
the reference count, which allows destruction to proceed, and calling wake_up
on
a freed cm_id. My guess is that you may need to do the same.
Good catch. Yes, the IW CM suffers from the same race condition. I'll
change this to use completions...
Can you also explain the use of the return value here? It's ignored below in
rem_ref() and destroy_cm_id().
The return value is supposed to indicate whether this call to deref
_may_ have resulted in waking up another thread and the cm_id being
freed. Its used in cm_work_handler(), in conjunction with setting the
IWCM_F_CALLBACK_DESTROY flag to know whether the cm_id needs to be freed
on the callback path.
+static void add_ref(struct iw_cm_id *cm_id)
+{
+ struct iwcm_id_private *cm_id_priv;
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ atomic_inc(cm_id_priv-refcount);
+}
+
+static void rem_ref(struct iw_cm_id *cm_id)
+{
+ struct iwcm_id_private *cm_id_priv;
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ iwcm_deref_id(cm_id_priv);
+}
+
+/*
+ * CM_ID -- CLOSING
+ *
+ * Block if a passive or active connection is currenlty being processed.
Then
+ * process the event as follows:
+ * - If we are ESTABLISHED, move to CLOSING and modify the QP state
+ * based on the abrupt flag
+ * - If the connection is already in the CLOSING or IDLE state, the peer is
+ * disconnecting concurrently with us and we've already seen the
+ * DISCONNECT event -- ignore the request and return 0
+ * - Disconnect on a listening endpoint returns -EINVAL
+ */
+int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt)
+{
+ struct iwcm_id_private *cm_id_priv;
+ unsigned long flags;
+ int ret = 0;
+
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ /* Wait if we're currently in a connect or accept downcall */
+ wait_event(cm_id_priv-connect_wait,
+ !test_bit(IWCM_F_CONNECT_WAIT, cm_id_priv-flags));
Am I understanding this check correctly? You're checking to see if the user
has
called iw_cm_disconnect() at the same time that they called iw_cm_connect()
or
iw_cm_accept(). Are connect / accept blocking, or are you just waiting for
an
event?
The CM must wait for the low level provider to finish a connect() or
accept() operation before telling the low level provider to disconnect
via modifying the iwarp QP. Regardless of whether they block, this
disconnect can happen concurrently with the connect/accept so we need to
hold the disconnect until the connect/accept completes.
+
+ spin_lock_irqsave(cm_id_priv-lock, flags);
+ switch (cm_id_priv-state) {
+ case IW_CM_STATE_ESTABLISHED:
+ cm_id_priv-state = IW_CM_STATE_CLOSING;
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ if (cm_id_priv-qp) { /* QP could be nul for user-mode
client */
+ if (abrupt)
+ ret = iwcm_modify_qp_err(cm_id_priv-qp);
+ else
+ ret = iwcm_modify_qp_sqd(cm_id_priv-qp);
+ /*
+* If both sides are disconnecting the QP could
+* already be in ERR or SQD states
+*/
+ ret = 0;
+ }
+ else
+ ret = -EINVAL;
+ break;
+ case IW_CM_STATE_LISTEN:
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ ret = -EINVAL;
+ break;
+ case IW_CM_STATE_CLOSING:
+ /* remote peer closed first */
+ case IW_CM_STATE_IDLE:
+ /* accept or connect returned !0 */
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ break;
+ case IW_CM_STATE_CONN_RECV:
+ /*
+* App called disconnect before/without calling accept after
+*
Re: 2.6.17-rc4: netfilter LOG messages truncated via NETCONSOLE
Frank van Maarseveen wrote: ok, now tc -s -d qdisc show says (after noticing missing netconsole packets): qdisc pfifo_fast 0: dev eth0 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 155031 bytes 2067 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Mhh no dropped packets. I tried to reproduce the problem by changing netconsole to always use the dev_queue_xmit path, but works flawlessly for me. Please try to find out if the packets are lost before or after the qdisc by looking at the packet counter. BTW: You still haven't sent me the packet dump (from the originating machine). - 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: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Meelis Roos wrote: Meelis, it would really help if you could try 2.6.16 and in case that doesn't work 2.6.15 to give an idea about whether this is a recent regression or an old problem. We had a number of changes in this area in the last two kernel versions that could be related. Have not gotten 2.6.15 to work with one evening of tinkering - the irq patch was not sufficent, there is something more broken in booting that I dodn't figure out yet. So no test results for 2.6.15 yet. Then lets try something different. Please enable the DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and post the results, if any. - 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: monitor_during_oper on rt*pci (or any other pcmcia card)?
Hi, Florian approached me with a project where you need a pcmcia card that can have monitor_during_oper. I'd use bcm43xx but unfortunately the signal strength calculations are way off right now, and that's another requirement. Can the rt family of cards be made to support this with reliable signal strength readings? At this moment the rt2x00 drivers are not known for their correct signal strength reporting. The reading is coming out of the registers but it isn't working in all cases. Even the legacy drivers from Ralink self are not known for their correct behaviour but some issues around that have been traced to bugs in the driver. But it could be possible the registers are wrong as well. Or maybe I should rephrase the questions: which pcmcia cards can support this in their hardware? I might be willing to port their drivers over to d80211 just to get some more familiarity with the stack... Now, if no one can point me to ones that do have working signal strength, I'll probably have to do more reverse engineering on bcm43xx to get some reliable readings :/ Thanks, johannes pgp5diIlFzHSx.pgp Description: PGP signature
Re: [openib-general] Re: [PATCH 1/2] iWARP Connection Manager.
On Wed, 2006-05-31 at 15:22 -0700, Sean Hefty wrote:
Steve Wise wrote:
+/*
+ * Release a reference on cm_id. If the last reference is being removed
+ * and iw_destroy_cm_id is waiting, wake up the waiting thread.
+ */
+static int iwcm_deref_id(struct iwcm_id_private *cm_id_priv)
+{
+ int ret = 0;
+
+ BUG_ON(atomic_read(cm_id_priv-refcount)==0);
+ if (atomic_dec_and_test(cm_id_priv-refcount)) {
+ BUG_ON(!list_empty(cm_id_priv-work_list));
+ if (waitqueue_active(cm_id_priv-destroy_wait)) {
+ BUG_ON(cm_id_priv-state != IW_CM_STATE_DESTROYING);
+ BUG_ON(test_bit(IWCM_F_CALLBACK_DESTROY,
+ cm_id_priv-flags));
+ ret = 1;
+ wake_up(cm_id_priv-destroy_wait);
We recently changed the RDMA CM, IB CM, and a couple of other modules from
using
wait objects to completions. This avoids a race condition between
decrementing
the reference count, which allows destruction to proceed, and calling wake_up
on
a freed cm_id. My guess is that you may need to do the same.
Can you also explain the use of the return value here? It's ignored below in
rem_ref() and destroy_cm_id().
+static void add_ref(struct iw_cm_id *cm_id)
+{
+ struct iwcm_id_private *cm_id_priv;
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ atomic_inc(cm_id_priv-refcount);
+}
+
+static void rem_ref(struct iw_cm_id *cm_id)
+{
+ struct iwcm_id_private *cm_id_priv;
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ iwcm_deref_id(cm_id_priv);
+}
+
+/*
+ * CM_ID -- CLOSING
+ *
+ * Block if a passive or active connection is currenlty being processed.
Then
+ * process the event as follows:
+ * - If we are ESTABLISHED, move to CLOSING and modify the QP state
+ * based on the abrupt flag
+ * - If the connection is already in the CLOSING or IDLE state, the peer is
+ * disconnecting concurrently with us and we've already seen the
+ * DISCONNECT event -- ignore the request and return 0
+ * - Disconnect on a listening endpoint returns -EINVAL
+ */
+int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt)
+{
+ struct iwcm_id_private *cm_id_priv;
+ unsigned long flags;
+ int ret = 0;
+
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ /* Wait if we're currently in a connect or accept downcall */
+ wait_event(cm_id_priv-connect_wait,
+ !test_bit(IWCM_F_CONNECT_WAIT, cm_id_priv-flags));
Am I understanding this check correctly? You're checking to see if the user
has
called iw_cm_disconnect() at the same time that they called iw_cm_connect()
or
iw_cm_accept(). Are connect / accept blocking, or are you just waiting for
an
event?
Yes. The application (or the case I saw was user-mode exit logic after
ctrl-C) cleaning up at random times relative to connection
establishment.
+
+ spin_lock_irqsave(cm_id_priv-lock, flags);
+ switch (cm_id_priv-state) {
+ case IW_CM_STATE_ESTABLISHED:
+ cm_id_priv-state = IW_CM_STATE_CLOSING;
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ if (cm_id_priv-qp) { /* QP could be nul for user-mode
client */
+ if (abrupt)
+ ret = iwcm_modify_qp_err(cm_id_priv-qp);
+ else
+ ret = iwcm_modify_qp_sqd(cm_id_priv-qp);
+ /*
+* If both sides are disconnecting the QP could
+* already be in ERR or SQD states
+*/
+ ret = 0;
+ }
+ else
+ ret = -EINVAL;
+ break;
+ case IW_CM_STATE_LISTEN:
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ ret = -EINVAL;
+ break;
+ case IW_CM_STATE_CLOSING:
+ /* remote peer closed first */
+ case IW_CM_STATE_IDLE:
+ /* accept or connect returned !0 */
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ break;
+ case IW_CM_STATE_CONN_RECV:
+ /*
+* App called disconnect before/without calling accept after
+* connect_request event delivered.
+*/
+ spin_unlock_irqrestore(cm_id_priv-lock, flags);
+ break;
+ case IW_CM_STATE_CONN_SENT:
+ /* Can only get here if wait above fails */
+ default:
+ BUG_ON(1);
+ }
+
+ return ret;
+}
+EXPORT_SYMBOL(iw_cm_disconnect);
+static void destroy_cm_id(struct iw_cm_id *cm_id)
+{
+ struct iwcm_id_private *cm_id_priv;
+ unsigned long flags;
+ int ret;
+
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ /* Wait if we're currently in a
Re: Question about tcp hash function tcp_hashfn()
Evgeniy,
On Thu, 01 Jun 2006, Evgeniy Polyakov wrote:
I think the sun shines more in Moscow than in Edmonton, so it is not
so random. ;)
Specially for you :)
Thank you for being so gracious and patient with me.
It does not have artifacts, but it's dispersion is wider than XOR one.
_Much_ wider, which tends to creation of some specially crafted source
distribution which ends up in totally broken fairness.
As usual folded and not folded versions behave exactly the same.
With following ip/port selection algo:
if (++sport == 0) {
//saddr++;
sport += 123;
}
I see yet another jenkins artefacts, but again different from previous
two.
Adding primes. Again, the arithmetic series of primes might auto-correlate
with the Jenkins function. Or it plain might not like gaps.
I want to confirm three things and one state:
1. Jenkins hash has some unacceptible artefacts in some source
address/port distributions, no matter if it has some law embedded or it
is (pseudo)-random set.
If there are bugs, bugs exist.
True, artifacts appeared even in the basic arithmetic sequence of
primes. It is quite possible that a large set of natural sequences
might cause artifacts.
2. If it does not have artifacts it has unacceptible dispersion.
This is likely due to the relatively small sample sets; however, real
experienced data sets would be very small compared to the widest
possible set and might also contain structured gaps.
3. It is 3 times slower than XOR one (28 seconds for XOR for 2^29
iterations vs. 101 seconds jhash nonfolded and 109 jhash folded on my AMD64
3500+ 2.2 Ghz desktop).
Yes, it is slower by inspection.
4. I believe it can be tuned or has some gaps inside refactoring logic,
which can be fixed, but as is it can not be used for fair hash creation.
Yes, I now agree. And, for the purpose of dynamic hash sizing, high
dispersion is worse than artifacts.
For some realistic TCP data sets it appears that XOR is superior.
Thank you again for your efforts in resolving my doubts.
So what are your thoughts about my sequence number approach (for
connected sockets)?
-
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: pci_enable_msix throws up error
I have submitted a proposed fix for the below issue. Will wait for comments. Ravi -Original Message- From: Andi Kleen [mailto:[EMAIL PROTECTED] Sent: Friday, May 05, 2006 1:44 AM To: Ayaz Abdulla Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; Ananda. Raju; netdev@vger.kernel.org; Leonid Grossman Subject: Re: pci_enable_msix throws up error On Friday 05 May 2006 07:14, Ayaz Abdulla wrote: I noticed the same behaviour, i.e. can not use both MSI and MSIX without rebooting. I had sent a message to the maintainer of the MSI/MSIX source a few months ago and got a response that they were working on fixing it. Not sure what the progress is on it. The best way to make progress faster would be for someone like you who needs it to submit a patch to fix it then. -Andi - 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
[RFT] Realtek 8168 ethernet support
I've produced this patch which should allow the r8169 driver to work with the
new Realtek 8168 chips. These are found in PCI-Express form and onboard some
newer motherboards.
Does anyone own this hardware? I'm looking for someone to test it before I
send it on.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Index: linux/drivers/net/r8169.c
===
--- linux.orig/drivers/net/r8169.c
+++ linux/drivers/net/r8169.c
@@ -184,6 +184,7 @@ static const struct {
static struct pci_device_id rtl8169_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8169), },
+ { PCI_DEVICE(PCI_VENDOR_ID_REALTEK, 0x8168), },
{ PCI_DEVICE(PCI_VENDOR_ID_DLINK, 0x4300), },
{ PCI_DEVICE(0x16ec,0x0116), },
{ PCI_VENDOR_ID_LINKSYS,0x1032, PCI_ANY_ID, 0x0024, },
@@ -1398,6 +1399,7 @@ rtl8169_init_board(struct pci_dev *pdev,
struct net_device *dev;
struct rtl8169_private *tp;
int rc = -ENOMEM, i, acpi_idle_state = 0, pm_cap;
+ u32 mmio_base = 0;
assert(ioaddr_out != NULL);
@@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
}
}
- /* make sure PCI base addr 1 is MMIO */
- if (!(pci_resource_flags(pdev, 1) IORESOURCE_MEM)) {
- if (netif_msg_probe(tp)) {
- printk(KERN_ERR PFX
- region #1 not an MMIO resource, aborting\n);
- }
- rc = -ENODEV;
- goto err_out_mwi;
+ /* find MMIO resource: this varies between 8168 and 8169 */
+ for (i = 0; i 5; i++) {
+ /* check resource type */
+ if (!(pci_resource_flags(pdev, i) IORESOURCE_MEM))
+ continue;
+
+ /* check for weird/broken PCI region reporting */
+ if (pci_resource_len(pdev, i) R8169_REGS_SIZE)
+ continue;
+
+ mmio_base = pci_resource_start(pdev, i);
+ break;
}
- /* check for weird/broken PCI region reporting */
- if (pci_resource_len(pdev, 1) R8169_REGS_SIZE) {
+
+ if (mmio_base == 0) {
if (netif_msg_probe(tp)) {
printk(KERN_ERR PFX
- Invalid PCI region size(s), aborting\n);
+ couldn't find valid MMIO resource, aborting\n);
}
rc = -ENODEV;
goto err_out_mwi;
@@ -1490,7 +1496,7 @@ rtl8169_init_board(struct pci_dev *pdev,
pci_set_master(pdev);
/* ioremap MMIO region */
- ioaddr = ioremap(pci_resource_start(pdev, 1), R8169_REGS_SIZE);
+ ioaddr = ioremap(mmio_base, R8169_REGS_SIZE);
if (ioaddr == NULL) {
if (netif_msg_probe(tp))
printk(KERN_ERR PFX cannot remap MMIO, aborting\n);
-
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: Question about tcp hash function tcp_hashfn()
From: Brian F. G. Bidulock [EMAIL PROTECTED] Date: Thu, 1 Jun 2006 12:40:10 -0600 I think the sun shines more in Moscow than in Edmonton, so it is not so random. ;) Go Oilers :) - 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: [Bugme-new] [Bug 6613] New: iptables broken on 32-bit PReP (ARCH=ppc)
Then lets try something different. Please enable the DEBUG_IP_FIREWALL_USER define in net/ipv4/netfilter/ip_tables.c and post the results, if any. On bootup I get this in dmesg (one Bad offset has been added): ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. ip_conntrack version 2.4 (1536 buckets, 12288 max) - 224 bytes per conntrack translate_table: size 632 Bad offset cb437924 ip_nat_init: can't setup rules. And on iptables -t nat -L translate_table: size 632 Bad offset cb4368f4 ip_nat_init: can't setup rules. translate_table: size 632 Bad offset cb4368f4 ip_nat_init: can't setup rules. Seems iptable_nat does not load at all this time. Modprobe iptable_filter still fails, dmesg contains translate_table: size 632 Finished chain 1 Finished chain 2 Finished chain 3 Next modprobe iptable_nat gives translate_table: size 632 Bad offset c8e01944 ip_nat_init: can't setup rules. -- Meelis Roos ([EMAIL PROTECTED]) - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] iWARP Connection Manager.
Steve Wise wrote:
+int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt)
+{
+ struct iwcm_id_private *cm_id_priv;
+ unsigned long flags;
+ int ret = 0;
+
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ /* Wait if we're currently in a connect or accept downcall */
+ wait_event(cm_id_priv-connect_wait,
+ !test_bit(IWCM_F_CONNECT_WAIT, cm_id_priv-flags));
Am I understanding this check correctly? You're checking to see if the user has
called iw_cm_disconnect() at the same time that they called iw_cm_connect() or
iw_cm_accept(). Are connect / accept blocking, or are you just waiting for an
event?
The CM must wait for the low level provider to finish a connect() or
accept() operation before telling the low level provider to disconnect
via modifying the iwarp QP. Regardless of whether they block, this
disconnect can happen concurrently with the connect/accept so we need to
hold the disconnect until the connect/accept completes.
+EXPORT_SYMBOL(iw_cm_disconnect);
+static void destroy_cm_id(struct iw_cm_id *cm_id)
+{
+ struct iwcm_id_private *cm_id_priv;
+ unsigned long flags;
+ int ret;
+
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ /* Wait if we're currently in a connect or accept downcall. A
+* listening endpoint should never block here. */
+ wait_event(cm_id_priv-connect_wait,
+ !test_bit(IWCM_F_CONNECT_WAIT, cm_id_priv-flags));
Same question/comment as above.
Same answer.
There's a difference between trying to handle the user calling
disconnect/destroy at the same time a call to accept/connect is active, versus
the user calling disconnect/destroy after accept/connect have returned. In the
latter case, I think you're fine. In the first case, this is allowing a user to
call destroy at the same time that they're calling accept/connect.
Additionally, there's no guarantee that the F_CONNECT_WAIT flag has been set by
accept/connect by the time disconnect/destroy tests it.
- Sean
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] new qla3xxx NIC Driver v2.02.00k30
All, Forth submission for the upstream inclusion of the qla3xxx Ethernet driver. This is a complementary network driver for our ISP4XXX parts. There is a concurrent effort underway to get the iSCSI driver (qla4xxx) integrated upstream as well. This submission is contained in a patch file that does the following: Adds: drivers/net/qla3xxx.c drivers/net/qla3xxx.h Modifies: MAINTAINERS drivers/net/Makefile drivers/net/Kconfig Built and tested using kernel 2.6.17-rc4. Patch file qla3xxxpatch1-v2.02.00k30 is at the following link: ftp://ftp.qlogic.com/outgoing/linux/network/upstream/2.02.00k30/ third submission: http://marc.theaimsgroup.com/?l=linux-netdevm=114867289310324w=2 Comments from third submission: http://marc.theaimsgroup.com/?l=linux-netdevm=114868292920149w=2 Changes in this release: 1. Call unregister_netdev before doing any hardware tear down. 2. Call pci_unmap_single before reference in eth_type_trans. 3. Change kfree to free_netdev. 4. Cleaned up indentation. 5. Changed more globals to use const. 6. ethtool get_link reports carrier state. 7. Got rid if multicast list comparisons since kernel has to do it. 8. Added call to prefetch before sending packet up the stack. 9. Renamed files to qla3xxx.c and qla3xxx.h. 10. Moved files to drivers/net and got rid of drivers/net/qla3xxx. 11. Updated Kconfig and Makefile to include driver build. 12. Cleaned up indents, eol whitespaces, and 80 column limits. 13. Added Ron Mercer to Maintainers list. Looking forward to any and all feedback. Regards, Ron Mercer Qlogic Corporation - 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: DPRINTKs in e1000 code (2.6.x kernels)
On Wed, 2006-05-31 at 16:30, Auke Kok wrote: On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora [EMAIL PROTECTED] wrote: Should these DPRINTKs be removed from the 2.6.x e1000 code as well ? they already are. the patch was merged in 7.0.38-k2 or so which is over a month ago. I do not think these DPRINTKs have been removed from the latest code. Or, they did get removed at some point of time, but somehow again got added. I checked in 2.16.17-rc4 kernel, and also in the following versions of e1000 codebase (pulled from git://lost.foo-projects.org/~ahkok/git/netdev-2.6): e1000-7.0.38-k1, -k2 ... -k5 e1000-7.0.41 All of the above versions have the concerned DPRINTKs in e1000_suspend() and other routines. Please check once and let me know if I am missing something. Thanks! Also, if you are getting these errors there are several fixes in 7.0.38+ in the kernel that might be related. especially the WoL fix that re-enables the shutdown handler correctly might fix this issue for you. Please give this kernel/module a try (see http://www.mail-archive.com/netdev@vger.kernel.org/msg12689.html). Cheers, Auke Regards, Amit Arora - 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: DPRINTKs in e1000 code (2.6.x kernels)
Amit Arora wrote:
On Wed, 2006-05-31 at 16:30, Auke Kok wrote:
On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora [EMAIL PROTECTED] wrote:
Should these DPRINTKs be removed from the 2.6.x e1000 code as well ?
they already are. the patch was merged in 7.0.38-k2 or so which is over a month ago.
I do not think these DPRINTKs have been removed from the latest code.
Or, they did get removed at some point of time, but somehow again got
added.
I checked in 2.16.17-rc4 kernel, and also in the following versions of
e1000 codebase (pulled from
git://lost.foo-projects.org/~ahkok/git/netdev-2.6):
e1000-7.0.38-k1, -k2 ... -k5
e1000-7.0.41
All of the above versions have the concerned DPRINTKs in e1000_suspend()
and other routines.
Please check once and let me know if I am missing something. Thanks!
git-show d0e027db7861ef03de0ac08494a9a61984d8f8b0
it's really in there - please use jgarzik's netdev#upstream branch. Not sure
if it already made it to 2.16.17-rc5, but I don't think this made it into
2.16.17-rc4, so that is where you may be missing it.
Auke
---
ref.:
diff-tree d0e027db7861ef03de0ac08494a9a61984d8f8b0 (from
a145410dccdb44f81d3b56763ef9b6f721f4e47c)
Author: Auke Kok [EMAIL PROTECTED]
Date: Fri Apr 14 19:04:40 2006 -0700
e1000: Remove PM warning DPRINTKs breaking 2.4.x kernels
remove DPRINTKs that were printing warnings about power management on
2.4 kernels. Since we really don't react differently these printk
statements are not needed. This code was originally added to fix
some compile time warnings that got fixed by newer kernels.
Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED]
Signed-off-by: Auke Kok [EMAIL PROTECTED]
Signed-off-by: John Ronciak [EMAIL PROTECTED]
diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
index add8dc4..ac1e838 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -4515,21 +4515,13 @@ e1000_suspend(struct pci_dev *pdev, pm_m
E1000_WRITE_REG(adapter-hw, WUC, E1000_WUC_PME_EN);
E1000_WRITE_REG(adapter-hw, WUFC, wufc);
- retval = pci_enable_wake(pdev, PCI_D3hot, 1);
- if (retval)
- DPRINTK(PROBE, ERR, Error enabling D3 wake\n);
- retval = pci_enable_wake(pdev, PCI_D3cold, 1);
- if (retval)
- DPRINTK(PROBE, ERR, Error enabling D3 cold wake\n);
+ pci_enable_wake(pdev, PCI_D3hot, 1);
+ pci_enable_wake(pdev, PCI_D3cold, 1);
} else {
E1000_WRITE_REG(adapter-hw, WUC, 0);
E1000_WRITE_REG(adapter-hw, WUFC, 0);
- retval = pci_enable_wake(pdev, PCI_D3hot, 0);
- if (retval)
- DPRINTK(PROBE, ERR, Error enabling D3 wake\n);
- retval = pci_enable_wake(pdev, PCI_D3cold, 0);
- if (retval)
- DPRINTK(PROBE, ERR, Error enabling D3 cold wake\n);
+ pci_enable_wake(pdev, PCI_D3hot, 0);
+ pci_enable_wake(pdev, PCI_D3cold, 0);
}
if (adapter-hw.mac_type = e1000_82540
@@ -4538,13 +4530,8 @@ e1000_suspend(struct pci_dev *pdev, pm_m
if (manc E1000_MANC_SMBUS_EN) {
manc |= E1000_MANC_ARP_EN;
E1000_WRITE_REG(adapter-hw, MANC, manc);
- retval = pci_enable_wake(pdev, PCI_D3hot, 1);
- if (retval)
- DPRINTK(PROBE, ERR, Error enabling D3 wake\n);
- retval = pci_enable_wake(pdev, PCI_D3cold, 1);
- if (retval)
- DPRINTK(PROBE, ERR,
- Error enabling D3 cold wake\n);
+ pci_enable_wake(pdev, PCI_D3hot, 1);
+ pci_enable_wake(pdev, PCI_D3cold, 1);
}
}
@@ -4554,9 +4541,7 @@ e1000_suspend(struct pci_dev *pdev, pm_m
pci_disable_device(pdev);
- retval = pci_set_power_state(pdev, pci_choose_state(pdev, state));
- if (retval)
- DPRINTK(PROBE, ERR, Error in setting power state\n);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
return 0;
}
@@ -4567,22 +4552,15 @@ e1000_resume(struct pci_dev *pdev)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct e1000_adapter *adapter = netdev_priv(netdev);
- int retval;
uint32_t manc, ret_val;
- retval = pci_set_power_state(pdev, PCI_D0);
- if (retval)
- DPRINTK(PROBE, ERR, Error in setting power state\n);
+ pci_set_power_state(pdev, PCI_D0);
e1000_pci_restore_state(adapter);
ret_val = pci_enable_device(pdev);
pci_set_master(pdev);
- retval = pci_enable_wake(pdev, PCI_D3hot, 0);
- if (retval)
- DPRINTK(PROBE, ERR, Error enabling D3 wake\n);
Re: [RFT] Realtek 8168 ethernet support
Daniel Drake [EMAIL PROTECTED] :
[...]
@@ -1442,20 +1444,24 @@ rtl8169_init_board(struct pci_dev *pdev,
}
}
- /* make sure PCI base addr 1 is MMIO */
- if (!(pci_resource_flags(pdev, 1) IORESOURCE_MEM)) {
- if (netif_msg_probe(tp)) {
- printk(KERN_ERR PFX
-region #1 not an MMIO resource, aborting\n);
- }
- rc = -ENODEV;
- goto err_out_mwi;
+ /* find MMIO resource: this varies between 8168 and 8169 */
+ for (i = 0; i 5; i++) {
I'd rather use pci_device_id-driver_data but it's an option.
Btw a 0x8167 may be encountered too.
A diff between latest versions of Realtek's code suggests that
rtl_chip_info and mac_info need an update as well.
--
Ueimor
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DPRINTKs in e1000 code (2.6.x kernels)
Auke Kok wrote: Amit Arora wrote: On Wed, 2006-05-31 at 16:30, Auke Kok wrote: On Wed, 31 May 2006 14:31:05 +0530, Amit K Arora [EMAIL PROTECTED] wrote: Should these DPRINTKs be removed from the 2.6.x e1000 code as well ? they already are. the patch was merged in 7.0.38-k2 or so which is over a month ago. I do not think these DPRINTKs have been removed from the latest code. Or, they did get removed at some point of time, but somehow again got added. I checked in 2.16.17-rc4 kernel, and also in the following versions of e1000 codebase (pulled from git://lost.foo-projects.org/~ahkok/git/netdev-2.6): e1000-7.0.38-k1, -k2 ... -k5 e1000-7.0.41 All of the above versions have the concerned DPRINTKs in e1000_suspend() and other routines. Please check once and let me know if I am missing something. Thanks! git-show d0e027db7861ef03de0ac08494a9a61984d8f8b0 it's really in there - please use jgarzik's netdev#upstream branch. Not sure if it already made it to 2.16.17-rc5, but I don't think this made it into 2.16.17-rc4, so that is where you may be missing it. I'm in need of coffee - these changes got queued for 2.6.18. They're in jgarziks netdev-2.6.git, but not anywhere in 2.6.17rcX Auke - 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: DPRINTKs in e1000 code (2.6.x kernels)
Auke Kok wrote: I'm in need of coffee - these changes got queued for 2.6.18. They're in jgarziks netdev-2.6.git, but not anywhere in 2.6.17rcX Auke Thanks for the clarification ! Regards, Amit Arora - 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: [openib-general] Re: [PATCH 1/2] iWARP Connection Manager.
On Thu, 2006-06-01 at 14:09 -0700, Sean Hefty wrote:
Steve Wise wrote:
+int iw_cm_disconnect(struct iw_cm_id *cm_id, int abrupt)
+{
+ struct iwcm_id_private *cm_id_priv;
+ unsigned long flags;
+ int ret = 0;
+
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ /* Wait if we're currently in a connect or accept downcall */
+ wait_event(cm_id_priv-connect_wait,
+ !test_bit(IWCM_F_CONNECT_WAIT, cm_id_priv-flags));
Am I understanding this check correctly? You're checking to see if the
user has
called iw_cm_disconnect() at the same time that they called iw_cm_connect()
or
iw_cm_accept(). Are connect / accept blocking, or are you just waiting for
an
event?
The CM must wait for the low level provider to finish a connect() or
accept() operation before telling the low level provider to disconnect
via modifying the iwarp QP. Regardless of whether they block, this
disconnect can happen concurrently with the connect/accept so we need to
hold the disconnect until the connect/accept completes.
+EXPORT_SYMBOL(iw_cm_disconnect);
+static void destroy_cm_id(struct iw_cm_id *cm_id)
+{
+ struct iwcm_id_private *cm_id_priv;
+ unsigned long flags;
+ int ret;
+
+ cm_id_priv = container_of(cm_id, struct iwcm_id_private, id);
+ /* Wait if we're currently in a connect or accept downcall. A
+ * listening endpoint should never block here. */
+ wait_event(cm_id_priv-connect_wait,
+ !test_bit(IWCM_F_CONNECT_WAIT, cm_id_priv-flags));
Same question/comment as above.
Same answer.
There's a difference between trying to handle the user calling
disconnect/destroy at the same time a call to accept/connect is active,
versus
the user calling disconnect/destroy after accept/connect have returned. In
the
latter case, I think you're fine. In the first case, this is allowing a user
to
call destroy at the same time that they're calling accept/connect.
Additionally, there's no guarantee that the F_CONNECT_WAIT flag has been set
by
accept/connect by the time disconnect/destroy tests it.
The problem is that we can't synchronously cancel an outstanding connect
request. Once we've asked the adapter to connect, we can't tell him to
stop, we have to wait for it to fail. During the time period between
when we ask to connect and the adapter says yeah-or-nay, the user hits
ctrl-C. This is the case where disconnect and/or destroy gets called and
we have to block it waiting for the outstanding connect request to
complete.
One alternative to this approach is to do the kfree of the cm_id in the
deref logic. This was the original design and leaves the object around
to handle the completion of the connect and still allows the app to
clean up and go away without all this waitin' around. When the adapter
finally finishes and releases it's reference, the object is kfree'd.
Hope this helps.
- Sean
___
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
-
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: [openib-general] Re: [PATCH 1/2] iWARP Connection Manager.
There's a difference between trying to handle the user calling disconnect/destroy at the same time a call to accept/connect is active, versus the user calling disconnect/destroy after accept/connect have returned. In the latter case, I think you're fine. In the first case, this is allowing a user to call destroy at the same time that they're calling accept/connect. Additionally, there's no guarantee that the F_CONNECT_WAIT flag has been set by accept/connect by the time disconnect/destroy tests it. The problem is that we can't synchronously cancel an outstanding connect request. Once we've asked the adapter to connect, we can't tell him to stop, we have to wait for it to fail. During the time period between when we ask to connect and the adapter says yeah-or-nay, the user hits ctrl-C. This is the case where disconnect and/or destroy gets called and we have to block it waiting for the outstanding connect request to complete. One alternative to this approach is to do the kfree of the cm_id in the deref logic. This was the original design and leaves the object around to handle the completion of the connect and still allows the app to clean up and go away without all this waitin' around. When the adapter finally finishes and releases it's reference, the object is kfree'd. Hope this helps. Why couldn't you synchronously put the cm_id in a state of pending delete and do the actual delete when the RNIC provides a response to the request? There could even be an optional method to see if the device is capable of cancelling the request. I know it can't yank a SYN back from the wire, but it could refrain from retransmitting. - 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
e1000 fails to load sometimes: The EEPROM Checksum Is Not Valid
With 2.6.17-rc5-mm2 (and other kernels), the e1000 fails to load sometimes, with the message: Intel(R) PRO/1000 Network Driver - version 7.0.38-k4-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :02:00.0[A] - GSI 16 (level, low) - IRQ 20 PCI: Setting latency timer of device :02:00.0 to 64 e1000: :02:00.0: e1000_probe: The EEPROM Checksum Is Not Valid e1000: probe of :02:00.0 failed with error -5 Sometimes it will do this after several modprobe/rmmod cycles, and then it will load OK. Once loaded, it seems to work perfectly. This is this built-in e1000 in a Thinkpad X60: 02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet Controller The full lspci output: 00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 03) Subsystem: Lenovo Unknown device 2017 Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information 00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03) (prog-if 00 [VGA]) Subsystem: Lenovo Unknown device 201a Flags: bus master, fast devsel, latency 0, IRQ 20 Memory at ee10 (32-bit, non-prefetchable) [size=512K] I/O ports at 1800 [size=8] Memory at d000 (32-bit, prefetchable) [size=256M] Memory at ee20 (32-bit, non-prefetchable) [size=256K] Capabilities: [90] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [d0] Power Management version 2 00:02.1 Display controller: Intel Corporation Mobile Integrated Graphics Controller (rev 03) Subsystem: Lenovo Unknown device 201a Flags: fast devsel Memory at ee18 (32-bit, non-prefetchable) [size=512K] Capabilities: [d0] Power Management version 2 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) Subsystem: Lenovo Unknown device 2010 Flags: bus master, fast devsel, latency 0, IRQ 22 Memory at ee24 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] Message Signalled Interrupts: 64bit+ Queue=0/0 Enable- Capabilities: [70] Express Unknown type IRQ 0 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: ee00-ee0f Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 3000-4fff Memory behind bridge: ec00-edff Prefetchable memory behind bridge: e400-e400 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1c.2 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 3 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=0b, sec-latency=0 I/O behind bridge: 5000-6fff Memory behind bridge: e800-e9ff Prefetchable memory behind bridge: e410-e410 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=0c, subordinate=13, sec-latency=0 I/O behind bridge: 7000-8fff Memory behind bridge: ea00-ebff Prefetchable memory behind bridge: e420-e420 Capabilities: [40] Express Root Port (Slot+) IRQ 0 Capabilities: [80] Message Signalled Interrupts: 64bit- Queue=0/0 Enable- Capabilities: [90] #0d [] Capabilities: [a0] Power Management version 2 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI #1 (rev 02) (prog-if 00 [UHCI]) Subsystem: Lenovo Unknown device 200a Flags: bus master, medium devsel, latency 0, IRQ 20 I/O ports at 1820 [size=32] 00:1d.1 USB Controller:
Re: [RFT] Realtek 8168 ethernet support
On Fri, Jun 02, 2006 at 12:24:37AM +0200, Francois Romieu wrote: I'd rather use pci_device_id-driver_data but it's an option. I would prefer this, too. Jeff - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] softmac: Fix handling of authentication failure
Daniel Drake wrote:
My router blew up earlier, but exhibited some interesting behaviour during
its dying moments. It was broadcasting beacons but wouldn't respond to
any authentication requests.
I noticed that softmac wasn't playing nice with this, as I couldn't make it try
to connect to other networks after it had timed out authenticating to my ill
router.
To resolve this, I modified the softmac event/notify API to pass the event
code to the callback, so that callbacks being notified from
IEEE80211SOFTMAC_EVENT_ANY masks can make some judgement. In this case, the
ieee80211softmac_assoc callback needs to make a decision based upon whether
the association passed or failed.
Signed-off-by: Daniel Drake [EMAIL PROTECTED]
Acked-by: Johannes Berg [EMAIL PROTECTED]
--snip--
Index: linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
===
--- linux.orig/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ linux/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -164,12 +164,28 @@ network_matches_request(struct ieee80211
}
static void
-ieee80211softmac_assoc_notify(struct net_device *dev, void *context)
+ieee80211softmac_assoc_notify_scan(struct net_device *dev, int event_type,
void *context)
{
struct ieee80211softmac_device *mac = ieee80211_priv(dev);
ieee80211softmac_assoc_work((void*)mac);
}
+static void
+ieee80211softmac_assoc_notify_auth(struct net_device *dev, int event_type,
void *context)
+{
+ struct ieee80211softmac_device *mac = ieee80211_priv(dev);
+
+ switch (event_type) {
+ case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
+ ieee80211softmac_assoc_work((void*)mac);
+ break;
+ case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
+ case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
+ ieee80211softmac_disassoc(mac);
This statement fails to compile on my system using Linus' tree, because
ieee80211softmac_disassoc needs a second argument - the reason. It seems
as if WLAN_REASON_PREV_AUTH_NOT_VALID would be appropriate.
Larry
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: netif_tx_disable and lockless TX
Robert Olsson wrote: jamal writes: Latency-wise: TX completion interrupt provides the best latency. Processing in the poll() -aka softirq- was almost close to the hardirq variant. So if you can make things run in a softirq such as transmit one, then the numbers will likely stay the same. I don't remember we tried tasklet for TX a la Herbert's suggestion but we used use tasklets for controlling RX processing to avoid hardirq livelock in pre-NAPI versions. Had variants of tulip driver with both TX cleaning at -poll and TX cleaning at hardirq and didn't see any performance difference. The -poll was much cleaner but we kept Alexey's original work for tulip. Sorry, I havent been following discussions on netchannels[1] so i am not qualified to comment on the replacement part Dave mentioned earlier. What I can say is the tx processing doesnt have to be part of the NAPI poll() and still use hardirq. Yes true but I see TX numbers with newer boards (wire rate small pakets) with cleaing in -poll. Also now linux is very safe in network overload situations. Moving work to hardirq may change that. I also noticed that you really don't save much by doing TX cleaning at hardirq, because in hardirq you need to do dev_kfree_irq and that causes a softirq (for the routing case where users=1). So when routing it doesn't make much difference, both methods cause the softirq delayed processing to be invoked. For locally generated packets which are cloned, the hardirq will drop the ref count, and that is faster than doing the whole softirq round trip. - 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 01/17] clean up initcall warning for netconsole
From: Matt Mackall [EMAIL PROTECTED]
netconsole is being wrong here. If it wasn't enabled there's no error.
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/net/netconsole.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/net/netconsole.c~clean-up-initcall-warning-for-netconsole
drivers/net/netconsole.c
--- devel/drivers/net/netconsole.c~clean-up-initcall-warning-for-netconsole
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/drivers/net/netconsole.c 2006-06-01 20:31:49.0 -0700
@@ -107,7 +107,7 @@ static int init_netconsole(void)
if(!configured) {
printk(netconsole: not configured, aborting\n);
- return -EINVAL;
+ return 0;
}
if(netpoll_setup(np))
_
-
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 04/17] ppp_async hang fix
From: [EMAIL PROTECTED] Adapted from http://bugzilla.kernel.org/show_bug.cgi?id=6530 Reschedule the async Tx tasklet if the transmit queue was full. Cc: Paul Mackerras [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/ppp_async.c |2 ++ 1 file changed, 2 insertions(+) diff -puN drivers/net/ppp_async.c~ppp_async-hang-fix drivers/net/ppp_async.c --- devel/drivers/net/ppp_async.c~ppp_async-hang-fix2006-06-01 20:31:49.0 -0700 +++ devel-akpm/drivers/net/ppp_async.c 2006-06-01 20:31:49.0 -0700 @@ -516,6 +516,8 @@ static void ppp_async_process(unsigned l /* try to push more stuff out */ if (test_bit(XMIT_WAKEUP, ap-xmit_flags) ppp_async_push(ap)) ppp_output_wakeup(ap-chan); + else if (test_bit(XMIT_FULL, ap-xmit_flags)) + ppp_asynctty_wakeup(ap-tty); } /* _ - 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 10/17] secmark: Add xtables SECMARK target
From: James Morris [EMAIL PROTECTED]
Add a SECMARK target to xtables, allowing the admin to apply security marks to
packets via both iptables and ip6tables.
The target currently handles SELinux security marking, but can be extended
for other purposes as needed.
Signed-off-by: James Morris [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/linux/netfilter/xt_SECMARK.h | 26
net/netfilter/Kconfig|9 +
net/netfilter/Makefile |1
net/netfilter/xt_SECMARK.c | 156 +
4 files changed, 192 insertions(+)
diff -puN /dev/null include/linux/netfilter/xt_SECMARK.h
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/include/linux/netfilter/xt_SECMARK.h 2006-06-01
20:31:50.0 -0700
@@ -0,0 +1,26 @@
+#ifndef _XT_SECMARK_H_target
+#define _XT_SECMARK_H_target
+
+/*
+ * This is intended for use by various security subsystems (but not
+ * at the same time).
+ *
+ * 'mode' refers to the specific security subsystem which the
+ * packets are being marked for.
+ */
+#define SECMARK_MODE_SEL 0x01/* SELinux */
+#define SECMARK_SELCTX_MAX 256
+
+struct xt_secmark_target_selinux_info {
+ u_int32_t selsid;
+ char selctx[SECMARK_SELCTX_MAX];
+};
+
+struct xt_secmark_target_info {
+ u_int8_t mode;
+ union {
+ struct xt_secmark_target_selinux_info sel;
+ } u;
+};
+
+#endif /*_XT_SECMARK_H_target */
diff -puN net/netfilter/Kconfig~secmark-add-xtables-secmark-target
net/netfilter/Kconfig
--- devel/net/netfilter/Kconfig~secmark-add-xtables-secmark-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Kconfig2006-06-01 20:31:50.0 -0700
@@ -174,6 +174,15 @@ config NETFILTER_XT_TARGET_NOTRACK
If you want to compile it as a module, say M here and read
file:Documentation/modules.txt. If unsure, say `N'.
+config NETFILTER_XT_TARGET_SECMARK
+ tristate 'SECMARK target support'
+ depends on NETFILTER_XTABLES NETWORK_SECMARK
+ help
+ The SECMARK target allows security marking of network
+ packets, for use with security subsystems.
+
+ To compile it as a module, choose M here. If unsure, say N.
+
config NETFILTER_XT_MATCH_COMMENT
tristate 'comment match support'
depends on NETFILTER_XTABLES
diff -puN net/netfilter/Makefile~secmark-add-xtables-secmark-target
net/netfilter/Makefile
--- devel/net/netfilter/Makefile~secmark-add-xtables-secmark-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Makefile 2006-06-01 20:31:50.0 -0700
@@ -28,6 +28,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_CONNMAR
obj-$(CONFIG_NETFILTER_XT_TARGET_MARK) += xt_MARK.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NOTRACK) += xt_NOTRACK.o
+obj-$(CONFIG_NETFILTER_XT_TARGET_SECMARK) += xt_SECMARK.o
# matches
obj-$(CONFIG_NETFILTER_XT_MATCH_COMMENT) += xt_comment.o
diff -puN /dev/null net/netfilter/xt_SECMARK.c
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/net/netfilter/xt_SECMARK.c 2006-06-01 20:31:50.0
-0700
@@ -0,0 +1,156 @@
+/*
+ * Module for modifying the secmark field of the skb, for use by
+ * security subsystems.
+ *
+ * Based on the nfmark match by:
+ * (C) 1999-2001 Marc Boucher [EMAIL PROTECTED]
+ *
+ * (C) 2006 Red Hat, Inc., James Morris [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include linux/module.h
+#include linux/skbuff.h
+#include linux/selinux.h
+#include linux/netfilter/x_tables.h
+#include linux/netfilter/xt_SECMARK.h
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(James Morris [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(ip[6]tables SECMARK modification module);
+MODULE_ALIAS(ipt_SECMARK);
+MODULE_ALIAS(ip6t_SECMARK);
+
+#define PFX SECMARK:
+
+static u8 mode;
+
+static unsigned int target(struct sk_buff **pskb, const struct net_device *in,
+ const struct net_device *out, unsigned int hooknum,
+ const struct xt_target *target,
+ const void *targinfo, void *userinfo)
+{
+ u32 secmark = 0;
+ const struct xt_secmark_target_info *info = targinfo;
+
+ BUG_ON(info-mode != mode);
+
+ switch (mode) {
+ case SECMARK_MODE_SEL:
+ secmark = info-u.sel.selsid;
+ break;
+
+ default:
+ BUG();
+ }
+
+ if ((*pskb)-secmark != secmark)
+ (*pskb)-secmark = secmark;
+
+ return XT_CONTINUE;
+}
+
+static int checkentry_selinux(struct xt_secmark_target_info *info)
+{
+ int err;
+ struct xt_secmark_target_selinux_info *sel = info-u.sel;
+
+ err = selinux_string_to_sid(sel-selctx,
[patch 02/17] remove dead entry in net wan Kconfig
From: Paul Fulghum [EMAIL PROTECTED] Remove dead entry from net wan Kconfig. This entry is left over from 2.4 where synclink used syncppp driver directly. synclink drivers now use generic HDLC Signed-off-by: Paul Fulghum [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/wan/Kconfig | 12 1 file changed, 12 deletions(-) diff -puN drivers/net/wan/Kconfig~remove-dead-entry-in-net-wan-kconfig drivers/net/wan/Kconfig --- devel/drivers/net/wan/Kconfig~remove-dead-entry-in-net-wan-kconfig 2006-06-01 20:31:49.0 -0700 +++ devel-akpm/drivers/net/wan/Kconfig 2006-06-01 20:31:49.0 -0700 @@ -134,18 +134,6 @@ config SEALEVEL_4021 The driver will be compiled as a module: the module will be called sealevel. -config SYNCLINK_SYNCPPP - tristate SyncLink HDLC/SYNCPPP support - depends on WAN - help - Enables HDLC/SYNCPPP support for the SyncLink WAN driver. - - Normally the SyncLink WAN driver works with the main PPP driver - file:drivers/net/ppp_generic.c and pppd program. - HDLC/SYNCPPP support allows use of the Cisco HDLC/PPP driver - file:drivers/net/wan/syncppp.c. The SyncLink WAN driver (in - character devices) must also be enabled. - # Generic HDLC config HDLC tristate Generic HDLC layer _ - 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 06/17] neighbour.c, pneigh_get_next() skips published entry
From: Jari Takkala [EMAIL PROTECTED]
Fix a problem where output from /proc/net/arp skips a record when the full
output does not fit into the users read() buffer.
To reproduce: publish a large number of ARP entries (more than 10 required
on my system). Run 'dd if=/proc/net/arp of=arp-1024.out bs=1024'. View
the output, one entry will be missing.
Signed-off-by: Jari Takkala [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/core/neighbour.c |6 ++
1 file changed, 6 insertions(+)
diff -puN net/core/neighbour.c~neighbourc-pneigh_get_next-skips-published-entry
net/core/neighbour.c
--- devel/net/core/neighbour.c~neighbourc-pneigh_get_next-skips-published-entry
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/net/core/neighbour.c 2006-06-01 20:31:49.0 -0700
@@ -2138,6 +2138,12 @@ static struct pneigh_entry *pneigh_get_n
struct neigh_seq_state *state = seq-private;
struct neigh_table *tbl = state-tbl;
+ if (pos != NULL *pos == 1
+ (pn-next || tbl-phash_buckets[state-bucket])) {
+ --(*pos);
+ return pn;
+ }
+
pn = pn-next;
while (!pn) {
if (++state-bucket PNEIGH_HASHMASK)
_
-
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/17] secmark: Add CONNSECMARK xtables target
From: James Morris [EMAIL PROTECTED]
Add a new xtables target, CONNSECMARK, which is used to specify rules for
copying security marks from packets to connections, and for copyying security
marks back from connections to packets. This is similar to the CONNMARK
target, but is more limited in scope in that it only allows copying of
security marks to and from packets, as this is all it needs to do.
A typical scenario would be to apply a security mark to a 'new' packet with
SECMARK, then copy that to its conntrack via CONNMARK, and then restore the
security mark from the connection to established and related packets on that
connection.
Signed-off-by: James Morris [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/linux/netfilter/xt_CONNSECMARK.h | 13 +
net/netfilter/Kconfig| 11 +
net/netfilter/Makefile |1
net/netfilter/xt_CONNSECMARK.c | 155 +
4 files changed, 180 insertions(+)
diff -puN /dev/null include/linux/netfilter/xt_CONNSECMARK.h
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/include/linux/netfilter/xt_CONNSECMARK.h 2006-06-01
20:31:50.0 -0700
@@ -0,0 +1,13 @@
+#ifndef _XT_CONNSECMARK_H_target
+#define _XT_CONNSECMARK_H_target
+
+enum {
+ CONNSECMARK_SAVE = 1,
+ CONNSECMARK_RESTORE,
+};
+
+struct xt_connsecmark_target_info {
+ u_int8_t mode;
+};
+
+#endif /*_XT_CONNSECMARK_H_target */
diff -puN net/netfilter/Kconfig~secmark-add-connsecmark-xtables-target
net/netfilter/Kconfig
--- devel/net/netfilter/Kconfig~secmark-add-connsecmark-xtables-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Kconfig2006-06-01 20:31:50.0 -0700
@@ -195,6 +195,17 @@ config NETFILTER_XT_TARGET_SECMARK
To compile it as a module, choose M here. If unsure, say N.
+config NETFILTER_XT_TARGET_CONNSECMARK
+ tristate 'CONNSECMARK target support'
+ depends on NETFILTER_XTABLES (NF_CONNTRACK_SECMARK ||
IP_NF_CONNTRACK_SECMARK)
+ help
+ The CONNSECMARK target copies security markings from packets
+ to connections, and restores security markings from connections
+ to packets (if the packets are not already marked). This would
+ normally be used in conjunction with the SECMARK target.
+
+ To compile it as a module, choose M here. If unsure, say N.
+
config NETFILTER_XT_MATCH_COMMENT
tristate 'comment match support'
depends on NETFILTER_XTABLES
diff -puN net/netfilter/Makefile~secmark-add-connsecmark-xtables-target
net/netfilter/Makefile
--- devel/net/netfilter/Makefile~secmark-add-connsecmark-xtables-target
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/netfilter/Makefile 2006-06-01 20:31:50.0 -0700
@@ -29,6 +29,7 @@ obj-$(CONFIG_NETFILTER_XT_TARGET_MARK) +
obj-$(CONFIG_NETFILTER_XT_TARGET_NFQUEUE) += xt_NFQUEUE.o
obj-$(CONFIG_NETFILTER_XT_TARGET_NOTRACK) += xt_NOTRACK.o
obj-$(CONFIG_NETFILTER_XT_TARGET_SECMARK) += xt_SECMARK.o
+obj-$(CONFIG_NETFILTER_XT_TARGET_CONNSECMARK) += xt_CONNSECMARK.o
# matches
obj-$(CONFIG_NETFILTER_XT_MATCH_COMMENT) += xt_comment.o
diff -puN /dev/null net/netfilter/xt_CONNSECMARK.c
--- /dev/null 2006-06-01 17:04:03.273681250 -0700
+++ devel-akpm/net/netfilter/xt_CONNSECMARK.c 2006-06-01 20:31:50.0
-0700
@@ -0,0 +1,155 @@
+/*
+ * This module is used to copy security markings from packets
+ * to connections, and restore security markings from connections
+ * back to packets. This would normally be performed in conjunction
+ * with the SECMARK target and state match.
+ *
+ * Based somewhat on CONNMARK:
+ * Copyright (C) 2002,2004 MARA Systems AB http://www.marasystems.com
+ *by Henrik Nordstrom [EMAIL PROTECTED]
+ *
+ * (C) 2006 Red Hat, Inc., James Morris [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include linux/module.h
+#include linux/skbuff.h
+#include linux/netfilter/x_tables.h
+#include linux/netfilter/xt_CONNSECMARK.h
+#include net/netfilter/nf_conntrack_compat.h
+
+#define PFX CONNSECMARK:
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(James Morris [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(ip[6]tables CONNSECMARK module);
+MODULE_ALIAS(ipt_CONNSECMARK);
+MODULE_ALIAS(ip6t_CONNSECMARK);
+
+/*
+ * If the packet has a security mark and the connection does not, copy
+ * the security mark from the packet to the connection.
+ */
+static void secmark_save(struct sk_buff *skb)
+{
+ if (skb-secmark) {
+ u32 *connsecmark;
+ enum ip_conntrack_info ctinfo;
+
+ connsecmark = nf_ct_get_secmark(skb, ctinfo);
+ if (connsecmark !*connsecmark)
+ if (*connsecmark != skb-secmark)
+ *connsecmark = skb-secmark;
[patch 14/17] irda: missing allocation result check in irlap_change_speed()
From: Florin Malita [EMAIL PROTECTED]
The skb allocation may fail, which can result in a NULL pointer dereference
in irlap_queue_xmit().
Coverity CID: 434.
davem: If the allocation fails we should probably do something more
interesting here, such as schedule a timer to try again later. Otherwise the
speed change will silently never occur.
Signed-off-by: Florin Malita [EMAIL PROTECTED]
Cc: Samuel Ortiz [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/irda/irlap.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff -puN
net/irda/irlap.c~irda-missing-allocation-result-check-in-irlap_change_speed
net/irda/irlap.c
---
devel/net/irda/irlap.c~irda-missing-allocation-result-check-in-irlap_change_speed
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/irda/irlap.c 2006-06-01 20:31:50.0 -0700
@@ -884,7 +884,8 @@ static void irlap_change_speed(struct ir
if (now) {
/* Send down empty frame to trigger speed change */
skb = dev_alloc_skb(0);
- irlap_queue_xmit(self, skb);
+ if (skb)
+ irlap_queue_xmit(self, skb);
}
}
_
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 05/17] selinux: add security class for appletalk sockets
From: Christopher J. PeBenito [EMAIL PROTECTED] Add a security class for appletalk sockets so that they can be distinguished in SELinux policy. Please apply. Signed-off-by: Stephen Smalley [EMAIL PROTECTED] Acked-by: James Morris [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- security/selinux/hooks.c |2 + security/selinux/include/av_inherit.h |1 security/selinux/include/av_permissions.h | 23 +++ security/selinux/include/class_to_string.h |1 security/selinux/include/flask.h |1 5 files changed, 28 insertions(+) diff -puN security/selinux/hooks.c~selinux-add-security-class-for-appletalk-sockets security/selinux/hooks.c --- devel/security/selinux/hooks.c~selinux-add-security-class-for-appletalk-sockets 2006-06-01 20:31:49.0 -0700 +++ devel-akpm/security/selinux/hooks.c 2006-06-01 20:31:49.0 -0700 @@ -696,6 +696,8 @@ static inline u16 socket_type_to_securit return SECCLASS_PACKET_SOCKET; case PF_KEY: return SECCLASS_KEY_SOCKET; + case PF_APPLETALK: + return SECCLASS_APPLETALK_SOCKET; } return SECCLASS_SOCKET; diff -puN security/selinux/include/av_inherit.h~selinux-add-security-class-for-appletalk-sockets security/selinux/include/av_inherit.h --- devel/security/selinux/include/av_inherit.h~selinux-add-security-class-for-appletalk-sockets 2006-06-01 20:31:49.0 -0700 +++ devel-akpm/security/selinux/include/av_inherit.h2006-06-01 20:31:49.0 -0700 @@ -29,3 +29,4 @@ S_(SECCLASS_NETLINK_IP6FW_SOCKET, socket, 0x0040UL) S_(SECCLASS_NETLINK_DNRT_SOCKET, socket, 0x0040UL) S_(SECCLASS_NETLINK_KOBJECT_UEVENT_SOCKET, socket, 0x0040UL) + S_(SECCLASS_APPLETALK_SOCKET, socket, 0x0040UL) diff -puN security/selinux/include/av_permissions.h~selinux-add-security-class-for-appletalk-sockets security/selinux/include/av_permissions.h --- devel/security/selinux/include/av_permissions.h~selinux-add-security-class-for-appletalk-sockets 2006-06-01 20:31:49.0 -0700 +++ devel-akpm/security/selinux/include/av_permissions.h2006-06-01 20:31:49.0 -0700 @@ -933,3 +933,26 @@ #define NETLINK_KOBJECT_UEVENT_SOCKET__SEND_MSG 0x0010UL #define NETLINK_KOBJECT_UEVENT_SOCKET__NAME_BIND 0x0020UL +#define APPLETALK_SOCKET__IOCTL 0x0001UL +#define APPLETALK_SOCKET__READ0x0002UL +#define APPLETALK_SOCKET__WRITE 0x0004UL +#define APPLETALK_SOCKET__CREATE 0x0008UL +#define APPLETALK_SOCKET__GETATTR 0x0010UL +#define APPLETALK_SOCKET__SETATTR 0x0020UL +#define APPLETALK_SOCKET__LOCK0x0040UL +#define APPLETALK_SOCKET__RELABELFROM 0x0080UL +#define APPLETALK_SOCKET__RELABELTO 0x0100UL +#define APPLETALK_SOCKET__APPEND 0x0200UL +#define APPLETALK_SOCKET__BIND0x0400UL +#define APPLETALK_SOCKET__CONNECT 0x0800UL +#define APPLETALK_SOCKET__LISTEN 0x1000UL +#define APPLETALK_SOCKET__ACCEPT 0x2000UL +#define APPLETALK_SOCKET__GETOPT 0x4000UL +#define APPLETALK_SOCKET__SETOPT 0x8000UL +#define APPLETALK_SOCKET__SHUTDOWN0x0001UL +#define APPLETALK_SOCKET__RECVFROM0x0002UL +#define APPLETALK_SOCKET__SENDTO 0x0004UL +#define APPLETALK_SOCKET__RECV_MSG0x0008UL +#define APPLETALK_SOCKET__SEND_MSG0x0010UL +#define APPLETALK_SOCKET__NAME_BIND 0x0020UL + diff -puN security/selinux/include/class_to_string.h~selinux-add-security-class-for-appletalk-sockets security/selinux/include/class_to_string.h --- devel/security/selinux/include/class_to_string.h~selinux-add-security-class-for-appletalk-sockets 2006-06-01 20:31:49.0 -0700 +++ devel-akpm/security/selinux/include/class_to_string.h 2006-06-01 20:31:49.0 -0700 @@ -58,3 +58,4 @@ S_(nscd) S_(association) S_(netlink_kobject_uevent_socket) +S_(appletalk_socket) diff -puN security/selinux/include/flask.h~selinux-add-security-class-for-appletalk-sockets security/selinux/include/flask.h --- devel/security/selinux/include/flask.h~selinux-add-security-class-for-appletalk-sockets 2006-06-01 20:31:49.0 -0700 +++ devel-akpm/security/selinux/include/flask.h 2006-06-01 20:31:49.0 -0700 @@ -60,6 +60,7 @@ #define SECCLASS_NSCD53 #define SECCLASS_ASSOCIATION 54 #define SECCLASS_NETLINK_KOBJECT_UEVENT_SOCKET 55 +#define SECCLASS_APPLETALK_SOCKET56 /* * Security identifier
[patch 16/17] recent match: fix sleeping function called from invalid context
From: Patrick McHardy [EMAIL PROTECTED]
create_proc_entry must not be called with locks held. Use a mutex instead
to protect data only changed in user context.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/ipv4/netfilter/ipt_recent.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff -puN
net/ipv4/netfilter/ipt_recent.c~recent-match-fix-sleeping-function-called-from-invalid-context
net/ipv4/netfilter/ipt_recent.c
---
devel/net/ipv4/netfilter/ipt_recent.c~recent-match-fix-sleeping-function-called-from-invalid-context
2006-06-01 20:31:51.0 -0700
+++ devel-akpm/net/ipv4/netfilter/ipt_recent.c 2006-06-01 20:31:51.0
-0700
@@ -69,6 +69,7 @@ struct recent_table {
static LIST_HEAD(tables);
static DEFINE_SPINLOCK(recent_lock);
+static DEFINE_MUTEX(recent_mutex);
#ifdef CONFIG_PROC_FS
static struct proc_dir_entry *proc_dir;
@@ -249,7 +250,7 @@ ipt_recent_checkentry(const char *tablen
strnlen(info-name, IPT_RECENT_NAME_LEN) == IPT_RECENT_NAME_LEN)
return 0;
- spin_lock_bh(recent_lock);
+ mutex_lock(recent_mutex);
t = recent_table_lookup(info-name);
if (t != NULL) {
t-refcnt++;
@@ -258,7 +259,7 @@ ipt_recent_checkentry(const char *tablen
}
t = kzalloc(sizeof(*t) + sizeof(t-iphash[0]) * ip_list_hash_size,
- GFP_ATOMIC);
+ GFP_KERNEL);
if (t == NULL)
goto out;
strcpy(t-name, info-name);
@@ -274,10 +275,12 @@ ipt_recent_checkentry(const char *tablen
t-proc-proc_fops = recent_fops;
t-proc-data = t;
#endif
+ spin_lock_bh(recent_lock);
list_add_tail(t-list, tables);
+ spin_unlock_bh(recent_lock);
ret = 1;
out:
- spin_unlock_bh(recent_lock);
+ mutex_unlock(recent_mutex);
return ret;
}
@@ -288,17 +291,19 @@ ipt_recent_destroy(const struct xt_match
const struct ipt_recent_info *info = matchinfo;
struct recent_table *t;
- spin_lock_bh(recent_lock);
+ mutex_lock(recent_mutex);
t = recent_table_lookup(info-name);
if (--t-refcnt == 0) {
+ spin_lock_bh(recent_lock);
list_del(t-list);
+ spin_unlock_bh(recent_lock);
recent_table_flush(t);
#ifdef CONFIG_PROC_FS
remove_proc_entry(t-name, proc_dir);
#endif
kfree(t);
}
- spin_unlock_bh(recent_lock);
+ mutex_unlock(recent_mutex);
}
#ifdef CONFIG_PROC_FS
_
-
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 16/17] recent match: fix sleeping function called from invalid context
oops, sorry, I didn't mean to send 16 and 17. - 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/17] secmark: Add new flask definitions to SELinux
From: James Morris [EMAIL PROTECTED]
Secmark implements a new scheme for adding security markings to packets via
iptables, as well as changes to SELinux to use these markings for security
policy enforcement. The rationale for this scheme is explained and discussed
in detail in the original threads:
http://thread.gmane.org/gmane.linux.network/34927/
http://thread.gmane.org/gmane.linux.network/35244/
Examples of policy and rulesets, as well as a full archive of patches for
iptables and SELinux userland, may be found at:
http://people.redhat.com/jmorris/selinux/secmark/
The code has been tested with various compilation options and in several
scenarios, including with 'complicated' protocols such as FTP and also with
the new generic conntrack code with IPv6 connection tracking.
This patch:
Add support for a new object class ('packet'), and associated permissions
('send', 'recv', 'relabelto'). These are used to enforce security policy for
network packets labeled with SECMARK, and for adding labeling rules.
Signed-off-by: James Morris [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
security/selinux/include/av_perm_to_string.h |3 +++
security/selinux/include/av_permissions.h|3 +++
security/selinux/include/class_to_string.h |1 +
security/selinux/include/flask.h |1 +
4 files changed, 8 insertions(+)
diff -puN
security/selinux/include/av_permissions.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/av_permissions.h
---
devel/security/selinux/include/av_permissions.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/av_permissions.h2006-06-01
20:31:50.0 -0700
@@ -956,3 +956,6 @@
#define APPLETALK_SOCKET__SEND_MSG0x0010UL
#define APPLETALK_SOCKET__NAME_BIND 0x0020UL
+#define PACKET__SEND 0x0001UL
+#define PACKET__RECV 0x0002UL
+#define PACKET__RELABELTO 0x0004UL
diff -puN
security/selinux/include/av_perm_to_string.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/av_perm_to_string.h
---
devel/security/selinux/include/av_perm_to_string.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/av_perm_to_string.h 2006-06-01
20:31:50.0 -0700
@@ -239,3 +239,6 @@
S_(SECCLASS_ASSOCIATION, ASSOCIATION__SENDTO, sendto)
S_(SECCLASS_ASSOCIATION, ASSOCIATION__RECVFROM, recvfrom)
S_(SECCLASS_ASSOCIATION, ASSOCIATION__SETCONTEXT, setcontext)
+ S_(SECCLASS_PACKET, PACKET__SEND, send)
+ S_(SECCLASS_PACKET, PACKET__RECV, recv)
+ S_(SECCLASS_PACKET, PACKET__RELABELTO, relabelto)
diff -puN
security/selinux/include/class_to_string.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/class_to_string.h
---
devel/security/selinux/include/class_to_string.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/class_to_string.h 2006-06-01
20:31:50.0 -0700
@@ -59,3 +59,4 @@
S_(association)
S_(netlink_kobject_uevent_socket)
S_(appletalk_socket)
+S_(packet)
diff -puN
security/selinux/include/flask.h~secmark-add-new-flask-definitions-to-selinux
security/selinux/include/flask.h
---
devel/security/selinux/include/flask.h~secmark-add-new-flask-definitions-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/include/flask.h 2006-06-01 20:31:50.0
-0700
@@ -61,6 +61,7 @@
#define SECCLASS_ASSOCIATION 54
#define SECCLASS_NETLINK_KOBJECT_UEVENT_SOCKET 55
#define SECCLASS_APPLETALK_SOCKET56
+#define SECCLASS_PACKET 57
/*
* Security identifier indices for initial entities
_
-
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 13/17] secmark: Add new packet controls to SELinux
From: James Morris [EMAIL PROTECTED]
Add new per-packet access controls to SELinux, replacing the old packet
controls.
Packets are labeled with the iptables SECMARK and CONNSECMARK targets, then
security policy for the packets is enforced with these controls.
To allow for a smooth transition to the new controls, the old code is still
present, but not active by default. To restore previous behavior, the old
controls may be activated at runtime by writing a '1' to /selinux/compat_net,
and also via the kernel boot parameter selinux_compat_net. Switching between
the network control models requires the security load_policy permission. The
old controls will probably eventually be removed and any continued use is
discouraged.
With this patch, the new secmark controls for SElinux are disabled by default,
so existing behavior is entirely preserved, and the user is not affected at
all.
It also provides a config option to enable the secmark controls by default
(which can always be overridden at boot and runtime). It is also noted in the
kconfig help that the user will need updated userspace if enabling secmark
controls for SELinux and that they'll probably need the SECMARK and CONNMARK
targets, and conntrack protocol helpers, although such decisions are beyond
the scope of kernel configuration.
Signed-off-by: James Morris [EMAIL PROTECTED]
Cc: Stephen Smalley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
Documentation/kernel-parameters.txt |9
security/selinux/Kconfig| 29 +++
security/selinux/hooks.c| 242 ++
security/selinux/include/xfrm.h |2
security/selinux/selinuxfs.c| 66 +++
security/selinux/xfrm.c | 12 -
6 files changed, 241 insertions(+), 119 deletions(-)
diff -puN
Documentation/kernel-parameters.txt~secmark-add-new-packet-controls-to-selinux
Documentation/kernel-parameters.txt
---
devel/Documentation/kernel-parameters.txt~secmark-add-new-packet-controls-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/Documentation/kernel-parameters.txt 2006-06-01
20:31:50.0 -0700
@@ -1405,6 +1405,15 @@ running once the system is up.
If enabled at boot time, /selinux/disable can be used
later to disable prior to initial policy load.
+ selinux_compat_net =
+ [SELINUX] Set initial selinux_compat_net flag value.
+Format: { 0 | 1 }
+0 -- use new secmark-based packet controls
+1 -- use legacy packet controls
+Default value is 0 (preferred).
+Value can be changed at runtime via
+/selinux/compat_net.
+
serialnumber[BUGS=IA-32]
sg_def_reserved_size= [SCSI]
diff -puN security/selinux/hooks.c~secmark-add-new-packet-controls-to-selinux
security/selinux/hooks.c
--- devel/security/selinux/hooks.c~secmark-add-new-packet-controls-to-selinux
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/security/selinux/hooks.c 2006-06-01 20:31:50.0 -0700
@@ -80,6 +80,7 @@
extern unsigned int policydb_loaded_version;
extern int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm);
+extern int selinux_compat_net;
#ifdef CONFIG_SECURITY_SELINUX_DEVELOP
int selinux_enforcing = 0;
@@ -3216,47 +3217,17 @@ static int selinux_socket_unix_may_send(
return 0;
}
-static int selinux_socket_sock_rcv_skb(struct sock *sk, struct sk_buff *skb)
+static int selinux_sock_rcv_skb_compat(struct sock *sk, struct sk_buff *skb,
+ struct avc_audit_data *ad, u32 sock_sid, u16 sock_class,
+ u16 family, char *addrp, int len)
{
- u16 family;
- char *addrp;
- int len, err = 0;
+ int err = 0;
u32 netif_perm, node_perm, node_sid, if_sid, recv_perm = 0;
- u32 sock_sid = 0;
- u16 sock_class = 0;
- struct socket *sock;
- struct net_device *dev;
- struct avc_audit_data ad;
-
- family = sk-sk_family;
- if (family != PF_INET family != PF_INET6)
- goto out;
-
- /* Handle mapped IPv4 packets arriving via IPv6 sockets */
- if (family == PF_INET6 skb-protocol == htons(ETH_P_IP))
- family = PF_INET;
-
- read_lock_bh(sk-sk_callback_lock);
- sock = sk-sk_socket;
- if (sock) {
- struct inode *inode;
- inode = SOCK_INODE(sock);
- if (inode) {
- struct inode_security_struct *isec;
- isec = inode-i_security;
- sock_sid = isec-sid;
- sock_class = isec-sclass;
- }
- }
- read_unlock_bh(sk-sk_callback_lock);
- if (!sock_sid)
- goto out;
- dev = skb-dev;
- if (!dev)
+ if (!skb-dev)
goto
[patch 11/17] secmark: Add secmark support to conntrack
From: James Morris [EMAIL PROTECTED]
Add a secmark field to IP and NF conntracks, so that security markings on
packets can be copied to their associated connections, and also copied back to
packets as required. This is similar to the network mark field currently used
with conntrack, although it is intended for enforcement of security policy
rather than network policy.
Signed-off-by: James Morris [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
include/linux/netfilter_ipv4/ip_conntrack.h |4 ++
include/net/netfilter/nf_conntrack.h |4 ++
include/net/netfilter/nf_conntrack_compat.h | 26 +
net/ipv4/netfilter/Kconfig | 12 +++
net/ipv4/netfilter/ip_conntrack_core.c |3 +
net/ipv4/netfilter/ip_conntrack_standalone.c |5 +++
net/netfilter/Kconfig| 12 +++
net/netfilter/nf_conntrack_core.c|3 +
net/netfilter/nf_conntrack_standalone.c |5 +++
9 files changed, 74 insertions(+)
diff -puN
include/linux/netfilter_ipv4/ip_conntrack.h~secmark-add-secmark-support-to-conntrack
include/linux/netfilter_ipv4/ip_conntrack.h
---
devel/include/linux/netfilter_ipv4/ip_conntrack.h~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/include/linux/netfilter_ipv4/ip_conntrack.h 2006-06-01
20:31:50.0 -0700
@@ -120,6 +120,10 @@ struct ip_conntrack
u_int32_t mark;
#endif
+#ifdef CONFIG_IP_NF_CONNTRACK_SECMARK
+ u_int32_t secmark;
+#endif
+
/* Traversed often, so hopefully in different cacheline to top */
/* These are my tuples; original and reply */
struct ip_conntrack_tuple_hash tuplehash[IP_CT_DIR_MAX];
diff -puN
include/net/netfilter/nf_conntrack_compat.h~secmark-add-secmark-support-to-conntrack
include/net/netfilter/nf_conntrack_compat.h
---
devel/include/net/netfilter/nf_conntrack_compat.h~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/include/net/netfilter/nf_conntrack_compat.h 2006-06-01
20:31:50.0 -0700
@@ -20,6 +20,19 @@ static inline u_int32_t *nf_ct_get_mark(
}
#endif /* CONFIG_IP_NF_CONNTRACK_MARK */
+#ifdef CONFIG_IP_NF_CONNTRACK_SECMARK
+static inline u_int32_t *nf_ct_get_secmark(const struct sk_buff *skb,
+ u_int32_t *ctinfo)
+{
+ struct ip_conntrack *ct = ip_conntrack_get(skb, ctinfo);
+
+ if (ct)
+ return ct-secmark;
+ else
+ return NULL;
+}
+#endif /* CONFIG_IP_NF_CONNTRACK_SECMARK */
+
#ifdef CONFIG_IP_NF_CT_ACCT
static inline struct ip_conntrack_counter *
nf_ct_get_counters(const struct sk_buff *skb)
@@ -70,6 +83,19 @@ static inline u_int32_t *nf_ct_get_mark(
}
#endif /* CONFIG_NF_CONNTRACK_MARK */
+#ifdef CONFIG_NF_CONNTRACK_SECMARK
+static inline u_int32_t *nf_ct_get_secmark(const struct sk_buff *skb,
+ u_int32_t *ctinfo)
+{
+ struct nf_conn *ct = nf_ct_get(skb, ctinfo);
+
+ if (ct)
+ return ct-secmark;
+ else
+ return NULL;
+}
+#endif /* CONFIG_NF_CONNTRACK_MARK */
+
#ifdef CONFIG_NF_CT_ACCT
static inline struct ip_conntrack_counter *
nf_ct_get_counters(const struct sk_buff *skb)
diff -puN
include/net/netfilter/nf_conntrack.h~secmark-add-secmark-support-to-conntrack
include/net/netfilter/nf_conntrack.h
---
devel/include/net/netfilter/nf_conntrack.h~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/include/net/netfilter/nf_conntrack.h 2006-06-01
20:31:50.0 -0700
@@ -113,6 +113,10 @@ struct nf_conn
u_int32_t mark;
#endif
+#ifdef CONFIG_NF_CONNTRACK_SECMARK
+ u_int32_t secmark;
+#endif
+
/* Storage reserved for other modules: */
union nf_conntrack_proto proto;
diff -puN
net/ipv4/netfilter/ip_conntrack_core.c~secmark-add-secmark-support-to-conntrack
net/ipv4/netfilter/ip_conntrack_core.c
---
devel/net/ipv4/netfilter/ip_conntrack_core.c~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
+++ devel-akpm/net/ipv4/netfilter/ip_conntrack_core.c 2006-06-01
20:31:50.0 -0700
@@ -724,6 +724,9 @@ init_conntrack(struct ip_conntrack_tuple
/* this is ugly, but there is no other place where to put it */
conntrack-nat.masq_index = exp-master-nat.masq_index;
#endif
+#ifdef CONFIG_IP_NF_CONNTRACK_SECMARK
+ conntrack-secmark = exp-master-secmark;
+#endif
nf_conntrack_get(conntrack-master-ct_general);
CONNTRACK_STAT_INC(expect_new);
} else {
diff -puN
net/ipv4/netfilter/ip_conntrack_standalone.c~secmark-add-secmark-support-to-conntrack
net/ipv4/netfilter/ip_conntrack_standalone.c
---
devel/net/ipv4/netfilter/ip_conntrack_standalone.c~secmark-add-secmark-support-to-conntrack
2006-06-01 20:31:50.0 -0700
[patch 15/17] pppoe: missing result check in __pppoe_xmit()
From: Florin Malita [EMAIL PROTECTED] skb_clone() may fail, we should check the result. Coverity CID: 1215. Signed-off-by: Florin Malita [EMAIL PROTECTED] Cc: David S. Miller [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/net/pppoe.c |3 +++ 1 file changed, 3 insertions(+) diff -puN drivers/net/pppoe.c~pppoe-missing-result-check-in-__pppoe_xmit drivers/net/pppoe.c --- devel/drivers/net/pppoe.c~pppoe-missing-result-check-in-__pppoe_xmit 2006-06-01 20:31:50.0 -0700 +++ devel-akpm/drivers/net/pppoe.c 2006-06-01 20:31:50.0 -0700 @@ -861,6 +861,9 @@ static int __pppoe_xmit(struct sock *sk, * give dev_queue_xmit something it can free. */ skb2 = skb_clone(skb, GFP_ATOMIC); + + if (skb2 == NULL) + goto abort; } ph = (struct pppoe_hdr *) skb_push(skb2, sizeof(struct pppoe_hdr)); _ - 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/17] eliminate unused /proc/sys/net/ethernet
From: Jes Sorensen [EMAIL PROTECTED]
The /proc/sys/net/ethernet directory has been sitting empty for more than
10 years! Time to eliminate it!
Signed-off-by: Jes Sorensen [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
net/ethernet/Makefile |1 -
net/ethernet/sysctl_net_ether.c | 14 --
net/sysctl_net.c|8
3 files changed, 23 deletions(-)
diff -puN net/ethernet/Makefile~eliminate-unused-proc-sys-net-ethernet
net/ethernet/Makefile
--- devel/net/ethernet/Makefile~eliminate-unused-proc-sys-net-ethernet
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/net/ethernet/Makefile2006-06-01 20:31:49.0 -0700
@@ -3,6 +3,5 @@
#
obj-y += eth.o
-obj-$(CONFIG_SYSCTL) += sysctl_net_ether.o
obj-$(subst m,y,$(CONFIG_IPX)) += pe2.o
obj-$(subst m,y,$(CONFIG_ATALK)) += pe2.o
diff -L net/ethernet/sysctl_net_ether.c -puN
net/ethernet/sysctl_net_ether.c~eliminate-unused-proc-sys-net-ethernet /dev/null
--- devel/net/ethernet/sysctl_net_ether.c
+++ /dev/null 2006-06-01 17:04:03.273681250 -0700
@@ -1,14 +0,0 @@
-/* -*- linux-c -*-
- * sysctl_net_ether.c: sysctl interface to net Ethernet subsystem.
- *
- * Begun April 1, 1996, Mike Shaver.
- * Added /proc/sys/net/ether directory entry (empty =) ). [MS]
- */
-
-#include linux/mm.h
-#include linux/sysctl.h
-#include linux/if_ether.h
-
-ctl_table ether_table[] = {
- {0}
-};
diff -puN net/sysctl_net.c~eliminate-unused-proc-sys-net-ethernet
net/sysctl_net.c
--- devel/net/sysctl_net.c~eliminate-unused-proc-sys-net-ethernet
2006-06-01 20:31:49.0 -0700
+++ devel-akpm/net/sysctl_net.c 2006-06-01 20:31:49.0 -0700
@@ -37,14 +37,6 @@ struct ctl_table net_table[] = {
.mode = 0555,
.child = core_table,
},
-#ifdef CONFIG_NET
- {
- .ctl_name = NET_ETHER,
- .procname = ethernet,
- .mode = 0555,
- .child = ether_table,
- },
-#endif
#ifdef CONFIG_INET
{
.ctl_name = NET_IPV4,
_
-
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: orinoco encodeext + auth patch on lkml
Hello, Dan! On Wed, 2006-05-31 at 08:03 -0400, Dan Williams wrote: Pavel, Unsure if you saw this. Slightly annoying he didn't send to netdev, but would be good to take a look at and possibly integrate. Looks sane to me from 10,000ft. http://lkml.org/lkml/2006/5/30/433 Thanks for heads up. Actually, this e-mail was copied to the orinoco mailing list, so I'm aware of it. -- Regards, Pavel Roskin - 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
