From: Herbert Poetzl Subject: Re: [2.6.38-3.x] [BUG] soft lockup - CPU#X stuck for 23s! (vfs, autofs, vserver) Date: Mon, 24 Sep 2012 13:23:00 +0200 Message-ID: <20120924112300.GE20655@MAIL.13thfloor.at> References: <5092540.GORQ1kUuNX@localhost> <2819949.zde5vZ04eb@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Linus Torvalds , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, arekm@pld-linux.org, baggins@pld-linux.org To: =?utf-8?B?UGF3ZcWC?= Sikora Return-path: Content-Disposition: inline In-Reply-To: <2819949.zde5vZ04eb@localhost> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Sep 24, 2012 at 07:23:55AM +0200, Pawe=C5=82 Sikora wrote: > On Sunday 23 of September 2012 18:10:30 Linus Torvalds wrote: >> On Sat, Sep 22, 2012 at 11:09 PM, Pawe=C5=82 Sikora wrote: >>> br_read_lock(vfsmount_lock); >> The vfsmount_lock is a "local-global" lock, where a read-lock >> is rather cheap and takes just a per-cpu lock, but the >> downside is that a write-lock is *very* expensive, and can >> cause serious trouble. >> And the write lock is taken by the [un]mount() paths. Do *not* >> do crazy things. If you do some insane "unmount and remount >> autofs" on a 1s granularity, you're doing insane things. >> Why do you have that 1s timeout? Insane. > 1s unmount timeout is *only* for fast bug reproduction (in few > seconds after opteron startup) and testing potential patches. > normally with 60s timeout it happens in few minutes..hours > (depends on machine i/o+cpu load) and makes server unusable > (permament soft-lockup). > can we redesign vserver's mnt_is_reachable() for better locking > to avoid total soft-lockup? currently we do: 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); and we have been considering to move the br_read_unlock() right before the is_subdir() call if there are any suggestions how to achieve the same with less locking I'm all ears ... best, Herbert > BR, > Pawe=C5=82. > ps). > i'm adding Herbert to CC.