1. 25 7月, 2008 1 次提交
  2. 01 5月, 2008 1 次提交
  3. 19 10月, 2007 1 次提交
  4. 21 2月, 2007 1 次提交
  5. 15 11月, 2006 1 次提交
  6. 12 10月, 2006 1 次提交
  7. 16 5月, 2006 1 次提交
    • I
      [PATCH] autofs4: NFY_NONE wait race fix · a5370553
      Ian Kent 提交于
      This patch fixes two problems.
      
      First, the comparison of entries in the waitq.c was incorrect.
      
      Second, the NFY_NONE check was incorrect. The test of whether the dentry
      is mounted if ineffective, for example, if an expire fails then we could
      wait forever on a non existant expire. The bug was identified by Jeff
      Moyer.
      
      The patch changes autofs4 to wait on expires only as this is all that's
      needed.  If there is no existing wait when autofs4_wait is call with a type
      of NFY_NONE it delays until either a wait appears or the the expire flag is
      cleared.
      Signed-off-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a5370553
  8. 28 3月, 2006 4 次提交
  9. 23 3月, 2006 1 次提交
  10. 07 11月, 2005 1 次提交
  11. 08 7月, 2005 1 次提交
  12. 22 6月, 2005 1 次提交
    • I
      [PATCH] autofs4: post expire race fix · cc9acc88
      Ian Kent 提交于
      At the tail end of an expire it's possible for a process to enter
      autofs4_wait, with a waitq type of NFY_NONE but find that the expire is
      finished.  In this cause autofs4_wait will try to create a new wait but not
      notify the daemon leading to a hang.  As the wait type is meant to delay mount
      requests from revalidate or lookup during an expire and the expire is done all
      we need to do is check if the dentry is a mountpoint.  If it's not then we're
      done.
      Signed-off-by: NIan Kent <raven@themaw.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cc9acc88
  13. 01 5月, 2005 1 次提交
  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