On Fri, Apr 18, 2014 at 8:11 AM, Lin Ming <minggr@xxxxxxxxx> wrote:
> On Thu, Apr 17, 2014 at 8:40 PM, Lin Ming <minggr@xxxxxxxxx> wrote:
>> On Thu, Apr 17, 2014 at 8:17 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
>>> On Fri, Apr 18, 2014 at 03:48:37AM +0100, Al Viro wrote:
>>>> Crap... No, it's a bit trickier - we start with clearing all flags,
>>>> so if we see the _intermediate_ d_flags and new d_inode, we'll sail
>>>> past the check. Which would leave us with correct inode, but might
>>>> give us a false negative in should_follow_link().
>>>
>>> Note that most of the places calling d_is_...() are protected by
>>> the following: if we'd obtained dentry by __lookup_hash() and friends
>>> *after* grabbing ->i_mutex on parent, we are fine - both positive-to-negative
>>> and negative-to-positive are possible only with ->i_mutex held, so it
>>> gives us a barrier.
>>>
>>> AFAICS, there are two more tricky places: walk_component() doing
>>> if (!inode)
>>> goto out_path_put;
>>>
>>> if (should_follow_link(path->dentry, follow)) {
>>> with unpleasant consequences if the second test gives a false negative,
>>> and similar for mountpoint_last().
>>>
>>> Basically, we'd concentrated on RCU races back then, and missed the possibility
>>> of non-RCU-but-without-i_mutex ones. Proposed fix follows:
>>
>> Should be OK. I'll test it tomorrow.
>
> Confirmed it's OK.
>
> Reported-and-tested-by: Lin Ming <minggr@xxxxxxxxx>
Hi Al,
Was this fix merged in your vfs tree?
Thanks.
--
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
