From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5316 invoked by alias); 26 Nov 2008 13:41:34 -0000 Received: (qmail 27851 invoked by uid 48); 26 Nov 2008 13:40:17 -0000 Date: Wed, 26 Nov 2008 13:41:00 -0000 Message-ID: <20081126134017.27849.qmail@sourceware.org> From: "pasky at suse dot cz" To: glibc-bugs@sources.redhat.com In-Reply-To: <20071121045836.5381.pasky@suse.cz> References: <20071121045836.5381.pasky@suse.cz> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug nscd/5381] nscd: Race condition of mempool_alloc() .. cache_add() and gc() X-Bugzilla-Reason: CC 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 X-SW-Source: 2008-11/txt/msg00071.txt.bz2 ------- Additional Comments From pasky at suse dot cz 2008-11-26 13:40 ------- Created an attachment (id=3078) --> (http://sourceware.org/bugzilla/attachment.cgi?id=3078&action=view) proposed patch #2 This is a proposed patch; currently, it seems to work fine - we have one reported crash in nscd, but I don't think it is related so far. This is a very simple approach - in theory, there could be a "gap area" near the top of the database that could grow indefinitely across gc() calls if _every_ gc() call would happen while there is some memory in flight, but based on my real-world nscd observations, I don't think this is realistic scenario even with very busy nscd; if your experience is different, we can go for a more complex patch that makes mempool_alloc() try to fit data into this gap area. -- http://sourceware.org/bugzilla/show_bug.cgi?id=5381 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.