1. 09 Jan, 2006 1 commit
    • Andrew Morton's avatar
      [PATCH] fix possible PAGE_CACHE_SHIFT overflows · 54b21a79
      Andrew Morton authored
      We've had two instances recently of overflows when doing
      	64_bit_value = (32_bit_value << PAGE_CACHE_SHIFT)
      I did a tree-wide grep of `<<.*PAGE_CACHE_SHIFT' and this is the result.
      - afs_rxfs_fetch_descriptor.offset is of type off_t, which seems broken.
      - jfs and jffs are limited to 4GB anyway.
      - reiserfs map_block_for_writepage() takes an unsigned long for the block -
        it should take sector_t.  (It'll fail for huge filesystems with
      - cramfs_read() needs to use sector_t (I think cramsfs is busted on large
        filesystems anyway)
      - affs is limited in file size anyway.
      - I generally didn't fix 32-bit overflows in directory operations.
      - arm's __flush_dcache_page() is peculiar.  What if the page lies beyond 4G?
      - gss_wrap_req_priv() needs checking (snd_buf->page_base)
      Cc: Oleg Drokin <green@linuxhacker.ru>
      Cc: David Howells <dhowells@redhat.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: <reiserfs-dev@namesys.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Anton Altaparmakov <aia21@cantab.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Cc: Roman Zippel <zippel@linux-m68k.org>
      Cc: <linux-fsdevel@vger.kernel.org>
      Cc: Miklos Szeredi <miklos@szeredi.hu>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Neil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  2. 09 Sep, 2005 1 commit
  3. 07 Sep, 2005 1 commit
  4. 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!