Unexpected behaviour of idr_get_empty_slot() on parisc

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

 



Ryan Niebur reported in <http://bugs.debian.org/561880> that on a
PA-RISC system running Linux 2.6.32 the following test case for inotify:

#include <sys/inotify.h>
#include <stdio.h>

int main()
{
    int fd, wd;

    fd = inotify_init ();
    wd = inotify_add_watch (fd,
                            "test.c",
                            IN_OPEN | IN_CLOSE);
    printf("First: %d\n", wd);
    inotify_rm_watch(fd, wd);
    wd = inotify_add_watch (fd,
                            "a.out",
                            IN_OPEN | IN_CLOSE);
    printf("Second: %d\n", wd);
    inotify_rm_watch(fd, wd);
}

produces the output:

First: 1
Second: 1

The behaviour he (and the test case's author) expects is that ids for
closed descriptors are not reused and the second id will be 2.  The
implementation does seem to ensure that:

static int inotify_handle_get_wd(struct inotify_handle *ih,
				 struct inotify_watch *watch)
{
	int ret;

	do {
		if (unlikely(!idr_pre_get(&ih->idr, GFP_NOFS)))
			return -ENOSPC;
		ret = idr_get_new_above(&ih->idr, watch, ih->last_wd+1, &watch->wd);
	} while (ret == -EAGAIN);

	if (likely(!ret))
		ih->last_wd = watch->wd;

	return ret;
}

Removing the inotify_rm_watch() calls from the test case results in the
expected output, so I have no reason to think that id can be assigned
while it is already in use.  However, it does appear that
idr_get_empty_slot() can somehow select an id smaller than starting_id.

Ben.

-- 
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux SoC]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux