1. 30 3月, 2012 1 次提交
  2. 17 1月, 2012 1 次提交
  3. 18 11月, 2011 2 次提交
    • K
      pstore: pass reason to backend write callback · 3d6d8d20
      Kees Cook 提交于
      This allows a backend to filter on the dmesg reason as well as the pstore
      reason. When ramoops is switched to pstore, this is needed since it has
      no interest in storing non-crash dmesg details.
      
      Drop pstore_write() as it has no users, and handling the "reason" here
      has no obviously correct value.
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      3d6d8d20
    • K
      pstore: pass allocated memory region back to caller · f6f82851
      Kees Cook 提交于
      The buf_lock cannot be held while populating the inodes, so make the backend
      pass forward an allocated and filled buffer instead. This solves the following
      backtrace. The effect is that "buf" is only ever used to notify the backends
      that something was written to it, and shouldn't be used in the read path.
      
      To replace the buf_lock during the read path, isolate the open/read/close
      loop with a separate mutex to maintain serialized access to the backend.
      
      Note that is is up to the pstore backend to cope if the (*write)() path is
      called in the middle of the read path.
      
      [   59.691019] BUG: sleeping function called from invalid context at .../mm/slub.c:847
      [   59.691019] in_atomic(): 0, irqs_disabled(): 1, pid: 1819, name: mount
      [   59.691019] Pid: 1819, comm: mount Not tainted 3.0.8 #1
      [   59.691019] Call Trace:
      [   59.691019]  [<810252d5>] __might_sleep+0xc3/0xca
      [   59.691019]  [<810a26e6>] kmem_cache_alloc+0x32/0xf3
      [   59.691019]  [<810b53ac>] ? __d_lookup_rcu+0x6f/0xf4
      [   59.691019]  [<810b68b1>] alloc_inode+0x2a/0x64
      [   59.691019]  [<810b6903>] new_inode+0x18/0x43
      [   59.691019]  [<81142447>] pstore_get_inode.isra.1+0x11/0x98
      [   59.691019]  [<81142623>] pstore_mkfile+0xae/0x26f
      [   59.691019]  [<810a2a66>] ? kmem_cache_free+0x19/0xb1
      [   59.691019]  [<8116c821>] ? ida_get_new_above+0x140/0x158
      [   59.691019]  [<811708ea>] ? __init_rwsem+0x1e/0x2c
      [   59.691019]  [<810b67e8>] ? inode_init_always+0x111/0x1b0
      [   59.691019]  [<8102127e>] ? should_resched+0xd/0x27
      [   59.691019]  [<8137977f>] ? _cond_resched+0xd/0x21
      [   59.691019]  [<81142abf>] pstore_get_records+0x52/0xa7
      [   59.691019]  [<8114254b>] pstore_fill_super+0x7d/0x91
      [   59.691019]  [<810a7ff5>] mount_single+0x46/0x82
      [   59.691019]  [<8114231a>] pstore_mount+0x15/0x17
      [   59.691019]  [<811424ce>] ? pstore_get_inode.isra.1+0x98/0x98
      [   59.691019]  [<810a8199>] mount_fs+0x5a/0x12d
      [   59.691019]  [<810b9174>] ? alloc_vfsmnt+0xa4/0x14a
      [   59.691019]  [<810b9474>] vfs_kern_mount+0x4f/0x7d
      [   59.691019]  [<810b9d7e>] do_kern_mount+0x34/0xb2
      [   59.691019]  [<810bb15f>] do_mount+0x5fc/0x64a
      [   59.691019]  [<810912fb>] ? strndup_user+0x2e/0x3f
      [   59.691019]  [<810bb3cb>] sys_mount+0x66/0x99
      [   59.691019]  [<8137b537>] sysenter_do_call+0x12/0x26
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      f6f82851
  4. 13 10月, 2011 1 次提交
  5. 17 8月, 2011 1 次提交
    • D
      pstore: change mutex locking to spin_locks · abd4d558
      Don Zickus 提交于
      pstore was using mutex locking to protect read/write access to the
      backend plug-ins.  This causes problems when pstore is executed in
      an NMI context through panic() -> kmsg_dump().
      
      This patch changes the mutex to a spin_lock_irqsave then also checks to
      see if we are in an NMI context.  If we are in an NMI and can't get the
      lock, just print a message stating that and blow by the locking.
      
      All this is probably a hack around the bigger locking problem but it
      solves my current situation of trying to sleep in an NMI context.
      
      Tested by loading the lkdtm module and executing a HARDLOCKUP which
      will cause the machine to panic inside the nmi handler.
      Signed-off-by: NDon Zickus <dzickus@redhat.com>
      Acked-by: NMatthew Garrett <mjg@redhat.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      abd4d558
  6. 23 7月, 2011 3 次提交
  7. 14 7月, 2011 1 次提交
  8. 17 5月, 2011 3 次提交
  9. 22 3月, 2011 1 次提交
    • H
      ACPI, APEI, Add ERST record ID cache · 885b976f
      Huang Ying 提交于
      APEI ERST firmware interface and implementation has no multiple users
      in mind.  For example, if there is four records in storage with ID: 1,
      2, 3 and 4, if two ERST readers enumerate the records via
      GET_NEXT_RECORD_ID as follow,
      
      reader 1		reader 2
      1
      			2
      3
      			4
      -1
      			-1
      
      where -1 signals there is no more record ID.
      
      Reader 1 has no chance to check record 2 and 4, while reader 2 has no
      chance to check record 1 and 3.  And any other GET_NEXT_RECORD_ID will
      return -1, that is, other readers will has no chance to check any
      record even they are not cleared by anyone.
      
      This makes raw GET_NEXT_RECORD_ID not suitable for used by multiple
      users.
      
      To solve the issue, an in-memory ERST record ID cache is designed and
      implemented.  When enumerating record ID, the ID returned by
      GET_NEXT_RECORD_ID is added into cache in addition to be returned to
      caller.  So other readers can check the cache to get all record ID
      available.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Reviewed-by: NAndi Kleen <ak@linux.intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      885b976f
  10. 04 1月, 2011 1 次提交
  11. 03 1月, 2011 1 次提交
  12. 11 12月, 2010 1 次提交
  13. 30 9月, 2010 2 次提交
  14. 29 9月, 2010 1 次提交
  15. 12 8月, 2010 1 次提交
    • T
      acpi: fix bogus preemption logic · 0a7992c9
      Thomas Gleixner 提交于
      The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d1
      (ACPICA: add preemption point after each opcode parse).  The follow up
      commits abe1dfab, 138d1569, c084ca70 tried to fix the preemption logic
      back and forth, but nobody noticed that the usage of
      in_atomic_preempt_off() in that context is wrong.
      
      The check which guards the call of cond_resched() is:
      
          if (!in_atomic_preempt_off() && !irqs_disabled())
      
      in_atomic_preempt_off() is not intended for general use as the comment
      above the macro definition clearly says:
      
       * Check whether we were atomic before we did preempt_disable():
       * (used by the scheduler, *after* releasing the kernel lock)
      
      On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by
      accident, but with CONFIG_PREEMPT=y it's just broken.
      
      The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency
      on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on
      CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210
      
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Francois Valenduc <francois.valenduc@tvcablenet.be>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0a7992c9
  16. 02 7月, 2010 1 次提交
  17. 20 5月, 2010 1 次提交
    • H
      ACPI, APEI, Error Record Serialization Table (ERST) support · a08f82d0
      Huang Ying 提交于
      ERST is a way provided by APEI to save and retrieve hardware error
      record to and from some simple persistent storage (such as flash).
      
      The Linux kernel support implementation is quite simple and workable
      in NMI context. So it can be used to save hardware error record into
      flash in hardware error exception or NMI handler, where other more
      complex persistent storage such as disk is not usable. After saving
      hardware error records via ERST in hardware error exception or NMI
      handler, the error records can be retrieved and logged into disk or
      network after a clean reboot.
      
      For more information about ERST, please refer to ACPI Specification
      version 4.0, section 17.4.
      
      This patch incorporate fixes from Jin Dongming.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      CC: Jin Dongming <jin.dongming@np.css.fujitsu.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      a08f82d0