1. 01 5月, 2008 1 次提交
  2. 15 2月, 2008 1 次提交
  3. 14 2月, 2008 1 次提交
    • M
      Linux Kernel Markers: support multiple probes · fb40bd78
      Mathieu Desnoyers 提交于
      RCU style multiple probes support for the Linux Kernel Markers.  Common case
      (one probe) is still fast and does not require dynamic allocation or a
      supplementary pointer dereference on the fast path.
      
      - Move preempt disable from the marker site to the callback.
      
      Since we now have an internal callback, move the preempt disable/enable to the
      callback instead of the marker site.
      
      Since the callback change is done asynchronously (passing from a handler that
      supports arguments to a handler that does not setup the arguments is no
      arguments are passed), we can safely update it even if it is outside the
      preempt disable section.
      
      - Move probe arm to probe connection. Now, a connected probe is automatically
        armed.
      
      Remove MARK_MAX_FORMAT_LEN, unused.
      
      This patch modifies the Linux Kernel Markers API : it removes the probe
      "arm/disarm" and changes the probe function prototype : it now expects a
      va_list * instead of a "...".
      
      If we want to have more than one probe connected to a marker at a given
      time (LTTng, or blktrace, ssytemtap) then we need this patch. Without it,
      connecting a second probe handler to a marker will fail.
      
      It allow us, for instance, to do interesting combinations :
      
      Do standard tracing with LTTng and, eventually, to compute statistics
      with SystemTAP, or to have a special trigger on an event that would call
      a systemtap script which would stop flight recorder tracing.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Mike Mason <mmlnx@us.ibm.com>
      Cc: Dipankar Sarma <dipankar@in.ibm.com>
      Cc: David Smith <dsmith@redhat.com>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Cc: "Frank Ch. Eigler" <fche@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fb40bd78
  4. 09 2月, 2008 1 次提交
  5. 29 1月, 2008 2 次提交
  6. 25 1月, 2008 2 次提交
  7. 20 10月, 2007 1 次提交
  8. 17 10月, 2007 2 次提交
  9. 17 7月, 2007 1 次提交
  10. 11 5月, 2007 1 次提交
  11. 10 5月, 2007 1 次提交
  12. 09 5月, 2007 4 次提交
  13. 03 5月, 2007 1 次提交
  14. 17 2月, 2007 1 次提交
  15. 08 2月, 2007 2 次提交
  16. 09 12月, 2006 1 次提交
    • J
      [PATCH] Generic BUG implementation · 7664c5a1
      Jeremy Fitzhardinge 提交于
      This patch adds common handling for kernel BUGs, for use by architectures as
      they wish.  The code is derived from arch/powerpc.
      
      The advantages of having common BUG handling are:
       - consistent BUG reporting across architectures
       - shared implementation of out-of-line file/line data
       - implement CONFIG_DEBUG_BUGVERBOSE consistently
      
      This means that in inline impact of BUG is just the illegal instruction
      itself, which is an improvement for i386 and x86-64.
      
      A BUG is represented in the instruction stream as an illegal instruction,
      which has file/line information associated with it.  This extra information is
      stored in the __bug_table section in the ELF file.
      
      When the kernel gets an illegal instruction, it first confirms it might
      possibly be from a BUG (ie, in kernel mode, the right illegal instruction).
      It then calls report_bug().  This searches __bug_table for a matching
      instruction pointer, and if found, prints the corresponding file/line
      information.  If report_bug() determines that it wasn't a BUG which caused the
      trap, it returns BUG_TRAP_TYPE_NONE.
      
      Some architectures (powerpc) implement WARN using the same mechanism; if the
      illegal instruction was the result of a WARN, then report_bug(Q) returns
      CONFIG_DEBUG_BUGVERBOSE; otherwise it returns BUG_TRAP_TYPE_BUG.
      
      lib/bug.c keeps a list of loaded modules which can be searched for __bug_table
      entries.  The architecture must call
      module_bug_finalize()/module_bug_cleanup() from its corresponding
      module_finalize/cleanup functions.
      
      Unsetting CONFIG_DEBUG_BUGVERBOSE will reduce the kernel size by some amount.
      At the very least, filename and line information will not be recorded for each
      but, but architectures may decide to store no extra information per BUG at
      all.
      
      Unfortunately, gcc doesn't have a general way to mark an asm() as noreturn, so
      architectures will generally have to include an infinite loop (or similar) in
      the BUG code, so that gcc knows execution won't continue beyond that point.
      gcc does have a __builtin_trap() operator which may be useful to achieve the
      same effect, unfortunately it cannot be used to actually implement the BUG
      itself, because there's no way to get the instruction's address for use in
      generating the __bug_table entry.
      
      [randy.dunlap@oracle.com: Handle BUG=n, GENERIC_BUG=n to prevent build errors]
      [bunk@stusta.de: include/linux/bug.h must always #include <linux/module.h]
      Signed-off-by: NJeremy Fitzhardinge <jeremy@goop.org>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Hugh Dickens <hugh@veritas.com>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7664c5a1
  17. 04 12月, 2006 1 次提交
  18. 02 12月, 2006 1 次提交
  19. 12 10月, 2006 1 次提交
    • F
      [PATCH] fix Module taint flags listing in Oops/panic · fa3ba2e8
      Florin Malita 提交于
      Module taint flags listing in Oops/panic has a couple of issues:
      
      * taint_flags() doesn't null-terminate the buffer after printing the flags
      
      * per-module taints are only set if the kernel is not already tainted
        (with that particular flag) => only the first offending module gets its
        taint info correctly updated
      
      Some additional changes:
      
      * 'license_gplok' is no longer needed - equivalent to !(taints &
        TAINT_PROPRIETARY_MODULE) - so we can drop it from struct module *
        exporting module taint info via /proc/module:
      
      pwc 88576 0 - Live 0xf8c32000
      evilmod 6784 1 pwc, Live 0xf8bbf000 (PF)
      Signed-off-by: NFlorin Malita <fmalita@gmail.com>
      Cc: "Randy.Dunlap" <rdunlap@xenotime.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fa3ba2e8
  20. 02 10月, 2006 1 次提交
    • R
      [PATCH] list module taint flags in Oops/panic · 2bc2d61a
      Randy Dunlap 提交于
      When listing loaded modules during an oops or panic, also list each
      module's Tainted flags if non-zero (P: Proprietary or F: Forced load only).
      
      If a module is did not taint the kernel, it is just listed like
      	usbcore
      but if it did taint the kernel, it is listed like
      	wizmodem(PF)
      
      Example:
      [ 3260.121718] Unable to handle kernel NULL pointer dereference at 0000000000000000 RIP:
      [ 3260.121729]  [<ffffffff8804c099>] :dump_test:proc_dump_test+0x99/0xc8
      [ 3260.121742] PGD fe8d067 PUD 264a6067 PMD 0
      [ 3260.121748] Oops: 0002 [1] SMP
      [ 3260.121753] CPU 1
      [ 3260.121756] Modules linked in: dump_test(P) snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device ide_cd generic ohci1394 snd_hda_intel snd_hda_codec snd_pcm snd_timer snd ieee1394 snd_page_alloc piix ide_core arcmsr aic79xx scsi_transport_spi usblp
      [ 3260.121785] Pid: 5556, comm: bash Tainted: P      2.6.18-git10 #1
      
      [Alternatively, I can look into listing tainted flags with 'lsmod',
      but that won't help in oopsen/panics so much.]
      
      [akpm@osdl.org: cleanup]
      Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2bc2d61a
  21. 30 9月, 2006 1 次提交
  22. 30 8月, 2006 1 次提交
    • J
      [SCSI] MODULE_FIRMWARE for binary firmware(s) · 187afbed
      Jon Masters 提交于
      Right now, various kernel modules are being migrated over to use
      request_firmware in order to pull in binary firmware blobs from userland
      when the module is loaded. This makes sense.
      
      However, there is right now little mechanism in place to automatically
      determine which binary firmware blobs must be included with a kernel in
      order to satisfy the prerequisites of these drivers. This affects
      vendors, but also regular users to a certain extent too.
      
      The attached patch introduces MODULE_FIRMWARE as a mechanism for
      advertising that a particular firmware file is to be loaded - it will
      then show up via modinfo and could be used e.g. when packaging a kernel.
      Signed-off-by: NJon Masters <jcm@redhat.com>
      
      Comments added in line with all the other MODULE_ tag
      Signed-off-by: NJames Bottomley <James.Bottomley@SteelEye.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      187afbed
  23. 15 7月, 2006 1 次提交
  24. 04 7月, 2006 1 次提交
  25. 29 6月, 2006 1 次提交
  26. 27 6月, 2006 1 次提交
  27. 23 6月, 2006 1 次提交
  28. 09 5月, 2006 1 次提交
  29. 26 4月, 2006 1 次提交
  30. 26 3月, 2006 1 次提交
  31. 25 3月, 2006 1 次提交
  32. 21 3月, 2006 2 次提交