All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Rogers <brian@xyzw.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Eric Paris <eparis@redhat.com>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@sisk.pl>
Subject: Re: [PATCH] inotify:  Ensure we alwasy write the terminating NULL.
Date: Fri, 28 Aug 2009 06:29:37 -0700	[thread overview]
Message-ID: <4A97DBC1.3000508@xyzw.org> (raw)
In-Reply-To: <m1iqg9k17v.fsf_-_@fess.ebiederm.org>

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

Eric W. Biederman wrote:
> Before the rewrite copy_event_to_user always wrote a terqminating '\0'
> byte to user space after the filename.  Since the rewrite that
> terminating byte was skipped if your filename is exactly a multiple of
> event_size.  Ouch!
>
> So add one byte to name_size before we round up and use clear_user to
> set userspace to zero like /dev/zero does instead of copying the
> strange nul_inotify_event.  I can't quite convince myself len_to_zero
> will never exceed 16 and even if it doesn't clear_user should be more
> efficient and a more accurate reflection of what the code is trying to
> do.
>
> Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
>   

I found that this change prevents my Ubuntu Karmic system from booting. 
It just idles forever very early in the process. Probably a boot script 
is waiting for an event that it doesn't receive properly.

> -	name_len = roundup(event->name_len, event_size);
> +	name_len = roundup(event->name_len + 1, event_size);
>   

This means the test later on will now always evaluate to true:
> if (name_len) {

And in cases where that test previously would have failed, the code now 
outputs a block full of zeros. Assuming that's bad and the test was 
important, I coded the attached naive fix, which is working for me.


[-- Attachment #2: 0001-inotify-Fix-events-with-no-pathname.patch --]
[-- Type: text/x-patch, Size: 1320 bytes --]

>From 1be7a610013b47be1257d2b0296d872d6bed7416 Mon Sep 17 00:00:00 2001
From: Brian Rogers <brian@xyzw.org>
Date: Fri, 28 Aug 2009 04:46:51 -0700
Subject: [PATCH] inotify: Fix events with no pathname

When an event has no pathname, there's no need to pad it with a null byte and
therefore generate an inotify_event sized block of zeros. This fixes a
regression introduced by commit 0db501bd0610ee0c0aca84d927f90bcccd09e2bd where
my system wouldn't finish booting because some process was being confused by
this.

Signed-off-by: Brian Rogers <brian@xyzw.org>
---
 fs/notify/inotify/inotify_user.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/fs/notify/inotify/inotify_user.c b/fs/notify/inotify/inotify_user.c
index 0e781bc..d94ce8b 100644
--- a/fs/notify/inotify/inotify_user.c
+++ b/fs/notify/inotify/inotify_user.c
@@ -199,7 +199,10 @@ static ssize_t copy_event_to_user(struct fsnotify_group *group,
 	/* round up event->name_len so it is a multiple of event_size
 	 * plus an extra byte for the terminating '\0'.
 	 */
-	name_len = roundup(event->name_len + 1, event_size);
+	if (event->name_len > 0)
+		name_len = roundup(event->name_len + 1, event_size);
+	else
+		name_len = 0;
 	inotify_event.len = name_len;
 
 	inotify_event.mask = inotify_mask_to_arg(event->mask);
-- 
1.6.3.3


  parent reply	other threads:[~2009-08-28 13:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-26  9:06 v2.6.31-rc6 inotify not reporting deleted files Eric W. Biederman
2009-08-26 11:25 ` Eric Paris
2009-08-26 15:11 ` Eric Paris
2009-08-26 20:12   ` Eric W. Biederman
2009-08-27 10:20   ` [PATCH] inotify: Ensure we alwasy write the terminating NULL Eric W. Biederman
2009-08-27 11:57     ` Eric Paris
2009-08-28 13:29     ` Brian Rogers [this message]
2009-08-28 14:18       ` Eric Paris

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=4A97DBC1.3000508@xyzw.org \
    --to=brian@xyzw.org \
    --cc=ebiederm@xmission.com \
    --cc=eparis@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.