From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261815AbTJWRTj (ORCPT ); Thu, 23 Oct 2003 13:19:39 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263653AbTJWRTj (ORCPT ); Thu, 23 Oct 2003 13:19:39 -0400 Received: from hockin.org ([66.35.79.110]:27908 "EHLO www.hockin.org") by vger.kernel.org with ESMTP id S261815AbTJWRTi (ORCPT ); Thu, 23 Oct 2003 13:19:38 -0400 Date: Thu, 23 Oct 2003 10:09:42 -0700 From: Tim Hockin To: Mike Waychison Cc: Ian Kent , Ingo Oeser , Kernel Mailing List Subject: Re: [NFS] RE: [autofs] multiple servers per automount Message-ID: <20031023170942.GA2895@hockin.org> References: <3F980949.1040201@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F980949.1040201@sun.com> User-Agent: Mutt/1.4.1i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 23, 2003 at 01:00:57PM -0400, Mike Waychison wrote: > >Would a GFP_ATOMIC make a difference to the analysis? > Yes, sleeping within a spinlock is bad practice because it may > eventually deadlock. Pretend that the lock is taken, the call to > kmalloc is made, the mm system doesn't have any immidiately free memory > and through some flow of execution requires that a some pseudo-block > device backed filesystem needs to be mounted -> deadlock. I have no > idea if this is currently a likely scenario, however not sleeping within > a lock is 'The Right Thing' and should be avoided at all costs. it's worse than that. It's forbidden. It's a VERY likely deadlock scenario in the general sense, even if this particular case is not. If you need to lock something and you need to sleep holding that lock, use a semaphore. -- Notice that as computers are becoming easier and easier to use, suddenly there's a big market for "Dummies" books. Cause and effect, or merely an ironic juxtaposition of unrelated facts?