From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: Jia-Ju Bai <baijiaju1990@163.com>
Cc: todd.fujinaka@intel.com, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, linux.nics@intel.com
Subject: Re: [linux-nics] [PATCH] e1000e in linux-3.18.0: some potential bugs
Date: Sat, 20 Dec 2014 02:22:32 -0800 [thread overview]
Message-ID: <1419070952.2461.82.camel@jtkirshe-mobl.home> (raw)
In-Reply-To: <000f01d01c2b$4af1b3b0$e0d51b10$@163.com>
[-- Attachment #1: Type: text/plain, Size: 3185 bytes --]
On Sat, 2014-12-20 at 16:02 +0800, Jia-Ju Bai wrote:
> I have actually tested e1000e driver on the real hardware(Intel
> 82572EI
> PCI-E Gigabit Ethernet Controller), and find some potential bugs:
> The target file is drivers/net/ethernet/intel/e1000e/netdev.c, which
> is used
> to build e1000e.ko.
>
> (1) In the normal process, netif_napi_add is called in e1000_probe,
> but
> netif_napi_del is not called in e1000_remove. However, many other
> ethernet
> card drivers call them in pairs, even in the error handling paths,
> such as
> r8169 and igb.
>
> (2) The function vzalloc is called by e1000e_setup_rx_resources (in
> e1000_open) when initializing the ethernet card driver. But when
> vzalloc is
> failed, "err" segment in e1000e_setup_rx_resources is executed to
> return and
> then e1000e_free_tx_resources in "err_setup_rx" segment in e1000_open
> is
> executed to halt. However, "writel(0, tx_ring->head)" statement in
> e1000_clean_tx_ring in e1000e_free_tx_resources will cause system
> crash,
> because "tx_ring->head" is not assigned the value. In the code,
> "tx_ring->head" is initialized in e1000_configure_tx in
> e1000_configure
> after the e1000e_setup_rx_resources.
> (3) The same system crashes happens, when kcalloc in
> e1000e_setup_rx_resources is failed(returns NULL).
> (4) The same system crashes happens, when e1000_alloc_ring_dma in
> e1000e_setup_rx_resources is failed(returns error code).
>
> (5) In the normal process of e1000e, pci_enable_pcie_error_reporting
> and
> pci_disable_pcie_error_reporting is called in pairs in e1000_probe and
> e1000_remove. However, when pci_enable_pcie_error_reporting has been
> called
> and pci_save_state in e1000_probe is failed, "err_alloc_etherdev"
> segment in
> e1000_probe is executed immediately to exit, but
> pci_disable_pcie_error_reporting is not called.
> (6) The same situation happens when alloc_etherdev_mqs in e1000_probe
> is
> failed.
> (7) The same situation happens when ioremap in e1000_probe is failed.
> (8) The same situation happens when e1000_sw_init in e1000_probe is
> failed.
> (9) The same situation happens when register_netdev in e1000_probe is
> failed.
>
> (10) When request_irq in e1000_request_irq is failed,
> pm_qos_add_request in
> e1000_open is called, but pm_qos_remove_request is not called.
>
> Meanwhile, I also write the patch to fix the bugs. I have run the
> patch on
> the hardware, it can work normally and fix the above bugs.
Again, is this an issue you saw or a theoretical issue?
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 247335d..02d1e67 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -2444,6 +2444,8 @@ static void e1000_clean_tx_ring(struct
> e1000_ring
> *tx_ring)
> tx_ring->next_to_use = 0;
> tx_ring->next_to_clean = 0;
>
> + if(!(tx_ring->head))
> + return;
Need a space between the 'if' and the (). Please check your patches by
running checkpatch.pl on them before sending them out.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2014-12-20 10:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-20 8:02 [PATCH] e1000e in linux-3.18.0: some potential bugs Jia-Ju Bai
2014-12-20 10:22 ` Jeff Kirsher [this message]
[not found] ` <aaab622.119b.14a67ba656c.Coremail.baijiaju1990@163.com>
2014-12-20 12:47 ` Re:Re: [linux-nics] " Jeff Kirsher
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=1419070952.2461.82.camel@jtkirshe-mobl.home \
--to=jeffrey.t.kirsher@intel.com \
--cc=baijiaju1990@163.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=linux.nics@intel.com \
--cc=netdev@vger.kernel.org \
--cc=todd.fujinaka@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox