linux-stable.git/drivers/rtc/rtc-dev.c, branch linux-2.6.26.y

rtc: fix kernel panic on second use of SIGIO nofitication

2008-10-09T03:23:11+00:00

commit 2e4a75cdcb89ff53bb182dda3a6dcdc14befe007 upstream

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:[]  [] __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:
   [] lock_acquire+0x85/0xa9
 [] ? send_sigio+0x2a/0x184
 [] _read_lock+0x3e/0x4a
 [] ? send_sigio+0x2a/0x184
 [] send_sigio+0x2a/0x184
 [] ? __lock_acquire+0x6e1/0x73f
 [] ? kill_fasync+0x2c/0x4e
 [] __kill_fasync+0x54/0x65
 [] kill_fasync+0x3a/0x4e
 [] rtc_update_irq+0x9c/0xa5
 [] cmos_interrupt+0xae/0xc0
 [] handle_IRQ_event+0x25/0x5a
 [] handle_edge_irq+0xdd/0x123
 [] do_IRQ+0xe4/0x144
 [] ret_from_intr+0x0/0xf
   [] ? __alloc_pages_internal+0xe7/0x3ad
 [] ? clear_page_c+0x7/0x10
 [] ? get_page_from_freelist+0x385/0x450
 [] ? __alloc_pages_internal+0xe7/0x3ad
 [] ? anon_vma_prepare+0x2e/0xf6
 [] ? handle_mm_fault+0x227/0x6a5
 [] ? do_page_fault+0x494/0x83f
 [] ? 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  [] __lock_acquire+0x3db/0x73f
 RSP 
---[ end trace 431877d860448760 ]---
Kernel panic - not syncing: Aiee, killing interrupt handler!

Signed-off-by: Marcin Slusarz 
Acked-by: Alessandro Zummo 
Acked-by: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

rtc-cmos alarm acts as oneshot

2008-02-06T18:41:13+00:00

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: David Brownell 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

RTC: assure proper memory ordering with respect to RTC_DEV_BUSY flag

2007-12-05T17:21:18+00:00

We must make sure that the RTC_DEV_BUSY flag has proper lock semantics,
i.e.  that the RTC_DEV_BUSY stores clearing the flag don't get reordered
before the preceeding stores and loads and vice versa.

Spotted by Nick Piggin.

Signed-off-by: Jiri Kosina 
Cc: Nick Piggin 
Cc: David Brownell 
Acked-by: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

RTC: convert mutex to bitfield

2007-11-29T17:24:54+00:00

RTC code is using mutex to assure exclusive access to /dev/rtc.  This is
however wrong usage, as it leaves the mutex locked when returning into
userspace, which is unacceptable.

Convert rtc->char_lock into bit operation.

Signed-off-by: Jiri Kosina 
Acked-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: allow validated RTC_PIE_ON for non-root

2007-10-16T16:43:13+00:00

drivers/char/rtc.c allowed RTC_PIE_ON ioctls for non-root users, as long as
the current interval (set via RTC_IRQP_SET) is <= max_user_freq.  Allow
RTC_PIE_ON under the same conditions when /dev/rtc* is handled by the rtc
subsystem.

Signed-off-by: Bryan Kadzban 
Acked-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-dev: no need to convert file->private_data to rtc device

2007-10-16T16:43:13+00:00

In rtc-dev.c, when a rtc device is opened, file->private_data is already
attached with the rtc device pointer, so there is no need to call
to_rtc_device() to convert file->private_data to a rtc device pointer.

Acked-by: Alessandro Zummo 
Signed-off-by: Mark Zhan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

RTC: periodic irq fix

2007-10-16T16:43:13+00:00

Add kernel/kernel and kernel/user locking for the periodic irq feature of
the rtc class.

PIE ioctls are also supported.

Signed-off-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-dev: Make RTC driver return ENOTTY instead of ENOIOCTLCMD

2007-07-31T22:39:36+00:00

Prevent the RTC driver from returning ENOIOCTLCMD to userspace.

Signed-off-by: Thomas Hommel 
Acked-by: Alessandro Zummo 
Cc: David Brownell 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc-dev: return -ENOTTY in ioctl if irq_set_freq is not implemented by driver

2007-07-17T17:23:09+00:00

Signed-off-by: Hans-Christian Egtvedt 
Cc: Haavard Skinnemoen 
Cc: David Brownell 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

rtc: remove "RTC_ALM_SET mode" bugs

2007-05-08T18:15:19+00:00

This fixes a common glitch in how RTC drivers handle two "set alarm" modes,
by getting rid of the surprising/hidden one that was rarely implemented
correctly (and which could expose nonportable hardware-specific behavior).

The glitch comes from the /dev/rtcX logic implementing the legacy
RTC_ALM_SET (limited to 24 hours, needing RTC_AIE_ON) ioctl on top of the
RTC driver call providing access to the newer RTC_WKALM_SET (without those
limitations) by initializing the day/month/year fields to be invalid ...
that second mode.

Now, since few RTC drivers check those fields, and most hardware misbehaves
when faced with invalid date fields, many RTC drivers will set bogus alarm
times on those RTC_ALM_SET code paths.  (Several in-tree drivers have that
issue, and I also noticed it with code reviews on several new RTC drivers.)

This patch ensures that RTC drivers never see such invalid alarm fields, by
moving some logic out of rtc-omap into the RTC_ALM_SET code and adding an
explicit check (which will prevent the issue on other code paths).

Signed-off-by: David Brownell 
Cc: Scott Wood 
Cc: Alessandro Zummo 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds