From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266808AbUBMIcf (ORCPT ); Fri, 13 Feb 2004 03:32:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266811AbUBMIcf (ORCPT ); Fri, 13 Feb 2004 03:32:35 -0500 Received: from herkules.viasys.com ([194.100.28.129]:61326 "HELO mail.viasys.com") by vger.kernel.org with SMTP id S266808AbUBMIcc (ORCPT ); Fri, 13 Feb 2004 03:32:32 -0500 Date: Fri, 13 Feb 2004 10:32:23 +0200 From: Ville Herva To: Linux-Kernel Mailing List Subject: 2.4: hung spamassassin processes on reiserfs+LVM Message-ID: <20040213083223.GC11555@viasys.com> Reply-To: vherva@viasys.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Operating-System: Linux herkules.viasys.com 2.4.21-pre4aa3+secfixes3 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org I've been experiencing deadlocks with kernel 2.4.21-pre4aa3+secfixes (secfixes includes ptrace, do_brk and mremap). I've seen at least one similar hang with 2.4.13ac2. The deadlocks have appeared when weekly cron jobs have run for some time, but also at other times. The kernel is still running, pingable, remote screen session is accessible, but process table seems full. It seems spamd from spamassassin package has to do with this, since on one occasion, alt-sysrq-t listed a huge number of hanging spamd processes. On other occasions, the alt-sysrq-t listing showed hanging crond and rsync processes (the list was way too long to see all of them.) Now I think I finally have a clue on what is going on. 39 spamd processes hung, and I was able to stop spamassassin before the box deadlocked totally. The spamd processes were unkillable (-KILL). After a while a couple of rsync processes hung, too, and I was able to find out that they tried to access /home/spamc/.spamassassin/ . "ls /home/spamc/.spamassassin" hangs too. /home is a reiserfs partition on LVM. I did alt-sysrq-t and ksymoopsed it. Most of the spamd processes have a stack trace like this: >>EIP; e71ec000 <===== Trace; c0107b6d <__down+5d/b0> Trace; c0107cc0 <__down_failed+8/c> Trace; c0146ad6 <.text.lock.namei+37/221> Trace; c012a835 Trace; c0139f46 Trace; c013a274 Trace; c0108deb Proc; spamd Some have have >>EIP; d72fe000 <===== Trace; c0107b6d <__down+5d/b0> Trace; c017f4d0 Trace; c0107cc0 <__down_failed+8/c> Trace; c01481d1 <.text.lock.readdir+5/54> Trace; c014815f Trace; c0147fd0 Trace; c0108deb Proc; spamd some >>EIP; f79a0000 <===== Trace; c013b6c8 <__wait_on_buffer+78/a0> Trace; c013e7db Trace; c013c9d6 Trace; c013cab4 Trace; c012ad79 Trace; c012ad94 Trace; c012af16 Trace; c012afab Trace; c014e0c4 Trace; c014ba86 Trace; c014bb58 Trace; c0145952 Trace; c0108deb Proc; spamd and rsync processes have this: >>EIP; e0cca000 <===== Trace; c0121af4 Trace; c020e15f Trace; c01485f6 Trace; c0148999 Trace; c0108deb Proc; rsync or this >>EIP; cfa9c000 <===== Trace; c0121af4 Trace; c020e15f Trace; c01485f6 Trace; c0148999 Trace; c0214312 Trace; c0108deb Proc; rsync Before I upgrade the kernel and move /home/spamc to an ext3 partition, is anyone aware of this kind of bug having been fixed in reiserfs (or elsewhere in kernel)? Has someone seen something like this? I can provide more info, in case anyone is interested. -- v -- v@iki.fi