Eric Lee / smarc-fsl-linux-kernel

07 May, 2014

4 commits

09 Aug, 2013

1 commit

  • 278f6679f   reiserfs: locking, handle nested locks properly ... Browse Code »

    The reiserfs write lock replaced the BKL and uses similar semantics.

    Frederic's locking code makes a distinction between when the lock is nested
    and when it's being acquired/released, but I don't think that's the right
    distinction to make.

    The right distinction is between the lock being released at end-of-use and
    the lock being released for a schedule. The unlock should return the depth
    and the lock should restore it, rather than the other way around as it is now.

    This patch implements that and adds a number of places where the lock
    should be dropped.

    Signed-off-by: Jeff Mahoney

    Jeff Mahoney
     

01 Jun, 2012

1 commit

21 Mar, 2012

2 commits

15 Sep, 2011

1 commit

26 Jul, 2011

1 commit

  • 0c2fd1bfb   reiserfs: use proper little-endian bitops ... Browse Code »

    Using __test_and_{set,clear}_bit_le() with ignoring its return value can
    be replaced with __{set,clear}_bit_le().

    This introduces reiserfs_{set,clear}_le_bit for __{set,clear}_bit_le and
    does the above change with them.

    Signed-off-by: Akinobu Mita
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Akinobu Mita
     

14 Sep, 2009

1 commit

  • 8ebc42323   reiserfs: kill-the-BKL ... Browse Code »

    This patch is an attempt to remove the Bkl based locking scheme from
    reiserfs and is intended.

    It is a bit inspired from an old attempt by Peter Zijlstra:

    http://lkml.indiana.edu/hypermail/linux/kernel/0704.2/2174.html

    The bkl is heavily used in this filesystem to prevent from
    concurrent write accesses on the filesystem.

    Reiserfs makes a deep use of the specific properties of the Bkl:

    - It can be acqquired recursively by a same task
    - It is released on the schedule() calls and reacquired when schedule() returns

    The two properties above are a roadmap for the reiserfs write locking so it's
    very hard to simply replace it with a common mutex.

    - We need a recursive-able locking unless we want to restructure several blocks
    of the code.
    - We need to identify the sites where the bkl was implictly relaxed
    (schedule, wait, sync, etc...) so that we can in turn release and
    reacquire our new lock explicitly.
    Such implicit releases of the lock are often required to let other
    resources producer/consumer do their job or we can suffer unexpected
    starvations or deadlocks.

    So the new lock that replaces the bkl here is a per superblock mutex with a
    specific property: it can be acquired recursively by a same task, like the
    bkl.

    For such purpose, we integrate a lock owner and a lock depth field on the
    superblock information structure.

    The first axis on this patch is to turn reiserfs_write_(un)lock() function
    into a wrapper to manage this mutex. Also some explicit calls to
    lock_kernel() have been converted to reiserfs_write_lock() helpers.

    The second axis is to find the important blocking sites (schedule...(),
    wait_on_buffer(), sync_dirty_buffer(), etc...) and then apply an explicit
    release of the write lock on these locations before blocking. Then we can
    safely wait for those who can give us resources or those who need some.
    Typically this is a fight between the current writer, the reiserfs workqueue
    (aka the async commiter) and the pdflush threads.

    The third axis is a consequence of the second. The write lock is usually
    on top of a lock dependency chain which can include the journal lock, the
    flush lock or the commit lock. So it's dangerous to release and trying to
    reacquire the write lock while we still hold other locks.

    This is fine with the bkl:

    T1 T2

    lock_kernel()
    mutex_lock(A)
    unlock_kernel()
    // do something
    lock_kernel()
    mutex_lock(A) -> already locked by T1
    schedule() (and then unlock_kernel())
    lock_kernel()
    mutex_unlock(A)
    ....

    This is not fine with a mutex:

    T1 T2

    mutex_lock(write)
    mutex_lock(A)
    mutex_unlock(write)
    // do something
    mutex_lock(write)
    mutex_lock(A) -> already locked by T1
    schedule()

    mutex_lock(write) -> already locked by T2
    deadlock

    The solution in this patch is to provide a helper which releases the write
    lock and sleep a bit if we can't lock a mutex that depend on it. It's another
    simulation of the bkl behaviour.

    The last axis is to locate the fs callbacks that are called with the bkl held,
    according to Documentation/filesystem/Locking.

    Those are:

    - reiserfs_remount
    - reiserfs_fill_super
    - reiserfs_put_super

    Reiserfs didn't need to explicitly lock because of the context of these callbacks.
    But now we must take care of that with the new locking.

    After this patch, reiserfs suffers from a slight performance regression (for now).
    On UP, a high volume write with dd reports an average of 27 MB/s instead
    of 30 MB/s without the patch applied.

    Signed-off-by: Frederic Weisbecker
    Reviewed-by: Ingo Molnar
    Cc: Jeff Mahoney
    Cc: Peter Zijlstra
    Cc: Bron Gondwana
    Cc: Andrew Morton
    Cc: Linus Torvalds
    Cc: Alexander Viro
    LKML-Reference:
    Signed-off-by: Ingo Molnar

    Frederic Weisbecker
     

24 Jun, 2009

1 commit

31 Mar, 2009

1 commit

20 Oct, 2007

