07 Feb, 2008

2 commits


04 Feb, 2008

1 commit

  • a) in device_write(): add sentinel NUL byte, making sure that lspace.name will
    be NUL-terminated
    b) in compat_input() be keep it simple about the amounts of data we are copying.

    Signed-off-by: Al Viro
    Signed-off-by: David Teigland

    Al Viro
     

31 Jan, 2008

3 commits


20 Oct, 2007

1 commit

  • The task_struct->pid member is going to be deprecated, so start
    using the helpers (task_pid_nr/task_pid_vnr/task_pid_nr_ns) in
    the kernel.

    The first thing to start with is the pid, printed to dmesg - in
    this case we may safely use task_pid_nr(). Besides, printks produce
    more (much more) than a half of all the explicit pid usage.

    [akpm@linux-foundation.org: git-drm went and changed lots of stuff]
    Signed-off-by: Pavel Emelyanov
    Cc: Dave Airlie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Pavel Emelyanov
     

09 Jul, 2007

4 commits

  • Add a function that can be used through libdlm by a system daemon to cancel
    another process's deadlocked lock. A completion ast with EDEADLK is returned
    to the process waiting for the lock.

    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland
     
  • Various fixes related to the new timeout feature:
    - add_timeout() missed setting TIMEWARN flag on lkb's when the
    TIMEOUT flag was already set
    - clear_proc_locks should remove a dead process's locks from the
    timeout list
    - the end-of-life calculation for user locks needs to consider that
    ETIMEDOUT is equivalent to -DLM_ECANCEL
    - make initial default timewarn_cs config value visible in configfs
    - change bit position of TIMEOUT_CANCEL flag so it's not copied to
    a remote master node
    - set timestamp on remote lkb's so a lock dump will display the time
    they've been waiting

    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland
     
  • Change the user/kernel device interface used by libdlm:
    - Add ability for userspace to check the version of the interface. libdlm
    can now adapt to different versions of the kernel interface.
    - Increase the size of the flags passed in a lock request so all possible
    flags can be used from userspace.
    - Add an opaque "xid" value for each lock. This "transaction id" will be
    used later to associate locks with each other during deadlock detection.
    - Add a "timeout" value for each lock. This is used along with the
    DLM_LKF_TIMEOUT flag.

    Also, remove a fragment of unused code in device_read().

    This patch requires updating libdlm which is backward compatible with
    older kernels.

    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland
     
  • New features: lock timeouts and time warnings. If the DLM_LKF_TIMEOUT
    flag is set, then the request/conversion will be canceled after waiting
    the specified number of centiseconds (specified per lock). This feature
    is only available for locks requested through libdlm (can be enabled for
    kernel dlm users if there's a use for it.)

    If the new DLM_LSFL_TIMEWARN flag is set when creating the lockspace, then
    a warning message will be sent to userspace (using genetlink) after a
    request/conversion has been waiting for a given number of centiseconds
    (configurable per node). The time warnings will be used in the future
    to do deadlock detection in userspace.

    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland
     

01 May, 2007

4 commits

  • This patch removes a redundant (and incorrect) assignment from compat_output

    Signed-Off-By: Patrick Caulfield
    Signed-off-by: Steven Whitehouse

    Patrick Caulfield
     
  • Add code to accept purge commands from userland.

    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland
     
  • Full cancel and force-unlock support. In the past, cancel and force-unlock
    wouldn't work if there was another operation in progress on the lock. Now,
    both cancel and unlock-force can overlap an operation on a lock, meaning there
    may be 2 or 3 operations in progress on a lock in parallel. This support is
    important not only because cancel and force-unlock are explicit operations
    that an app can use, but both are used implicitly when a process exits while
    holding locks.

    Summary of changes:

    - add-to and remove-from waiters functions were rewritten to handle situations
    with more than one remote operation outstanding on a lock

    - validate_unlock_args detects when an overlapping cancel/unlock-force
    can be sent and when it needs to be delayed until a request/lookup
    reply is received

    - processing request/lookup replies detects when cancel/unlock-force
    occured during the op, and carries out the delayed cancel/unlock-force

    - manipulation of the "waiters" (remote operation) state of a lock moved under
    the standard rsb mutex that protects all the other lock state

    - the two recovery routines related to locks on the waiters list changed
    according to the way lkb's are now locked before accessing waiters state

    - waiters recovery detects when lkb's being recovered have overlapping
    cancel/unlock-force, and may not recover such locks

    - revert_lock (cancel) returns a value to distinguish cases where it did
    nothing vs cases where it actually did a cancel; the cancel completion ast
    should only be done when cancel did something

    - orphaned locks put on new list so they can be found later for purging

    - cancel must be called on a lock when making it an orphan

    - flag user locks (ENDOFLIFE) at the end of their useful life (to the
    application) so we can return an error for any further cancel/unlock-force

    - we weren't setting COMP/BAST ast flags if one was already set, so we'd lose
    either a completion or blocking ast

    - clear an unread bast on a lock that's become unlocked

    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland
     
  • Currently if the lockspace removal fails the misc device associated with a
    lockspace is left deleted. After that there is no way to access the orphaned
    lockspace from userland.

    This patch recreates the misc device if th dlm_release_lockspace fails. I
    believe this is better than attempting to remove the lockspace first because
    that leaves an unattached device lying around. The potential gap in which there
    is no access to the lockspace between removing the misc device and recreating it
    is acceptable ... after all the application is trying to remove it, and only new
    users of the lockspace will be affected.

    Signed-Off-By: Patrick Caulfield
    Signed-off-by: Steven Whitehouse

    Patrick Caulfield
     

08 Mar, 2007

1 commit


13 Feb, 2007

1 commit

  • Many struct file_operations in the kernel can be "const". Marking them const
    moves these to the .rodata section, which avoids false sharing with potential
    dirty data. In addition it'll catch accidental writes at compile time to
    these shared resources.

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

06 Feb, 2007

1 commit

  • When a user process exits, we clear all the locks it holds. There is a
    problem, though, with locks that the process had begun unlocking before it
    exited. We couldn't find the lkb's that were in the process of being
    unlocked remotely, to flag that they are DEAD. To solve this, we move
    lkb's being unlocked onto a new list in the per-process structure that
    tracks what locks the process is holding. We can then go through this
    list to flag the necessary lkb's when clearing locks for a process when it
    exits.

    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland
     

01 Sep, 2006

1 commit


21 Jul, 2006

1 commit


20 Jul, 2006

1 commit


13 Jul, 2006

1 commit

  • This changes the way the dlm handles user locks. The core dlm is now
    aware of user locks so they can be dealt with more efficiently. There is
    no more dlm_device module which previously managed its own duplicate copy
    of every user lock.

    Signed-off-by: Patrick Caulfield
    Signed-off-by: David Teigland
    Signed-off-by: Steven Whitehouse

    David Teigland