Received: by oss.sgi.com id ; Thu, 22 Feb 2001 11:30:10 -0800 Received: from deliverator.sgi.com ([204.94.214.10]:29807 "EHLO deliverator.sgi.com") by oss.sgi.com with ESMTP id ; Thu, 22 Feb 2001 11:29:54 -0800 Received: from madurai.engr.sgi.com (madurai.engr.sgi.com [163.154.5.75]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id LAA23291 for ; Thu, 22 Feb 2001 11:28:50 -0800 (PST) mail_from (ananth@sgi.com) Received: from sgi.com (mango.engr.sgi.com [163.154.5.76]) by madurai.engr.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA30944; Thu, 22 Feb 2001 11:23:46 -0800 (PST) Message-ID: <3A956800.A11C4AE3@sgi.com> Date: Thu, 22 Feb 2001 11:26:56 -0800 From: Rajagopal Ananthanarayanan X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-4SGI_20smp i686) X-Accept-Language: en MIME-Version: 1.0 To: Marcelo Tosatti CC: dcox@connex.com, Linux-XFS Subject: Re: Repeatable Panics with XFS and RAID1 (long) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-xfs-outgoing Marcelo Tosatti wrote: > > On Thu, 22 Feb 2001, Marcelo Tosatti wrote: > > > > I think allocating memory from the atomic queue (used mainly by in > > interrupt context) to generate dirty data may cause problems. > > I'll write the GFP_PAGE_IO thing we talked about RSN to avoid having to > use GFP_ATOMIC. Hi Marcelo, The particular allocation in question, the kmalloc in __pagebuf_write_full_page, is needed only to perform clustering. So, what's needed is a really cheap allocation; the code doesn't care if the allocation fails. I think the patch you sent avoids calling writepage out of page_launder() on GFP_PAGE_IO. This should work also. cheers, ananth. -- -------------------------------------------------------------------------- Rajagopal Ananthanarayanan ("ananth") Member Technical Staff, SGI. --------------------------------------------------------------------------