1. 12 Jan, 2006 1 commit
  2. 09 Jan, 2006 1 commit
  3. 09 Sep, 2005 3 commits
  4. 27 Jul, 2005 1 commit
    • Peter Staubach's avatar
      [PATCH] stale POSIX lock handling · c293621b
      Peter Staubach authored
      I believe that there is a problem with the handling of POSIX locks, which
      the attached patch should address.
      
      The problem appears to be a race between fcntl(2) and close(2).  A
      multithreaded application could close a file descriptor at the same time as
      it is trying to acquire a lock using the same file descriptor.  I would
      suggest that that multithreaded application is not providing the proper
      synchronization for itself, but the OS should still behave correctly.
      
      SUS3 (Single UNIX Specification Version 3, read: POSIX) indicates that when
      a file descriptor is closed, that all POSIX locks on the file, owned by the
      process which closed the file descriptor, should be released.
      
      The trick here is when those locks are released.  The current code releases
      all locks which exist when close is processing, but any locks in progress
      are handled when the last reference to the open file is released.
      
      There are three cases to consider.
      
      One is the simple case, a multithreaded (mt) process has a file open and
      races to close it and acquire a lock on it.  In this case, the close will
      release one reference to the open file and when the fcntl is done, it will
      release the other reference.  For this situation, no locks should exist on
      the file when both the close and fcntl operations are done.  The current
      system will handle this case because the last reference to the open file is
      being released.
      
      The second case is when the mt process has dup(2)'d the file descriptor.
      The close will release one reference to the file and the fcntl, when done,
      will release another, but there will still be at least one more reference
      to the open file.  One could argue that the existence of a lock on the file
      after the close has completed is okay, because it was acquired after the
      close operation and there is still a way for the application to release the
      lock on the file, using an existing file descriptor.
      
      The third case is when the mt process has forked, after opening the file
      and either before or after becoming an mt process.  In this case, each
      process would hold a reference to the open file.  For each process, this
      degenerates to first case above.  However, the lock continues to exist
      until both processes have released their references to the open file.  This
      lock could block other lock requests.
      
      The changes to release the lock when the last reference to the open file
      aren't quite right because they would allow the lock to exist as long as
      there was a reference to the open file.  This is too long.
      
      The new proposed solution is to add support in the fcntl code path to
      detect a race with close and then to release the lock which was just
      acquired when such as race is detected.  This causes locks to be released
      in a timely fashion and for the system to conform to the POSIX semantic
      specification.
      
      This was tested by instrumenting a kernel to detect the handling locks and
      then running a program which generates case #3 above.  A dangling lock
      could be reliably generated.  When the changes to detect the close/fcntl
      race were added, a dangling lock could no longer be generated.
      
      Cc: Matthew Wilcox <willy@debian.org>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      c293621b
  5. 01 May, 2005 1 commit
  6. 16 Apr, 2005 2 commits
    • Bharath Ramesh's avatar
      [PATCH] AYSNC IO using singals other than SIGIO · fc9c9ab2
      Bharath Ramesh authored
      A question on sigwaitinfo based IO mechanism in multithreaded applications.
      
      I am trying to use RT signals to notify me of IO events using RT signals
      instead of SIGIO in a multithreaded applications.  I noticed that there was
      some discussion on lkml during november 1999 with the subject of the
      discussion as "Signal driven IO".  In the thread I noticed that RT signals
      were being delivered to the worker thread.  I am running 2.6.10 kernel and
      I am trying to use the very same mechanism and I find that only SIGIO being
      propogated to the worker threads and RT signals only being propogated to
      the main thread and not the worker threads where I actually want them to be
      propogated too.  On further inspection I found that the following patch
      which I have attached solves the problem.
      
      I am not sure if this is a bug or feature in the kernel.
      
      
      Roland McGrath <roland@redhat.com> said:
      
      This relates only to fcntl F_SETSIG, which is a Linux extension.  So there is
      no POSIX issue.  When changing various things like the normal SIGIO signalling
      to do group signals, I was concerned strictly with the POSIX semantics and
      generally avoided touching things in the domain of Linux inventions.  That's
      why I didn't change this when I changed the call right next to it.  There is
      no reason I can see that F_SETSIG-requested signals shouldn't use a group
      signal like normal SIGIO does.  I'm happy to ACK this patch, there is nothing
      wrong with its change to the semantics in my book.  But neither POSIX nor I
      care a whit what F_SETSIG does.
      Signed-off-by: 's avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: 's avatarLinus Torvalds <torvalds@osdl.org>
      fc9c9ab2
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4