An error occurred fetching the project authors.
  1. 09 Sep, 2014 1 commit
  2. 18 Feb, 2014 1 commit
    • Jan Kara's avatar
      inotify: Fix reporting of cookies for inotify events · 45a22f4c
      Jan Kara authored
      My rework of handling of notification events (namely commit 7053aee2
      "fsnotify: do not share events between notification groups") broke
      sending of cookies with inotify events. We didn't propagate the value
      passed to fsnotify() properly and passed 4 uninitialized bytes to
      userspace instead (so it is also an information leak). Sadly I didn't
      notice this during my testing because inotify cookies aren't used very
      much and LTP inotify tests ignore them.
      
      Fix the problem by passing the cookie value properly.
      
      Fixes: 7053aee2Reported-by: default avatarVegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      45a22f4c
  3. 22 Jan, 2014 3 commits
    • Jan Kara's avatar
      fsnotify: remove pointless NULL initializers · 56b27cf6
      Jan Kara authored
      We usually rely on the fact that struct members not specified in the
      initializer are set to NULL.  So do that with fsnotify function pointers
      as well.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      56b27cf6
    • Jan Kara's avatar
      fsnotify: remove .should_send_event callback · 83c4c4b0
      Jan Kara authored
      After removing event structure creation from the generic layer there is
      no reason for separate .should_send_event and .handle_event callbacks.
      So just remove the first one.
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      83c4c4b0
    • Jan Kara's avatar
      fsnotify: do not share events between notification groups · 7053aee2
      Jan Kara authored
      Currently fsnotify framework creates one event structure for each
      notification event and links this event into all interested notification
      groups.  This is done so that we save memory when several notification
      groups are interested in the event.  However the need for event
      structure shared between inotify & fanotify bloats the event structure
      so the result is often higher memory consumption.
      
      Another problem is that fsnotify framework keeps path references with
      outstanding events so that fanotify can return open file descriptors
      with its events.  This has the undesirable effect that filesystem cannot
      be unmounted while there are outstanding events - a regression for
      inotify compared to a situation before it was converted to fsnotify
      framework.  For fanotify this problem is hard to avoid and users of
      fanotify should kind of expect this behavior when they ask for file
      descriptors from notified files.
      
      This patch changes fsnotify and its users to create separate event
      structure for each group.  This allows for much simpler code (~400 lines
      removed by this patch) and also smaller event structures.  For example
      on 64-bit system original struct fsnotify_event consumes 120 bytes, plus
      additional space for file name, additional 24 bytes for second and each
      subsequent group linking the event, and additional 32 bytes for each
      inotify group for private data.  After the conversion inotify event
      consumes 48 bytes plus space for file name which is considerably less
      memory unless file names are long and there are several groups
      interested in the events (both of which are uncommon).  Fanotify event
      fits in 56 bytes after the conversion (fanotify doesn't care about file
      names so its events don't have to have it allocated).  A win unless
      there are four or more fanotify groups interested in the event.
      
      The conversion also solves the problem with unmount when only inotify is
      used as we don't have to grab path references for inotify events.
      
      [hughd@google.com: fanotify: fix corruption preventing startup]
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Eric Paris <eparis@parisplace.org>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      7053aee2
  4. 09 Jul, 2013 1 commit
  5. 23 Feb, 2013 1 commit
  6. 11 Dec, 2012 1 commit
  7. 28 Jul, 2010 20 commits
  8. 20 Oct, 2009 1 commit
    • Andreas Gruenbacher's avatar
      dnotify: ignore FS_EVENT_ON_CHILD · 94552684
      Andreas Gruenbacher authored
      Mask off FS_EVENT_ON_CHILD in dnotify_handle_event().  Otherwise, when there
      is more than one watch on a directory and dnotify_should_send_event()
      succeeds, events with FS_EVENT_ON_CHILD set will trigger all watches and cause
      spurious events.
      
      This case was overlooked in commit e42e2773.
      
      	#define _GNU_SOURCE
      
      	#include <stdio.h>
      	#include <stdlib.h>
      	#include <unistd.h>
      	#include <signal.h>
      	#include <sys/types.h>
      	#include <sys/stat.h>
      	#include <fcntl.h>
      	#include <string.h>
      
      	static void create_event(int s, siginfo_t* si, void* p)
      	{
      		printf("create\n");
      	}
      
      	static void delete_event(int s, siginfo_t* si, void* p)
      	{
      		printf("delete\n");
      	}
      
      	int main (void) {
      		struct sigaction action;
      		char *tmpdir, *file;
      		int fd1, fd2;
      
      		sigemptyset (&action.sa_mask);
      		action.sa_flags = SA_SIGINFO;
      
      		action.sa_sigaction = create_event;
      		sigaction (SIGRTMIN + 0, &action, NULL);
      
      		action.sa_sigaction = delete_event;
      		sigaction (SIGRTMIN + 1, &action, NULL);
      
      	#	define TMPDIR "/tmp/test.XXXXXX"
      		tmpdir = malloc(strlen(TMPDIR) + 1);
      		strcpy(tmpdir, TMPDIR);
      		mkdtemp(tmpdir);
      
      	#	define TMPFILE "/file"
      		file = malloc(strlen(tmpdir) + strlen(TMPFILE) + 1);
      		sprintf(file, "%s/%s", tmpdir, TMPFILE);
      
      		fd1 = open (tmpdir, O_RDONLY);
      		fcntl(fd1, F_SETSIG, SIGRTMIN);
      		fcntl(fd1, F_NOTIFY, DN_MULTISHOT | DN_CREATE);
      
      		fd2 = open (tmpdir, O_RDONLY);
      		fcntl(fd2, F_SETSIG, SIGRTMIN + 1);
      		fcntl(fd2, F_NOTIFY, DN_MULTISHOT | DN_DELETE);
      
      		if (fork()) {
      			/* This triggers a create event */
      			creat(file, 0600);
      			/* This triggers a create and delete event (!) */
      			unlink(file);
      		} else {
      			sleep(1);
      			rmdir(tmpdir);
      		}
      
      		return 0;
      	}
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@suse.de>
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      94552684
  9. 11 Jun, 2009 6 commits
  10. 31 Dec, 2008 2 commits
    • Eric Paris's avatar
      filesystem notification: create fs/notify to contain all fs notification · 272eb014
      Eric Paris authored
      Creating a generic filesystem notification interface, fsnotify, which will be
      used by inotify, dnotify, and eventually fanotify is really starting to
      clutter the fs directory.  This patch simply moves inotify and dnotify into
      fs/notify/inotify and fs/notify/dnotify respectively to make both current fs/
      and future notification tidier.
      Signed-off-by: default avatarEric Paris <eparis@redhat.com>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      272eb014
    • Al Viro's avatar
      kill ->dir_notify() · 6badd79b
      Al Viro authored
      Remove the hopelessly misguided ->dir_notify().  The only instance (cifs)
      has been broken by design from the very beginning; the objects it creates
      are never destroyed, keep references to struct file they can outlive, nothing
      that could possibly evict them exists on close(2) path *and* no locking
      whatsoever is done to prevent races with close(), should the previous, er,
      deficiencies someday be dealt with.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      6badd79b
  11. 01 May, 2008 2 commits
    • Al Viro's avatar
      [PATCH] split linux/file.h · 9f3acc31
      Al Viro authored
      Initial splitoff of the low-level stuff; taken to fdtable.h
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      9f3acc31
    • Al Viro's avatar
      Fix dnotify/close race · 214b7049
      Al Viro authored
      We have a race between fcntl() and close() that can lead to
      dnotify_struct inserted into inode's list *after* the last descriptor
      had been gone from current->files.
      
      Since that's the only point where dnotify_struct gets evicted, we are
      screwed - it will stick around indefinitely.  Even after struct file in
      question is gone and freed.  Worse, we can trigger send_sigio() on it at
      any later point, which allows to send an arbitrary signal to arbitrary
      process if we manage to apply enough memory pressure to get the page
      that used to host that struct file and fill it with the right pattern...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      214b7049
  12. 20 Jul, 2007 1 commit
    • Paul Mundt's avatar
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt authored
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      either.
      
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
      20c2df83