From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965082AbWD0Kdc (ORCPT ); Thu, 27 Apr 2006 06:33:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965083AbWD0Kdc (ORCPT ); Thu, 27 Apr 2006 06:33:32 -0400 Received: from srv5.dvmed.net ([207.36.208.214]:9894 "EHLO mail.dvmed.net") by vger.kernel.org with ESMTP id S965082AbWD0Kdc (ORCPT ); Thu, 27 Apr 2006 06:33:32 -0400 Message-ID: <44509DF8.20107@garzik.org> Date: Thu, 27 Apr 2006 06:33:28 -0400 From: Jeff Garzik User-Agent: Thunderbird 1.5 (X11/20060313) MIME-Version: 1.0 To: Miklos Szeredi CC: torvalds@osdl.org, linux-kernel@vger.kernel.org Subject: Re: [git patch] fuse fixes References: <444FD204.7040708@garzik.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Spam-Report: SpamAssassin version 3.1.1 on srv5.dvmed.net summary: Content analysis details: (-4.0 points, 5.0 required) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi wrote: >> This function is called from everywhere, and so, it looks like it should >> use SLAB_NOFS rather than SLAB_KERNEL. I would audit every GFP_KERNEL >> and SLAB_KERNEL usage, and consider replacing with SLAB_NOFS or GFP_NOFS. > > GFP_NOFS doesn't make much sense, since mm never calls back into FUSE > anyway: FUSE writes through the page-cache, and hence never dirties > any pages. > > I'll add a comment to fuse_request_alloc(). If you're using loop, particularly something insane like swapping over loop, "the path" will certainly want to know that its passing through the VFS layer, regardless of specific page cache behavior, AFAICS. Jeff