1. 06 8月, 2006 14 次提交
    • R
      [PATCH] au1100fb: info->var.rotate fix · fd2d5430
      Rodolfo Giometti 提交于
      Fix "info->var.rotate" data settings.
      
      This info should be deduced directly from "fbdev->panel->control_base"
      defined into au1100fb.h.
      Signed-off-by: NRodolfo Giometti <giometti@linux.it>
      Signed-off-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fd2d5430
    • A
      [PATCH] vt: printk: Fix framebuffer console triggering might_sleep assertion · 78944e54
      Antonino A. Daplas 提交于
      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: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      78944e54
    • J
      [PATCH] fix vmstat per cpu usage · 38cbcdc0
      Jan Blunck 提交于
      The per cpu variables are used incorrectly in vmstat.h.
      Signed-off-by: NJan Blunck <jblunck@suse.de>
      Cc: Christoph Lameter <clameter@engr.sgi.com>
      Acked-by: NSteve Fox <drfickle@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      38cbcdc0
    • C
      [PATCH] ptrace: make pid of child process available for PTRACE_EVENT_VFORK_DONE · 9f59ce5d
      Chuck Ebbert 提交于
      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: NChuck 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      9f59ce5d
    • N
      [PATCH] md: Fix a bug that recently crept into md/linear · f9abd1ac
      NeilBrown 提交于
      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: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f9abd1ac
    • D
      [PATCH] omap-rng build fix · af2bc7d2
      David Brownell 提交于
      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: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      af2bc7d2
    • A
      [PATCH] i_mutex does not need to be locked in reiserfs_delete_inode() · b0b33dee
      Alexander Zarochentsev 提交于
      Fixes an i_mutex-inside-i_mutex lockdep nasty.
      Signed-off-by: NAlexander Zarochentsev <zam@namesys.com>
      Cc: <reiserfs-dev@namesys.com>
      Cc: Hans Reiser <reiser@namesys.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b0b33dee
    • O
      [PATCH] crash in aty128_set_lcd_enable() on PowerBook · c3760ae1
      Olaf Hering 提交于
      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: NOlaf Hering <olh@suse.de>
      Acked-by: NAntonino Daplas <adaplas@pol.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c3760ae1
    • E
      [PATCH] ufs: handle truncated pages · 06fa45d3
      Evgeniy Dushistov 提交于
      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: NEvgeniy Dushistov <dushistov@mail.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      06fa45d3
    • E
      [PATCH] ufs: ufs_get_locked_page() race fix · 1fb32b7b
      Evgeniy Dushistov 提交于
      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: NEvgeniy Dushistov <dushistov@mail.ru>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      1fb32b7b
    • C
      [PATCH] bug in futex unqueue_me · e91467ec
      Christian Borntraeger 提交于
      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: NIngo Molnar <mingo@redhat.com>
      Cc: Thomas Gleixner <tglx@timesys.com>
      Signed-off-by: NChristian Borntraeger <borntrae@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e91467ec
    • A
      [PATCH] disable debugging version of write_lock() · 72f0b4e2
      Andrew Morton 提交于
      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: NIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      72f0b4e2
    • A
      [PATCH] drivers/edac/edac_mc.h must #include <linux/platform_device.h> · 927cbe8a
      Adrian Bunk 提交于
      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: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      927cbe8a
    • R
      [PATCH] Make suspend possible with a traced process at a breakpoint · a7ef7878
      Rafael J. Wysocki 提交于
      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: NRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: NPavel Machek <pavel@ucw.cz>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a7ef7878
  2. 05 8月, 2006 4 次提交
  3. 04 8月, 2006 22 次提交