Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> writes:
>> mkdir c
>> ln -s c a
>>
>> f=open("a/",O_RDONLY+O_NOFOLLOW)
>>
>> fails with ELOOP. However, this open should behave like open("a/.") not like
>> open("a") according to path_resolution(7). In kernel version 2.6.32 the open
>> worked as documented.
>>
>> On a higher level this bug makes
>>
>> find a/
>>
>> to fail.
>>
>
> It sounds like this 2.6.32->2.6.34-rc6 regression could have pretty
> serious ramifications for some users. Does anyone know whcih commit
> might have caused it?
This probably is the part of do_last cleanup series. (I was looking this
series, but unfortunately I also didn't notice about this bug..)
And with quick-look, it seems to be in do_last():
/* trailing slashes? */
if (nd->last.name[nd->last.len]) {
if (open_flag & O_CREAT)
goto exit;
nd->flags |= LOOKUP_DIRECTORY;
}
Before (i.e. do_path_lookup()), it was doing with LOOKUP_FOLLOW for
"trailing slash". Current one, it isn't.
If Al or someone don't fix, I'll see more later (it may be next weekend
or so, sorry).
Thanks.
--
OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx>
--
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
