30 Mar, 2009

1 commit

  • The uuid table handling should not be part of a semi-generic uuid library
    but in the XFS code using it, so move those bits to xfs_mount.c and
    refactor the whole glob to make it a proper abstraction.

    Signed-off-by: Christoph Hellwig
    Reviewed-by: Felix Blyakher

    Christoph Hellwig
     

15 Mar, 2009

1 commit


07 Mar, 2009

1 commit

  • Fix this sparse warnings:
    fs/xfs/linux-2.6/xfs_ioctl.c:72:1: warning: symbol 'xfs_find_handle' was not declared. Should it be static?
    fs/xfs/linux-2.6/xfs_ioctl.c:249:1: warning: symbol 'xfs_open_by_handle' was not declared. Should it be static?
    fs/xfs/linux-2.6/xfs_ioctl.c:361:1: warning: symbol 'xfs_readlink_by_handle' was not declared. Should it be static?
    fs/xfs/linux-2.6/xfs_ioctl.c:496:1: warning: symbol 'xfs_attrmulti_attr_get' was not declared. Should it be static?
    fs/xfs/linux-2.6/xfs_ioctl.c:525:1: warning: symbol 'xfs_attrmulti_attr_set' was not declared. Should it be static?
    fs/xfs/linux-2.6/xfs_ioctl.c:555:1: warning: symbol 'xfs_attrmulti_attr_remove' was not declared. Should it be static?
    fs/xfs/linux-2.6/xfs_ioctl.c:657:1: warning: symbol 'xfs_ioc_space' was not declared. Should it be static?
    fs/xfs/linux-2.6/xfs_ioctl.c:1340:1: warning: symbol 'xfs_file_ioctl' was not declared. Should it be static?
    fs/xfs/support/debug.c:65:1: warning: symbol 'xfs_fs_vcmn_err' was not declared. Should it be static?
    fs/xfs/support/debug.c:112:1: warning: symbol 'xfs_hex_dump' was not declared. Should it be static?

    Signed-off-by: Hannes Eder
    Reviewed-by: Christoph Hellwig
    Signed-off-by: Felix Blyakher

    Hannes Eder
     

22 Dec, 2008

1 commit

  • xfs_fs_vcmn_err can be called under a spinlock, but does a sleeping memory
    allocation to create buffer for it's internal sprintf. Fortunately it's
    the only caller of icmn_err, so we can merge the two and have one single
    static buffer and spinlock protecting it. While we're at it make sure
    we proper __attribute__ format annotations so that the compiler can detect
    mismatched format strings.

    Reported-by: Alexander Beregalov
    Signed-off-by: Christoph Hellwig
    Reviewed-by: Eric Sandeen
    Signed-off-by: Lachlan McIlroy

    Christoph Hellwig
     

05 Dec, 2008

1 commit


30 Oct, 2008

1 commit


28 Jul, 2008

2 commits

  • Currently the xfs module init/exit code is a mess. It's farmed out over a
    lot of function with very little error checking. This patch makes sure we
    propagate all initialization failures properly and clean up after them.
    Various runtime initializations are replaced with compile-time
    initializations where possible to make this easier. The exit path is
    similarly consolidated.

    There's now split out function to create/destroy the kmem zones and
    alloc/free the trace buffers. I've also changed the ktrace allocations to
    KM_MAYFAIL and handled errors resulting from that.

    And yes, we really should replace the XFS_*_TRACE ifdefs with a single
    XFS_TRACE..

    SGI-PV: 976035

    SGI-Modid: xfs-linux-melb:xfs-kern:31354a

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Niv Sardi
    Signed-off-by: Lachlan McIlroy

    Christoph Hellwig
     
  • kmem_free() function takes (ptr, size) arguments but doesn't actually use
    second one.

    This patch removes size argument from all callsites.

    SGI-PV: 981498
    SGI-Modid: xfs-linux-melb:xfs-kern:31050a

    Signed-off-by: Denys Vlasenko
    Signed-off-by: David Chinner
    Signed-off-by: Lachlan McIlroy

    Denys Vlasenko
     

30 Apr, 2008

1 commit


18 Apr, 2008

