All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Lamparter <chunkeey@googlemail.com>
To: Zhu Yi <yi.zhu@intel.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	Christian Mehlis <mehlis@inf.fu-berlin.de>,
	John W Linville <linville@tuxdriver.com>
Subject: Re: [PATCH] ar9170usb: fix panic triggered by undersized rxstream buffer
Date: Wed, 24 Mar 2010 13:30:53 +0100	[thread overview]
Message-ID: <201003241330.53869.chunkeey@googlemail.com> (raw)
In-Reply-To: <1269397218.4043.84.camel@debian>

On Wednesday 24 March 2010 03:20:18 Zhu Yi wrote:
> On Wed, 2010-03-24 at 09:59 +0800, Johannes Berg wrote:
> > On Tue, 2010-03-23 at 21:51 +0100, Christian Lamparter wrote:
> > > While ar9170's USB transport packet size is currently set to 8KiB,
> > > the PHY is capable of receiving AMPDUs with up to 64KiB.
> > > Such a large frame will be split over several rx URBs and
> > > exceed the previously allocated space for rx stream reconstruction.
> > > 
> > > This patch increases the buffer size to 64KiB which is
> > > in fact the phy & rx stream designed size limit.
> > 
> > That's a pretty high order allocation, you may want to paged allocation
> > -- you'll end up doing a order 5 allocation here!
> Yup, order-5 given the struct skb_shared_info overhead in __alloc_skb().
> If the URBs are split over, you probably don't need to allocate such a
> big chunk of memory in one go. 

I know, I know, but unfortunately I do need a continuous address space.
The reason is that usually one URB can have up to 5 data frames
(each with ~1600 Octets). That's why the driver memcpys everything
from the rxstream skbs into newly allocated ones for each individual frame.
(The reconstruction  simply adds another memcpy to a temporary buffer,
 until we have everything...).

as far as I can tell, there's only one other options:
 * mix vmalloc with paged skbs API ;-)

   This looks kind of funny. The API abuse is highly questionable and
   probably not something for "stable".

 * early drop, if len > 8KiB

   This has the downside that we lose the data and the rx stream state.
   (E.g.: signal quality & phy data, mac error codes, the lot...)

 * something I don't know?

   please tell me about it!

> You just need to connect them into a paged skb later before pushing to mac80211.
> BTW, I've moved the skb_linearize() from iwlwifi to mac80211. Will submit the patches today.
AFAIK Atheros resolved this issue with AR9271. At least that's what I
heard from Luis about the _new_ scatter/gather IO implementation.

Regards,
	Chr

      reply	other threads:[~2010-03-24 12:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-23 20:51 [PATCH] ar9170usb: fix panic triggered by undersized rxstream buffer Christian Lamparter
2010-03-24  1:59 ` Johannes Berg
2010-03-24  2:20   ` Zhu Yi
2010-03-24 12:30     ` Christian Lamparter [this message]

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=201003241330.53869.chunkeey@googlemail.com \
    --to=chunkeey@googlemail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=mehlis@inf.fu-berlin.de \
    --cc=yi.zhu@intel.com \
    /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.