Re: [patch 16/28] fs: Use rename lock and RCU for multi-step operations

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

 



On Tue, Nov 16, 2010 at 6:09 AM, Nick Piggin <npiggin@xxxxxxxxx> wrote:

> +               /* might go back up the wrong parent if we have had a rename
> +                * or deletion */
> +               if (this_parent != child->d_parent ||
> +                               read_seqretry(&rename_lock, seq)) {
> +                       spin_unlock(&this_parent->d_lock);
> +                       spin_unlock(&dcache_lock);
> +                       rcu_read_unlock();
> +                       goto rename_retry;
> +               }
> +               rcu_read_unlock();
> +               next = child->d_u.d_child.next;

Again there are something like three insertions of this check.  Right
now it arguably makes sense to have everything explicitly clear inline
at every instance of the code for review, but eventually it might be
more readable if these became something like:

if (rename_happened(...))
        goto rename_retry;

(accounting for the change in patch 19 of course)
--
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