[Top] [All Lists]

Re: TAKE 981498 - Use KM_NOFS for debug trace buffers

To: "Bhagi rathi" <jahnu77@xxxxxxxxx>, "Lachlan McIlroy" <lachlan@xxxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: TAKE 981498 - Use KM_NOFS for debug trace buffers
From: "Bhagi rathi" <jahnu77@xxxxxxxxx>
Date: Thu, 7 Aug 2008 23:13:59 +0530
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type:references; bh=7Du/9PYAokNN1B0xzaiQSj2YTI/oMwp+E8V+S15Dhe0=; b=KN9kxexnKlGOQpKJgRY8arsu6saJLVCWuRy6oQskG4AzasQh/WtJDeTAULRsvLB8fm HA6P3aD5ZjfoLjeHwx6K12w8+FNRGJZdTluP63O3iTCAQpGX/UBTiMPLukGbx7xmLf5p +6aB4O387OrptRkF/rmz6vlRYQex7nLDvGQL8=
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=
In-reply-to: <20080806201957.GQ21635@disturbed>
References: <20080806061553.A8D8958C52A4@xxxxxxxxxxxxxxxxxxxxxxx> <cc7060690808061012x43511581m15c794e72129becc@xxxxxxxxxxxxxx> <20080806201957.GQ21635@disturbed>
Sender: xfs-bounce@xxxxxxxxxxx
On Thu, Aug 7, 2008 at 1:49 AM, Dave Chinner <david@xxxxxxxxxxxxx> 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.


 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,
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx

[[HTML alternate version deleted]]

<Prev in Thread] Current Thread [Next in Thread>