ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm... 2.6.23-rc6-mm1 is a 29MB diff against 2.6.23-rc6. It took me over two solid days to get this lot compiling and booting on a few boxes. This required around ninety fixup patches and patch droppings. There are several bugs in here which I know of (details below) and presumably many more which I don't know of. I have to say that this just isn't working any more. - The Vaio hangs when quitting X due to x86_64-mm-cpa-clflush.patch, but I didn't drop that patch because the iommu patch series depends on it. - The Vaio also hangs during resume-from-RAM, due to git-acpi.patch - And it hangs during suspend-to-RAM, due to git-acpi.patch - Huge churn in networking. Many wireless drivers will be busted, and b44.c has been disabled altogether. If you need b44, then good luck working out what was done to it. - Added Peter's writeback balancing changes. Might help people who are seeing large latency during heavy writeback. - Major changes in the basically-unmaintained IPC code. Needs careful testing and reviewing. - Matthias fixed the mm-to-git importer, so the below-referenced git tree should hopefully be working again. - Pleeeeeze do try to cc the appropriate developer(s) and mailing lists when reporting problems, thanks. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail majordomo@vger.kernel.org - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. In...
This patch does the following things:
- Make hidp_setup_input() return int to indicate errors.
- Check its return value to handle errors.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
---
net/bluetooth/hidp/core.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
===================================================================
--- linux-2.6.23-rc6-mm1.orig/net/bluetooth/hidp/core.c
+++ linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
@@ -625,7 +625,7 @@ static struct device *hidp_get_device(st
return conn ? &conn->dev : NULL;
}
-static inline void hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
+static inline int hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
{
struct input_dev *input = session->input;
int i;
@@ -669,7 +669,7 @@ static inline void hidp_setup_input(stru
input->event = hidp_input_event;
- input_register_device(input);
+ return input_register_device(input);
}
static int hidp_open(struct hid_device *hid)
@@ -823,7 +823,8 @@ int hidp_add_connection(struct hidp_conn
session->idle_to = req->idle_to;
if (session->input)
- hidp_setup_input(session, req);
+ if ((err = (hidp_setup_input(session, req))))
+ goto failed;
if (session->hid)
hidp_setup_hid(session, req);
-This is confusing, why not just do
if (session->input) {
err = hidp_setup_input(session, req);
if (err)
goto failed;
-lets use "if (err < 0)" and I am okay with that patch. Regards Marcel -
This patch does the following things:
- Make hidp_setup_input() return int to indicate errors.
- Check its return value to handle errors.
Thanks to roel for comments.
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
---
net/bluetooth/hidp/core.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
Index: linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
===================================================================
--- linux-2.6.23-rc6-mm1.orig/net/bluetooth/hidp/core.c
+++ linux-2.6.23-rc6-mm1/net/bluetooth/hidp/core.c
@@ -625,7 +625,7 @@ static struct device *hidp_get_device(st
return conn ? &conn->dev : NULL;
}
-static inline void hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
+static inline int hidp_setup_input(struct hidp_session *session, struct hidp_connadd_req *req)
{
struct input_dev *input = session->input;
int i;
@@ -669,7 +669,7 @@ static inline void hidp_setup_input(stru
input->event = hidp_input_event;
- input_register_device(input);
+ return input_register_device(input);
}
static int hidp_open(struct hid_device *hid)
@@ -822,8 +822,11 @@ int hidp_add_connection(struct hidp_conn
session->flags = req->flags & (1 << HIDP_BLUETOOTH_VENDOR_ID);
session->idle_to = req->idle_to;
- if (session->input)
- hidp_setup_input(session, req);
+ if (session->input) {
+ err = hidp_setup_input(session, req);
+ if (err)
+ goto failed;
+ }
if (session->hid)
hidp_setup_hid(session, req);
-Yes, you are right. Thanks. I will resend this patch. ;) -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." -
This bug appears in 2.6.23-rc3-mm1, too. The message: [ 3267.844826] NMI Watchdog detected LOCKUP on CPU 0 [ 3267.849515] CPU 0 [ 3267.851525] Modules linked in: binfmt_misc ipt_MASQUERADE iptable_mangle iptable_nat nf_conntrack_ipv4 iptable_filter ip_tables x_tables nf_nat_tftp nf_nat_ftp nf_nat nf_conntrack_tftp nf_conntrack_ftp nf_conntrack nfnetlink fan ac battery ipv6 eeprom lm85 hwmon_vid i2c_core tun fuse kvm snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd sg soundcore snd_page_alloc thermal sr_mod pcspkr evdev button processor cdrom [ 3267.889547] Pid: 13507, comm: gcc Not tainted 2.6.23-rc6-mm1 #4 [ 3267.895442] RIP: 0033:[<00002ab84e34cd44>] [<00002ab84e34cd44>] [ 3267.901438] RSP: 002b:00007fff5c9e03f8 EFLAGS: 00000287 [ 3267.906726] RAX: 0000000000000000 RBX: 00007fff5c9e0580 RCX: 0000000000000000 [ 3267.913833] RDX: 0000000000000013 RSI: 00007fff5c9e0680 RDI: 00000000012a7010 [ 3267.920939] RBP: 00007fff5c9e0550 R08: 0000000000000050 R09: 0000000000000000 [ 3267.928045] R10: 0000000000000000 R11: 00000000012a7410 R12: 0000000000000002 [ 3267.935151] R13: 0000000000000003 R14: 0000000000000005 R15: 000000000000001f [ 3267.942258] FS: 00002ab84f144170(0000) GS:ffffffff814f3000(0000) knlGS:0000000000000000 [ 3267.950317] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3267.956038] CR2: 00002ab84e3a7430 CR3: 000000000d618000 CR4: 00000000000006e0 [ 3267.963144] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3267.970250] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 3267.977357] Process gcc (pid: 13507, threadinfo ffff81000ebe6000, task ffff810008b849d0) [ 3267.985416] [ 3267.997480] Unable to handle kernel paging request at 00000000fffffffe RIP: [ 3268.002082] [<00000000fffffffe>] [ 3268.007827] PGD ea85067 PUD 0 [ 3268.010887] Oops: 0010 [1] SMP [ 3268.014035] last sysfs file: /devices/pci0000:00/0000:00:1e.0/0000:05:04.0/resource [ 3268.021662] CPU 0 [ 3268.023674] Modules linked i...
Looks like it oopsed in the middle of handling an NMI watchdog expiry, That's interensting. serial_in(). We have had NMI watchdog expiries when the kernel is printing a large amount of stuff out a slow serial port with interrutps disabled. But I thought we'd pretty much plugged those problems by sprinkling touch_nmi_watchdog() in various places. Do you think this is what was happening on your system? -
Very likely. I'm running linux with cmdline "root=/dev/sda1 ro nmi_watchdog=1 console=ttyS0,115200 console=tty0", and doing a lot of printks at the time ;-) Thank you, Fengguang -
OK. We need to find a suitable place to poke yet another touch_nmi_watchdog(). Maybe we should give up and put one in printk(). And you oopsed for different reasons in the nmi-watchdog handling code too. I think I'll pretend I didn't see that. -
Let's forget it for now. I can try Ingo's latency tracing patches at some convenient time. -
drivers/net/iseries_veth.c: In function 'veth_transmit_to_many':
drivers/net/iseries_veth.c:1174: warning: unused variable 'port'
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/iseries_veth.c | 1 -
1 file changed, 1 deletion(-)
diff -ruNp a/drivers/net/iseries_veth.c b/drivers/net/iseries_veth.c
--- a/drivers/net/iseries_veth.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/iseries_veth.c 2007-09-22 11:17:29.000000000 +0530
@@ -1171,7 +1171,6 @@ static void veth_transmit_to_many(struct
HvLpIndexMap lpmask,
struct net_device *dev)
{
- struct veth_port *port = (struct veth_port *) dev->priv;
int i, success, error;
success = error = 0;
-Of ethtool_ops->get_stats_count and ethtool_ops->get_ethtool_stats. Signed-off-by: Satyam Sharma <satyam@infradead.org> --- drivers/net/mv643xx_eth.c | 2 -- 1 file changed, 2 deletions(-) diff -ruNp a/drivers/net/mv643xx_eth.c b/drivers/net/mv643xx_eth.c --- a/drivers/net/mv643xx_eth.c 2007-09-22 06:26:39.000000000 +0530 +++ b/drivers/net/mv643xx_eth.c 2007-09-22 13:15:41.000000000 +0530 @@ -2740,8 +2740,6 @@ static const struct ethtool_ops mv643xx_ .get_stats_count = mv643xx_get_stats_count, .get_ethtool_stats = mv643xx_get_ethtool_stats, .get_strings = mv643xx_get_strings, - .get_stats_count = mv643xx_get_stats_count, - .get_ethtool_stats = mv643xx_get_ethtool_stats, .nway_reset = mv643xx_eth_nway_restart, }; -
The netfilter sysctls in the bridging code don't set strategy routines:
sysctl table check failed: /net/bridge/bridge-nf-call-arptables .3.10.1 Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-call-iptables .3.10.2 Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-call-ip6tables .3.10.3 Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-filter-vlan-tagged .3.10.4 Missing strategy
sysctl table check failed: /net/bridge/bridge-nf-filter-pppoe-tagged .3.10.5 Missing strategy
These binary sysctls can't work. The binary sysctl numbers of
other netfilter sysctls with this problem are being removed. These
need to go as well.
Signed-off-by: Joseph Fannin <jfannin@gmail.com>
---
This *really* needs to be reviewed by someone who knows what this
is all about. I've simply extended the removal of netfilter binary
sysctl numbers so I could load bridge.ko. I don't particularly
care if I get attributed for this fix or any of that.
It Works For Me.
diff -ru linux-2.6.23-rc6-mm1.orig/net/bridge/br_netfilter.c linux-2.6.23-rc6-mm1/net/bridge/br_netfilter.c
--- linux-2.6.23-rc6-mm1.orig/net/bridge/br_netfilter.c 2007-09-19 02:40:49.000000000 -0400
+++ linux-2.6.23-rc6-mm1/net/bridge/br_netfilter.c 2007-09-20 20:31:41.000000000 -0400
@@ -904,7 +904,6 @@
static ctl_table brnf_table[] = {
{
- .ctl_name = NET_BRIDGE_NF_CALL_ARPTABLES,
.procname = "bridge-nf-call-arptables",
.data = &brnf_call_arptables,
.maxlen = sizeof(int),
@@ -912,7 +911,6 @@
.proc_handler = &brnf_sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_CALL_IPTABLES,
.procname = "bridge-nf-call-iptables",
.data = &brnf_call_iptables,
.maxlen = sizeof(int),
@@ -920,7 +918,6 @@
.proc_handler = &brnf_sysctl_call_tables,
},
{
- .ctl_name = NET_BRIDGE_NF_CALL_IP6TABLES,
.procname = "bridge-nf-call-ip6tables",
.data = &brnf_call_ip6tables,
.maxlen = sizeof(int),
@@ -...Hmm. This is an interesting case. The proc method is forcing the integer to be either 0 or 1 in a racy fashion. But none of the users appear to depend upon that. So this is the least broken set of binary sysctls I have seen caught by my check. A really good fix would be to remove the binary side and then to modify brnf_sysctl_call_tables to allocate a temporary ctl_table and integer on the stack and only set ctl->data after we have normalized the written value. But since in practice nothing cares about the race a better fix probably isn't worth it. Eric -
I seem to be missing something, the entire brnf_sysctl_call_tables thing looks purely cosmetic to me, wouldn't it be better to simply remove it? -
Well it is cosmetic in a user space visible way. Which means I don't
have a clue which if any user space programs or scripts care if we change
the behavior.
I just looked in the git history and brnf_sysctl_call_tables has been
that way since sysctl support was added to the bridge netfilter code.
The only comment I can found about the addition is:
2003/12/24 19:32:34-08:00 bdschuym
[BRIDGE]: Add 4 sysctl entries for bridge netfilter behavioral control:
bridge-nf-call-arptables - pass or don't pass bridged ARP traffic to
arptables' FORWARD chain.
bridge-nf-call-iptables - pass or don't pass bridged IPv4 traffic to
iptables' chains.
bridge-nf-filter-vlan-tagged - pass or don't pass bridged vlan-tagged
ARP/IP traffic to arptables/iptables.
So since forcing the values to 0 or 1 doesn't seem hard to maintain
I am uncomfortable with removing that check.
Eric
-OK lets keep it then. Fixing the race seems overkill to me though. -
Me to. Eric -
On Mon, 24 Sep 2007 18:55:38 +0200 I agree, removing seems like a better option. But probably need to go through a 3-6mo warning period, since sysctl's are technically an API. -- Stephen Hemminger <shemminger@linux-foundation.org> -
I meant removing brnf_sysctl_call_tables function, not the sysctls themselves, all it does is change values != 0 to 1. Or did you actually mean that something in userspace might depend on reading back the value 1 after writing a value != 0? -
On Tue, 25 Sep 2007 06:07:24 +0200 I was going farther, because don't really see the value of having a sysctl for this. It seems better to just not load filters if they aren't going to be used. Having another enable/disable hook just adds needless complexity. -
These sysctls control whether bridged packets will be handled by iptables and friends. The bridge netfilter code always handles bridged packets, and iptables might be loaded for different reasons. So I don't see how that would work. I think it should be specified in the ebtables ruleset, but the current netfilter infrastructure doesn't allow to do that cleanly. -
allmodconfig on ppc64 fails to build with the following error
drivers/block/ps3disk.c: In function `ps3disk_probe':
drivers/block/ps3disk.c:509: error: implicit declaration of function `blk_queue_issue_flush_fn'
make[2]: *** [drivers/block/ps3disk.o] Error 1
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2
The problem seems to be coming from git-block.patch. Jens, glancing through
the patch, the function blk_queue_issue_flush_fn() seems to be have been
made redundant. Based on that, this looks like the correct fix but it needs
a review. Thanks
Signed-off-by: Mel Gorman <mel@csn.ul.ie>
---
drivers/block/ps3disk.c | 21 ---------------------
1 file changed, 21 deletions(-)
diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/block/ps3disk.c linux-2.6.23-rc6-mm1-035_fix_ppc64_ps3disk/drivers/block/ps3disk.c
--- linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/block/ps3disk.c 2007-09-11 03:50:29.000000000 +0100
+++ linux-2.6.23-rc6-mm1-035_fix_ppc64_ps3disk/drivers/block/ps3disk.c 2007-09-20 14:17:43.000000000 +0100
@@ -414,26 +414,6 @@ static void ps3disk_prepare_flush(struct
req->cmd_type = REQ_TYPE_FLUSH;
}
-static int ps3disk_issue_flush(struct request_queue *q, struct gendisk *gendisk,
- sector_t *sector)
-{
- struct ps3_storage_device *dev = q->queuedata;
- struct request *req;
- int res;
-
- dev_dbg(&dev->sbd.core, "%s:%u\n", __func__, __LINE__);
-
- req = blk_get_request(q, WRITE, __GFP_WAIT);
- ps3disk_prepare_flush(q, req);
- res = blk_execute_rq(q, gendisk, req, 0);
- if (res)
- dev_err(&dev->sbd.core, "%s:%u: flush request failed %d\n",
- __func__, __LINE__, res);
- blk_put_request(req);
- return res;
-}
-
-
static unsigned long ps3disk_mask;
static DEFINE_MUTEX(ps3disk_mask_mutex);
@@ -506,7 +486,6 @@ static int __devinit ps3disk_probe(struc
blk_queue_dma_alignment(queue, dev->blk_size-1);
blk_queue_hardsect_size(queue, dev->blk_size...BTW ppc64_defconfig didn't quite like 2.6.23-rc6-mm1 either ... IIRC I got build failures in: drivers/ata/pata_scc.c drivers/md/raid6int8.c drivers/net/spider_net.c drivers/net/pasemi_mac.c drivers/pci/hotplug/rpadlpar_sysfs.c I was in a hurry so didn't record the errors, just noted down the files and disabled them from .config and continued building ... I'll get back to fixing these up tonight (if you don't do that by then already). Satyam -
[PATCH -mm] pasemi_mac: Build fix after recent netdev stats changes
Unbreak the following:
drivers/net/pasemi_mac.c: In function 'pasemi_mac_clean_rx':
drivers/net/pasemi_mac.c:533: error: 'dev' undeclared (first use in this function)
drivers/net/pasemi_mac.c:533: error: (Each undeclared identifier is reported only once
drivers/net/pasemi_mac.c:533: error: for each function it appears in.)
And remove an unused static function:
drivers/net/pasemi_mac.c: At top level:
drivers/net/pasemi_mac.c:89: warning: 'read_iob_reg' defined but not used
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/pasemi_mac.c | 9 ++-------
1 file changed, 2 insertions(+), 7 deletions(-)
diff -ruNp a/drivers/net/pasemi_mac.c b/drivers/net/pasemi_mac.c
--- a/drivers/net/pasemi_mac.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/pasemi_mac.c 2007-09-22 13:03:04.000000000 +0530
@@ -85,11 +85,6 @@ MODULE_PARM_DESC(debug, "PA Semi MAC bit
static struct pasdma_status *dma_status;
-static unsigned int read_iob_reg(struct pasemi_mac *mac, unsigned int reg)
-{
- return in_le32(mac->iob_regs+reg);
-}
-
static void write_iob_reg(struct pasemi_mac *mac, unsigned int reg,
unsigned int val)
{
@@ -530,8 +525,8 @@ static int pasemi_mac_clean_rx(struct pa
} else
skb->ip_summed = CHECKSUM_NONE;
- dev->stats.rx_bytes += len;
- dev->stats.rx_packets++;
+ mac->netdev->stats.rx_bytes += len;
+ mac->netdev->stats.rx_packets++;
skb->protocol = eth_type_trans(skb, mac->netdev);
netif_receive_skb(skb);
-Fixing the above showed up another problem in another file of the
same driver (drivers/net/spider_net_ethtool.c)
[PATCH -mm] spider_net_ethtool: Keep up with recent netdev stats changes
Unbreak the following:
drivers/net/spider_net_ethtool.c: In function 'spider_net_get_ethtool_stats':
drivers/net/spider_net_ethtool.c:160: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:161: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:162: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:163: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:164: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:165: error: structure has no member named 'netdev_stats'
drivers/net/spider_net_ethtool.c:166: error: structure has no member named 'netdev_stats'
make[2]: *** [drivers/net/spider_net_ethtool.o] Error 1
Also do another ARRAY_SIZE() cleanup while at it.
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/spider_net_ethtool.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff -ruNp a/drivers/net/spider_net_ethtool.c b/drivers/net/spider_net_ethtool.c
--- a/drivers/net/spider_net_ethtool.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/spider_net_ethtool.c 2007-09-22 12:43:51.000000000 +0530
@@ -28,8 +28,6 @@
#include "spider_net.h"
-#define SPIDER_NET_NUM_STATS 13
-
static struct {
const char str[ETH_GSTRING_LEN];
} ethtool_stats_keys[] = {
@@ -149,7 +147,7 @@ spider_net_ethtool_get_ringparam(struct
static int spider_net_get_stats_count(struct net_device *netdev)
{
- return SPIDER_NET_NUM_STATS;
+ return ARRAY_SIZE(ethtool_stats_keys);
}
static void spider_net_get_ethtool_stats(struct net_device *netdev,
@@ -157,13 +155,13 @@ static void spider_net_get_ethtool_stats
{
struct spider_net_card *card = netdev->priv;
...[PATCH -mm] spider_net: Misc build fixes after recent netdev stats changes
Unbreak the following:
drivers/net/spider_net.c: In function 'spider_net_release_tx_chain':
drivers/net/spider_net.c:818: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c:818: error: (Each undeclared identifier is reported only once
drivers/net/spider_net.c:818: error: for each function it appears in.)
drivers/net/spider_net.c: In function 'spider_net_xmit':
drivers/net/spider_net.c:922: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c: In function 'spider_net_pass_skb_up':
drivers/net/spider_net.c:1018: error: 'dev' undeclared (first use in this function)
drivers/net/spider_net.c: In function 'spider_net_decode_one_descr':
drivers/net/spider_net.c:1215: error: 'dev' undeclared (first use in this function)
make[2]: *** [drivers/net/spider_net.o] Error 1
Signed-off-by: Satyam Sharma <satyam@infradead.org>
---
drivers/net/spider_net.c | 24 +++++++++++-------------
1 file changed, 11 insertions(+), 13 deletions(-)
diff -ruNp a/drivers/net/spider_net.c b/drivers/net/spider_net.c
--- a/drivers/net/spider_net.c 2007-09-22 06:26:39.000000000 +0530
+++ b/drivers/net/spider_net.c 2007-09-22 12:12:23.000000000 +0530
@@ -795,6 +795,7 @@ spider_net_set_low_watermark(struct spid
static int
spider_net_release_tx_chain(struct spider_net_card *card, int brutal)
{
+ struct net_device *dev = card->netdev;
struct spider_net_descr_chain *chain = &card->tx_chain;
struct spider_net_descr *descr;
struct spider_net_hw_descr *hwdescr;
@@ -919,7 +920,7 @@ spider_net_xmit(struct sk_buff *skb, str
spider_net_release_tx_chain(card, 0);
if (spider_net_prepare_tx_descr(card, skb) != 0) {
- dev->stats.tx_dropped++;
+ netdev->stats.tx_dropped++;
netif_stop_queue(netdev);
return NETDEV_TX_BUSY;
}
@@ -979,16 +980,12 @@ static void
spider_net_pass_skb_up(struct spider_net_descr *descr,
struct spider...I've confirmed that this patch fixes the build error in question. -- -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -
This turned out to be a gcc bug -- I was using an old cross-compiler. -
Thanks! The patch is correct, the prepare_flush() hook is now all that is needed. I will apply this to my barrier branch, where this originates from. -- Jens Axboe -
PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It doesn't show up on other arches because this driver is specific to the architecture. drivers/ata/pata_scc.c: In function `scc_bmdma_status': drivers/ata/pata_scc.c:734: error: structure has no member named `active_tag' drivers/ata/pata_scc.c: In function `scc_pata_prereset': drivers/ata/pata_scc.c:866: warning: passing arg 1 of `ata_std_prereset' from incompatible pointer type drivers/ata/pata_scc.c: In function `scc_error_handler': drivers/ata/pata_scc.c:908: warning: passing arg 2 of `ata_bmdma_drive_eh' from incompatible pointer type drivers/ata/pata_scc.c:908: warning: passing arg 3 of `ata_bmdma_drive_eh' from incompatible pointer type drivers/ata/pata_scc.c:908: warning: passing arg 5 of `ata_bmdma_drive_eh' from incompatible pointer type make[2]: *** [drivers/ata/pata_scc.o] Error 1 make[1]: *** [drivers/ata] Error 2 make: *** [drivers] Error 2 The problem seems to be in git-libata-all.patch but based on similar changes in this patch, the following patch should be the fix. Signed-off-by: Mel Gorman <mel@csn.ul.ie> --- drivers/ata/pata_scc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.23-rc6-mm1-025_fix_ppc64_kgdb/drivers/ata/pata_scc.c linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/ata/pata_scc.c --- linux-2.6.23-rc6-mm1-025_fix_ppc64_kgdb/drivers/ata/pata_scc.c 2007-09-18 11:29:26.000000000 +0100 +++ linux-2.6.23-rc6-mm1-030_fix_ppc64_sata/drivers/ata/pata_scc.c 2007-09-20 11:51:01.000000000 +0100 @@ -731,7 +731,7 @@ static u8 scc_bmdma_status (struct ata_p void __iomem *mmio = ap->ioaddr.bmdma_addr; u8 host_stat = in_be32(mmio + SCC_DMA_STATUS); u32 int_status = in_be32(mmio + SCC_DMA_INTST); - struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag); + struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->link.active_tag); static int retry = 0; /* return if IOS_SS is cleared */ -- Mel...
On Thu, 20 Sep 2007 14:13:15 +0100
Its not been updated to match the libata core changes. Try something like
this. Whoever is maintaining it should also remove the prereset cable handling
code and use the proper cable detect method.
Signed-off-by: Alan Cox <alan@redhat.com>
diff -u --exclude-from /usr/src/exclude --new-file --recursive linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_scc.c linux-2.6.23rc6-mm1/drivers/ata/pata_scc.c
--- linux.vanilla-2.6.23rc6-mm1/drivers/ata/pata_scc.c 2007-09-18 15:32:51.000000000 +0100
+++ linux-2.6.23rc6-mm1/drivers/ata/pata_scc.c 2007-09-20 14:23:32.879807760 +0100
@@ -731,7 +731,7 @@
void __iomem *mmio = ap->ioaddr.bmdma_addr;
u8 host_stat = in_be32(mmio + SCC_DMA_STATUS);
u32 int_status = in_be32(mmio + SCC_DMA_INTST);
- struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->active_tag);
+ struct ata_queued_cmd *qc = ata_qc_from_tag(ap, ap->link.active_tag);
static int retry = 0;
/* return if IOS_SS is cleared */
@@ -860,10 +860,10 @@
* @deadline: deadline jiffies for the operation
*/
-static int scc_pata_prereset(struct ata_port *ap, unsigned long deadline)
+static int scc_pata_prereset(struct ata_link *link, unsigned long deadline)
{
- ap->cbl = ATA_CBL_PATA80;
- return ata_std_prereset(ap, deadline);
+ link->ap->cbl = ATA_CBL_PATA80;
+ return ata_std_prereset(link, deadline);
}
/**
@@ -874,8 +874,9 @@
* Note: Original code is ata_std_postreset().
*/
-static void scc_std_postreset (struct ata_port *ap, unsigned int *classes)
+static void scc_std_postreset (struct ata_link *link, unsigned int *classes)
{
+ struct ata_port *ap = link->ap;
DPRINTK("ENTER\n");
/* is double-select really necessary? */
-Hi,
It appears you forgot to fix scc_std_softreset() and one of its callsites
in scc_bdma_stop(). A complete patch is attempted below -- please review.
[PATCH -mm] pata_scc: Keep up with libata core API changes
Little fixlets, that the build started erroring / warning about:
drivers/ata/pata_scc.c: In function 'scc_bmdma_status':
drivers/ata/pata_scc.c:734: error: structure has no member named 'active_tag'
drivers/ata/pata_scc.c: In function 'scc_pata_prereset':
drivers/ata/pata_scc.c:866: warning: passing arg 1 of 'ata_std_prereset' from incompatible pointer type
drivers/ata/pata_scc.c: In function 'scc_error_handler':
drivers/ata/pata_scc.c:908: warning: passing arg 2 of 'ata_bmdma_drive_eh' from incompatible pointer type
drivers/ata/pata_scc.c:908: warning: passing arg 3 of 'ata_bmdma_drive_eh' from incompatible pointer type
drivers/ata/pata_scc.c:908: warning: passing arg 5 of 'ata_bmdma_drive_eh' from incompatible pointer type
make[2]: *** [drivers/ata/pata_scc.o] Error 1
Signed-off-by: Satyam Sharma <satyam@infradead.org>
Cc: Alan Cox <alan@redhat.com>
Cc: Mel Gorman <mel@skynet.ie>
---
Andrew, this includes (supercedes) the previous two ones from Mel / Alan.
drivers/ata/pata_scc.c | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
diff -ruNp a/drivers/ata/pata_scc.c b/drivers/ata/pata_scc.c
--- a/drivers/ata/pata_scc.c 2007-09-22 06:26:37.000000000 +0530
+++ b/drivers/ata/pata_scc.c 2007-09-22 08:04:42.000000000 +0530
@@ -594,16 +594,17 @@ static unsigned int scc_bus_softreset(st
* Note: Original code is ata_std_softreset().
*/
-static int scc_std_softreset (struct ata_port *ap, unsigned int *classes,
- unsigned long deadline)
+static int scc_std_softreset(struct ata_link *link, unsigned int *classes,
+ unsigned long deadline)
{
+ struct ata_port *ap = link->ap;
unsigned int slave_possible = ap->flags & ATA_FLAG_SLAVE_POSS;
u...applied -
I can confirm it builds without warnings or errors, so thanks. I'm not in -- -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -
Hi, This patch solves the build failure, but with following warnings CC drivers/ata/pata_scc.o drivers/ata/pata_scc.c: In function ‘scc_error_handler’: drivers/ata/pata_scc.c:909: warning: passing argument 3 of ‘ata_bmdma_drive_eh’ from incompatible pointer type and after that the build fails with CC [M] drivers/net/spider_net.o drivers/net/spider_net.c: In function ‘spider_net_release_tx_chain’: drivers/net/spider_net.c:818: error: ‘dev’ undeclared (first use in this function) drivers/net/spider_net.c:818: error: (Each undeclared identifier is reported only once drivers/net/spider_net.c:818: error: for each function it appears in.) drivers/net/spider_net.c: In function ‘spider_net_xmit’: drivers/net/spider_net.c:922: error: ‘dev’ undeclared (first use in this function) drivers/net/spider_net.c: In function ‘spider_net_pass_skb_up’: drivers/net/spider_net.c:1018: error: ‘dev’ undeclared (first use in this function) drivers/net/spider_net.c: In function ‘spider_net_decode_one_descr’: drivers/net/spider_net.c:1215: error: ‘dev’ undeclared (first use in this function) make[2]: *** [drivers/net/spider_net.o] Error 1 make[1]: *** [drivers/net] Error 2 make: *** [drivers] Error 2 -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. -
I can confirm it builds with the following messages CC [M] drivers/ata/pata_scc.o drivers/ata/pata_scc.c: In function `scc_error_handler': drivers/ata/pata_scc.c:909: warning: passing arg 3 of `ata_bmdma_drive_eh' from incompatible pointer type As for the rest, I cannot comment. -- -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -
Hello !
make-access-to-tasks-nsproxy-lighter.patch breaks unshare()
when called from unshare(), switch_task_namespaces() takes an
extra refcount on the nsproxy, leading to a memory leak of
nsproxy objects.
Now the problem is that we still need that extra ref when called
from daemonize(). Here's an ugly fix for it.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
---
include/linux/nsproxy.h | 5 +++++
kernel/exit.c | 2 ++
kernel/nsproxy.c | 7 -------
3 files changed, 7 insertions(+), 7 deletions(-)
Index: 2.6.23-rc6-mm1/kernel/nsproxy.c
===================================================================
--- 2.6.23-rc6-mm1.orig/kernel/nsproxy.c
+++ 2.6.23-rc6-mm1/kernel/nsproxy.c
@@ -25,11 +25,6 @@ static struct kmem_cache *nsproxy_cachep
struct nsproxy init_nsproxy = INIT_NSPROXY(init_nsproxy);
-static inline void get_nsproxy(struct nsproxy *ns)
-{
- atomic_inc(&ns->count);
-}
-
/*
* creates a copy of "orig" with refcount 1.
*/
@@ -208,8 +203,6 @@ void switch_task_namespaces(struct task_
if (ns == new)
return;
- if (new)
- get_nsproxy(new);
rcu_assign_pointer(p->nsproxy, new);
if (ns && atomic_dec_and_test(&ns->count)) {
Index: 2.6.23-rc6-mm1/kernel/exit.c
===================================================================
--- 2.6.23-rc6-mm1.orig/kernel/exit.c
+++ 2.6.23-rc6-mm1/kernel/exit.c
@@ -408,6 +408,8 @@ void daemonize(const char *name, ...)
current->fs = fs;
atomic_inc(&fs->count);
+ if (current->nsproxy != init_task.nsproxy)
+ get_nsproxy(init_task.nsproxy);
switch_task_namespaces(current, init_task.nsproxy);
exit_files(current);
Index: 2.6.23-rc6-mm1/include/linux/nsproxy.h
===================================================================
--- 2.6.23-rc6-mm1.orig/include/linux/nsproxy.h
+++ 2.6.23-rc6-mm1/include/linux/nsproxy.h
@@ -77,6 +77,11 @@ static inline void put_nsproxy(struct ns
}
}
+static inline void get_...Looks sane :) shouldn't we make the switch under this if() as well? -
right. we can probably simplify switch_task_namespaces() and remove : if (ns == new) return; I'll cook a better one today. Thanks ! C. -
So I removed this test in
* daemonize() bc it is already done
* sys_unshare() bc the nsproxy is always new one
* exit_task_namespaces() bc it is called with NULL and the
task will die right after that.
C.
make-access-to-tasks-nsproxy-lighter.patch breaks unshare()
when called from unshare(), switch_task_namespaces() takes an
extra refcount on the nsproxy, leading to a memory leak of
nsproxy objects.
Now the problem is that we still need that extra ref when called
from daemonize(). Here's an ugly fix for it.
Signed-off-by: Cedric Le Goater <clg@fr.ibm.com>
Cc: Serge E. Hallyn <serue@us.ibm.com>
Cc: Pavel Emelyanov <xemul@openvz.org>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
---
include/linux/nsproxy.h | 5 +++++
kernel/exit.c | 5 ++++-
kernel/nsproxy.c | 9 ---------
3 files changed, 9 insertions(+), 10 deletions(-)
Index: 2.6.23-rc6-mm1/kernel/nsproxy.c
===================================================================
--- 2.6.23-rc6-mm1.orig/kernel/nsproxy.c
+++ 2.6.23-rc6-mm1/kernel/nsproxy.c
@@ -25,11 +25,6 @@ static struct kmem_cache *nsproxy_cachep
struct nsproxy init_nsproxy = INIT_NSPROXY(init_nsproxy);
-static inline void get_nsproxy(struct nsproxy *ns)
-{
- atomic_inc(&ns->count);
-}
-
/*
* creates a copy of "orig" with refcount 1.
*/
@@ -205,11 +200,7 @@ void switch_task_namespaces(struct task_
might_sleep();
ns = p->nsproxy;
- if (ns == new)
- return;
- if (new)
- get_nsproxy(new);
rcu_assign_pointer(p->nsproxy, new);
if (ns && atomic_dec_and_test(&ns->count)) {
Index: 2.6.23-rc6-mm1/kernel/exit.c
===================================================================
--- 2.6.23-rc6-mm1.orig/kernel/exit.c
+++ 2.6.23-rc6-mm1/kernel/exit.c
@@ -408,7 +408,10 @@ void daemonize(const char *name, ...)
current->fs = fs;
...Looks good. Thanks for catching the leak. -
[patch submitter cc'd]
I had to reverse
convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch (and the
fix on top of it) to get past this error on 32bit powerpc:
make[1]: Entering directory `/usr/src/ctesiphon/linux-2.6.23-rc6-mm1'
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CC arch/powerpc/kernel/asm-offsets.s
In file included from include/linux/smp.h:19,
from include/linux/sched.h:67,
from arch/powerpc/kernel/asm-offsets.c:17:
include/asm/smp.h:63: error: expected declaration specifiers orOn Wed, 19 Sep 2007 19:58:28 -0400 This, methinks. --- a/include/asm-powerpc/smp.h~convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64-fix-2 +++ a/include/asm-powerpc/smp.h @@ -25,8 +25,8 @@ #ifdef CONFIG_PPC64 #include <asm/paca.h> -#include <asm/percpu.h> #endif +#include <asm/percpu.h> extern int boot_cpuid; (conditional includes are evil) -
This is a multi-part message in MIME format. --------------090208080409080002090402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I get several "duplicate file name" messages. Hope Greg's the right one to cc on these. <4>[ 21.211942] Duplicate file names "rtc" detected. [dump_trace+100/49= 8] dump_trace+0x64/0x1f2 <4>[ 21.216801] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2= f <4>[ 21.221639] [show_trace+18/20] show_trace+0x12/0x14 <4>[ 21.226307] [dump_stack+22/24] dump_stack+0x16/0x18 <4>[ 21.231063] [proc_register+315/332] proc_register+0x13b/0x14c <4>[ 21.235814] [create_proc_entry+114/135] create_proc_entry+0x72/0x8= 7 <4>[ 21.240562] [<faa1d123>] rtc_proc_add_device+0x1d/0x39 [rtc_core] <4>[ 21.245304] [<faa1c1f9>] rtc_device_register+0x170/0x207 [rtc_core= ] <4>[ 21.250077] [<faa3c5db>] cmos_do_probe+0x8d/0x1ee [rtc_cmos] <4>[ 21.254715] [<faa3c77d>] cmos_pnp_probe+0x41/0x44 [rtc_cmos] <4>[ 21.259477] [pnp_device_probe+102/135] pnp_device_probe+0x66/0x87 <4>[ 21.264206] [driver_probe_device+233/362] driver_probe_device+0xe9= /0x16a <4>[ 21.268738] [__driver_attach+108/165] __driver_attach+0x6c/0xa5 <4>[ 21.273387] [bus_for_each_dev+54/91] bus_for_each_dev+0x36/0x5b <4>[ 21.277975] [driver_attach+25/27] driver_attach+0x19/0x1b <4>[ 21.282501] [bus_add_driver+115/429] bus_add_driver+0x73/0x1ad <4>[ 21.286984] [driver_register+103/108] driver_register+0x67/0x6c <4>[ 21.291269] [pnp_register_driver+23/25] pnp_register_driver+0x17/0= x19 <4>[ 21.295661] [<faa4000d>] cmos_init+0xd/0xf [rtc_cmos] <4>[ 21.300044] [sys_init_module+5544/5953] sys_init_module+0x15a8/0x1= 741 <4>[ 21.304406] [sysenter_past_esp+107/181] sysenter_past_esp+0x6b/0xb= 5 <4>[ 21.308749] [phys_startup_32+3085673488/3221225472] 0...
Another data point. When booting into runlevel 3, the system is usable, although these messages still appear after boot: <4>[ 22.731025] sysfs: duplicate filename 'bInterfaceNumber' can not be= created <4>[ 22.735872] WARNING: at fs/sysfs/dir.c:433 sysfs_add_one() <7>[ 22.740737] bas_gigaset: <-------3: 0x11 (0 [0x00 0x00]) <4>[ 22.740881] [dump_trace+100/498] dump_trace+0x64/0x1f2 <7>[ 22.745708] bas_gigaset: <-------3: 0x11 (0 [0x00 0x00]) <4>[ 22.745721] [show_trace_log_lvl+26/47] show_trace_log_lvl+0x1a/0x2= f <4>[ 22.750533] [show_trace+18/20] show_trace+0x12/0x14 <4>[ 22.755285] [dump_stack+22/24] dump_stack+0x16/0x18 <4>[ 22.759997] [sysfs_add_one+87/188] sysfs_add_one+0x57/0xbc <4>[ 22.764633] [sysfs_add_file+73/135] sysfs_add_file+0x49/0x87 <4>[ 22.769418] [sysfs_create_group+138/240] sysfs_create_group+0x8a/0= xf0 <4>[ 22.774014] [<fa99c20a>] usb_create_sysfs_intf_files+0x2d/0xa2 [us= bcore] <4>[ 22.778659] [<fa9989ed>] usb_set_configuration+0x450/0x48d [usbcor= e] <4>[ 22.783246] [<fa99fa9b>] generic_probe+0x53/0x94 [usbcore] <4>[ 22.787895] [<fa99a00b>] usb_probe_device+0x35/0x3b [usbcore] <4>[ 22.792471] [driver_probe_device+233/362] driver_probe_device+0xe9= /0x16a <4>[ 22.797214] [__device_attach+8/10] __device_attach+0x8/0xa <4>[ 22.801779] [bus_for_each_drv+56/97] bus_for_each_drv+0x38/0x61 <4>[ 22.806344] [device_attach+112/133] device_attach+0x70/0x85 <4>[ 22.810905] [bus_attach_device+41/119] bus_attach_device+0x29/0x77= <4>[ 22.815468] [device_add+795/1342] device_add+0x31b/0x53e <4>[ 22.820052] [<fa993de7>] usb_new_device+0x5c/0x168 [usbcore] <4>[ 22.824653] [<fa9954f9>] hub_thread+0x6b9/0xaa5 [usbcore] <4>[ 22.829276] [kthread+59/100] kthread+0x3b/0x64 <4>[ 22.833823] [kernel_thread_helper+7/16] ...
On Thu, 20 Sep 2007 21:20:24 +0200 There was a locking imbalance in the IPC code. Do you have the fixes in ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc6/2.6.23-rc6-mm... Greg isn't the only USB developer ;) linux-usb-devel cc added.. -
I hadn't. Now that I have, all the troubles are gone. X comes up fine, and all of the segfault/invalid context/scheduling while atomic messages have disappeared. Thanks, Tilman --=20 Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Unge=F6ffnet mindestens haltbar bis: (siehe R=FCckseite)
On Thu, 20 Sep 2007 01:02:06 +0200
Nah, that's an rtc-specific problem.
I think David says that it's actually not a problem, but I didn't
really understand how this can be?
Perhaps I'll need to drop that debugging patch. Which would be a shame,
because it can detect real bugs. Perhaps it needs a strcmp("rtc") to
filter out the (surprising) false positive.
-RTC-related ... but it's a procfs bug, since it's procfs which doesn't even bother to check for duplicate names before it registers files. And it's that duplication which is the problem. Try the patch in this message I said it's not an RTC problem ... it's a procfs problem. That _shouldn't_ be a problem at all; only one of them should be able to bind to that hardware. The only problem I see in these messages is that procfs bug. - Dave -
On Wed, 19 Sep 2007 16:44:48 -0700 So you keep on claiming, but I don't think I've yet seen a description of the *reason* why two copies of this file are being created, and a It's not obvious that this is only a procfs bug. If some part of the kernel tries to add a procfs file which is already there, that's often a bug in the caller. Yes, procfs should have been checking for this. But it is too late now for us to just fail out of the procfs registration code. Because this can cause previously buggy-but-works-ok code to now fail completely. So I think the best we can do now is to retain the runtime warning and to continue to "succeed" and to identify all the problematic codesites and to either fix them or to convince ourselves that they really are working as intended. -
Although maybe you meant me to parse that differently ... as in, not "why is procfs doing this broken thing?" but rather "how is it that procfs fault (non)handling code ended up getting used?". That's always seemed self-evident: the RTC framework was creating it for /dev/rtc0 (presumably, rtc-cmos), while at the same time the legacy drivers/char/rtc.c was creating it for /dev/rtc. Workaround by configuring just one, and the problem goes away. (Although it *ought* to be OK to configure both, with all the normal It's not a wrong thing, at any rate. This is a fairly basic task in any filesystem: mutual exclusion. Code is allowed to rely on Not really; procfs is supposed to not create it if it's already there!! Reasonable callers will cope with "it didn't get created", and that's What do you mean by too late "now" ... just-before-2.6.23? I'm a bit puzzled why this issue cropped up suddenly, when the "two RTC drivers" configs have been behaving fine (presumably failing properly, but at least not generating problem reports) for some time. One of the procfs changes must have caused this trouble. And what would an example be of buggy-but-works code, which would At a micro level, both the relevant call sites already have code to tolerate the "couldn't create that file" error, which looked correct at a quick reading. - Dave -
Head still spinning. a) "rtc0" != "rtc" ?? b) The kernel is trying to register two procfs files of the same name! We're relying on procfs behaviour to prevent registration of two rtc devices? That's a strange means of arbitration. And what happens No. What I mean is that we cannot change procfs as you propose until we have located and fixed all places in the kernel which can cause duplicated procfs names. (Good luck with that). Because we've had this happening before, and *the driver kept working* (apart from, presumably, some of their procfs features which, presumably, nobody used much). With the change which you propose, these drivers will probably stop I'm not sure that anything _has_ changed. It's just that a few people have suddenly noticed duplicated rtc entris in /proc. Perhaps theye were there A driver which checks the return value from procfs registration and which -
One key difference between any of the numerous legacy RTC drivers and the new framework is that the legacy drivers tended to think (wrongly!) they would be the only RTC in the system, while the framework recognizes that other configurations are important. Hence names "rtc0", "rtc1", "rtc2" ... etc in framework drivers, versus just "rtc" in legacy code. Easily tweaked with "udev" if it matters, but current versions of "hwclock" (in util-linux and also in busybox) don't require a /dev/rtc file any more ... they check Not so much an "error" as minor awkwardness. The end result is Not at all. But if two chunks of code try to create /proc/x/y/z, only one of them should succeed. Today, there's a clear bug in Then nothing gets stored there; procfs is nonessential. The same But causing duplicated names doesn't need any "fix" when that code handles the error sanely -- by using its "PROCFS=n" code paths. If you're arguing that you think such fault handling code may have a lot of bugs, I might agree: not all fault handling code gets even basic testing. But that would seem to be nothing more than a reason to want some code auditing (to see how common such bugs really are, and fix at least a few of them), and perhaps to let such bugfixes sit Evidently there's no procfs maintainer ... you've said there are patches in MM to detect and report such duplication. What is it The last time I had occasion to look at such stuff I observed that procfs users were generally sane. If they couldn't create a file, they just Erroring out is appropriate for fatal errors ... but procfs errors generally can't be fatal. (Code which uses procfs for its primary userspace interface would be the exception.) So most code should never error out on such faults. As I commented above, most code I've happend across will proceed just fine if the extra procfs support is unavailable. After all, it needs to work with CONFIG_PROCFS=n so those code paths aren't going to suddenly stop working! - D...
On Wed, 19 Sep 2007 23:11:21 -0700 I guess the best solution would be to have Kconfig avoid that. I'll try to code something as soon as I get back home. -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it -
Isn't that all caused by the rtc driver registering itself without checking if it is able to grab the device? Wouldn't moving the request_resource() before doing any device registration do the magic? Kay -
I suspect it would. Got patch?
I'm trying to remember why it registers before grabbing resources
(I/O region, irq) ... which is not the usual pattern, and is somewhat
of a surprise every time I notice it. Though everything's undone on
error, so it "should" work just fine.
If that's not just some debugging leftover, the only thing that comes
to mind is that maybe it was to ensure that the resource labels in
/proc/{interrupts,ioports} clearly distinguished this from the legacy
driver. The now-conventional way to label things there is by using
a logical name like "rtc0", which is the output of registration.
- Dave
-AFAICT the rtc problem is caused by misconfiguration: both the new and old rtc driver have been built and they are both trying to load. -
Rats. Sorry. I remember now. That's not the first time I am hit by that one. I had even made a resolution to try and find out the correct options to set. So what