1. 01 9月, 2012 1 次提交
  2. 05 8月, 2012 3 次提交
    • A
      pstore/ram: Mark ramoops_pstore_write_buf() as notrace · 24203036
      Anton Vorontsov 提交于
      write_buf() should be marked as notrace, otherwise it is prone to
      recursion.
      
      Though, yet the issue is never triggered in real life, because we run
      inside the function tracer, where ftrace does its own recurse protection.
      
      But it's still no good, plus soon we might switch to our own tracer ops,
      and then the issue will be fatal. So, let's fix it.
      Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      24203036
    • R
      pstore/ram: Fix printk format warning · 0427193b
      Randy Dunlap 提交于
      Fix printk format warning (on i386) in pstore:
      
      fs/pstore/ram.c:409:3: warning: format '%lu' expects type 'long unsigned int', but argument 2 has type 'size_t'
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      0427193b
    • A
      pstore/ram: Fix possible NULL dereference · a384f641
      Anton Vorontsov 提交于
      We can dereference 'cxt->cprz' if console and dump logging are disabled
      (which is unlikely, but still possible to do). This patch fixes the issue
      by changing the code so that we don't dereference przs at all, we can
      just calculate bufsize from console_size and record_size values.
      
      Plus, while at it, the patch improves the buffer size calculation.
      
      After Kay's printk rework, we know the optimal buffer size for console
      logging -- it is LOG_LINE_MAX (defined privately in printk.c). Previously,
      if only console logging was enabled, we would allocate unnecessary large
      buffer in pstore, while we only need LOG_LINE_MAX. (Pstore console logging
      is still capable of handling buffers > LOG_LINE_MAX, it will just do
      multiple calls to psinfo->write).
      
      Note that I don't export the constant, since we will do even a better
      thing soon: we will switch console logging to a new write_buf API, which
      will eliminate the need for the additional buffer; and so we won't need
      the constant.
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NAnton Vorontsov <anton.vorontsov@linaro.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      a384f641
  3. 18 7月, 2012 4 次提交
  4. 21 6月, 2012 2 次提交
  5. 14 6月, 2012 6 次提交
  6. 17 5月, 2012 2 次提交
  7. 16 5月, 2012 3 次提交
  8. 25 2月, 2012 1 次提交
  9. 13 1月, 2012 3 次提交
  10. 01 11月, 2011 1 次提交
  11. 04 8月, 2011 1 次提交
  12. 30 7月, 2011 1 次提交
  13. 27 7月, 2011 4 次提交
  14. 14 1月, 2011 2 次提交
    • A
      ramoops: fix types, remove typecasts · 264b795f
      Andrew Morton 提交于
      Cc: Ahmed S. Darwish <darwish.07@gmail.com>
      Cc: Kyungmin Park <kyungmin.park@samsung.com>
      Cc: Marco Stornelli <marco.stornelli@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      264b795f
    • S
      kmsg_dump: constrain mtdoops and ramoops to perform their actions only for KMSG_DUMP_PANIC · fc2d557c
      Seiji Aguchi 提交于
      This series aims to develop logging facility for enterprise use.
      
      It is important to save kernel messages reliably on enterprise system
      because they are helpful for diagnosing system.
      
      This series add kmsg_dump() to the paths loosing kernel messages.  The use
      case is the following.
      
      [Use case of reboot/poweroff/halt/emergency_restart]
      
       My company has often experienced the followings in our support service.
       - Customer's system suddenly reboots.
       - Customers ask us to investigate the reason of the reboot.
      
      We recognize the fact itself because boot messages remain in
      /var/log/messages.  However, we can't investigate the reason why the
      system rebooted, because the last messages don't remain.  And off course
      we can't explain the reason.
      
      We can solve above problem with this patch as follows.
      
       Case1: reboot with command
         - We can see "Restarting system with command:" or ""Restarting system.".
      
       Case2: halt with command
         - We can see "System halted.".
      
       Case3: poweroff with command
         - We can see " Power down.".
      
       Case4: emergency_restart with sysrq.
         - We can see "Sysrq:" outputted in __handle_sysrq().
      
       Case5: emergency_restart with softdog.
         - We can see "Initiating system reboot" in watchdog_fire().
      
      So, we can distinguish the reason of reboot, poweroff, halt and emergency_restart.
      
      If customer executed reboot command, you may think the customer should
      know the fact.  However, they often claim they don't execute the command
      when they rebooted system by mistake.
      
      No message remains on the current Linux kernel, so we can't show the proof
      to the customer.  This patch improves this situation.
      
      This patch:
      
      Alters mtdoops and ramoops to perform their actions only for
      KMSG_DUMP_PANIC, KMSG_DUMP_OOPS and KMSG_DUMP_KEXEC because they would
      like to log crashes only.
      Signed-off-by: NSeiji Aguchi <seiji.aguchi@hds.com>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: Marco Stornelli <marco.stornelli@gmail.com>
      Reviewed-by: NArtem Bityutskiy <Artem.Bityutskiy@nokia.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fc2d557c
  15. 29 12月, 2010 1 次提交
  16. 28 10月, 2010 1 次提交
  17. 28 5月, 2010 1 次提交
    • M
      char drivers: RAM oops/panic logger · 56d611a0
      Marco Stornelli 提交于
      Ramoops, like mtdoops, can log oops/panic information but in RAM.  It can
      be used with persistent RAM for systems without flash support.  In
      addition, for this systems, with this driver, it's no more needed add to
      the kernel the mtd subsystem with advantage in footprint.
      
      It can be used in a very easy way with persistent RAM for systems without
      flash support.  For these systems, with this driver, it is no longer
      required to cinlude mtd subsystem with an advantage in footprint.  In
      addition, you can save flash space and store this information only in RAM.
      Signed-off-by: NMarco Stornelli <marco.stornelli@gmail.com>
      Cc: Simon Kagstrom <simon.kagstrom@netinsight.net>
      Cc: David Woodhouse <David.Woodhouse@intel.com>
      Cc; Anders Grafstrom <anders.grafstrom@netinsight.net>
      Cc: Yuasa Yoichi <yuasa@linux-mips.org>
      Cc: Jamie Lokier <jamie@shareable.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      56d611a0