1. 21 3月, 2006 13 次提交
  2. 14 3月, 2006 1 次提交
    • T
      [PATCH] NFS: Fix a potential panic in O_DIRECT · 143f412e
      Trond Myklebust 提交于
      Based on an original patch by Mike O'Connor and Greg Banks of SGI.
      
      Mike states:
      
      A normal user can panic an NFS client and cause a local DoS with
      'judicious'(?) use of O_DIRECT.  Any O_DIRECT write to an NFS file where the
      user buffer starts with a valid mapped page and contains an unmapped page,
      will crash in this way.  I haven't followed the code, but O_DIRECT reads with
      similar user buffers will probably also crash albeit in different ways.
      
      Details: when nfs_get_user_pages() calls get_user_pages(), it detects and
      correctly handles get_user_pages() returning an error, which happens if the
      first page covered by the user buffer's address range is unmapped.  However,
      if the first page is mapped but some subsequent page isn't, get_user_pages()
      will return a positive number which is less than the number of pages requested
      (this behaviour is sort of analagous to a short write() call and appears to be
      intentional).  nfs_get_user_pages() doesn't detect this and hands off the
      array of pages (whose last few elements are random rubbish from the newly
      allocated array memory) to it's caller, whence they go to
      nfs_direct_write_seg(), which then totally ignores the nr_pages it's given,
      and calculates its own idea of how many pages are in the array from the user
      buffer length.  Needless to say, when it comes to transmit those uninitialised
      page* pointers, we see a crash in the network stack.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      143f412e
  3. 02 2月, 2006 1 次提交
  4. 07 1月, 2006 5 次提交
  5. 20 12月, 2005 1 次提交
  6. 05 11月, 2005 1 次提交
  7. 24 6月, 2005 1 次提交
  8. 23 6月, 2005 1 次提交
    • T
      [PATCH] NFS: Fix the file size revalidation · 951a143b
      Trond Myklebust 提交于
       Instead of looking at whether or not the file is open for writes before
       we accept to update the length using the server value, we should rather
       be looking at whether or not we are currently caching any writes.
      
       Failure to do so means in particular that we're not updating the file
       length correctly after obtaining a POSIX or BSD lock.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      951a143b
  9. 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