DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=veFtohS2mkY7XV7dvmyLK6p+KldaMYqPHxeO/UeaUdAyl7PaF1kAY30tVwShjlFlmL
         G8X7emm6SsBGQG6+mCxtYuK0NQKE80IVxupFxw+5hbNTG4JppmFe8aIMsyINAtXUH9Te
         BJlXBNHEmszBtOVTjrJKobWVGgbaMAj4dyQFQ=
Message-ID: <cc7060690808071043r659aea9fn4e28959b3a62081e@mail.gmail.com>
Date: Thu, 7 Aug 2008 23:13:59 +0530
From: "Bhagi rathi" <jahnu77@gmail.com>
To: "Bhagi rathi" <jahnu77@gmail.com>, "Lachlan McIlroy" <lachlan@sgi.com>,
        xfs@oss.sgi.com
Subject: Re: TAKE 981498 - Use KM_NOFS for debug trace buffers
In-Reply-To: <20080806201957.GQ21635@disturbed>
MIME-Version: 1.0
References: <20080806061553.A8D8958C52A4@chook.melbourne.sgi.com>
	 <cc7060690808061012x43511581m15c794e72129becc@mail.gmail.com>
	 <20080806201957.GQ21635@disturbed>
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-length: 1490
Sender: xfs-bounce@oss.sgi.com
Errors-to: xfs-bounce@oss.sgi.com
Precedence: bulk

On Thu, Aug 7, 2008 at 1:49 AM, Dave Chinner <david@fromorbit.com> wrote:

> On Wed, Aug 06, 2008 at 10:42:15PM +0530, Bhagi rathi wrote:
> > I couldn't get a chance to read the diff's completely. If I click on
> > Lachlan's url for diff's, I couldn't access them. It looks to me that
> > the issue is not just with trace buffers. It can extend to xfs_iformat
> > as well. The same dead-lock can spring via
> >
> > xfs_iread -> xfs_iformat -> xfs_iformat_extents -> xfs_iext_add ->
> > xfs_iext_inline_to_direct -> which can do kmem_alloc with
> > KM_SLEEP flag.
>
> Fixed already:
>
>
> http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=8c6266658cb76e282c14cb92f8ba5a1c674f4928
>

 Thanks Dave. However, My concern is just not one allocation. We
 need to clean all allocations that can re-enter to file-system.
 I see that this issue exists in attributes format for i_afp allocations.
 It may exist with local format of data and attributes too.

 xfs_iread->xfs_iformat->xfs_iformat_local.

 Are we safe that we fixed all these real problems by looking
 into possible allocations that will enter into file-system? The
 problem with trace buffers is telling us to clean this code path.

 By the way, I browse the source code from lxr.linux.no.
 If I have to browse the latest xfs source code with linux
 kernel that is used at SGI, how can I do that?

 Cheers,
 Bhagi.

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>


[[HTML alternate version deleted]]