lkml.org 
[lkml]   [2017]   [Dec]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] rtc: ac100: Fix multiple race conditions
From
Date
Hi Alexandre,

On 04/12/2017 15:05, Alexandre Belloni wrote:
> The probe function is not allowed to fail after registering the RTC because
> the following may happen:
>
> CPU0: CPU1:
> sys_load_module()
> do_init_module()
> do_one_initcall()
> cmos_do_probe()
> rtc_device_register()
> __register_chrdev()
> cdev->owner = struct module*
> open("/dev/rtc0")
> rtc_device_unregister()
> module_put()
> free_module()
> module_free(mod->module_core)
> /* struct module *module is now
> freed */
> chrdev_open()
> spin_lock(cdev_lock)
> cdev_get()
> try_module_get()
> module_is_live()
> /* dereferences already
> freed struct module* */
>
> Also, the interrupt handler: ac100_rtc_irq() is dereferencing chip->rtc but
> this may still be NULL when it is called, resulting in:
> Unable to handle kernel NULL pointer dereference at virtual address 00000194
> pgd = (ptrval)
> [00000194] *pgd=00000000
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 72 Comm: irq/71-ac100-rt Not tainted 4.15.0-rc1-next-20171201-dirty #120
> Hardware name: Allwinner sun8i Family
> task: (ptrval) task.stack: (ptrval)
> PC is at mutex_lock+0x14/0x3c
> LR is at ac100_rtc_irq+0x38/0xc8
> pc : [<c06543a4>] lr : [<c04d9a2c>] psr: 60000053
> sp : ee9c9f28 ip : 00000000 fp : ee9adfdc
> r10: 00000000 r9 : c0a04c48 r8 : c015ed18
> r7 : ee9bd600 r6 : ee9c9f28 r5 : ee9af590 r4 : c0a04c48
> r3 : ef3cb3c0 r2 : 00000000 r1 : ee9af590 r0 : 00000194
> Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 4000406a DAC: 00000051
> Process irq/71-ac100-rt (pid: 72, stack limit = 0x(ptrval))
> Stack: (0xee9c9f28 to 0xee9ca000)
> 9f20: 00000000 7c2fd1be c015ed18 ee9adf40 ee9c0400 ee9c0400
> 9f40: ee9adf40 c015ed34 ee9c8000 ee9adf64 ee9c0400 c015f040 ee9adf80 00000000
> 9f60: c015ee24 7c2fd1be ee9adfc0 ee9adf80 00000000 ee9c8000 ee9adf40 c015eef4
> 9f80: ef1eba34 c0138f14 ee9c8000 ee9adf80 c0138df4 00000000 00000000 00000000
> 9fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
> 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
> [<c06543a4>] (mutex_lock) from [<c04d9a2c>] (ac100_rtc_irq+0x38/0xc8)
> [<c04d9a2c>] (ac100_rtc_irq) from [<c015ed34>] (irq_thread_fn+0x1c/0x54)
> [<c015ed34>] (irq_thread_fn) from [<c015f040>] (irq_thread+0x14c/0x214)
> [<c015f040>] (irq_thread) from [<c0138f14>] (kthread+0x120/0x150)
> [<c0138f14>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
>
> Solve both issues by moving to
> devm_rtc_allocate_device()/rtc_register_device()
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Tested-by: Quentin Schulz <quentin.schulz@free-electrons.com>

Thanks,
Quentin
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

\
 
 \ /
  Last update: 2017-12-04 15:26    [W:0.029 / U:17.604 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site