2 commits

  • Now that the ktrace_enter() code is using atomics, the non-power-of-2
    buffer sizes - which require modulus operations to get the index - are
    showing up as using substantial CPU in the profiles.

    Force the buffer sizes to be rounded up to the nearest power of two and
    use masking rather than modulus operations to convert the index counter to
    the buffer index. This reduces ktrace_enter overhead to 8% of a CPU time,
    and again almost halves the trace intensive test runtime.

    SGI-PV: 977546
    SGI-Modid: xfs-linux-melb:xfs-kern:30538a

    Signed-off-by: David Chinner
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Lachlan McIlroy

    David Chinner
     
  • ktrace_enter() is consuming vast amounts of CPU time due to the use of a
    single global lock for protecting buffer index increments. Change it to
    use per-buffer atomic counters - this reduces ktrace_enter() overhead
    during a trace intensive test on a 4p machine from 58% of all CPU time to
    12% and halves test runtime.

    SGI-PV: 977546
    SGI-Modid: xfs-linux-melb:xfs-kern:30537a

    Signed-off-by: David Chinner
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Lachlan McIlroy

    David Chinner
     

07 Feb, 2008

4 commits


15 Oct, 2007

1 commit

  • Kill uio related functions and defines now that they're unused.

    SGI-PV: 968563
    SGI-Modid: xfs-linux-melb:xfs-kern:29480a

    Signed-off-by: Christoph Hellwig
    Signed-off-by: David Chinner
    Signed-off-by: Tim Shimmin

    Christoph Hellwig
     

05 Sep, 2007

1 commit

  • - remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now
    complains about comparisons between pointers and 0
    - add a standalone ASSERT implementation because defining it to
    ASSERT_ALWAYS means the string is expanded before the token passing
    stringification. This way we get the actual content of the
    assertion in the assfail message and don't overflow sparse's
    stringification buffer leading to sparse error messages.

    SGI-PV: 968555
    SGI-Modid: xfs-linux-melb:xfs-kern:29310a

    Signed-off-by: Christoph Hellwig
    Signed-off-by: David Chinner
    Signed-off-by: Tim Shimmin

    Christoph Hellwig
     

08 May, 2007

1 commit


10 Feb, 2007

3 commits

  • SGI-PV: 954580
    SGI-Modid: xfs-linux-melb:xfs-kern:27701a

    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Christoph Hellwig
    Signed-off-by: Tim Shimmin

    Lachlan McIlroy
     
  • gcc-4.1 and more recent aggressively inline static functions which
    increases XFS stack usage by ~15% in critical paths. Prevent this from
    occurring by adding noinline to the STATIC definition.

    Also uninline some functions that are too large to be inlined and were
    causing problems with CONFIG_FORCED_INLINING=y.

    Finally, clean up all the different users of inline, __inline and
    __inline__ and put them under one STATIC_INLINE macro. For debug kernels
    the STATIC_INLINE macro uninlines those functions.

    SGI-PV: 957159
    SGI-Modid: xfs-linux-melb:xfs-kern:27585a

    Signed-off-by: David Chinner
    Signed-off-by: David Chatterton
    Signed-off-by: Tim Shimmin

    David Chinner
     
  • The message buffer used by cmn_err() is only 256 bytes and some CXFS
    messages were exceeding this length. Since we were using vsprintf() and
    not checking for buffer overruns we were clobbering memory beyond the
    buffer. The size of the buffer has been increased to 1024 bytes so we can
    capture these larger messages and we are now using vsnprintf() to prevent
    overrunning the buffer size.

    SGI-PV: 958599
    SGI-Modid: xfs-linux-melb:xfs-kern:27561a

    Signed-off-by: Lachlan McIlroy
    Signed-off-by: Geoffrey Wehrman
    Signed-off-by: Tim Shimmin

    Lachlan McIlroy
     

11 Nov, 2006

2 commits


04 Oct, 2006

1 commit


28 Sep, 2006

1 commit


09 Jun, 2006

1 commit


22 Mar, 2006

1 commit


14 Mar, 2006

1 commit


12 Jan, 2006

1 commit


11 Jan, 2006

2 commits


10 Jan, 2006

1 commit

  • This patch switches XFS over to use the new mutex code directly as
    opposed to the previous workaround patch I posted earlier that avoided
    the namespace clash by forcing it back to semaphores. This falls in the
    'works for me' category.

    Signed-off-by: Jes Sorensen
    Signed-off-by: Ingo Molnar

    Jes Sorensen
     

04 Nov, 2005

1 commit


02 Nov, 2005

3 commits


10 Sep, 2005

1 commit


05 Sep, 2005

1 commit


21 Jun, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds