linux/drivers/rtc/rtc-dev.c, branch v2.6.28

saner FASYNC handling on file close

2008-11-01T16:49:46Z

As it is, all instances of ->release() for files that have ->fasync() need to remember to evict file from fasync lists; forgetting that creates a hole and we actually have a bunch that *does* forget. So let's keep our lives simple - let __fput() check FASYNC in file->f_flags and call ->fasync() there if it's been set. And lose that crap in ->release() instances - leaving it there is still valid, but we don't have to bother anymore. Signed-off-by: Al Viro Signed-off-by: Linus Torvalds

rtc: file close() consistently disables repeating irqs

2008-10-16T18:21:40Z

Make the rtc framework consistent about disabling 1/second update IRQs that may have been activated through the /dev interface, when that /dev file is closed. (It may have closed because of coredump, etc.) This was previously done only for emulated update IRQs ... now, do it always. Also comment the current policy: repeating IRQs (periodic, update) that userspace enabled will be cleanly disabled, but alarms are left alone. Such repeating IRQs are a constant and pointless system load. Update some RTC drivers to remove now-needless release() methods. Most such methods just enforce that policy. The others all seem to be buggy, and mistreat in-kernel clients of periodic or alarm IRQs. Signed-off-by: David Brownell Acked-by: Andrew Sharp Cc: Angelo Castello Acked-by: Atsushi Nemoto Acked-by: Paul Mundt Cc: Thomas Hommel Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

rtc: fix kernel panic on second use of SIGIO nofitication

2008-10-04T01:22:17Z

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

rtc: fix double lock on UIE emulation

2008-08-20T22:40:31Z

With commit 5ad31a575157147b43fa84ef1e21471661653878 ("rtc: remove BKL for ioctl()"), RTC_UIE_ON ioctl cause double lock on rtc->ops_lock. The ops_lock must not be held while set_uie() calls rtc_read_time() which takes the lock. Also clear_uie() does not need ops_lock. This patch fixes return value of RTC_UIE_OFF ioctl too. Signed-off-by: Atsushi Nemoto Cc: David Brownell Cc: Russell King Cc: Alessandro Zummo Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

revert "rtc: cdev lock_kernel() pushdown"

2008-08-12T23:07:28Z

Revert commit 51a776fa7a7997e726d4a478eda0854c6f9143bd ("rtc: cdev lock_kernel() pushdown"). The RTC framework does not need BKL protection. Signed-off-by: David Brownell Cc: Jonathan Corbet Cc: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

rtc-dev: stop periodic interrupts on device release

2008-07-30T16:41:47Z

Solves http://bugzilla.kernel.org/show_bug.cgi?id=11127 The old rtc.c driver did it and some drivers (like rtc-sh) do it in their release function, though they should not -- because they should provide the irq_set_state op and the rtc framework itself should care about it. This patch makes it do so. I am aware that some drivers, like rtc-sh, handle userspace PIE sets in their ioctl op (instead of having the framework call the op), exporting the irq_set_state op at the same time. The logic in rtc_irq_set_state should make sure it doesn't matter and the driver should not need to care stopping periodic interrupts in its release routine any more. The correct way, in my opinion, should be this: 1) The driver provides the irq_set_state op and does not care closing the interrupts in its release op. 2) If the driver does not provide the op and handles PIE in the ioctl op, it's reponsible for closing them in its release op. 3) Something similar for other IRQs, like UIE -- if there's no in-kernel API like irq_set_state, handle it in ioctl and release ops. The framework will be responsible either for everything or for nothing. (This will probably change later.) Signed-off-by: Tomas Janousek Acked-by: David Brownell Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

rtc: don't return -EBUSY when mutex_lock_interruptible() fails

2008-07-30T16:41:45Z

It was pointed out that the RTC framework handles its mutex locks oddly ... returning -EBUSY when interrupted. This fixes that by returning the value of mutex_lock_interruptible() (i.e. -EINTR). Signed-off-by: David Brownell Acked-by: Alessandro Zummo Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

rtc: remove BKL for ioctl()

2008-07-24T17:47:33Z

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

rtc: cdev lock_kernel() pushdown

2008-06-20T20:03:43Z

Signed-off-by: Jonathan Corbet

rtc-cmos alarm acts as oneshot

2008-02-06T18:41:13Z

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