On Wed, Aug 21, 2013 at 11:20 AM, Oleg Nesterov <o...@redhat.com> wrote:
> Can't really comment the patch, just a nit:
>
> On 08/21, Andy Lutomirski wrote:
>>
>> +static bool may_flink(const struct path *path)
>> +{
>> + bool ret;
>> + struct inode *inode = path->dentry->d_inode;
>> +
>> + /*
>> + * This is racy: I_LINKABLE could be cleared between this check
>> + * and the actual link operation.
>
> OK,
>
>> + spin_lock(&inode->i_lock);
>> + ret = !!(inode->i_state & I_LINKABLE);
>> + spin_unlock(&inode->i_lock);
>
> so why do we need to take a lock ?
>
We probably don't. But other accesses to this field take that lock,
so it seemed safer.
(In principle, someone could take the lock, write I_LINKABLE, clear
it, and unlock, and we'd get confused if we didn't take the lock
ourselves.)
> Oleg.
>
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
