28 Sep, 2016

1 commit

  • CURRENT_TIME macro is not appropriate for filesystems as it
    doesn't use the right granularity for filesystem timestamps.
    Use current_time() instead.

    CURRENT_TIME is also not y2038 safe.

    This is also in preparation for the patch that transitions
    vfs timestamps to use 64 bit time and hence make them
    y2038 safe. As part of the effort current_time() will be
    extended to do range checks. Hence, it is necessary for all
    file system timestamps to use current_time(). Also,
    current_time() will be transitioned along with vfs to be
    y2038 safe.

    Note that whenever a single call to current_time() is used
    to change timestamps in different inodes, it is because they
    share the same time granularity.

    Signed-off-by: Deepa Dinamani
    Reviewed-by: Arnd Bergmann
    Acked-by: Felipe Balbi
    Acked-by: Steven Whitehouse
    Acked-by: Ryusuke Konishi
    Acked-by: David Sterba
    Signed-off-by: Al Viro

    Deepa Dinamani
     

15 Jan, 2016

1 commit

  • Mark those kmem allocations that are known to be easily triggered from
    userspace as __GFP_ACCOUNT/SLAB_ACCOUNT, which makes them accounted to
    memcg. For the list, see below:

    - threadinfo
    - task_struct
    - task_delay_info
    - pid
    - cred
    - mm_struct
    - vm_area_struct and vm_region (nommu)
    - anon_vma and anon_vma_chain
    - signal_struct
    - sighand_struct
    - fs_struct
    - files_struct
    - fdtable and fdtable->full_fds_bits
    - dentry and external_name
    - inode for all filesystems. This is the most tedious part, because
    most filesystems overwrite the alloc_inode method.

    The list is far from complete, so feel free to add more objects.
    Nevertheless, it should be close to "account everything" approach and
    keep most workloads within bounds. Malevolent users will be able to
    breach the limit, but this was possible even with the former "account
    everything" approach (simply because it did not account everything in
    fact).

    [akpm@linux-foundation.org: coding-style fixes]
    Signed-off-by: Vladimir Davydov
    Acked-by: Johannes Weiner
    Acked-by: Michal Hocko
    Cc: Tejun Heo
    Cc: Greg Thelen
    Cc: Christoph Lameter
    Cc: Pekka Enberg
    Cc: David Rientjes
    Cc: Joonsoo Kim
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Vladimir Davydov
     

09 Dec, 2015

1 commit

  • kmap() in page_follow_link_light() needed to go - allowing to hold
    an arbitrary number of kmaps for long is a great way to deadlocking
    the system.

    new helper (inode_nohighmem(inode)) needs to be used for pagecache
    symlinks inodes; done for all in-tree cases. page_follow_link_light()
    instrumented to yell about anything missed.

    Signed-off-by: Al Viro

    Al Viro
     

07 Dec, 2015

1 commit


19 Nov, 2012

1 commit


03 Oct, 2012

