> On Tue, 20 Feb 2007 16:08:11 +0100 20 Feb was a long time ago, sorry. I was hoping to feed the pcmcia patches through Dominik but I think he's busy with exams or such. So I get to pretend to be pcmcia maintainer.
"Markus Rechberger" <[EMAIL PROTECTED]> wrote: > following patch prevents a mutex/semaphore deadlock within the pcmcia > framework when ejecting devices multiple times using pccardctl eject. > > For some more details see: > http://lkml.org/lkml/2007/2/19/58 > > Signed-off-by: Markus Rechberger <[EMAIL PROTECTED]> > > -- > Markus Rechberger > Operating System Research Center > AMD Saxony LLC & Co. KG > > > > [pcmcia-pccard-deadlock-fix.diff text/plain (757B)] > index ac00424..c02bf0d 100644 > --- a/drivers/pcmcia/cs.c > +++ b/drivers/pcmcia/cs.c > @@ -856,7 +856,8 @@ int pcmcia_eject_card(struct pcmcia_socket *skt) > > cs_dbg(skt, 1, "user eject request\n"); > > - mutex_lock(&skt->skt_mutex); > + if (!mutex_trylock(&skt->skt_mutex)) > + return -EAGAIN; > do { > if (!(skt->state & SOCKET_PRESENT)) { > ret = -ENODEV; > index 18e111e..b9d3440 100644 > --- a/drivers/pcmcia/ds.c > +++ b/drivers/pcmcia/ds.c > @@ -1100,7 +1100,9 @@ static ssize_t pcmcia_store_allow_func_id_match(struct > device *dev, > if (!count) > return -EINVAL; > > - mutex_lock(&p_dev->socket->skt_mutex); > + if (!mutex_trylock(&p_dev->socket->skt_mutex)) > + return -EAGAIN; > + > p_dev->allow_func_id_match = 1; > mutex_unlock(&p_dev->socket->skt_mutex); > This is a pretty sad-looking solution. Does it not mean that sometimes user-initiated actions will mysteriously fail? Are you able to provide a more detailed description of why/how the deadlock actually occurs so that perhaps a more robust fix can be implemented? Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
