RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 839384 - kernel hangs up in netpoll
Summary: kernel hangs up in netpoll
Keywords:
Status: CLOSED DUPLICATE of bug 769734
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Rashid Khan
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
: 839381 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-11 19:20 UTC by Andrew Vagin
Modified: 2012-08-08 07:53 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-08 07:53:27 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
console.log (37.16 KB, text/x-log)
2012-07-11 19:20 UTC, Andrew Vagin 		no flags Details
View All

Description Andrew Vagin 2012-07-11 19:20:10 UTC 
Created attachment 597656 [details]
console.log

Description of problem:
Non-debug kernel hangs up, the debug kernel reports a problem:
<3>BUG: sleeping function called from invalid context at kernel/mutex.c:287
<0>BUG: spinlock recursion on CPU#0, brctl/4715 (Not tainted)
<0> lock: ffffffffa02d3000, .magic: dead4ead, .owner: brctl/4715, .owner_cpu: 

Version-Release number of selected component (if applicable):
2.6.32-279.el6.x86_64

How reproducible:
100%


Steps to Reproduce:
1. Set up netconsole in eth0
2. Create veth devices
   # ip link create type veth
   # ip link set up dev veth1
   # ip link set up dev veth0
3. Create bridge and add veth1 to it
   # brctl addbr br0
   # brctl addif br0 veth1
4. Add eth0 to br0
   # brctl addif br0 eth0
  
Actual results:
kernel hangs up

Expected results:
kernel should not hang
Comment 2 Andrew Vagin 2012-07-11 19:36:50 UTC 
The mainstrem kernel doesn't hangs in this case and reports following messages in log:
netconsole: network logging stopped on interface eth0 as it is joining a master device
device eth0 entered promiscuous mode
br0: port 2(eth0) entered forwarding state
br0: port 2(eth0) entered forwarding state
Comment 3 Andrew Vagin 2012-07-12 07:59:32 UTC 
Looks like the following commit should be back-ported.

commit 13f172ff26563995049abe73f6eeba828de3c09d
Author: Neil Horman <nhorman>
Date:   Fri Apr 22 08:10:59 2011 +0000

    netconsole: fix deadlock when removing net driver that netconsole is using (v2)
    
    A deadlock was reported to me recently that occured when netconsole was being
    used in a virtual guest.  If the virtio_net driver was removed while netconsole
    was setup to use an interface that was driven by that driver, the guest
    deadlocked.  No backtrace was provided because netconsole was the only console
    configured, but it became clear pretty quickly what the problem was.  In
    netconsole_netdev_event, if we get an unregister event, we call
    __netpoll_cleanup with the target_list_lock held and irqs disabled.
    __netpoll_cleanup can, if pending netpoll packets are waiting call
    cancel_delayed_work_sync, which is a sleeping path.  the might_sleep call in
    that path gets triggered, causing a console warning to be issued.  The
    netconsole write handler of course tries to take the target_list_lock again,
    which we already hold, causing deadlock.
    
    The fix is pretty striaghtforward.  Simply drop the target_list_lock and
    re-enable irqs prior to calling __netpoll_cleanup, the re-acquire the lock, and
    restart the loop.  Confirmed by myself to fix the problem reported.
    
    Signed-off-by: Neil Horman <nhorman>
    CC: "David S. Miller" <davem>
    Signed-off-by: David S. Miller <davem>
Comment 4 Rashid Khan 2012-07-26 20:26:54 UTC 
*** Bug 839381 has been marked as a duplicate of this bug. ***
Comment 5 Cong Wang 2012-08-08 07:53:27 UTC 

*** This bug has been marked as a duplicate of bug 769734 ***
Note You need to log in before you can comment on or make changes to this bug.