[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAP6odjgHcQ3Q6j_XSaLm0iJkAx+8tgtN+psXUekQ9U55O+9zjg@mail.gmail.com>
Date: Tue, 16 Jul 2013 10:20:40 -0700
From: Grant Grundler <grantgrundler@...il.com>
To: Ben Hutchings <bhutchings@...arflare.com>
Cc: George Spelvin <linux@...izon.com>, eric.dumazet@...il.com,
Grant Grundler <grundler@...isc-linux.org>,
"open list:TULIP NETWORK DRI..." <netdev@...r.kernel.org>
Subject: Re: [RFC] tulip: Support for byte queue limits
On Tue, Jul 16, 2013 at 7:37 AM, Ben Hutchings
<bhutchings@...arflare.com> wrote:
> On Mon, 2013-07-15 at 18:17 -0700, Grant Grundler wrote:
...
>> Is the problem the reference to skb->len?
>> By passing ownership, are you suggesting the device can change this value?
>
> No, the device can complete the descriptor and then the TX completion
> handler will free the skb.
Ah ok. That's what the spinlock_irqsave() is protecting against.
> [...]
>> > But one day someone may want to get rid of this lock,
>> > so this is a trap waiting to spring.
>>
>> Even for tulip driver? Sorry, I just can't imagine anyone taking
>> enough interest in tulip driver to implement that. I'm not even sure
>> it would be possible.
>
> You're taking interest in it, aren't you?
Let me clarify my interest: I will reject patches to change the
locking for this driver. Patch reviews for this driver are a
"community service project" since I know reasonably well how this chip
behaves. But I'm not doing anything else (e.g. bug fixes or testing).
If someone else wants to change the tulip driver locking, they need to
submit a patch to become the new maintainer first (I'll ACK that :)
> But I accept this is a minor issue.
Ok.
cheers,
grant
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists