Eric Lee / smarc-fsl-linux-kernel

04 Jan, 2012

2 commits

24 Mar, 2011

1 commit

25 Nov, 2010

1 commit

  • da905873e   reiserfs: fix inode mutex - reiserfs lock misordering ... Browse Code »

    reiserfs_unpack() locks the inode mutex with reiserfs_mutex_lock_safe()
    to protect against reiserfs lock dependency. However this protection
    requires to have the reiserfs lock to be locked.

    This is the case if reiserfs_unpack() is called by reiserfs_ioctl but
    not from reiserfs_quota_on() when it tries to unpack tails of quota
    files.

    Fix the ordering of the two locks in reiserfs_unpack() to fix this
    issue.

    Signed-off-by: Frederic Weisbecker
    Reported-by: Markus Gapp
    Reported-by: Jan Kara
    Cc: Jeff Mahoney
    Cc: [2.6.36.x]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frederic Weisbecker
     

18 Nov, 2010

1 commit

26 Oct, 2010

1 commit

  • ebdec241d   fs: kill block_prepare_write ... Browse Code »

    __block_write_begin and block_prepare_write are identical except for slightly
    different calling conventions. Convert all callers to the __block_write_begin
    calling conventions and drop block_prepare_write.

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Al Viro

    Christoph Hellwig
     

02 Oct, 2010

