From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: SathyaNarayanan <sathyan@teamf1.com>
Cc: linuxppc-dev@ozlabs.org, Stefan Roese <sr@denx.de>,
netdev@vger.kernel.org
Subject: Re: [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver
Date: Wed, 02 Jul 2008 15:46:00 +1000 [thread overview]
Message-ID: <1214977560.21182.35.camel@pasglop> (raw)
In-Reply-To: <1946a170807012145v6e6d629cvea443f2b8462d708@mail.gmail.com>
>
> Actually the meachanism of stopping the queue and starting it is
> already there. But even then due to some sync issue between the poll
> routine and xmit, we were resulted in using the slots of skb which was
> not actually got freed before.
> I agree this could a bug , Since its not is not clear why buffers are
> not getting transferred timely?. But to handle this we should have a
> work around otherwise system may go out of memory. If we go for
> stopping the queue in these scenario also ( Where a unfreed skbs slot
> has been assigned to another ), Then kernel may call tx timeout, And
> reset the driver. In that case handelling this special case here could
> lead us better performance as compared to stopping the queue
> Let me know your comments.
Well, if we have a bug, we need to fix it. ie, understand how it is that
the existing mechanism to stop the queue doesn't work, and prevent xmit
from overwriting a non-clear transmit slot (possibly displaying an error
to help us track down the bug).
I'll have to dig a bit, I'll see if I can find some time tomorrow.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: SathyaNarayanan <sathyan@teamf1.com>
Cc: Stefan Roese <sr@denx.de>,
linuxppc-dev@ozlabs.org, netdev@vger.kernel.org
Subject: Re: [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver
Date: Wed, 02 Jul 2008 15:46:00 +1000 [thread overview]
Message-ID: <1214977560.21182.35.camel@pasglop> (raw)
In-Reply-To: <1946a170807012145v6e6d629cvea443f2b8462d708@mail.gmail.com>
>
> Actually the meachanism of stopping the queue and starting it is
> already there. But even then due to some sync issue between the poll
> routine and xmit, we were resulted in using the slots of skb which was
> not actually got freed before.
> I agree this could a bug , Since its not is not clear why buffers are
> not getting transferred timely?. But to handle this we should have a
> work around otherwise system may go out of memory. If we go for
> stopping the queue in these scenario also ( Where a unfreed skbs slot
> has been assigned to another ), Then kernel may call tx timeout, And
> reset the driver. In that case handelling this special case here could
> lead us better performance as compared to stopping the queue
> Let me know your comments.
Well, if we have a bug, we need to fix it. ie, understand how it is that
the existing mechanism to stop the queue doesn't work, and prevent xmit
from overwriting a non-clear transmit slot (possibly displaying an error
to help us track down the bug).
I'll have to dig a bit, I'll see if I can find some time tomorrow.
Cheers,
Ben.
next prev parent reply other threads:[~2008-07-02 5:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-23 12:55 [PATCH] ibm_newemac: Fixes memory leak in ibm_newemac ethernet driver Stefan Roese
2008-06-23 12:55 ` Stefan Roese
2008-06-23 23:21 ` Benjamin Herrenschmidt
2008-06-23 23:21 ` Benjamin Herrenschmidt
2008-07-02 4:45 ` SathyaNarayanan
2008-07-02 4:45 ` SathyaNarayanan
2008-07-02 5:46 ` Benjamin Herrenschmidt [this message]
2008-07-02 5:46 ` Benjamin Herrenschmidt
2008-07-02 6:11 ` SathyaNarayanan
2008-07-02 6:11 ` SathyaNarayanan
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=1214977560.21182.35.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=sathyan@teamf1.com \
--cc=sr@denx.de \
/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.