1. 08 7月, 2008 7 次提交
    • C
      x86, SGI UV: TLB shootdown using broadcast assist unit, v6 · cef53278
      Cliff Wickman 提交于
      v6: 6/19 close the security hole in uv_ptc_proc_write())
      
        > Found a potential security hole while doing that:
        > static ssize_t uv_ptc_proc_write(struct file *file, const char __user *user,
        >                              size_t count, loff_t *data)
        >     if (copy_from_user(optstr, user, count))
        >             return -EFAULT;
        >
        > is count guaranteed to never be larger than 64?
      
      is fixed below.
      
      It adds tlb_uv.o to the Makefile.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Cc: mingo@elte.hu
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      cef53278
    • J
      x86: fix stack overflow for large values of MAX_APICS · b6df1b8b
      Jack Steiner 提交于
      physid_mask_of_physid() causes a huge stack (12k) to be created if the
      number of APICS is large. Replace physid_mask_of_physid() with a
      new function that does not create large stacks. This is a problem only
      on large x86_64 systems.
      
      this paves the way to increase MAX_APICS.
      Signed-off-by: NJack Steiner <steiner@sgi.com>
      Cc: linux-mm@kvack.org
      Cc: mingo@elte.hu
      Cc: tglx@linutronix.de
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b6df1b8b
    • I
      SGI UV: TLB shootdown using broadcast assist unit, fix · d400524a
      Ingo Molnar 提交于
      fix:
      
      arch/x86/kernel/tlb_uv.c: In function ‘uv_table_bases_init':
      arch/x86/kernel/tlb_uv.c:612: error: ‘bau_tabsp' undeclared (first use in this function)
      arch/x86/kernel/tlb_uv.c:612: error: (Each undeclared identifier is reported only once
      arch/x86/kernel/tlb_uv.c:612: error: for each function it appears in.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d400524a
    • I
      SGI UV: clean up arch/x86/kernel/tlb_uv.c · b4c286e6
      Ingo Molnar 提交于
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b4c286e6
    • I
      SGI UV: TLB shootdown using broadcast assist unit · dc163a41
      Ingo Molnar 提交于
      TLB shootdown for SGI UV.
      
      v5: 6/12 corrections/improvements per Ingo's second review
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      dc163a41
    • C
      SGI UV: TLB shootdown using broadcast assist unit, cleanups · b194b120
      Cliff Wickman 提交于
      TLB shootdown for SGI UV.
      
      v1: 6/2 original
      v2: 6/3 corrections/improvements per Ingo's review
      v3: 6/4 split atomic operations off to a separate patch (Jeremy's review)
      v4: 6/12 include <mach_apic.h> rather than <asm/mach-bigsmp/mach_apic.h>
               (fixes a !SMP build problem that Ingo found)
               fix the index on uv_table_bases[blade]
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      b194b120
    • C
      x86, SGI UV: TLB shootdown using broadcast assist unit · 1812924b
      Cliff Wickman 提交于
      TLB shootdown for SGI UV.
      
      Depends on patch (in tip/x86/irq):
         x86-update-macros-used-by-uv-platform.patch   Jack Steiner May 29
      
      This patch provides the ability to flush TLB's in cpu's that are not on
      the local node.  The hardware mechanism for distributing the flush
      messages is the UV's "broadcast assist unit".
      
      The hook to intercept TLB shootdown requests is a 2-line change to
      native_flush_tlb_others() (arch/x86/kernel/tlb_64.c).
      
      This code has been tested on a hardware simulator. The real hardware
      is not yet available.
      
      The shootdown statistics are provided through /proc/sgi_uv/ptc_statistics.
      The use of /sys was considered, but would have required the use of
      many /sys files.  The debugfs was also considered, but these statistics
      should be available on an ongoing basis, not just for debugging.
      
      Issues to be fixed later:
      - The IRQ for the messaging interrupt is currently hardcoded as 200
        (see UV_BAU_MESSAGE).  It should be dynamically assigned in the future.
      - The use of appropriate udelay()'s is untested, as they are a problem
        in the simulator.
      Signed-off-by: NCliff Wickman <cpw@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      1812924b
  2. 05 7月, 2008 2 次提交
  3. 04 7月, 2008 1 次提交
  4. 03 7月, 2008 2 次提交
    • A
      arch/x86/mm/init_64.c: early_memtest(): fix types · 27df66a4
      Andrew Morton 提交于
      fix this warning:
      
      arch/x86/mm/init_64.c: In function 'early_memtest':
      arch/x86/mm/init_64.c:524: warning: passing argument 2 of 'find_e820_area_size' from incompatible pointer type
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      27df66a4
    • H
      x86: fix Intel Mac booting with EFI · 216705d2
      Hugh Dickins 提交于
      Fedora reports that mem_init()'s zap_low_mappings(), extended to SMP in
      61165d7a x86: fix app crashes after SMP
      resume causes 32-bit Intel Mac machines to reboot very early when
      booting with EFI.
      
      The EFI code appears to manage low mappings for itself when needed; but
      like many before it, confuses PSE with PAE.  So it has only been mapping
      half the space it needed when PSE but not PAE.  This remained unnoticed
      until we moved the SMP zap_low_mappings() before
      efi_enter_virtual_mode().  Presumably could have been noticed years ago
      if anyone ran a UP kernel on such machines?
      Reported-by: NPeter Jones <pjones@redhat.com>
      Signed-off-by: NHugh Dickins <hugh@veritas.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Glauber Costa <gcosta@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Tested-by: NPeter Jones <pjones@redhat.com>
      216705d2
  5. 01 7月, 2008 1 次提交
  6. 30 6月, 2008 2 次提交
    • T
      ptrace GET/SET FPXREGS broken · 11dbc963
      TAKADA Yoshihito 提交于
      When I update kernel 2.6.25 from 2.6.24, gdb does not work.
      On 2.6.25, ptrace(PTRACE_GETFPXREGS, ...) returns ENODEV.
      
      But 2.6.24 kernel's ptrace() returns EIO.
      It is issue of compatibility.
      
      I attached test program as pt.c and patch for fix it.
      
      #include <stdio.h>
      #include <stdlib.h>
      #include <unistd.h>
      #include <signal.h>
      #include <errno.h>
      #include <sys/ptrace.h>
      #include <sys/types.h>
      
      struct user_fxsr_struct {
      	unsigned short	cwd;
      	unsigned short	swd;
      	unsigned short	twd;
      	unsigned short	fop;
      	long	fip;
      	long	fcs;
      	long	foo;
      	long	fos;
      	long	mxcsr;
      	long	reserved;
      	long	st_space[32];	/* 8*16 bytes for each FP-reg = 128 bytes */
      	long	xmm_space[32];	/* 8*16 bytes for each XMM-reg = 128 bytes */
      	long	padding[56];
      };
      
      int main(void)
      {
        pid_t pid;
      
        pid = fork();
      
        switch(pid){
        case -1:/*  error */
          break;
        case 0:/*  child */
          child();
          break;
        default:
          parent(pid);
          break;
        }
        return 0;
      }
      
      int child(void)
      {
        ptrace(PTRACE_TRACEME);
        kill(getpid(), SIGSTOP);
        sleep(10);
        return 0;
      }
      int parent(pid_t pid)
      {
        int ret;
        struct user_fxsr_struct fpxregs;
      
        ret = ptrace(PTRACE_GETFPXREGS, pid, 0, &fpxregs);
        if(ret < 0){
          printf("%d: %s.\n", errno, strerror(errno));
        }
        kill(pid, SIGCONT);
        wait(pid);
        return 0;
      }
      
      /* in the kerel, at kernel/i387.c get_fpxregs() */
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      11dbc963
    • Z
      x86: fix cpu hotplug crash · fcb43042
      Zhang, Yanmin 提交于
      Vegard Nossum reported crashes during cpu hotplug tests:
      
        http://marc.info/?l=linux-kernel&m=121413950227884&w=4
      
      In function _cpu_up, the panic happens when calling
      __raw_notifier_call_chain at the second time. Kernel doesn't panic when
      calling it at the first time. If just say because of nr_cpu_ids, that's
      not right.
      
      By checking the source code, I found that function do_boot_cpu is the culprit.
      Consider below call chain:
       _cpu_up=>__cpu_up=>smp_ops.cpu_up=>native_cpu_up=>do_boot_cpu.
      
      So do_boot_cpu is called in the end. In do_boot_cpu, if
      boot_error==true, cpu_clear(cpu, cpu_possible_map) is executed. So later
      on, when _cpu_up calls __raw_notifier_call_chain at the second time to
      report CPU_UP_CANCELED, because this cpu is already cleared from
      cpu_possible_map, get_cpu_sysdev returns NULL.
      
      Many resources are related to cpu_possible_map, so it's better not to
      change it.
      
      Below patch against 2.6.26-rc7 fixes it by removing the bit clearing in
      cpu_possible_map.
      Signed-off-by: NZhang Yanmin <yanmin_zhang@linux.intel.com>
      Tested-by: NVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: NRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      fcb43042
  7. 26 6月, 2008 1 次提交
    • D
      x86: section/warning fixes · 0b1faeef
      Daniel J Blueman 提交于
      WARNING: arch/x86/mm/built-in.o(.text+0x3a1): Section mismatch in
      reference from the function set_pte_phys() to the function
      .init.text:spp_getpage()
      The function set_pte_phys() references
      the function __init spp_getpage().
      This is often because set_pte_phys lacks a __init
      annotation or the annotation of spp_getpage is wrong.
      
      arch/x86/mm/init_64.c: In function 'early_memtest':
      arch/x86/mm/init_64.c:520: warning: passing argument 2 of
      'find_e820_area_size' from incompatible pointer type
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      0b1faeef
  8. 25 6月, 2008 4 次提交
  9. 24 6月, 2008 7 次提交
  10. 20 6月, 2008 2 次提交
  11. 19 6月, 2008 4 次提交
    • J
      x86, geode: add a VSA2 ID for General Software · ffe6e1da
      Jordan Crouse 提交于
      General Software writes their own VSA2 module for their version
      of the Geode BIOS, which returns a different ID then the standard
      VSA2.  This was causing the framebuffer driver to break for most
      GSW boards.
      Signed-off-by: NJordan Crouse <jordan.crouse@amd.com>
      Cc: tglx@linutronix.de
      Cc: linux-geode@lists.infradead.org
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ffe6e1da
    • B
      x86: use BOOTMEM_EXCLUSIVE on 32-bit · d3942cff
      Bernhard Walle 提交于
      This patch uses the BOOTMEM_EXCLUSIVE for crashkernel reservation also for
      i386 and prints a error message on failure.
      
      The patch is still for 2.6.26 since it is only bug fixing. The unification
      of reserve_crashkernel() between i386 and x86_64 should be done for 2.6.27.
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: <stable@kernel.org>
      d3942cff
    • M
      x86, 32-bit: fix boot failure on TSC-less processors · df17b1d9
      Mikael Pettersson 提交于
      Booting 2.6.26-rc6 on my 486 DX/4 fails with a "BUG: Int 6"
      (invalid opcode) and a kernel halt immediately after the
      kernel has been uncompressed. The BUG shows EIP pointing
      to an rdtsc instruction in native_read_tsc(), invoked from
      native_sched_clock().
      
      (This error occurs so early that not even the serial console
      can capture it.)
      
      A bisection showed that this bug first occurs in 2.6.26-rc3-git7,
      via commit 9ccc906c:
      
      >x86: distangle user disabled TSC from unstable
      >
      >tsc_enabled is set to 0 from the command line switch "notsc" and from
      >the mark_tsc_unstable code. Seperate those functionalities and replace
      >tsc_enable with tsc_disable. This makes also the native_sched_clock()
      >decision when to use TSC understandable.
      >
      >Preparatory patch to solve the sched_clock() issue on 32 bit.
      >
      >Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
      
      The core reason for this bug is that native_sched_clock() gets
      called before tsc_init().
      
      Before the commit above, tsc_32.c used a "tsc_enabled" variable
      which defaulted to 0 == disabled, and which only got enabled late
      in tsc_init(). Thus early calls to native_sched_clock() would skip
      the TSC and use jiffies instead.
      
      After the commit above, tsc_32.c uses a "tsc_disabled" variable
      which defaults to 0, meaning that the TSC is Ok to use. Early calls
      to native_sched_clock() now erroneously try to use the TSC on
      !cpu_has_tsc processors, leading to invalid opcode exceptions.
      
      My proposed fix is to initialise tsc_disabled to a "soft disabled"
      state distinct from the hard disabled state set up by the "notsc"
      kernel option. This fixes the native_sched_clock() problem. It also
      allows tsc_init() to be simplified: instead of setting tsc_disabled = 1
      on every error return, we just set tsc_disabled = 0 once when all
      checks have succeeded.
      
      I've verified that this lets my 486 boot again. I've also verified
      that a Core2 machine still uses the TSC as clocksource after the patch.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      df17b1d9
    • S
      x86: fix NULL pointer deref in __switch_to · 75118a82
      Suresh Siddha 提交于
      Patrick McHardy reported a crash:
      
      > > I get this oops once a day, its apparently triggered by something
      > > run by cron, but the process is a different one each time.
      > >
      > > Kernel is -git from yesterday shortly before the -rc6 release
      > > (last commit is the usb-2.6 merge, the x86 patches are missing),
      > > .config is attached.
      > >
      > > I'll retry with current -git, but the patches that have gone in
      > > since I last updated don't look related.
      > >
      > > [62060.043009] BUG: unable to handle kernel NULL pointer dereference at
      > > 000001ff
      > > [62060.043009] IP: [<c0102a9b>] __switch_to+0x2f/0x118
      > > [62060.043009] *pde = 00000000
      > > [62060.043009] Oops: 0002 [#1] PREEMPT
      
      Vegard Nossum analyzed it:
      
      > This decodes to
      >
      >    0:   0f ae 00                fxsave (%eax)
      >
      > so it's related to the floating-point context. This is the exact
      > location of the crash:
      >
      > $ addr2line -e arch/x86/kernel/process_32.o -i ab0
      > include/asm/i387.h:232
      > include/asm/i387.h:262
      > arch/x86/kernel/process_32.c:595
      >
      > ...so it looks like prev_task->thread.xstate->fxsave has become NULL.
      > Or maybe it never had any other value.
      
      Somehow (as described below) TS_USEDFPU is set but the fpu is not
      allocated or freed.
      
      Another possible FPU pre-emption issue with the sleazy FPU optimization
      which was benign before but not so anymore, with the dynamic FPU allocation
      patch.
      
      New task is getting exec'd and it is prempted at the below point.
      
      flush_thread() {
      	...
      	/*
      	* Forget coprocessor state..
      	*/
      	clear_fpu(tsk);
      		<----- Preemption point
      	clear_used_math();
      	...
      }
      
      Now when it context switches in again, as the used_math() is still set
      and fpu_counter can be > 5, we will do a math_state_restore() which sets
      the task's TS_USEDFPU. After it continues from the above preemption point
      it does clear_used_math() and much later free_thread_xstate().
      
      Now, at the next context switch, it is quite possible that xstate is
      null, used_math() is not set and TS_USEDFPU is still set. This will
      trigger unlazy_fpu() causing kernel oops.
      
      Fix this  by clearing tsk's fpu_counter before clearing task's fpu.
      Reported-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      75118a82
  12. 18 6月, 2008 1 次提交
    • L
      x86-64: Fix "bytes left to copy" return value for copy_from_user() · 42a886af
      Linus Torvalds 提交于
      Most users by far do not care about the exact return value (they only
      really care about whether the copy succeeded in its entirety or not),
      but a few special core routines actually care deeply about exactly how
      many bytes were copied from user space.
      
      And the unrolled versions of the x86-64 user copy routines would
      sometimes report that it had copied more bytes than it actually had.
      
      Very few uses actually have partial copies to begin with, but to make
      this bug even harder to trigger, most x86 CPU's use the "rep string"
      instructions for normal user copies, and that version didn't have this
      issue.
      
      To make it even harder to hit, the one user of this that really cared
      about the return value (and used the uncached version of the copy that
      doesn't use the "rep string" instructions) was the generic write
      routine, which pre-populated its source, once more hiding the problem by
      avoiding the exception case that triggers the bug.
      
      In other words, very special thanks to Bron Gondwana who not only
      triggered this, but created a test-program to show it, and bisected the
      behavior down to commit 08291429 ("mm:
      fix pagecache write deadlocks") which changed the access pattern just
      enough that you can now trigger it with 'writev()' with multiple
      iovec's.
      
      That commit itself was not the cause of the bug, it just allowed all the
      stars to align just right that you could trigger the problem.
      
      [ Side note: this is just the minimal fix to make the copy routines
        (with __copy_from_user_inatomic_nocache as the particular version that
        was involved in showing this) have the right return values.
      
        We really should improve on the exceptional case further - to make the
        copy do a byte-accurate copy up to the exact page limit that causes it
        to fail.  As it is, the callers have to do extra work to handle the
        limit case gracefully. ]
      Reported-by: NBron Gondwana <brong@fastmail.fm>
      Cc: Nick Piggin <npiggin@suse.de>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Al Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      
       (which didn't have this problem), and since
      most users that do the carethis was very hard to trigger, but
      42a886af
  13. 13 6月, 2008 6 次提交
    • S
      provide rtc_cmos platform device · 1da2e3d6
      Stas Sergeev 提交于
      Recently (around 2.6.25) I've noticed that RTC no longer works for me.  It
      turned out this is because I use pnpacpi=off kernel option to work around
      the parport_pc bugs.  I always did so, but RTC used to work fine in the
      past, and now it have regressed.
      
      The patch fixes the problem by creating the platform device for the RTC
      when PNP is disabled.  This may also help running the PNP-enabled kernel
      on an older PCs.
      Signed-off-by: NStas Sergeev <stsp@aknet.ru>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Bjorn Helgaas <bjorn.helgaas@hp.com>
      Cc: Adam Belay <ambx1@neo.rr.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1da2e3d6
    • K
      x86: fix pointer type warning in arch/x86/mm/init_64.c:early_memtest · f8a45704
      Kevin Winchester 提交于
      Changed the call to find_e820_area_size to pass u64 instead of unsigned long.
      Signed-off-by: NKevin Winchester <kjwinchester@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f8a45704
    • V
      x86, lockdep: fix "WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()" · 4461145e
      Vegard Nossum 提交于
      Alessandro Suardi reported:
      > Recently upgraded my FC6 desktop to Fedora 9; with the
      >  latest nautilus RPM updates my VNC session went nuts
      >  with nautilus pegging the CPU for everything that breathed.
      >
      > I now reverted to an earlier nautilus package, but during
      >  the peak CPU period my kernel spat this:
      >
      > [314185.623294] ------------[ cut here ]------------
      > [314185.623414] WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x128()
      > [314185.623514] Modules linked in: iptable_filter ip_tables x_tables
      > sunrpc ipv6 fuse snd_via82xx snd_ac97_codec ac97_bus snd_mpu401_uart
      > snd_rawmidi via686a hwmon parport_pc sg parport uhci_hcd ehci_hcd
      > [314185.623924] Pid: 12314, comm: nautilus Not tainted 2.6.26-rc5-git2 #4
      > [314185.624021]  [<c0115b95>] warn_on_slowpath+0x41/0x7b
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c0128396>] ? up_read+0x16/0x28
      > [314185.624021]  [<c010de70>] ? do_page_fault+0x2c1/0x5fd
      > [314185.624021]  [<c012fa33>] ? __lock_acquire+0xbb4/0xbc3
      > [314185.624021]  [<c012d0a0>] check_flags+0x4c/0x128
      > [314185.624021]  [<c012fa73>] lock_acquire+0x31/0x7d
      > [314185.624021]  [<c0128cf6>] __atomic_notifier_call_chain+0x30/0x80
      > [314185.624021]  [<c0128cc6>] ? __atomic_notifier_call_chain+0x0/0x80
      > [314185.624021]  [<c0128d52>] atomic_notifier_call_chain+0xc/0xe
      > [314185.624021]  [<c0128d81>] notify_die+0x2d/0x2f
      > [314185.624021]  [<c01043b0>] do_int3+0x1f/0x4d
      > [314185.624021]  [<c02f2d3b>] int3+0x27/0x2c
      > [314185.624021]  =======================
      > [314185.624021] ---[ end trace 1923f65a2d7bb246 ]---
      > [314185.624021] possible reason: unannotated irqs-off.
      > [314185.624021] irq event stamp: 488879
      > [314185.624021] hardirqs last  enabled at (488879): [<c0102d67>]
      > restore_nocheck+0x12/0x15
      > [314185.624021] hardirqs last disabled at (488878): [<c0102dca>]
      > work_resched+0x19/0x30
      > [314185.624021] softirqs last  enabled at (488876): [<c011a1ba>]
      > __do_softirq+0xa6/0xac
      > [314185.624021] softirqs last disabled at (488865): [<c010476e>]
      > do_softirq+0x57/0xa6
      >
      > I didn't seem to find it with some googling, so here it is.
      >
      > I was incidentally ltracing that process to try and find out
      >  what was gulping down that much CPU (sorry, no idea
      >  whether ltrace and the WARNING happened at the same
      >  time or which came first) and:
      
      Yeah, this is extremely likely to be the source of the warning.
      
      The warning should be harmless, however.
      
      > Box is my trusty noname K7-800, 512MB RAM; if there's
      >  anything else useful I might be able to provide, just ask.
      
      It would be interesting to see where the int3 comes from.  Too bad,
      lockdep doesn't provide the register dump. The stacktrace also doesn't
      go further than the int3(), I wonder if this int3 came from userspace?
      The ltrace readme says "software breakpoints, like gdb", so I guess
      this is the case. Yep, seems like it.
      
      This looks relevant:
      
      | commit fb1dac90
      | Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
      | Date:   Wed Jan 16 09:51:59 2008 +0100
      |
      |     lockdep: more hardirq annotations for notify_die()
      
      I'm attaching a similarly-looking patch for this case (DO_VM86_ERROR),
      though I suspect it might be missing for the other cases
      (DO_ERROR/DO_ERROR_INFO) as well.
      Reported-by: NAlessandro Suardi <alessandro.suardi@gmail.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4461145e
    • D
      x86: fix an incompatible pointer type warning on 64-bit compilations · eb53e9f3
      David Howells 提交于
      Fix an incompatible pointer type warning on x86_64 compilations.
      early_memtest() is passing a u64* to find_e820_area_size() which is expecting
      an unsigned long.  Change t_start and t_size to unsigned long as those are
      also 64-bit types on x88_64.
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      eb53e9f3
    • P
      x86: fix lockdep warning during suspend-to-ram · e32e58a9
      Peter Zijlstra 提交于
      Andrew Morton wrote:
      
      > I've been seeing the below for a long time during suspend-to-ram on the Vaio.
      >
      >
      > PM: Syncing filesystems ... done.
      > PM: Preparing system for mem sleep
      > Freezing user space processes ... <4>------------[ cut here ]------------
      > WARNING: at kernel/lockdep.c:2658 check_flags+0x4c/0x127()
      > Modules linked in: i915 drm ipw2200 sonypi ipv6 autofs4 hidp l2cap bluetooth sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack xt_tcpudp iptable_filter ip_tables x_tables acpi_cpufreq nvram ohci1394 ieee1394 ehci_hcd uhci_hcd sg joydev snd_hda_intel snd_seq_dummy sr_mod snd_seq_oss cdrom snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss ieee80211 pcspkr ieee80211_crypt snd_pcm i2c_i801 snd_timer i2c_core ide_pci_generic piix snd soundcore snd_page_alloc button ext3 jbd ide_disk ide_core [last unloaded: ipw2200]
      > Pid: 3250, comm: zsh Not tainted 2.6.26-rc5 #1
      >  [<c011c5f5>] warn_on_slowpath+0x41/0x6d
      >  [<c01080e6>] ? native_sched_clock+0x82/0x96
      >  [<c013789c>] ? mark_held_locks+0x41/0x5c
      >  [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58
      >  [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d
      >  [<c0138637>] ? __lock_acquire+0xae3/0xb2b
      >  [<c0313413>] ? schedule+0x39b/0x3b4
      >  [<c0135596>] check_flags+0x4c/0x127
      >  [<c01386b9>] lock_acquire+0x3a/0x86
      >  [<c0315075>] _spin_lock+0x26/0x53
      >  [<c0140660>] ? refrigerator+0x13/0xc3
      >  [<c0140660>] refrigerator+0x13/0xc3
      >  [<c012684a>] get_signal_to_deliver+0x3c/0x31e
      >  [<c0102fe7>] do_notify_resume+0x91/0x6ee
      >  [<c01359fd>] ? lock_release_holdtime+0x50/0x56
      >  [<c0315688>] ? _spin_unlock_irqrestore+0x36/0x58
      >  [<c0235d24>] ? read_chan+0x0/0x58c
      >  [<c0137a29>] ? trace_hardirqs_on+0xe6/0x10d
      >  [<c0315694>] ? _spin_unlock_irqrestore+0x42/0x58
      >  [<c0230afa>] ? tty_ldisc_deref+0x5c/0x63
      >  [<c0233104>] ? tty_read+0x66/0x98
      >  [<c014b3f0>] ? audit_syscall_exit+0x2aa/0x2c5
      >  [<c0109430>] ? do_syscall_trace+0x6b/0x16f
      >  [<c0103a9c>] work_notifysig+0x13/0x1b
      >  =======================
      > ---[ end trace 25b49fe59a25afa5 ]---
      > possible reason: unannotated irqs-off.
      > irq event stamp: 58919
      > hardirqs last  enabled at (58919): [<c0103afd>] syscall_exit_work+0x11/0x26
      
      Joy - I so love entry.S
      
      Best I can make of it:
      
      syscall_exit_work
        resume_userspace
          DISABLE_INTERRUPTS
          (no TRACE_IRQS_OFF)
            work_pending
              work_notifysig
                do_notify_resume()
                  do_signal()
                    get_signal_to_deliver()
                      try_to_freeze()
                        refrigerator()
                          task_lock() -> check_flags() -> BANG
      
      The normal path is:
      
      syscall_exit_work
        resume_userspace
          DISABLE_INTERRUPTS
          restore_all
            TRACE_IRQS_IRET
            iret
      
      No idea why that would not warn..
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e32e58a9
    • M
      x86: fix unused variable 'loops' warning in arch/x86/boot/a20.c · 52aaa12f
      Manish Katiyar 提交于
      Following patch fixes the below warning message :
      arch/x86/boot/a20.c:118: warning: unused variable 'loops'
      
      Signed-off-by : Manish Katiyar <mkatiyar@gmail.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      52aaa12f