Fix JFFS2 sync silent failure
Subsystems (4)
PATCH 1/1 Fix JFFS2 sync silent failure
Moin David,
if I read the code correctly, JFFS2 will happily perform a NOP on sys_sync() again. And this time it appears to be Jens' fault.
JFFS2 does not appear to set s_bdi anywhere. And as of 32a88aa1, __sync_filesystem() will return 0 if s_bdi is not set. As a result, sync_fs() is never called for jffs2 and whatever remains in the wbuf will not make it to the device.
The patch also adds a BUG_ON to catch this problem in any remaining or future offenders. I am not sure about network filesystems, but at least bdev- and mtd-based ones should be caught.
Opinions?
Jörn
Signature · 3 lines
No art, however minor, demands less than total dedication if you want to excel in it. -- Leon Battista Alberti
drivers/mtd/mtdsuper.c +2 -0
@@ -13,6 +13,7 @@#include <linux/mtd/super.h> #include <linux/namei.h> #include <linux/ctype.h> +#include <linux/slab.h> /* * compare superblocks to see if they're equivalent
@@ -44,6 +45,7 @@ static int get_sb_mtd_set(struct super_block *sb, void *_mtd) sb->s_mtd = mtd; sb->s_dev =MKDEV (MTD_BLOCK_MAJOR , mtd->index); + sb->s_bdi = mtd->backing_dev_info;return 0 ; }
fs/super.c +5 -3
@@ -954,10 +954,12 @@ vfs_kern_mount(struct file_system_type *type, int flags, const char *name, voidif (error <0 ) goto out_free_secdata;BUG_ON (!mnt->mnt_sb); +BUG_ON (!mnt->mnt_sb->s_bdi && + (mnt->mnt_sb->s_bdev || mnt->mnt_sb->s_mtd)); - error =security_sb_kern_mount (mnt->mnt_sb, flags, secdata); -if (error) - goto out_sb; + error =security_sb_kern_mount (mnt->mnt_sb, flags, secdata); +if (error) + goto out_sb;/* * filesystems should never set s_maxbytes larger than MAX_LFS_FILESIZE
Quoted 10 lines · Jörn Engel
Moin David,
if I read the code correctly, JFFS2 will happily perform a NOP on
sys_sync()again. And this time it appears to be Jens' fault.JFFS2 does not appear to set
s_bdianywhere. And as of32a88aa1,__sync_filesystem()will return 0 ifs_bdiis not set. As a result,sync_fs()is never called for jffs2 and whatever remains in the wbuf will not make it to the device.
Quoted 5 lines
The patch also adds a
BUG_ONto catch this problem in any remaining or future offenders. I am not sure about network filesystems, but at least bdev- and mtd-based ones should be caught.Opinions?
I think that BUG_ON() would be a lot better as a printk() and fail mount instead. There's really little point in killing the kernel for something you could easily warn about and recover nicely.
Signature · 1 line
Jens Axboe
Quoted 15 lines · Jens Axboe
Quoted 14 lines · Jörn Engel
Moin David,
if I read the code correctly, JFFS2 will happily perform a NOP on
sys_sync()again. And this time it appears to be Jens' fault.JFFS2 does not appear to set
s_bdianywhere. And as of32a88aa1,__sync_filesystem()will return 0 ifs_bdiis not set. As a result,sync_fs()is never called for jffs2 and whatever remains in the wbuf will not make it to the device.The patch also adds a
BUG_ONto catch this problem in any remaining or future offenders. I am not sure about network filesystems, but at least bdev- and mtd-based ones should be caught.
Quoted 5 lines
Quoted 1 line
Opinions?
I think that
BUG_ON()would be a lot better as aprintk()and fail mount instead. There's really little point in killing the kernel for something you could easily warn about and recover nicely.
*shrug*
The BUG_ON directly above is not qualitatively different. In both cases the only solution is to find and fix the bug in some other file, recompile and try again. But ultimately I don't care, as long as we catch the bug before people lose their data.
Feel free to respin this patch. You caused the problem in the first place. ;)
For the record, while I consider the two-liner that causes this mess a real turd, the rest of your patch was brilliant. A shame I didn't catch this earlier.
Jörn
Signature · 4 lines
You ain't got no problem, Jules. I'm on the motherfucker. Go back in there, chill them niggers out and wait for the Wolf, who should be coming directly. -- Marsellus Wallace
Quoted 28 lines · Jörn Engel
Quoted 15 lines · Jens Axboe
Quoted 14 lines · Jörn Engel
Moin David,
if I read the code correctly, JFFS2 will happily perform a NOP on
sys_sync()again. And this time it appears to be Jens' fault.JFFS2 does not appear to set
s_bdianywhere. And as of32a88aa1,__sync_filesystem()will return 0 ifs_bdiis not set. As a result,sync_fs()is never called for jffs2 and whatever remains in the wbuf will not make it to the device.The patch also adds a
BUG_ONto catch this problem in any remaining or future offenders. I am not sure about network filesystems, but at least bdev- and mtd-based ones should be caught.Quoted 5 lines
Quoted 1 line
Opinions?
I think that
BUG_ON()would be a lot better as aprintk()and fail mount instead. There's really little point in killing the kernel for something you could easily warn about and recover nicely.*shrug*
TheBUG_ONdirectly above is not qualitatively different. In both cases the only solution is to find and fix the bug in some other file, recompile and try again. But ultimately I don't care, as long as we catch the bug before people lose their data.
Quoted 6 lines
Feel free to respin this patch. You caused the problem in the first place. ;)
For the record, while I consider the two-liner that causes this mess a real turd, the rest of your patch was brilliant. A shame I didn't catch this earlier.
Thanks, we definitely should have put a debug statement to catch this in from day 1, good debugging should be an important part of any new infrastructure.
Care to send your jffs2 patch separately to David? Then I'll commit a modified variant for complaining about missing ->s_bdi on mount.
Signature · 1 line
Jens Axboe
Quoted 3 lines · Jens Axboe
Care to send your jffs2 patch separately to David? Then I'll commit a modified variant for complaining about missing ->s_bdi on mount.
Sure.
David, this patch is untested. It looks trivially correct and fixes a nasty bug, but I don't test jffs2 and only noticed the problem in passing.
Jörn
Signature · 4 lines
Maintenance in other professions and of other articles is concerned with the return of the item to its original state; in Software, maintenance is concerned with moving an item away from its original state. -- Les Belady
drivers/mtd/mtdsuper.c +1 -0
@@ -44,6 +45,7 @@ static int get_sb_mtd_set(struct super_block *sb, void *_mtd) sb->s_mtd = mtd; sb->s_dev =MKDEV (MTD_BLOCK_MAJOR , mtd->index); + sb->s_bdi = mtd->backing_dev_info;return 0 ; }
Quoted 4 lines · Jens Axboe
Thanks, we definitely should have put a debug statement to catch this in from day 1, good debugging should be an important part of any new infrastructure.
Woke up early and had another look at this. Looks like a much more widespread problem. Based on a quick grep an uncaffeinated brain:
9p no s_bdi
afs no s_bdi
ceph creates its own s_bdi
cifs no s_bdi
coda no s_bdi
ecryptfs no s_bdi
exofs no s_bdi
fuse creates its own s_bdi?
gfs2 creates its own s_bdi?
jffs2 patch exists
logfs fixed now
ncpfs no s_bdi
nfs creates its own s_bdi
ocfs2 no s_bdi
smbfs no s_bdi
ubifs creates its own s_bdi
I excluded all filesystems that appear to be read-only, block device based or lack any sort of backing store. So there is a chance I have missed some as well.
Jörn
Signature · 2 lines
Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra
Linus,
I think this is bad enough that you should be involved. 32a88aa1 broke a number of filesystems in a way that sync() would return 0 without doing any work. Even politicians are better at keeping the promises.
This is caused by the two-liner in __sync_filesystem:
if (!sb->s_bdi) return 0;
s_bdi is set implicitly for all filesystems using set_bdev_super(), so most block device based filesystems are safe. There are, however, a number of odd-balls around:
Quoted 17 lines · Jörn Engel
9p no
s_bdi
afs nos_bdi
ceph creates its owns_bdi
cifs nos_bdi
coda nos_bdi
ecryptfs nos_bdi
exofs nos_bdi
fuse creates its owns_bdi?
gfs2 creates its owns_bdi?
jffs2 patch exists
logfs fixed now
ncpfs nos_bdi
nfs creates its owns_bdi
ocfs2 nos_bdi
smbfs nos_bdi
ubifs creates its owns_bdi
Obviously this list should get checked and all affected filesystems get repaired. Additionally we should add an assertion and BUG() or refuse to mount or something. My original patch to that extend was this:
fs/super.c +2 -0
@@ -954,6 +954,8 @@ vfs_kern_mount(struct file_system_type *type, int flags, const char *name, voidif (error <0 ) goto out_free_secdata;BUG_ON (!mnt->mnt_sb); +BUG_ON (!mnt->mnt_sb->s_bdi && + (mnt->mnt_sb->s_bdev || mnt->mnt_sb->s_mtd)); error =security_sb_kern_mount (mnt->mnt_sb, flags, secdata);if (error)
goto out_sb;
The real problem is finding a condition that has neither false positives nor false negatives. The "(mnt->mnt_sb->s_bdev || mnt->mnt_sb->s_mtd)" part takes care of false positives like tmpfs, but it would catch none of the network filesystems. Should we instead annotate tmpfs and friends with something like sb->s_dont_need_bdi? It is the only way I can think of not to miss something.
Jörn
Signature · 3 lines
People will accept your ideas much more readily if you tell them that Benjamin Franklin said it first. -- unknown
Quoted 11 lines · Jörn Engel
I think this is bad enough that you should be involved.
32a88aa1broke a number of filesystems in a way thatsync()would return 0 without doing any work. Even politicians are better at keeping the promises.This is caused by the two-liner in
__sync_filesystem:if (!sb->s_bdi) return 0;
s_bdiis set implicitly for all filesystems usingset_bdev_super(), so most block device based filesystems are safe. There are, however, a number of odd-balls around:
Umm. Why not just remove the two-liner? It was incorrect. The comment says "this should be safe", and if it wasn't, then the commit that caused this all was total crap to begin with.
Why even discuss any other measures?
Linus
Quoted 4 lines · Linus Torvalds
Umm. Why not just remove the two-liner? It was incorrect. The comment says "this should be safe", and if it wasn't, then the commit that caused this all was total crap to begin with.
Grr. Ok, so we do need it. Because Jens made it not work without it, and didn't fix up the filesystems, just added a random comment saying "we shouldn't need to".
Double-grr. I hate misleading comments. It makes the patch and the code look like people knew what they were doing.
Jens - please help fix this up.
Linus
Quoted 8 lines · Linus Torvalds
Quoted 4 lines · Linus Torvalds
Umm. Why not just remove the two-liner? It was incorrect. The comment says "this should be safe", and if it wasn't, then the commit that caused this all was total crap to begin with.
Quoted 6 lines
Grr. Ok, so we do need it. Because Jens made it not work without it, and didn't fix up the filesystems, just added a random comment saying "we shouldn't need to".
Double-grr. I hate misleading comments. It makes the patch and the code look like people knew what they were doing.
Yeah sorry, that part was apparently not well thought through. It did go through review and testing, but at least the latter was not good enough.
Quoted 1 line
Jens - please help fix this up.
Of course, I already posted a series of patches to fix this up. I want to test them a bit, and I'll send them in tomorrow.
Signature · 1 line
Jens Axboe
PATCH 1/1 Catch filesystems lacking s_bdi
Quoted 5 lines · Jens Axboe
Quoted 2 lines
Jens - please help fix this up.
Of course, I already posted a series of patches to fix this up. I want to test them a bit, and I'll send them in tomorrow.
How about something like this to catch future cases? It compiles and survived a test boot, so it does seem to work for the common cases like tmpfs, procfs, etc.
Jens, you know the bdi code 10x better than me, would this work?
Jörn
Signature · 9 lines
ticks = jiffies; while (ticks == jiffies); ticks = jiffies; -- /usr/src/linux/init/main.c noop_backing_dev_info is used only as a flag to mark filesystems that don't have any backing store, like tmpfs, procfs, spufs, etc. Signed-off-by: Joern Engel <[email protected]>
fs/super.c +5 -3
@@ -693,6 +693,7 @@ int set_anon_super(struct super_block *s, void *data)return -EMFILE ; } s->s_dev =MKDEV (0 , dev &MINORMASK ); + s->s_bdi = &noop_backing_dev_info;return 0 ; }
@@ -954,10 +955,11 @@ vfs_kern_mount(struct file_system_type *type, int flags, const char *name, voidif (error <0 ) goto out_free_secdata;BUG_ON (!mnt->mnt_sb); +BUG_ON (!mnt->mnt_sb->s_bdi); - error =security_sb_kern_mount (mnt->mnt_sb, flags, secdata); -if (error) - goto out_sb; + error =security_sb_kern_mount (mnt->mnt_sb, flags, secdata); +if (error) + goto out_sb;/* * filesystems should never set s_maxbytes larger than MAX_LFS_FILESIZE
fs/sync.c +2 -1
@@ -14,6 +14,7 @@#include <linux/pagemap.h> #include <linux/quotaops.h> #include <linux/buffer_head.h> +#include <linux/backing-dev.h> #include "internal.h" #define VALID_FLAGS (SYNC_FILE_RANGE_WAIT_BEFORE|SYNC_FILE_RANGE_WRITE| \
@@ -32,7 +33,7 @@ static int __sync_filesystem(struct super_block *sb, int wait)* This should be safe, as we require bdi backing to actually * write out data in the first place */ -if (!sb->s_bdi) +if (!sb->s_bdi || sb->s_bdi == &noop_backing_dev_info)return 0 ;if (sb->s_qcop && sb->s_qcop->quota_sync)
include/linux/backing-dev.h +1 -0
@@ -246,6 +246,7 @@ int bdi_set_max_ratio(struct backing_dev_info *bdi, unsigned int max_ratio);#endif extern struct backing_dev_info default_backing_dev_info; +extern struct backing_dev_info noop_backing_dev_info;void default_unplug_io_fn (struct backing_dev_info *bdi,struct page *page);int writeback_in_progress (struct backing_dev_info *bdi);
mm/backing-dev.c +5 -0
@@ -25,6 +25,11 @@ struct backing_dev_info default_backing_dev_info = { };EXPORT_SYMBOL_GPL (default_backing_dev_info); +struct backing_dev_info noop_backing_dev_info = { + .name ="noop" , +}; +EXPORT_SYMBOL_GPL (noop_backing_dev_info); +static struct class *bdi_class;/*
Re: [Patch] Catch filesystems lacking s_bdi
Quoted 4 lines · Jörn Engel
Quoted 3 lines · Jens Axboe
Quoted 2 lines
Jens - please help fix this up.
Quoted 8 lines
Quoted 2 lines
Of course, I already posted a series of patches to fix this up. I want to test them a bit, and I'll send them in tomorrow.
How about something like this to catch future cases? It compiles and survived a test boot, so it does seem to work for the common cases like tmpfs, procfs, etc.
Jens, you know the bdi code 10x better than me, would this work?
Looks sane, it's a good start. I think we should augment that with a check to ensure that we don't ever add dirty inodes to this bdi, since it's not going to be flushed.
Something like a:
WARN_ON(bdi == &noop_backing_dev_info);
to __mark_inode_dirty(). Looking at the code it should already trigger a warning, since it'll check for BDI_CAP_NO_WRITEBACK (which isn't set for noop_backing_dev_info) and the fact that noop-bdi isn't registered to begin with.
So it's probably safe and good enough as-is, I'll add it. Thanks!
Signature · 1 line
Jens Axboe
Re: [Patch] Catch filesystems lacking s_bdi
Quoted 2 lines · Jens Axboe
So it's probably safe and good enough as-is, I'll add it. Thanks!
I cannot see this patch in your tree yet. Could be the weekend or a deliberate decision not to send this for 2.6.34-rc anymore.
In case it was a deliberate decision, can we please make it explicit? I don't like the idea of adding a BUG_ON() that potentially triggers for thousands of people this late in the stabilization process - but it is better than having people lose data. Even if we already ran two stable kernels that way.
Damned if you do, damned if you don't. :(
Jörn
Signature · 2 lines
Time? What's that? Time is only worth what you do with it. -- Theo de Raadt
Re: [Patch] Catch filesystems lacking s_bdi
Quoted 6 lines · Jörn Engel
Quoted 2 lines · Jens Axboe
So it's probably safe and good enough as-is, I'll add it. Thanks!
I cannot see this patch in your tree yet. Could be the weekend or a deliberate decision not to send this for 2.6.34-rc anymore.
It's there, I put it in yesterday. It's definitely 2.6.34-rc material, I hope to submit it tonight.
Quoted 7 lines
In case it was a deliberate decision, can we please make it explicit? I don't like the idea of adding a
BUG_ON()that potentially triggers for thousands of people this late in the stabilization process - but it is better than having people lose data. Even if we already ran two stable kernels that way.Damned if you do, damned if you don't. :(
Yeah, it's a bad situation to be in. I changed that BUG_ON() to a WARN_ON(). I'm not too worried about that part, I'm more worried about the file system changed. OTOH, they do lack proper flushing now, so it's likely not a huge risk from that perspective.
Signature · 1 line
Jens Axboe
Re: [Patch] Catch filesystems lacking s_bdi
Quoted 10 lines · Jens Axboe
Quoted 6 lines · Jörn Engel
Quoted 2 lines · Jens Axboe
So it's probably safe and good enough as-is, I'll add it. Thanks!
I cannot see this patch in your tree yet. Could be the weekend or a deliberate decision not to send this for 2.6.34-rc anymore.
It's there, I put it in yesterday. It's definitely 2.6.34-rc material, I hope to submit it tonight.
Ok, thanks.
Quoted 6 lines
Quoted 6 lines
In case it was a deliberate decision, can we please make it explicit? I don't like the idea of adding a
BUG_ON()that potentially triggers for thousands of people this late in the stabilization process - but it is better than having people lose data. Even if we already ran two stable kernels that way.
Quoted 6 lines
Quoted 1 line
Damned if you do, damned if you don't. :(
Yeah, it's a bad situation to be in. I changed that
BUG_ON()to aWARN_ON(). I'm not too worried about that part, I'm more worried about the file system changed. OTOH, they do lack proper flushing now, so it's likely not a huge risk from that perspective.
It is worse still. Using mtd->backing_dev_info results in kernel BUG at fs/fs-writeback.c:157
which is BUG_ON(!work->seen); in bdi_queue_work(). Logfs is affected and I bet jffs2 is as well. So much for dwmw2 or me actually testing the fix. :(
I did a hexdump to see what sb->s_bdi actually contained and the result was this:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ........
Which should be mtd_bdi_unmappable. And at this point I have to admit being clueless. What exactly should a struct backing_dev_info contain and for what purposes? And where is this documented?
Jörn
Signature · 3 lines
He who knows others is wise. He who knows himself is enlightened. -- Lao Tsu
Re: [Patch] Catch filesystems lacking s_bdi
Quoted 60 lines · Jörn Engel
Quoted 4 lines
Yeah, it's a bad situation to be in. I changed that
BUG_ON()to aWARN_ON(). I'm not too worried about that part, I'm more worried about the file system changed. OTOH, they do lack proper flushing now, so it's likely not a huge risk from that perspective.It is worse still. Using
mtd->backing_dev_inforesults in kernel BUG atfs/fs-writeback.c:157which is
BUG_ON(!work->seen); inbdi_queue_work(). Logfs is affected and I bet jffs2 is as well. So much for dwmw2 or me actually testing the fix. :(I did a hexdump to see what
sb->s_bdiactually contained and the result was this:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ........
Quoted 3 lines
Which should be
mtd_bdi_unmappable. And at this point I have to admit being clueless. What exactly should a structbacking_dev_infocontain and for what purposes? And where is this documented?
The important bit is that each bdi must be initialized and registered if it's going to be handling dirty data, it can't just be a static placeholder. See the bdi_setup_and_register() helper I added.
Signature · 1 line
Jens Axboe
Re: [Patch] Catch filesystems lacking s_bdi
Quoted 61 lines · Jens Axboe
Quoted 60 lines · Jörn Engel
Quoted 4 lines
Yeah, it's a bad situation to be in. I changed that
BUG_ON()to aWARN_ON(). I'm not too worried about that part, I'm more worried about the file system changed. OTOH, they do lack proper flushing now, so it's likely not a huge risk from that perspective.It is worse still. Using
mtd->backing_dev_inforesults in kernel BUG atfs/fs-writeback.c:157which is
BUG_ON(!work->seen); inbdi_queue_work(). Logfs is affected and I bet jffs2 is as well. So much for dwmw2 or me actually testing the fix. :(I did a hexdump to see what
sb->s_bdiactually contained and the result was this:00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 ........
Quoted 7 lines
Quoted 3 lines
Which should be
mtd_bdi_unmappable. And at this point I have to admit being clueless. What exactly should a structbacking_dev_infocontain and for what purposes? And where is this documented?The important bit is that each bdi must be initialized and registered if it's going to be handling dirty data, it can't just be a static placeholder. See the
bdi_setup_and_register()helper I added.
Took a quick look, and you want bdi_setup_and_register() for the three bdis listed in mtdbdi.c in mtdcore.c:init_mtd(). Or manual bdi_init() and bdi_register(). I'll take a look post-dinner. Either is workable, but since the flags are already setup, the latter may be cleaner.
Signature · 1 line
Jens Axboe
PATCH 1/2 Move mtd_bdi_*mappable to mtdcore.c
Quoted 5 lines · Jens Axboe
Took a quick look, and you want
bdi_setup_and_register()for the three bdis listed inmtdbdi.cin mtdcore.c:init_mtd(). Or manualbdi_init()andbdi_register(). I'll take a look post-dinner. Either is workable, but since the flags are already setup, the latter may be cleaner.
Ok, here are two patches that appear to solve the problem for me.
Jörn
Signature · 15 lines
Courage is not the absence of fear, but rather the judgement that something else is more important than fear. -- Ambrose Redmoon Removes one .h and one .c file that are never used outside of mtdcore.c. Signed-off-by: Joern Engel <[email protected]> --- drivers/mtd/Makefile | 2 +- drivers/mtd/devices/drais.c | 2 +- drivers/mtd/internal.h | 17 ----------------- drivers/mtd/mtdbdi.c | 43 ------------------------------------------- drivers/mtd/mtdcore.c | 33 ++++++++++++++++++++++++++++++++- 5 files changed, 34 insertions(+), 63 deletions(-)
drivers/mtd/Makefile +1 -1
@@ -4,7 +4,7 @@ # Core functionality. obj-$(CONFIG_MTD) += mtd.o -mtd-y := mtdcore.o mtdsuper.o mtdbdi.o +mtd-y := mtdcore.o mtdsuper.o mtd-$(CONFIG_MTD_PARTITIONS) += mtdpart.o obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
drivers/mtd/devices/drais.c +1 -1
@@ -33,7 +33,7 @@#include <linux/sched.h> #include "drais.h" -#undef DEBUG_ERASE +#define DEBUG_ERASE #define DRAIS_BB_MAGIC 0x3911b26ba5a931d8ull
drivers/mtd/internal.h +0 -17
@@ -1,17 +0,0 @@ -/* Internal MTD definitions -* -* Copyright © 2006 Red Hat, Inc. All Rights Reserved. -* Written by David Howells ([email protected]) -* -* This program is free software; you can redistribute it and/or -* modify it under the terms of the GNU General Public License -* as published by the Free Software Foundation; either version -* 2 of the License, or (at your option) any later version. -*/ - -/* -* mtdbdi.c -*/ -extern struct backing_dev_info mtd_bdi_unmappable; -extern struct backing_dev_info mtd_bdi_ro_mappable; -extern struct backing_dev_info mtd_bdi_rw_mappable;
drivers/mtd/mtdbdi.c +0 -43
43 lines not on this page · raw message
drivers/mtd/mtdcore.c +32 -1
@@ -2,6 +2,9 @@* Core registration and callback routines for MTD * drivers and users. * +* bdi bits are: +* Copyright © 2006 Red Hat, Inc. All Rights Reserved. +* Written by David Howells ([email protected]) */ #include <linux/module.h>
@@ -16,11 +19,39 @@#include <linux/init.h> #include <linux/mtd/compatmac.h> #include <linux/proc_fs.h> +#include <linux/backing-dev.h> #include <linux/mtd/mtd.h> -#include "internal.h" #include "mtdcore.h" +/* +* backing device capabilities for non-mappable devices (such as NAND flash) +* - permits private mappings, copies are taken of the data +*/ +struct backing_dev_info mtd_bdi_unmappable = { + .capabilities =BDI_CAP_MAP_COPY , +}; + +/* +* backing device capabilities for R/O mappable devices (such as ROM) +* - permits private mappings, copies are taken of the data +* - permits non-writable shared mappings +*/ +struct backing_dev_info mtd_bdi_ro_mappable = { + .capabilities = (BDI_CAP_MAP_COPY |BDI_CAP_MAP_DIRECT | +BDI_CAP_EXEC_MAP |BDI_CAP_READ_MAP ), +}; + +/* +* backing device capabilities for writable mappable devices (such as RAM) +* - permits private mappings, copies are taken of the data +* - permits non-writable shared mappings +*/ +struct backing_dev_info mtd_bdi_rw_mappable = { + .capabilities = (BDI_CAP_MAP_COPY |BDI_CAP_MAP_DIRECT | +BDI_CAP_EXEC_MAP |BDI_CAP_READ_MAP | +BDI_CAP_WRITE_MAP ), +};static int mtd_cls_suspend (struct device *dev,pm_message_t state);static int mtd_cls_resume (struct device *dev);
Signature · 1 line
1.6.2.1
PATCH 2/2 Call bdi_init() and bdi_register()
Otherwise we hit a BUG_ON in bdi_queue_work().
--- drivers/mtd/mtdcore.c | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-)
drivers/mtd/mtdcore.c +16 -1
@@ -299,7 +299,7 @@ static struct device_type mtd_devtype = {int add_mtd_device (struct mtd_info *mtd) { -int i; +int i, err;if (!mtd->backing_dev_info) {switch (mtd->type) {
@@ -322,6 +322,12 @@ int add_mtd_device(struct mtd_info *mtd)if (!mtd_table[i]) {struct mtd_notifier *not; + err =bdi_register (mtd->backing_dev_info,NULL ,"mtd%d" , + i); +if (err) { +/* We lose the errno information :( */ +break ; + } mtd_table[i] = mtd; mtd->index = i; mtd->usecount =0 ;
@@ -692,6 +698,15 @@ static int __init init_mtd(void)int ret; ret =class_register (&mtd_class); + ret =bdi_init (&mtd_bdi_unmappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_ro_mappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_rw_mappable); +if (ret) +return ret;if (ret) {pr_err ("Error registering mtd class: %d\n" , ret);return ret;
Signature · 1 line
1.6.2.1
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 12 lines · Jörn Engel
Otherwise we hit a
BUG_ONinbdi_queue_work().Signed-off-by Joern Engel <[email protected]>--- drivers/mtd/mtdcore.c | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-)drivers/mtd/mtdcore.c +0
-0
drivers/mtd/mtdcore.c int add_mtd_device(struct mtd_info *mtd) · line 330
Quoted 9 lines
drivers/mtd/mtdcore.c +6
-0@@ -322,6 +322,12 @@ int add_mtd_device(struct mtd_info *mtd)if (!mtd_table[i]) {struct mtd_notifier *not; + err =bdi_register (mtd->backing_dev_info,NULL ,"mtd%d" , + i); +if (err) { +/* We lose the errno information :( */ +break ; + }
This is not a good idea, even if it'll currently work.
drivers/mtd/mtdcore.c static int __init init_mtd(void) · line 709
Quoted 13 lines
drivers/mtd/mtdcore.c +9
-0@@ -692,6 +698,15 @@ static int __init init_mtd(void)int ret; ret =class_register (&mtd_class); + ret =bdi_init (&mtd_bdi_unmappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_ro_mappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_rw_mappable); +if (ret) +return ret;
Do the bdi_register() here as well.
Signature · 1 line
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 29 lines · Jens Axboe
Quoted 12 lines · Jörn Engel
Otherwise we hit a
BUG_ONinbdi_queue_work().Signed-off-by Joern Engel <[email protected]>--- drivers/mtd/mtdcore.c | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-)drivers/mtd/mtdcore.c +0
-0drivers/mtd/mtdcore.c int add_mtd_device(struct mtd_info *mtd) · line 330
Quoted 9 lines
drivers/mtd/mtdcore.c +6
-0@@ -322,6 +322,12 @@ int add_mtd_device(struct mtd_info *mtd)if (!mtd_table[i]) {struct mtd_notifier *not; + err =bdi_register (mtd->backing_dev_info,NULL ,"mtd%d" , + i); +if (err) { +/* We lose the errno information :( */ +break ; + }This is not a good idea, even if it'll currently work.
Quoted 4 lines
drivers/mtd/mtdcore.c +0
-0@@ -692,6 +698,15 @@ static int __init init_mtd(void)int ret; ret =class_register (&mtd_class);
Quoted 11 lines
drivers/mtd/mtdcore.c static int __init init_mtd(void) · line 709
Quoted 9 lines
drivers/mtd/mtdcore.c +9
-0+ ret =bdi_init (&mtd_bdi_unmappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_ro_mappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_rw_mappable); +if (ret) +return ret;Do the
bdi_register()here as well.
-ENOBRAIN
Initially I wanted to do just than. Then I looked at the block layer and thought we could create one backing_dev_info per mtd as well. Not necessarily a bad if I would actually _create_ them and not just reuse the same ones over and over again.
Jörn
Signature · 3 lines
Linux [...] existed just for discussion between people who wanted to show off how geeky they were. -- Rob Enderle
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 42 lines · Jörn Engel
Quoted 29 lines · Jens Axboe
Quoted 12 lines · Jörn Engel
Otherwise we hit a
BUG_ONinbdi_queue_work().Signed-off-by Joern Engel <[email protected]>--- drivers/mtd/mtdcore.c | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-)drivers/mtd/mtdcore.c +0
-0drivers/mtd/mtdcore.c int add_mtd_device(struct mtd_info *mtd) · line 330
Quoted 9 lines
drivers/mtd/mtdcore.c +6
-0@@ -322,6 +322,12 @@ int add_mtd_device(struct mtd_info *mtd)if (!mtd_table[i]) {struct mtd_notifier *not; + err =bdi_register (mtd->backing_dev_info,NULL ,"mtd%d" , + i); +if (err) { +/* We lose the errno information :( */ +break ; + }This is not a good idea, even if it'll currently work.
Quoted 4 lines
drivers/mtd/mtdcore.c +0
-0@@ -692,6 +698,15 @@ static int __init init_mtd(void)int ret; ret =class_register (&mtd_class);Quoted 11 lines
drivers/mtd/mtdcore.c static int __init init_mtd(void) · line 709
Quoted 9 lines
drivers/mtd/mtdcore.c +9
-0+ ret =bdi_init (&mtd_bdi_unmappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_ro_mappable); +if (ret) +return ret; + ret =bdi_init (&mtd_bdi_rw_mappable); +if (ret) +return ret;Do the
bdi_register()here as well.
Quoted 6 lines
-ENOBRAINInitially I wanted to do just than. Then I looked at the block layer and thought we could create one
backing_dev_infoper mtd as well. Not necessarily a bad if I would actually _create_ them and not just reuse the same ones over and over again.
I cooked up that patch myself, here:
http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=0661b1ac5d48eb47c8a5948c0554fea25e0895ab
Care to give it a quick spin?
Signature · 1 line
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
I Jens,
I'm Paolo Minazzi and I have a problem with logfs and 2.6.34rc5. Can I apply the patch to rc5 and make a test on my ARM board ? Paolo
Quoted 60 lines · Jens Axboe
Quoted 42 lines · Jörn Engel
Quoted 29 lines · Jens Axboe
Quoted 12 lines · Jörn Engel
Otherwise we hit a
BUG_ONinbdi_queue_work().Signed-off-by Joern Engel <[email protected]>---
drivers/mtd/mtdcore.c | 17 ++++++++++++++++-1 files changed, 16 insertions(+), 1 deletions(-)drivers/mtd/mtdcore.c +0
-0drivers/mtd/mtdcore.c int add_mtd_device(struct mtd_info *mtd) · line 330
Quoted 9 lines
drivers/mtd/mtdcore.c +6
-0@@ -322,6 +322,12 @@ int add_mtd_device(struct mtd_info *mtd) if (!mtd_table[i]) { struct mtd_notifier *not; + err = bdi_register(mtd->backing_dev_info, NULL, "mtd%d", + i); + if (err) { + /* We lose the errno information :( */ + break; + }This is not a good idea, even if it'll currently work.
Quoted 4 lines
drivers/mtd/mtdcore.c +0
-0@@ -692,6 +698,15 @@ static int __init init_mtd(void) int ret; ret = class_register(&mtd_class);Quoted 11 lines
drivers/mtd/mtdcore.c static int __init init_mtd(void) · line 709
Quoted 9 lines
drivers/mtd/mtdcore.c +9
-0+ ret =bdi_init (&mtd_bdi_unmappable); +if (ret) + return ret; + ret =bdi_init (&mtd_bdi_ro_mappable); +if (ret) + return ret; + ret =bdi_init (&mtd_bdi_rw_mappable); +if (ret) + return ret;Do the
bdi_register()here as well.Quoted 6 lines
-ENOBRAINInitially I wanted to do just than. Then I looked at the block layer and thought we could create one
backing_dev_infoper mtd as well. Not necessarily a bad if I would actually _create_ them and not just reuse the same ones over and over again.I cooked up that patch myself, here:
http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=0661b1ac5d48eb47c8a5948c0554fea25e0895ab
Care to give it a quick spin?
--
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 4 lines · Paolo Minazzi
I Jens,
I'm Paolo Minazzi and I have a problem with logfs and 2.6.34rc5. Can I apply the patch to rc5 and make a test on my ARM board ? Paolo
Yes please do, below are the collected fixes for mtd in this area. It should apply to recent -git just fine.
drivers/mtd/Makefile +1 -1
@@ -4,7 +4,7 @@ # Core functionality. obj-$(CONFIG_MTD) += mtd.o -mtd-y := mtdcore.o mtdsuper.o mtdbdi.o +mtd-y := mtdcore.o mtdsuper.o mtd-$(CONFIG_MTD_PARTITIONS) += mtdpart.o obj-$(CONFIG_MTD_CONCAT) += mtdconcat.o
drivers/mtd/internal.h +0 -17
@@ -1,17 +0,0 @@ -/* Internal MTD definitions -* -* Copyright © 2006 Red Hat, Inc. All Rights Reserved. -* Written by David Howells ([email protected]) -* -* This program is free software; you can redistribute it and/or -* modify it under the terms of the GNU General Public License -* as published by the Free Software Foundation; either version -* 2 of the License, or (at your option) any later version. -*/ - -/* -* mtdbdi.c -*/ -extern struct backing_dev_info mtd_bdi_unmappable; -extern struct backing_dev_info mtd_bdi_ro_mappable; -extern struct backing_dev_info mtd_bdi_rw_mappable;
drivers/mtd/mtdbdi.c +0 -43
43 lines not on this page · raw message
drivers/mtd/mtdcore.c +74 -5
117 lines not on this page · raw message
drivers/mtd/mtdsuper.c +2 -0
@@ -13,6 +13,7 @@#include <linux/mtd/super.h> #include <linux/namei.h> #include <linux/ctype.h> +#include <linux/slab.h> /* * compare superblocks to see if they're equivalent
@@ -44,6 +45,7 @@ static int get_sb_mtd_set(struct super_block *sb, void *_mtd) sb->s_mtd = mtd; sb->s_dev =MKDEV (MTD_BLOCK_MAJOR , mtd->index); + sb->s_bdi = mtd->backing_dev_info;return 0 ; }
Signature · 1 line
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
In reply to Jens AxboeQuoted 6 lines · Jens Axboe
I cooked up that patch myself, here:
http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=0661b1ac5d48eb47c8a5948c0554fea25e0895ab
Care to give it a quick spin?
Works for me.
Jörn
Signature · 3 lines
If you're willing to restrict the flexibility of your approach, you can almost always do something better. -- John Carmack
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 9 lines · Jörn Engel
Quoted 6 lines · Jens Axboe
I cooked up that patch myself, here:
http://git.kernel.dk/?p=linux-2.6-block.git;a=commit;h=0661b1ac5d48eb47c8a5948c0554fea25e0895ab
Care to give it a quick spin?
Works for me.
Goodness, thanks for testing. Now we are pretty close to have something we can send out.
Signature · 1 line
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
In reply to Jörn EngelI have tried this patch.
I have enabled LOGFS, but not mounted partition with it. /dev/mtdblock1 is my romfs root partition and it is OK.
The problem is that init cannot mount my /dev/mtdblock1 romfs root.
This is the fault :
Platform: Cirrus Logic EDB9315A Board (ARM920T) Rev A Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
|----------------------------------------------
Raw file loaded 0x00080000-0x001dce6b, assumed entry at 0x00080000-----------------------------------------------------------
RedBoot> exec -s 0x00b00000 -r 0x00a00000 -c "root=/dev/mtdblock1
console=ttyAM console=tty1"-------------------------------- ENTRY=0xc0008000------------------------------------------------------------------------------------------------------------- LENGTH=0x00300000------------------------------------------------------------------------------------------------------------ BASE_ADDR=0x00080000--------------------------------------------------------------------------------------------------------- Using base address 0x00080000 and length 0x00300000--------------------------------------------------------------------------
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc5 (root@darkstar) (gcc version 3.4.3) #18 Tue
Apr 27 10:55:55 CEST 2010
CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Cirrus Logic EDB9315A Evaluation Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/mtdblock1 console=ttyAM console=tty1 PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126928k/126928k available, 4144k reserved, 0K highmem Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
vmalloc : 0xc8800000 - 0xfe800000 ( 864 MB)
lowmem : 0xc0000000 - 0xc8000000 ( 128 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.init : 0xc0008000 - 0xc0036000 ( 184 kB)
.text : 0xc0036000 - 0xc02ab000 (2516 kB)
.data : 0xc02ac000 - 0xc02c4e00 ( 100 kB)SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation.
NR_IRQS:120
VIC @fefb0000: id 0x00041190, vendor 0x41
VIC @fefc0000: id 0x00041190, vendor 0x41
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop... 99.73 BogoMIPS (lpj=498688)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
ep93xx clock: PLL1 running at 200 MHz, PLL2 at 48 MHz
ep93xx clock: FCLK 200 MHz, HCLK 100 MHz, PCLK 50 MHz
ep93xx dma_m2p: M2P DMA subsystem initialized
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
***REGISTER LOGFS
***REGISTER LOGFS DONE ret=0
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 247
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Console: switching to colour frame buffer device 100x37
graphics fb0: registered. Mode = 800x600-16
Serial: AMBA driver
apb:uart1: ttyAM0 at MMIO 0x808c0000 (irq = 52) is a AMBA
console [ttyAM0] enabled
apb:uart2: ttyAM1 at MMIO 0x808d0000 (irq = 54) is a AMBA apb:uart3: ttyAM2 at MMIO 0x808e0000 (irq = 55) is a AMBA dev->num_resources=1
physmap platform flash device: 02000000 at 60000000 physmap-flash.0: Found 1 x16 devices at 0x0 in 16-bit bank physmap-flash.0: Found 1 x16 devices at 0x1000000 in 16-bit bank
Intel/Sharp Extended Query Table at 0x0031
Intel/Sharp Extended Query Table at 0x0031
Using buffer write methodcfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset 0x1fe0000 6 RedBoot partitions found on MTD device physmap-flash.0
Creating 6 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "RedBoot" 0x000000040000-0x000000b40000 : "ramdisk" 0x000000b40000-0x000000e40000 : "zImage" 0x000000e40000-0x000001fc0000 : "jffs2" 0x000001fc0000-0x000001fe0000 : "RedBoot config" 0x000001fe0000-0x000002000000 : "FIS directory"
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
ep93xx-eth version 0.1 loading
eth0: ep93xx on-chip ethernet, IRQ 39, 00:00:11:22:33:36ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ep93xx-ohci ep93xx-ohci: EP93xx OHCI
ep93xx-ohci ep93xx-ohci: new USB bus registered, assigned bus number 1 ep93xx-ohci ep93xx-ohci: irq 56, io mem 0x80020000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new interface driver cdc_acmcdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ep93xx-rtc ep93xx-rtc: rtc core: registered ep93xx-rtc as rtc0
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 17
Last power-down at UTC 08:47:16 on 27/04/2010
ep93xx-rtc ep93xx-rtc: setting system clock to 2010-04-27 08:47:16 UTC (1272358036)
VFS: Cannot open root device "mtdblock1" or unknown-block(31,1) Please append a correct "root=" boot option; here are the available partitions:
1f00 256 mtdblock0 (driver?)
1f01 11264 mtdblock1 (driver?)
1f02 3072 mtdblock2 (driver?)
1f03 17920 mtdblock3 (driver?)
1f04 128 mtdblock4 (driver?)
1f05 128 mtdblock5 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1) Backtrace: [<c003a3dc>] (dump_backtrace+0x0/0x12c) from [<c003a520>] (dump_stack+0x18/0x1c) r7:c7c11000 r6:fffffffb r5:c7c11000 r4:00000000 [<c003a508>] (dump_stack+0x0/0x1c) from [<c0046628>] (panic+0x3c/0xc4) [<c00465ec>] (panic+0x0/0xc4) from [<c0008d58>] (mount_block_root+0x110/0x2e8) r3:00000000 r2:20000013 r1:c7c27f58 r0:c0276b44 [<c0008c48>] (mount_block_root+0x0/0x2e8) from [<c0008f84>] (mount_root+0x54/0x6c) [<c0008f30>] (mount_root+0x0/0x6c) from [<c0009094>] (prepare_namespace+0xf8/0x194) r5:c001a56c r4:c001a570 [<c0008f9c>] (prepare_namespace+0x0/0x194) from [<c0008aa4>] (kernel_init+0x114/0x15c) r6:c0019b0c r5:c0019d5c r4:c02c4e18 [<c0008990>] (kernel_init+0x0/0x15c) from [<c0048e98>] (do_exit+0x0/0x628) r6:00000000 r5:00000000 r4:00000000
If I disable logfs, my root /dev/mtdblock1 is mounted correclty.
Any ideas ?
Paolo
Quoted 53 lines · Jörn Engel
Otherwise we hit a
BUG_ONinbdi_queue_work().Signed-off-by Joern Engel <[email protected]>---
drivers/mtd/mtdcore.c | 17 ++++++++++++++++-1 files changed, 16 insertions(+), 1 deletions(-)drivers/mtd/mtdcore.c +16
-2@@ -299,7 +299,7 @@ static struct device_type mtd_devtype = { int add_mtd_device(struct mtd_info *mtd) { - int i; + int i, err; if (!mtd->backing_dev_info) { switch (mtd->type) {@@ -322,6 +322,12 @@ int add_mtd_device(struct mtd_info *mtd) if (!mtd_table[i]) { struct mtd_notifier *not; + err = bdi_register(mtd->backing_dev_info, NULL, "mtd%d", + i); + if (err) { + /* We lose the errno information :( */ + break; + } mtd_table[i] = mtd; mtd->index = i; mtd->usecount = 0;@@ -692,6 +698,15 @@ static int __init init_mtd(void) int ret; ret = class_register(&mtd_class); + ret = bdi_init(&mtd_bdi_unmappable); + if (ret) + return ret; + ret = bdi_init(&mtd_bdi_ro_mappable); + if (ret) + return ret; + ret = bdi_init(&mtd_bdi_rw_mappable); + if (ret) + return ret; if (ret) { pr_err("Error registering mtd class: %d\n", ret); return ret; --1.6.2.1
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 157 lines · Paolo Minazzi
I have tried this patch.
I have enabled LOGFS, but not mounted partition with it./dev/mtdblock1is my romfs root partition and it is OK.The problem is that init cannot mount my
/dev/mtdblock1romfs root.This is the fault :
Platform: Cirrus Logic EDB9315A Board (ARM920T) Rev A Copyright (C) 2000, 2001, 2002, Red Hat, Inc.|----------------------------------------------Raw file loaded 0x00080000-0x001dce6b, assumed entry at 0x00080000-----------------------------------------------------------
RedBoot> exec -s0x00b00000-r0x00a00000-c "root=/dev/mtdblock1
console=ttyAM console=tty1"-------------------------------- ENTRY=0xc0008000------------------------------------------------------------------------------------------------------------- LENGTH=0x00300000------------------------------------------------------------------------------------------------------------ BASE_ADDR=0x00080000--------------------------------------------------------------------------------------------------------- Using base address0x00080000and length 0x00300000--------------------------------------------------------------------------
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc5 (root@darkstar) (gcc version 3.4.3) #18 TueApr 27 10:55:55 CEST 2010CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Cirrus Logic EDB9315A Evaluation Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/mtdblock1 console=ttyAM console=tty1 PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126928k/126928k available, 4144k reserved, 0K highmem Virtual kernel memory layout:vector : 0xffff0000 - 0xffff1000 ( 4 kB) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) DMA : 0xffc00000 - 0xffe00000 ( 2 MB) vmalloc : 0xc8800000 - 0xfe800000 ( 864 MB) lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) modules : 0xbf000000 - 0xc0000000 ( 16 MB) .init : 0xc0008000 - 0xc0036000 ( 184 kB) .text : 0xc0036000 - 0xc02ab000 (2516 kB) .data : 0xc02ac000 - 0xc02c4e00 ( 100 kB)SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation.
NR_IRQS:120
VIC @fefb0000: id0x00041190, vendor0x41
VIC @fefc0000: id0x00041190, vendor0x41
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop... 99.73 BogoMIPS (lpj=498688)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
ep93xx clock: PLL1 running at 200 MHz, PLL2 at 48 MHz
ep93xx clock: FCLK 200 MHz, HCLK 100 MHz, PCLK 50 MHz
ep93xxdma_m2p: M2P DMA subsystem initialized
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
***REGISTER LOGFS
***REGISTER LOGFS DONE ret=0
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 247
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Console: switching to colour frame buffer device 100x37
graphics fb0: registered. Mode = 800x600-16
Serial: AMBA driver
apb:uart1: ttyAM0 at MMIO0x808c0000(irq = 52) is a AMBA
console [ttyAM0] enabled
apb:uart2: ttyAM1 at MMIO0x808d0000(irq = 54) is a AMBA apb:uart3: ttyAM2 at MMIO0x808e0000(irq = 55) is a AMBA dev->num_resources=1
physmap platform flash device: 02000000 at 60000000 physmap-flash.0: Found 1 x16 devices at0x0in 16-bit bank physmap-flash.0: Found 1 x16 devices at0x1000000in 16-bit bank
Intel/Sharp Extended Query Table at0x0031
Intel/Sharp Extended Query Table at0x0031
Using buffer write methodcfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset0x1fe00006 RedBoot partitions found on MTD device physmap-flash.0
Creating 6 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "RedBoot" 0x000000040000-0x000000b40000 : "ramdisk" 0x000000b40000-0x000000e40000 : "zImage" 0x000000e40000-0x000001fc0000 : "jffs2" 0x000001fc0000-0x000001fe0000 : "RedBoot config" 0x000001fe0000-0x000002000000 : "FIS directory"
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
ep93xx-eth version 0.1 loading
eth0: ep93xx on-chip ethernet, IRQ 39, 00:00:11:22:33:36ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ep93xx-ohci ep93xx-ohci: EP93xx OHCI
ep93xx-ohci ep93xx-ohci: new USB bus registered, assigned bus number 1 ep93xx-ohci ep93xx-ohci: irq 56, io mem0x80020000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new interface drivercdc_acmcdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ep93xx-rtc ep93xx-rtc: rtc core: registered ep93xx-rtc as rtc0
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 17
Last power-down at UTC 08:47:16 on 27/04/2010
ep93xx-rtc ep93xx-rtc: setting system clock to 2010-04-27 08:47:16 UTC (1272358036)
VFS: Cannot open root device "mtdblock1" or unknown-block(31,1) Please append a correct "root=" boot option; here are the available partitions:
1f00 256 mtdblock0 (driver?)
1f01 11264 mtdblock1 (driver?)
1f02 3072 mtdblock2 (driver?)
1f03 17920 mtdblock3 (driver?)
1f04 128 mtdblock4 (driver?)
1f05 128 mtdblock5 (driver?)Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1) Backtrace: [<c003a3dc>] (dump_backtrace+0x0/0x12c) from [<c003a520>] (dump_stack+0x18/0x1c) r7:c7c11000 r6:fffffffb r5:c7c11000 r4:00000000 [<c003a508>] (dump_stack+0x0/0x1c) from [<c0046628>] (panic+0x3c/0xc4) [<c00465ec>] (panic+0x0/0xc4) from [<c0008d58>] (mount_block_root+0x110/0x2e8) r3:00000000 r2:20000013 r1:c7c27f58 r0:c0276b44 [<c0008c48>] (mount_block_root+0x0/0x2e8) from [<c0008f84>] (mount_root+0x54/0x6c) [<c0008f30>] (mount_root+0x0/0x6c) from [<c0009094>] (prepare_namespace+0xf8/0x194) r5:c001a56c r4:c001a570 [<c0008f9c>] (prepare_namespace+0x0/0x194) from [<c0008aa4>] (kernel_init+0x114/0x15c) r6:c0019b0c r5:c0019d5c r4:c02c4e18 [<c0008990>] (kernel_init+0x0/0x15c) from [<c0048e98>] (do_exit+0x0/0x628) r6:00000000 r5:00000000 r4:00000000
Quoted 1 line
If I disable logfs, my root
/dev/mtdblock1is mounted correclty.
So this issue looks unrelated, but a bug none the less (if just enabling logfs breaks the mount).
Signature · 1 line
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
To be precise, I say :
- downloaded 2.6.34rc5
- apply the jens patch
- the logfs code is the code in the 2.6.34rc5 (I have no applied other jorn patch)
Paolo
Quoted 167 lines · Jens Axboe
Quoted 157 lines · Paolo Minazzi
I have tried this patch.
I have enabled LOGFS, but not mounted partition with it./dev/mtdblock1is my romfs root partition and it is OK.The problem is that init cannot mount my
/dev/mtdblock1romfs root.This is the fault :
Platform: Cirrus Logic EDB9315A Board (ARM920T) Rev A
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
|----------------------------------------------
Raw file loaded 0x00080000-0x001dce6b, assumed entry at 0x00080000-----------------------------------------------------------
RedBoot> exec -s0x00b00000-r0x00a00000-c "root=/dev/mtdblock1
console=ttyAM console=tty1"-------------------------------- ENTRY=0xc0008000------------------------------------------------------------------------------------------------------------- LENGTH=0x00300000------------------------------------------------------------------------------------------------------------ BASE_ADDR=0x00080000--------------------------------------------------------------------------------------------------------- Using base address0x00080000and length 0x00300000--------------------------------------------------------------------------
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc5 (root@darkstar) (gcc version 3.4.3) #18 TueApr 27 10:55:55 CEST 2010CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Cirrus Logic EDB9315A Evaluation Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/mtdblock1 console=ttyAM console=tty1 PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126928k/126928k available, 4144k reserved, 0K highmem Virtual kernel memory layout:
vector :0xffff0000-0xffff1000( 4 kB)
fixmap :0xfff00000-0xfffe0000( 896 kB)
DMA :0xffc00000-0xffe00000( 2 MB)
vmalloc :0xc8800000-0xfe800000( 864 MB)
lowmem :0xc0000000-0xc8000000( 128 MB)
modules :0xbf000000-0xc0000000( 16 MB)
.init :0xc0008000-0xc0036000( 184 kB)
.text :0xc0036000-0xc02ab000(2516 kB)
.data :0xc02ac000-0xc02c4e00( 100 kB)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation.
NR_IRQS:120
VIC @fefb0000: id0x00041190, vendor0x41
VIC @fefc0000: id0x00041190, vendor0x41
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop... 99.73 BogoMIPS (lpj=498688)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
ep93xx clock: PLL1 running at 200 MHz, PLL2 at 48 MHz
ep93xx clock: FCLK 200 MHz, HCLK 100 MHz, PCLK 50 MHz
ep93xxdma_m2p: M2P DMA subsystem initialized
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
***REGISTER LOGFS
***REGISTER LOGFS DONE ret=0
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 247
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Console: switching to colour frame buffer device 100x37
graphics fb0: registered. Mode = 800x600-16
Serial: AMBA driver
apb:uart1: ttyAM0 at MMIO0x808c0000(irq = 52) is a AMBA
console [ttyAM0] enabled
apb:uart2: ttyAM1 at MMIO0x808d0000(irq = 54) is a AMBA apb:uart3: ttyAM2 at MMIO0x808e0000(irq = 55) is a AMBA dev->num_resources=1
physmap platform flash device: 02000000 at 60000000 physmap-flash.0: Found 1 x16 devices at0x0in 16-bit bank physmap-flash.0: Found 1 x16 devices at0x1000000in 16-bit bank Intel/Sharp Extended Query Table at0x0031
Intel/Sharp Extended Query Table at0x0031
Using buffer write methodcfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset0x1fe00006 RedBoot partitions found on MTD device physmap-flash.0
Creating 6 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "RedBoot" 0x000000040000-0x000000b40000 : "ramdisk" 0x000000b40000-0x000000e40000 : "zImage" 0x000000e40000-0x000001fc0000 : "jffs2" 0x000001fc0000-0x000001fe0000 : "RedBoot config" 0x000001fe0000-0x000002000000 : "FIS directory"
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
ep93xx-eth version 0.1 loading
eth0: ep93xx on-chip ethernet, IRQ 39, 00:00:11:22:33:36ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ep93xx-ohci ep93xx-ohci: EP93xx OHCI
ep93xx-ohci ep93xx-ohci: new USB bus registered, assigned bus number 1 ep93xx-ohci ep93xx-ohci: irq 56, io mem0x80020000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new interface drivercdc_acmcdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ep93xx-rtc ep93xx-rtc: rtc core: registered ep93xx-rtc as rtc0
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 17
Last power-down at UTC 08:47:16 on 27/04/2010
ep93xx-rtc ep93xx-rtc: setting system clock to 2010-04-27 08:47:16 UTC (1272358036)
VFS: Cannot open root device "mtdblock1" or unknown-block(31,1) Please append a correct "root=" boot option; here are the available partitions:
1f00 256 mtdblock0 (driver?)
1f01 11264 mtdblock1 (driver?)
1f02 3072 mtdblock2 (driver?)
1f03 17920 mtdblock3 (driver?)
1f04 128 mtdblock4 (driver?)
1f05 128 mtdblock5 (driver?)Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1) Backtrace: [<c003a3dc>] (dump_backtrace+0x0/0x12c) from [<c003a520>] (dump_stack+0x18/0x1c) r7:c7c11000 r6:fffffffb r5:c7c11000 r4:00000000 [<c003a508>] (dump_stack+0x0/0x1c) from [<c0046628>] (panic+0x3c/0xc4) [<c00465ec>] (panic+0x0/0xc4) from [<c0008d58>] (mount_block_root+0x110/0x2e8) r3:00000000 r2:20000013 r1:c7c27f58 r0:c0276b44 [<c0008c48>] (mount_block_root+0x0/0x2e8) from [<c0008f84>] (mount_root+0x54/0x6c) [<c0008f30>] (mount_root+0x0/0x6c) from [<c0009094>] (prepare_namespace+0xf8/0x194) r5:c001a56c r4:c001a570 [<c0008f9c>] (prepare_namespace+0x0/0x194) from [<c0008aa4>] (kernel_init+0x114/0x15c) r6:c0019b0c r5:c0019d5c r4:c02c4e18 [<c0008990>] (kernel_init+0x0/0x15c) from [<c0048e98>] (do_exit+0x0/0x628) r6:00000000 r5:00000000 r4:00000000Quoted 1 line
If I disable logfs, my root
/dev/mtdblock1is mounted correclty.So this issue looks unrelated, but a bug none the less (if just enabling logfs breaks the mount).
--
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 164 lines · Paolo Minazzi
Quoted 158 lines · Jens Axboe
Quoted 157 lines · Paolo Minazzi
I have tried this patch.
I have enabled LOGFS, but not mounted partition with it./dev/mtdblock1is my romfs root partition and it is OK.The problem is that init cannot mount my
/dev/mtdblock1romfs root.This is the fault :
Platform: Cirrus Logic EDB9315A Board (ARM920T) Rev A
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.
|----------------------------------------------
Raw file loaded 0x00080000-0x001dce6b, assumed entry at 0x00080000-----------------------------------------------------------
RedBoot> exec -s0x00b00000-r0x00a00000-c "root=/dev/mtdblock1
console=ttyAM console=tty1"-------------------------------- ENTRY=0xc0008000------------------------------------------------------------------------------------------------------------- LENGTH=0x00300000------------------------------------------------------------------------------------------------------------ BASE_ADDR=0x00080000--------------------------------------------------------------------------------------------------------- Using base address0x00080000and length 0x00300000--------------------------------------------------------------------------
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc5 (root@darkstar) (gcc version 3.4.3) #18 TueApr 27 10:55:55 CEST 2010CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Cirrus Logic EDB9315A Evaluation Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/mtdblock1 console=ttyAM console=tty1 PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 126928k/126928k available, 4144k reserved, 0K highmem Virtual kernel memory layout:
vector :0xffff0000-0xffff1000( 4 kB)
fixmap :0xfff00000-0xfffe0000( 896 kB)
DMA :0xffc00000-0xffe00000( 2 MB)
vmalloc :0xc8800000-0xfe800000( 864 MB)
lowmem :0xc0000000-0xc8000000( 128 MB)
modules :0xbf000000-0xc0000000( 16 MB)
.init :0xc0008000-0xc0036000( 184 kB)
.text :0xc0036000-0xc02ab000(2516 kB)
.data :0xc02ac000-0xc02c4e00( 100 kB)
SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Hierarchical RCU implementation.
NR_IRQS:120
VIC @fefb0000: id0x00041190, vendor0x41
VIC @fefc0000: id0x00041190, vendor0x41
Console: colour dummy device 80x30
console [tty1] enabled
Calibrating delay loop... 99.73 BogoMIPS (lpj=498688)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
ep93xx clock: PLL1 running at 200 MHz, PLL2 at 48 MHz
ep93xx clock: FCLK 200 MHz, HCLK 100 MHz, PCLK 50 MHz
ep93xxdma_m2p: M2P DMA subsystem initialized
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 3, 32768 bytes) TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
***REGISTER LOGFS
***REGISTER LOGFS DONE ret=0
ROMFS MTD (C) 2007 Red Hat, Inc.
msgmni has been set to 247
io scheduler noop registered
io scheduler deadline registered
io scheduler cfq registered (default)
Console: switching to colour frame buffer device 100x37
graphics fb0: registered. Mode = 800x600-16
Serial: AMBA driver
apb:uart1: ttyAM0 at MMIO0x808c0000(irq = 52) is a AMBA
console [ttyAM0] enabled
apb:uart2: ttyAM1 at MMIO0x808d0000(irq = 54) is a AMBA apb:uart3: ttyAM2 at MMIO0x808e0000(irq = 55) is a AMBA dev->num_resources=1
physmap platform flash device: 02000000 at 60000000 physmap-flash.0: Found 1 x16 devices at0x0in 16-bit bank physmap-flash.0: Found 1 x16 devices at0x1000000in 16-bit bank Intel/Sharp Extended Query Table at0x0031
Intel/Sharp Extended Query Table at0x0031
Using buffer write methodcfi_cmdset_0001: Erase suspend on write enabled
cmdlinepart partition parsing not available
Searching for RedBoot partition table in physmap-flash.0 at offset0x1fe00006 RedBoot partitions found on MTD device physmap-flash.0
Creating 6 MTD partitions on "physmap-flash.0":
0x000000000000-0x000000040000 : "RedBoot" 0x000000040000-0x000000b40000 : "ramdisk" 0x000000b40000-0x000000e40000 : "zImage" 0x000000e40000-0x000001fc0000 : "jffs2" 0x000001fc0000-0x000001fe0000 : "RedBoot config" 0x000001fe0000-0x000002000000 : "FIS directory"
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
ep93xx-eth version 0.1 loading
eth0: ep93xx on-chip ethernet, IRQ 39, 00:00:11:22:33:36ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
ep93xx-ohci ep93xx-ohci: EP93xx OHCI
ep93xx-ohci ep93xx-ohci: new USB bus registered, assigned bus number 1 ep93xx-ohci ep93xx-ohci: irq 56, io mem0x80020000
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
usbcore: registered new interface drivercdc_acmcdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
ep93xx-rtc ep93xx-rtc: rtc core: registered ep93xx-rtc as rtc0
usbcore: registered new interface driver usbhid
usbhid: USB HID core driver
TCP cubic registered
NET: Registered protocol family 17
Last power-down at UTC 08:47:16 on 27/04/2010
ep93xx-rtc ep93xx-rtc: setting system clock to 2010-04-27 08:47:16 UTC (1272358036)
VFS: Cannot open root device "mtdblock1" or unknown-block(31,1) Please append a correct "root=" boot option; here are the available partitions:
1f00 256 mtdblock0 (driver?)
1f01 11264 mtdblock1 (driver?)
1f02 3072 mtdblock2 (driver?)
1f03 17920 mtdblock3 (driver?)
1f04 128 mtdblock4 (driver?)
1f05 128 mtdblock5 (driver?)Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1) Backtrace: [<c003a3dc>] (dump_backtrace+0x0/0x12c) from [<c003a520>] (dump_stack+0x18/0x1c) r7:c7c11000 r6:fffffffb r5:c7c11000 r4:00000000 [<c003a508>] (dump_stack+0x0/0x1c) from [<c0046628>] (panic+0x3c/0xc4) [<c00465ec>] (panic+0x0/0xc4) from [<c0008d58>] (mount_block_root+0x110/0x2e8) r3:00000000 r2:20000013 r1:c7c27f58 r0:c0276b44 [<c0008c48>] (mount_block_root+0x0/0x2e8) from [<c0008f84>] (mount_root+0x54/0x6c) [<c0008f30>] (mount_root+0x0/0x6c) from [<c0009094>] (prepare_namespace+0xf8/0x194) r5:c001a56c r4:c001a570 [<c0008f9c>] (prepare_namespace+0x0/0x194) from [<c0008aa4>] (kernel_init+0x114/0x15c) r6:c0019b0c r5:c0019d5c r4:c02c4e18 [<c0008990>] (kernel_init+0x0/0x15c) from [<c0048e98>] (do_exit+0x0/0x628) r6:00000000 r5:00000000 r4:00000000Quoted 4 lines
Quoted 1 line
If I disable logfs, my root
/dev/mtdblock1is mounted correclty.So this issue looks unrelated, but a bug none the less (if just enabling logfs breaks the mount).
Quoted 6 lines
To be precise, I say :
- downloaded 2.6.34rc5
- apply the jens patch
- the logfs code is the code in the 2.6.34rc5 (I have no applied other jorn patch)
(please stop top posting, I fixed this one up for you).
Just to be on the safe side - without the patch, does it work or not?
Signature · 1 line
Jens Axboe
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 4 lines
Just to be on the safe side - without the patch, does it work or not?
--
Jens Axboe
Without the patch for me means the standard 2.6.34rc5.
In this case :
- enabling logfs I have an oop in fs/write-back.c:157 before kernel calls init.
- disabling logfs I can do normal mount my root /dev/mtdblock1
This is my experience.
Paolo
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
In reply to Paolo MinazziQuoted 22 lines · Paolo Minazzi
I have tried this patch.
I have enabled LOGFS, but not mounted partition with it./dev/mtdblock1is my romfs root partition and it is OK.The problem is that init cannot mount my
/dev/mtdblock1romfs root.This is the fault :
Platform: Cirrus Logic EDB9315A Board (ARM920T) Rev A Copyright (C) 2000, 2001, 2002, Red Hat, Inc.|----------------------------------------------Raw file loaded 0x00080000-0x001dce6b, assumed entry at 0x00080000-----------------------------------------------------------
RedBoot> exec -s0x00b00000-r0x00a00000-c "root=/dev/mtdblock1
console=ttyAM console=tty1"-------------------------------- ENTRY=0xc0008000------------------------------------------------------------------------------------------------------------- LENGTH=0x00300000------------------------------------------------------------------------------------------------------------ BASE_ADDR=0x00080000--------------------------------------------------------------------------------------------------------- Using base address0x00080000and length 0x00300000--------------------------------------------------------------------------
Uncompressing Linux... done, booting the kernel.
Linux version 2.6.34-rc5 (root@darkstar) (gcc version 3.4.3) #18 Tue
Quoted 7 lines
Apr 27 10:55:55 CEST 2010CPU: ARM920T [41129200] revision 0 (ARMv4T), cr=c0007177
CPU: VIVT data cache, VIVT instruction cache
Machine: Cirrus Logic EDB9315A Evaluation Board
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: root=/dev/mtdblock1 console=ttyAM console=tty1
If you add "rootfstype=romfs" to the command line, does the problem still exist?
Jörn
Signature · 2 lines
And spam is a useful source of entropy for /dev/random too! -- Jasmine Strong
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 4 lines
If you add "rootfstype=romfs" to the command line, does the problem still exist?
Jörn
Jorn , you are right.
It seems work....
please wait....
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 7 lines · Paolo Minazzi
Quoted 3 lines
If you add "rootfstype=romfs" to the command line, does the problem still exist?
Jorn , you are right.
It seems work....
please wait....
Ok, I'm pretty sure that logfs returns -EIO where it should return -EINVAL. If filesystems are tried in alphabetical order, logfs comes first and -EIO tells the kernel to stop trying and panic, essentially.
Will cook up a patch...
Jörn
Signature · 2 lines
A defeated army first battles and then seeks victory. -- Sun Tzu
PATCH 1/1 Return -EINVAL if filesystem image doesn't match
Quoted 9 lines · Jörn Engel
Quoted 7 lines · Paolo Minazzi
Quoted 3 lines
If you add "rootfstype=romfs" to the command line, does the problem still exist?
Jorn , you are right.
It seems work....
please wait....
Quoted 5 lines
Ok, I'm pretty sure that logfs returns
-EIOwhere it should return-EINVAL. If filesystems are tried in alphabetical order, logfs comes first and-EIOtells the kernel to stop trying and panic, essentially.Will cook up a patch...
Does the patch below solve the problem for you (without the explicit "rootfstype=romfs")?
Jörn
Signature · 8 lines
One of my most productive days was throwing away 1000 lines of code. -- Ken Thompson. Signed-off-by: Joern Engel <[email protected]> --- fs/logfs/super.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
fs/logfs/super.c +1 -1
@@ -413,7 +413,7 @@ static int __logfs_read_sb(struct super_block *sb) page =find_super_block (sb);if (!page) -return -EIO ; +return -EINVAL ; ds =page_address (page); super->s_size =be64_to_cpu (ds->ds_filesystem_size);
Signature · 1 line
1.6.2.1
Re: [PATCH] [LogFS] Return -EINVAL if filesystem image doesn't match
Quoted 20 lines
Does the patch below solve the problem for you (without the explicit "rootfstype=romfs")?
Jörn
--
One of my most productive days was throwing away 1000 lines of code. -- Ken Thompson.Signed-off-by Joern Engel <[email protected]>---
fs/logfs/super.c | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)fs/logfs/super.c +0
-0
fs/logfs/super.c static int __logfs_read_sb(struct super_block *sb) · line 419
Quoted 8 lines
fs/logfs/super.c +1
-1@@ -413,7 +413,7 @@ static int __logfs_read_sb(struct super_block *sb) page = find_super_block(sb); if (!page) - return -EIO; + return -EINVAL; ds = page_address(page); super->s_size = be64_to_cpu(ds->ds_filesystem_size);
The above patch solve the problem for me.
Now I can mount root without rootfstype=romfs
Bye,
Paolo
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
In reply to Jörn EngelOk, now it is very better.
My problem now is that logfs does not save files in the following case:
1) power-off, then power-on (without umount)
2) sync, then power-off, then power-on (without umount)
Using umount sometimes seems works, sometimes I have the following oop :
~ # mount -t logfs /dev/mtdblock7 /mitrolbackup
~ # cd /mitrolbackup
/mitrolbackup # echo ciao > ciao
/mitrolbackup # echo pino > pino
/mitrolbackup # ls
ciao pino
/mitrolbackup # cd ..
~ # umount /mitrolbackup/
kernel BUG at fs/logfs/readwrite.c:1976!
Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = c7db0000 [00000000] *pgd=c7dac031, *pte=00000000, *ppte=00000000 Internal error: Oops: 817 [#1] last sysfs file: Modules linked in: CPU: 0 Not tainted (2.6.34-rc5 #19) PC is at __bug+0x20/0x2c LR is at release_console_sem+0x1b8/0x1ec pc : [<c003a1ac>] lr : [<c004760c>] psr: 60000013
sp : c7d5fe60 ip : c7d5fd98 fp : c7d5fe6c
r10: 00000003 r9 : 00000000 r8 : c7d5feb4
r7 : 00000003 r6 : c7d5feb4 r5 : c7819878 r4 : c7819870 r3 : 00000000 r2 : 60000013 r1 : 000019c2 r0 : 0000002f
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: c000717f Table: c7db0000 DAC: 00000015 Process umount (pid: 307, stack limit = 0xc7d5e260)
Stack: (0xc7d5fe60 to 0xc7d60000)
fe60: c7d5fe7c c7d5fe70 c00fb2f0 c003a19c c7d5fe90 c7d5fe80 c00ad358 c00fb274
fe80: c7819870 c7d5feb0 c7d5fe94 c00ad3e4 c00ad2bc c7d46a64 c7d46a54 c7819880
fea0: c7d46a64 c7d5fee4 c7d5feb4 c00ad5a8 c00ad3d0 c7d5feb4 c7d5feb4 c7d46a00
fec0: c7d5e000 c022a324 00000000 c7d5ff54 c7d2b880 00000000 c7d5ff00 c7d5fee8
fee0: c009c8ec c00ad4c0 c7d46a00 c7c14000 c7d2b880 c7d5ff1c c7d5ff04 c00feb38
ff00: c009c84c c7d46a00 c02b7b84 c7d2b880 c7d5ff34 c7d5ff20 c009c740 c00feb00
ff20: c7d2b880 c7d46a00 c7d5ff4c c7d5ff38 c00b0bd0 c009c708 00000000 c7d2b898
ff40: c7d5ff94 c7d5ff50 c00b1e90 c00b0b7c 00000000 c7d5ff54 c7d5ff54 c7d5ff5c
ff60: c7d5ff5c c7d2b880 c7817500 be8e3e0c 00000000 be8e5fb4 00000016 c00370a4
ff80: c7d5e000 be8e5eec c7d5ffa4 c7d5ff98 c00b2164 c00b1e34 00000000 c7d5ffa8
ffa0: c0036f00 c00b2160 be8e3e0c 00000000 be8e5fb4 be8e3e0c be8e3e1a 00000000
ffc0: be8e3e0c 00000000 be8e5fb4 00000000 00000000 00000000 be8e5eec 00000000
ffe0: 40099450 be8e3de4 0006779c 40099458 20000010 be8e5fb4 e0830007 e0833006
Backtrace: [<c003a18c>] (__bug+0x0/0x2c) from [<c00fb2f0>] (logfs_clear_inode+0x8c/0xb0) [<c00fb264>] (logfs_clear_inode+0x0/0xb0) from [<c00ad358>] (clear_inode+0xac/0x114) [<c00ad2ac>] (clear_inode+0x0/0x114) from [<c00ad3e4>] (dispose_list+0x24/0xf0) r4:c7819870 [<c00ad3c0>] (dispose_list+0x0/0xf0) from [<c00ad5a8>] (invalidate_inodes+0xf8/0x12c) r7:c7d46a64 r6:c7819880 r5:c7d46a54 r4:c7d46a64 [<c00ad4b0>] (invalidate_inodes+0x0/0x12c) from [<c009c8ec>] (generic_shutdown_super+0xb0/0x11c) [<c009c83c>] (generic_shutdown_super+0x0/0x11c) from [<c00feb38>] (logfs_kill_sb+0x48/0xfc) r6:c7d2b880 r5:c7c14000 r4:c7d46a00 [<c00feaf0>] (logfs_kill_sb+0x0/0xfc) from [<c009c740>] (deactivate_super+0x48/0x60) r6:c7d2b880 r5:c02b7b84 r4:c7d46a00 [<c009c6f8>] (deactivate_super+0x0/0x60) from [<c00b0bd0>] (mntput_no_expire+0x64/0xbc) r5:c7d46a00 r4:c7d2b880 [<c00b0b6c>] (mntput_no_expire+0x0/0xbc) from [<c00b1e90>] (sys_umount+0x6c/0x32c) r5:c7d2b898 r4:00000000 [<c00b1e24>] (sys_umount+0x0/0x32c) from [<c00b2164>] (sys_oldumount+0x14/0x18) [<c00b2150>] (sys_oldumount+0x0/0x18) from [<c0036f00>] (ret_fast_syscall+0x0/0x2c) Code: e1a01000 e59f000c eb003605 e3a03000 (e5833000) ---[ end trace 979e02c61e928049 ]--- ------------[ cut here ]------------ WARNING: at kernel/exit.c:907 do_exit+0x50c/0x628() Modules linked in: Backtrace: [<c003a3dc>] (dump_backtrace+0x0/0x12c) from [<c003a520>] (dump_stack+0x18/0x1c) r7:00000000 r6:c00493a4 r5:c02794cc r4:0000038b [<c003a508>] (dump_stack+0x0/0x1c) from [<c0046a38>] (warn_slowpath_common+0x4c/0x64) [<c00469ec>] (warn_slowpath_common+0x0/0x64) from [<c0046a68>] (warn_slowpath_null+0x18/0x1c) r7:c7d5fcdf r6:c7c8cc00 r5:00000000 r4:0000000b [<c0046a50>] (warn_slowpath_null+0x0/0x1c) from [<c00493a4>] (do_exit+0x50c/0x628) [<c0048e98>] (do_exit+0x0/0x628) from [<c003a7bc>] (die+0x27c/0x2b4) [<c003a540>] (die+0x0/0x2b4) from [<c003be7c>] (__do_kernel_fault+0x6c/0x8c) [<c003be10>] (__do_kernel_fault+0x0/0x8c) from [<c003c108>] (do_page_fault+0x198/0x1d8) r8:00000000 r7:00010000 r6:c7d341b4 r5:c7d34180 r4:c7d33d74 [<c003bf70>] (do_page_fault+0x0/0x1d8) from [<c0036210>] (do_DataAbort+0x40/0xa8) [<c00361d0>] (do_DataAbort+0x0/0xa8) from [<c0036a80>] (__dabt_svc+0x40/0x60) Exception stack(0xc7d5fe18 to 0xc7d5fe60)
fe00: 0000002f 000019c2
fe20: 60000013 00000000 c7819870 c7819878 c7d5feb4 00000003 c7d5feb4 00000000
fe40: 00000003 c7d5fe6c c7d5fd98 c7d5fe60 c004760c c003a1ac 60000013 ffffffff
r8:c7d5feb4 r7:00000003 r6:c7d5feb4 r5:c7d5fe4c r4:ffffffff
[<c003a18c>] (__bug+0x0/0x2c) from [<c00fb2f0>] (logfs_clear_inode+0x8c/0xb0) [<c00fb264>] (logfs_clear_inode+0x0/0xb0) from [<c00ad358>] (clear_inode+0xac/0x114)
[<c00ad2ac>] (clear_inode+0x0/0x114) from [<c00ad3e4>] (dispose_list+0x24/0xf0)
r4:c7819870
[<c00ad3c0>] (dispose_list+0x0/0xf0) from [<c00ad5a8>] (invalidate_inodes+0xf8/0x12c)
r7:c7d46a64 r6:c7819880 r5:c7d46a54 r4:c7d46a64
[<c00ad4b0>] (invalidate_inodes+0x0/0x12c) from [<c009c8ec>] (generic_shutdown_super+0xb0/0x11c)
[<c009c83c>] (generic_shutdown_super+0x0/0x11c) from [<c00feb38>] (logfs_kill_sb+0x48/0xfc)
r6:c7d2b880 r5:c7c14000 r4:c7d46a00
[<c00feaf0>] (logfs_kill_sb+0x0/0xfc) from [<c009c740>] (deactivate_super+0x48/0x60)
r6:c7d2b880 r5:c02b7b84 r4:c7d46a00
[<c009c6f8>] (deactivate_super+0x0/0x60) from [<c00b0bd0>] (mntput_no_expire+0x64/0xbc)
r5:c7d46a00 r4:c7d2b880
[<c00b0b6c>] (mntput_no_expire+0x0/0xbc) from [<c00b1e90>] (sys_umount+0x6c/0x32c)
r5:c7d2b898 r4:00000000
[<c00b1e24>] (sys_umount+0x0/0x32c) from [<c00b2164>] (sys_oldumount+0x14/0x18) [<c00b2150>] (sys_oldumount+0x0/0x18) from [<c0036f00>] (ret_fast_syscall+0x0/0x2c)
---[ end trace 979e02c61e92804a ]---
Segmentation fault
Today I have to work for money....probably I have no much time to test .... As soon as I can I'm happy to give my contribute to test.
Paolo
Re: [PATCH 2/2] [MTD] Call bdi_init() and bdi_register()
Quoted 5 lines · Paolo Minazzi
Ok, now it is very better.
My problem now is that logfs does not save files in the following case:
1) power-off, then power-on (without umount)
2) sync, then power-off, then power-on (without umount)
Ok, I'll have a look.
Can we move this and any other logfs problems to a seperate thread? I'd like to leave this one for the sync issues and not spam everyone on Cc:
with unrelated bugs. :)
Jörn
Signature · 2 lines
Don't patch bad code, rewrite it. -- Kernigham and Pike, according to Rusty
Re: [PATCH 1/2] [MTD] Move mtd_bdi_*mappable to mtdcore.c
In reply to Jörn EngelQuoted 14 lines · Jörn Engel
Quoted 5 lines · Jens Axboe
Took a quick look, and you want
bdi_setup_and_register()for the three bdis listed inmtdbdi.cin mtdcore.c:init_mtd(). Or manualbdi_init()andbdi_register(). I'll take a look post-dinner. Either is workable, but since the flags are already setup, the latter may be cleaner.Ok, here are two patches that appear to solve the problem for me.
drivers/mtd/devices/drais.c +0
-0
drivers/mtd/devices/drais.c line 36
Quoted 5 lines
drivers/mtd/devices/drais.c +1
-1@@ -33,7 +33,7 @@#include <linux/sched.h> #include "drais.h" -#undef DEBUG_ERASE +#define DEBUG_ERASE
Leftover debugging?
Signature · 1 line
Jens Axboe
Re: [PATCH 1/2] [MTD] Move mtd_bdi_*mappable to mtdcore.c
Quoted 10 lines · Jens Axboe
Quoted 9 lines · Jörn Engel
drivers/mtd/devices/drais.c +0
-0@@ -33,7 +33,7 @@#include <linux/sched.h> #include "drais.h"
Quoted 4 lines
drivers/mtd/devices/drais.c line 36
Quoted 2 lines
drivers/mtd/devices/drais.c +1
-1-#undef DEBUG_ERASE +#define DEBUG_ERASE Leftover debugging?
Yes. Can you just remove that hunk or should I resend?
Jörn
Signature · 2 lines
"Error protection by error detection and correction." -- from a university class
Re: [PATCH 1/2] [MTD] Move mtd_bdi_*mappable to mtdcore.c
Quoted 11 lines · Jörn Engel
Quoted 10 lines · Jens Axboe
Quoted 9 lines · Jörn Engel
drivers/mtd/devices/drais.c +0
-0@@ -33,7 +33,7 @@#include <linux/sched.h> #include "drais.h"
Quoted 6 lines
Quoted 4 lines
drivers/mtd/devices/drais.c line 36
Quoted 2 lines
drivers/mtd/devices/drais.c +1
-1-#undef DEBUG_ERASE +#define DEBUG_ERASE Leftover debugging?
Yes. Can you just remove that hunk or should I resend?
I can kill that hunk, no problem.
Signature · 1 line
Jens Axboe
Quoted 26 lines · Jörn Engel
Quoted 4 lines · Jens Axboe
Thanks, we definitely should have put a debug statement to catch this in from day 1, good debugging should be an important part of any new infrastructure.
Woke up early and had another look at this. Looks like a much more widespread problem. Based on a quick grep an uncaffeinated brain:
9p no
s_bdi
afs nos_bdi
ceph creates its owns_bdi
cifs nos_bdi
coda nos_bdi
ecryptfs nos_bdi
exofs nos_bdi
fuse creates its owns_bdi?
gfs2 creates its owns_bdi?
jffs2 patch exists
logfs fixed now
ncpfs nos_bdi
nfs creates its owns_bdi
ocfs2 nos_bdi
smbfs nos_bdi
ubifs creates its owns_bdi
Quoted 3 lines
I excluded all filesystems that appear to be read-only, block device based or lack any sort of backing store. So there is a chance I have missed some as well.
It's funky, I was pretty sure there was/is code to set a default bdi for non-bdev file systems. It appears to be missing, that's not good. So options include:
- Add the appropriate per-sb bdi for these file systems (right fix), or
- Pre-fill default_backing_dev_info as a fallback ->s_bdi to at least ensure that data gets flushed (quick fix)
I'll slap together a set of fixes for this.
Signature · 1 line
Jens Axboe
Quoted 35 lines · Jens Axboe
Quoted 26 lines · Jörn Engel
Quoted 4 lines · Jens Axboe
Thanks, we definitely should have put a debug statement to catch this in from day 1, good debugging should be an important part of any new infrastructure.
Woke up early and had another look at this. Looks like a much more widespread problem. Based on a quick grep an uncaffeinated brain:
9p no
s_bdi
afs nos_bdi
ceph creates its owns_bdi
cifs nos_bdi
coda nos_bdi
ecryptfs nos_bdi
exofs nos_bdi
fuse creates its owns_bdi?
gfs2 creates its owns_bdi?
jffs2 patch exists
logfs fixed now
ncpfs nos_bdi
nfs creates its owns_bdi
ocfs2 nos_bdi
smbfs nos_bdi
ubifs creates its owns_bdiQuoted 3 lines
I excluded all filesystems that appear to be read-only, block device based or lack any sort of backing store. So there is a chance I have missed some as well.
It's funky, I was pretty sure there was/is code to set a default bdi for non-bdev file systems. It appears to be missing, that's not good. So options include:
Quoted 5 lines
- Add the appropriate per-sb bdi for these file systems (right fix), or
- Pre-filldefault_backing_dev_infoas a fallback ->s_bdi to at least ensure that data gets flushed (quick fix)I'll slap together a set of fixes for this.
Here's a series for fixing these. At this point they are totally untested except that I did compile them. Note that your analysis appeared correct for all cases but ocfs2, which does use get_sb_bdev() and hence gets ->s_bdi assigned.
You can see them here, I'll post the series soon:
http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=refs/heads/for-linus
The first patch is a helper addition, the rest are per-fs fixups.
Signature · 1 line
Jens Axboe
Quoted 11 lines · Jens Axboe
Here's a series for fixing these. At this point they are totally untested except that I did compile them. Note that your analysis appeared correct for all cases but ocfs2, which does use
get_sb_bdev()and hence gets ->s_bdi assigned.You can see them here, I'll post the series soon:
http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=refs/heads/for-linus
The first patch is a helper addition, the rest are per-fs fixups.
Do you want to include Jörn's addition of same to get_sb_mtd_set(), with my Acked-By: David Woodhouse <[email protected]> ?
Signature · 2 lines
David Woodhouse Open Source Technology Centre [email protected] Intel Corporation
Quoted 7 lines · David Woodhouse
Quoted 6 lines · Jens Axboe
Here's a series for fixing these. At this point they are totally untested except that I did compile them. Note that your analysis appeared correct for all cases but ocfs2, which does use
get_sb_bdev()and hence gets ->s_bdi assigned.
Quoted 8 lines
Quoted 5 lines
You can see them here, I'll post the series soon:
http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=refs/heads/for-linus
The first patch is a helper addition, the rest are per-fs fixups.
Do you want to include Jörn's addition of same to
get_sb_mtd_set(), with my Acked-By: David Woodhouse <[email protected]> ?
Yeah will do. I also really wanted to provide a WARN and mount fail if we get it wrong, but I don't see an easy way to do that. Basically I'd want to check whether the storage backing is volatile or not.
Signature · 1 line
Jens Axboe
Quoted 11 lines · Jens Axboe
Here's a series for fixing these. At this point they are totally untested except that I did compile them. Note that your analysis appeared correct for all cases but ocfs2, which does use
get_sb_bdev()and hence gets ->s_bdi assigned.You can see them here, I'll post the series soon:
http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=refs/heads/for-linus
The first patch is a helper addition, the rest are per-fs fixups.
Looks good at a cursory glance. What's still missing is some sort of assertion. You are a smart person and missed this problem, twice even. Even if you hadn't, a not so smart person can add a new filesystem and miss s_bdi, like I did. We want some automatism to catch this.
Jörn
Signature · 2 lines
"Security vulnerabilities are here to stay." -- Scott Culp, Manager of the Microsoft Security Response Center, 2001
Quoted 9 lines · Jörn Engel
Quoted 8 lines · Jens Axboe
Here's a series for fixing these. At this point they are totally untested except that I did compile them. Note that your analysis appeared correct for all cases but ocfs2, which does use
get_sb_bdev()and hence gets ->s_bdi assigned.You can see them here, I'll post the series soon:
Quoted 8 lines
Quoted 3 lines
http://git.kernel.dk/?p=linux-2.6-block.git;a=shortlog;h=refs/heads/for-linus
The first patch is a helper addition, the rest are per-fs fixups.
Looks good at a cursory glance. What's still missing is some sort of assertion. You are a smart person and missed this problem, twice even. Even if you hadn't, a not so smart person can add a new filesystem and miss
s_bdi, like I did. We want some automatism to catch this.
I totally agree, we want some way to catch this problem in the future. Really the check needs to be something ala:
if (!sb->s_bdi && mnt_has_storage_backing() && rw_mount)
yell_and_fail;but I'm not sure how best to accomplish that. We can check for ->s_bdev and mtd like you did, but that does not catch network file systems for instance.
Signature · 1 line
Jens Axboe
Quoted 10 lines · Jens Axboe
I totally agree, we want some way to catch this problem in the future. Really the check needs to be something ala:
if (!sb->s_bdi && mnt_has_storage_backing() && rw_mount) yell_and_fail;but I'm not sure how best to accomplish that. We can check for ->s_bdev and mtd like you did, but that does not catch network file systems for instance.
One way would be to either add a flag to all safe filesystems or create a noop_bdi for them. It adds a line of code and some bytes[*] per instance to most filesystems, but that's the only catchall I can think of.
I guess if noone comes up with a better plan I'll look into that.
[*] Maybe we can steal a bit somewhere to make it less expensive.
Jörn
Signature · 4 lines
You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is. -- Rob Pike