jbd/jbd2 NULL noise
PATCH 1/1 jbd/jbd2 NULL noise
--- fs/jbd/journal.c | 4 ++-- fs/jbd/revoke.c | 4 ++-- fs/jbd2/journal.c | 12 ++++++------ fs/jbd2/revoke.c | 4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-)
fs/jbd/journal.c +2 -2
@@ -1620,14 +1620,14 @@ static int journal_init_journal_head_cache(void) {int retval; -J_ASSERT (journal_head_cache ==0 ); +J_ASSERT (journal_head_cache ==NULL ); journal_head_cache =kmem_cache_create ("journal_head" ,sizeof (struct journal_head ),0 ,/* offset */ SLAB_TEMPORARY ,/* flags */ NULL );/* ctor */ retval =0 ; -if (journal_head_cache ==0 ) { +if (!journal_head_cache) { retval = -ENOMEM ;printk (KERN_EMERG "JBD: no memory for journal_head cache\n" ); }
fs/jbd/revoke.c +2 -2
@@ -173,13 +173,13 @@ int __init journal_init_revoke_caches(void)0 ,SLAB_HWCACHE_ALIGN |SLAB_TEMPORARY , NULL); -if (revoke_record_cache ==0 ) +if (!revoke_record_cache)return -ENOMEM ; revoke_table_cache =kmem_cache_create ("revoke_table" ,sizeof (struct jbd_revoke_table_s ),0 ,SLAB_TEMPORARY ,NULL ); -if (revoke_table_cache ==0 ) { +if (!revoke_table_cache) {kmem_cache_destroy (revoke_record_cache); revoke_record_cache =NULL ;return -ENOMEM ;
fs/jbd2/journal.c +6 -6
@@ -219,7 +219,7 @@ static int jbd2_journal_start_thread(journal_t *journal)if (IS_ERR (t))return PTR_ERR (t); -wait_event (journal->j_wait_done_commit, journal->j_task !=0 ); +wait_event (journal->j_wait_done_commit, journal->j_task !=NULL );return 0 ; }
@@ -231,7 +231,7 @@ static void journal_kill_thread(journal_t *journal)while (journal->j_task) {wake_up (&journal->j_wait_commit);spin_unlock (&journal->j_state_lock); -wait_event (journal->j_wait_done_commit, journal->j_task ==0 ); +wait_event (journal->j_wait_done_commit, journal->j_task ==NULL );spin_lock (&journal->j_state_lock); }spin_unlock (&journal->j_state_lock);
@@ -1969,14 +1969,14 @@ static int journal_init_jbd2_journal_head_cache(void) {int retval; -J_ASSERT (jbd2_journal_head_cache ==0 ); +J_ASSERT (jbd2_journal_head_cache ==NULL ); jbd2_journal_head_cache =kmem_cache_create ("jbd2_journal_head" ,sizeof (struct journal_head ),0 ,/* offset */ SLAB_TEMPORARY ,/* flags */ NULL );/* ctor */ retval =0 ; -if (jbd2_journal_head_cache ==0 ) { +if (!jbd2_journal_head_cache) { retval = -ENOMEM ;printk (KERN_EMERG "JBD: no memory for journal_head cache\n" ); }
@@ -2002,14 +2002,14 @@ static struct journal_head *journal_alloc_journal_head(void)atomic_inc (&nr_journal_heads);#endif ret =kmem_cache_alloc (jbd2_journal_head_cache,GFP_NOFS ); -if (ret ==0 ) { +if (!ret) {jbd_debug (1 ,"out of memory for journal_head\n" );if (time_after (jiffies, last_warning +5 *HZ )) {printk (KERN_NOTICE "ENOMEM in %s, retrying.\n" , __FUNCTION__); last_warning = jiffies; } -while (ret ==0 ) { +while (!ret) {yield (); ret =kmem_cache_alloc (jbd2_journal_head_cache,GFP_NOFS ); }
fs/jbd2/revoke.c +2 -2
@@ -174,13 +174,13 @@ int __init jbd2_journal_init_revoke_caches(void)0 ,SLAB_HWCACHE_ALIGN |SLAB_TEMPORARY , NULL); -if (jbd2_revoke_record_cache ==0 ) +if (!jbd2_revoke_record_cache)return -ENOMEM ; jbd2_revoke_table_cache =kmem_cache_create ("jbd2_revoke_table" ,sizeof (struct jbd2_revoke_table_s ),0 ,SLAB_TEMPORARY ,NULL ); -if (jbd2_revoke_table_cache ==0 ) { +if (!jbd2_revoke_table_cache) {kmem_cache_destroy (jbd2_revoke_record_cache); jbd2_revoke_record_cache =NULL ;return -ENOMEM ;
Signature · 1 line
1.5.3.GIT
Quoted 8 lines · Al Viro
Signed-off-by Al Viro <[email protected]>--- fs/jbd/journal.c | 4 ++-- fs/jbd/revoke.c | 4 ++-- fs/jbd2/journal.c | 12 ++++++------ fs/jbd2/revoke.c | 4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-)
I had just about all of fs/ done for this sitting in mm.
Harvey
Quoted 11 lines · Harvey Harrison
Quoted 8 lines · Al Viro
Signed-off-by Al Viro <[email protected]>--- fs/jbd/journal.c | 4 ++-- fs/jbd/revoke.c | 4 ++-- fs/jbd2/journal.c | 12 ++++++------ fs/jbd2/revoke.c | 4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-)I had just about all of
fs/done for this sitting in mm.
So send it? I mean, that hardly has a potential to cause breakage - anything wrong will be immediately seen on build.
Quoted 11 lines · Al Viro
Quoted 10 lines · Harvey Harrison
Quoted 8 lines · Al Viro
Signed-off-by Al Viro <[email protected]>--- fs/jbd/journal.c | 4 ++-- fs/jbd/revoke.c | 4 ++-- fs/jbd2/journal.c | 12 ++++++------ fs/jbd2/revoke.c | 4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-)
Quoted 4 lines
Quoted 1 line
I had just about all of
fs/done for this sitting in mm.So send it? I mean, that hardly has a potential to cause breakage - anything wrong will be immediately seen on build.
I did, it went into -mm and on Mar 5 it was taken into the subsystem tree.
Harvey
Quoted 12 lines · Harvey Harrison
Quoted 11 lines · Al Viro
Quoted 10 lines · Harvey Harrison
Quoted 8 lines · Al Viro
Signed-off-by Al Viro <[email protected]>--- fs/jbd/journal.c | 4 ++-- fs/jbd/revoke.c | 4 ++-- fs/jbd2/journal.c | 12 ++++++------ fs/jbd2/revoke.c | 4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-)
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
I had just about all of
fs/done for this sitting in mm.So send it? I mean, that hardly has a potential to cause breakage - anything wrong will be immediately seen on build.
I did, it went into -mm and on Mar 5 it was taken into the subsystem tree.
Wait a minute... where had it been taken? What subsystem tree for "just about all of fs/"?
In any case, if the stuff above is covered by whatever went to whichever subsystem tree - by all means, discard that one.
Quoted 5 lines · Al Viro
Quoted 2 lines
I did, it went into -mm and on Mar 5 it was taken into the subsystem tree.
Wait a minute... where had it been taken? What subsystem tree for "just about all of
fs/"?
You've really got me curious. The latest -mm I can find is 2.6.25-rc5-mm1, it's dated Mar 11 and the patches are very much there - broken-out/jbd-sparse-warnings-in-revokec-journalc.patch and broken-out/jbd2-sparse-warnings-in-revokec-journalc.patch resp., all by themselves and not as a part of any subsystem tree.
Linus, consider the patch upthread withdrawn.
Al, still morbidly curious about the akpm's scripts and aforementioned message...
Quoted 14 lines · Al Viro
Quoted 5 lines · Al Viro
Quoted 2 lines
I did, it went into -mm and on Mar 5 it was taken into the subsystem tree.
Wait a minute... where had it been taken? What subsystem tree for "just about all of
fs/"?You've really got me curious. The latest -mm I can find is 2.6.25-rc5-mm1, it's dated Mar 11 and the patches are very much there -
broken-out/jbd-sparse-warnings-in-revokec-journalc.patchandbroken-out/jbd2-sparse-warnings-in-revokec-journalc.patchresp., all by themselves and not as a part of any subsystem tree.
Quoted 4 lines
Linus, consider the patch upthread withdrawn.
Al, still morbidly curious about the akpm's scripts and aforementioned message...
Not sure which tree, but received this on Feb 27:
The patch titled
jbd2: sparse warnings in revoke.c, journal.c
has been removed from the -mm tree. Its filename was
jbd2-sparse-warnings-in-revokec-journalc.patch
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at
http://userweb.kernel.org/~akpm/mmotm/
------------------------------------------------------
Subject: jbd2: sparse warnings in revoke.c, journal.c
From: Harvey Harrison <[email protected]>
fs/jbd2/revoke.c:177:34: warning: Using plain integer as NULL pointer fs/jbd2/revoke.c:183:33: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:222:2: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:222:2: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:234:3: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:234:3: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:1972:2: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:1979:33: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:2005:13: warning: Using plain integer as NULL pointer fs/jbd2/journal.c:2012:17: warning: Using plain integer as NULL pointer
Quoted 13 lines · Harvey Harrison
Quoted 4 lines
Quoted 1 line
Quoted 1 line
I did, it went into -mm and on Mar 5 it was taken into the subsystem
Al, still morbidly curious about the akpm's scripts and aforementioned message...
Not sure which tree, but received this on Feb 27:
The patch titled
jbd2: sparse warnings inrevoke.c,journal.c
has been removed from the -mm tree. Its filename was
jbd2-sparse-warnings-in-revokec-journalc.patch
Quoted 5 lines
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at
http://userweb.kernel.org/~akpm/mmotm/
Ah... jbd part of it is still there, jbd2 is *also* there, but it's got ext4-mm- prefix to filename. And looking at ext4.git, jbd2 side of that stuff *is* merged, so what the hell is it doing in a separate file? Looks like -mm has ext4 stuff not as a single patch (like it does for many other git trees) but split into individual changesets for some reason...
Anyway, as long as this stuff gets eventually merged...
Quoted 20 lines · Al Viro
Quoted 13 lines · Harvey Harrison
Quoted 4 lines
Quoted 1 line
Quoted 1 line
I did, it went into -mm and on Mar 5 it was taken into the subsystem
Al, still morbidly curious about the akpm's scripts and aforementioned message...
Not sure which tree, but received this on Feb 27:
The patch titled
jbd2: sparse warnings inrevoke.c,journal.c
has been removed from the -mm tree. Its filename was
jbd2-sparse-warnings-in-revokec-journalc.patchQuoted 5 lines
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at
http://userweb.kernel.org/~akpm/mmotm/
Quoted 8 lines
Ah... jbd part of it is still there, jbd2 is *also* there, but it's got ext4-mm- prefix to filename. And looking at ext4.git, jbd2 side of that stuff *is* merged, so what the hell is it doing in a separate file? Looks like -mm has ext4 stuff not as a single patch (like it does for many other git trees) but split into individual changesets for some reason...
Anyway, as long as this stuff gets eventually merged...
I'll go through your patches in the morning and see if you've changed anything that my patches didnt't (referring to you NULL noise patches).
I think I also did the drivers/media stuff, but I will look through it all tomorrow.
Harvey
Quoted 20 lines · On Sat, 29 Mar 2008 04:56:34 +0000 Al Viro <[email protected]> wrote:
Quoted 13 lines · Harvey Harrison
Quoted 4 lines
Quoted 1 line
Quoted 1 line
I did, it went into -mm and on Mar 5 it was taken into the subsystem
Al, still morbidly curious about the akpm's scripts and aforementioned message...
Not sure which tree, but received this on Feb 27:
The patch titled
jbd2: sparse warnings inrevoke.c,journal.c
has been removed from the -mm tree. Its filename was
jbd2-sparse-warnings-in-revokec-journalc.patchQuoted 5 lines
This patch was dropped because it was merged into mainline or a subsystem tree
The current -mm tree may be found at
http://userweb.kernel.org/~akpm/mmotm/
Quoted 7 lines
Ah... jbd part of it is still there, jbd2 is *also* there, but it's got ext4-mm- prefix to filename. And looking at ext4.git, jbd2 side of that stuff *is* merged, so what the hell is it doing in a separate file? Looks like -mm has ext4 stuff not as a single patch (like it does for many other git trees) but split into individual changesets for some reason...
Yup, -mm consists of
- 71 git trees (origin.patch plus 70 git-foo.patch) (some may be empty)
- The URL for each of these can be obtained from the first line of git-foo.patch, in http://userweb.kernel.org/~akpm/mmotm/
- Nine quilt trees, pulled from various opendirs
Sekkrit locations:
http://ozlabs.org/~rusty/kernel/rr-latest
http://www.kernel.org/pub/linux/kernel/people/kristen/pci-hotplug
ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/LATEST/broken-out/
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-01-driver-core
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-03-usb
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/gregkh-02-pci
http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/
ftp://ftp.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/
- squillions of other patches which are only in -mm.
Interesting factoid: -mm's series file was started on 1 Dec 2002 and is at its 16,231st revision. I'm surprised it hasn't worn out.
Quoted 11 lines · On Sat, 29 Mar 2008 03:18:43 +0000 Al Viro <[email protected]> wrote:
Quoted 10 lines · Harvey Harrison
Quoted 8 lines · Al Viro
Signed-off-by Al Viro <[email protected]>--- fs/jbd/journal.c | 4 ++-- fs/jbd/revoke.c | 4 ++-- fs/jbd2/journal.c | 12 ++++++------ fs/jbd2/revoke.c | 4 ++-- 4 files changed, 12 insertions(+), 12 deletions(-)
Quoted 4 lines
Quoted 1 line
I had just about all of
fs/done for this sitting in mm.So send it? I mean, that hardly has a potential to cause breakage - anything wrong will be immediately seen on build.
Still, it didn't meet my (and apparently Ted's) is-it-needed-in-late-rc criteria.
Quoted 7 lines
From a later email:
You've really got me curious. The latest -mm I can find is 2.6.25-rc5-mm1, it's dated Mar 11 and the patches are very much there -
broken-out/jbd-sparse-warnings-in-revokec-journalc.patchandbroken-out/jbd2-sparse-warnings-in-revokec-journalc.patchresp., all by themselves and not as a part of any subsystem tree.
The jbd2 one went into the ext4 tree.
Alas, -mm's are slow nowadays. Due to a combination of a) the difficulty of getting it all to compile, let alone boot on sevenish machines, and b) waning motivation due to me wondering why we merge so much new stuff when we've just written so many bugs.
My tree is always available at http://userweb.kernel.org/~akpm/mmotm/ - it's updated multiple times per day.
Quoted 3 lines
Al, still morbidly curious about the akpm's scripts and aforementioned message...
The jbd2 changes got moved into the ext4 tree at ftp://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-patches/LATEST/broken-out/ hence I dropped them from the mm-specific patches. I still have the patch, but it's now known as ext4-mm-jbd2-sparse-warnings-in-revokec-journalc.patch because Ted now owns it.
Quoted 1 line
Linus, consider the patch upthread withdrawn.
Whatever. As long as it got merged.