1. 04 3月, 2008 16 次提交
  2. 03 3月, 2008 17 次提交
  3. 02 3月, 2008 4 次提交
    • S
      firewire: fix crash in automatic module unloading · 855c603d
      Stefan Richter 提交于
      "modprobe firewire-ohci; sleep .1; modprobe -r firewire-ohci" used to
      result in crashes like this:
      
          BUG: unable to handle kernel paging request at ffffffff8807b455
          IP: [<ffffffff8807b455>]
          PGD 203067 PUD 207063 PMD 7c170067 PTE 0
          Oops: 0010 [1] PREEMPT SMP
          CPU 0
          Modules linked in: i915 drm cpufreq_ondemand acpi_cpufreq freq_table applesmc input_polldev led_class coretemp hwmon eeprom snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss button thermal processor sg snd_hda_intel snd_pcm snd_timer snd snd_page_alloc sky2 i2c_i801 rtc [last unloaded: crc_itu_t]
          Pid: 9, comm: events/0 Not tainted 2.6.25-rc2 #3
          RIP: 0010:[<ffffffff8807b455>]  [<ffffffff8807b455>]
          RSP: 0018:ffff81007dcdde88  EFLAGS: 00010246
          RAX: ffff81007dc95040 RBX: ffff81007dee5390 RCX: 0000000000005e13
          RDX: 0000000000008c8b RSI: 0000000000000001 RDI: ffff81007dee5388
          RBP: ffff81007dc5eb40 R08: 0000000000000002 R09: ffffffff8022d05c
          R10: ffffffff8023b34c R11: ffffffff8041a353 R12: ffff81007dee5388
          R13: ffffffff8807b455 R14: ffffffff80593bc0 R15: 0000000000000000
          FS:  0000000000000000(0000) GS:ffffffff8055a000(0000) knlGS:0000000000000000
          CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
          CR2: ffffffff8807b455 CR3: 0000000000201000 CR4: 00000000000006e0
          DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
          DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
          Process events/0 (pid: 9, threadinfo ffff81007dcdc000, task ffff81007dc95040)
          Stack:  ffffffff8023b396 ffffffff88082524 0000000000000000 ffffffff8807d9ae
          ffff81007dc5eb40 ffff81007dc9dce0 ffff81007dc5eb40 ffff81007dc5eb80
          ffff81007dc9dce0 ffffffffffffffff ffffffff8023be87 0000000000000000
          Call Trace:
          [<ffffffff8023b396>] ? run_workqueue+0xdf/0x1df
          [<ffffffff8023be87>] ? worker_thread+0xd8/0xe3
          [<ffffffff8023e917>] ? autoremove_wake_function+0x0/0x2e
          [<ffffffff8023bdaf>] ? worker_thread+0x0/0xe3
          [<ffffffff8023e813>] ? kthread+0x47/0x74
          [<ffffffff804198e0>] ? trace_hardirqs_on_thunk+0x35/0x3a
          [<ffffffff8020c008>] ? child_rip+0xa/0x12
          [<ffffffff8020b6e3>] ? restore_args+0x0/0x3d
          [<ffffffff8023e68a>] ? kthreadd+0x14c/0x171
          [<ffffffff8023e68a>] ? kthreadd+0x14c/0x171
          [<ffffffff8023e7cc>] ? kthread+0x0/0x74
          [<ffffffff8020bffe>] ? child_rip+0x0/0x12
      
          Code:  Bad RIP value.
          RIP  [<ffffffff8807b455>]
          RSP <ffff81007dcdde88>
          CR2: ffffffff8807b455
          ---[ end trace c7366c6657fe5bed ]---
      
      Note that this crash happened _after_ firewire-core was unloaded.  The
      shared workqueue tried to run firewire-core's device initialization jobs
      or similar jobs.
      
      The fix makes sure that firewire-ohci and hence firewire-core is not
      unloaded before all device shutdown jobs have been completed.  This is
      determined by the count of device initializations minus device releases.
      
      Also skip useless retries in the node initialization job if the node is
      to be shut down.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      855c603d
    • S
      firewire: potentially invalid pointers used in fw_card_bm_work · 15803478
      Stefan Richter 提交于
      The bus management workqueue job was in danger to dereference NULL
      pointers.  Also, after having temporarily lifted card->lock, a few node
      pointers and a device pointer may have become invalid.
      
      Add NULL pointer checks and get the necessary references.  Also, move
      card->local_node out of fw_card_bm_work's sight during shutdown of the
      card.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Signed-off-by: NJarod Wilson <jwilson@redhat.com>
      15803478
    • S
      firewire: fw-sbp2: better fix for NULL pointer dereference in scsi_remove_device · f8436158
      Stefan Richter 提交于
      Patch "firewire: fw-sbp2: fix NULL pointer deref. in scsi_remove_device"
      had the unintended effect that firewire-sbp2 could not be unloaded
      anymore until all SBP-2 devices were unplugged.
      
      We now fix the NULL pointer bug by reacquiring a reference to the sdev
      instead of holding a reference to the sdev (and to the module) all the
      time.
      Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>
      Tested-by: NJarod Wilson <jwilson@redhat.com>
      f8436158
    • U
      [ARM] Fix freeing of page tables for ARM in free_pgd_slow · 0c82d83c
      Uwe Kleine-König 提交于
      Since 2f569afd (CONFIG_HIGHPTE vs. sub-page page tables.) pte_free() calls
      pte_lock_deinit() and dec_zone_page_state().  So free_pgd_slow must not call
      the latter two when calling the first.
      Signed-off-by: NUwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      0c82d83c
  4. 01 3月, 2008 3 次提交
    • S
      [PATCH] drop EOE records from printk · 8d07a67c
      Steve Grubb 提交于
      Hi,
      
      While we are looking at the printk issue, I see that its printk'ing the EOE
      (end of event) records which is really not something that we need in syslog.
      Its really intended for the realtime audit event stream handled by the audit
      daemon. So, lets avoid printk'ing that record type.
      Signed-off-by: NSteve Grubb <sgrubb@redhat.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      8d07a67c
    • E
      [RFC] AUDIT: do not panic when printk loses messages · b29ee87e
      Eric Paris 提交于
      On the latest kernels if one was to load about 15 rules, set the failure
      state to panic, and then run service auditd stop the kernel will panic.
      This is because auditd stops, then the script deletes all of the rules.
      These deletions are sent as audit messages out of the printk kernel
      interface which is already known to be lossy.  These will overun the
      default kernel rate limiting (10 really fast messages) and will call
      audit_panic().  The same effect can happen if a slew of avc's come
      through while auditd is stopped.
      
      This can be fixed a number of ways but this patch fixes the problem by
      just not panicing if auditd is not running.  We know printk is lossy and
      if the user chooses to set the failure mode to panic and tries to use
      printk we can't make any promises no matter how hard we try, so why try?
      At least in this way we continue to get lost message accounting and will
      eventually know that things went bad.
      
      The other change is to add a new call to audit_log_lost() if auditd
      disappears.  We already pulled the skb off the queue and couldn't send
      it so that message is lost.  At least this way we will account for the
      last message and panic if the machine is configured to panic.  This code
      path should only be run if auditd dies for unforeseen reasons.  If
      auditd closes correctly audit_pid will get set to 0 and we won't walk
      this code path.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      b29ee87e
    • P
      [PATCH] Audit: Fix the format type for size_t variables · 422b03cf
      Paul Moore 提交于
      Fix the following compiler warning by using "%zu" as defined in C99.
      
        CC      kernel/auditsc.o
        kernel/auditsc.c: In function 'audit_log_single_execve_arg':
        kernel/auditsc.c:1074: warning: format '%ld' expects type 'long int', but
        argument 4 has type 'size_t'
      Signed-off-by: NPaul Moore <paul.moore@hp.com>
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      422b03cf