1. 06 Aug, 2006 13 commits
    • Antonino A. Daplas's avatar
      [PATCH] vt: printk: Fix framebuffer console triggering might_sleep assertion · 78944e54
      Antonino A. Daplas authored
      Reported by: Dave Jones
      
      Whilst printk'ing to both console and serial console, I got this...
      (2.6.18rc1)
      
      BUG: sleeping function called from invalid context at kernel/sched.c:4438
      in_atomic():0, irqs_disabled():1
      
      Call Trace:
       [<ffffffff80271db8>] show_trace+0xaa/0x23d
       [<ffffffff80271f60>] dump_stack+0x15/0x17
       [<ffffffff8020b9f8>] __might_sleep+0xb2/0xb4
       [<ffffffff8029232e>] __cond_resched+0x15/0x55
       [<ffffffff80267eb8>] cond_resched+0x3b/0x42
       [<ffffffff80268c64>] console_conditional_schedule+0x12/0x14
       [<ffffffff80368159>] fbcon_redraw+0xf6/0x160
       [<ffffffff80369c58>] fbcon_scroll+0x5d9/0xb52
       [<ffffffff803a43c4>] scrup+0x6b/0xd6
       [<ffffffff803a4453>] lf+0x24/0x44
       [<ffffffff803a7ff8>] vt_console_print+0x166/0x23d
       [<ffffffff80295528>] __call_console_drivers+0x65/0x76
       [<ffffffff80295597>] _call_console_drivers+0x5e/0x62
       [<ffffffff80217e3f>] release_console_sem+0x14b/0x232
       [<ffffffff8036acd6>] fb_flashcursor+0x279/0x2a6
       [<ffffffff80251e3f>] run_workqueue+0xa8/0xfb
       [<ffffffff8024e5e0>] worker_thread+0xef/0x122
       [<ffffffff8023660f>] kthread+0x100/0x136
       [<ffffffff8026419e>] child_rip+0x8/0x12
      
      This can occur when release_console_sem() is called but the log
      buffer still has contents that need to be flushed. The console drivers
      are called while the console_may_schedule flag is still true. The
      might_sleep() is triggered when fbcon calls console_conditional_schedule().
      
      Fix by setting console_may_schedule to zero earlier, before the call to the
      console drivers.
      Signed-off-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      78944e54
    • Jan Blunck's avatar
      [PATCH] fix vmstat per cpu usage · 38cbcdc0
      Jan Blunck authored
      The per cpu variables are used incorrectly in vmstat.h.
      Signed-off-by: default avatarJan Blunck <jblunck@suse.de>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Acked-by: default avatarSteve Fox <drfickle@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      38cbcdc0
    • Chuck Ebbert's avatar
      [PATCH] ptrace: make pid of child process available for PTRACE_EVENT_VFORK_DONE · 9f59ce5d
      Chuck Ebbert authored
      When delivering PTRACE_EVENT_VFORK_DONE, provide pid of the child process
      when tracer calls ptrace(PTRACE_GETEVENTMSG).  This is already
      (accidentally) available when the tracer is tracing VFORK in addition to
      VFORK_DONE.
      Signed-off-by: default avatarChuck Ebbert <76306.1226@compuserve.com>
      Cc: Daniel Jacobowitz <dan@debian.org>
      Cc: Albert Cahalan <acahalan@gmail.com>
      Cc: Roland McGrath <roland@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      9f59ce5d
    • NeilBrown's avatar
      [PATCH] md: Fix a bug that recently crept into md/linear · f9abd1ac
      NeilBrown authored
      A recent patch that allowed linear arrays to be reconfigured on-line
      allowed in a bug which results in divide by zero - not all
      mddev->array_size were converted to conf->array_size.
      
      This patch finished the conversion and fixed the bug.
      
      The offending patch was commit 7c7546cc.
      
      Thanks to Simon Kirby <sim@netnation.com> for the bug report.
      
      Cc: Simon Kirby <sim@netnation.com>
      Signed-off-by: default avatarNeil Brown <neilb@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f9abd1ac
    • David Brownell's avatar
      [PATCH] omap-rng build fix · af2bc7d2
      David Brownell authored
      Seems like the omap-rng driver in the main tree predates the switch from
      <asm/hardware/clock.h> to <linux/clk.h> ...  now it builds OK.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      af2bc7d2
    • Alexander Zarochentsev's avatar
      [PATCH] i_mutex does not need to be locked in reiserfs_delete_inode() · b0b33dee
      Alexander Zarochentsev authored
      Fixes an i_mutex-inside-i_mutex lockdep nasty.
      Signed-off-by: default avatarAlexander Zarochentsev <zam@namesys.com>
      Cc: <reiserfs-dev@namesys.com>
      Cc: Hans Reiser <reiser@namesys.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      b0b33dee
    • Olaf Hering's avatar
      [PATCH] crash in aty128_set_lcd_enable() on PowerBook · c3760ae1
      Olaf Hering authored
      Current Linus tree crashes in aty128_set_lcd_enable() because par->pdev
      is NULL. This happens since at least a week. Call trace is:
      
      aty128_set_lcd_enable
      aty128fb_set_par
      fbcon_init
      visual_init
      take_over_console
      fbcon_takeover
      notifier_call_chain
      blocking_notifier_call_chain
      register_framebuffer
      aty128fb_probe
      pci_device_probe
      bus_for_each_dev
      driver_attach
      bus_add_driver
      driver_register
      __pci_register_driver
      aty128fb_init
      init
      kernel_thread
      
      - info->fix was assigned twice.
      
      - par->vram_size is assigned in aty128_probe(), no need to redo it again
        in aty128_init()
      
      - register_framebuffer() uses uninitialized struct members, move it past
        par->pdev assignment and past aty128_bl_init().
      Signed-off-by: default avatarOlaf Hering <olh@suse.de>
      Acked-by: default avatarAntonino Daplas <adaplas@pol.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c3760ae1
    • Evgeniy Dushistov's avatar
      [PATCH] ufs: handle truncated pages · 06fa45d3
      Evgeniy Dushistov authored
      ufs_get_locked_page is called twice in ufs code, one time in ufs_truncate
      path(we allocated last block), and another time when fragments are
      reallocated.  In ideal world in the second case on allocation/free block
      layer we should not know that things like `truncate' exists, but now with
      such crutch like ufs_get_locked_page we can (or should?) skip truncated
      pages.
      Signed-off-by: default avatarEvgeniy Dushistov <dushistov@mail.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      06fa45d3
    • Evgeniy Dushistov's avatar
      [PATCH] ufs: ufs_get_locked_page() race fix · 1fb32b7b
      Evgeniy Dushistov authored
      As discussed earlier:
      http://lkml.org/lkml/2006/6/28/136
      this patch fixes such issue:
      
      `ufs_get_locked_page' takes page from cache
      after that `vmtruncate' takes page and deletes it from cache
      `ufs_get_locked_page' locks page, and reports about EIO error.
      
      Also because of find_lock_page always return valid page or NULL, we have no
      need to check it if page not NULL.
      Signed-off-by: default avatarEvgeniy Dushistov <dushistov@mail.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      1fb32b7b
    • Christian Borntraeger's avatar
      [PATCH] bug in futex unqueue_me · e91467ec
      Christian Borntraeger authored
      This patch adds a barrier() in futex unqueue_me to avoid aliasing of two
      pointers.
      
      On my s390x system I saw the following oops:
      
      Unable to handle kernel pointer dereference at virtual kernel address
      0000000000000000
      Oops: 0004 [#1]
      CPU:    0    Not tainted
      Process mytool (pid: 13613, task: 000000003ecb6ac0, ksp: 00000000366bdbd8)
      Krnl PSW : 0704d00180000000 00000000003c9ac2 (_spin_lock+0xe/0x30)
      Krnl GPRS: 00000000ffffffff 000000003ecb6ac0 0000000000000000 0700000000000000
                 0000000000000000 0000000000000000 000001fe00002028 00000000000c091f
                 000001fe00002054 000001fe00002054 0000000000000000 00000000366bddc0
                 00000000005ef8c0 00000000003d00e8 0000000000144f91 00000000366bdcb8
      Krnl Code: ba 4e 20 00 12 44 b9 16 00 3e a7 84 00 08 e3 e0 f0 88 00 04
      Call Trace:
      ([<0000000000144f90>] unqueue_me+0x40/0xe4)
       [<0000000000145a0c>] do_futex+0x33c/0xc40
       [<000000000014643e>] sys_futex+0x12e/0x144
       [<000000000010bb00>] sysc_noemu+0x10/0x16
       [<000002000003741c>] 0x2000003741c
      
      The code in question is:
      
      static int unqueue_me(struct futex_q *q)
      {
              int ret = 0;
              spinlock_t *lock_ptr;
      
              /* In the common case we don't take the spinlock, which is nice. */
       retry:
              lock_ptr = q->lock_ptr;
              if (lock_ptr != 0) {
                      spin_lock(lock_ptr);
      		/*
                       * q->lock_ptr can change between reading it and
                       * spin_lock(), causing us to take the wrong lock.  This
                       * corrects the race condition.
      [...]
      
      and my compiler (gcc 4.1.0) makes the following out of it:
      
      00000000000003c8 <unqueue_me>:
           3c8:       eb bf f0 70 00 24       stmg    %r11,%r15,112(%r15)
           3ce:       c0 d0 00 00 00 00       larl    %r13,3ce <unqueue_me+0x6>
                              3d0: R_390_PC32DBL      .rodata+0x2a
           3d4:       a7 f1 1e 00             tml     %r15,7680
           3d8:       a7 84 00 01             je      3da <unqueue_me+0x12>
           3dc:       b9 04 00 ef             lgr     %r14,%r15
           3e0:       a7 fb ff d0             aghi    %r15,-48
           3e4:       b9 04 00 b2             lgr     %r11,%r2
           3e8:       e3 e0 f0 98 00 24       stg     %r14,152(%r15)
           3ee:       e3 c0 b0 28 00 04       lg      %r12,40(%r11)
      		/* write q->lock_ptr in r12 */
           3f4:       b9 02 00 cc             ltgr    %r12,%r12
           3f8:       a7 84 00 4b             je      48e <unqueue_me+0xc6>
      		/* if r12 is zero then jump over the code.... */
           3fc:       e3 20 b0 28 00 04       lg      %r2,40(%r11)
      		/* write q->lock_ptr in r2 */
           402:       c0 e5 00 00 00 00       brasl   %r14,402 <unqueue_me+0x3a>
                              404: R_390_PC32DBL      _spin_lock+0x2
      		/* use r2 as parameter for spin_lock */
      
      So the code becomes more or less:
      if (q->lock_ptr != 0) spin_lock(q->lock_ptr)
      instead of
      if (lock_ptr != 0) spin_lock(lock_ptr)
      
      Which caused the oops from above.
      After adding a barrier gcc creates code without this problem:
      [...] (the same)
           3ee:       e3 c0 b0 28 00 04       lg      %r12,40(%r11)
           3f4:       b9 02 00 cc             ltgr    %r12,%r12
           3f8:       b9 04 00 2c             lgr     %r2,%r12
           3fc:       a7 84 00 48             je      48c <unqueue_me+0xc4>
           400:       c0 e5 00 00 00 00       brasl   %r14,400 <unqueue_me+0x38>
                              402: R_390_PC32DBL      _spin_lock+0x2
      
      As a general note, this code of unqueue_me seems a bit fishy. The retry logic
      of unqueue_me only works if we can guarantee, that the original value of
      q->lock_ptr is always a spinlock (Otherwise we overwrite kernel memory). We
      know that q->lock_ptr can change. I dont know what happens with the original
      spinlock, as I am not an expert with the futex code.
      
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarIngo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@timesys.com>
      Signed-off-by: default avatarChristian Borntraeger <borntrae@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      e91467ec
    • Andrew Morton's avatar
      [PATCH] disable debugging version of write_lock() · 72f0b4e2
      Andrew Morton authored
      We've confirmed that the debug version of write_lock() can get stuck for long
      enough to cause NMI watchdog timeouts and hence a crash.
      
      We don't know why, yet.   Disable it for now.
      
      Also disable the similar read_lock() code.  Just in case.
      
      Thanks to Dave Olson <olson@unixfolk.com> for reporting and testing.
      Acked-by: default avatarIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      72f0b4e2
    • Adrian Bunk's avatar
      [PATCH] drivers/edac/edac_mc.h must #include <linux/platform_device.h> · 927cbe8a
      Adrian Bunk authored
      With CONFIG_PCI=n:
      
        CC      drivers/edac/edac_mc.o
      drivers/edac/edac_mc.c: In function ‘add_mc_to_global_list’:
      drivers/edac/edac_mc.c:1362: error: implicit declaration of function ‘to_platform_device’
      drivers/edac/edac_mc.c:1362: error: invalid type argument of ‘->’
      drivers/edac/edac_mc.c: In function ‘edac_mc_add_mc’:
      drivers/edac/edac_mc.c:1467: error: invalid type argument of ‘->’
      drivers/edac/edac_mc.c: In function ‘edac_mc_del_mc’:
      drivers/edac/edac_mc.c:1504: error: invalid type argument of ‘->’
      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>
      927cbe8a
    • Rafael J. Wysocki's avatar
      [PATCH] Make suspend possible with a traced process at a breakpoint · a7ef7878
      Rafael J. Wysocki authored
      It should be possible to suspend, either to RAM or to disk, if there's a
      traced process that has just reached a breakpoint.  However, this is a
      special case, because its parent process might have been frozen already and
      then we are unable to deliver the "freeze" signal to the traced process.
      If this happens, it's better to cancel the freezing of the traced process.
      
      Ref. http://bugzilla.kernel.org/show_bug.cgi?id=6787Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a7ef7878
  2. 04 Aug, 2006 7 commits
  3. 03 Aug, 2006 20 commits