Messages in this thread Patch in this message | | | Date | Wed, 5 Feb 2003 18:40:21 +0100 | From | Andrea Arcangeli <> | Subject | 2.5 changeset 1.952.4.2 corrupt in fs/jfs/inode.c |
| |
Hello Larry,
If you apply all changeset in order starting from 2.5.59 until 1.952.4.2 you should get a fs/jfs/inode.c like this:
void jfs_truncate(struct inode *ip) { jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size));
block_truncate_page(ip->i_mapping, ip->i_size, jfs_get_block); ^^^^^^^^^^^^^^^^^^^
but the changeset 1.952.4.2 is the below one and it shows:
@@ -378,7 +377,7 @@
void jfs_truncate(struct inode *ip) { - jFYI(1, ("jfs_truncate: size = 0x%lx\n", (ulong) ip->i_size)); + jfs_info("jfs_truncate: size = 0x%lx", (ulong) ip->i_size);
nobh_truncate_page(ip->i_mapping, ip->i_size); ^^^^^^^^^^^^^^^^^^
so it thinks the function is called nobh_truncate_page and not block_truncate_page. Note, I'm using my own GPL software to checkout from the bitkeeper servers (I don't want to miss the additional information stored in proprietary form inside the bitkepper database and so I'm extracting it all and storing it in a open manner locally, in a complete structured form, they're live classes dumped to disk, not like the monolithic patches in the cset/ directory where it's not trivial to manage all the metadata to see all the evolution of a certain file or subsystem by writing a few more lines of code that loads and use those classes) so it could be my bug and not a bug in bitkeeper, no idea if it's reproducible with bitkeeper. I hope I'm not wasting your time and that it's not a bug from my part ;)
btw, the changeset would apply anyways despite the corrupted patch, if I'd use the default fuzz level of patch, but still it looks corrupted and a bug that needs fixing (either from my part or your part) so I'm not going to ignore it even if it doesn't literally reject.
See:
http://linux.bkbits.net:8080/linux-2.5/patch@1.952.4.2?nav=index.html|ChangeSet@-4w|cset@1.952.4.2 I'd appreciate if you could check why bitkeeper thinks such function is nobh_truncate_page and not block_truncate_page as my GPL software pretends while it checkouts all the changesets from the bitkeeper servers.
Thanks,
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |