lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <c2b2191a22eab7f6127d5ea1d519bee1.squirrel@webmail01.one.com>
Date:	Thu, 21 Jul 2011 08:47:44 +0200
From:	Morten Winkler Jørgensen <morten@...kler.dk>
To:	linux-kernel@...r.kernel.org
Subject: Possible bug in inotify api

To whom it might concern

I'd like to report a possible malfunction of the inotify api and check if
this issue has been reported.
If this is not the proper place to do so, please let me know. I have
searched the archives and the web and found similar reportings but none
the same.

The observed behavior is when calling inotify_remove_watch. Now and then
it returns error 22, INVALID_ARGUMENT, even though the watchdesriptor
ought to be valid. I've seen that people complain about this behavior on
the dovecot mailing list but nobody seems to have suggested a fix.

I've attached a small program that I use to reproduce the behavior.
The program watches /tmp and whenever it's notified about a directory
created in /tmp, my program adds a watch for that directory as well.

The program is a C++ program (as I will need the inotify functionality in
a C++ program, but the behavior is the same in a pure C implementation)
and to reproduce I do the following:

* g++ main.cpp
* ./a.out

In a shell I go to /tmp and run
* for i in `seq 1 5000`; do mkdir D-$i; done; for i in `seq 1 5000`; do
rmdir D-$i; done

This makes my testprogram output the wd's created and and the wd's my
program tries to remove. I've never seen the program successfully remove
all 5000 watch descriptors and I've seen inotify_rm_watch fail after 0
removes and after approx 2000 removes and anything in between.

I'm running kernel 2.6.23-5 from the Debian repositories.

If what I've written is totally nonsense, if it is expected behavior or if
I've done anything wrong, please let me know. Also, if I can do anything
further to investigate the misbehavior also, please let me know.

Best and thanks in advance,
   Morten

Attached: C++ program used to reproduce the behavior.

View attachment "main.cpp" of type "text/x-c++src" (3952 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