[RFC PATCH 1/2] Remove highmem.h include from pagemap.h
There has been a long-standing wart in linux/swap.h where it uses page_cache_release and release_pages without declaring them by including linux/pagemap.h. There is this scary comment to warn off anyone foolish enough to try to fix this: /* only sparc can not include linux/pagemap.h in this file * so leave page_cache_release and release_pages undeclared... */ This has caused problems for a number of people including: akpm - http://www.ussg.iu.edu/hypermail/linux/kernel/0708.3/0446.html Oh that damn thing again. It's a regular source of include breakage. ppc - http://patchwork.ozlabs.org/linuxppc/patch?id=12288 UML - http://www.mail-archive.com/[EMAIL PROTECTED]/msg05095.html What happens with sparc, when this include is added, is a linux/mm.h - linux/mm.h recursion: linux/mm.h - asm/pgtable.h - linux/swap.h - linux/pagemap.h - linux/highmem.h - linux/mm.h leaving various things that live in mm.h undefined in highmem.h. sparc is unique in the asm/pgtable.h - linux/swap.h inclusion. This looks correct, as pgtable.h uses swp_entry_t, which is defined in swap.h, so maybe the other arches should do the same. Adding this to the UML pgtable.h causes the same build breakage. All of the links in the recursion above look reasonable, except for linux/pagemap.h - linux/highmem.h, which is the point of attack for this fix. linux/pagemap.h uses nothing from linux/highmem.h, so doesn't need to include it. However, there are a number of files which use stuff from highmem.h, don't include it, but do include pagemap.h. This patch removes the linux/pagemap.h - linux/highmem.h inclusion and adds a linux/highmem.h include to every file in the tree which now needs one. --- arch/parisc/kernel/cache.c |1 + drivers/block/rd.c |1 + drivers/dma/iovlock.c|1 + drivers/media/video/ivtv/ivtv-udma.c |1 + drivers/net/e1000/e1000_main.c |1 + drivers/net/e1000e/netdev.c |1 + fs/9p/vfs_addr.c |1 + fs/affs/file.c |1 + fs/affs/symlink.c|1 + fs/afs/dir.c |1 + fs/afs/fsclient.c|1 + fs/afs/mntpt.c |1 + fs/afs/rxrpc.c |1 + fs/afs/write.c |1 + fs/cifs/file.c |1 + fs/cifs/inode.c |1 + fs/coda/symlink.c|1 + fs/cramfs/inode.c|1 + fs/dlm/lowcomms.c|1 + fs/ecryptfs/mmap.c |1 + fs/ecryptfs/read_write.c |1 + fs/efs/symlink.c |1 + fs/ext2/dir.c|1 + fs/ext2/namei.c |1 + fs/ext3/inode.c |1 + fs/ext4/extents.c|1 + fs/ext4/inode.c |1 + fs/freevxfs/vxfs_immed.c |1 + fs/freevxfs/vxfs_subr.c |1 + fs/fuse/dev.c|1 + fs/gfs2/bmap.c |1 + fs/gfs2/lops.c |1 + fs/gfs2/ops_address.c|1 + fs/gfs2/ops_file.c |1 + fs/hfs/bnode.c |1 + fs/hfs/btree.c |1 + fs/hfsplus/bitmap.c |1 + fs/hfsplus/bnode.c |1 + fs/hfsplus/btree.c |1 + fs/hostfs/hostfs_kern.c |1 + fs/hpfs/namei.c |1 + fs/isofs/compress.c |1 + fs/isofs/rock.c |1 + fs/jbd/journal.c |1 + fs/jbd2/journal.c|1 + fs/jffs2/fs.c|1 + fs/jfs/super.c |1 + fs/libfs.c |1 + fs/minix/namei.c |1 + fs/namei.c |1 + fs/ncpfs/dir.c |1 + fs/ncpfs/mmap.c |1 + fs/ncpfs/symlink.c |1 + fs/nfs/dir.c |1 + fs/nfs/nfs2xdr.c |1 + fs/nfs/nfs3xdr.c |1 + fs/nfs/nfs4proc.c|1 + fs/nfs/nfs4xdr.c |1 + fs/nfs/read.c|1 + fs/nfs/symlink.c |1 + fs/nfs/write.c |1 + fs/ntfs/aops.c |1 + fs/ntfs/file.c |1 + fs/ocfs2/symlink.c |1 + fs/reiserfs/ioctl.c |1 + fs/reiserfs/stree.c |1 + fs/reiserfs/tail_conversion.c|1 + fs/reiserfs/xattr.c |1 + fs/romfs/inode.c |1 +
[RFC PATCH 0/2] Fix linux/swap.h build wart
For some time, there has been a problem of linux/swap.h using page_cache_release and release_pages without declaring them by including linux/pagemap.h. pagemap.h isn't included because that breaks the sparc build. The full details are in the next post, but the short story is that sparc's pgtable.h includes linux/swap.h, creating a mm.h - mm.h recursion. The current tree breaks that recursion by removing the swap.h - pagemap.h inclusion. This breaks builds on a regular basis (references also in the next post). These patches propose to break the recursion instead by removing the linux/pagemap.h - linux/highmem.h inclusion. I'd like to know whether there are any fundamental reasons that this include should be preserved. The reason for choosing this include is that pagemap.h doesn't use anything exported by highmem.h. The downside is that a bunch of things now need to include highmem.h. These are mostly filesystems, plus a good amount of arch code and a few drivers. I would argue that if you use something from a header, you should include it, regardless of whether you already get the header indirectly, so this isn't too much of a downside as far as I'm concerned. The one thing I'm uncertain about is whether pagemap.h and highmem.h have some basic relationship that implies that you can assume you get highmem when you include pagemap. The two patches that follow do the following: remove highmem.h from pagemap.h and add includes of highmem.h to a number of files that now need them include pagemap.h in swap.h These are for comment only, not for mainline, so there's no S-o-b right yet. At this point, I haven't confirmed that the following files, which use stuff from highmem.h but don't include it, still build: ./arch/x86/kernel/crash_dump_64.c ./arch/frv/mm/fault.c ./arch/frv/mm/kmap.c ./arch/h8300/mm/kmap.c ./arch/ia64/kernel/crash_dump.c ./arch/m68k/mm/kmap.c ./arch/m68knommu/mm/kmap.c ./arch/powerpc/kernel/crash_dump.c ./arch/sh/kernel/crash_dump.c ./arch/xtensa/mm/pgtable.c ./drivers/block/ps3disk.c ./drivers/infiniband/hw/ipath/ipath_verbs.h ./drivers/mmc/host/at91_mci.c ./drivers/mmc/host/mmci.h ./drivers/mmc/host/mmc_spi.c ./drivers/s390/block/xpram.c ./drivers/s390/char/tape_34xx.c ./drivers/kvm/paging_tmpl.h ./fs/hfsplus/hfsplus_fs.h ./include/asm-arm/cacheflush.h ./include/asm-frv/pgtable.h ./include/asm-x86/kexec_32.h ./include/asm-x86/kexec_64.h ./include/asm-x86/pgtable_32.h ./include/asm-m68k/motorola_pgalloc.h ./include/asm-m68k/sun3_pgalloc.h ./include/asm-m68k/sun3_pgtable.h ./include/asm-mips/cacheflush.h ./include/asm-mips/page.h ./include/asm-parisc/cacheflush.h ./include/asm-powerpc/pgtable-ppc32.h ./include/asm-ppc/pgtable.h ./include/asm-s390/kexec.h ./include/asm-sh/kexec.h ./mm/migrate.c Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/2] Fix linux/swap.h build wart
On Fri, Oct 26, 2007 at 01:38:12PM -0700, Luck, Tony wrote: Not fundamental reasons, but these patches break the ia64 build for most configs with: In file included from kernel/futex.c:59: include/asm/futex.h: In function `futex_atomic_op_inuser': include/asm/futex.h:62: error: implicit declaration of function `pagefault_disable' include/asm/futex.h:86: error: implicit declaration of function `pagefault_enable' make[1]: *** [kernel/futex.o] Error 1 Adding an include of linux/uaccess.h to kernel/futex.c is sufficient (but not necessarily right) to unbreak this. Yeah, I've been changing asm/uaccess.h to linux/uaccess.h for these. Looks like I'll need to make a pass over all the futex.h's. A few configs also fail with: mm/migrate.c: In function `migrate_page_copy': mm/migrate.c:359: error: implicit declaration of function `copy_highpage' make[1]: *** [mm/migrate.o] Error 1 Making mm/migrate.c include linux/highmem.h fixes this one. Excellent, I hadn't yet figured out who used migrate.c. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck
On Thu, Apr 26, 2007 at 09:58:25PM -0700, Valerie Henson wrote: Here's an example, spelled out: Allocate file 1 in chunk A. Grow file 1. Chunk A fills up. Allocate continuation inode for file 1 in chunk B. Chunk A gets some free space. Chunk B fills up. Pick chunk A for allocating next block of file 1. Try to look up a continuation inode for file 1 in chunk A. Continuation inode for file 1 found in chunk A! Attach newly allocated block to existing inode for file 1 in chunk A. So far, so good (and the slides are helpful, tx!). What happens when file 1 keeps growing and chunk A fills up (and chunk B is still full)? Can the same continuation inode also point at chunk C, where the file is going to grow to? Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 37/44] hostfs convert to new aops
On Tue, Apr 24, 2007 at 11:24:23AM +1000, Nick Piggin wrote: This also gets rid of a lot of useless read_file stuff. And also optimises the full page write case by marking a !uptodate page uptodate. Cc: Jeff Dike [EMAIL PROTECTED] Cc: Linux Filesystems linux-fsdevel@vger.kernel.org Signed-off-by: Nick Piggin [EMAIL PROTECTED] Looks good. Acked-by: Jeff Dike [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck
On Wed, Apr 25, 2007 at 03:47:10PM -0700, Valerie Henson wrote: Actually, there is an upper limit on the number of continuation inodes. Each file can have a maximum of one continuation inode per chunk. (This is why we need to support sparse files.) How about this case: Growing file starts in chunk A. Overflows into chunk B. Delete file in chunk A. Growing file overflows chunk B and spots new free space in chunk A (and nothing anywhere else) Overflows into chunk A Delete file in chunk B. Overflow into chunk B again. Maybe this is not realistic, but in the absence of a mechanism to pull data back from an overflow chunk, it seems at least a theoretical possibility that there could be 1 continuation inodes per file per chunk. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH] ChunkFS: fs fission for faster fsck
On Thu, Apr 26, 2007 at 10:53:16AM -0500, Amit Gud wrote: Jeff Dike wrote: How about this case: Growing file starts in chunk A. Overflows into chunk B. Delete file in chunk A. Growing file overflows chunk B and spots new free space in chunk A (and nothing anywhere else) Overflows into chunk A Delete file in chunk B. Overflow into chunk B again. Maybe this is not realistic, but in the absence of a mechanism to pull data back from an overflow chunk, it seems at least a theoretical possibility that there could be 1 continuation inodes per file per chunk. Preventive measures are taken to limit only one continuation inode per file per chunk. This can be done easily in the chunk allocation algorithm for disk space. Although I'm not quite sure what you mean by Delete file in chunk A. If you are referring to same file thats growing, then deletion is not possible, because individual parts of any file in any chunk cannot be deleted. No, I'm referring to a different file. The scenario is that you have a growing file in a nearly full disk with files being deleted (and thus space being freed) such that allocations for the growing file bounce back and forth between chunks. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
