From: Dave Kleikamp <shaggy@austin.ibm.com>
To: Adrian Bunk <bunk@stusta.de>
Cc: JFS Discussion <jfs-discussion@www-124.southbury.usf.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [2.6 patch] jfs_metapage.c: remove an unused function
Date: Fri, 29 Oct 2004 09:11:45 -0500 [thread overview]
Message-ID: <1099059105.7480.7.camel@localhost> (raw)
In-Reply-To: <20041029001839.GK29142@stusta.de>
On Thu, 2004-10-28 at 19:18, Adrian Bunk wrote:
> The patch below removes an unused function from fs/jfs/jfs_metapage.c
>
> --- patch removed ---
I guess I had intended to call alloc_metapage when I wrote that code,
but I never did. This must have been my intent:
diff -urp linux.orig/fs/jfs/jfs_metapage.c linux/fs/jfs/jfs_metapage.c
--- linux.orig/fs/jfs/jfs_metapage.c 2004-10-29 08:55:16.670499440 -0500
+++ linux/fs/jfs/jfs_metapage.c 2004-10-29 08:56:35.603499800 -0500
@@ -289,7 +289,7 @@ again:
*/
mp = NULL;
if (JFS_IP(inode)->fileset == AGGREGATE_I) {
- mp = mempool_alloc(metapage_mempool, GFP_ATOMIC);
+ mp = alloc_metapage(1);
if (!mp) {
/*
* mempool is supposed to protect us from
@@ -306,7 +306,7 @@ again:
struct metapage *mp2;
spin_unlock(&meta_lock);
- mp = mempool_alloc(metapage_mempool, GFP_NOFS);
+ mp = alloc_metapage(0);
spin_lock(&meta_lock);
/* we dropped the meta_lock, we need to search the
It seems cleaner to call alloc_metapage, since we have a corresponding
free_metapage, but this version is less cryptic:
diff -urp linux.orig/fs/jfs/jfs_metapage.c linux/fs/jfs/jfs_metapage.c
--- linux.orig/fs/jfs/jfs_metapage.c 2004-10-29 08:55:16.670499440 -0500
+++ linux/fs/jfs/jfs_metapage.c 2004-10-29 09:01:24.560571648 -0500
@@ -108,9 +108,9 @@ static void init_once(void *foo, kmem_ca
}
}
-static inline struct metapage *alloc_metapage(int no_wait)
+static inline struct metapage *alloc_metapage(int gfp_mask)
{
- return mempool_alloc(metapage_mempool, no_wait ? GFP_ATOMIC : GFP_NOFS);
+ return mempool_alloc(metapage_mempool, gfp_mask);
}
static inline void free_metapage(struct metapage *mp)
@@ -289,7 +289,7 @@ again:
*/
mp = NULL;
if (JFS_IP(inode)->fileset == AGGREGATE_I) {
- mp = mempool_alloc(metapage_mempool, GFP_ATOMIC);
+ mp = alloc_metapage(GFP_ATOMIC);
if (!mp) {
/*
* mempool is supposed to protect us from
@@ -306,7 +306,7 @@ again:
struct metapage *mp2;
spin_unlock(&meta_lock);
- mp = mempool_alloc(metapage_mempool, GFP_NOFS);
+ mp = alloc_metapage(GFP_NOFS);
spin_lock(&meta_lock);
/* we dropped the meta_lock, we need to search the
--
Dave Kleikamp
IBM Linux Technology Center
shaggy@austin.ibm.com
prev parent reply other threads:[~2004-10-29 14:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-28 22:24 [2.6 patch] jfs_metapage.c: remove an unused function Adrian Bunk
2004-10-29 0:18 ` Adrian Bunk
2004-10-29 14:11 ` Dave Kleikamp [this message]
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=1099059105.7480.7.camel@localhost \
--to=shaggy@austin.ibm.com \
--cc=bunk@stusta.de \
--cc=jfs-discussion@www-124.southbury.usf.ibm.com \
--cc=linux-kernel@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.