From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22967 invoked by alias); 29 Aug 2014 08:07:03 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 22888 invoked by uid 48); 29 Aug 2014 08:06:53 -0000 From: "ma.jiang at zte dot com.cn" To: glibc-bugs@sourceware.org Subject: [Bug nptl/17326] New: endless loop in __reclaim_stacks Date: Fri, 29 Aug 2014 08:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: nptl X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: ma.jiang at zte dot com.cn X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-08/txt/msg00148.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17326 Bug ID: 17326 Summary: endless loop in __reclaim_stacks Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: nptl Assignee: unassigned at sourceware dot org Reporter: ma.jiang at zte dot com.cn CC: drepper.fsp at gmail dot com Created attachment 7766 --> https://sourceware.org/bugzilla/attachment.cgi?id=7766&action=edit my fix for the bug Hi all, After the fix mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=477705, I can still reproduce the bug on a dual-core armv7 board. As the Linux kernel only guarantee a per-page atomicity when doing fork, just adding a atomic_write_barrier is not enough to protect the stack_used/stack_cache lists. We need to stop threads which tried to modify the lists when a thread is doing fork, only then the child process could get a coherent list, and the __reclaim_stacks could do the right job. In fork, we have already done such things for io locks(see _IO_list_lock (),_IO_list_resetlock () and _IO_list_unlock () in __libc_fork). I belive we should also add some similar codes to protect the stack_used/stack_cache lists. I have made a patch(see the attachment), is that ok for trunk? -- You are receiving this mail because: You are on the CC list for the bug.