1. 01 May, 2008 2 commits
    • Al Viro's avatar
      [PATCH] split linux/file.h · 9f3acc31
      Al Viro authored
      Initial splitoff of the low-level stuff; taken to fdtable.h
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
    • Al Viro's avatar
      Fix dnotify/close race · 214b7049
      Al Viro authored
      We have a race between fcntl() and close() that can lead to
      dnotify_struct inserted into inode's list *after* the last descriptor
      had been gone from current->files.
      Since that's the only point where dnotify_struct gets evicted, we are
      screwed - it will stick around indefinitely.  Even after struct file in
      question is gone and freed.  Worse, we can trigger send_sigio() on it at
      any later point, which allows to send an arbitrary signal to arbitrary
      process if we manage to apply enough memory pressure to get the page
      that used to host that struct file and fill it with the right pattern...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  2. 20 Jul, 2007 1 commit
    • Paul Mundt's avatar
      mm: Remove slab destructors from kmem_cache_create(). · 20c2df83
      Paul Mundt authored
      Slab destructors were no longer supported after Christoph's
      c59def9f change. They've been
      BUGs for both slab and slub, and slob never supported them
      This rips out support for the dtor pointer from kmem_cache_create()
      completely and fixes up every single callsite in the kernel (there were
      about 224, not including the slab allocator definitions themselves,
      or the documentation references).
      Signed-off-by: default avatarPaul Mundt <lethal@linux-sh.org>
  3. 08 Dec, 2006 1 commit
  4. 07 Dec, 2006 2 commits
  5. 02 Oct, 2006 1 commit
  6. 26 Mar, 2006 1 commit
  7. 16 Apr, 2005 1 commit
    • 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!