2 commits

  • 9d8117e72   reiserfs: fix unwanted reiserfs lock recursion ... Browse Code »

    Prevent from recursively locking the reiserfs lock in reiserfs_unpack()
    because we may call journal_begin() that requires the lock to be taken
    only once, otherwise it won't be able to release the lock while taking
    other mutexes, ending up in inverted dependencies between the journal
    mutex and the reiserfs lock for example.

    This fixes:

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.35.4.4a #3
    -------------------------------------------------------
    lilo/1620 is trying to acquire lock:
    (&journal->j_mutex){+.+...}, at: [] do_journal_begin_r+0x7f/0x340 [reiserfs]

    but task is already holding lock:
    (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs]

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_write_lock+0x28/0x40 [reiserfs]
    [] do_journal_begin_r+0x86/0x340 [reiserfs]
    [] journal_begin+0x77/0x140 [reiserfs]
    [] reiserfs_remount+0x224/0x530 [reiserfs]
    [] do_remount_sb+0x60/0x110
    [] do_mount+0x625/0x790
    [] sys_mount+0x84/0xb0
    [] syscall_call+0x7/0xb

    -> #0 (&journal->j_mutex){+.+...}:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] do_journal_begin_r+0x7f/0x340 [reiserfs]
    [] journal_begin+0x77/0x140 [reiserfs]
    [] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
    [] reiserfs_get_block+0x22c/0x1530 [reiserfs]
    [] __block_prepare_write+0x1bb/0x3a0
    [] block_prepare_write+0x26/0x40
    [] reiserfs_prepare_write+0x88/0x170 [reiserfs]
    [] reiserfs_unpack+0xe6/0x120 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] syscall_call+0x7/0xb

    other info that might help us debug this:

    2 locks held by lilo/1620:
    #0: (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [] reiserfs_unpack+0x6a/0x120 [reiserfs]
    #1: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs]

    stack backtrace:
    Pid: 1620, comm: lilo Not tainted 2.6.35.4.4a #3
    Call Trace:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] do_journal_begin_r+0x7f/0x340 [reiserfs]
    [] journal_begin+0x77/0x140 [reiserfs]
    [] reiserfs_persistent_transaction+0x41/0x90 [reiserfs]
    [] reiserfs_get_block+0x22c/0x1530 [reiserfs]
    [] __block_prepare_write+0x1bb/0x3a0
    [] block_prepare_write+0x26/0x40
    [] reiserfs_prepare_write+0x88/0x170 [reiserfs]
    [] reiserfs_unpack+0xe6/0x120 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] syscall_call+0x7/0xb

    Reported-by: Jarek Poplawski
    Tested-by: Jarek Poplawski
    Signed-off-by: Frederic Weisbecker
    Cc: Jeff Mahoney
    Cc: All since 2.6.32
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frederic Weisbecker
     
  • 3f259d092   reiserfs: fix dependency inversion between inode and reiserfs mutexes ... Browse Code »

    The reiserfs mutex already depends on the inode mutex, so we can't lock
    the inode mutex in reiserfs_unpack() without using the safe locking API,
    because reiserfs_unpack() is always called with the reiserfs mutex locked.

    This fixes:

    =======================================================
    [ INFO: possible circular locking dependency detected ]
    2.6.35c #13
    -------------------------------------------------------
    lilo/1606 is trying to acquire lock:
    (&sb->s_type->i_mutex_key#8){+.+.+.}, at: [] reiserfs_unpack+0x60/0x110 [reiserfs]

    but task is already holding lock:
    (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs]

    which lock already depends on the new lock.

    the existing dependency chain (in reverse order) is:

    -> #1 (&REISERFS_SB(s)->lock){+.+.+.}:
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_write_lock+0x28/0x40 [reiserfs]
    [] reiserfs_lookup_privroot+0x2a/0x90 [reiserfs]
    [] reiserfs_fill_super+0x941/0xe60 [reiserfs]
    [] get_sb_bdev+0x117/0x170
    [] get_super_block+0x21/0x30 [reiserfs]
    [] vfs_kern_mount+0x6a/0x1b0
    [] do_kern_mount+0x39/0xe0
    [] do_mount+0x340/0x790
    [] sys_mount+0x84/0xb0
    [] syscall_call+0x7/0xb

    -> #0 (&sb->s_type->i_mutex_key#8){+.+.+.}:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_unpack+0x60/0x110 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] syscall_call+0x7/0xb

    other info that might help us debug this:

    1 lock held by lilo/1606:
    #0: (&REISERFS_SB(s)->lock){+.+.+.}, at: [] reiserfs_write_lock+0x28/0x40 [reiserfs]

    stack backtrace:
    Pid: 1606, comm: lilo Not tainted 2.6.35c #13
    Call Trace:
    [] __lock_acquire+0x1026/0x1180
    [] lock_acquire+0x67/0x80
    [] __mutex_lock_common+0x4d/0x410
    [] mutex_lock_nested+0x18/0x20
    [] reiserfs_unpack+0x60/0x110 [reiserfs]
    [] reiserfs_ioctl+0x272/0x320 [reiserfs]
    [] vfs_ioctl+0x28/0xa0
    [] do_vfs_ioctl+0x32d/0x5c0
    [] sys_ioctl+0x63/0x70
    [] syscall_call+0x7/0xb

    Reported-by: Jarek Poplawski
    Tested-by: Jarek Poplawski
    Signed-off-by: Frederic Weisbecker
    Cc: Jeff Mahoney
    Cc: [2.6.32 and later]
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Frederic Weisbecker
     

07 Jan, 2010

1 commit

  • e0baec1b6   reiserfs: Fix unreachable statement ... Browse Code »

    Stanse found an unreachable statement in reiserfs_ioctl. There is a
    if followed by error assignment and `break' with no braces. Add the
    braces so that we don't break every time, but only in error case,
    so that REISERFS_IOC_SETVERSION actually works when it returns no
    error.

    Signed-off-by: Jiri Slaby
    Cc: Reiserfs
    Cc: Andrew Morton
    Signed-off-by: Frederic Weisbecker

    Jiri Slaby
     

15 Oct, 2009

2 commits

  • 205cb37b8   kill-the-bkl/reiserfs: definitely drop the bkl from reiserfs_ioctl() ... Browse Code »

    The reiserfs ioctl path doesn't need the big kernel lock anymore , now
    that the filesystem synchronizes through its own lock.

    We can then turn reiserfs_ioctl() into an unlocked_ioctl callback.

    Signed-off-by: Frederic Weisbecker
    Cc: Jeff Mahoney
    Cc: Chris Mason
    Cc: Ingo Molnar
    Cc: Alexander Beregalov
    Cc: Laurent Riffard
    Cc: Thomas Gleixner

    Frederic Weisbecker
     
  • ac78a0789   kill-the-bkl/reiserfs: always lock the ioctl path ... Browse Code »

    Reiserfs uses the ioctl callback for its file operations, which means
    that its ioctl path is still locked by the bkl, this was synchronizing
    with the rest of the filsystem operations. We have changed that by
    locking it with the new reiserfs lock but we do that only from the
    compat_ioctl callback.

    Fix that by locking reiserfs_ioctl() everytime.

    Signed-off-by: Frederic Weisbecker
    Cc: Jeff Mahoney
    Cc: Chris Mason
    Cc: Ingo Molnar
    Cc: Alexander Beregalov
    Cc: Laurent Riffard
    Cc: Thomas Gleixner

    Frederic Weisbecker
     

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
     

31 Mar, 2009

1 commit

28 Apr, 2008

1 commit

  • d5dee5c39   reiserfs: unpack tails on quota files ... Browse Code »

    Quota files cannot have tails because quota_write and quota_read functions do
    not support them. So far when quota files did have tail, we just refused to
    turn quotas on it. Sadly this check has been wrong and so there are now
    plenty installations where quota files don't have NOTAIL flag set and so now
    after fixing the check, they suddently fail to turn quotas on. Since it's
    easy to unpack the tail from kernel, do this from reiserfs_quota_on() which
    solves the problem and is generally nicer to users anyway.

    Signed-off-by: Jan Kara
    Reported-by:
    Cc: Jeff Mahoney
    Cc: Chris Mason
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

19 Apr, 2008

1 commit

15 Nov, 2007

1 commit

  • e47776a0a   Forbid user to change file flags on quota files ... Browse Code »

    Forbid user from changing file flags on quota files. User has no bussiness
    in playing with these flags when quota is on. Furthermore there is a
    remote possibility of deadlock due to a lock inversion between quota file's
    i_mutex and transaction's start (i_mutex for quota file is locked only when
    trasaction is started in quota operations) in ext3 and ext4.

    Signed-off-by: Jan Kara
    Cc: LIOU Payphone
    Cc:
    Acked-by: Dave Kleikamp
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jan Kara
     

17 Oct, 2007

1 commit

18 Jul, 2007

1 commit

  • 3bd858ab1   Introduce is_owner_or_cap() to wrap CAP_FOWNER use with fsuid check ... Browse Code »

    Introduce is_owner_or_cap() macro in fs.h, and convert over relevant
    users to it. This is done because we want to avoid bugs in the future
    where we check for only effective fsuid of the current task against a
    file's owning uid, without simultaneously checking for CAP_FOWNER as
    well, thus violating its semantics.
    [ XFS uses special macros and structures, and in general looked ...
    untouchable, so we leave it alone -- but it has been looked over. ]

    The (current->fsuid != inode->i_uid) check in generic_permission() and
    exec_permission_lite() is left alone, because those operations are
    covered by CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH. Similarly operations
    falling under the purview of CAP_CHOWN and CAP_LEASE are also left alone.

    Signed-off-by: Satyam Sharma
    Cc: Al Viro
    Acked-by: Serge E. Hallyn
    Signed-off-by: Linus Torvalds

    Satyam Sharma
     

09 Dec, 2006

1 commit

01 Oct, 2006

1 commit

06 Aug, 2006

1 commit

12 Jan, 2006

1 commit

10 Jan, 2006

1 commit

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
     

30 Jun, 2005

1 commit

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