Re: Re: Re: [PATCH] pcmcia: cs.c : load "pcmcia" module automatically.
Hi, >> This patch integrates some of the pcmciautils feature into the kernel. > >yes, but why? Also, wouldn't request_module_nowait() suffice? > (1) Because the "pcmcia" is kernel module, so I think it should be loaded by kernel, if kernel can do it. (2) Even if distribution developer forgets to install the pcmciautils, the "pcmcia" is loaded with this patch. (especially embedded systems) (3) I think request_module_nowait is better. Best Regards Komuro ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Lockdep violation in pcmcia
Hey, On Mon, Nov 02, 2009 at 04:21:23PM -0500, Alan Stern wrote: > I've been getting these warnings for a long, long time, and finally > decided to report them: Thanks! > [ 1893.036023] other info that might help us debug this: > [ 1893.036023] 2 locks held by cardmgr/1457: Wow, cardmgr still in use... I had hoped it had already disappeared on non-embedded systems... > The cause is easy enough to track down. In pcmcia_ioctl.c, > pcmcia_adjust_resource_info() does a down_read() on > pcmcia_socket_list_rwsem. While holding the rwsem, one of the pathways > calls the s->resource_ops->add_mem method. On my system this method is > realized by adjust_memory() in rsrc_nonstatic.c, which does its own > down_read() on the same rwsem -- i.e., a recursive locking attempt. > > The reason lockdep warns about this behavior is that it can lead to > deadlock in the wrong circumstances, namely, if another thread were to > do a down_write() in between the two down_read() calls. > > Would it be correct simply to omit the down_read() in adjust_memory()? No, for there are other code paths reaching adjust_memory() not holding a (read) lock on this semaphore. As pcmcia_ioctl.c is on its way out anyways: would you mind keeping it as it is, for a down_write() call is quite unlikely during the only time cardmgr actually does this call (system startup)? Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Lockdep violation in pcmcia
I've been getting these warnings for a long, long time, and finally
decided to report them:
[ 1893.033051] =
[ 1893.036023] [ INFO: possible recursive locking detected ]
[ 1893.036023] 2.6.31 #2
[ 1893.036023] -
[ 1893.036023] cardmgr/1457 is trying to acquire lock:
[ 1893.036023] (pcmcia_socket_list_rwsem){.+}, at: []
adjust_memory+0x71/0xbd [rsrc_nonstatic]
[ 1893.036023]
[ 1893.036023] but task is already holding lock:
[ 1893.036023] (pcmcia_socket_list_rwsem){.+}, at: []
ds_ioctl+0x282/0xa6b [pcmcia]
[ 1893.036023]
[ 1893.036023] other info that might help us debug this:
[ 1893.036023] 2 locks held by cardmgr/1457:
[ 1893.036023] #0: (pcmcia_socket_list_rwsem){.+}, at: []
ds_ioctl+0x282/0xa6b [pcmcia]
[ 1893.036023] #1: (rsrc_mutex){+.+.+.}, at: []
adjust_memory+0x39/0xbd [rsrc_nonstatic]
[ 1893.036023]
[ 1893.036023] stack backtrace:
[ 1893.036023] Pid: 1457, comm: cardmgr Not tainted 2.6.31 #2
[ 1893.036023] Call Trace:
[ 1893.036023] [] __lock_acquire+0x741/0xa61
[ 1893.036023] [] ? mark_held_locks+0x3b/0x56
[ 1893.036023] [] lock_acquire+0x58/0x7a
[ 1893.036023] [] ? adjust_memory+0x71/0xbd [rsrc_nonstatic]
[ 1893.036023] [] down_read+0x2a/0x3e
[ 1893.036023] [] ? adjust_memory+0x71/0xbd [rsrc_nonstatic]
[ 1893.036023] [] adjust_memory+0x71/0xbd [rsrc_nonstatic]
[ 1893.036023] [] ? adjust_memory+0x0/0xbd [rsrc_nonstatic]
[ 1893.036023] [] ds_ioctl+0x32c/0xa6b [pcmcia]
[ 1893.036023] [] ? _raw_spin_trylock+0x2b/0x30
[ 1893.036023] [] vfs_ioctl+0x4c/0x65
[ 1893.036023] [] do_vfs_ioctl+0x451/0x478
[ 1893.036023] [] ? lock_release+0x12c/0x133
[ 1893.036023] [] sys_ioctl+0x2a/0x43
[ 1893.036023] [] sysenter_do_call+0x12/0x36
Is this problem already well known?
The cause is easy enough to track down. In pcmcia_ioctl.c,
pcmcia_adjust_resource_info() does a down_read() on
pcmcia_socket_list_rwsem. While holding the rwsem, one of the pathways
calls the s->resource_ops->add_mem method. On my system this method is
realized by adjust_memory() in rsrc_nonstatic.c, which does its own
down_read() on the same rwsem -- i.e., a recursive locking attempt.
The reason lockdep warns about this behavior is that it can lead to
deadlock in the wrong circumstances, namely, if another thread were to
do a down_write() in between the two down_read() calls.
Would it be correct simply to omit the down_read() in adjust_memory()?
Alan Stern
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Re: [PATCH] pcmcia: cs.c : load "pcmcia" module automatically.
Hey, On Mon, Nov 02, 2009 at 09:37:51PM +0900, Komuro wrote: > This patch integrates some of the pcmciautils feature into the kernel. yes, but why? Also, wouldn't request_module_nowait() suffice? Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [RFC PATCH 00/10] PCMCIA soc_common re-factorization
On Thu, Oct 29, 2009 at 05:25:52PM +, Russell King - ARM Linux wrote: > On Wed, Oct 28, 2009 at 10:25:34PM +0100, Dominik Brodowski wrote: > > Do you have a git tree to pull from, or shall I apply each patch locally? > > Alternatively, you're free to push it upstream yourself; as the PCMCIA core > > is only touched in one (albeit _very_ useful) line. > > Thanks. Here's a URL you can pull them from: > > ssh://master.kernel.org/home/rmk/linux-2.6-arm.git pcmcia Thanks! I've applied the patches you sent me by mail, though, as your tree was based on something more recent from Linus than my tree, and I wanted to avoid a merge of Linus' tree into my tree. http://git.kernel.org/?p=linux/kernel/git/brodo/pcmcia-2.6.git;a=summary should have your patches momentarily. Best, Dominik ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: Re: [PATCH] pcmcia: cs.c : load "pcmcia" module automatically.
Hi,
This patch integrates some of the pcmciautils feature into the kernel.
>
>As I'm a bit unsure about it: what's the general feeling about
>this patch?
>
>On Sun, Nov 01, 2009 at 12:04:30PM +0900, Komuro wrote:
>>
>> load "pcmcia" module for 16-bit PCMCIA cards
>> without help of userland script.
>>
>>
>> Signed-off-by: Komuro
>>
>> ---
>>
>> --- linux-2.6.32-rc5-git3/drivers/pcmcia/cs.c.orig 2009-11-01 11:50:57.
0 +0900
>> +++ linux-2.6.32-rc5-git3/drivers/pcmcia/cs.c2009-11-01
>> 11:47:53.0
+0900
>> @@ -239,6 +239,9 @@ int pcmcia_register_socket(struct pcmcia
>> goto err;
>> }
>>
>> +/* loading "pcmcia" module for 16-bit PCMCIA cards */
>> +request_module("pcmcia");
>> +
>> tsk = kthread_run(pccardd, socket, "pccardd");
>> if (IS_ERR(tsk)) {
>> ret = PTR_ERR(tsk);
>>
>> ___
>> Linux PCMCIA reimplementation list
>> http://lists.infradead.org/mailman/listinfo/linux-pcmcia
___
Linux PCMCIA reimplementation list
http://lists.infradead.org/mailman/listinfo/linux-pcmcia
Re: [alsa-devel] [PATCH 13/16] pcmcia: use dynamic debug infrastructure, deprecate CS_CHECK (sound)
At Sat, 24 Oct 2009 21:43:03 +0200, Dominik Brodowski wrote: > > Convert PCMCIA drivers to use the dynamic debug infrastructure, instead of > requiring manual settings of PCMCIA_DEBUG. > > Also, remove all usages of the CS_CHECK macro and replace them with proper > Linux style calling and return value checking. The extra error reporting may > be dropped, as the PCMCIA core already complains about any (non-driver-author) > errors. > > CC: Jaroslav Kysela > CC: alsa-de...@alsa-project.org > Signed-off-by: Dominik Brodowski Thanks, applied to sound git tree now. Takashi ___ Linux PCMCIA reimplementation list http://lists.infradead.org/mailman/listinfo/linux-pcmcia
