All of lore.kernel.org
 help / color / mirror / Atom feed
From: Holger Schurig <hs4233@mail.mn-solutions.de>
To: Dan Williams <dcbw@redhat.com>
Cc: libertas-dev@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCH] libertas: fix spinlock recursion bug
Date: Thu, 27 Mar 2008 12:57:26 +0100	[thread overview]
Message-ID: <200803271257.26820.hs4233@mail.mn-solutions.de> (raw)
In-Reply-To: <1206617646.6368.31.camel@localhost.localdomain>

> The problem with using upld_buf (and therefore zero-copy in
> the CF driver) is that you have no idea how long a read from
> the card will really take, and what errors might happen during
> the read from the card.

Yes, this can take a long time. And, BTW, I don't want to use 
upld_buf.


My idea is this:

> > struct lbs_event *lbs_get_free_event(struct lbs_private
> > *priv);

This will take out an lbs_event from the event_free_list and 
return it.
Taking out has to be done under spinlock, but this is very fast.

Once the lbs_event is no longer in any of the two event list, 
we "own" it and can handle it as long as we want, without the 
need of an additional spinlock.

Then

> > void lbs_handle_event(struct lbs_private *priv, struct
> > lbs_event *event);

would again take the spinlock, insert the event in the 
event_list, and release the spinlock. Which again takes only a 
short time.

This approach can make receiption of command responses from card 
zero-copy like, at least insofar the event processing is 
considered. 



> I'd argue that the CF driver should also have an internal
> buffer like the SDIO and USB drivers do, and then there's still
> only one copy.

Yeah, but I can reduce easily to a 0-copy-scheme.


I hope all of this sounds sane.


  reply	other threads:[~2008-03-27 12:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-19 14:24 [PATCH] libertas: fix spinlock recursion bug Holger Schurig
2008-03-19 15:02 ` Dan Williams
2008-03-26  7:48   ` Holger Schurig
2008-03-26 14:41 ` Holger Schurig
2008-03-26 15:17   ` Dan Williams
2008-03-26 15:37     ` Holger Schurig
2008-03-26 17:33       ` Dan Williams
2008-03-27  8:17         ` Holger Schurig
2008-03-27 10:08         ` Holger Schurig
2008-03-27 11:34           ` Dan Williams
2008-03-27 11:57             ` Holger Schurig [this message]
2008-03-27 14:31               ` Dan Williams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200803271257.26820.hs4233@mail.mn-solutions.de \
    --to=hs4233@mail.mn-solutions.de \
    --cc=dcbw@redhat.com \
    --cc=libertas-dev@lists.infradead.org \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.