linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Gruenbacher <agruen@suse.de>
To: Eric Paris <eparis@redhat.com>, David Howells <dhowells@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Matt Helsley <matthltc@us.ibm.com>,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	viro@zeniv.linux.org.uk, akpm@linux-foundation.org,
	Michael Kerrisk <michael.kerrisk@gmail.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: [GIT PULL] notification tree: directory events
Date: Fri, 20 Aug 2010 13:07:36 +0200	[thread overview]
Message-ID: <201008201307.37748.agruen@suse.de> (raw)
In-Reply-To: <1282275497.21419.2073.camel@acb20005.ipt.aol.com>

On Friday 20 August 2010 05:38:17 Eric Paris wrote:
> On Fri, 2010-08-20 at 01:41 +0200, Andreas Gruenbacher wrote:
> > 	(2) Construct a file descriptor that refers to the file that could not be
> > 	    dentry_open()ed, but which cannot be used for any I/O, and pass the
> > 	    error condition in a separate field.  The kernel has all the
> > 	    information needed for doing that, and it shouldn't be hard to
> > 	    implement.
> > 	    
> > 	    That way, the listener always has a file descriptor to poke around
> > 	    with.
> > 
> > Failing to do (2) right now, I think it still makes sense to separate the
> > file descriptor from the error code in struct fanotify_event_metadata;
> > this would enable us to do (2) later if we decide to.
> 
> In reference to (2), I don't even understand what an fd is that can't be
> used for anything.  I'll let Al or Christoph respond if they feel like
> it, but it sounds crazy to me.  You want to just magic up some struct
> file and attach a struct path to it even though dentry_open() failed?
> So you can do what with it?

I've never said the fd can't be used for anything.  The idea would be to
allow the file to be stat()ed, to poke around in /proc/fd/ in the hope to
get a somewhat useful pathname out, or to use something like xstat() on the
fd one day (David Howells is going to be looking into that).

It would be a good thing to be able to use the same mechanisms for
identifying the file that are available for a "normal" file descriptor.

> On a more realistic note, I'm not opposed to (1), however, your
> arguments would lead one to reject inotify as the IN_OVERFLOW or oom
> conditions will result in silently lost events or events which provide
> no useful information since the notification system has broken down.

Nonsense.  An overflow event obviously is not associated with any one file,
so that would be the (only) case where you should get an event that doesn't
refer to a file.

Andreas

  parent reply	other threads:[~2010-08-20 11:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1281110319.17812.21.camel@dhcp231-200.rdu.redhat.com>
     [not found] ` <201008191444.08966.agruen@suse.de>
     [not found]   ` <1282230012.21419.1566.camel@acb20005.ipt.aol.com>
2010-08-19 23:41     ` [GIT PULL] notification tree: directory events Andreas Gruenbacher
2010-08-20  3:38       ` Eric Paris
2010-08-20  5:19         ` Andreas Dilger
2010-08-20  9:21           ` Christoph Hellwig
2010-08-20 15:29             ` Andreas Gruenbacher
2010-08-20 20:39               ` Andreas Dilger
2010-08-20  9:09         ` Tvrtko Ursulin
2010-08-20 11:07         ` Andreas Gruenbacher [this message]
2010-08-20 11:25         ` Andreas Gruenbacher
2010-08-20 12:16         ` Andreas Gruenbacher
     [not found] ` <1282016387.21419.113.camel@acb20005.ipt.aol.com>
     [not found]   ` <201008171009.51737.agruen@suse.de>
2010-08-20  0:00     ` [GIT PULL] notification tree - try 37! Andreas Gruenbacher
     [not found] ` <201008192307.32526.agruen@suse.de>
     [not found]   ` <1282276236.21419.2101.camel@acb20005.ipt.aol.com>
2010-08-20 12:38     ` Andreas Gruenbacher
2010-08-23 16:46       ` Eric Paris
2010-08-23 22:38         ` Andreas Gruenbacher

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=201008201307.37748.agruen@suse.de \
    --to=agruen@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=eparis@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthltc@us.ibm.com \
    --cc=michael.kerrisk@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    /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;
as well as URLs for NNTP newsgroup(s).