[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121129105934.3e0c3a04@thirdoffive.cmf.nrl.navy.mil>
Date: Thu, 29 Nov 2012 10:59:34 -0500
From: chas williams - CONTRACTOR <chas@....nrl.navy.mil>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Krzysztof Mazur <krzysiek@...lesie.net>,
David Laight <David.Laight@...LAB.COM>, davem@...emloft.net,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
nathan@...verse.com.au
Subject: Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
On Thu, 29 Nov 2012 15:47:57 +0000
David Woodhouse <dwmw2@...radead.org> wrote:
> @@ -1020,12 +1048,15 @@ static uint32_t fpga_tx(struct solos_card *card)
> if (vcc) {
> atomic_inc(&vcc->stats->tx);
> solos_pop(vcc, oldskb);
> - } else {
> - struct pkt_hdr *header = (void *)oldskb->data;
> - if (le16_to_cpu(header->type) == PKT_PCLOSE)
> - complete(&SKB_CB(oldskb)->c);
> +
> + /*
> + * If it's a TX skb on a closed VCC, pclose()
> + * may be waiting for it...
> + */
> + if (!test_bit(ATM_VF_READY, &vcc->flags))
> + wake_up(&card->param_wq);
> + } else
> dev_kfree_skb_irq(oldskb);
> - }
the part that bothers me (and i dont have the programmer's guide for
the solos hardware) is that you are watching for the PKT_PCLOSE to be
sent to the card. shouldnt you be watching for the PKT_PCLOSE to be
returned from the card (assuming it does such a thing) so that you can
be assured that the tx/rx for this vpi/vci pair has been "stopped"?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists