> > In the first case no new locks are needed. In the second, no locks > > are modified prior to the check. > > Consider something like > > fcntl(SETLK, 0, 100) > fcntl(SETLK, 0, 100) > fcntl(SETLK, 0, 100) Huh? What is the type of lock in each case. But anyway your example is no good. If the new lock completely covers the previous one, then the old lock will simply be adjusted and no new lock is inserted. 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/
- Follow-Ups:
- Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- From: Trond Myklebust <[email protected]>
- Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- References:
- [PATCH 0/4] locks: cleanups and fixes
- From: Miklos Szeredi <[email protected]>
- [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- From: Miklos Szeredi <[email protected]>
- Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- From: Trond Myklebust <[email protected]>
- Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- From: Miklos Szeredi <[email protected]>
- Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- From: Trond Myklebust <[email protected]>
- [PATCH 0/4] locks: cleanups and fixes
- Prev by Date: Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- Next by Date: Re: [PATCH] splice SPLICE_F_MOVE support
- Previous by thread: Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- Next by thread: Re: [PATCH 2/4] locks: don't unnecessarily fail posix lock operations
- Index(es):
 |