1. 04 10月, 2008 1 次提交
    • M
      rtc: fix kernel panic on second use of SIGIO nofitication · 2e4a75cd
      Marcin Slusarz 提交于
      When userspace uses SIGIO notification and forgets to disable it before
      closing file descriptor, rtc->async_queue contains stale pointer to struct
      file.  When user space enables again SIGIO notification in different
      process, kernel dereferences this (poisoned) pointer and crashes.
      
      So disable SIGIO notification on close.
      
      Kernel panic:
      (second run of qemu (requires echo 1024 > /sys/class/rtc/rtc0/max_user_freq))
      
      general protection fault: 0000 [1] PREEMPT
      CPU 0
      Modules linked in: af_packet snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq usbhid tuner tea5767 tda8290 tuner_xc2028 xc5000 tda9887 tuner_simple tuner_types mt20xx tea5761 tda9875 uhci_hcd ehci_hcd usbcore bttv snd_via82xx snd_ac97_codec ac97_bus snd_pcm snd_timer ir_common compat_ioctl32 snd_page_alloc videodev v4l1_compat snd_mpu401_uart snd_rawmidi v4l2_common videobuf_dma_sg videobuf_core snd_seq_device snd btcx_risc soundcore tveeprom i2c_viapro
      Pid: 5781, comm: qemu-system-x86 Not tainted 2.6.27-rc6 #363
      RIP: 0010:[<ffffffff8024f891>]  [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f
      RSP: 0000:ffffffff80674cb8  EFLAGS: 00010002
      RAX: ffff8800224c62f0 RBX: 0000000000000046 RCX: 0000000000000002
      RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8800224c62f0
      RBP: ffffffff80674d08 R08: 0000000000000002 R09: 0000000000000001
      R10: ffffffff80238941 R11: 0000000000000001 R12: 0000000000000000
      R13: 6b6b6b6b6b6b6b6b R14: ffff88003a450080 R15: 0000000000000000
      FS:  00007f98b69516f0(0000) GS:ffffffff80623200(0000) knlGS:00000000f7cc86d0
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 0000000000a87000 CR3: 0000000022598000 CR4: 00000000000006e0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process qemu-system-x86 (pid: 5781, threadinfo ffff880028812000, task ffff88003a450080)
      Stack:  ffffffff80674cf8 0000000180238440 0000000200000002 0000000000000000
       ffff8800224c62f0 0000000000000046 0000000000000000 0000000000000002
       0000000000000002 0000000000000000 ffffffff80674d68 ffffffff8024fc7a
      Call Trace:
       <IRQ>  [<ffffffff8024fc7a>] lock_acquire+0x85/0xa9
       [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184
       [<ffffffff80491d1f>] _read_lock+0x3e/0x4a
       [<ffffffff8029cb62>] ? send_sigio+0x2a/0x184
       [<ffffffff8029cb62>] send_sigio+0x2a/0x184
       [<ffffffff8024fb97>] ? __lock_acquire+0x6e1/0x73f
       [<ffffffff8029cd4d>] ? kill_fasync+0x2c/0x4e
       [<ffffffff8029cd10>] __kill_fasync+0x54/0x65
       [<ffffffff8029cd5b>] kill_fasync+0x3a/0x4e
       [<ffffffff80402896>] rtc_update_irq+0x9c/0xa5
       [<ffffffff80404640>] cmos_interrupt+0xae/0xc0
       [<ffffffff8025d1c1>] handle_IRQ_event+0x25/0x5a
       [<ffffffff8025e5e4>] handle_edge_irq+0xdd/0x123
       [<ffffffff8020da34>] do_IRQ+0xe4/0x144
       [<ffffffff8020bad6>] ret_from_intr+0x0/0xf
       <EOI>  [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad
       [<ffffffff8033fe67>] ? clear_page_c+0x7/0x10
       [<ffffffff8026fc10>] ? get_page_from_freelist+0x385/0x450
       [<ffffffff8026fdc2>] ? __alloc_pages_internal+0xe7/0x3ad
       [<ffffffff80280aac>] ? anon_vma_prepare+0x2e/0xf6
       [<ffffffff80279400>] ? handle_mm_fault+0x227/0x6a5
       [<ffffffff80494716>] ? do_page_fault+0x494/0x83f
       [<ffffffff8049251d>] ? error_exit+0x0/0xa9
      
      Code: cc 41 39 45 28 74 24 e8 5e 1d 0f 00 85 c0 0f 84 6a 03 00 00 83 3d 8f a9 aa 00 00 be 47 03 00 00 0f 84 6a 02 00 00 e9 53 03 00 00 <41> ff 85 38 01 00 00 45 8b be 90 06 00 00 41 83 ff 2f 76 24 e8
      RIP  [<ffffffff8024f891>] __lock_acquire+0x3db/0x73f
       RSP <ffffffff80674cb8>
      ---[ end trace 431877d860448760 ]---
      Kernel panic - not syncing: Aiee, killing interrupt handler!
      Signed-off-by: NMarcin Slusarz <marcin.slusarz@gmail.com>
      Acked-by: NAlessandro Zummo <alessandro.zummo@towertech.it>
      Acked-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2e4a75cd
  2. 21 8月, 2008 1 次提交
  3. 13 8月, 2008 1 次提交
  4. 31 7月, 2008 2 次提交
  5. 25 7月, 2008 1 次提交
    • D
      rtc: remove BKL for ioctl() · 5ad31a57
      David Brownell 提交于
      Remove implicit use of BKL in ioctl() from the RTC framework.
      
      Instead, the rtc->ops_lock is used.  That's the same lock that already
      protects the RTC operations when they're issued through the exported
      rtc_*() calls in drivers/rtc/interface.c ...  making this a bugfix, not
      just a cleanup, since both ioctl calls and set_alarm() need to update IRQ
      enable flags and that implies a common lock (which RTC drivers as a rule
      do not provide on their own).
      
      A new comment at the declaration of "struct rtc_class_ops" summarizes
      current locking rules.  It's not clear to me that the exceptions listed
      there should exist ...  if not, those are pre-existing problems which can
      be fixed in a patch that doesn't relate to BKL removal.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Acked-by: NAlessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ad31a57
  6. 21 6月, 2008 1 次提交
  7. 07 2月, 2008 1 次提交
    • D
      rtc-cmos alarm acts as oneshot · 8a0bdfd7
      David Brownell 提交于
      Start making the rtc-cmos alarm act more like a oneshot alarm by disabling
      that alarm after its IRQ fires.  (ACPI hooks are also needed.)
      
      The Linux RTC framework has previously been a bit vague in this area, but
      any other behavior is problematic and not very portable.  RTCs with full
      YYYY-MM-DD HH:MM[:SS] alarms won't have a problem here.  Only ones with
      partial match criteria, with the most visible example being the PC RTC, get
      confused.  (Because the criteria will match repeatedly.)
      
      Update comments relating to that oneshot behavior and timezone handling.
      (Timezones are another issue that's mostly visible with rtc-cmos.  That's
      because PCs often dual-boot MS-Windows, which likes its RTC to match local
      wall-clock time instead of UTC.)
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Cc: Alessandro Zummo <a.zummo@towertech.it>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8a0bdfd7
  8. 06 12月, 2007 1 次提交
  9. 30 11月, 2007 1 次提交
  10. 17 10月, 2007 3 次提交
  11. 01 8月, 2007 1 次提交
  12. 18 7月, 2007 1 次提交
  13. 09 5月, 2007 5 次提交
  14. 13 2月, 2007 1 次提交
  15. 10 2月, 2007 1 次提交
  16. 14 12月, 2006 1 次提交
  17. 26 11月, 2006 2 次提交
  18. 22 11月, 2006 1 次提交
  19. 01 10月, 2006 3 次提交
  20. 26 6月, 2006 2 次提交
  21. 22 5月, 2006 1 次提交
  22. 02 5月, 2006 1 次提交
  23. 28 3月, 2006 1 次提交