1. 19 Jul, 2012 3 commits
  2. 11 Jul, 2012 5 commits
    • Yinghai Lu's avatar
      memblock: free allocated memblock_reserved_regions later · 29f67386
      Yinghai Lu authored
      memblock_free_reserved_regions() calls memblock_free(), but
      memblock_free() would double reserved.regions too, so we could free the
      old range for reserved.regions.
      
      Also tj said there is another bug which could be related to this.
      
      | I don't think we're saving any noticeable
      | amount by doing this "free - give it to page allocator - reserve
      | again" dancing.  We should just allocate regions aligned to page
      | boundaries and free them later when memblock is no longer in use.
      
      in that case, when DEBUG_PAGEALLOC, will get panic:
      
           memblock_free: [0x0000102febc080-0x0000102febf080] memblock_free_reserved_regions+0x37/0x39
        BUG: unable to handle kernel paging request at ffff88102febd948
        IP: [<ffffffff836a5774>] __next_free_mem_range+0x9b/0x155
        PGD 4826063 PUD cf67a067 PMD cf7fa067 PTE 800000102febd160
        Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
        CPU 0
        Pid: 0, comm: swapper Not tainted 3.5.0-rc2-next-20120614-sasha #447
        RIP: 0010:[<ffffffff836a5774>]  [<ffffffff836a5774>] __next_free_mem_range+0x9b/0x155
      
      See the discussion at https://lkml.org/lkml/2012/6/13/469
      
      
      
      So try to allocate with PAGE_SIZE alignment and free it later.
      Reported-by: default avatarSasha Levin <levinsasha928@gmail.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      29f67386
    • Yinghai Lu's avatar
      mm: sparse: fix usemap allocation above node descriptor section · 99ab7b19
      Yinghai Lu authored
      After commit f5bf18fa ("bootmem/sparsemem: remove limit constraint
      in alloc_bootmem_section"), usemap allocations may easily be placed
      outside the optimal section that holds the node descriptor, even if
      there is space available in that section.  This results in unnecessary
      hotplug dependencies that need to have the node unplugged before the
      section holding the usemap.
      
      The reason is that the bootmem allocator doesn't guarantee a linear
      search starting from the passed allocation goal but may start out at a
      much higher address absent an upper limit.
      
      Fix this by trying the allocation with the limit at the section end,
      then retry without if that fails.  This keeps the fix from f5bf18fa
      
      
      of not panicking if the allocation does not fit in the section, but
      still makes sure to try to stay within the section at first.
      Signed-off-by: default avatarYinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Cc: <stable@vger.kernel.org>	[3.3.x, 3.4.x]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      99ab7b19
    • Jiang Liu's avatar
      memory hotplug: fix invalid memory access caused by stale kswapd pointer · d8adde17
      Jiang Liu authored
      
      
      kswapd_stop() is called to destroy the kswapd work thread when all memory
      of a NUMA node has been offlined.  But kswapd_stop() only terminates the
      work thread without resetting NODE_DATA(nid)->kswapd to NULL.  The stale
      pointer will prevent kswapd_run() from creating a new work thread when
      adding memory to the memory-less NUMA node again.  Eventually the stale
      pointer may cause invalid memory access.
      
      An example stack dump as below. It's reproduced with 2.6.32, but latest
      kernel has the same issue.
      
        BUG: unable to handle kernel NULL pointer dereference at (null)
        IP: [<ffffffff81051a94>] exit_creds+0x12/0x78
        PGD 0
        Oops: 0000 [#1] SMP
        last sysfs file: /sys/devices/system/memory/memory391/state
        CPU 11
        Modules linked in: cpufreq_conservative cpufreq_userspace cpufreq_powersave acpi_cpufreq microcode fuse loop dm_mod tpm_tis rtc_cmos i2c_i801 rtc_core tpm serio_raw pcspkr sg tpm_bios igb i2c_core iTCO_wdt rtc_lib mptctl iTCO_vendor_support button dca bnx2 usbhid hid uhci_hcd ehci_hcd usbcore sd_mod crc_t10dif edd ext3 mbcache jbd fan ide_pci_generic ide_core ata_generic ata_piix libata thermal processor thermal_sys hwmon mptsas mptscsih mptbase scsi_transport_sas scsi_mod
        Pid: 7949, comm: sh Not tainted 2.6.32.12-qiuxishi-5-default #92 Tecal RH2285
        RIP: 0010:exit_creds+0x12/0x78
        RSP: 0018:ffff8806044f1d78  EFLAGS: 00010202
        RAX: 0000000000000000 RBX: ffff880604f22140 RCX: 0000000000019502
        RDX: 0000000000000000 RSI: 0000000000000202 RDI: 0000000000000000
        RBP: ffff880604f22150 R08: 0000000000000000 R09: ffffffff81a4dc10
        R10: 00000000000032a0 R11: ffff880006202500 R12: 0000000000000000
        R13: 0000000000c40000 R14: 0000000000008000 R15: 0000000000000001
        FS:  00007fbc03d066f0(0000) GS:ffff8800282e0000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000000000 CR3: 000000060f029000 CR4: 00000000000006e0
        DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        Process sh (pid: 7949, threadinfo ffff8806044f0000, task ffff880603d7c600)
        Stack:
         ffff880604f22140 ffffffff8103aac5 ffff880604f22140 ffffffff8104d21e
         ffff880006202500 0000000000008000 0000000000c38000 ffffffff810bd5b1
         0000000000000000 ffff880603d7c600 00000000ffffdd29 0000000000000003
        Call Trace:
          __put_task_struct+0x5d/0x97
          kthread_stop+0x50/0x58
          offline_pages+0x324/0x3da
          memory_block_change_state+0x179/0x1db
          store_mem_state+0x9e/0xbb
          sysfs_write_file+0xd0/0x107
          vfs_write+0xad/0x169
          sys_write+0x45/0x6e
          system_call_fastpath+0x16/0x1b
        Code: ff 4d 00 0f 94 c0 84 c0 74 08 48 89 ef e8 1f fd ff ff 5b 5d 31 c0 41 5c c3 53 48 8b 87 20 06 00 00 48 89 fb 48 8b bf 18 06 00 00 <8b> 00 48 c7 83 18 06 00 00 00 00 00 00 f0 ff 0f 0f 94 c0 84 c0
        RIP  exit_creds+0x12/0x78
         RSP <ffff8806044f1d78>
        CR2: 0000000000000000
      
      [akpm@linux-foundation.org: add pglist_data.kswapd locking comments]
      Signed-off-by: default avatarXishi Qiu <qiuxishi@huawei.com>
      Signed-off-by: default avatarJiang Liu <jiang.liu@huawei.com>
      Acked-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Acked-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Acked-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Reviewed-by: default avatarMinchan Kim <minchan@kernel.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d8adde17
    • Thomas Gleixner's avatar
      timekeeping: Provide hrtimer update function · f6c06abf
      Thomas Gleixner authored
      
      
      To finally fix the infamous leap second issue and other race windows
      caused by functions which change the offsets between the various time
      bases (CLOCK_MONOTONIC, CLOCK_REALTIME and CLOCK_BOOTTIME) we need a
      function which atomically gets the current monotonic time and updates
      the offsets of CLOCK_REALTIME and CLOCK_BOOTTIME with minimalistic
      overhead. The previous patch which provides ktime_t offsets allows us
      to make this function almost as cheap as ktime_get() which is going to
      be replaced in hrtimer_interrupt().
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJohn Stultz <johnstul@us.ibm.com>
      Link: http://lkml.kernel.org/r/1341960205-56738-7-git-send-email-johnstul@us.ibm.com
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      f6c06abf
    • John Stultz's avatar
      hrtimer: Provide clock_was_set_delayed() · f55a6faa
      John Stultz authored
      
      
      clock_was_set() cannot be called from hard interrupt context because
      it calls on_each_cpu().
      
      For fixing the widely reported leap seconds issue it is necessary to
      call it from hard interrupt context, i.e. the timer tick code, which
      does the timekeeping updates.
      
      Provide a new function which denotes it in the hrtimer cpu base
      structure of the cpu on which it is called and raise the hrtimer
      softirq. We then execute the clock_was_set() notificiation from
      softirq context in run_hrtimer_softirq(). The hrtimer softirq is
      rarely used, so polling the flag there is not a performance issue.
      
      [ tglx: Made it depend on CONFIG_HIGH_RES_TIMERS. We really should get
        rid of all this ifdeffery ASAP ]
      Signed-off-by: default avatarJohn Stultz <johnstul@us.ibm.com>
      Reported-by: default avatarJan Engelhardt <jengelh@inai.de>
      Reviewed-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatarPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/1341960205-56738-2-git-send-email-johnstul@us.ibm.com
      
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      f55a6faa
  3. 10 Jul, 2012 1 commit
    • Alan Stern's avatar
      PCI: EHCI: fix crash during suspend on ASUS computers · dbf0e4c7
      Alan Stern authored
      Quite a few ASUS computers experience a nasty problem, related to the
      EHCI controllers, when going into system suspend.  It was observed
      that the problem didn't occur if the controllers were not put into the
      D3 power state before starting the suspend, and commit
      151b6128 (USB: EHCI: fix crash during
      suspend on ASUS computers) was created to do this.
      
      It turned out this approach messed up other computers that didn't have
      the problem -- it prevented USB wakeup from working.  Consequently
      commit c2fb8a3f (USB: add
      NO_D3_DURING_SLEEP flag and revert 151b6128) was merged; it
      reverted the earlier commit and added a whitelist of known good board
      names.
      
      Now we know the actual cause of the problem.  Thanks to AceLan Kao for
      tracking it down.
      
      According to him, an engineer at ASUS explained that some of their
      BIOSes contain a bug that was added in an attempt to work around a
      problem in early versions of Windows.  When the computer goes into S3
      suspend, the BIOS tries to verify that the EHCI controllers were first
      quiesced by the OS.  Nothing's wrong with this, but the BIOS does it
      by checking that the PCI COMMAND registers contain 0 without checking
      the controllers' power state.  If the register isn't 0, the BIOS
      assumes the controller needs to be quiesced and tries to do so.  This
      involves making various MMIO accesses to the controller, which don't
      work very well if the controller is already in D3.  The end result is
      a system hang or memory corruption.
      
      Since the value in the PCI COMMAND register doesn't matter once the
      controller has been suspended, and since the value will be restored
      anyway when the controller is resumed, we can work around the BIOS bug
      simply by setting the register to 0 during system suspend.  This patch
      (as1590) does so and also reverts the second commit mentioned above,
      which is now unnecessary.
      
      In theory we could do this for every PCI device.  However to avoid
      introducing new problems, the patch restricts itself to EHCI host
      controllers.
      
      Finally the affected systems can suspend with USB wakeup working
      properly.
      
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=37632
      Reference: https://bugzilla.kernel.org/show_bug.cgi?id=42728
      
      Based-on-patch-by: default avatarAceLan Kao <acelan.kao@canonical.com>
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      Tested-by: default avatarDâniel Fraga <fragabr@gmail.com>
      Tested-by: default avatarJavier Marcet <jmarcet@gmail.com>
      Tested-by: default avatarAndrey Rahmatullin <wrar@wrar.name>
      Tested-by: default avatarOleksij Rempel <bug-track@fisher-privat.net>
      Tested-by: default avatarPavel Pisa <pisa@cmp.felk.cvut.cz>
      Cc: stable <stable@vger.kernel.org>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbf0e4c7
  4. 07 Jul, 2012 1 commit
  5. 06 Jul, 2012 2 commits
  6. 05 Jul, 2012 3 commits
  7. 04 Jul, 2012 2 commits
    • Ohad Ben-Cohen's avatar
      rpmsg: make sure inflight messages don't invoke just-removed callbacks · 15fd943a
      Ohad Ben-Cohen authored
      
      
      When inbound messages arrive, rpmsg core looks up their associated
      endpoint (by destination address) and then invokes their callback.
      
      We've made sure that endpoints will never be de-allocated after they
      were found by rpmsg core, but we also need to protect against the
      (rare) scenario where the rpmsg driver was just removed, and its
      callback function isn't available anymore.
      
      This is achieved by introducing a callback mutex, which must be taken
      before the callback is invoked, and, obviously, before it is removed.
      
      Cc: stable <stable@vger.kernel.org>
      Reported-by: default avatarFernando Guzman Lugo <fernando.lugo@ti.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      15fd943a
    • Ohad Ben-Cohen's avatar
      rpmsg: avoid premature deallocation of endpoints · 5a081caa
      Ohad Ben-Cohen authored
      
      
      When an inbound message arrives, the rpmsg core looks up its
      associated endpoint and invokes the registered callback.
      
      If a message arrives while its endpoint is being removed (because
      the rpmsg driver was removed, or a recovery of a remote processor
      has kicked in) we must ensure atomicity, i.e.:
      
      - Either the ept is removed before it is found
      
      or
      
      - The ept is found but will not be freed until the callback returns
      
      This is achieved by maintaining a per-ept reference count, which,
      when drops to zero, will trigger deallocation of the ept.
      
      With this in hand, it is now forbidden to directly deallocate
      epts once they have been added to the endpoints idr.
      
      Cc: stable <stable@vger.kernel.org>
      Reported-by: default avatarFernando Guzman Lugo <fernando.lugo@ti.com>
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      5a081caa
  8. 03 Jul, 2012 1 commit
  9. 02 Jul, 2012 1 commit
  10. 30 Jun, 2012 1 commit
  11. 28 Jun, 2012 1 commit
    • Steven Rostedt's avatar
      tracing: Remove NR_CPUS array from trace_iterator · 6d158a81
      Steven Rostedt authored
      
      
      Replace the NR_CPUS array of buffer_iter from the trace_iterator
      with an allocated array. This will just create an array of
      possible CPUS instead of the max number specified.
      
      The use of NR_CPUS in that array caused allocation failures for
      machines that were tight on memory. This did not cause any failures
      to the system itself (no crashes), but caused unnecessary failures
      for reading the trace files.
      
      Added a helper function called 'trace_buffer_iter()' that returns
      the buffer_iter item or NULL if it is not defined or the array was
      not allocated. Some routines do not require the array
      (tracing_open_pipe() for one).
      Reported-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      6d158a81
  12. 21 Jun, 2012 1 commit
  13. 20 Jun, 2012 2 commits
  14. 18 Jun, 2012 5 commits
  15. 16 Jun, 2012 2 commits
    • Randy Dunlap's avatar
      vga_switcheroo.h: fix pci_dev warning · f8fee8f5
      Randy Dunlap authored
      
      
      Fix warnings on some architectures/configs (not on x86):
      
      include/linux/vga_switcheroo.h:28:30: warning: 'struct pci_dev' declared inside parameter list [enabled by default]
      include/linux/vga_switcheroo.h:28:30: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default]
      Signed-off-by: default avatarRandy Dunlap <rdunlap@xenotime.net>
      Cc:	Takashi Iwai <tiwai@suse.de>
      Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      f8fee8f5
    • Hugh Dickins's avatar
      swap: fix shmem swapping when more than 8 areas · 9b15b817
      Hugh Dickins authored
      
      
      Minchan Kim reports that when a system has many swap areas, and tmpfs
      swaps out to the ninth or more, shmem_getpage_gfp()'s attempts to read
      back the page cannot locate it, and the read fails with -ENOMEM.
      
      Whoops.  Yes, I blindly followed read_swap_header()'s pte_to_swp_entry(
      swp_entry_to_pte()) technique for determining maximum usable swap
      offset, without stopping to realize that that actually depends upon the
      pte swap encoding shifting swap offset to the higher bits and truncating
      it there.  Whereas our radix_tree swap encoding leaves offset in the
      lower bits: it's swap "type" (that is, index of swap area) that was
      truncated.
      
      Fix it by reducing the SWP_TYPE_SHIFT() in swapops.h, and removing the
      broken radix_to_swp_entry(swp_to_radix_entry()) from read_swap_header().
      
      This does not reduce the usable size of a swap area any further, it
      leaves it as claimed when making the original commit: no change from 3.0
      on x86_64, nor on i386 without PAE; but 3.0's 512GB is reduced to 128GB
      per swapfile on i386 with PAE.  It's not a change I would have risked
      five years ago, but with x86_64 supported for ten years, I believe it's
      appropriate now.
      
      Hmm, and what if some architecture implements its swap pte with offset
      encoded below type? That would equally break the maximum usable swap
      offset check.  Happily, they all follow the same tradition of encoding
      offset above type, but I'll prepare a check on that for next.
      Reported-and-Reviewed-and-Tested-by: default avatarMinchan Kim <minchan@kernel.org>
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: stable@vger.kernel.org [3.1, 3.2, 3.3, 3.4]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9b15b817
  16. 15 Jun, 2012 3 commits
  17. 14 Jun, 2012 1 commit
    • Steven Rostedt's avatar
      tracing: Add comments for the other bits of ftrace_event_call.flags · 5da43bed
      Steven Rostedt authored
      
      
      	TRACE_EVENT_FL_ENABLED_BIT,
      	TRACE_EVENT_FL_FILTERED_BIT,
      	TRACE_EVENT_FL_RECORDED_CMD_BIT,
      
      Have comments about what they are, but:
      
      	TRACE_EVENT_FL_CAP_ANY_BIT,
      	TRACE_EVENT_FL_NO_SET_FILTER_BIT,
      	TRACE_EVENT_FL_IGNORE_ENABLE_BIT,
      
      do not, making them second class citizens. To prevent another
      class warfare, these bits have protested for their right to be
      commented. And By Golly! I'll give them what they want!
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      5da43bed
  18. 13 Jun, 2012 4 commits
  19. 12 Jun, 2012 1 commit