1. 09 5月, 2007 3 次提交
  2. 03 5月, 2007 1 次提交
  3. 17 2月, 2007 1 次提交
  4. 08 2月, 2007 2 次提交
  5. 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
  6. 04 12月, 2006 1 次提交
  7. 02 12月, 2006 1 次提交
  8. 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
  9. 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
  10. 30 9月, 2006 1 次提交
  11. 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
  12. 15 7月, 2006 1 次提交
  13. 04 7月, 2006 1 次提交
  14. 29 6月, 2006 1 次提交
  15. 27 6月, 2006 1 次提交
  16. 23 6月, 2006 1 次提交
  17. 09 5月, 2006 1 次提交
  18. 26 4月, 2006 1 次提交
  19. 26 3月, 2006 1 次提交
  20. 25 3月, 2006 1 次提交
  21. 21 3月, 2006 2 次提交
  22. 31 10月, 2005 1 次提交
  23. 24 6月, 2005 1 次提交
    • M
      [PATCH] modules: add version and srcversion to sysfs · c988d2b2
      Matt Domsch 提交于
      This patch adds version and srcversion files to
      /sys/module/${modulename} containing the version and srcversion fields
      of the module's modinfo section (if present).
      
      /sys/module/e1000
      |-- srcversion
      `-- version
      
      This patch differs slightly from the version posted in January, as it
      now uses the new kstrdup() call in -mm.
      
      Why put this in sysfs?
      
      a) Tools like DKMS, which deal with changing out individual kernel
         modules without replacing the whole kernel, can behave smarter if they
         can tell the version of a given module.  The autoinstaller feature, for
         example, which determines if your system has a "good" version of a
         driver (i.e.  if the one provided by DKMS has a newer verson than that
         provided by the kernel package installed), and to automatically compile
         and install a newer version if DKMS has it but your kernel doesn't yet
         have that version.
      
      b) Because sysadmins manually, or with tools like DKMS, can switch out
         modules on the file system, you can't count on 'modinfo foo.ko', which
         looks at /lib/modules/${kernelver}/...  actually matching what is loaded
         into the kernel already.  Hence asking sysfs for this.
      
      c) as the unbind-driver-from-device work takes shape, it will be
         possible to rebind a driver that's built-in (no .ko to modinfo for the
         version) to a newly loaded module.  sysfs will have the
         currently-built-in version info, for comparison.
      
      d) tech support scripts can then easily grab the version info for what's
         running presently - a question I get often.
      
      There has been renewed interest in this patch on linux-scsi by driver
      authors.
      
      As the idea originated from GregKH, I leave his Signed-off-by: intact,
      though the implementation is nearly completely new.  Compiled and run on
      x86 and x86_64.
      
      From: Matthew Dobson <colpatch@us.ibm.com>
      
            build fix
      
      From: Thierry Vignaud <tvignaud@mandriva.com>
      
            build fix
      
      From: Matthew Dobson <colpatch@us.ibm.com>
      
            warning fix
      Signed-off-by: NGreg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: NMatt Domsch <Matt_Domsch@dell.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c988d2b2
  24. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4