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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox