lkml.org 
[lkml]   [2006]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
    From
    Date
    > OK. I see what you mean now. Do you agree with the following analysis?
    >
    > 1) We need 2 extra locks for the case where we
    > upgrade/downgrade, a single existing lock and end up splitting
    > it.
    >
    > 2) We need to use 1 extra lock in the case where we unlock and
    > split a single existing lock.
    >
    > 3) We also need to use 1 extra lock in the case where there is
    > no existing lock that is contiguous with the region to lock.

    4) Also 1 extra lock needed if there's an existing lock that is
    contiguous/overlapping with the new region but it's a different
    type, and no existing locks are completely covered

    > In all other cases, we resort to modifying existing locks instead of
    > using new_fl/new_fl2.
    >
    > In cases (1) and (2) we do need to modify the existing lock. Since this
    > is only done after we've set up the extra locks, we're safe.

    And 4.

    > Could I still suggest a couple of modifications to your patch? Firstly,
    > we only need to test for 'added' once.

    Like this?


    + /*
    + * The above code only modifies existing locks in case of
    + * merging or replacing. If new lock(s) need to be inserted
    + * all modifications are done bellow this, so it's safe yet to
    + * bail out.
    + */
    + error = -ENOLCK; /* "no luck" */
    + if (right && left == right && !new_fl2)
    + goto out;
    +
    error = 0;
    if (!added) {
    if (request->fl_type == F_UNLCK)
    goto out;
    +
    + if (!new_fl) {
    + error -ENOLCK;
    + goto out;
    + }
    locks_copy_lock(new_fl, request);
    locks_insert_lock(before, new_fl);
    new_fl = NULL;

    > Secondly, in cases (2) and (3), we can still complete the lock
    > despite one of new_fl/new_fl2 failing to be allocated.

    I think it's highly unlikely that one of the allocations would succeed
    and the other fail. If the machine is OOM, then it will very likely
    fail all allocations.

    But even if that would happen it's not worth it to add more
    complexity, just to squeeze the last drop out of the available memory
    for file locking purposes.

    Miklos
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-04-01 08:43    [W:0.023 / U:89.404 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site