linux-kernel - RE: e1000_intr in request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 15 Feb 2007 18:10:53 -0800
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	"Len Brown" <lenb@...nel.org>
Cc:	"Ronciak, John" <john.ronciak@...el.com>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>,
	"Kok, Auke-jan H" <auke-jan.h.kok@...el.com>,
	"lkml - Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: RE: e1000_intr in request_irq faults in 2.6.20-git

Eric W. Biederman wrote:
> Len Brown <lenb@...nel.org> writes:
> 
>> e1000 faults in 2.6.20-git, while 2.6.20 worked fine.
>> 
>> System is a D875PBZ with LOM.
>> 
>> clues?
> 
> I'm guessing this is an old bug found by the following bit of
> debug coded added into since v2.6.20
> 
> +#ifdef CONFIG_DEBUG_SHIRQ
> +       if (irqflags & IRQF_SHARED) {
> +               /*
> +                * It's a shared IRQ -- the driver ought to be
> prepared for it +                * to happen immediately, so let's
> make sure.... +                * We do this before actually
> registering it, to make sure that +                * a 'real' IRQ
> doesn't run in parallel with our fake +                */
> +               if (irqflags & IRQF_DISABLED) {
> +                       unsigned long flags;
> +
> +                       local_irq_save(flags);
> +                       handler(irq, dev_id);
> +                       local_irq_restore(flags);
> +               } else
> +                       handler(irq, dev_id);
> +       }
> +#endif
> 
> I don't have a clue why the e1000 wasn't ready though.
> 

our code is clearly calling request_irq before we have assigned the
function pointer adapter->clean_rx as well as adapter->alloc_rx_buf

That would be a bug, a possible patch would be (inline and attached):
compile tested, *but* I couldn't test this patch to make sure it worked
because I couldn't boot 2.6.20-git due to it not finding my RAID0 + lvm
disk.

[PATCH] e1000: fix shared interrupt warning message

From: Jesse Brandeburg <jesse.brandeburg@...el.com>

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
---

 drivers/net/e1000/e1000_main.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/net/e1000/e1000_main.c
b/drivers/net/e1000/e1000_main.c
index 619c892..b8c4d5c 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -1417,10 +1417,6 @@ e1000_open(struct net_device *netdev)
        if ((err = e1000_setup_all_rx_resources(adapter)))
                goto err_setup_rx;

-       err = e1000_request_irq(adapter);
-       if (err)
-               goto err_req_irq;
-
        e1000_power_up_phy(adapter);

        if ((err = e1000_up(adapter)))
@@ -1431,6 +1427,10 @@ e1000_open(struct net_device *netdev)
                e1000_update_mng_vlan(adapter);
        }

+       err = e1000_request_irq(adapter);
+       if (err)
+               goto err_req_irq;
+
        /* If AMT is enabled, let the firmware know that the network
         * interface is now open */
        if (adapter->hw.mac_type == e1000_82573 &&
@@ -1439,10 +1439,11 @@ e1000_open(struct net_device *netdev)

        return E1000_SUCCESS;

+err_req_irq:
+       e1000_down(adapter);
+       e1000_free_irq(adapter);
 err_up:
        e1000_power_down_phy(adapter);
-       e1000_free_irq(adapter);
-err_req_irq:
        e1000_free_all_rx_resources(adapter);
 err_setup_rx:
        e1000_free_all_tx_resources(adapter);

Download attachment "e1000_interrupt.patch" of type "application/octet-stream" (1373 bytes)