netfilter tables config problem
(on 2.6.20-rc1-git8) It's possible to have CONFIG_NETFILTER_XTABLES=y and CONFIG_IP6_NF_MATCH_IPV6HEADER=m, which causes this build error: net/built-in.o: In function `hashlimit_match': xt_hashlimit.c:(.text+0x1c887): undefined reference to `ipv6_find_hdr' make: *** [.tmp_vmlinux1] Error 1 Clean build if I set CONFIG_IP6_NF_MATCH_IPV6HEADER=y. .config (for i386) attached. --- ~Randy config-netfilt2-ipv6-hdr Description: Binary data
d80211 and SMP issues
Hi Sorry if you receive this email twice, my email is acting a little weird. I was looking at SMP issues in d80211 stack, below in my finding. I did change the d80211 stack to add SMP safety code. I will email these patches later after I update them with what ever feedback I will get back. The D80211 stack has many entry points; this could leads to race conditions and use of invalid pointers. This document will point out the shared data between all threads which can run concurrently. D80211 threads and entry points. 1- Wireless handler callback functions. We don't need to protect these functions from each other since each function touches different data. 2- net_device callback functions. The only one we have to worry about is hard_start_xmit which runs in software interrupt context. 3- timers, d80211 uses three timers. Below is a list of all function names of these timers: * ieee80211_stat_refresh timer function. It is SMP safe and appropriate locks are used to protect shared data. * sta_info_cleanup timer function. It is SMP safe and appropriate locks are used to protect shared data. * ieee80211_scan_start timer function. N/A 4- Work queue. Below is a list of all callback functions used by work queues. * ieee80211_sta_work function. This function is the heart beat that monitors the state of the connection. It uses shared data with other threads that need to be protected. Inside this function it calls the appropriate function according to the state. These functions are supposed to be mutually exclusive, however they are also called from other threads. We need partial locking in these function to keep a valid state across concurrent execution. A new spinlock called local->ifsta_state_lock was added to protect state's shared data. * ieee80211_sta_scan_work. This function is SMP safe. * sta_info_proc_add_task, this function is SMP safe. 5- export functions of d80211. Most of these functions are SMP safe except ieee80211_beacon_get which shares data that can be touched by other threads concurrently. 6- tasklet functions. There are two tasklet functions used by D80211. These are: * ieee80211_tx_pending tasklet is used to transfer pending Tx frames. It uses the same route as hard_start_xmit, so any fix in hard_start_xmit should apply to it. * ieee80211_tasklet_handler tasklet is used as the Rx route. It uses shared data with other threads. Data to protect We have two types of shared data to protect. Shared pointers need to be protected. The thread that is going to set a pointer needs to lock the access, change or allocate pointer then unlock. The thread that is going to access this pointer needs to lock it first, check pointer if it is a valid to use, use the pointer. It must keep the lock for as long as it is using the pointer, then unlock. The other shared data type is groups of data that are used together, like essid and essid_length. These groupings must be locked any time any part of that data is used or changed by any thread. Shared data The only shared data we need to protect are the members of these structures: * local, ifdata bss and sta. We use ifsta_data_lock to protect these shared data. ifsta->assocreq_ies ifsta->assocreq_ies_len ifsta->assocresp_ies ifsta->assocresp_ies_len ifsta->bssid ifsta->auth_alg ifsta->ssid_len ifsta->ssid ifsta->assocresp_ies ifsta->probe_resp ifsta->auth_algs ifsta->extra_ie ifsta->extra_ie_len sdata->u.ap.generic_elem sdata->u.ap.beacon_head sdata->u.ap.beacon_tail ifsta->auth_transaction local->curr_rates local->phymode local->sta_scanning This shared data is touched by two functions: * ieee80211_sta_req_scan and ieee80211_scan_completed These functions are called from different threads. The lock in these functions is to protect from two scan requests invoked at the same time (protecting the scan state from a race condition) Data we did not protect: sdata->fragments sdata->fragment_next pending_packet We don't need to lock these because the data is only used and changed from the one Rx thread. State shared data. We use ifsta_state_lock to protect state shared data which is used to identify the state of the connection and association steps. This is also used to prevent mutual exclusive functions to run at the same time in these sections. The sections where state shared data are changed: ifsta->auth_alg ifsta->auth_tries ifsta->assoc_tries; sdata->u.sta.associated sdata->u.sta.authenticated Shared data of ieee80211_sta_bss structure is protected by using local->sta_bss_lock lock. We needed to add a lock in ieee80211_rx_bss_info function where we change and allocate its members. The same lock is used to protect reader thread of this data in ieee80211_sta_scan_result function. Is anything above incorrect? What other locking issues are people looking to have resolved before merging? Thanks Mohamed - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majord
Fwd: d80211 and SMP
Hi I was looking at SMP issues in d80211 stack, below in my finding. I did change the d80211 stack to add SMP safety code. I will email these patches later after I update them with what ever feedback I will get back. The D80211 stack has many entry points; this could leads to race conditions and use of invalid pointers. This document will point out the shared data between all threads which can run concurrently. D80211 threads and entry points. 1- Wireless handler callback functions. We don't need to protect these functions from each other since each function touches different data. 2- net_device callback functions. The only one we have to worry about is hard_start_xmit which runs in software interrupt context. 3- timers, d80211 uses three timers. Below is a list of all function names of these timers: * ieee80211_stat_refresh timer function. It is SMP safe and appropriate locks are used to protect shared data. * sta_info_cleanup timer function. It is SMP safe and appropriate locks are used to protect shared data. * ieee80211_scan_start timer function. N/A 4- Work queue. Below is a list of all callback functions used by work queues. * ieee80211_sta_work function. This function is the heart beat that monitors the state of the connection. It uses shared data with other threads that need to be protected. Inside this function it calls the appropriate function according to the state. These functions are supposed to be mutually exclusive, however they are also called from other threads. We need partial locking in these function to keep a valid state across concurrent execution. A new spinlock called local->ifsta_state_lock was added to protect state's shared data. * ieee80211_sta_scan_work. This function is SMP safe. * sta_info_proc_add_task, this function is SMP safe. 5- export functions of d80211. Most of these functions are SMP safe except ieee80211_beacon_get which shares data that can be touched by other threads concurrently. 6- tasklet functions. There are two tasklet functions used by D80211. These are: * ieee80211_tx_pending tasklet is used to transfer pending Tx frames. It uses the same route as hard_start_xmit, so any fix in hard_start_xmit should apply to it. * ieee80211_tasklet_handler tasklet is used as the Rx route. It uses shared data with other threads. Data to protect We have two types of shared data to protect. Shared pointers need to be protected. The thread that is going to set a pointer needs to lock the access, change or allocate pointer then unlock. The thread that is going to access this pointer needs to lock it first, check pointer if it is a valid to use, use the pointer. It must keep the lock for as long as it is using the pointer, then unlock. The other shared data type is groups of data that are used together, like essid and essid_length. These groupings must be locked any time any part of that data is used or changed by any thread. Shared data The only shared data we need to protect are the members of these structures: * local, ifdata bss and sta. We use ifsta_data_lock to protect these shared data. ifsta->assocreq_ies ifsta->assocreq_ies_len ifsta->assocresp_ies ifsta->assocresp_ies_len ifsta->bssid ifsta->auth_alg ifsta->ssid_len ifsta->ssid ifsta->assocresp_ies ifsta->probe_resp ifsta->auth_algs ifsta->extra_ie ifsta->extra_ie_len sdata->u.ap.generic_elem sdata->u.ap.beacon_head sdata->u.ap.beacon_tail ifsta->auth_transaction local->curr_rates local->phymode local->sta_scanning This shared data is touched by two functions: * ieee80211_sta_req_scan and ieee80211_scan_completed These functions are called from different threads. The lock in these functions is to protect from two scan requests invoked at the same time (protecting the scan state from a race condition) Data we did not protect: sdata->fragments sdata->fragment_next pending_packet We don't need to lock these because the data is only used and changed from the one Rx thread. State shared data. We use ifsta_state_lock to protect state shared data which is used to identify the state of the connection and association steps. This is also used to prevent mutual exclusive functions to run at the same time in these sections. The sections where state shared data are changed: ifsta->auth_alg ifsta->auth_tries ifsta->assoc_tries; sdata->u.sta.associated sdata->u.sta.authenticated Shared data of ieee80211_sta_bss structure is protected by using local->sta_bss_lock lock. We needed to add a lock in ieee80211_rx_bss_info function where we change and allocate its members. The same lock is used to protect reader thread of this data in ieee80211_sta_scan_result function. Is anything above incorrect? What other locking issues are people looking to have resolved before merging? Thanks Mohamed - 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: removing gotos considered harmful...
On 12/22/06, David Miller <[EMAIL PROTECTED]> wrote: Because of massively painful regressions like the following, I absolutely refuse to apply "cleanup" patches to remove gotos for "clarity". All such patches do is change the code and potentially add bugs, they don't help in any way at all. Gerrit, please be more careful next time, and resist the urge to "fix" stuff that isn't broken just to satisfy your own personal coding tastes during a conversion. This is a locally exploitable hole, all someone has to do is open a few hundred UDP sockets to a particular destination port and then nobody, not even root, can so much as run ping successfully. Arnaldo, sorry I originally thought this bug was added by you, you're totally innocent this time :-))) Was so fast I wasn't even able to plead "not guilty!" :-) - Arnaldo - 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: Generic PHY lib vs. locking
On Fri, 2006-12-22 at 10:24 -0500, David Hollis wrote: > On Fri, 2006-12-22 at 15:07 +1100, Benjamin Herrenschmidt wrote: > > Hi Andy ! > > > > I've been looking at porting various drivers (EMAC, sungem, > > spider_net, ...) to the generic PHY stuff. However, I have one > > significant problem here. > > > > > One solution would be to change it to use a mutex instead of a lock as > > well, though that would change the requirements of where phy_start/stop > > can be called, and use a delayed work queue instead of a timer. > > Wouldn't this change also allow it to be used with USB Ethernet devices? > I was looking at porting the asix.c drive to use the PHY layer but the > locking killed that effort since USB devices can't do spinlocks without > hosing things up. Yes, possibly. At the end of the day, I get the locking in the driver down to something like: - All rx/tx operatations are done between the NAPI poll and the hard_start_xmit() routine. Locking here is done with the netif_tx_lock if needed (depends on the driver). Those can't sleep. - Everything else is task level and locks against the fast path above with stopping NAPI poll and stopping tx. I have my driver_netif_stop/start routines doing that and a bit more (see below). - There is at least one issue with set_multicast which is called with the lock held. What I do here is that my driver_netif_stop above also take the lock, set a flag tellign set-mcast to say away, release the lock. start() on the other hand take the lock, clears that flag, checks if another flag was set by set-mcast telling it was here, and does the mcast setting if that was the case. I much prefer that than having most of the driver operations locked with the tx lock or some other or run at softirq. Some of the reset/recovery operations can be slow, PHY operations too, and thus it's all better run at task level. In addition, MDIO access might be able to sleep waiting on an interrupt signaling the completion of the access. Ben. - 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
removing gotos considered harmful...
Because of massively painful regressions like the following,
I absolutely refuse to apply "cleanup" patches to remove gotos
for "clarity". All such patches do is change the code and
potentially add bugs, they don't help in any way at all.
Gerrit, please be more careful next time, and resist the urge to "fix"
stuff that isn't broken just to satisfy your own personal coding
tastes during a conversion. This is a locally exploitable hole,
all someone has to do is open a few hundred UDP sockets to a
particular destination port and then nobody, not even root, can
so much as run ping successfully.
Arnaldo, sorry I originally thought this bug was added by you, you're
totally innocent this time :-)))
I've submitted this fix to Linus and 2.6.19-stable.
Thanks.
[UDP]: Fix reversed logic in udp_get_port().
When this code was converted to use sk_for_each() the
logic for the "best hash chain length" code was reversed,
breaking everything.
The original code was of the form:
size = 0;
do {
if (++size >= best_size_so_far)
goto next;
} while ((sk = sk->next) != NULL);
best_size_so_far = size;
best = result;
next:;
and this got converted into:
sk_for_each(sk2, node, head)
if (++size < best_size_so_far) {
best_size_so_far = size;
best = result;
}
Which does something very very different from the original.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 9e1bd37..404dd21 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -167,11 +167,14 @@ int udp_get_port(struct sock *sk, unsigned short snum,
goto gotit;
}
size = 0;
- sk_for_each(sk2, node, head)
- if (++size < best_size_so_far) {
- best_size_so_far = size;
- best = result;
- }
+ sk_for_each(sk2, node, head) {
+ if (++size >= best_size_so_far)
+ goto next;
+ }
+ best_size_so_far = size;
+ best = result;
+ next:
+ ;
}
result = best;
for(i = 0; i < (1 << 16) / UDP_HTABLE_SIZE; i++, result +=
UDP_HTABLE_SIZE) {
-
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 -mm 0/5] proposal for dynamic configurable netconsole
On Fri, 22 Dec 2006 21:01:09 +0900 Keiichi KII <[EMAIL PROTECTED]> wrote: > From: Keiichi KII <[EMAIL PROTECTED]> > > The netconsole is a very useful module for collecting kernel message under > certain circumstances(e.g. disk logging fails, serial port is unavailable). > > But current netconsole is not flexible. For example, if you want to change ip > address for logging agent, in the case of built-in netconsole, you can't > change > config except for changing boot parameter and rebooting your system, or in the > case of module netconsole, you need to reload netconsole module. If netconsole is a module, you should be able to remove it and reload with different parameters. > So, I propose the following extended features for netconsole. > > 1) support for multiple logging agents. > 2) add interface to access each parameter of netconsole >using sysfs. > > This patch is for linux-2.6.20-rc1-mm1 and is divided to each function. > Your comments are very welcome. Rather than extending the existing kludge with module parameter, to sysfs. I would rather see a better API for this. Please build think about doing a better API with a basic set of ioctl's. Some additional things: - shouldn't just be IPV4 specific, should handle IPV6 as well - shouldn't specify MAC address, it can do network discovery/arp to find that when adding addresses - 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
bcm43xx from 2.6.20-rc1-mm1 on HPC nx6325 (x86_64)
I'm trying to make the bcm43xx driver out of the 2.6.20-rc1-mm1 kernel work on
an HPC nx6325, with no luck, so far, although I'm using a firmware that has
been reported to work with these boxes
(http://gentoo-wiki.com/HARDWARE_Gentoo_on_HP_Compaq_nx6325#Onboard_Wireless_.28802.11.29).
The driver loads and seems to operate the hardware to some extent, but there
seems to be a problem with interrupts. Namely, the chip doesn't seem to
generate any.
Raphael J. Wysocki wrote:
> Right after a fresh 'modprobe bcm43xx' I get the following messages in dmesg:
> bcm43xx driver
> ACPI: PCI Interrupt :30:00.0[A] -> GSI 18 (level, low) -> IRQ 18
> PCI: Setting latency timer of device :30:00.0 to 64
> bcm43xx: Chip ID 0x4311, rev 0x1
> bcm43xx: Number of cores: 4
> bcm43xx: Core 0: ID 0x800, rev 0x11, vendor 0x4243
> bcm43xx: Core 1: ID 0x812, rev 0xa, vendor 0x4243
> bcm43xx: Core 2: ID 0x817, rev 0x3, vendor 0x4243
> bcm43xx: Core 3: ID 0x820, rev 0x1, vendor 0x4243
> bcm43xx: PHY connected
> bcm43xx: Detected PHY: Version: 4, Type 2, Revision 8
> bcm43xx: Detected Radio: ID: 2205017f (Manuf: 17f Ver: 2050 Rev: 2)
> bcm43xx: Radio turned off
> bcm43xx: Radio turned off
> PM: Adding info for No Bus:eth1
> printk: 3 messages suppressed.
> SoftMAC: ASSERTION FAILED (0) at: >
net/ieee80211/softmac/ieee80211softmac_wx.c:306:ieee80211softmac_wx_get_rate()
>
> but, strangely enough, eth1 does not appear, but eth2 appears instead:
>
Usually the problem generates an oops, but I think your problem is due to the changes in the work
struct in 2.6.20-rc1. There is a fix in the pipeline, but it has not propagated through the system.
You should apply the work_struct2 patch attached. If your computer has a switch to kill the RF, you
may also wish to apply the radio_hwenable patch, which should cause the radio LED to be turned on.
The selection of eth2 rather than eth1 is probably due to the rules in
/etc/udev/rules.d/30-net_persistent_names.rules. When I boot a softmac version, my bcm43xx device is
wlan0, but when I boot the d80211 version, it is eth1. I have a second bcm43xx card, which becomes
eth2 under softmac.
Larry
From: Ulrich Kunitz <[EMAIL PROTECTED]>
The signature of work functions changed recently from a context
pointer to the work structure pointer. This caused a problem in
the ieee80211softmac code, because the ieee80211softmac_assox_work
function has been called directly with a parameter explicitly
casted to (void*). This compiled correctly but resulted in a
softlock, because mutex_lock was called with the wrong memory
address. The patch fixes the problem. Another issue was a wrong
call of the schedule_work function. Softmac works again and this
fixes the problem I mentioned earlier in the zd1211rw rx tasklet
patch. The patch is against Linus' tree (commit af1713e0).
Signed-off-by: Ulrich Kunitz <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
Signed-off-by: Larry Finger <[EMAIL PROTECTED]>
---
John,
This patch should be pushed upstream to 2.6.20. At the moment, the work
struct changes have not yet propagated to wireless-2.6. When they do,
it will be needed there as well.
Larry
net/ieee80211/softmac/ieee80211softmac_assoc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ieee80211/softmac/ieee80211softmac_assoc.c
b/net/ieee80211/softmac/ieee80211softmac_assoc.c
index eec1a1d..a824852 100644
--- a/net/ieee80211/softmac/ieee80211softmac_assoc.c
+++ b/net/ieee80211/softmac/ieee80211softmac_assoc.c
@@ -167,7 +167,7 @@ static void
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);
+ ieee80211softmac_assoc_work(&mac->associnfo.work.work);
}
static void
@@ -177,7 +177,7 @@ ieee80211softmac_assoc_notify_auth(struc
switch (event_type) {
case IEEE80211SOFTMAC_EVENT_AUTHENTICATED:
- ieee80211softmac_assoc_work((void*)mac);
+ ieee80211softmac_assoc_work(&mac->associnfo.work.work);
break;
case IEEE80211SOFTMAC_EVENT_AUTH_FAILED:
case IEEE80211SOFTMAC_EVENT_AUTH_TIMEOUT:
Index: linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
===
--- linux-2.6.orig/drivers/net/wireless/bcm43xx/bcm43xx_main.c
+++ linux-2.6/drivers/net/wireless/bcm43xx/bcm43xx_main.c
@@ -2441,6 +2441,9 @@ static int bcm43xx_chip_init(struct bcm4
if (err)
goto err_gpio_cleanup;
bcm43xx_radio_turn_on(bcm);
+ bcm->radio_hw_enable = bcm43xx_is_hw_radio_enabled(bcm);
+ printk(KERN_INFO PFX "Radio %s by hardware\n",
+ (bcm->radio_hw_enable == 0) ? "disabled" : "enabled");
bcm43xx_write16(bcm, 0x03E6, 0x);
err = bcm43xx_phy_init(bcm);
@@ -3172,9 +3175,24 @@ static void bcm43xx_periodic_every30sec(
sta
Re: Generic PHY lib vs. locking
On Fri, 2006-12-22 at 15:07 +1100, Benjamin Herrenschmidt wrote: > Hi Andy ! > > I've been looking at porting various drivers (EMAC, sungem, > spider_net, ...) to the generic PHY stuff. However, I have one > significant problem here. > > One solution would be to change it to use a mutex instead of a lock as > well, though that would change the requirements of where phy_start/stop > can be called, and use a delayed work queue instead of a timer. Wouldn't this change also allow it to be used with USB Ethernet devices? I was looking at porting the asix.c drive to use the PHY layer but the locking killed that effort since USB devices can't do spinlocks without hosing things up. -- David Hollis <[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] Fix up smc911x after work_struct changes
Fix up the smc911x driver after the work_struct changes.
Signed-off-by: Peter Korsgaard <[EMAIL PROTECTED]>
diff -urpN linux-2.6.20-rc1/drivers/net/smc911x.c
linux-2.6.20-rc1.new/drivers/net/smc911x.c
--- linux-2.6.20-rc1/drivers/net/smc911x.c 2006-11-29 22:57:37.0
+0100
+++ linux-2.6.20-rc1.new/drivers/net/smc911x.c 2006-12-22 15:13:15.0
+0100
@@ -123,6 +123,9 @@ struct smc911x_local {
*/
struct net_device_stats stats;
+ /* parent net device for easy reference in _phy_configure */
+ struct net_device *dev;
+
/* version/revision of the SMC911x chip */
u16 version;
u16 revision;
@@ -948,10 +951,11 @@ static void smc911x_phy_check_media(stru
* of autonegotiation.) If the RPC ANEG bit is cleared, the selection
* is controlled by the RPC SPEED and RPC DPLX bits.
*/
-static void smc911x_phy_configure(void *data)
+static void smc911x_phy_configure(struct work_struct *work)
{
- struct net_device *dev = data;
- struct smc911x_local *lp = netdev_priv(dev);
+ struct smc911x_local *lp =
+ container_of(work, struct smc911x_local, phy_configure);
+ struct net_device *dev = lp->dev;
unsigned long ioaddr = dev->base_addr;
int phyaddr = lp->mii.phy_id;
int my_phy_caps; /* My PHY capabilities */
@@ -1495,6 +1499,8 @@ static void smc911x_set_multicast_list(s
static int
smc911x_open(struct net_device *dev)
{
+ struct smc911x_local *lp = netdev_priv(dev);
+
DBG(SMC_DEBUG_FUNC, "%s: --> %s\n", dev->name, __FUNCTION__);
/*
@@ -1511,7 +1517,7 @@ smc911x_open(struct net_device *dev)
smc911x_reset(dev);
/* Configure the PHY, initialize the link state */
- smc911x_phy_configure(dev);
+ smc911x_phy_configure(&lp->phy_configure);
/* Turn on Tx + Rx */
smc911x_enable(dev);
@@ -2060,7 +2066,8 @@ static int __init smc911x_probe(struct n
dev->poll_controller = smc911x_poll_controller;
#endif
- INIT_WORK(&lp->phy_configure, smc911x_phy_configure, dev);
+ INIT_WORK(&lp->phy_configure, smc911x_phy_configure);
+ lp->dev = dev;
lp->mii.phy_id_mask = 0x1f;
lp->mii.reg_num_mask = 0x1f;
lp->mii.force_media = 0;
@@ -2275,7 +2282,7 @@ static int smc911x_drv_resume(struct pla
smc911x_reset(ndev);
smc911x_enable(ndev);
if (lp->phy_type != 0)
- smc911x_phy_configure(ndev);
+ smc911x_phy_configure(&lp->phy_configure);
netif_device_attach(ndev);
}
}
--
Bye, Peter Korsgaard
-
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] igmp: spin_lock_bh in timer (Re: BUG: soft lockup detected on CPU#0!)
Jarek Poplawski wrote: On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote: On 20-12-2006 03:13, Ben Greear wrote: This is from 2.6.18.2 kernel with my patch set. The MAC-VLANs are in active use. From the backtrace, I am thinking this might be a generic problem, however. Any ideas about what this could be? It seems to be reproducible every day or ... If it doesn't help, I hope lockdep will be more precise when you'll upgrade to 2.6.19 or higher. ... or when you enable lockdep in 2.6.18 (I've forgotten it's there alredy!). I got lucky..the system was available by ssh still. I see this in the boot logs..I assume this means lockdep is enabled? Should I have expected to see a lockdep trace in the case of his soft-lockup then? . Dec 19 04:33:48 localhost kernel: Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo MolnarDec 19 04:33:48 localhost kernel: ... MAX_LOCKDEP_SUBCLASSES:8 Dec 19 04:33:48 localhost kernel: ... MAX_LOCK_DEPTH: 30 Dec 19 04:33:48 localhost kernel: ... MAX_LOCKDEP_KEYS:2048 Dec 19 04:33:48 localhost kernel: ... CLASSHASH_SIZE: 1024 Dec 19 04:33:48 localhost kernel: ... MAX_LOCKDEP_ENTRIES: 8192 Dec 19 04:33:48 localhost kernel: ... MAX_LOCKDEP_CHAINS: 8192 Dec 19 04:33:48 localhost kernel: ... CHAINHASH_SIZE: 4096 Dec 19 04:33:48 localhost kernel: memory used by lock dependency info: 696 kB Dec 19 04:33:48 localhost kernel: per task-struct memory footprint: 1200 bytes Dec 19 04:33:48 localhost kernel: Dec 19 04:33:48 localhost kernel: | Locking API testsuite: Jarek P. -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] igmp: spin_lock_bh in timer (Re: BUG: soft lockup detected on CPU#0!)
Jarek Poplawski wrote: On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote: On 20-12-2006 03:13, Ben Greear wrote: This is from 2.6.18.2 kernel with my patch set. The MAC-VLANs are in active use. From the backtrace, I am thinking this might be a generic problem, however. Any ideas about what this could be? It seems to be reproducible every day or ... If it doesn't help, I hope lockdep will be more precise when you'll upgrade to 2.6.19 or higher. ... or when you enable lockdep in 2.6.18 (I've forgotten it's there alredy!). I thought I had it enabled, but perhaps I do not. I'll double check that as soon as I'm back in the office after Christmas vacation. Thanks for looking at this! Ben Jarek P. -- Ben Greear <[EMAIL PROTECTED]> Candela Technologies Inc http://www.candelatech.com - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
The new SSB subsystem for bcm43xx (and others)
This is a development snapshot of the new Sonics Silicon Backplane subsystem I am currently designing. A port of the bcm43xx driver is included and it works (more or less). There are still some things left and broken (most are marked with TODO or FIXME). This is just a snapshot for you to look at what it will look like when it's done. The major API is done. There will be some minor changes to it, but that's it. Well, what is this, actually? This subsystem has the goal to make it possible to drive the mainline kernel with bcm43xx on an embedded system based on the sonics backplane natively and out of the box. The Linksys WRT router is a good example for one of these devices. There is also a port of b44 available, so it can run on this, but it's not included here. In general it works like this: [Host PCI bus] \ [Sonics Backplane] \ \ \ bcm43xx b44 other devices... The Host PCI bus does not need to be there. In fact, it is not there for the embedded devices. So the Sonics Backplane is the main system bus. The ssb subsystem completely abstracts all these details, so that we can run the same bcm43xx (and b44) driver on a normal PCI machine and such an embedded device natively. In previous implementations the normal bcm43xx PCI driver was run on these devices, by emulating a PCI bus on top of the real SSB Bus. The Quilt series for all this can be downloaded here: http://bu3sch.de/misc/new-ssb-20061222.tar.bz2 This series applies against my wireless development git tree. -- Greetings Michael. - 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] igmp: spin_lock_bh in timer (Re: BUG: soft lockup detected on CPU#0!)
On Fri, Dec 22, 2006 at 10:16:30PM +1100, Herbert Xu wrote: > Jarek Poplawski <[EMAIL PROTECTED]> wrote: > > > > [PATCH] igmp: spin_lock_bh in timer > > > > igmp_timer_expire() uses spin_lock(&im->lock) > > but this lock is also taken by other igmp timers, > > so it should be changed to bh version. > > When you're in a timer BH is already disabled. So this patch > is redundant. Yes, I recognized this "after the damage was done". Thanks and regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC][PATCH -mm 5/5] add "add" element in /sys/class/misc/netconsole
From: Keiichi KII <[EMAIL PROTECTED]>
This patch contains the following changes.
To add port dynamically, create "add" element in /sys/class/misc/netconsole.
ex)
echo "@/eth0,@192.168.0.1/" > /sys/class/misc/netconsole/add
then the port is added with the settings sending kernel messages
to 192.168.0.1 using eth0 device.
-+- /sys/class/misc/
|-+- netconsole/
|--- add [-w---] If you write parameter(network interface name
| or one config parameter of netconsole), The
|port related its config is added
|--- port1/
|--- port2/
...
Signed-off-by: Keiichi KII <[EMAIL PROTECTED]>
---
[changes]
1. remove unneccesary cast.
2. change config parameter for "add" element.
--- linux-mm/drivers/net/netconsole.c 2006-12-22 20:54:54.531679750 +0900
+++ enhanced-netconsole/drivers/net/netconsole.c.add2006-12-22
16:13:02.062716500 +0900
@@ -338,6 +338,30 @@ static struct miscdevice netconsole_misc
.name = "netconsole",
};
+static ssize_t store_miscdev_add(struct class_device *cdev,
+ const char *buf, size_t count)
+{
+ char *target_param;
+
+ target_param = kmalloc(count+1, GFP_KERNEL);
+ if (!target_param) {
+ printk(KERN_ERR "netconsole: kmalloc() failed!\n");
+ return -ENOMEM;
+ }
+
+ strcpy(target_param, buf);
+ if (target_param[count - 1] == '\n')
+ target_param[count - 1] = '\0';
+
+ printk(KERN_INFO "netconsole: config = [%s]\n", target_param);
+ add_target(target_param);
+ kfree(target_param);
+
+ return count;
+}
+
+static CLASS_DEVICE_ATTR(add, S_IWUSR, NULL, store_miscdev_add);
+
static struct netpoll np = {
.name = "netconsole",
.dev_name = "eth0",
@@ -467,6 +491,9 @@ static int __init init_netconsole(void)
register_console(&netconsole);
+ class_device_create_file(netconsole_miscdev.class,
+&class_device_attr_add);
+
if(!strlen(config)) {
printk(KERN_ERR "netconsole: not configured\n");
return 0;
--
Keiichi KII
NEC Corporation OSS Promotion Center
E-mail: [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
[RFC][PATCH -mm 4/5] switch function of netpoll
From: Keiichi KII <[EMAIL PROTECTED]>
This patch contains switch function of netpoll.
If "enabled" attribute of certain port is '1', this port is used
and the configurations of this port are uable to change.
If "enabled" attribute of certain port is '0', this port isn't used
and the configurations of this port are able to change.
-+- /sys/class/misc/
|-+- netconsole/
|-+- port1/
| |--- id [r--r--r--] id
| |--- enabled [rw-r--r--] 0: disable 1: enable, writable
| ...
|--- port2/
...
Signed-off-by: Keiichi KII <[EMAIL PROTECTED]>
---
[changes]
1. change active/inactive netpoll from list management to flag management.
2. change the name of switch from "enable" to "enabled".
3. return proper error value.
--- linux-mm/drivers/net/netconsole.c 2006-12-22 20:54:54.495677500 +0900
+++ enhanced-netconsole/drivers/net/netconsole.c.switch 2006-12-22
16:12:54.746259250 +0900
@@ -60,6 +60,7 @@ struct netconsole_target {
struct list_head list;
struct kobject obj;
int id;
+ int enabled;
struct netpoll np;
};
@@ -131,10 +132,19 @@ static ssize_t show_remote_mac(struct ne
nt->np.remote_mac[4], nt->np.remote_mac[5]);
}
+static ssize_t show_enabled(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%d\n", nt->enabled);
+}
+
static ssize_t store_local_port(struct netconsole_target *nt, const char *buf,
size_t count)
{
spin_lock(&target_list_lock);
+ if (nt->enabled) {
+ spin_unlock(&target_list_lock);
+ return -EINVAL;
+ }
nt->np.local_port = simple_strtol(buf, NULL, 10);
spin_unlock(&target_list_lock);
@@ -145,6 +155,10 @@ static ssize_t store_remote_port(struct
size_t count)
{
spin_lock(&target_list_lock);
+ if (nt->enabled) {
+ spin_unlock(&target_list_lock);
+ return -EINVAL;
+ }
nt->np.remote_port = simple_strtol(buf, NULL, 10);
spin_unlock(&target_list_lock);
@@ -155,6 +169,10 @@ static ssize_t store_local_ip(struct net
size_t count)
{
spin_lock(&target_list_lock);
+ if (nt->enabled) {
+ spin_unlock(&target_list_lock);
+ return -EINVAL;
+ }
nt->np.local_ip = ntohl(in_aton(buf));
spin_unlock(&target_list_lock);
@@ -165,6 +183,10 @@ static ssize_t store_remote_ip(struct ne
size_t count)
{
spin_lock(&target_list_lock);
+ if (nt->enabled) {
+ spin_unlock(&target_list_lock);
+ return -EINVAL;
+ }
nt->np.remote_ip = ntohl(in_aton(buf));
spin_unlock(&target_list_lock);
@@ -189,12 +211,39 @@ static ssize_t store_remote_mac(struct n
cur = delim + 1;
}
spin_lock(&target_list_lock);
+ if (nt->enabled) {
+ spin_unlock(&target_list_lock);
+ return -EINVAL;
+ }
memcpy(nt->np.remote_mac, input_mac, MAC_ADDR_DIGIT);
spin_unlock(&target_list_lock);
return count;
}
+static ssize_t store_enabled(struct netconsole_target *nt, const char *buf,
+ size_t count)
+{
+ int enabled = 0;
+
+ if (count >= 2 && (count != 2 || buf[count - 1] != '\n')) {
+ printk(KERN_ERR "netconsole: invalid argument: %s\n", buf);
+ return -EINVAL;
+ } else if (strncmp(buf, "1", 1) == 0) {
+ enabled = 1;
+ } else if(strncmp(buf, "0", 1) == 0) {
+ enabled = 0;
+ } else {
+ printk(KERN_ERR "netconsole: invalid argument: %s\n", buf);
+ return -EINVAL;
+ }
+ spin_lock(&target_list_lock);
+ nt->enabled = enabled;
+ spin_unlock(&target_list_lock);
+
+ return count;
+}
+
static ssize_t store_remove(struct netconsole_target *nt, const char *buf,
size_t count)
{
@@ -219,6 +268,8 @@ static NETCON_CLASS_ATTR(remote_ip, S_IR
static NETCON_CLASS_ATTR(local_mac, S_IRUGO, show_local_mac, NULL);
static NETCON_CLASS_ATTR(remote_mac, S_IRUGO | S_IWUSR,
show_remote_mac, store_remote_mac);
+static NETCON_CLASS_ATTR(enabled, S_IRUGO | S_IWUSR,
+show_enabled, store_enabled);
static NETCON_CLASS_ATTR(remove, S_IWUSR, NULL, store_remove);
static struct attribute *target_attrs[] = {
@@ -230,6 +281,7 @@ static struct attribute *target_attrs[]
&target_attr_remote_ip.attr,
&target_attr_local_mac.attr,
&target_attr_remote_mac.attr,
+ &target_attr_enabled.attr,
&target_attr_remove.attr,
NULL
};
@@ -245,7 +297,7 @@ static ssize_t show_target_attr(struct k
if (na->show)
return na->show(nt, buffer);
else
- return -EACCES;
+ return -EI
[RFC][PATCH -mm 3/5] add interface for netconsole using sysfs
From: Keiichi KII <[EMAIL PROTECTED]>
This patch contains the following changes.
create a sysfs entry for netconsole in /sys/class/misc.
This entry has elements related to netconsole as follows.
You can change configuration of netconsole(writable attributes such as IP
address, port number and so on) and check current configuration of netconsole.
-+- /sys/class/misc/
|-+- netconsole/
|-+- port1/
| |--- id [r--r--r--] unique port id
| |--- remove [-w---] if you write something to "remove",
| | this port is removed.
| |--- dev_name[r--r--r--] network interface name
| |--- local_ip[rw-r--r--] source IP to use, writable
| |--- local_port [rw-r--r--] source port number for UDP packets, writable
| |--- local_mac [r--r--r--] source MAC address
| |--- remote_ip [rw-r--r--] port number for logging agent, writable
| |--- remote_port [rw-r--r--] IP address for logging agent, writable
| remote_mac [rw-r--r--] MAC address for logging agent, writable
|--- port2/
|--- port3/
...
Signed-off-by: Keiichi KII <[EMAIL PROTECTED]>
---
[changes]
1. expand macro code as far as possible.
2. follow kernel coding style.
3. print proper output messeage.
4. attach proper label for printk.
5. integrate netpoll_lock and netcon_target_list_lock into common spinlock.
6. return proper error value.
--- linux-mm/drivers/net/netconsole.c 2006-12-22 20:54:54.431673500 +0900
+++ enhanced-netconsole/drivers/net/netconsole.c.sysfs 2006-12-22
16:12:47.925833000 +0900
@@ -45,6 +45,8 @@
#include
#include
#include
+#include
+#include
MODULE_AUTHOR("Maintainer: Matt Mackall <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Console driver for network interfaces");
@@ -56,18 +58,234 @@ MODULE_PARM_DESC(netconsole, " netconsol
struct netconsole_target {
struct list_head list;
+ struct kobject obj;
int id;
struct netpoll np;
};
+#define MAX_PRINT_CHUNK 1000
+#define CONFIG_SEPARATOR ":"
+#define MAC_ADDR_DIGIT 6
+
+struct target_attr {
+ struct attribute attr;
+ ssize_t (*show)(struct netconsole_target*, char*);
+ ssize_t (*store)(struct netconsole_target*, const char*,
+size_t count);
+};
+
static int add_target(char* target_config);
+static void setup_target_sysfs(struct netconsole_target *nt);
static void cleanup_netconsole(void);
static void delete_target(struct netconsole_target *nt);
+static int miscdev_configured = 0;
+
static LIST_HEAD(target_list);
static DEFINE_SPINLOCK(target_list_lock);
+static ssize_t show_id(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%d\n", nt->id);
+}
+
+static ssize_t show_dev_name(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%s\n", nt->np.dev_name);
+}
+
+static ssize_t show_local_port(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%d\n", nt->np.local_port);
+}
+
+static ssize_t show_remote_port(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%d\n", nt->np.remote_port);
+}
+
+static ssize_t show_local_ip(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%d.%d.%d.%d\n", HIPQUAD(nt->np.local_ip));
+}
+
+static ssize_t show_remote_ip(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%d.%d.%d.%d\n", HIPQUAD(nt->np.remote_ip));
+}
+
+static ssize_t show_local_mac(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%02x:%02x:%02x:%02x:%02x:%02x\n",
+ nt->np.local_mac[0], nt->np.local_mac[1],
+ nt->np.local_mac[2], nt->np.local_mac[3],
+ nt->np.local_mac[4], nt->np.local_mac[5]);
+}
+
+static ssize_t show_remote_mac(struct netconsole_target *nt, char *buf)
+{
+ return sprintf(buf, "%02x:%02x:%02x:%02x:%02x:%02x\n",
+ nt->np.remote_mac[0], nt->np.remote_mac[1],
+ nt->np.remote_mac[2], nt->np.remote_mac[3],
+ nt->np.remote_mac[4], nt->np.remote_mac[5]);
+}
+
+static ssize_t store_local_port(struct netconsole_target *nt, const char *buf,
+ size_t count)
+{
+ spin_lock(&target_list_lock);
+ nt->np.local_port = simple_strtol(buf, NULL, 10);
+ spin_unlock(&target_list_lock);
+
+ return count;
+}
+
+static ssize_t store_remote_port(struct netconsole_target *nt, const char *buf,
+ size_t count)
+{
+ spin_lock(&target_list_lock);
+ nt->np.remote_port = simple_strtol(buf, NULL, 10);
+ spin_unlock(&target_list_lock);
+
+ return count;
+}
+
+static ssize_t store_local_ip(struct netconsole_target *nt, const char *buf,
+ size_t count)
+{
+ spin_lock(&target_list_lock);
+ nt->np.local_ip = ntohl(in_aton(buf));
+ spin_unlock(&target_list_lock);
+
+ return count;
+}
+
+s
[RFC][PATCH -mm 0/5] proposal for dynamic configurable netconsole
From: Keiichi KII <[EMAIL PROTECTED]> The netconsole is a very useful module for collecting kernel message under certain circumstances(e.g. disk logging fails, serial port is unavailable). But current netconsole is not flexible. For example, if you want to change ip address for logging agent, in the case of built-in netconsole, you can't change config except for changing boot parameter and rebooting your system, or in the case of module netconsole, you need to reload netconsole module. So, I propose the following extended features for netconsole. 1) support for multiple logging agents. 2) add interface to access each parameter of netconsole using sysfs. This patch is for linux-2.6.20-rc1-mm1 and is divided to each function. Your comments are very welcome. Signed-off-by: Keiichi KII <[EMAIL PROTECTED]> --- [changes] 1. change kernel base from 2.6.19 to 2.6.20-rc1-mm1. -- Keiichi KII NEC Corporation OSS Promotion Center E-mail: [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 2/10] cxgb3 - main source file
> Using request_firmware assumes that the driver knows the FW file name no it knows an ALIAS for it. > and the driver initiates the load. That's not our model where we work > with different FWs, don't know what the names are, you can have the user make a symlink to the one he wants. No Big Deal. > and the user > initiates the load. that sounds broken, but you can have a sysfs parameter for "load now"; cpu microcode has something like that as well.. but are you really sure you don't want to just do the load at "up" time ? -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] igmp: spin_lock_bh in timer (Re: BUG: soft lockup detected on CPU#0!)
Jarek Poplawski <[EMAIL PROTECTED]> wrote:
>
> [PATCH] igmp: spin_lock_bh in timer
>
> igmp_timer_expire() uses spin_lock(&im->lock)
> but this lock is also taken by other igmp timers,
> so it should be changed to bh version.
When you're in a timer BH is already disabled. So this patch
is redundant.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] fix cfg80211 WE compat code
On Fri, 2006-12-22 at 00:30 -0500, Pavel Roskin wrote: > Actually, iwpriv without arguments is still hosed. In this case, > cfg80211_wext_ioctl() returns -EOPNOTSUPP. Ahrg, right, probably caused by me ripping out large chunks of code of of the base function after copying it as the cfg80211 compat code... I'll have to take a look. > I also noticed that cfg80211_wext_ioctl() sometimes returns 0 although > no drivers I'm using are cfg80211 capable. Now that really shouldn't happen. johannes signature.asc Description: This is a digitally signed message part
Re: [PATCH] igmp: spin_lock_bh in timer (Re: BUG: soft lockup detected on CPU#0!)
On Fri, Dec 22, 2006 at 08:13:08AM +0100, Jarek Poplawski wrote: > [PATCH] igmp: spin_lock_bh in timer > > igmp_timer_expire() uses spin_lock(&im->lock) > but this lock is also taken by other igmp timers, > so it should be changed to bh version. ... but according to theory this doesn't matter. I was suggested by this other timers, which probably use _bh unnecessarily. Sorry for confusion - I withdraw this patch. Jarek P. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Netchannels take19] new netchannel release.
On Fri, Dec 22, 2006 at 01:40:33AM +0100, Hans Henrik Happe ([EMAIL PROTECTED]) wrote: > > Code is in development state, but I would like to hear comments about > > overall design, features, usefullness for the kernel and get feedback on > > kernel side. > > I follow your work with great interest, even though my kernel coding > experience isn't great. When I get the time I would like to actually try it > out and provide some feedback. > > For now I only follow your progress by reading your web page to get the big > picture. I must admit it is not easy to get the overall picture from reading > that, because it is mostly about small details. I think you would get a lot > more enthusiasm from people, if you described your work top-down. Much of the > work is about new interfaces and it would be very helpfull with detailed > descriptions of these. > > I think kevent has arrived to a level of documentation, which makes it > possible to get the bigger picture before digging into the code. Although kevent has documentation, it does not help it, as we can see :) > I know documentation is boring, especially for people who actually put their > ideas into code (some people like to rant about their ideas forever, without > actually showing any results). So don't get me wrong; I like your work, but > if you want more people to get excited about it, I think you need to > communicate it better. I will write some documentation about overall design and interfaces (it is a bit easier than kevent, since there is only one syscall with everyone-likes-it multiplexor inside, and one connector based interface for netfilter (NAT)). > Anyway, keep up the good work! Thank you. > Hans Henrik -- 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
