Re: [RFC] PCMCIA locking updates for 2.6.34
> > Does the new locking work for you? I'd wonder why...
>
> I wonder too why it worked yesterday -- I updated the patch-set completely,
> it's up at the same location as yesterday
>
> git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git#locking
>
> and survives any test case I can throw at it (which aren't many,
> unfortunately). Could you test this, please?
This branch works better. I plugged and pulled some cards and so far it works
for me. Minor nit, compiling gave me:
CC [M] drivers/pcmcia/ds.o
drivers/pcmcia/ds.c: In function ‘pcmcia_delayed_requery’:
drivers/pcmcia/ds.c:720: warning: ignoring return value of
‘bus_rescan_devices’, declared with attribute warn_unused_result
I'd like to do some more testing, though.
Another thing: You said these locking patches were for 2.6.34. What about
waiting for 2.6.35, so your other patches can stabilize in mainline, and the
locking stuff gets another round of testing? I'd fear hunting possible
regressions ("My card/slots stopped working!") might get troublesome otherwise?
Regards (and thanks for this work!),
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [RFC] PCMCIA locking updates for 2.6.34
Hey, On Sun, Jan 17, 2010 at 03:30:08PM +0900, Komuro wrote: > Same result as Wolfram. On Sun, Jan 17, 2010 at 12:08:20PM +0100, Wolfram Sang wrote: > > If it doesn't help, could you enable lockdep, please, and check with > > I enabled locking debug and got this while inserting the card: ... > Does the new locking work for you? I'd wonder why... I wonder too why it worked yesterday -- I updated the patch-set completely, it's up at the same location as yesterday git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git#locking and survives any test case I can throw at it (which aren't many, unfortunately). Could you test this, please? Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [RFC] PCMCIA locking updates for 2.6.34
> If it doesn't help, could you enable lockdep, please, and check with
I enabled locking debug and got this while inserting the card:
[ 187.347741] ===
[ 187.347745] [ INFO: possible circular locking dependency detected ]
[ 187.347750] 2.6.33-rc4-ninja-00035-g117c14a-dirty #66
[ 187.347753] ---
[ 187.347758] pccardd/1248 is trying to acquire lock:
[ 187.347761] (rsrc_mutex){+.+.+.}, at: []
nonstatic_find_mem_region+0x83/0x210 [rsrc_nonstatic]
[ 187.347776]
[ 187.34] but task is already holding lock:
[ 187.347780] (&socket->ops_mutex){+.+.+.}, at: []
set_cis_map+0x2a/0x140 [pcmcia]
[ 187.347797]
[ 187.347798] which lock already depends on the new lock.
[ 187.347800]
[ 187.347803]
[ 187.347804] the existing dependency chain (in reverse order) is:
[ 187.347808]
[ 187.347810] -> #1 (&socket->ops_mutex){+.+.+.}:
[ 187.347817][<8015fe21>] __lock_acquire+0x11b1/0x1940
[ 187.347827][<80160669>] lock_acquire+0xb9/0xd0
[ 187.347834][<8053c6b6>] mutex_lock_nested+0x46/0x2a0
[ 187.347842][] readable+0x2a/0xe0 [rsrc_nonstatic]
[ 187.347849][] do_validate_mem+0xe9/0x1a0 [rsrc_nonstatic]
[ 187.347856][] do_mem_probe+0x172/0x210 [rsrc_nonstatic]
[ 187.347864][] pcmcia_nonstatic_validate_mem+0xb1/0xf0
[rsrc_nonstatic]
[ 187.347872][] pcmcia_validate_mem+0x1c/0x20 [pcmcia]
[ 187.347881][] pcmcia_card_add+0x22/0x1e0 [pcmcia]
[ 187.347890][] ds_event+0x7e/0x230 [pcmcia]
[ 187.347899][] send_event+0xba/0x160 [pcmcia_core]
[ 187.347909][] socket_insert+0x111/0x1e0 [pcmcia_core]
[ 187.347918][] pccardd+0x205/0x2b0 [pcmcia_core]
[ 187.347927][<8014b374>] kthread+0x74/0x80
[ 187.347934][<801031ba>] kernel_thread_helper+0x6/0x10
[ 187.347942]
[ 187.347944] -> #0 (rsrc_mutex){+.+.+.}:
[ 187.347950][<801605ac>] __lock_acquire+0x193c/0x1940
[ 187.347957][<80160669>] lock_acquire+0xb9/0xd0
[ 187.347963][<8053c6b6>] mutex_lock_nested+0x46/0x2a0
[ 187.347969][] nonstatic_find_mem_region+0x83/0x210
[rsrc_nonstatic]
[ 187.347977][] pcmcia_find_mem_region+0x3a/0x50 [pcmcia]
[ 187.347987][] set_cis_map+0xc0/0x140 [pcmcia]
[ 187.347996][] pcmcia_read_cis_mem+0x10e/0x2c0 [pcmcia]
[ 187.348006][] read_cis_cache+0x131/0x210 [pcmcia]
[ 187.348016][] pccard_get_next_tuple+0x1b3/0x480 [pcmcia]
[ 187.348026][] pccard_get_first_tuple+0x8c/0xe0 [pcmcia]
[ 187.348036][] pccard_validate_cis+0x13b/0x340 [pcmcia]
[ 187.348046][] pcmcia_card_add+0x34/0x1e0 [pcmcia]
[ 187.348055][] ds_event+0x7e/0x230 [pcmcia]
[ 187.348064][] send_event+0xba/0x160 [pcmcia_core]
[ 187.348072][] socket_insert+0x111/0x1e0 [pcmcia_core]
[ 187.348080][] pccardd+0x205/0x2b0 [pcmcia_core]
[ 187.348089][<8014b374>] kthread+0x74/0x80
[ 187.348095][<801031ba>] kernel_thread_helper+0x6/0x10
[ 187.348102]
[ 187.348103] other info that might help us debug this:
[ 187.348105]
[ 187.348109] 2 locks held by pccardd/1248:
[ 187.348112] #0: (&socket->skt_mutex){+.+.+.}, at: []
pccardd+0x102/0x2b0 [pcmcia_core]
[ 187.348125] #1: (&socket->ops_mutex){+.+.+.}, at: []
set_cis_map+0x2a/0x140 [pcmcia]
[ 187.348139]
[ 187.348140] stack backtrace:
[ 187.348145] Pid: 1248, comm: pccardd Not tainted
2.6.33-rc4-ninja-00035-g117c14a-dirty #66
[ 187.348150] Call Trace:
[ 187.348159] [<8053b021>] ? printk+0x1d/0x24
[ 187.348166] [<8015e709>] print_circular_bug+0xd9/0xe0
[ 187.348172] [<801605ac>] __lock_acquire+0x193c/0x1940
[ 187.348180] [<801669ed>] ? is_module_text_address+0xd/0x20
[ 187.348186] [<80149237>] ? __kernel_text_address+0x57/0x80
[ 187.348192] [<80105fc1>] ? print_context_stack+0x61/0x120
[ 187.348200] [<8015dcec>] ? trace_hardirqs_on_caller+0x11c/0x160
[ 187.348208] [<801c6cc2>] ? create_object+0x192/0x250
[ 187.348215] [<80160669>] lock_acquire+0xb9/0xd0
[ 187.348222] [] ? nonstatic_find_mem_region+0x83/0x210
[rsrc_nonstatic]
[ 187.348229] [<8053c6b6>] mutex_lock_nested+0x46/0x2a0
[ 187.348236] [] ? nonstatic_find_mem_region+0x83/0x210
[rsrc_nonstatic]
[ 187.348244] [] nonstatic_find_mem_region+0x83/0x210
[rsrc_nonstatic]
[ 187.348251] [<8015dcec>] ? trace_hardirqs_on_caller+0x11c/0x160
[ 187.348259] [] ? nonstatic_find_mem_region+0x0/0x210
[rsrc_nonstatic]
[ 187.348269] [] pcmcia_find_mem_region+0x3a/0x50 [pcmcia]
[ 187.348279] [] set_cis_map+0xc0/0x140 [pcmcia]
[ 187.348289] [] pcmcia_read_cis_mem+0x10e/0x2c0 [pcmcia]
[ 187.348296] [<8015dd3b>] ? trace_hardirqs_on+0xb/0x10
[ 187.348306] [] read_cis_cache+0x131/0x210 [pcmcia]
[ 187.348312] [<8015da50>] ? mark_held_locks+0x60/0x80
[ 187.348322] [] pccard_get_next_tuple+0x1b3/0x480 [pcmcia]
[ 187.348328] [<8015dcec>] ? trace_hardirqs_on_calle
Re: [RFC] PCMCIA locking updates for 2.6.34
Hi, Same result as Wolfram. > "echo d > /proc/sysrq-trigger" No output from sysrq-trigger. pcmcia 0.0: pcmcia: registering new device pcmcia0.0 pcmcia 0.1: pcmcia: registering new device pcmcia0.1 INFO: task modprobe:2191 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D 001c 0 2191 2187 0x0080 f45f1dd8 0086 36e648c7 001c f518c2f4 c0922ec0 c091e394 c0922ec0 f518c2f4 c0922ec0 c0922ec0 f45f fffd451a c3a84394 0001 001c f518c060 00d8 f6a1f178 f6a1f170 Call Trace: [] __mutex_lock_common+0x109/0x158 [] ? alloc_netdev_mq+0x19e/0x1bf [] __mutex_lock_slowpath+0x17/0x1a [] ? mutex_lock+0x30/0x3e [] mutex_lock+0x30/0x3e [] pcmcia_request_io+0x23/0xc9 [pcmcia] [] tc589_probe+0xfb/0x2eb [3c589_cs] [] pcmcia_device_probe+0x121/0x1a9 [pcmcia] [] ? device_release_driver+0xd/0x28 [] driver_probe_device+0x7e/0xf2 [] __driver_attach+0x48/0x64 [] bus_for_each_dev+0x42/0x6c [] driver_attach+0x19/0x1b [] ? __driver_attach+0x0/0x64 [] bus_add_driver+0x94/0x1c4 [] ? kset_find_obj+0x12/0x4f [] driver_register+0x7e/0xe5 [] pcmcia_register_driver+0xc2/0xf2 [pcmcia] [] ? init_tc589+0x0/0xf [3c589_cs] [] init_tc589+0xd/0xf [3c589_cs] [] do_one_initcall+0x51/0x144 [] sys_init_module+0xac/0x1e0 [] sysenter_do_call+0x12/0x2d INFO: task modprobe:2192 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D 001c 0 2192 2188 0x0080 f45f3e64 0086 3840b4f3 001c f5378f74 26c0 c091e394 c0922ec0 f5378f74 c0922ec0 c0922ec0 f45f3e5c fffd457c c3a04394 001c f5378ce0 f45f3e94 f712fc9c f712fc94 Call Trace: [] schedule_timeout+0x1b/0x95 [] ? pcmcia_devmatch+0x2a3/0x2b4 [pcmcia] [] ? __sysfs_add_one+0x2b/0x7a [] ? sysfs_addrm_finish+0x1b/0x93 [] ? sysfs_add_one+0x18/0xc2 [] __down_common+0x82/0xb9 [] __down+0x17/0x19 [] down+0x27/0x37 [] __driver_attach+0x2f/0x64 [] bus_for_each_dev+0x42/0x6c [] driver_attach+0x19/0x1b [] ? __driver_attach+0x0/0x64 [] bus_add_driver+0x94/0x1c4 [] ? kset_find_obj+0x23/0x4f [] driver_register+0x7e/0xe5 [] pcmcia_register_driver+0xc2/0xf2 [pcmcia] [] ? init_serial_cs+0x0/0xf [serial_cs] [] init_serial_cs+0xd/0xf [serial_cs] [] do_one_initcall+0x51/0x144 [] sys_init_module+0xac/0x1e0 [] sysenter_do_call+0x12/0x2d SysRq : HELP : loglevel(0-9) reBoot Crash terminate-all-tasks(E) memory-full-oom-kill(F) kill-all-tasks(I) thaw-filesystems(J) saK show-backtrace-all-active-cpus(L) show-memory-usage(M) nice-all-RT-tasks(N) powerOff show-registers(P) show-all-timers(Q) unRaw Sync show-task-states(T) Unmount force-fb(V) show-blocked-tasks(W) dump-ftrace-buffer(Z) INFO: task modprobe:2191 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D 001c 0 2191 1 0x0080 f45f1dd8 0086 36e648c7 001c f518c2f4 c0922ec0 c091e394 c0922ec0 f518c2f4 c0922ec0 c0922ec0 f45f fffd451a c3a84394 0001 001c f518c060 00d8 f6a1f178 f6a1f170 Call Trace: [] __mutex_lock_common+0x109/0x158 [] ? alloc_netdev_mq+0x19e/0x1bf [] __mutex_lock_slowpath+0x17/0x1a [] ? mutex_lock+0x30/0x3e [] mutex_lock+0x30/0x3e [] pcmcia_request_io+0x23/0xc9 [pcmcia] [] tc589_probe+0xfb/0x2eb [3c589_cs] [] pcmcia_device_probe+0x121/0x1a9 [pcmcia] [] ? device_release_driver+0xd/0x28 [] driver_probe_device+0x7e/0xf2 [] __driver_attach+0x48/0x64 [] bus_for_each_dev+0x42/0x6c [] driver_attach+0x19/0x1b [] ? __driver_attach+0x0/0x64 [] bus_add_driver+0x94/0x1c4 [] ? kset_find_obj+0x12/0x4f [] driver_register+0x7e/0xe5 [] pcmcia_register_driver+0xc2/0xf2 [pcmcia] [] ? init_tc589+0x0/0xf [3c589_cs] [] init_tc589+0xd/0xf [3c589_cs] [] do_one_initcall+0x51/0x144 [] sys_init_module+0xac/0x1e0 [] sysenter_do_call+0x12/0x2d INFO: task modprobe:2192 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. modprobe D 001c 0 2192 1 0x0080 f45f3e64 0086 3840b4f3 001c f5378f74 26c0 c091e394 c0922ec0 f5378f74 c0922ec0 c0922ec0 f45f3e5c fffd457c c3a04394 001c f5378ce0 f45f3e94 f712fc9c f712fc94 Call Trace: [] schedule_timeout+0x1b/0x95 [] ? pcmcia_devmatch+0x2a3/0x2b4 [pcmcia] [] ? __sysfs_add_one+0x2b/0x7a [] ? sysfs_addrm_finish+0x1b/0x93 [] ? sysfs_add_one+0x18/0xc2 [] __down_common+0x82/0xb9 [] __down+0x17/0x19 [] down+0x27/0x37 [] __driver_attach+0x2f/0x64 [] bus_for_each_dev+0x42/0x6c [] driver_attach+0x19/0x1b [] ? __driver_attach+0x0/0x64 [] bus_add_driver+0x94/0x1c4 [] ? kset_find_obj+0x23/0x4f [] driver_register+0x7e/0xe5 [] pcmcia_register_driver+0xc2/0xf2 [pcmcia] [] ? init_serial_cs+0x0/0xf [serial_cs] [] init_seri
Re: [RFC] PCMCIA locking updates for 2.6.34
> Thanks for testing -- might it be the following one-liner? I did a quick test, but it did not help. Will do a more careful check tomorrow. I feel quite tired right now, maybe I just mixed something up... > If it doesn't help, could you enable lockdep, please, and check with > > "echo d > /proc/sysrq-trigger" > > which lock is held where by which task? Will do! Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [RFC] PCMCIA locking updates for 2.6.34
Hey Wolfram, On Sat, Jan 16, 2010 at 08:41:21PM +0100, Wolfram Sang wrote: > On Sat, Jan 16, 2010 at 01:41:43PM +0100, Dominik Brodowski wrote: > > > > > on top of what had already been discussed for 2.6.34, here are 12 patches > > trying to fix the locking mess the PCMCIA subsystem used to be. As a > > side-effect, the PCMCIA ioctl will be disabled for all except the ARM > > architecture, and even there you need !SMP and !PREEMPT. Hopefully, we'll be > > able to remove the ioctl from ARM too. > > > > Everything is available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git#locking > > I pulled and tested this branch. Sadly, it doesn't work for me. If I insert a > (previously working) network card, io-resources get allocated, but the driver > does not even print its success-string. Luckily, I had hung-task detection > enabled: Thanks for testing -- might it be the following one-liner? > A deadlock? At this stage, the pcmcia-host is stuck. Card removal is detected, > but the resources don't get freed. Let me know if I can provide more info or > can do more testing. If it doesn't help, could you enable lockdep, please, and check with "echo d > /proc/sysrq-trigger" which lock is held where by which task? Best, Dominik From: Dominik Brodowski Date: Sat, 16 Jan 2010 21:19:57 +0100 Subject: [PATCH] pcmcia: fix pcmcia_request_io locking Signed-off-by: Dominik Brodowski diff --git a/drivers/pcmcia/pcmcia_resource.c b/drivers/pcmcia/pcmcia_resource.c index 052b6ca..44cb7fa 100644 --- a/drivers/pcmcia/pcmcia_resource.c +++ b/drivers/pcmcia/pcmcia_resource.c @@ -689,9 +689,10 @@ int pcmcia_request_io(struct pcmcia_device *p_dev, io_req_t *req) c->io = *req; c->state |= CONFIG_IO_REQ; p_dev->_io = 1; - mutex_unlock(&s->ops_mutex); out: + mutex_unlock(&s->ops_mutex); + return ret; } /* pcmcia_request_io */ EXPORT_SYMBOL(pcmcia_request_io); ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [RFC] PCMCIA locking updates for 2.6.34
Hi Dominik, On Sat, Jan 16, 2010 at 01:41:43PM +0100, Dominik Brodowski wrote: > > on top of what had already been discussed for 2.6.34, here are 12 patches > trying to fix the locking mess the PCMCIA subsystem used to be. As a > side-effect, the PCMCIA ioctl will be disabled for all except the ARM > architecture, and even there you need !SMP and !PREEMPT. Hopefully, we'll be > able to remove the ioctl from ARM too. > > Everything is available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git#locking I pulled and tested this branch. Sadly, it doesn't work for me. If I insert a (previously working) network card, io-resources get allocated, but the driver does not even print its success-string. Luckily, I had hung-task detection enabled: [ 54.276728] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 [ 54.276747] pcmcia_socket pcmcia_socket0: cs: memory probe 0x0d4000-0x0d: clean. [ 54.288227] pcmcia_socket pcmcia_socket0: cs: memory probe 0x6000-0x60ff: clean. [ 54.318694] pcmcia_socket pcmcia_socket0: cs: memory probe 0xa000-0xa0ff: clean. [ 54.349945] pcmcia_socket pcmcia_socket0: cs: memory probe 0xffd1-0xffde: clean. [ 54.381320] pcmcia 0.0: pcmcia: registering new device pcmcia0.0 [ 240.110047] INFO: task modprobe:2669 blocked for more than 120 seconds. [ 240.110056] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 240.110065] modprobe D bf05c428 0 2669 1 0x [ 240.110078] bd823c40 0086 c1d6637d bf05c428 bf800140 bf87d890 bf05c534 bf87d890 [ 240.110096] bf05c538 bd823c64 8050eac3 bf05c538 bf05c538 bf87d890 bf05c534 [ 240.110112] bf03d020 bf05c428 bd823c74 8050ed2e bf03d020 bf03d000 bd823cac c1d66e58 [ 240.110128] Call Trace: [ 240.110155] [] ? alloc_io_space+0x32d/0x3a0 [pcmcia] [ 240.110170] [<8050eac3>] __mutex_lock_slowpath+0x53/0x90 [ 240.110181] [<8050ed2e>] mutex_lock+0x1e/0x30 [ 240.110195] [] pcmcia_request_io+0x28/0x420 [pcmcia] [ 240.110204] [<8050ed23>] ? mutex_lock+0x13/0x30 [ 240.110218] [] ? read_cis_cache+0xa3/0x200 [pcmcia] [ 240.110239] [] pcnet_confcheck+0x110/0x174 [pcnet_cs] [ 240.110253] [] pcmcia_do_loop_config+0x69/0x80 [pcmcia] [ 240.110267] [] pccard_loop_tuple+0xed/0x150 [pcmcia] [ 240.110282] [] ? pcmcia_do_loop_config+0x0/0x80 [pcmcia] [ 240.110296] [] pcmcia_loop_config+0xb9/0xd0 [pcmcia] [ 240.110310] [] ? pcmcia_do_loop_config+0x0/0x80 [pcmcia] [ 240.110327] [] ? pcnet_confcheck+0x0/0x174 [pcnet_cs] [ 240.110344] [] pcnet_probe+0x9d/0xbf0 [pcnet_cs] [ 240.110358] [] ? read_cis_cache+0xa3/0x200 [pcmcia] [ 240.110373] [] ? pccard_read_tuple+0xaf/0x120 [pcmcia] [ 240.110388] [<80292491>] ? ida_get_new_above+0x81/0x1f0 [ 240.110402] [] pcmcia_device_probe+0xf8/0x2b0 [pcmcia] [ 240.110412] [<8050ed23>] ? mutex_lock+0x13/0x30 [ 240.110425] [<803bae00>] ? driver_sysfs_add+0x50/0x70 [ 240.110435] [<803baf73>] driver_probe_device+0x93/0x280 [ 240.110445] [<802934d9>] ? kobject_add_internal+0xb9/0x240 [ 240.110456] [<803bb1e9>] __driver_attach+0x89/0x90 [ 240.110466] [<803ba683>] bus_for_each_dev+0x53/0x80 [ 240.110476] [<803bad4e>] driver_attach+0x1e/0x20 [ 240.110486] [<803bb160>] ? __driver_attach+0x0/0x90 [ 240.110495] [<803b9f17>] bus_add_driver+0x207/0x300 [ 240.110510] [] ? pcmcia_device_remove+0x0/0x1e0 [pcmcia] [ 240.110520] [<803bb4ca>] driver_register+0x7a/0x170 [ 240.110535] [] pcmcia_register_driver+0xb4/0x170 [pcmcia] [ 240.110549] [<8016d1c5>] ? tracepoint_module_notify+0x25/0x30 [ 240.110561] [<8014c64d>] ? notifier_call_chain+0x3d/0x80 [ 240.110578] [] ? init_pcnet_cs+0x0/0xf [pcnet_cs] [ 240.110596] [] init_pcnet_cs+0xd/0xf [pcnet_cs] [ 240.110606] [<80101118>] do_one_initcall+0x28/0x180 [ 240.110617] [<8014cb4f>] ? blocking_notifier_call_chain+0x1f/0x30 [ 240.110630] [<8015f00f>] sys_init_module+0xaf/0x210 [ 240.110640] [<80102bd0>] sysenter_do_call+0x12/0x26 A deadlock? At this stage, the pcmcia-host is stuck. Card removal is detected, but the resources don't get freed. Let me know if I can provide more info or can do more testing. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
[RFC] PCMCIA locking updates for 2.6.34
Hey, on top of what had already been discussed for 2.6.34, here are 12 patches trying to fix the locking mess the PCMCIA subsystem used to be. As a side-effect, the PCMCIA ioctl will be disabled for all except the ARM architecture, and even there you need !SMP and !PREEMPT. Hopefully, we'll be able to remove the ioctl from ARM too. Everything is available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git#locking Dominik Brodowski (12): pcmcia: add locking to set_mem_map() pcmcia: also lock fake and cache CIS by ops_mutex pcmcia: lock ops->set_io_map() pcmcia: lock ops->set_socket pcmcia: properly lock skt->irq, skt->irq_mask pcmcia: protect s->device_count pcmcia: add locking to struct pcmcia_socket->pcmcia_state() pcmcia: simplify locking pcmcia: add locking documentation pcmcia: assert locking to struct pcmcia_device pcmcia: use mutex for dynid lock pcmcia: disable pcmcia ioctl for !ARM Documentation/pcmcia/locking.txt | 117 drivers/pcmcia/Kconfig |2 +- drivers/pcmcia/cistpl.c | 24 ++- drivers/pcmcia/cs.c | 24 +-- drivers/pcmcia/ds.c | 138 +- drivers/pcmcia/pcmcia_ioctl.c| 11 ++-- drivers/pcmcia/pcmcia_resource.c | 124 +- drivers/pcmcia/rsrc_mgr.c|6 +- drivers/pcmcia/rsrc_nonstatic.c |8 ++ drivers/pcmcia/socket_sysfs.c|7 +- include/pcmcia/ds.h |2 +- include/pcmcia/ss.h |7 ++- 12 files changed, 369 insertions(+), 101 deletions(-) create mode 100644 Documentation/pcmcia/locking.txt Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
