Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> NACK.
> 
> This changes the behaviour of F_UNLCK. Currently, if the allocation
> fails, the inode locking state remains unchanged. With your change, an
> unlock request may end up unlocking part of the inode, but not the rest.

No, look more closer.  There are two cases:

  - some locks are partially or completely removed

  - the unlock splits an existing lock in two.

In the first case no new locks are needed.  In the second, no locks
are modified prior to the check.

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux