From: "Matt Carlson" <mcarlson@broadcom.com>
To: "Richard Cochran" <richardcochran@gmail.com>
Cc: "Eric Dumazet" <eric.dumazet@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"David Miller" <davem@davemloft.net>,
"Matthew Carlson" <mcarlson@broadcom.com>,
"Michael Chan" <mchan@broadcom.com>
Subject: Re: [PATCH 07/11] fs_enet: enable transmit time stamping.
Date: Wed, 22 Jun 2011 16:56:32 -0700 [thread overview]
Message-ID: <20110622235632.GA31004@mcarlson.broadcom.com> (raw)
In-Reply-To: <20110620065831.GA5771@riccoc20.at.omicron.at>
On Sun, Jun 19, 2011 at 11:58:31PM -0700, Richard Cochran wrote:
> On Sun, Jun 19, 2011 at 08:30:49PM +0200, Eric Dumazet wrote:
> > Le dimanche 19 juin 2011 ? 20:12 +0200, Richard Cochran a ?crit :
> >
> > > Thanks for your review. I have posted a fix for the first batch (since
> > > they are already in next) and reposted this series.
> > >
> > > But, considering your point, it looks like pxa168_eth and mv643xx_eth
> > > (see patches 9 and 10 of this series) already access skb->len unsafely.
> > >
> > > Would you care to comment on those spots, too?
> >
> > They certainly are buggy, at a first glance.
> >
> > Not only skb->len is unsafe, but netif_tx_stop_queue() calls are unsafe
> > too.
>
> Out of the MAC drivers in my two batches, only drivers/net/tg3.c calls
> netif_tx_stop_queue(txq);
>
> However, I don't know how to fix that. Anyone else care to take a look?
How is netif_tx_stop_queue() unsafe?
next prev parent reply other threads:[~2011-06-22 23:53 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-19 11:19 [PATCH 00/11] net: expand time stamping, batch #2 Richard Cochran
2011-06-19 11:19 ` [PATCH 01/11] net: export the receive time stamping hook for non-NAPI drivers Richard Cochran
2011-06-19 11:19 ` [PATCH 02/11] lib8390: enable transmit and receive time stamping Richard Cochran
2011-06-19 11:19 ` [PATCH 03/11] emaclite: " Richard Cochran
2011-06-19 11:53 ` Eric Dumazet
2011-06-19 11:20 ` [PATCH 04/11] ll_temac: " Richard Cochran
2011-06-19 11:20 ` [PATCH 05/11] fec_mpc52xx: " Richard Cochran
2011-06-19 11:56 ` Eric Dumazet
2011-06-19 11:20 ` [PATCH 06/11] macb: enable transmit " Richard Cochran
2011-06-19 11:56 ` Eric Dumazet
2011-06-19 11:20 ` [PATCH 07/11] fs_enet: " Richard Cochran
2011-06-19 11:58 ` Eric Dumazet
2011-06-19 18:12 ` Richard Cochran
2011-06-19 18:30 ` Eric Dumazet
2011-06-20 6:58 ` Richard Cochran
2011-06-22 23:56 ` Matt Carlson [this message]
2011-06-19 11:20 ` [PATCH 08/11] smsc911x: " Richard Cochran
2011-06-19 11:20 ` [PATCH 09/11] pxa168_eth: " Richard Cochran
2011-06-19 18:15 ` Richard Cochran
2011-06-19 11:20 ` [PATCH 10/11] mv643xx_eth: " Richard Cochran
2011-06-19 18:17 ` Richard Cochran
2011-06-19 18:33 ` Eric Dumazet
2011-06-19 19:05 ` David Miller
2011-06-19 22:43 ` [PATCH] hp100: fix an skb->len race Eric Dumazet
2011-06-19 23:34 ` David Miller
2011-06-19 11:20 ` [PATCH 11/11] ucc_geth: enable transmit time stamping Richard Cochran
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=20110622235632.GA31004@mcarlson.broadcom.com \
--to=mcarlson@broadcom.com \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=mchan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=richardcochran@gmail.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.