How to get list of all files open in the system

How to get list of all files open in the system

[Sergei Starovoi]

Hi, all.

I'm writing a kernel module. One of its tasks requires getting full paths of all open files in the system.

My first solution essentially looks like:
 for_each_process_thread(process, thread)
  iterate_fd(files, 0, my_callback, NULL);
my_callback calls d_path for passed file->f_path to get its full path.

But this solution has obvious problems:
   A. It will skip files which were opened directly from kernel code (using filp_open for example);
   B. It iterates over fd_table for each thread, performing a lot of unnecessary work (invoking my_callback multiple times for one file).

My questions are:
1) Is there any bettter way to get full paths of all open files?
2) If there is no better way, what kind of locking should i use
   a) to protect access to task list when invoking for_each_process_thread?
   b) to protect access to thread's fd_table when invoking iterate_fd?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151114/a7f61aac/attachment.html 

How to get list of all files open in the system

[Greg KH]

On Sat, Nov 14, 2015 at 08:13:26PM +0200, Sergei Starovoi wrote:
> Hi, all.
>  
> I'm writing a kernel module. One of its tasks requires getting full paths of
> all open files in the system.

That's a very odd request, why would a kernel module ever care about
such a thing?  And in what namespace do these files need to be in?

> My first solution essentially looks like:
>  for_each_process_thread(process, thread)
>   iterate_fd(files, 0, my_callback, NULL);
> my_callback calls d_path for passed file->f_path to get its full path.
>  
> But this solution has obvious problems:
>    A. It will skip files which were opened directly from kernel code (using
> filp_open for example);

You shouldn't care about those, but then again, you aren't saying why
you care about open files, so I can't judge that.

thanks,

greg k-h