netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers3@gmail.com>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: kvalo@codeaurora.org, linux-wireless@vger.kernel.org,
	netdev@vger.kernel.org, Stable <stable@vger.kernel.org>
Subject: Re: [PATCH for 3.19] rtlwifi: Fix error when accessing unmapped memory in skb
Date: Mon, 22 Dec 2014 17:33:05 -0600	[thread overview]
Message-ID: <20141222233305.GA11280@zzz> (raw)
In-Reply-To: <54989E12.6050808@lwfinger.net>

On Mon, Dec 22, 2014 at 04:41:22PM -0600, Larry Finger wrote:
> Please look at the attached patch. I think it handles the skb allocations
> correctly. The critical point is that _rtl_pci_init_one_rxdesc() cannot be
> allowed to fail to allocate an skb while in the interrupt path. Now, I have
> already allocated the skb before the call and bypassed this routine if the
> allocation fails. After a couple of crashes, this one now works for the case
> when the allocation wouldn't fail anyway. I will likely pull the allocation
> out of _rtl_pci_init_one_rxdesc() in all cases for the final patch.

Well, it's looking better.  But what seems strange to me is that
_rtl_pci_init_one_rxdesc() will map the skb for DMA, even though in the error
path it was never unmapped from the previous use.  The 3.17 version will neither
unmap nor map the skb in the error path.

I also suspect that trying to share _rtl_pci_init_one_rxdesc() between the
driver initialization and the interrupt handler is just confusing matters.
Perhaps only the ->set_desc() calls should be shared?

In any case, I assume it would be a good idea to, for testing, inject some
random skb allocation failures and make sure the driver still works smoothly
except for some dropped packets.

  reply	other threads:[~2014-12-22 23:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-22 17:37 [PATCH for 3.19] rtlwifi: Fix error when accessing unmapped memory in skb Larry Finger
2014-12-22 19:48 ` Eric Biggers
2014-12-22 22:41   ` Larry Finger
2014-12-22 23:33     ` Eric Biggers [this message]
2014-12-23  6:37     ` Kalle Valo

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=20141222233305.GA11280@zzz \
    --to=ebiggers3@gmail.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=kvalo@codeaurora.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stable@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).