xfs
[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: Fri, 8 Aug 2008 10:46:56 +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=uS881Ku/WMmszhFp85i6Ktk/N/G7l+V5jMlPzvPD30A=; b=ZzJEvfN9PMl8hfvuaTuDlKOdui90pDWhSkPNx1wg3oOmLGFIMyQBXoOYConL/6/9ik Ycpq050bfiYo4DBn6CWXNzNxkKzCB169UE7o9oJ4sCD9UNs2+YjOZta1IM8tJmjAyxbw kJ9eB8wpxOMzlwzHupZ5RYcZMqlZH1GhUMKfQ=
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=h36oE/wFEL3A0g7f32fxDgj3hDUb8I84EbKKuOJ7/bZgAdQ39m/ywK5dpwpzKXSg1+ yCWwqMnIW7ho7BjgZQD97oqPZ/bZc8UpirusxRUkWsbin3v7q+oCBzcmnjK3hFDb9axD G3Sz99p1xliQE5Es4q4rm9yi/Fji5yPr2F910=
In-reply-to: <cc7060690808071043r659aea9fn4e28959b3a62081e@xxxxxxxxxxxxxx>
References: <20080806061553.A8D8958C52A4@xxxxxxxxxxxxxxxxxxxxxxx> <cc7060690808061012x43511581m15c794e72129becc@xxxxxxxxxxxxxx> <20080806201957.GQ21635@disturbed> <cc7060690808071043r659aea9fn4e28959b3a62081e@xxxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
On Thu, Aug 7, 2008 at 11:13 PM, Bhagi rathi <jahnu77@xxxxxxxxx> wrote:

>
>
> 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.
>
>  xfs_iread->xfs_iformat->xfs_iformat_local.
>

  Is the above issue fixed already? I see this existing in latest linux
  kernel.


>
>  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?
>

 Any pointers on this? I wish to setup my own xfs development enviroment
 and details on this will be helpful.

Cheers,
Bhagi.

>
>
>  Cheers,
>  Bhagi.
>
>>
>> Cheers,
>>
>> Dave.
>> --
>> Dave Chinner
>> david@xxxxxxxxxxxxx
>>
>
>


[[HTML alternate version deleted]]


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