From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?UGF3ZcWC?= Sikora Subject: Re: [2.6.38-3.x] [BUG] soft lockup - CPU#X stuck for 23s! (vfs, autofs, vserver) Date: Mon, 24 Sep 2012 07:23:55 +0200 Message-ID: <2819949.zde5vZ04eb@localhost> References: <5092540.GORQ1kUuNX@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, arekm@pld-linux.org, baggins@pld-linux.org, herbert@13thfloor.at To: Linus Torvalds Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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); >=20 > 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. >=20 > 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. >=20 > 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 avoi= d total soft-lockup? BR, Pawe=C5=82. ps). i'm adding Herbert to CC.