1. 10 10月, 2010 1 次提交
  2. 11 8月, 2010 1 次提交
  3. 28 7月, 2010 2 次提交
    • S
      fanotify: FMODE_NONOTIFY and __O_SYNC in sparc conflict · 12ed2e36
      Signed-off-by: Wu Fengguang 提交于
      sparc used the same value as FMODE_NONOTIFY so change FMODE_NONOTIFY to be
      something unique.
      Signed-off-by: NWu Fengguang <fengguang.wu@intel.com>
      Signed-off-by: NEric Paris <eparis@redhat.com>
      12ed2e36
    • E
      vfs: introduce FMODE_NONOTIFY · ecf081d1
      Eric Paris 提交于
      This is a new f_mode which can only be set by the kernel.  It indicates
      that the fd was opened by fanotify and should not cause future fanotify
      events.  This is needed to prevent fanotify livelock.  An example of
      obvious livelock is from fanotify close events.
      
      Process A closes file1
      This creates a close event for file1.
      fanotify opens file1 for Listener X
      Listener X deals with the event and closes its fd for file1.
      This creates a close event for file1.
      fanotify opens file1 for Listener X
      Listener X deals with the event and closes its fd for file1.
      This creates a close event for file1.
      fanotify opens file1 for Listener X
      Listener X deals with the event and closes its fd for file1.
      notice a pattern?
      
      The fix is to add the FMODE_NONOTIFY bit to the open filp done by the kernel
      for fanotify.  Thus when that file is used it will not generate future
      events.
      
      This patch simply defines the bit.
      Signed-off-by: NEric Paris <eparis@redhat.com>
      ecf081d1
  4. 18 12月, 2009 1 次提交
  5. 10 12月, 2009 1 次提交
    • C
      vfs: Implement proper O_SYNC semantics · 6b2f3d1f
      Christoph Hellwig 提交于
      While Linux provided an O_SYNC flag basically since day 1, it took until
      Linux 2.4.0-test12pre2 to actually get it implemented for filesystems,
      since that day we had generic_osync_around with only minor changes and the
      great "For now, when the user asks for O_SYNC, we'll actually give
      O_DSYNC" comment.  This patch intends to actually give us real O_SYNC
      semantics in addition to the O_DSYNC semantics.  After Jan's O_SYNC
      patches which are required before this patch it's actually surprisingly
      simple, we just need to figure out when to set the datasync flag to
      vfs_fsync_range and when not.
      
      This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's
      numerical value to keep binary compatibility, and adds a new real O_SYNC
      flag.  To guarantee backwards compatiblity it is defined as expanding to
      both the O_DSYNC and the new additional binary flag (__O_SYNC) to make
      sure we are backwards-compatible when compiled against the new headers.
      
      This also means that all places that don't care about the differences can
      just check O_DSYNC and get the right behaviour for O_SYNC, too - only
      places that actuall care need to check __O_SYNC in addition.  Drivers and
      network filesystems have been updated in a fail safe way to always do the
      full sync magic if O_DSYNC is set.  The few places setting O_SYNC for
      lower layers are kept that way for now to stay failsafe.
      
      We enforce that O_DSYNC is set when __O_SYNC is set early in the open path
      to make sure we always get these sane options.
      
      Note that parisc really screwed up their headers as they already define a
      O_DSYNC that has always been a no-op.  We try to repair it by using it for
      the new O_DSYNC and redefinining O_SYNC to send both the traditional
      O_SYNC numerical value _and_ the O_DSYNC one.
      
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Grant Grundler <grundler@parisc-linux.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Andreas Dilger <adilger@sun.com>
      Acked-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NUlrich Drepper <drepper@redhat.com>
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJan Kara <jack@suse.cz>
      6b2f3d1f
  6. 18 11月, 2009 1 次提交
  7. 12 11月, 2009 1 次提交
  8. 24 9月, 2009 1 次提交
    • P
      fcntl: add F_[SG]ETOWN_EX · ba0a6c9f
      Peter Zijlstra 提交于
      In order to direct the SIGIO signal to a particular thread of a
      multi-threaded application we cannot, like suggested by the manpage, put a
      TID into the regular fcntl(F_SETOWN) call.  It will still be send to the
      whole process of which that thread is part.
      
      Since people do want to properly direct SIGIO we introduce F_SETOWN_EX.
      
      The need to direct SIGIO comes from self-monitoring profiling such as with
      perf-counters.  Perf-counters uses SIGIO to notify that new sample data is
      available.  If the signal is delivered to the same task that generated the
      new sample it can augment that data by inspecting the task's user-space
      state right after it returns from the kernel.  This is esp.  convenient
      for interpreted or virtual machine driven environments.
      
      Both F_SETOWN_EX and F_GETOWN_EX take a pointer to a struct f_owner_ex
      as argument:
      
      struct f_owner_ex {
      	int   type;
      	pid_t pid;
      };
      
      Where type is one of F_OWNER_TID, F_OWNER_PID or F_OWNER_GID.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Reviewed-by: NOleg Nesterov <oleg@redhat.com>
      Tested-by: Nstephane eranian <eranian@googlemail.com>
      Cc: Michael Kerrisk <mtk.manpages@googlemail.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba0a6c9f
  9. 27 3月, 2009 1 次提交
    • A
      make exported headers use strict posix types · 85efde6f
      Arnd Bergmann 提交于
      A number of standard posix types are used in exported headers, which
      is not allowed if __STRICT_KERNEL_NAMES is defined. In order to
      get rid of the non-__STRICT_KERNEL_NAMES part and to make sane headers
      the default, we have to change them all to safe types.
      
      There are also still some leftovers in reiserfs_fs.h, elfcore.h
      and coda.h, but these files have not compiled in user space for
      a long time.
      
      This leaves out the various integer types ({u_,u,}int{8,16,32,64}_t),
      which we take care of separately.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Cc: netdev@vger.kernel.org
      Cc: linux-ppp@vger.kernel.org
      Cc: Jaroslav Kysela <perex@perex.cz>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      85efde6f
  10. 17 7月, 2007 1 次提交
    • U
      Introduce O_CLOEXEC · f23513e8
      Ulrich Drepper 提交于
      The problem is as follows: in multi-threaded code (or more correctly: all
      code using clone() with CLONE_FILES) we have a race when exec'ing.
      
         thread #1                       thread #2
      
         fd=open()
      
                                         fork + exec
      
        fcntl(fd,F_SETFD,FD_CLOEXEC)
      
      In some applications this can happen frequently.  Take a web browser.  One
      thread opens a file and another thread starts, say, an external PDF viewer.
       The result can even be a security issue if that open file descriptor
      refers to a sensitive file and the external program can somehow be tricked
      into using that descriptor.
      
      Just adding O_CLOEXEC support to open() doesn't solve the whole set of
      problems.  There are other ways to create file descriptors (socket,
      epoll_create, Unix domain socket transfer, etc).  These can and should be
      addressed separately though.  open() is such an easy case that it makes not
      much sense putting the fix off.
      
      The test program:
      
      #include <errno.h>
      #include <fcntl.h>
      #include <stdio.h>
      #include <unistd.h>
      
      #ifndef O_CLOEXEC
      # define O_CLOEXEC 02000000
      #endif
      
      int
      main (int argc, char *argv[])
      {
        int fd;
        if (argc > 1)
          {
            fd = atol (argv[1]);
            printf ("child: fd = %d\n", fd);
            if (fcntl (fd, F_GETFD) == 0 || errno != EBADF)
              {
                puts ("file descriptor valid in child");
                return 1;
              }
            return 0;
          }
      
        fd = open ("/proc/self/exe", O_RDONLY | O_CLOEXEC);
        printf ("in parent: new fd = %d\n", fd);
        char buf[20];
        snprintf (buf, sizeof (buf), "%d", fd);
        execl ("/proc/self/exe", argv[0], buf, NULL);
        puts ("execl failed");
        return 1;
      }
      
      [kyle@parisc-linux.org: parisc fix]
      Signed-off-by: NUlrich Drepper <drepper@redhat.com>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Davide Libenzi <davidel@xmailserver.org>
      Cc: Michael Kerrisk <mtk-manpages@gmx.net>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f23513e8
  11. 26 4月, 2006 1 次提交
  12. 08 9月, 2005 5 次提交