From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?UGF3ZcWC?= Sikora Subject: [2.6.38-3.x] [BUG] soft lockup - CPU#X stuck for 23s! (vfs, autofs, vserver) Date: Sun, 23 Sep 2012 08:09:48 +0200 Message-ID: <5092540.GORQ1kUuNX@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org, torvalds@linux-foundation.org, arekm@pld-linux.org, baggins@pld-linux.org To: linux-kernel@vger.kernel.org Return-path: Received: from mail.agmk.net ([91.192.224.71]:53921 "EHLO mail.agmk.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753607Ab2IWGS5 convert rfc822-to-8bit (ORCPT ); Sun, 23 Sep 2012 02:18:57 -0400 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, a long time ago i reported an ugly soft lock of heavy loaded opteron sy= stem without usable backtraces :( recently, i've logged on 3.4.6 via serial console backtraces from all 1= 6 cores which show some kind of vfs lock (http://pluto.agmk.net/kernel/oops.txt). this lock occurs o= n heavy loaded system with frequent autofs unmount (timeout=3D1s) in action with vserver patch app= lied. i've isolated the vserver function that exposes problem: mnt_is_reachab= le() http://vserver.13thfloor.at/Experimental/patch-3.4.6-vs2.3.3.6.diff: static int mnt_is_reachable(struct vfsmount *vfsmnt) { struct path root; struct dentry *point; struct mount *mnt =3D real_mount(vfsmnt); struct mount *root_mnt; int ret; if (mnt =3D=3D mnt->mnt_ns->root) return 1; br_read_lock(vfsmount_lock); root =3D current->fs->root; root_mnt =3D real_mount(root.mnt); point =3D root.dentry; while ((mnt !=3D mnt->mnt_parent) && (mnt !=3D root_mnt)) { point =3D mnt->mnt_mountpoint; mnt =3D mnt->mnt_parent; } ret =3D (mnt =3D=3D root_mnt) && is_subdir(point, root.dentry); br_read_unlock(vfsmount_lock); return ret; } the vserver developer (Herbert Poetzl) said that locking scheme used in= this function looks correct, so it might be a hidden vfs bug accidentaly exposed by vserver patch. i= 'm not a kernel developer, so i'd like to ask you for help in solving this problem. afaics the pro= blem starts with 2.6.38 release which introduced some major vfs changes. please CC me on reply. BR, Pawe=C5=82. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html