From: Matthew Wilcox <willy@debian.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Petr Vandrovec <vandrove@vc.cvut.cz>, linux-kernel@vger.kernel.org
Subject: [PATCH] Remove GFP_NFS
Date: Thu, 26 Sep 2002 19:25:44 +0100 [thread overview]
Message-ID: <20020926192544.E28188@parcelfarce.linux.theplanet.co.uk> (raw)
GFP_NFS means the same as GFP_KERNEL these days and it's only used
by ncpfs. Looks like copy & paste from NFS code which has now changed
to using the page cache. So I think we should eliminate GFP_NFS.
diff -urpNX dontdiff linux-2.5.33/fs/ncpfs/symlink.c linux-2.5.33-willy/fs/ncpfs/symlink.c
--- linux-2.5.33/fs/ncpfs/symlink.c 2002-09-04 07:20:56.000000000 -0600
+++ linux-2.5.33-willy/fs/ncpfs/symlink.c 2002-09-09 06:29:03.000000000 -0600
@@ -49,7 +49,7 @@ static int ncp_symlink_readpage(struct f
char *buf = kmap(page);
error = -ENOMEM;
- rawlink=(char *)kmalloc(NCP_MAX_SYMLINK_SIZE, GFP_NFS);
+ rawlink=(char *)kmalloc(NCP_MAX_SYMLINK_SIZE, GFP_KERNEL);
if (!rawlink)
goto fail;
@@ -126,7 +126,7 @@ int ncp_symlink(struct inode *dir, struc
/* EPERM is returned by VFS if symlink procedure does not exist */
return -EPERM;
- rawlink=(char *)kmalloc(NCP_MAX_SYMLINK_SIZE, GFP_NFS);
+ rawlink=(char *)kmalloc(NCP_MAX_SYMLINK_SIZE, GFP_KERNEL);
if (!rawlink)
return -ENOMEM;
diff -urpNX dontdiff linux-2.5.33/include/linux/gfp.h linux-2.5.33-willy/include/linux/gfp.h
--- linux-2.5.33/include/linux/gfp.h 2002-09-04 07:21:06.000000000 -0600
+++ linux-2.5.33-willy/include/linux/gfp.h 2002-09-09 06:27:59.000000000 -0600
@@ -25,7 +25,6 @@
#define GFP_USER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
#define GFP_HIGHUSER ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS | __GFP_HIGHMEM)
#define GFP_KERNEL ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
-#define GFP_NFS ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
#define GFP_KSWAPD ( __GFP_WAIT | __GFP_IO | __GFP_HIGHIO | __GFP_FS)
/* Flag - indicates that the buffer will be suitable for DMA. Ignored on some
diff -urpNX dontdiff linux-2.5.33/include/linux/slab.h linux-2.5.33-willy/include/linux/slab.h
--- linux-2.5.33/include/linux/slab.h 2002-08-02 05:44:53.000000000 -0600
+++ linux-2.5.33-willy/include/linux/slab.h 2002-09-09 06:28:31.000000000 -0600
@@ -21,7 +21,6 @@ typedef struct kmem_cache_s kmem_cache_t
#define SLAB_ATOMIC GFP_ATOMIC
#define SLAB_USER GFP_USER
#define SLAB_KERNEL GFP_KERNEL
-#define SLAB_NFS GFP_NFS
#define SLAB_DMA GFP_DMA
#define SLAB_LEVEL_MASK (__GFP_WAIT|__GFP_HIGH|__GFP_IO|__GFP_HIGHIO|__GFP_FS)
--
Revolutions do not require corporate support.
next reply other threads:[~2002-09-26 18:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-26 18:25 Matthew Wilcox [this message]
-- strict thread matches above, loose matches on Subject: below --
2002-09-09 14:37 [PATCH] remove GFP_NFS Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020926192544.E28188@parcelfarce.linux.theplanet.co.uk \
--to=willy@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=vandrove@vc.cvut.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).