1. 29 Jun, 2006 7 commits
    • Andrew Morton's avatar
      [PATCH] ufs: printk() fix · 7256d819
      Andrew Morton authored
      fs/ufs/inode.c: In function `ufs_frag_map':
      fs/ufs/inode.c:101: warning: long long unsigned int format, u64 arg (arg 4)
      fs/ufs/inode.c: In function `ufs_getfrag_block':
      fs/ufs/inode.c:432: warning: long long unsigned int format, u64 arg (arg 2)
      
      Cc: Evgeniy Dushistov <dushistov@mail.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      7256d819
    • David Howells's avatar
      [PATCH] Keys: Allow in-kernel key requestor to pass auxiliary data to upcaller · 4e54f085
      David Howells authored
      The proposed NFS key type uses its own method of passing key requests to
      userspace (upcalling) rather than invoking /sbin/request-key.  This is
      because the responsible userspace daemon should already be running and will
      be contacted through rpc_pipefs.
      
      This patch permits the NFS filesystem to pass auxiliary data to the upcall
      operation (struct key_type::request_key) so that the upcaller can use a
      pre-existing communications channel more easily.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-By: default avatarKevin Coffman <kwc@citi.umich.edu>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4e54f085
    • Andrew Morton's avatar
      [PATCH] sparc: register_cpu() build fix · 94583779
      Andrew Morton authored
      arch/sparc/kernel/setup.c: In function 'topology_init':
      arch/sparc/kernel/setup.c:528: error: too many arguments to function 'register_cpu'
      
      Cc: William Lee Irwin III <wli@holomorphy.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      94583779
    • 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 33 commits