linux-kernel - Re: Debugfs : inotify, multiple calls to debugfs_create

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20061122052730.GD20836@kroah.com>
Date:	Tue, 21 Nov 2006 21:27:30 -0800
From:	Greg KH <greg@...ah.com>
To:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
Cc:	ltt-dev@...fik.org, linux-kernel@...r.kernel.org
Subject: Re: Debugfs : inotify, multiple calls to debugfs_create_file, remove

On Mon, Nov 20, 2006 at 01:18:38PM -0500, Mathieu Desnoyers wrote:
> Hi Greg,
> 
> I just had to add inotify support to my LTTng consumer so I could inform it
> of the presence of new CPUs (for CPU hotplug). I noticed that no
> notification event was being sent when a debugfs file is created from within
> the kernel through debugfs_create. There are probably other notifications
> missing, but here is the patch adding the one I care about. Should it be added
> in libfs or in debugfs ?

So does this fix the inotify issue?

> A second problem I noticed is when a caller calls debugfs_create_file more than
> once : the result is that the debugfs_remove will fail. I guess the second call
> to debugfs_create_file increments the reference counts (there is not fix for
> this issue in my patch).
> 
> Third problem : a failing call to debugfs_remove keeps the filesystem pinned.
> (fixed by calling simple_release_fs in the error path).
> 
> The third problem : When a process is in a directory, the call to simple_rmdir
> will fail. Debugfs does not use its return value. I noticed that calling
> simple_unlink on a directory when simple_rmdir fails removes the directory that
> would otherwise be left there. I am not sure if this approach is correct
> through.
> 
> This patch is against Linux 2.6.18.

Care to split this into 4 different patches (you seem to have 4 issues
here), so that it's easier to see them, and it will follow the
1-patch-per-issue rule?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/