Re: [GIT PULL] please pull file-locking related changes for v3.20

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

 



On Tue, Feb 17, 2015 at 11:13 AM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> That said, I'm not at all sure about the "we're stuck with it". We can
> improve the semantics without anybody noticing, because it's not like
> anybody could *depend* on the weaker semantics - they needed
> particular races and timings to hit anyway.

.. that said, it's true that we cannot do the FILE_LOCK_DEFERRED thing
for multiple blockers that already hold a lock. One of them has to
release its lock for other lockers to make progress. So I guess the
weak model of dropping a read lock before taking a write lock is
actually required.

That sleep in the middle with dropping the lock is still complete
crap, though. You can't do it. If you drop the lock, you have to
repeat the while cycle, not just sleep and continue.

Or just go to sleep, waiting for the conflicting lock to also be dropped.

So maybe just removing that whole "if (found) { reschedule }" - but
leaving the "drop early - is the right thing to do.

                          Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux