1. 06 10月, 2005 1 次提交
  2. 04 10月, 2005 1 次提交
  3. 16 9月, 2005 2 次提交
  4. 01 9月, 2005 1 次提交
  5. 31 8月, 2005 2 次提交
  6. 27 8月, 2005 1 次提交
    • S
      [PATCH] Fix oops in fs/locks.c on close of file with pending locks · d634cc15
      Steve French 提交于
      The recent change to locks_remove_flock code in fs/locks.c changes how
      byte range locks are removed from closing files, which shows up a bug in
      cifs.
      
      The assumption in the cifs code was that the close call sent to the
      server would remove any pending locks on the server on this file, but
      that is no longer safe as the fs/locks.c code on the client wants unlock
      of 0 to PATH_MAX to remove all locks (at least from this client, it is
      not possible AFAIK to remove all locks from other clients made to the
      server copy of the file).
      
      Note that cifs locks are different from posix locks - and it is not
      possible to map posix locks perfectly on the wire yet, due to
      restrictions of the cifs network protocol, even to Samba without adding
      a new request type to the network protocol (which we plan to do for
      Samba 3.0.21 within a few months), but the local client will have the
      correct, posix view, of the lock in most cases.
      
      The correct fix for cifs for this would involve a bigger change than I
      would like to do this late in the 2.6.13-rc cycle - and would involve
      cifs keeping track of all unmerged (uncoalesced) byte range locks for
      each remote inode and scanning that list to remove locks that intersect
      or fall wholly within the range - locks that intersect may have to be
      reaquired with the smaller, remaining range.
      Signed-off-by: NSteve French <sfrench@us.ibm.com>
      Signed-off-by: NDave Kleikamp <shaggy@austin.ibm.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d634cc15
  7. 25 8月, 2005 2 次提交
  8. 21 8月, 2005 1 次提交
  9. 24 6月, 2005 1 次提交
  10. 23 6月, 2005 1 次提交
  11. 14 6月, 2005 1 次提交
  12. 10 6月, 2005 1 次提交
  13. 29 4月, 2005 3 次提交
  14. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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