I received the following email and the Doc Text was updated but the X-Bugzilla-Reason header only shows CC. So it ended up getting misfiled by my filtering rules. Return-Path: bugzilla Received: from zmta05.collab.prod.int.phx2.redhat.com (LHLO zmta05.collab.prod.int.phx2.redhat.com) (10.5.81.12) by zmail09.collab.prod.int.phx2.redhat.com with LMTP; Fri, 23 Aug 2013 06:12:05 -0400 (EDT) Received: from zmta05.collab.prod.int.phx2.redhat.com (localhost [127.0.0.1]) by zmta05.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 9E07EF34C1 for <jvillalo>; Fri, 23 Aug 2013 06:12:05 -0400 (EDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by zmta05.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id 8B35DF347E for <jvillalo.redhat.com>; Fri, 23 Aug 2013 06:12:05 -0400 (EDT) Received: from mx1-phx2.redhat.com (mx01.util.phx2.redhat.com [10.5.26.26]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r7NAC5Dv006308 for <jvillalo>; Fri, 23 Aug 2013 06:12:05 -0400 Received: from bzweb02.app.bz.hst.phx2.redhat.com (bzweb02.app.bz.hst.phx2.redhat.com [10.5.117.17]) by mx1-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7NAC56L030674 for <jvillalo>; Fri, 23 Aug 2013 06:12:05 -0400 Received: from bzweb02.app.bz.hst.phx2.redhat.com (localhost.localdomain [127.0.0.1]) by bzweb02.app.bz.hst.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r7NAC5tM012264 for <jvillalo>; Fri, 23 Aug 2013 06:12:05 -0400 Received: (from root@localhost) by bzweb02.app.bz.hst.phx2.redhat.com (8.13.8/8.13.8/Submit) id r7NAC5cd012262; Fri, 23 Aug 2013 06:12:05 -0400 From: bugzilla To: jvillalo Subject: [Bug 977666] read_swap_cache_async() race to deadlock while waiting on discard I/O completion [rhel-6.2.z] Date: Fri, 23 Aug 2013 10:11:33 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Classification: Red Hat X-Bugzilla-Product: Red Hat Enterprise Linux 6 X-Bugzilla-Component: kernel X-Bugzilla-Version: 6.3 X-Bugzilla-Keywords: ZStream X-Bugzilla-Severity: urgent X-Bugzilla-Who: msvoboda X-Bugzilla-Status: CLOSED X-Bugzilla-Priority: urgent X-Bugzilla-Assigned-To: npajkovs X-Bugzilla-Target-Milestone: rc X-Bugzilla-Changed-Fields: cc X-Bugzilla-Comment: none X-Loop: bugzilla X-BeenThere: bugzilla X-Bugzilla-Reporter: jkurik Message-ID: <bug-977666-265752-OYKMBOmw7s.com> In-Reply-To: <bug-977666-265752.com> References: <bug-977666-265752.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugzilla.redhat.com/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 https://bugzilla.redhat.com/show_bug.cgi?id=977666 Miroslav Svoboda <msvoboda> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |msvoboda --- Doc Text *updated* --- A race condition between the read_swap_cache_async() and get_swap_page() functions in the Memory management (mm) code could lead to a deadlock situation. The deadlock could occur only on systems that deployed swap partitions on devices supporting block DISCARD and TRIM operations if kernel preemption was disabled (the !CONFIG_PREEMPT parameter). If the read_swap_cache_async() function was given a SWAP_HAS_CACHE entry that did not have a page in the swap cache yet , a DISCARD operation was performed in the scan_swap_map() function. Consequently , completion of an I/O operation was scheduled on the same CPU's working queue the read_swap_cache_async() was running on. This caused the thread in read_swap_cache_async() to loop indefinitely around its "-EEXIST" case , rendering the system unresponsive. The problem has been fixed by adding an explicit cond_resched() call to read_swap_cache_async(), which allows other tasks to run on the affected CPU, and thus avoiding the deadlock. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kuJRUVjElZ&a=cc_unsubscribe
Sorry, it was caused by the change in bug 908343. I think it is possible to do the changes requested in that bug another way.
Found a small bug that meant the plain text was mucked up if two or more changes happened on a bug.
This change is now live. If there are any issues, do not reopen this bug. Instead, you should create a new bug and reference this bug. -- simon