Linux PARISC architecture development
 help / color / mirror / Atom feed
From: Ben Hutchings <ben@decadent.org.uk>
To: linux-parisc@vger.kernel.org
Cc: Ryan Niebur <ryan@debian.org>
Subject: Unexpected behaviour of idr_get_empty_slot() on parisc
Date: Sun, 03 Jan 2010 23:23:25 +0000	[thread overview]
Message-ID: <1262561005.2238.51.camel@localhost> (raw)
In-Reply-To: <1261357334.25157.272.camel@localhost>

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

       reply	other threads:[~2010-01-03 23:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20091220234610.GG11237@jade.home>
     [not found] ` <1261354364.25157.246.camel@localhost>
     [not found]   ` <20091221003500.GK11237@jade.home>
     [not found]     ` <1261357334.25157.272.camel@localhost>
2010-01-03 23:23       ` Ben Hutchings [this message]
2010-01-03 23:50         ` Unexpected behaviour of idr_get_empty_slot() on parisc Kyle McMartin
2010-01-15 16:26           ` James Bottomley
2010-01-18 17:12             ` James Bottomley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1262561005.2238.51.camel@localhost \
    --to=ben@decadent.org.uk \
    --cc=linux-parisc@vger.kernel.org \
    --cc=ryan@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox