1. 16 Nov, 2007 19 commits
    • Ralf Baechle's avatar
      MIPS: R1: Fix hazard barriers to make kernels work on R2 also. · 2f51141b
      Ralf Baechle authored
      patch 572afc24 in mainline.
      
      Tested with Malta; inflates malta_defconfig by 3932 bytes.  Ideally there
      should be additional configuration to allow getting rid of this overhead
      but that would be too much complexity at this stage of the release cycle.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2f51141b
    • Ralf Baechle's avatar
      MIPS: MT: Fix bug in multithreaded kernels. · e989c61a
      Ralf Baechle authored
      patch a76ab5c1 in mainline.
      
      When GDB writes a breakpoint into address area of inferior process the
      kernel needs to invalidate the modified memory in the inferior which
      is done by calling flush_cache_page which in turns calls
      r4k_flush_cache_page and local_r4k_flush_cache_page for VSMP or SMTC
      kernel via r4k_on_each_cpu().
      
      As the VSMP and SMTC SMP kernels for 34K are running on a single shared
      caches it is possible to get away without interprocessor function calls.
      This optimization is implemented in r4k_on_each_cpu, so
      local_r4k_flush_cache_page is only ever called on the local CPU.
      
      This is where the following code in local_r4k_flush_cache_page() strikes:
      
              /*
               * If ownes no valid ASID yet, cannot possibly have gotten
               * this page into the cache.
               */
              if (cpu_context(smp_processor_id(), mm) == 0)
                      return;
      
      On VSMP and SMTC had a function of cpu_context() for each CPU(TC).
      
      So in case another CPU than the CPU executing local_r4k_cache_flush_page
      has not accessed the mm but one of the other CPUs has there may be data
      to be flushed in the cache yet local_r4k_cache_flush_page will falsely
      return leaving the I-cache inconsistent for the breakpoint.
      
      While the issue was discovered with GDB it also exists in
      local_r4k_flush_cache_range() and local_r4k_flush_cache().
      
      Fixed by introducing a new function has_valid_asid which on MT kernels
      returns true if a mm is active on any processor in the system.
      
      This is relativly expensive since for memory acccesses in that loop
      cache misses have to be assumed but it seems the most viable solution
      for 2.6.23 and older -stable kernels.
      Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e989c61a
    • Chris Wright's avatar
      Fix sparc64 MAP_FIXED handling of framebuffer mmaps · efd233a4
      Chris Wright authored
      patch d58aa8c7 in mainline.
      
      From: Chris Wright <chrisw@sous-sol.org>
      Date: Tue, 23 Oct 2007 20:36:14 -0700
      Subject: [PATCH] [SPARC64]: pass correct addr in get_fb_unmapped_area(MAP_FIXED)
      
      Looks like the MAP_FIXED case is using the wrong address hint.  I'd
      expect the comment "don't mess with it" means pass the request
      straight on through, not change the address requested to -ENOMEM.
      Signed-off-by: default avatarChris Wright <chrisw@sous-sol.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      efd233a4
    • David Miller's avatar
      Fix sparc64 niagara optimized RAID xor asm · 71ec6448
      David Miller authored
      patch d060db63 in mainline.
      
      [SPARC64]: Fix register usage in xor_raid_4().
      
      Some typos led to using %i6/%i7 instead of %l6/%l7 in loads which is
      really really bad because those are the frame pointer and return PC.
      
      Based upon a raid5 crash report by Bertrand Joel.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      71ec6448
    • Greg Kroah-Hartman's avatar
      Linux 2.6.23.2 · 553e6a1a
      Greg Kroah-Hartman authored
      553e6a1a
    • Jens Axboe's avatar
      BLOCK: Fix bad sharing of tag busy list on queues with shared tag maps · 0520fb16
      Jens Axboe authored
      patch 6eca9004 in mainline.
      
      For the locking to work, only the tag map and tag bit map may be shared
      (incidentally, I was just explaining this to Nick yesterday, but I
      apparently didn't review the code well enough myself). But we also share
      the busy list!  The busy_list must be queue private, or we need a
      block_queue_tag covering lock as well.
      
      So we have to move the busy_list to the queue. This'll work fine, and
      it'll actually also fix a problem with blk_queue_invalidate_tags() which
      will invalidate tags across all shared queues. This is a bit confusing,
      the low level driver should call it for each queue seperately since
      otherwise you cannot kill tags on just a single queue for eg a hard
      drive that stops responding. Since the function has no callers
      currently, it's not an issue.
      
      This is fixed with commit 6eca9004 in
      Linus' tree.
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0520fb16
    • Hugh Dickins's avatar
      fix tmpfs BUG and AOP_WRITEPAGE_ACTIVATE · bba9d994
      Hugh Dickins authored
      patch 487e9bf2 in mainline.
      
      It's possible to provoke unionfs (not yet in mainline, though in mm and
      some distros) to hit shmem_writepage's BUG_ON(page_mapped(page)).  I expect
      it's possible to provoke the 2.6.23 ecryptfs in the same way (but the
      2.6.24 ecryptfs no longer calls lower level's ->writepage).
      
      This came to light with the recent find that AOP_WRITEPAGE_ACTIVATE could
      leak from tmpfs via write_cache_pages and unionfs to userspace.  There's
      already a fix (e4230030 - writeback: don't
      propagate AOP_WRITEPAGE_ACTIVATE) in the tree for that, and it's okay so
      far as it goes; but insufficient because it doesn't address the underlying
      issue, that shmem_writepage expects to be called only by vmscan (relying on
      backing_dev_info capabilities to prevent the normal writeback path from
      ever approaching it).
      
      That's an increasingly fragile assumption, and ramdisk_writepage (the other
      source of AOP_WRITEPAGE_ACTIVATEs) is already careful to check
      wbc->for_reclaim before returning it.  Make the same check in
      shmem_writepage, thereby sidestepping the page_mapped BUG also.
      Signed-off-by: default avatarHugh Dickins <hugh@veritas.com>
      Cc: Erez Zadok <ezk@cs.sunysb.edu>
      Reviewed-by: default avatarPekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      bba9d994
    • David Miller's avatar
      Fix compat futex hangs. · 59ddd460
      David Miller authored
      [FUTEX]: Fix address computation in compat code.
      
      [ Upstream commit: 3c5fd9c7 ]
      
      compat_exit_robust_list() computes a pointer to the
      futex entry in userspace as follows:
      
      	(void __user *)entry + futex_offset
      
      'entry' is a 'struct robust_list __user *', and
      'futex_offset' is a 'compat_long_t' (typically a 's32').
      
      Things explode if the 32-bit sign bit is set in futex_offset.
      
      Type promotion sign extends futex_offset to a 64-bit value before
      adding it to 'entry'.
      
      This triggered a problem on sparc64 running 32-bit applications which
      would lock up a cpu looping forever in the fault handling for the
      userspace load in handle_futex_death().
      
      Compat userspace runs with address masking (wherein the cpu zeros out
      the top 32-bits of every effective address given to a memory operation
      instruction) so the sparc64 fault handler accounts for this by
      zero'ing out the top 32-bits of the fault address too.
      
      Since the kernel properly uses the compat_uptr interfaces, kernel side
      accesses to compat userspace work too since they will only use
      addresses with the top 32-bit clear.
      
      Because of this compat futex layer bug we get into the following loop
      when executing the get_user() load near the top of handle_futex_death():
      
      1) load from address '0xfffffffff7f16bd8', FAULT
      2) fault handler clears upper 32-bits, processes fault
         for address '0xf7f16bd8' which succeeds
      3) goto #1
      
      I want to thank Bernd Zeimetz, Josip Rodin, and Fabio Massimo Di Nitto
      for their tireless efforts helping me track down this bug.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      59ddd460
    • Frans Pop's avatar
      sched: keep utime/stime monotonic · e823c33c
      Frans Pop authored
      sched: keep utime/stime monotonic
      
      cpustats use utime/stime as a ratio against sum_exec_runtime, as a
      consequence it can happen - when the ratio changes faster than time
      accumulates - that either can be appear to go backwards.
      
      Combined backport for 2.6.23 of the following patches from mainline:
      commit 73a2bcb0
      Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
        sched: keep utime/stime monotonic
      
      commit 9301899b
      Author: Balbir Singh <balbir@linux.vnet.ibm.com>
        sched: fix /proc/<PID>/stat stime/utime monotonicity, part 2
      Signed-off-by: default avatarFrans Pop <elendil@planet.nl>
      CC: Peter Zijlstra <a.p.zijlstra@chello.nl>
      CC: Balbir Singh <balbir@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e823c33c
    • Ingo Molnar's avatar
      fix the softlockup watchdog to actually work · 436e61d9
      Ingo Molnar authored
      patch a115d5ca in mainline.
      
      this Xen related commit:
      
         commit 966812dc
         Author: Jeremy Fitzhardinge <jeremy@goop.org>
         Date:   Tue May 8 00:28:02 2007 -0700
      
             Ignore stolen time in the softlockup watchdog
      
      broke the softlockup watchdog to never report any lockups. (!)
      
      print_timestamp defaults to 0, this makes the following condition
      always true:
      
      	if (print_timestamp < (touch_timestamp + 1) ||
      
      and we'll in essence never report soft lockups.
      
      apparently the functionality of the soft lockup watchdog was never
      actually tested with that patch applied ...
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      436e61d9
    • Jens Axboe's avatar
      splice: fix double kunmap() in vmsplice copy path · 4d03fda8
      Jens Axboe authored
      patch 6866bef4 in mainline.
      
      The out label should not include the unmap, the only way to jump
      there already has unmapped the source.
      
      00002000
             f7c21a00 00000000 00000000 c0489036 00018e32 00000002 00000000
      00001000
      Call Trace:
       [<c0487dd9>] pipe_to_user+0xca/0xd3
       [<c0488233>] __splice_from_pipe+0x53/0x1bd
       [<c0454947>] ------------[ cut here ]------------
      filemap_fault+0x221/0x380
       [<c0487d0f>] pipe_to_user+0x0/0xd3
       [<c0489036>] sys_vmsplice+0x3b7/0x422
       [<c045ec3f>] kernel BUG at mm/highmem.c:206!
      handle_mm_fault+0x4d5/0x8eb
       [<c041ed5b>] kmap_atomic+0x1c/0x20
       [<c045d33d>] unmap_vmas+0x3d1/0x584
       [<c045f717>] free_pgtables+0x90/0xa0
       [<c041d84b>] pgd_dtor+0x0/0x1
       [<c044d665>] audit_syscall_exit+0x2aa/0x2c6
       [<c0407817>] do_syscall_trace+0x124/0x169
       [<c0404df2>] syscall_call+0x7/0xb
       =======================
      Code: 2d 00 d0 5b 00 25 00 00 e0 ff 29 invalid opcode: 0000 [#1]
      c2 89 d0 c1 e8 0c 8b 14 85 a0 6c 7c c0 4a 85 d2 89 14 85 a0 6c 7c c0 74 07
      31 c9 4a 75 15 eb 04 <0f> 0b eb fe 31 c9 81 3d 78 38 6d c0 78 38 6d c0 0f
      95 c1 b0 01
      EIP: [<c045bbc3>] kunmap_high+0x51/0x8e SS:ESP 0068:f5960df0
      SMP
      Modules linked in: netconsole autofs4 hidp nfs lockd nfs_acl rfcomm l2cap
      bluetooth sunrpc ipv6 ib_iser rdma_cm ib_cm iw_cmib_sa ib_mad ib_core
      ib_addr iscsi_tcp libiscsi scsi_transport_iscsi dm_mirror dm_multipath
      dm_mod video output sbs batteryac parport_pc lp parport sg i2c_piix4
      i2c_core floppy cfi_probe gen_probe scb2_flash mtd chipreg tg3 e1000 button
      ide_cd serio_raw cdrom aic7xxx scsi_transport_spi sd_mod scsi_mod ext3 jbd
      ehci_hcd ohci_hcd uhci_hcd
      CPU:    3
      EIP:    0060:[<c045bbc3>]    Not tainted VLI
      EFLAGS: 00010246   (2.6.23 #1)
      EIP is at kunmap_high+0x51/0x8e
      Signed-off-by: default avatarJens Axboe <jens.axboe@oracle.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      4d03fda8
    • Andrew Morton's avatar
      writeback: don't propagate AOP_WRITEPAGE_ACTIVATE · 2e25e433
      Andrew Morton authored
      patch e4230030 in mainline.
      
      This is a writeback-internal marker but we're propagating it all the way back
      to userspace!.
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      
      2e25e433
    • Christoph Lameter's avatar
      SLUB: Fix memory leak by not reusing cpu_slab · f8b98ff9
      Christoph Lameter authored
      patch 05aa3450 in mainline.
      
      SLUB: Fix memory leak by not reusing cpu_slab
      
      Fix the memory leak that may occur when we attempt to reuse a cpu_slab
      that was allocated while we reenabled interrupts in order to be able to
      grow a slab cache. The per cpu freelist may contain objects and in that
      situation we may overwrite the per cpu freelist pointer loosing objects.
      This only occurs if we find that the concurrently allocated slab fits
      our allocation needs.
      
      If we simply always deactivate the slab then the freelist will be properly
      reintegrated and the memory leak will go away.
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Cc: Hugh Dickins <hugh@veritas.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f8b98ff9
    • Tsugikazu Shibata's avatar
      HOWTO: update ja_JP/HOWTO with latest changes · 0ebc8ca8
      Tsugikazu Shibata authored
      patch 3b6662f1 upstream.
      
      Here is another sync patch of Documentation/ja_JP/HOWTO
      
      Japanese developer sent me some cosmetic changes and also follow
      changes of HOWTO
          Cross reference URL (sosdg.org/qiyong/lxr)
          known_regression explanations on kernel dev. process
      Signed-off-by: default avatarTsugikazu Shibata <tshibata@ab.jp.nec.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0ebc8ca8
    • Jan Kiszka's avatar
      fix param_sysfs_builtin name length check · e8af293b
      Jan Kiszka authored
      patch 22800a28 in mainline.
      
      Commit faf8c714 caused a regression:
      parameter names longer than MAX_KBUILD_MODNAME will now be rejected,
      although we just need to keep the module name part that short.  This patch
      restores the old behaviour while still avoiding that memchr is called with
      its length parameter larger than the total string length.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@web.de>
      Cc: Dave Young <hidave.darkstar@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e8af293b
    • Dave Young's avatar
      param_sysfs_builtin memchr argument fix · 2b5ee286
      Dave Young authored
      patch faf8c714 in mainline.
      
      If memchr argument is longer than strlen(kp->name), there will be some
      weird result.
      
      It will casuse duplicate filenames in sysfs for the "nousb".  kernel
      warning messages are as bellow:
      
      sysfs: duplicate filename 'usbcore' can not be created
      WARNING: at fs/sysfs/dir.c:416 sysfs_add_one()
       [<c01c4750>] sysfs_add_one+0xa0/0xe0
       [<c01c4ab8>] create_dir+0x48/0xb0
       [<c01c4b69>] sysfs_create_dir+0x29/0x50
       [<c024e0fb>] create_dir+0x1b/0x50
       [<c024e3b6>] kobject_add+0x46/0x150
       [<c024e2da>] kobject_init+0x3a/0x80
       [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
       [<c053b9ce>] param_sysfs_builtin+0xee/0x130
       [<c053ba33>] param_sysfs_init+0x23/0x60
       [<c024d062>] __next_cpu+0x12/0x20
       [<c052aa30>] kernel_init+0x0/0xb0
       [<c052aa30>] kernel_init+0x0/0xb0
       [<c052a856>] do_initcalls+0x46/0x1e0
       [<c01bdb12>] create_proc_entry+0x52/0x90
       [<c0158d4c>] register_irq_proc+0x9c/0xc0
       [<c01bda94>] proc_mkdir_mode+0x34/0x50
       [<c052aa30>] kernel_init+0x0/0xb0
       [<c052aa92>] kernel_init+0x62/0xb0
       [<c0104f83>] kernel_thread_helper+0x7/0x14
       =======================
      kobject_add failed for usbcore with -EEXIST, don't try to register things with the same name in the same directory.
       [<c024e466>] kobject_add+0xf6/0x150
       [<c053b880>] kernel_param_sysfs_setup+0x50/0xb0
       [<c053b9ce>] param_sysfs_builtin+0xee/0x130
       [<c053ba33>] param_sysfs_init+0x23/0x60
       [<c024d062>] __next_cpu+0x12/0x20
       [<c052aa30>] kernel_init+0x0/0xb0
       [<c052aa30>] kernel_init+0x0/0xb0
       [<c052a856>] do_initcalls+0x46/0x1e0
       [<c01bdb12>] create_proc_entry+0x52/0x90
       [<c0158d4c>] register_irq_proc+0x9c/0xc0
       [<c01bda94>] proc_mkdir_mode+0x34/0x50
       [<c052aa30>] kernel_init+0x0/0xb0
       [<c052aa92>] kernel_init+0x62/0xb0
       [<c0104f83>] kernel_thread_helper+0x7/0x14
       =======================
      Module 'usbcore' failed to be added to sysfs, error number -17
      The system will be unstable now.
      Signed-off-by: default avatarDave Young <hidave.darkstar@gmail.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      2b5ee286
    • Linus Torvalds's avatar
      Remove broken ptrace() special-case code from file mapping · aead196b
      Linus Torvalds authored
      The kernel has for random historical reasons allowed ptrace() accesses
      to access (and insert) pages into the page cache above the size of the
      file.
      
      However, Nick broke that by mistake when doing the new fault handling in
      commit 54cb8821 ("mm: merge populate and
      nopage into fault (fixes nonlinear)".  The breakage caused a hang with
      gdb when trying to access the invalid page.
      
      The ptrace "feature" really isn't worth resurrecting, since it really is
      wrong both from a portability _and_ from an internal page cache validity
      standpoint.  So this removes those old broken remnants, and fixes the
      ptrace() hang in the process.
      
      Noticed and bisected by Duane Griffin, who also supplied a test-case
      (quoth Nick: "Well that's probably the best bug report I've ever had,
      thanks Duane!").
      
      Cc: Duane Griffin <duaneg@dghda.com>
      Acked-by: default avatarNick Piggin <npiggin@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      aead196b
    • J. Bruce Fields's avatar
      locks: fix possible infinite loop in posix deadlock detection · f153577e
      J. Bruce Fields authored
      patch 97855b49 in mainline.
      
      It's currently possible to send posix_locks_deadlock() into an infinite
      loop (under the BKL).
      
      For now, fix this just by bailing out after a few iterations.  We may
      want to fix this in a way that better clarifies the semantics of
      deadlock detection.  But that will take more time, and this minimal fix
      is probably adequate for any realistic scenario, and is simple enough to
      be appropriate for applying to stable kernels now.
      
      Thanks to George Davis for reporting the problem.
      
      Cc: "George G. Davis" <gdavis@mvista.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@citi.umich.edu>
      Acked-by: default avatarAlan Cox <alan@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f153577e
    • Gregory Haskins's avatar
      lockdep: fix mismatched lockdep_depth/curr_chain_hash · e354b801
      Gregory Haskins authored
      patch 3aa416b0 in mainline.
      
      
       It is possible for the current->curr_chain_key to become inconsistent with the
       current index if the chain fails to validate.  The end result is that future
       lock_acquire() operations may inadvertently fail to find a hit in the cache
       resulting in a new node being added to the graph for every acquire.
      Signed-off-by: default avatarGregory Haskins <ghaskins@novell.com>
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: Chuck Ebbert <cebbert@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      e354b801
  2. 12 Oct, 2007 2 commits
  3. 09 Oct, 2007 7 commits
  4. 08 Oct, 2007 11 commits
    • Maarten Bressers's avatar
      Correct Makefile rule for generating custom keymap · e2a57a81
      Maarten Bressers authored
      When building a custom keymap, after setting GENERATE_KEYMAP := 1 in
      drivers/char/Makefile, the kernel build fails like this:
      
          CC      drivers/char/vt.o
        make[2]: *** No rule to make target `drivers/char/%.map', needed by `drivers/char/defkeymap.c'.  Stop.
        make[1]: *** [drivers/char] Error 2
        make: *** [drivers] Error 2
      
      This was caused by commit af8b1287, which
      deleted a necessary colon from the Makefile rule that generates the keymap,
      since that rule contains both a target and a target-pattern.  The following
      patch puts the colon back:
      Signed-off-by: default avatarMaarten Bressers <mbres@gentoo.org>
      Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      e2a57a81
    • Karsten Keil's avatar
      ISDN: Fix data access out of array bounds · d39d5ed9
      Karsten Keil authored
      Fix against access random data bytes outside the dev->chanmap array.
      Thanks to Oliver Neukum for pointing me to this issue.
      Signed-off-by: default avatarKarsten Keil <kkeil@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d39d5ed9
    • Linus Torvalds's avatar
      Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6 · e46dc1da
      Linus Torvalds authored
      * 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
        [IPv6]: Fix ICMPv6 redirect handling with target multicast address
        [PKT_SCHED] cls_u32: error code isn't been propogated properly
        [ROSE]: Fix rose.ko oops on unload
        [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed
      e46dc1da
    • Yan Zheng's avatar
      AIO: fix cleanup in io_submit_one(...) · 87e2831c
      Yan Zheng authored
      When IOCB_FLAG_RESFD flag is set and iocb->aio_resfd is incorrect,
      statement 'goto out_put_req' is executed. At label 'out_put_req',
      aio_put_req(..) is called, which requires 'req->ki_filp' set.
      
      Signed-off-by: Yan Zheng<yanzheng@21cn.com>
      Cc: Zach Brown <zach.brown@oracle.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      87e2831c
    • Yan Zheng's avatar
      fix page release issue in filemap_fault · 745ad48e
      Yan Zheng authored
      find_lock_page increases page's usage count, we should decrease it
      before return VM_FAULT_SIGBUS
      
      Signed-off-by: Yan Zheng<yanzheng@21cn.com>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      745ad48e
    • Yan Zheng's avatar
      fix VM_CAN_NONLINEAR check in sys_remap_file_pages · dd204d63
      Yan Zheng authored
      The test for VM_CAN_NONLINEAR always fails
      
      Signed-off-by: Yan Zheng<yanzheng@21cn.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dd204d63
    • Peter Zijlstra's avatar
      mm: set_page_dirty_balance() vs ->page_mkwrite() · a200ee18
      Peter Zijlstra authored
      All the current page_mkwrite() implementations also set the page dirty. Which
      results in the set_page_dirty_balance() call to _not_ call balance, because the
      page is already found dirty.
      
      This allows us to dirty a _lot_ of pages without ever hitting
      balance_dirty_pages().  Not good (tm).
      
      Force a balance call if ->page_mkwrite() was successful.
      Signed-off-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      a200ee18
    • Brian Haley's avatar
      [IPv6]: Fix ICMPv6 redirect handling with target multicast address · bf0b48df
      Brian Haley authored
      When the ICMPv6 Target address is multicast, Linux processes the 
      redirect instead of dropping it.  The problem is in this code in 
      ndisc_redirect_rcv():
      
               if (ipv6_addr_equal(dest, target)) {
                       on_link = 1;
               } else if (!(ipv6_addr_type(target) & IPV6_ADDR_LINKLOCAL)) {
                       ND_PRINTK2(KERN_WARNING
                                  "ICMPv6 Redirect: target address is not 
      link-local.\n");
                       return;
               }
      
      This second check will succeed if the Target address is, for example, 
      FF02::1 because it has link-local scope.  Instead, it should be checking 
      if it's a unicast link-local address, as stated in RFC 2461/4861 Section 
      8.1:
      
             - The ICMP Target Address is either a link-local address (when
               redirected to a router) or the same as the ICMP Destination
               Address (when redirected to the on-link destination).
      
      I know this doesn't explicitly say unicast link-local address, but it's 
      implied.
      
      This bug is preventing Linux kernels from achieving IPv6 Logo Phase II 
      certification because of a recent error that was found in the TAHI test 
      suite - Neighbor Disovery suite test 206 (v6LC.2.3.6_G) had the 
      multicast address in the Destination field instead of Target field, so 
      we were passing the test.  This won't be the case anymore.
      
      The patch below fixes this problem, and also fixes ndisc_send_redirect() 
      to not send an invalid redirect with a multicast address in the Target 
      field.  I re-ran the TAHI Neighbor Discovery section to make sure Linux 
      passes all 245 tests now.
      Signed-off-by: default avatarBrian Haley <brian.haley@hp.com>
      Acked-by: default avatarDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bf0b48df
    • Stephen Hemminger's avatar
    • Alexey Dobriyan's avatar
      [ROSE]: Fix rose.ko oops on unload · 891e6a93
      Alexey Dobriyan authored
      Commit a3d38402 aka
      "[AX.25]: Fix unchecked rose_add_loopback_neigh uses"
      transformed rose_loopback_neigh var into statically allocated one.
      However, on unload it will be kfree's which can't work.
      
      Steps to reproduce:
      
      	modprobe rose
      	rmmod rose
      
      BUG: unable to handle kernel NULL pointer dereference at virtual address 00000008
       printing eip:
      c014c664
      *pde = 00000000
      Oops: 0000 [#1]
      PREEMPT DEBUG_PAGEALLOC
      Modules linked in: rose ax25 fan ufs loop usbhid rtc snd_intel8x0 snd_ac97_codec ehci_hcd ac97_bus uhci_hcd thermal usbcore button processor evdev sr_mod cdrom
      CPU:    0
      EIP:    0060:[<c014c664>]    Not tainted VLI
      EFLAGS: 00210086   (2.6.23-rc9 #3)
      EIP is at kfree+0x48/0xa1
      eax: 00000556   ebx: c1734aa0   ecx: f6a5e000   edx: f7082000
      esi: 00000000   edi: f9a55d20   ebp: 00200287   esp: f6a5ef28
      ds: 007b   es: 007b   fs: 0000  gs: 0033  ss: 0068
      Process rmmod (pid: 1823, ti=f6a5e000 task=f7082000 task.ti=f6a5e000)
      Stack: f9a55d20 f9a5200c 00000000 00000000 00000000 f6a5e000 f9a5200c f9a55a00 
             00000000 bf818cf0 f9a51f3f f9a55a00 00000000 c0132c60 65736f72 00000000 
             f69f9630 f69f9528 c014244a f6a4e900 00200246 f7082000 c01025e6 00000000 
      Call Trace:
       [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose]
       [<f9a5200c>] rose_rt_free+0x1d/0x49 [rose]
       [<f9a51f3f>] rose_exit+0x4c/0xd5 [rose]
       [<c0132c60>] sys_delete_module+0x15e/0x186
       [<c014244a>] remove_vma+0x40/0x45
       [<c01025e6>] sysenter_past_esp+0x8f/0x99
       [<c012bacf>] trace_hardirqs_on+0x118/0x13b
       [<c01025b6>] sysenter_past_esp+0x5f/0x99
       =======================
      Code: 05 03 1d 80 db 5b c0 8b 03 25 00 40 02 00 3d 00 40 02 00 75 03 8b 5b 0c 8b 73 10 8b 44 24 18 89 44 24 04 9c 5d fa e8 77 df fd ff <8b> 56 08 89 f8 e8 84 f4 fd ff e8 bd 32 06 00 3b 5c 86 60 75 0f 
      EIP: [<c014c664>] kfree+0x48/0xa1 SS:ESP 0068:f6a5ef28
      Signed-off-by: default avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      891e6a93
    • Ilpo Järvinen's avatar
      [TCP]: Fix fastpath_cnt_hint when GSO skb is partially ACKed · 48611c47
      Ilpo Järvinen authored
      When only GSO skb was partially ACKed, no hints are reset,
      therefore fastpath_cnt_hint must be tweaked too or else it can
      corrupt fackets_out. The corruption to occur, one must have
      non-trivial ACK/SACK sequence, so this bug is not very often
      that harmful. There's a fackets_out state reset in TCP because
      fackets_out is known to be inaccurate and that fixes the issue
      eventually anyway.
      
      In case there was also at least one skb that got fully ACKed,
      the fastpath_skb_hint is set to NULL which causes a recount for
      fastpath_cnt_hint (the old value won't be accessed anymore),
      thus it can safely be decremented without additional checking.
      
      Reported by Cedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarIlpo Järvinen <ilpo.jarvinen@helsinki.fi>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      48611c47
  5. 07 Oct, 2007 1 commit