Re: Updated sysctl documentation take #2
On Thu, 8 Jun 2006 00:18:06 +0200 Diego Calleja wrote: > El Wed, 7 Jun 2006 13:06:53 -0700, > "Randy.Dunlap" <[EMAIL PROTECTED]> escribió: > > > OK, that's all for the README file. I'll look at the rest of it > > sometime this week. I don't think that it's quite ready to be merged. > > Thank's for your review, altought I didn't though someone was to review > so deeply a documentation patch ;) I've gone through all the files and > fixed the 72-col limit and everything I could. I've updated the patch > http://terra.es/personal/diegocg/sysctl-docs Here are some more comments for you. 1. There are quite a few lines (17) ending with ^M (carriage return) that should be removed. 2. Lines like this one should end with a period (full stop): +This file is SPARC-only 3. I would put this comment near the top of each file, not at the end: +PLEASE KEEP THIS FILE ORDERED ALPHABETICALLY. Other than that, it's looking good to me. Thanks, --- ~Randy - 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 6646] New: UDP socket doesn't return to bound state after association is dissolved by connect(..AF_UNSPEC)
From: Andrew Morton <[EMAIL PROTECTED]> Date: Mon, 5 Jun 2006 00:07:51 -0700 > > When disconnect a UDP socket, Linux kernel set local port to zero if the > > port > > number comes from a implicit bind. Linux connect(2) man page reads: > > "Generally, connection-based protocol sockets may successfully *connect* > > only > > once; connectionless protocol sockets may use *connect* multiple times to > > change > > their association. Connectionless sockets may dissolve the association by > > connecting to an address with the /sa_family/ member of *sockaddr* set to > > *AF_UNSPEC*." > > But dissolve the association should not impact the local binding, while > > currently it does. In contrast, Unix variants like Solaris don't alter local > > binding when disconnecting a UDP socket. You can only preserve the parts of a local binding which are explicitly specified. Since you make an explicit bind to a source address, that will be preserved by the disconnect. However, since you use a zero anonymous port during the bind, the one choosen by the kernel will not be preserved. If you had choosen an explicit port during bind() it would be preserved by the disconnect. This behavior is intentional and will not change. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost
On Sat, 10 Jun 2006 12:13:35 -0700, Randy.Dunlap wrote:
>On Sat, 10 Jun 2006 14:11:42 +0200 (MEST) Mikael Pettersson wrote:
>
>> While compiling 2.6.17-rc6 for a 486 with an NE2000 ISA ethernet card, I got:
>>
>> WARNING: drivers/net/ne.o - Section mismatch: reference to
>> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
>> 0x158) and 'ne_block_input'
>> WARNING: drivers/net/ne.o - Section mismatch: reference to
>> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
>> 0x176) and 'ne_block_input'
>> WARNING: drivers/net/ne.o - Section mismatch: reference to
>> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
>> 0x183) and 'ne_block_input'
>> WARNING: drivers/net/ne.o - Section mismatch: reference to
>> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
>> 0x1ea) and 'ne_block_input'
>> WARNING: drivers/net/ne.o - Section mismatch: reference to
>> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
>> 0x251) and 'ne_block_input'
>> WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from
>> .text between 'init_module' (at offset 0x266) and 'ne_block_input'
>> WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from
>> .text between 'init_module' (at offset 0x29b) and 'ne_block_input'
>>
>> Not sure how serious this is; the driver seems to work fine later on.
>
>Doesn't look serious. init_module() is not __init, but it calls
>some __init functions and touches some __initdata.
>
>BTW, I would be happy to see some consistent results from modpost
>section checking. I don't see all of these warnings (I see only 1)
>when using gcc 3.3.6. What gcc version are you using?
>Does that matter? (not directed at anyone in particular)
The messages above are from when I used gcc-4.1.1.
With gcc-3.2.3 I only see a single warning.
>Patch below fixes it for me. Please test/report.
Worked for me too. Thanks.
/Mikael
>---
>
>From: Randy Dunlap <[EMAIL PROTECTED]>
>
>Fix section mismatch warnings:
>WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from
>.text between 'init_module' (at offset 0x396) and 'cleanup_card'
>WARNING: drivers/net/ne2.o - Section mismatch: reference to .init.text: from
>.text between 'init_module' (at offset 0x483) and 'cleanup_card'
>
>Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
>---
> drivers/net/ne.c |2 +-
> drivers/net/ne2.c |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
>--- linux-2617-rc6.orig/drivers/net/ne.c
>+++ linux-2617-rc6/drivers/net/ne.c
>@@ -829,7 +829,7 @@ that the ne2k probe is the last 8390 bas
> is at boot) and so the probe will get confused by any other 8390 cards.
> ISA device autoprobes on a running machine are not recommended anyway. */
>
>-int init_module(void)
>+int __init init_module(void)
> {
> int this_dev, found = 0;
>
>--- linux-2617-rc6.orig/drivers/net/ne2.c
>+++ linux-2617-rc6/drivers/net/ne2.c
>@@ -780,7 +780,7 @@ MODULE_PARM_DESC(bad, "(ignored)");
>
> /* Module code fixed by David Weinehall */
>
>-int init_module(void)
>+int __init init_module(void)
> {
> struct net_device *dev;
> int this_dev, found = 0;
>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Francois Romieu <[EMAIL PROTECTED]> : [...] > -> the != ... && ... != test above seems inverted. Answering to myself: yes, it is. The 8100 and 8101 are PCI Express fast ethernet only (but they should do 802.1q, go figure). -- 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
[PATCH 2.6.17-rc6-mm2] eth1394: replace __constant_htons by htons
...and __constant_ntohs, __constant_ntohl, __constant_cpu_to_be32 too
where possible. Htons and friends are resolved to constants in these
places anyway. Also fix an endianess glitch in a log message, spotted
by Alexey Dobriyan.
Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
drivers/ieee1394/eth1394.c | 23 +++
1 files changed, 11 insertions(+), 12 deletions(-)
Index: linux-2.6.17-rc6-mm2/drivers/ieee1394/eth1394.c
===
--- linux-2.6.17-rc6-mm2.orig/drivers/ieee1394/eth1394.c2006-06-10
21:18:28.0 +0200
+++ linux-2.6.17-rc6-mm2/drivers/ieee1394/eth1394.c 2006-06-10
21:33:59.0 +0200
@@ -770,7 +770,7 @@ static int ether1394_rebuild_header(stru
default:
ETH1394_PRINT(KERN_DEBUG, dev->name,
"unable to resolve type %04x addresses.\n",
- eth->h_proto);
+ ntohs(eth->h_proto));
break;
}
@@ -792,9 +792,8 @@ static int ether1394_header_cache(struct
(16 - ETH1394_HLEN));
struct net_device *dev = neigh->dev;
- if (type == __constant_htons(ETH_P_802_3)) {
+ if (type == htons(ETH_P_802_3))
return -1;
- }
eth->h_proto = type;
memcpy(eth->h_dest, neigh->ha, dev->addr_len);
@@ -883,7 +882,7 @@ static inline u16 ether1394_parse_encap(
/* If this is an ARP packet, convert it. First, we want to make
* use of some of the fields, since they tell us a little bit
* about the sending machine. */
- if (ether_type == __constant_htons (ETH_P_ARP)) {
+ if (ether_type == htons(ETH_P_ARP)) {
struct eth1394_arp *arp1394 = (struct eth1394_arp*)skb->data;
struct arphdr *arp = (struct arphdr *)skb->data;
unsigned char *arp_ptr = (unsigned char *)(arp + 1);
@@ -939,8 +938,8 @@ static inline u16 ether1394_parse_encap(
}
/* Now add the ethernet header. */
- if (dev->hard_header (skb, dev, __constant_ntohs (ether_type),
- &dest_hw, NULL, skb->len) >= 0)
+ if (dev->hard_header(skb, dev, ntohs(ether_type), &dest_hw, NULL,
+skb->len) >= 0)
ret = ether1394_type_trans(skb, dev);
return ret;
@@ -1509,8 +1508,8 @@ static inline void ether1394_prep_gasp_p
p->data = ((quadlet_t*)skb->data) - 2;
p->data[0] = cpu_to_be32((priv->host->node_id << 16) |
ETHER1394_GASP_SPECIFIER_ID_HI);
- p->data[1] = __constant_cpu_to_be32((ETHER1394_GASP_SPECIFIER_ID_LO <<
24) |
- ETHER1394_GASP_VERSION);
+ p->data[1] = cpu_to_be32((ETHER1394_GASP_SPECIFIER_ID_LO << 24) |
+ETHER1394_GASP_VERSION);
/* Setting the node id to ALL_NODES (not LOCAL_BUS | ALL_NODES)
* prevents hpsb_send_packet() from setting the speed to an arbitrary
@@ -1665,9 +1664,9 @@ static int ether1394_tx (struct sk_buff
/* Set the transmission type for the packet. ARP packets and IP
* broadcast packets are sent via GASP. */
if (memcmp(eth->h_dest, dev->broadcast, ETH1394_ALEN) == 0 ||
- proto == __constant_htons(ETH_P_ARP) ||
- (proto == __constant_htons(ETH_P_IP) &&
-IN_MULTICAST(__constant_ntohl(skb->nh.iph->daddr {
+ proto == htons(ETH_P_ARP) ||
+ (proto == htons(ETH_P_IP) &&
+IN_MULTICAST(ntohl(skb->nh.iph->daddr {
tx_type = ETH1394_GASP;
dest_node = LOCAL_BUS | ALL_NODES;
max_payload = priv->bc_maxpayload - ETHER1394_GASP_OVERHEAD;
@@ -1699,7 +1698,7 @@ static int ether1394_tx (struct sk_buff
}
/* If this is an ARP packet, convert it */
- if (proto == __constant_htons (ETH_P_ARP))
+ if (proto == htons(ETH_P_ARP))
ether1394_arp_to_1394arp (skb, dev);
ptask->hdr.words.word1 = 0;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost
> >
> > Not sure how serious this is; the driver seems to work fine later on.
>
> Doesn't look serious. init_module() is not __init, but it calls
> some __init functions and touches some __initdata.
This is the typical case with inconsistent tagging.
> BTW, I would be happy to see some consistent results from modpost
> section checking. I don't see all of these warnings (I see only 1)
> when using gcc 3.3.6. What gcc version are you using?
> Does that matter? (not directed at anyone in particular)
I did not see anyone of them - strange.
I did not dig into it, but objdump -rR ne.o should tell the number of
mismatches with soem carefull checking.
> --- linux-2617-rc6.orig/drivers/net/ne.c
> +++ linux-2617-rc6/drivers/net/ne.c
> @@ -829,7 +829,7 @@ that the ne2k probe is the last 8390 bas
> is at boot) and so the probe will get confused by any other 8390 cards.
> ISA device autoprobes on a running machine are not recommended anyway. */
>
> -int init_module(void)
> +int __init init_module(void)
> {
> int this_dev, found = 0;
When you anyway touches the driver I suggest to name the function
_init, _cleanup and use module_init(), module_cleanup().
Sam
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] hp ethernet: fix section mismatches
From: Randy Dunlap <[EMAIL PROTECTED]>
Priority: not critical; makes init code discardable.
Fix section mismatch warnings:
WARNING: drivers/net/hp-plus.o - Section mismatch: reference to .init.text:
from .text between 'init_module' (at offset 0x387) and 'cleanup_card'
WARNING: drivers/net/hp.o - Section mismatch: reference to .init.data: from
.text between 'hp_init_card' (at offset 0x310) and 'init_module'
WARNING: drivers/net/hp.o - Section mismatch: reference to .init.text: from
.text between 'init_module' (at offset 0x367) and 'cleanup_card'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/hp-plus.c |2 +-
drivers/net/hp.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--- linux-2617-rc6.orig/drivers/net/hp-plus.c
+++ linux-2617-rc6/drivers/net/hp-plus.c
@@ -446,7 +446,7 @@ MODULE_LICENSE("GPL");
/* This is set up so that only a single autoprobe takes place per call.
ISA device autoprobes on a running machine are not recommended. */
-int
+int __init
init_module(void)
{
struct net_device *dev;
--- linux-2617-rc6.orig/drivers/net/hp.c
+++ linux-2617-rc6/drivers/net/hp.c
@@ -384,7 +384,7 @@ hp_block_output(struct net_device *dev,
}
/* This function resets the ethercard if something screws up. */
-static void
+static void __init
hp_init_card(struct net_device *dev)
{
int irq = dev->irq;
@@ -409,7 +409,7 @@ MODULE_LICENSE("GPL");
/* This is set up so that only a single autoprobe takes place per call.
ISA device autoprobes on a running machine are not recommended. */
-int
+int __init
init_module(void)
{
struct net_device *dev;
---
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] smc ethernet: fix section mismatch warnings
From: Randy Dunlap <[EMAIL PROTECTED]>
Priority: not critical; makes init code discardable.
Removes one duplicate assignment.
Fix section mismatch warnings:
WARNING: drivers/net/smc-ultra.o - Section mismatch: reference to .init.text:
from .text between 'init_module' (at offset 0x369) and 'cleanup_card'
WARNING: drivers/net/smc-ultra32.o - Section mismatch: reference to
.init.text:ultra32_probe from .text between 'init_module' (at offset 0x254) and
'cleanup_module'
WARNING: drivers/net/smc9194.o - Section mismatch: reference to
.init.text:smc_init from .text between 'init_module' (at offset 0x997) and
'cleanup_module'
WARNING: drivers/net/smc9194.o - Section mismatch: reference to .init.data:
from .data between 'smcdev.0' (at offset 0x44) and '__param_str_io'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/smc-ultra.c |2 +-
drivers/net/smc-ultra32.c |2 +-
drivers/net/smc9194.c |7 ++-
3 files changed, 4 insertions(+), 7 deletions(-)
--- linux-2617-rc6.orig/drivers/net/smc-ultra.c
+++ linux-2617-rc6/drivers/net/smc-ultra.c
@@ -553,7 +553,7 @@ MODULE_LICENSE("GPL");
/* This is set up so that only a single autoprobe takes place per call.
ISA device autoprobes on a running machine are not recommended. */
-int
+int __init
init_module(void)
{
struct net_device *dev;
--- linux-2617-rc6.orig/drivers/net/smc-ultra32.c
+++ linux-2617-rc6/drivers/net/smc-ultra32.c
@@ -421,7 +421,7 @@ static struct net_device *dev_ultra[MAX_
MODULE_DESCRIPTION("SMC Ultra32 EISA ethernet driver");
MODULE_LICENSE("GPL");
-int init_module(void)
+int __init init_module(void)
{
int this_dev, found = 0;
--- linux-2617-rc6.orig/drivers/net/smc9194.c
+++ linux-2617-rc6/drivers/net/smc9194.c
@@ -732,12 +732,9 @@ static int ifport;
struct net_device * __init smc_init(int unit)
{
struct net_device *dev = alloc_etherdev(sizeof(struct smc_local));
- static struct devlist *smcdev = smc_devlist;
+ struct devlist *smcdev = smc_devlist;
int err = 0;
-#ifndef NO_AUTOPROBE
- smcdev = smc_devlist;
-#endif
if (!dev)
return ERR_PTR(-ENODEV);
@@ -1607,7 +1604,7 @@ MODULE_PARM_DESC(io, "SMC 99194 I/O base
MODULE_PARM_DESC(irq, "SMC 99194 IRQ number");
MODULE_PARM_DESC(ifport, "SMC 99194 interface port (0-default, 1-TP, 2-AUI)");
-int init_module(void)
+int __init init_module(void)
{
if (io == 0)
printk(KERN_WARNING
---
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Oliver Neukum wrote:
+static void disconnect(struct usb_interface *intf)
+{
This is racy. It allows io to disconnected devices. You must take the
lock and set a flag that you test after you've taken the lock elsewhere.
It's been a bit of an adventure, but I'm now fairly confident that only
a single-line change is required to fix this: stop the TX queue early on
in the netdev->stop function.
When disconnect() happens, we call unregister_netdev(). This will call
netdev->stop if the interface was up, and netdev->stop ensures that no
more packets are queued for transmission, and that the host does not
receive any more packets or interrupts from the device.
unregister_netdev() also does some synchronization and rtnl stuff, and
after it has returned, it is guaranteed that no ioctls or other
functions (hard_start_xmit/set_mac_address) are in progress, and it is
guaranteed that no more of those will happen.
In disconnect() we also kill all urbs that we know about. All of our URB
completions handle the cancelled case without generating further I/O.
Additionally, the return values of all of our usb I/O function calls are
checked and propagated up, so most code will simply stop when the device
gets unplugged.
At this point, it's now safe to say that nobody is using (or will use)
the various structures, so disconnect() frees the whole lot and returns.
Do you agree, or did you have certain other race paths in mind which I
might have missed?
Thanks,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost
On Sat, 10 Jun 2006 14:11:42 +0200 (MEST) Mikael Pettersson wrote:
> While compiling 2.6.17-rc6 for a 486 with an NE2000 ISA ethernet card, I got:
>
> WARNING: drivers/net/ne.o - Section mismatch: reference to
> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
> 0x158) and 'ne_block_input'
> WARNING: drivers/net/ne.o - Section mismatch: reference to
> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
> 0x176) and 'ne_block_input'
> WARNING: drivers/net/ne.o - Section mismatch: reference to
> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
> 0x183) and 'ne_block_input'
> WARNING: drivers/net/ne.o - Section mismatch: reference to
> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
> 0x1ea) and 'ne_block_input'
> WARNING: drivers/net/ne.o - Section mismatch: reference to
> .init.data:isapnp_clone_list from .text between 'init_module' (at offset
> 0x251) and 'ne_block_input'
> WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from
> .text between 'init_module' (at offset 0x266) and 'ne_block_input'
> WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from
> .text between 'init_module' (at offset 0x29b) and 'ne_block_input'
>
> Not sure how serious this is; the driver seems to work fine later on.
Doesn't look serious. init_module() is not __init, but it calls
some __init functions and touches some __initdata.
BTW, I would be happy to see some consistent results from modpost
section checking. I don't see all of these warnings (I see only 1)
when using gcc 3.3.6. What gcc version are you using?
Does that matter? (not directed at anyone in particular)
Patch below fixes it for me. Please test/report.
---
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch warnings:
WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from
.text between 'init_module' (at offset 0x396) and 'cleanup_card'
WARNING: drivers/net/ne2.o - Section mismatch: reference to .init.text: from
.text between 'init_module' (at offset 0x483) and 'cleanup_card'
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
drivers/net/ne.c |2 +-
drivers/net/ne2.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2617-rc6.orig/drivers/net/ne.c
+++ linux-2617-rc6/drivers/net/ne.c
@@ -829,7 +829,7 @@ that the ne2k probe is the last 8390 bas
is at boot) and so the probe will get confused by any other 8390 cards.
ISA device autoprobes on a running machine are not recommended anyway. */
-int init_module(void)
+int __init init_module(void)
{
int this_dev, found = 0;
--- linux-2617-rc6.orig/drivers/net/ne2.c
+++ linux-2617-rc6/drivers/net/ne2.c
@@ -780,7 +780,7 @@ MODULE_PARM_DESC(bad, "(ignored)");
/* Module code fixed by David Weinehall */
-int init_module(void)
+int __init init_module(void)
{
struct net_device *dev;
int this_dev, found = 0;
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
On Sat, Jun 10, 2006 at 08:50:10PM +0300, Faidon Liambotis wrote:
> Remove Prism II IDs from the orinoco driver since now we have a separate
> driver for them (HostAP). Additionally, kill orinoco_{pci,plx,nortel}
> completely, since they only exist to support Prism cards.
> No attempt was made to clean up the rest of the driver of the actual
> Prism II code, only the PCI IDs were removed.
I'm fairly certain I have a buffalo card that doesn't work with hostap
that works just fine with orinoco. I'll dig it out and see if that
has been improved.
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.17-rc6] Add two PLX device IDs
This patch adds device IDs for Symbol LA-4123 and Global Sun Tech GL24110P to the HostAP PLX driver. This is not tested with real hardware, but there is no reason why it shouldn't work. Please test. Signed-off-by: Faidon Liambotis <[EMAIL PROTECTED]> -- hostap_plx.c |2 ++ 1 files changed, 2 insertions(+) diff -Nur linux-2.6.17-rc6/drivers/net/wireless/hostap/hostap_plx.c linux/drivers/net/wireless/hostap/hostap_plx.c --- linux-2.6.17-rc6/drivers/net/wireless/hostap/hostap_plx.c 2006-06-06 03:57:02.0 +0300 +++ linux/drivers/net/wireless/hostap/hostap_plx.c 2006-06-10 19:20:10.0 +0300 @@ -67,10 +67,12 @@ PLXDEV(0x10b7, 0x7770, "3Com AirConnect PCI 777A"), PLXDEV(0x111a, 0x1023, "Siemens SpeedStream SS1023"), PLXDEV(0x126c, 0x8030, "Nortel emobility"), + PLXDEV(0x1562, 0x0001, "Symbol LA-4123"), PLXDEV(0x1385, 0x4100, "Netgear MA301"), PLXDEV(0x15e8, 0x0130, "National Datacomm NCP130 (PLX9052)"), PLXDEV(0x15e8, 0x0131, "National Datacomm NCP130 (TMD7160)"), PLXDEV(0x1638, 0x1100, "Eumitcom WL11000"), + PLXDEV(0x16ab, 0x1100, "Global Sun Tech GL24110P"), PLXDEV(0x16ab, 0x1101, "Global Sun Tech GL24110P (?)"), PLXDEV(0x16ab, 0x1102, "Linksys WPC11 with WDT11"), PLXDEV(0x16ab, 0x1103, "Longshine 8031"), - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.17-rc6] Remove Prism II support from Orinoco
Remove Prism II IDs from the orinoco driver since now we have a separate
driver for them (HostAP). Additionally, kill orinoco_{pci,plx,nortel}
completely, since they only exist to support Prism cards.
No attempt was made to clean up the rest of the driver of the actual
Prism II code, only the PCI IDs were removed.
Signed-off-by: Faidon Liambotis <[EMAIL PROTECTED]>
--
drivers/net/wireless/Kconfig | 61 -
drivers/net/wireless/Makefile |4
drivers/net/wireless/orinoco_cs.c | 24 --
drivers/net/wireless/orinoco_nortel.c | 312 --
drivers/net/wireless/orinoco_pci.c| 399 -
drivers/net/wireless/orinoco_plx.c| 403 --
drivers/net/wireless/orinoco_tmd.c| 260 -
7 files changed, 9 insertions(+), 1454 deletions(-)
diff -Nur linux-2.6.17-rc6/drivers/net/wireless/Kconfig
linux/drivers/net/wireless/Kconfig
--- linux-2.6.17-rc6/drivers/net/wireless/Kconfig 2006-06-06
03:57:02.0 +0300
+++ linux/drivers/net/wireless/Kconfig 2006-06-10 19:03:27.0 +0300
@@ -285,18 +285,16 @@
depends on NET_RADIO && (PPC_PMAC || PCI || PCMCIA)
---help---
A driver for 802.11b wireless cards based based on the "Hermes" or
- Intersil HFA384x (Prism 2) MAC controller. This includes the vast
- majority of the PCMCIA 802.11b cards (which are nearly all rebadges)
- - except for the Cisco/Aironet cards. Cards supported include the
- Apple Airport (not a PCMCIA card), WavelanIEEE/Orinoco,
- Cabletron/EnteraSys Roamabout, ELSA AirLancer, MELCO Buffalo, Avaya,
- IBM High Rate Wireless, Farralon Syyline, Samsung MagicLAN, Netgear
- MA401, LinkSys WPC-11, D-Link DWL-650, 3Com AirConnect, Intel
- PRO/Wireless, and Symbol Spectrum24 High Rate amongst others.
+ MAC controller. Cards supported include the Apple Airport (not a
+ PCMCIA card), WavelanIEEE/Orinoco, Cabletron/EnteraSys Roamabout,
+ ELSA AirLancer, MELCO Buffalo, Avaya, IBM High Rate Wireless,
+ Farralon Syyline, Samsung MagicLAN, Netgear MA401, LinkSys WPC-11,
+ D-Link DWL-650, 3Com AirConnect, Intel PRO/Wireless, and Symbol
+ Spectrum24 High Rate amongst others.
This option includes the guts of the driver, but in order to
actually use a card you will also need to enable support for PCMCIA
- Hermes cards, PLX9052 based PCI adaptors or the Apple Airport below.
+ Hermes cards or the Apple Airport below.
You will also very likely also need the Wireless Tools in order to
configure your card and that /etc/pcmcia/wireless.opts works :
@@ -314,46 +312,6 @@
This driver does not support the Airport Extreme (802.11b/g). Use
the BCM43xx driver for Airport Extreme cards.
-config PLX_HERMES
- tristate "Hermes in PLX9052 based PCI adaptor support (Netgear MA301
etc.)"
- depends on PCI && HERMES
- help
- Enable support for PCMCIA cards supported by the "Hermes" (aka
- orinoco) driver when used in PLX9052 based PCI adaptors. These
- adaptors are not a full PCMCIA controller but act as a more limited
- PCI <-> PCMCIA bridge. Several vendors sell such adaptors so that
- 802.11b PCMCIA cards can be used in desktop machines. The Netgear
- MA301 is such an adaptor.
-
-config TMD_HERMES
- tristate "Hermes in TMD7160 based PCI adaptor support"
- depends on PCI && HERMES
- help
- Enable support for PCMCIA cards supported by the "Hermes" (aka
- orinoco) driver when used in TMD7160 based PCI adaptors. These
- adaptors are not a full PCMCIA controller but act as a more limited
- PCI <-> PCMCIA bridge. Several vendors sell such adaptors so that
- 802.11b PCMCIA cards can be used in desktop machines.
-
-config NORTEL_HERMES
- tristate "Nortel emobility PCI adaptor support"
- depends on PCI && HERMES
- help
- Enable support for PCMCIA cards supported by the "Hermes" (aka
- orinoco) driver when used in Nortel emobility PCI adaptors. These
- adaptors are not full PCMCIA controllers, but act as a more limited
- PCI <-> PCMCIA bridge.
-
-config PCI_HERMES
- tristate "Prism 2.5 PCI 802.11b adaptor support"
- depends on PCI && HERMES
- help
- Enable support for PCI and mini-PCI 802.11b wireless NICs based on
- the Prism 2.5 chipset. These are true PCI cards, not the 802.11b
- PCMCIA cards bundled with PCI<->PCMCIA adaptors which are also
- common. Some of the built-in wireless adaptors in laptops are of
- this variety.
-
config ATMEL
tristate "Atmel at76c50x chipset 802.11b support"
depends on NET_RADIO && (PCI || PCMCIA)
@@ -388,9 +346,8 @@
A driver for "Hermes" ch
Re: netif_tx_disable vs netif_stop_queue (possible races?)
On Sat, Jun 10, 2006 at 05:40:39PM +0100, Daniel Drake ([EMAIL PROTECTED]) wrote: > Evgeniy Polyakov wrote: > >On Sat, Jun 10, 2006 at 01:42:21PM +0100, Daniel Drake ([EMAIL PROTECTED]) > >wrote: > >>Herbert Xu wrote: > >>>Correct. All callers of hard_start_xmit do so under RCU or equivalent > >>>locks so they must be complete by the time synchronize_net() returns. > >>Does this hold for other operations? Such as: > >> > >>- The netdev->set_mac_address function > >>- The wireless ioctl's (SIOCSIWESSID, etc) > >> > >>Are these also guaranteed to have returned after synchronize_net()? > > > >None of above calls is protected with RCU (except set_mac_address() > >called through ioctl, which is performed under read_lock which disables > >preemtption), so they still can run after synchronize_net(). > > > >But if you are talking about synchronize_net() inside > >unregister_netdevice(), which is called from > >usbnet_disconnect()->unregister_netdev(), than it is safe. > > Are you referring to set_mac_address in the above statement, or both > set_mac_address *and* the wireless ioctls? oth calls have the same nature actually, and both calls are not protected by RCU. > I'm basically just looking to clarify that after unregister_netdev has > completed, none of the following can be still in progress on any CPU, > and none of the following can be triggered again: > > 1. hard_start_xmit handler > 2. set_mac_address handler > 3. WX ioctls > > It's logical that this is the case, but the code doesn't make that very > clear (and would certainly result in many potential ZD1211 races if this > was not the case). set_mac_address() and wireless ioctls are protected by rtnl. unregister_netdevice() is called under rtnl protection too. But hard_start_xmit() is not protected (and can not be protected in all situations) by sleeping semaphore (like rtnl), so instead it runs under RCU, which is synchronized in synchronize_net() inside unregister_netdevice(). > Daniel -- Evgeniy Polyakov - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] eth1394: endian fixes
Alexey Dobriyan wrote on 2006-05-27: On Sat, May 27, 2006 at 12:05:40PM +0200, Stefan Richter wrote: Did you have the chance to test your patch on different platforms and with different peer OSs/platforms? Unfortunately not. The patch works OK on an x86/Linux host with x86/WinXP peer and ppc32/OSX peer. Thanks, -- Stefan Richter -=-=-==- -==- -=-=- http://arcgraph.de/sr/ - 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 vs netif_stop_queue (possible races?)
Evgeniy Polyakov wrote: On Sat, Jun 10, 2006 at 01:42:21PM +0100, Daniel Drake ([EMAIL PROTECTED]) wrote: Herbert Xu wrote: Correct. All callers of hard_start_xmit do so under RCU or equivalent locks so they must be complete by the time synchronize_net() returns. Does this hold for other operations? Such as: - The netdev->set_mac_address function - The wireless ioctl's (SIOCSIWESSID, etc) Are these also guaranteed to have returned after synchronize_net()? None of above calls is protected with RCU (except set_mac_address() called through ioctl, which is performed under read_lock which disables preemtption), so they still can run after synchronize_net(). But if you are talking about synchronize_net() inside unregister_netdevice(), which is called from usbnet_disconnect()->unregister_netdev(), than it is safe. Are you referring to set_mac_address in the above statement, or both set_mac_address *and* the wireless ioctls? I'm basically just looking to clarify that after unregister_netdev has completed, none of the following can be still in progress on any CPU, and none of the following can be triggered again: 1. hard_start_xmit handler 2. set_mac_address handler 3. WX ioctls It's logical that this is the case, but the code doesn't make that very clear (and would certainly result in many potential ZD1211 races if this was not the case). Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
LIBIPQ: problem with Injecting encapsulated packet (plz somebody ) reply)]
Hi,
I am posting this query again. plz somebody reply. Also I am new to
IPtables and LIBIPQ
I am working on a application that involves encapsulatting the packets .
Suppose there are 3 machines A B C. Assume that machine A is sending some
some information to machine B. All I do is to capture packets(using
libipq) destined for machine B on machine A and send it to machine C . I
encapuslate this captured packet in a new packet with(adding both IP/UDP
header, although UDP header is not really required, with destinatin
address as machine C IP).
The issue is that after the call to set_verdict function, instead of the
encapsulated packet, original packet is getting transmitted. I tried my
best to find the solution with no success. I am updating the checksum
correctly after adding new header.
Below is snippet of my code
**
unsigned char *new_packet = NULL;
struct iphdr *new_iphdr;
struct iphdr *original_iphdr = (struct iphdr *)(m->payload);
int status;
new_packet = (unsigned char *) calloc(1,sizeof(struct iphdr) +
(m->data_len) + sizeof(struct udphdr));
new_iphdr = (struct iphdr *) calloc(1,sizeof(struct iphdr));
/* extra Udp header */
struct udphdr *new_udp;
new_udp = (struct udphdr *) calloc(1,sizeof(struct udphdr));
new_udp->source = htons(5);
new_udp->dest = htons(5);
new_udp->len = original_iphdr->tot_len;
new_udp->check = 0;
/* udp*/
/** New IP header **/
new_iphdr->version = original_iphdr->version;
new_iphdr->ihl = original_iphdr->ihl;
new_iphdr->tos = original_iphdr->tos;
new_iphdr->id = original_iphdr->id;;
new_iphdr->frag_off = original_iphdr->frag_off;
new_iphdr->ttl = original_iphdr->ttl;
new_iphdr->protocol = original_iphdr->protocol;
new_iphdr->saddr= inet_addr("10.107.26.27");//original_iphdr->saddr;
new_iphdr->daddr=inet_addr("10.12.25.7");//daddr.s_addr;
new_iphdr->tot_len=htons(ntohs(original_iphdr->tot_len)+
(sizeof(struct iphdr))+ sizeof(struct udphdr));
new_iphdr->check=0;
new_iphdr->check=(((ip_sum_calc((unsigned short
*)new_iphdr,sizeof(struct iphdr);
// Place the IP packet inside another IP packet
memcpy(new_packet,new_iphdr,(unsigned int)sizeof(struct iphdr));
memcpy(new_packet+sizeof(struct iphdr),new_udp,(unsigned
int)sizeof(struct udphdr));
memcpy(new_packet+sizeof(struct iphdr)+sizeof(struct
udphdr),m->payload,m->data_len);
size_t length = ntohs(new_iphdr->tot_len);;
status =
ipq_set_verdict(handle,m->packet_id,NF_ACCEPT,length,(unsigned char
*) new_packet);
if(status < 0)
{
printf("\n Packet Modification failed \n");
die();
}
printf("\n Packet Transmitted Successfull \n");
*checksum function**
unsigned short ip_sum_calc(unsigned short *addr,int len)
{
int nleft = len;
int sum = 0;
unsigned short *w = addr;
unsigned short answer = 0;
printf(" \nsize %d", sizeof(sum));
while (nleft > 1)
{
sum += *w++;
nleft -= 2;
}
if (nleft == 1)
{
*(unsigned char *)(&answer) = *(unsigned char *) w;
sum += answer;
}
sum = (sum >> 16) + (sum & 0x);
sum += (sum >> 16);
answer = ~sum;
return answer;
}
-
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
Wrong IPv4 source address selected
This is 2.6.17-rc6 running on a 32-bit ppc (the same ARC=ppc PReP machine that had the x_tables problem, so it has the x_tables alignment first fix too). The problem: IPv4 source addresses are sometimes selected wrong (packets are sent to the internal 172.30 network with external 193.40 source address). I have seen this with ARP requests for 172.30.0.x addresses and UDP multicast traffic (avahi query from 193.40.37.61:5353 to 224.0.0.251:5353 on eth1). I have 2 physical network interfaces (+ loopback + unconfiured sit0) 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 08:00:3e:28:c4:a2 brd ff:ff:ff:ff:ff:ff inet 193.40.37.61/23 brd 193.40.37.255 scope global eth0 inet6 2001:bb8:2002:2400:a00:3eff:fe28:c4a2/64 scope global dynamic valid_lft 2591964sec preferred_lft 604764sec inet6 fe80::a00:3eff:fe28:c4a2/64 scope link valid_lft forever preferred_lft forever 3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:00:94:7a:31:8c brd ff:ff:ff:ff:ff:ff inet 172.30.0.1/24 brd 172.30.0.255 scope global eth1 inet6 fe80::200:94ff:fe7a:318c/64 scope link valid_lft forever preferred_lft forever ip route ls: 172.30.0.0/24 dev eth1 proto kernel scope link src 172.30.0.1 193.40.36.0/23 dev eth0 proto kernel scope link src 193.40.37.61 default via 193.40.36.1 dev eth0 -- 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: netif_tx_disable vs netif_stop_queue (possible races?)
On Sat, Jun 10, 2006 at 01:42:21PM +0100, Daniel Drake ([EMAIL PROTECTED]) wrote: > Herbert Xu wrote: > >Correct. All callers of hard_start_xmit do so under RCU or equivalent > >locks so they must be complete by the time synchronize_net() returns. > > Does this hold for other operations? Such as: > > - The netdev->set_mac_address function > - The wireless ioctl's (SIOCSIWESSID, etc) > > Are these also guaranteed to have returned after synchronize_net()? None of above calls is protected with RCU (except set_mac_address() called through ioctl, which is performed under read_lock which disables preemtption), so they still can run after synchronize_net(). But if you are talking about synchronize_net() inside unregister_netdevice(), which is called from usbnet_disconnect()->unregister_netdev(), than it is safe. > Thanks, > Daniel -- 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: netif_tx_disable vs netif_stop_queue (possible races?)
Herbert Xu wrote: Correct. All callers of hard_start_xmit do so under RCU or equivalent locks so they must be complete by the time synchronize_net() returns. Does this hold for other operations? Such as: - The netdev->set_mac_address function - The wireless ioctl's (SIOCSIWESSID, etc) Are these also guaranteed to have returned after synchronize_net()? Thanks, Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Ulrich Kunitz wrote: Not so fast, because I don't know what to fix. I am working on it. A couple more mails to Herbert Xu should clarify it, then I'll post a patch. On first glance I was quite worried that there are a lot of potential races, but now I think there will only be a few places. Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.17-rc6] Section mismatch in drivers/net/ne.o during modpost
While compiling 2.6.17-rc6 for a 486 with an NE2000 ISA ethernet card, I got: Building modules, stage 2. make -rR -f /tmp/linux-2.6.17-rc6/scripts/Makefile.modpost scripts/mod/modpost -o /tmp/linux-2.6.17-rc6/Module.symvers vmlinux drivers/net/8390.o drivers/net/ne.o lib/crc32.o net/packet/af_packet.o WARNING: drivers/net/ne.o - Section mismatch: reference to .init.data:isapnp_clone_list from .text between 'init_module' (at offset 0x158) and 'ne_block_input' WARNING: drivers/net/ne.o - Section mismatch: reference to .init.data:isapnp_clone_list from .text between 'init_module' (at offset 0x176) and 'ne_block_input' WARNING: drivers/net/ne.o - Section mismatch: reference to .init.data:isapnp_clone_list from .text between 'init_module' (at offset 0x183) and 'ne_block_input' WARNING: drivers/net/ne.o - Section mismatch: reference to .init.data:isapnp_clone_list from .text between 'init_module' (at offset 0x1ea) and 'ne_block_input' WARNING: drivers/net/ne.o - Section mismatch: reference to .init.data:isapnp_clone_list from .text between 'init_module' (at offset 0x251) and 'ne_block_input' WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from .text between 'init_module' (at offset 0x266) and 'ne_block_input' WARNING: drivers/net/ne.o - Section mismatch: reference to .init.text: from .text between 'init_module' (at offset 0x29b) and 'ne_block_input' Not sure how serious this is; the driver seems to work fine later on. /Mikael - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT] Realtek 8168 ethernet support
Jeff Garzik <[EMAIL PROTECTED]> :
> Francois Romieu wrote:
> >Jeff Garzik <[EMAIL PROTECTED]> :
> >>Randy.Dunlap wrote:
> >>>Conversely, any reason to use the RealTek r1000 driver?
> >>FWIW, RealTek emailed me about merging r1000. I suggested that, if the
> >
> >Which one ?
> >
> >r1000_n.c where #define RELEASE_DATE "2006/02/23"
>
> They didn't say. Just "r1000"
Can you ask your Realtek person if he is really sure about the following
snippet in r1000_n.c::r1000_init_one:
if((priv->mcfg!=MCFG_METHOD_13)&&(priv->mcfg!=MCFG_METHOD_14)&&(priv->mcfg!=MCFG_METHOD_15))
printk("This Realtek NIC doesn't support 1000Mbps\n");
else
Cap1000 = PHY_Cap_1000_Full|PHY_Cap_1000_Half;
-> in forced 1000 mode, 1000_{Half/Full} would only be written to the
advertisement register for MCFG_METHOD_1{3/4/5}. It excludes all
the adapters that the in-kernel driver support (huh ?).
Later in the same function:
[...]
if(( priv->mcfg == MCFG_METHOD_11 )||( priv->mcfg == MCFG_METHOD_12 ))
printk("Realtek RTL8168/8111 Family PCI-E Gigabit Ethernet
Network Adapter\n");
else
if((priv->mcfg==MCFG_METHOD_13)||(priv->mcfg==MCFG_METHOD_14)||(priv->mcfg==MCFG_METHOD_15))
printk("Realtek RTL8139/810x Family Fast Ethernet Network
Adapter\n");
-> the != ... && ... != test above seems inverted.
Btw, it would be nice if he could confirm that the 0x10ec/0x8129 ID
sent by Yoichi Yuasa is really allowed (and not a random bitflip).
--
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
[PATCH] bnx2: endian fixes
Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---
drivers/net/bnx2.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/net/bnx2.c
+++ b/drivers/net/bnx2.c
@@ -1820,7 +1820,7 @@ reuse_rx:
skb->protocol = eth_type_trans(skb, bp->dev);
if ((len > (bp->dev->mtu + ETH_HLEN)) &&
- (htons(skb->protocol) != 0x8100)) {
+ (ntohs(skb->protocol) != 0x8100)) {
dev_kfree_skb_irq(skb);
goto next_rx;
@@ -4310,7 +4310,7 @@ bnx2_start_xmit(struct sk_buff *skb, str
ip_tcp_len = (skb->nh.iph->ihl << 2) + sizeof(struct tcphdr);
skb->nh.iph->check = 0;
- skb->nh.iph->tot_len = ntohs(mss + ip_tcp_len + tcp_opt_len);
+ skb->nh.iph->tot_len = htons(mss + ip_tcp_len + tcp_opt_len);
skb->h.th->check =
~csum_tcpudp_magic(skb->nh.iph->saddr,
skb->nh.iph->daddr,
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
Am Samstag, 10. Juni 2006 13:23 schrieb Ulrich Kunitz: > On 06-06-04 00:25 Oliver Neukum wrote: > > > > > +static void disconnect(struct usb_interface *intf) > > > > This is racy. It allows io to disconnected devices. You must take the > > > > lock and set a flag that you test after you've taken the lock elsewhere. > > > > > > Will fix, thanks. > > > > You're welcome > > Not so fast, because I don't know what to fix. > > Actually there are two cases, when disconnect is called. The first There are three cases. It can also be triggered by sysfs and usbfs. > is, when the device is removed. The second is, when the kernel > module is removed from the kernel. It should also be recognized > that disconnect() must always succeed, so we have to ignore IO > errors anyhow. You can ignore IO errors in disconnect(). They are harmless. > In the first case we don't need the IO and in the second case we > have to do it, because otherwise, the device will not come up, if > we load the driver again. > > Testing shows, that doing the IO doesn't create a lot of issues, > there are some errors reported, but that's it and the second case > just works fine. So there doesn't appear a problem and even if > want to be "clean", I would like to know, how to distinguish both > cases without trying to do IO with the device. The problem is not that you may do IO _during_ disconnect. You may do IO _after_ disconnect, even if usbfs might already have claimed the device. Disconnect() must either terminate ongoing IO or wait for it to end. And it must make sure that there'll be no IO afterwards. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-usb-devel] [PATCH RFC] ZyDAS ZD1211 USB-WLAN driver
On 06-06-04 00:25 Oliver Neukum wrote: > > > +static void disconnect(struct usb_interface *intf) > > > This is racy. It allows io to disconnected devices. You must take the > > > lock and set a flag that you test after you've taken the lock elsewhere. > > > > Will fix, thanks. > > You're welcome Not so fast, because I don't know what to fix. Actually there are two cases, when disconnect is called. The first is, when the device is removed. The second is, when the kernel module is removed from the kernel. It should also be recognized that disconnect() must always succeed, so we have to ignore IO errors anyhow. In the first case we don't need the IO and in the second case we have to do it, because otherwise, the device will not come up, if we load the driver again. Testing shows, that doing the IO doesn't create a lot of issues, there are some errors reported, but that's it and the second case just works fine. So there doesn't appear a problem and even if want to be "clean", I would like to know, how to distinguish both cases without trying to do IO with the device. In the meanwhile I removed the misleading comment about locking. I would like also like to know, that beside the fact that device IO fails, which races can happen? -- Uli Kunitz - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [patch 0/6] [Network namespace] introduction
[EMAIL PROTECTED] writes in gmane.linux.network,gmane.linux.kernel: > The following patches create a private "network namespace" for use > within containers. This is intended for use with system containers > like vserver, but might also be useful for restricting individual > applications' access to the network stack. > > These patches isolate traffic inside the network namespace. The > network ressources, the incoming and the outgoing packets are > identified to be related to a namespace. > > It hides network resource not contained in the current namespace, but > still allows administration of the network with normal commands like > ifconfig. > > It applies to the kernel version 2.6.17-rc6-mm1 > > It provides the following: > - >- when an application unshares its network namespace, it looses its > view of all network devices by default. The administrator can > choose to make any devices to become visible again. The container > then gains a view to the device but without the ip address > configured on it. It is up to the container administrator to use > ifconfig or ip command to setup a new ip address. This ip address > is only visible inside the container. Do other namespaces work differently ? When namespace is unshared, it has initially the same resources (for example compare to CLONE_NEWNS) >- the loopback is isolated inside the container and it is not > possible to communicate between containers via the > loopback. > >- several containers can have an application bind to the same > address:port without conflicting. That of course be problem, if initially unshared namespace shares same resources. / Kari Hurtta - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: wireless (was Re: 2.6.18 -mm merge plans)
Hi! > > > It's just that a cleanroom approach is a sure way to prove > > > you didn't copy. That's all. > > > > Which is an extremely important detail especially if you have been > > reverse engineering another driver for the same or similar OS where it > > is likely that people will retain knowledge and copy rather than > > re-implement th?ngs. > > oh don't get me wrong, it's important to not copy from the original. > (even if that original did copy from linux ;) Well, if original did copy from linux, it surely is GPLed and case closed, no? Being sued from vendor not respecting the GPL would probably only do harm to them. Like US courts are crazy, but hopefully not _that_ crazy. Pavel -- Thanks for all the (sleeping) penguins. - 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