3 commits

  • cb680c1be   reiserfs: ignore on disk s_bmap_nr value ... Browse Code »

    Implement support for file systems larger than 8 TiB.

    The reiserfs superblock contains a 16 bit value for counting the number of
    bitmap blocks. The rest of the disk format supports file systems up to 2^32
    blocks, but the bitmap block limitation artificially limits this to 8 TiB with
    a 4KiB block size.

    Rather than trust the superblock's 16-bit bitmap block count, we calculate it
    dynamically based on the number of blocks in the file system. When an
    incorrect value is observed in the superblock, it is zeroed out, ensuring that
    older kernels will not be able to mount the file system.

    Userspace support has already been implemented and shipped in reiserfsprogs
    3.6.20.

    Signed-off-by: Jeff Mahoney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     
  • 4d20851d3   reiserfs: remove first_zero_hint ... Browse Code »

    The first_zero_hint metadata caching was never actually used, and it's of
    dubious optimization quality. This patch removes it.

    It doesn't actually shrink the size of the reiserfs_bitmap_info struct, since
    that doesn't work with block sizes larger than 8K. There was a big fixme in
    there, and with all the work lately in allowing block size > page size, I
    might as well kill the fixme as well.

    Signed-off-by: Jeff Mahoney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     
  • 6c57c2c8d   reiserfs: fix memset byte count during resize ... Browse Code »

    Correct the memset in reiserfs_resize to clear the memory allocated for the
    new bitmap info structs. Previously, it would clear the memory used by the
    old size. Depending on the contents of memory, this could cause incorrect
    caching behavior for bitmap blocks in the newly allocated area.

    Signed-off-by: Jeff Mahoney
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     

09 May, 2007

1 commit

01 Oct, 2006

3 commits

  • 5065227b4   [PATCH] reiserfs: on-demand bitmap loading ... Browse Code »

    This is the patch the three previous ones have been leading up to.

    It changes the behavior of ReiserFS from loading and caching all the bitmaps
    as special, to treating the bitmaps like any other bit of metadata and just
    letting the system-wide caches figure out what to hang on to.

    Buffer heads are allocated on the fly, so there is no need to retain pointers
    to all of them. The caching of the metadata occurs when the data is read and
    updated, and is considered invalid and uncached until then.

    I needed to remove the vs-4040 check for performing a duplicate operation on a
    particular bit. The reason is that while the other sites for working with
    bitmaps are allowed to schedule, is_reusable() is called from do_balance(),
    which will panic if a schedule occurs in certain places.

    The benefit of on-demand bitmaps clearly outweighs a sanity check that depends
    on a compile-time option that is discouraged.

    [akpm@osdl.org: warning fix]
    Signed-off-by: Jeff Mahoney
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     
  • 6f01046b3   [PATCH] reiserfs: reorganize bitmap loading functions ... Browse Code »

    This patch moves the bitmap loading code from super.c to bitmap.c

    The code is also restructured somewhat. The only difference between new
    format bitmaps and old format bitmaps is where they are. That's a two liner
    before loading the block to use the correct one. There's no need for an
    entirely separate code path.

    The load path is generally the same, with the pattern being to throw out a
    bunch of requests and then wait for them, then cache the metadata from the
    contents.

    Again, like the previous patches, the purpose is to set up for later ones.

    Update: There was a bug in the previously posted version of this that resulted
    in corruption. The problem was that bitmap 0 on new format file systems must
    be treated specially, and wasn't. A stupid bug with an easy fix.

    This is hopefully the last fix for the disaster that is the reiserfs bitmap
    patch set.

    If a bitmap block was full, first_zero_hint would end up at zero since it
    would never be changed from it's zeroed out value. This just sets it
    beyond the end of the bitmap block. If any bits are freed, it will be
    reset to a valid bit. When info->free_count = 0, then we already know it's
    full.

    Signed-off-by: Jeff Mahoney
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     
  • 0b3dc17bc   [PATCH] reiserfs: clean up bitmap block buffer head references ... Browse Code »

    Similar to the SB_JOURNAL cleanup that was accepted a while ago, this patch
    uses a temporary variable for buffer head references from the bitmap info
    array.

    This makes the code much more readable in some areas.

    It also uses proper reference counting, doing a get_bh() after using the
    pointer from the array and brelse()'ing it later. This may seem silly, but a
    later patch will replace the simple temporary variables with an actual read,
    so the reference freeing will be used then.

    Signed-off-by: Jeff Mahoney
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jeff Mahoney
     

13 Jul, 2005

1 commit

  • bd4c625c0   reiserfs: run scripts/Lindent on reiserfs code ... Browse Code »

    This was a pure indentation change, using:

    scripts/Lindent fs/reiserfs/*.c include/linux/reiserfs_*.h

    to make reiserfs match the regular Linux indentation style. As Jeff
    Mahoney writes:

    The ReiserFS code is a mix of a number of different coding styles, sometimes
    different even from line-to-line. Since the code has been relatively stable
    for quite some time and there are few outstanding patches to be applied, it
    is time to reformat the code to conform to the Linux style standard outlined
    in Documentation/CodingStyle.

    This patch contains the result of running scripts/Lindent against
    fs/reiserfs/*.c and include/linux/reiserfs_*.h. There are places where the
    code can be made to look better, but I'd rather keep those patches separate
    so that there isn't a subtle by-hand hand accident in the middle of a huge
    patch. To be clear: This patch is reformatting *only*.

    A number of patches may follow that continue to make the code more consistent
    with the Linux coding style.

    Hans wasn't particularly enthusiastic about these patches, but said he
    wouldn't really oppose them either.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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