On 9/7/09, Alan Jenkins <sourcejedi.lkml@xxxxxxxxxxxxxx> wrote:
>> int util_create_path(struct udev *udev, const char *path)
>> {
>> char p[UTIL_PATH_SIZE];
>> @@ -32,6 +54,8 @@ int util_create_path(struct udev *udev, const char
>> *path)
>> struct stat stats;
>> int ret;
>>
>> + if (util_path_lock())
>> + return -1;
>>
>> util_strscpy(p, sizeof(p), path);
>> pos = strrchr(p, '/');
>> if (pos == NULL)
>> @@ -47,8 +71,10 @@ int util_create_path(struct udev *udev, const char
>> *path)
>> if (stat(p, &stats) == 0 && (stats.st_mode & S_IFMT) == S_IFDIR)
>> return 0;
>>
>
>> - if (util_create_path(udev, p) != 0)
>> + if (util_create_path(udev, p) != 0) {
>> + util_path_unlock();
>> return -1;
>> + }
>
> Looks suspicious. It'll try to unlock even If the recursive
> util_create_path() bailed because it failed at util_path_lock().
>
> I suspect that can't happen, but this seems needlessly tricky. How
> about just renaming the old create_path() to create_path_unlocked() or
> something (updating the recursive call accordingly), and then
>
> int util_create_path(struct udev *udev, const char *path)
> {
> if (!util_path_lock())
> return -1;
> return util_path_create_unlocked(udev, path);
> }
Wups, that '!' shouldn't be there.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
