1. 29 Jun, 2006 4 commits
    • Yasunori Goto's avatar
      [PATCH] solve config broken: undefined reference to `online_page' · cc57637b
      Yasunori Goto authored
      Memory hotplug code of i386 adds memory to only highmem.  So, if
      CONFIG_HIGHMEM is not set, CONFIG_MEMORY_HOTPLUG shouldn't be set.
      Otherwise, it causes compile error.
      
      In addition, many architecture can't use memory hotplug feature yet.  So, I
      introduce CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG.
      Signed-off-by: default avatarYasunori Goto <y-goto@jp.fujitsu.com>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      cc57637b
    • Andrew Morton's avatar
      [PATCH] generic_file_buffered_write(): handle zero-length iovec segments · 81b0c871
      Andrew Morton authored
      The recent generic_file_write() deadlock fix caused
      generic_file_buffered_write() to loop inifinitely when presented with a
      zero-length iovec segment.  Fix.
      
      Note that this fix deliberately avoids calling ->prepare_write(),
      ->commit_write() etc with a zero-length write.  This is because I don't trust
      all filesystems to get that right.
      
      This is a cautious approach, for 2.6.17.x.  For 2.6.18 we should just go ahead
      and call ->prepare_write() and ->commit_write() with the zero length and fix
      any broken filesystems.  So I'll make that change once this code is stabilised
      and backported into 2.6.17.x.
      
      The reason for preferring to call ->prepare_write() and ->commit_write() with
      the zero-length segment: a zero-length segment _should_ be sufficiently
      uncommon that this is the correct way of handling it.  We don't want to
      optimise for poorly-written userspace at the expense of well-written
      userspace.
      
      Cc: "Vladimir V. Saveliev" <vs@namesys.com>
      Cc: Neil Brown <neilb@suse.de>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Chris Wright <chrisw@sous-sol.org>
      Cc: Greg KH <greg@kroah.com>
      Cc: <stable@kernel.org>
      Cc: walt <wa1ter@myrealbox.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      81b0c871
    • Adrian Bunk's avatar
      [PATCH] fix sgivwfb compile · 0686cd8f
      Adrian Bunk authored
      drivers/built-in.o: In function `sgivwfb_set_par':
      sgivwfb.c:(.text+0x88583): undefined reference to `sgivwfb_mem_phys'
      sgivwfb.c:(.text+0x88596): undefined reference to `sgivwfb_mem_phys'
      sgivwfb.c:(.text+0x885a8): undefined reference to `sgivwfb_mem_phys'
      drivers/built-in.o: In function `sgivwfb_check_var':
      sgivwfb.c:(.text+0x88ad0): undefined reference to `sgivwfb_mem_size'
      drivers/built-in.o: In function `sgivwfb_mmap':
      sgivwfb.c:(.text+0x88c75): undefined reference to `sgivwfb_mem_size'
      sgivwfb.c:(.text+0x88c7f): undefined reference to `sgivwfb_mem_phys'
      drivers/built-in.o: In function `sgivwfb_probe':
      sgivwfb.c:(.init.text+0x4060): undefined reference to `sgivwfb_mem_size'
      sgivwfb.c:(.init.text+0x4065): undefined reference to `sgivwfb_mem_phys'
      sgivwfb.c:(.init.text+0x4076): undefined reference to `sgivwfb_mem_phys'
      sgivwfb.c:(.init.text+0x409c): undefined reference to `sgivwfb_mem_size'
      sgivwfb.c:(.init.text+0x410e): undefined reference to `sgivwfb_mem_size'
      sgivwfb.c:(.init.text+0x4113): undefined reference to `sgivwfb_mem_phys'
      sgivwfb.c:(.init.text+0x4162): undefined reference to `sgivwfb_mem_size'
      sgivwfb.c:(.init.text+0x4168): undefined reference to `sgivwfb_mem_phys'
      make: *** [.tmp_vmlinux1] Error 1
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0686cd8f
    • Linus Torvalds's avatar
      Fix vsnprintf off-by-one bug · 0a6047ee
      Linus Torvalds authored
      The recent vsnprintf() fix introduced an off-by-one, and it's now
      possible to overrun the target buffer by one byte.
      
      The "end" pointer points to past the end of the buffer, so if we
      have to truncate the result, it needs to be done though "end[-1]".
      
      [ This is just an alternate and simpler patch to one proposed by Andrew
        and Jeremy, who actually noticed the problem ]
      Acked-by: default avatarAndrew Morton <akpm@osdl.org>
      Acked-by: default avatarJeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      0a6047ee
  2. 28 Jun, 2006 36 commits