3 commits

  • Pull vfs update from Al Viro:

    - big one - consolidation of descriptor-related logics; almost all of
    that is moved to fs/file.c

    (BTW, I'm seriously tempted to rename the result to fd.c. As it is,
    we have a situation when file_table.c is about handling of struct
    file and file.c is about handling of descriptor tables; the reasons
    are historical - file_table.c used to be about a static array of
    struct file we used to have way back).

    A lot of stray ends got cleaned up and converted to saner primitives,
    disgusting mess in android/binder.c is still disgusting, but at least
    doesn't poke so much in descriptor table guts anymore. A bunch of
    relatively minor races got fixed in process, plus an ext4 struct file
    leak.

    - related thing - fget_light() partially unuglified; see fdget() in
    there (and yes, it generates the code as good as we used to have).

    - also related - bits of Cyrill's procfs stuff that got entangled into
    that work; _not_ all of it, just the initial move to fs/proc/fd.c and
    switch of fdinfo to seq_file.

    - Alex's fs/coredump.c spiltoff - the same story, had been easier to
    take that commit than mess with conflicts. The rest is a separate
    pile, this was just a mechanical code movement.

    - a few misc patches all over the place. Not all for this cycle,
    there'll be more (and quite a few currently sit in akpm's tree)."

    Fix up trivial conflicts in the android binder driver, and some fairly
    simple conflicts due to two different changes to the sock_alloc_file()
    interface ("take descriptor handling from sock_alloc_file() to callers"
    vs "net: Providing protocol type via system.sockprotoname xattr of
    /proc/PID/fd entries" adding a dentry name to the socket)

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (72 commits)
    MAX_LFS_FILESIZE should be a loff_t
    compat: fs: Generic compat_sys_sendfile implementation
    fs: push rcu_barrier() from deactivate_locked_super() to filesystems
    btrfs: reada_extent doesn't need kref for refcount
    coredump: move core dump functionality into its own file
    coredump: prevent double-free on an error path in core dumper
    usb/gadget: fix misannotations
    fcntl: fix misannotations
    ceph: don't abuse d_delete() on failure exits
    hypfs: ->d_parent is never NULL or negative
    vfs: delete surplus inode NULL check
    switch simple cases of fget_light to fdget
    new helpers: fdget()/fdput()
    switch o2hb_region_dev_write() to fget_light()
    proc_map_files_readdir(): don't bother with grabbing files
    make get_file() return its argument
    vhost_set_vring(): turn pollstart/pollstop into bool
    switch prctl_set_mm_exe_file() to fget_light()
    switch xfs_find_handle() to fget_light()
    switch xfs_swapext() to fget_light()
    ...

    Linus Torvalds
     
  • There's no reason to call rcu_barrier() on every
    deactivate_locked_super(). We only need to make sure that all delayed rcu
    free inodes are flushed before we destroy related cache.

    Removing rcu_barrier() from deactivate_locked_super() affects some fast
    paths. E.g. on my machine exit_group() of a last process in IPC
    namespace takes 0.07538s. rcu_barrier() takes 0.05188s of that time.

    Signed-off-by: Kirill A. Shutemov
    Cc: Al Viro
    Signed-off-by: Andrew Morton
    Signed-off-by: Al Viro

    Kirill A. Shutemov
     
  • Pull user namespace changes from Eric Biederman:
    "This is a mostly modest set of changes to enable basic user namespace
    support. This allows the code to code to compile with user namespaces
    enabled and removes the assumption there is only the initial user
    namespace. Everything is converted except for the most complex of the
    filesystems: autofs4, 9p, afs, ceph, cifs, coda, fuse, gfs2, ncpfs,
    nfs, ocfs2 and xfs as those patches need a bit more review.

    The strategy is to push kuid_t and kgid_t values are far down into
    subsystems and filesystems as reasonable. Leaving the make_kuid and
    from_kuid operations to happen at the edge of userspace, as the values
    come off the disk, and as the values come in from the network.
    Letting compile type incompatible compile errors (present when user
    namespaces are enabled) guide me to find the issues.

    The most tricky areas have been the places where we had an implicit
    union of uid and gid values and were storing them in an unsigned int.
    Those places were converted into explicit unions. I made certain to
    handle those places with simple trivial patches.

    Out of that work I discovered we have generic interfaces for storing
    quota by projid. I had never heard of the project identifiers before.
    Adding full user namespace support for project identifiers accounts
    for most of the code size growth in my git tree.

    Ultimately there will be work to relax privlige checks from
    "capable(FOO)" to "ns_capable(user_ns, FOO)" where it is safe allowing
    root in a user names to do those things that today we only forbid to
    non-root users because it will confuse suid root applications.

    While I was pushing kuid_t and kgid_t changes deep into the audit code
    I made a few other cleanups. I capitalized on the fact we process
    netlink messages in the context of the message sender. I removed
    usage of NETLINK_CRED, and started directly using current->tty.

    Some of these patches have also made it into maintainer trees, with no
    problems from identical code from different trees showing up in
    linux-next.

    After reading through all of this code I feel like I might be able to
    win a game of kernel trivial pursuit."

    Fix up some fairly trivial conflicts in netfilter uid/git logging code.

    * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (107 commits)
    userns: Convert the ufs filesystem to use kuid/kgid where appropriate
    userns: Convert the udf filesystem to use kuid/kgid where appropriate
    userns: Convert ubifs to use kuid/kgid
    userns: Convert squashfs to use kuid/kgid where appropriate
    userns: Convert reiserfs to use kuid and kgid where appropriate
    userns: Convert jfs to use kuid/kgid where appropriate
    userns: Convert jffs2 to use kuid and kgid where appropriate
    userns: Convert hpfs to use kuid and kgid where appropriate
    userns: Convert btrfs to use kuid/kgid where appropriate
    userns: Convert bfs to use kuid/kgid where appropriate
    userns: Convert affs to use kuid/kgid wherwe appropriate
    userns: On alpha modify linux_to_osf_stat to use convert from kuids and kgids
    userns: On ia64 deal with current_uid and current_gid being kuid and kgid
    userns: On ppc convert current_uid from a kuid before printing.
    userns: Convert s390 getting uid and gid system calls to use kuid and kgid
    userns: Convert s390 hypfs to use kuid and kgid where appropriate
    userns: Convert binder ipc to use kuids
    userns: Teach security_path_chown to take kuids and kgids
    userns: Add user namespace support to IMA
    userns: Convert EVM to deal with kuids and kgids in it's hmac computation
    ...

    Linus Torvalds
     

21 Sep, 2012

1 commit


23 Jul, 2012

1 commit

  • LogFS does not use a specialized area to maintain the inodes. The
    inodes information is kept in a specialized file called inode file.
    Similarly, the segment information is kept in a segment file. Since
    the segment file also has an inode which is kept in the inode file,
    the inode for segment file must be evicted before the inode for inode
    file. The change fixes the following BUG during unmount

    Pid: 2057, comm: umount Not tainted 3.5.0-rc6+ #25 Bochs Bochs
    RIP: 0010:[] [] move_page_to_btree+0x32/0x1f0 [logfs]
    Process umount (pid: 2057, threadinfo ...)
    Call Trace:
    [] ? find_get_pages+0x2a/0x180
    [] logfs_invalidatepage+0x85/0x90 [logfs]
    [] truncate_inode_page+0xb1/0xd0
    [] truncate_inode_pages_range+0x15f/0x490
    [] ? printk+0x78/0x7a
    [] truncate_inode_pages+0x15/0x20
    [] logfs_evict_inode+0x6c/0x190 [logfs]
    [] ? _raw_spin_unlock+0x2b/0x40
    [] evict+0xa7/0x1b0
    [] dispose_list+0x3e/0x60
    [] evict_inodes+0xf4/0x110
    [] generic_shutdown_super+0x53/0xf0
    [] logfs_kill_sb+0x52/0xf0 [logfs]
    [] deactivate_locked_super+0x45/0x80
    [] deactivate_super+0x4a/0x70
    [] mntput_no_expire+0xde/0x140
    [] sys_umount+0x6f/0x3a0
    [] system_call_fastpath+0x16/0x1b
    ---[ end trace 45f7752082cefafd ]---

    Signed-off-by: Prasad Joshi

    Prasad Joshi
     

02 Apr, 2012

1 commit

  • We were assuming that the evict_inode() would never be called on
    reserved inodes. However, (after the commit 8e22c1a4e logfs: get rid
    of magical inodes) while unmounting the file system, in put_super, we
    call iput() on all of the reserved inodes.

    The following simple test used to cause a kernel panic on LogFS:

    1. Mount a LogFS file system on /mnt

    2. Create a file
    $ touch /mnt/a

    3. Try to unmount the FS
    $ umount /mnt

    The simple fix would be to drop the assumption and properly destroy
    the reserved inodes.

    Signed-off-by: Prasad Joshi

    Prasad Joshi
     

01 Feb, 2012

1 commit

  • There are few important bug fixes for LogFS

    * tag 'for-linus' of git://github.com/prasad-joshi/logfs_upstream:
    Logfs: Allow NULL block_isbad() methods
    logfs: Grow inode in delete path
    logfs: Free areas before calling generic_shutdown_super()
    logfs: remove useless BUG_ON
    MAINTAINERS: Add Prasad Joshi in LogFS maintiners
    logfs: Propagate page parameter to __logfs_write_inode
    logfs: set superblock shutdown flag after generic sb shutdown
    logfs: take write mutex lock during fsync and sync
    logfs: Prevent memory corruption
    logfs: update page reference count for pined pages

    Fix up conflict in fs/logfs/dev_mtd.c due to semantic change in what
    "mtd->block_isbad" means in commit f2933e86ad93: "Logfs: Allow NULL
    block_isbad() methods" clashing with the abstraction changes in the
    commits 7086c19d0742: "mtd: introduce mtd_block_isbad interface" and
    d58b27ed58a3: "logfs: do not use 'mtd->block_isbad' directly".

    This resolution takes the semantics from commit f2933e86ad93, and just
    makes mtd_block_isbad() return zero (false) if the 'block_isbad'
    function is NULL. But that also means that now "mtd_can_have_bb()"
    always returns 0.

    Now, "mtd_block_markbad()" will obviously return an error if the
    low-level driver doesn't support bad blocks, so this is somewhat
    non-symmetric, but it actually makes sense if a NULL "block_isbad"
    function is considered to mean "I assume that all my blocks are always
    good".

    Linus Torvalds
     

28 Jan, 2012

2 commits

  • During GC LogFS has to rewrite each valid block to a separate segment.
    Rewrite operation reads data from an old segment and writes it to a
    newly allocated segment. Since every write operation changes data
    block pointers maintained in inode, inode should also be rewritten.

    In GC path to avoid AB-BA deadlock LogFS marks a page with
    PG_pre_locked in addition to locking the page (PG_locked). The page
    lock is ignored iff the page is pre-locked.

    LogFS uses a special file called segment file. The segment file
    maintains an 8 bytes entry for every segment. It keeps track of erase
    count, level etc. for every segment.

    Bad things happen with a segment belonging to the segment file is GCed

    ------------[ cut here ]------------
    kernel BUG at /home/prasad/logfs/readwrite.c:297!
    invalid opcode: 0000 [#1] SMP
    Modules linked in: logfs joydev usbhid hid psmouse e1000 i2c_piix4
    serio_raw [last unloaded: logfs]
    Pid: 20161, comm: mount Not tainted 3.1.0-rc3+ #3 innotek GmbH
    VirtualBox
    EIP: 0060:[] EFLAGS: 00010292 CPU: 0
    EIP is at logfs_lock_write_page+0x6a/0x70 [logfs]
    EAX: 00000027 EBX: f73f5b20 ECX: c16007c8 EDX: 00000094
    ESI: 00000000 EDI: e59be6e4 EBP: c7337b28 ESP: c7337b18
    DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
    Process mount (pid: 20161, ti=c7336000 task=eb323f70 task.ti=c7336000)
    Stack:
    f8099a3d c7337b24 f73f5b20 00001002 c7337b50 f8091f6d f8099a4d f80994e4
    00000003 00000000 c7337b68 00000000 c67e4400 00001000 c7337b80 f80935e5
    00000000 00000000 00000000 00000000 e1fcf000 0000000f e59be618 c70bf900
    Call Trace:
    [] logfs_get_write_page.clone.16+0xdd/0x100 [logfs]
    [] logfs_mod_segment_entry+0x55/0x110 [logfs]
    [] logfs_get_segment_entry+0x1d/0x20 [logfs]
    [] ? logfs_cleanup_journal+0x50/0x50 [logfs]
    [] ostore_get_erase_count+0x1b/0x40 [logfs]
    [] logfs_open_area+0xc8/0x150 [logfs]
    [] ? kmemleak_alloc+0x2c/0x60
    [] __logfs_segment_write.clone.16+0x4e/0x1b0 [logfs]
    [] ? mempool_kmalloc+0x13/0x20
    [] ? mempool_kmalloc+0x13/0x20
    [] logfs_segment_write+0x17f/0x1d0 [logfs]
    [] logfs_write_i0+0x11c/0x180 [logfs]
    [] logfs_write_direct+0x45/0x90 [logfs]
    [] __logfs_write_buf+0xbd/0xf0 [logfs]
    [] ? kmap_atomic_prot+0x4e/0xe0
    [] logfs_write_buf+0x3b/0x60 [logfs]
    [] __logfs_write_inode+0xa9/0x110 [logfs]
    [] logfs_rewrite_block+0xc0/0x110 [logfs]
    [] ? get_mapping_page+0x10/0x60 [logfs]
    [] ? logfs_load_object_aliases+0x2e0/0x2f0 [logfs]
    [] logfs_gc_segment+0x2ad/0x310 [logfs]
    [] __logfs_gc_once+0x4a/0x80 [logfs]
    [] logfs_gc_pass+0x683/0x6a0 [logfs]
    [] logfs_mount+0x5a9/0x680 [logfs]
    [] mount_fs+0x21/0xd0
    [] ? __alloc_percpu+0xf/0x20
    [] ? alloc_vfsmnt+0xb1/0x130
    [] vfs_kern_mount+0x4b/0xa0
    [] do_kern_mount+0x3e/0xe0
    [] do_mount+0x34d/0x670
    [] ? strndup_user+0x49/0x70
    [] sys_mount+0x6b/0xa0
    [] syscall_call+0x7/0xb
    Code: f8 e8 8b 93 39 c9 8b 45 f8 3e 0f ba 28 00 19 d2 85 d2 74 ca eb d0 0f 0b 8d 45 fc 89 44 24 04 c7 04 24 3d 9a 09 f8 e8 09 92 39 c9 0b 8d 74 26 00 55 89 e5 3e 8d 74 26 00 8b 10 80 e6 01 74 09
    EIP: [] logfs_lock_write_page+0x6a/0x70 [logfs] SS:ESP 0068:c7337b18
    ---[ end trace 96e67d5b3aa3d6ca ]---

    The patch passes locked page to __logfs_write_inode. It calls function
    logfs_get_wblocks() to pre-lock the page. This ensures any further
    attempts to lock the page are ignored (esp from get_erase_count).

    Acked-by: Joern Engel
    Signed-off-by: Prasad Joshi

    Prasad Joshi
     
  • LogFS uses super->s_write_mutex while writing data to disk. Taking the
    same mutex lock in sync and fsync code path solves the following BUG:

    ------------[ cut here ]------------
    kernel BUG at /home/prasad/logfs/dev_bdev.c:134!

    Pid: 2387, comm: flush-253:16 Not tainted 3.0.0+ #4 Bochs Bochs
    RIP: 0010:[] []
    bdev_writeseg+0x25d/0x270 [logfs]
    Call Trace:
    [] logfs_open_area+0x91/0x150 [logfs]
    [] ? find_level.clone.9+0x62/0x100
    [] __logfs_segment_write.clone.20+0x5c/0x190 [logfs]
    [] ? mempool_kmalloc+0x15/0x20
    [] ? mempool_alloc+0x53/0x130
    [] logfs_segment_write+0x1d4/0x230 [logfs]
    [] logfs_write_i0+0x12e/0x190 [logfs]
    [] __logfs_write_rec+0x140/0x220 [logfs]
    [] logfs_write_rec+0x64/0xd0 [logfs]
    [] __logfs_write_buf+0x106/0x110 [logfs]
    [] logfs_write_buf+0x4e/0x80 [logfs]
    [] __logfs_writepage+0x23/0x80 [logfs]
    [] logfs_writepage+0xdc/0x110 [logfs]
    [] __writepage+0x17/0x40
    [] write_cache_pages+0x208/0x4f0
    [] ? set_page_dirty+0x70/0x70
    [] generic_writepages+0x4a/0x70
    [] do_writepages+0x21/0x40
    [] writeback_single_inode+0x101/0x250
    [] writeback_sb_inodes+0xed/0x1c0
    [] writeback_inodes_wb+0x7b/0x1e0
    [] wb_writeback+0x4c3/0x530
    [] ? sub_preempt_count+0x9d/0xd0
    [] wb_do_writeback+0xdb/0x290
    [] ? sub_preempt_count+0x9d/0xd0
    [] ? _raw_spin_unlock_irqrestore+0x18/0x40
    [] ? del_timer+0x8a/0x120
    [] bdi_writeback_thread+0x8c/0x2e0
    [] ? wb_do_writeback+0x290/0x290
    [] kthread+0x96/0xa0
    [] kernel_thread_helper+0x4/0x10
    [] ? kthread_worker_fn+0x190/0x190
    [] ? gs_change+0xb/0xb
    RIP [] bdev_writeseg+0x25d/0x270 [logfs]
    ---[ end trace 0211ad60a57657c4 ]---

    Reviewed-by: Joern Engel
    Signed-off-by: Prasad Joshi

    Prasad Joshi
     

04 Jan, 2012

2 commits


02 Nov, 2011

2 commits


25 Mar, 2011

1 commit

  • Now that inode state changes are protected by the inode->i_lock and
    the inode LRU manipulations by the inode_lru_lock, we can remove the
    inode_lock from prune_icache and the initial part of iput_final().

    instead of using the inode_lock to protect the inode during
    iput_final, use the inode->i_lock instead. This protects the inode
    against new references being taken while we change the inode state
    to I_FREEING, as well as preventing prune_icache from grabbing the
    inode while we are manipulating it. Hence we no longer need the
    inode_lock in iput_final prior to setting I_FREEING on the inode.

    For prune_icache, we no longer need the inode_lock to protect the
    LRU list, and the inodes themselves are protected against freeing
    races by the inode->i_lock. Hence we can lift the inode_lock from
    prune_icache as well.

    Signed-off-by: Dave Chinner
    Signed-off-by: Al Viro

    Dave Chinner
     

07 Jan, 2011

1 commit

  • RCU free the struct inode. This will allow:

    - Subsequent store-free path walking patch. The inode must be consulted for
    permissions when walking, so an RCU inode reference is a must.
    - sb_inode_list_lock to be moved inside i_lock because sb list walkers who want
    to take i_lock no longer need to take sb_inode_list_lock to walk the list in
    the first place. This will simplify and optimize locking.
    - Could remove some nested trylock loops in dcache code
    - Could potentially simplify things a bit in VM land. Do not need to take the
    page lock to follow page->mapping.

    The downsides of this is the performance cost of using RCU. In a simple
    creat/unlink microbenchmark, performance drops by about 10% due to inability to
    reuse cache-hot slab objects. As iterations increase and RCU freeing starts
    kicking over, this increases to about 20%.

    In cases where inode lifetimes are longer (ie. many inodes may be allocated
    during the average life span of a single inode), a lot of this cache reuse is
    not applicable, so the regression caused by this patch is smaller.

    The cache-hot regression could largely be avoided by using SLAB_DESTROY_BY_RCU,
    however this adds some complexity to list walking and store-free path walking,
    so I prefer to implement this at a later date, if it is shown to be a win in
    real situations. I haven't found a regression in any non-micro benchmark so I
    doubt it will be a problem.

    Signed-off-by: Nick Piggin

    Nick Piggin
     

10 Aug, 2010

3 commits


22 May, 2010

1 commit


06 May, 2010

1 commit


05 May, 2010

1 commit


02 May, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

07 Mar, 2010

1 commit

  • * git://git.kernel.org/pub/scm/linux/kernel/git/joern/logfs:
    [LogFS] Change magic number
    [LogFS] Remove h_version field
    [LogFS] Check feature flags
    [LogFS] Only write journal if dirty
    [LogFS] Fix bdev erases
    [LogFS] Silence gcc
    [LogFS] Prevent 64bit divisions in hash_index
    [LogFS] Plug memory leak on error paths
    [LogFS] Add MAINTAINERS entry
    [LogFS] add new flash file system

    Fixed up trivial conflict in lib/Kconfig, and a semantic conflict in
    fs/logfs/inode.c introduced by write_inode() being changed to use
    writeback_control' by commit a9185b41a4f84971b930c519f0c63bd450c4810d
    ("pass writeback_control to ->write_inode")

    Linus Torvalds
     

21 Nov, 2009

1 commit