linux-toradex.git/drivers/media/rc/lirc_dev.c, branch v4.9.120

lirc: fix dead lock between open and wakeup_filter

2017-12-14T08:28:17+00:00

[ Upstream commit db5b15b74ed9a5c04bb808d18ffa2c773f5c18c0 ]

The locking in lirc needs improvement, but for now just fix this potential
deadlock.

======================================================
[ INFO: possible circular locking dependency detected ]
4.10.0-rc1+ #1 Not tainted
-------------------------------------------------------
bash/2502 is trying to acquire lock:
 (ir_raw_handler_lock){+.+.+.}, at: [] ir_raw_encode_scancode+0x3e/0xb0 [rc_core]

               but task is already holding lock:
 (&dev->lock){+.+.+.}, at: [] store_filter+0x9f/0x240 [rc_core]

               which lock already depends on the new lock.

               the existing dependency chain (in reverse order) is:

               -> #2 (&dev->lock){+.+.+.}:

[] lock_acquire+0xfd/0x200
[] mutex_lock_nested+0x77/0x6d0
[] rc_open+0x2a/0x80 [rc_core]
[] lirc_dev_fop_open+0xda/0x1e0 [lirc_dev]
[] chrdev_open+0xb0/0x210
[] do_dentry_open+0x20a/0x2f0
[] vfs_open+0x4c/0x80
[] path_openat+0x5bc/0xc00
[] do_filp_open+0x91/0x100
[] do_sys_open+0x130/0x220
[] SyS_open+0x1e/0x20
[] entry_SYSCALL_64_fastpath+0x1f/0xc2
               -> #1 (lirc_dev_lock){+.+.+.}:
[] lock_acquire+0xfd/0x200
[] mutex_lock_nested+0x77/0x6d0
[] lirc_register_driver+0x67/0x59b [lirc_dev]
[] ir_lirc_register+0x1f4/0x260 [ir_lirc_codec]
[] ir_raw_handler_register+0x7c/0xb0 [rc_core]
[] 0xffffffffc0398010
[] do_one_initcall+0x52/0x1b0
[] do_init_module+0x5f/0x1fa
[] load_module+0x2675/0x2b00
[] SYSC_finit_module+0xdf/0x110
[] SyS_finit_module+0xe/0x10
[] do_syscall_64+0x6c/0x1f0
[] return_from_SYSCALL_64+0x0/0x7a
               -> #0 (ir_raw_handler_lock){+.+.+.}:
[] __lock_acquire+0x10f7/0x1290
[] lock_acquire+0xfd/0x200
[] mutex_lock_nested+0x77/0x6d0
[] ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
[] loop_set_wakeup_filter+0x62/0xbd [rc_loopback]
[] store_filter+0x1aa/0x240 [rc_core]
[] dev_attr_store+0x18/0x30
[] sysfs_kf_write+0x45/0x60
[] kernfs_fop_write+0x155/0x1e0
[] __vfs_write+0x37/0x160
[] vfs_write+0xc8/0x1e0
[] SyS_write+0x58/0xc0
[] entry_SYSCALL_64_fastpath+0x1f/0xc2

               other info that might help us debug this:

Chain exists of:
                 ir_raw_handler_lock --> lirc_dev_lock --> &dev->lock

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&dev->lock);
                               lock(lirc_dev_lock);
                               lock(&dev->lock);
  lock(ir_raw_handler_lock);

                *** DEADLOCK ***

4 locks held by bash/2502:
 #0:  (sb_writers#4){.+.+.+}, at: [] vfs_write+0x195/0x1e0
 #1:  (&of->mutex){+.+.+.}, at: [] kernfs_fop_write+0x11f/0x1e0
 #2:  (s_active#215){.+.+.+}, at: [] kernfs_fop_write+0x128/0x1e0
 #3:  (&dev->lock){+.+.+.}, at: [] store_filter+0x9f/0x240 [rc_core]

               stack backtrace:
CPU: 3 PID: 2502 Comm: bash Not tainted 4.10.0-rc1+ #1
Hardware name:                  /DG45ID, BIOS IDG4510H.86A.0135.2011.0225.1100 02/25/2011
Call Trace:
 dump_stack+0x86/0xc3
 print_circular_bug+0x1be/0x210
 __lock_acquire+0x10f7/0x1290
 lock_acquire+0xfd/0x200
 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 mutex_lock_nested+0x77/0x6d0
 ? ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 ? loop_set_wakeup_filter+0x44/0xbd [rc_loopback]
 ir_raw_encode_scancode+0x3e/0xb0 [rc_core]
 loop_set_wakeup_filter+0x62/0xbd [rc_loopback]
 ? loop_set_tx_duty_cycle+0x70/0x70 [rc_loopback]
 store_filter+0x1aa/0x240 [rc_core]
 dev_attr_store+0x18/0x30
 sysfs_kf_write+0x45/0x60
 kernfs_fop_write+0x155/0x1e0
 __vfs_write+0x37/0x160
 ? rcu_read_lock_sched_held+0x4a/0x80
 ? rcu_sync_lockdep_assert+0x2f/0x60
 ? __sb_start_write+0x10c/0x220
 ? vfs_write+0x195/0x1e0
 ? security_file_permission+0x3b/0xc0
 vfs_write+0xc8/0x1e0
 SyS_write+0x58/0xc0
 entry_SYSCALL_64_fastpath+0x1f/0xc2

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

lirc_dev: LIRC_{G,S}ET_REC_MODE do not work

2017-03-12T05:41:41+00:00

commit bd291208d7f5d6b2d6a033fee449a429230b06df upstream.

Since "273b902 [media] lirc_dev: use LIRC_CAN_REC() define" these
ioctls no longer work.

Signed-off-by: Sean Young 
Reviewed-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

[media] lirc_dev: use LIRC_CAN_REC() define to check if the device can receive

2016-07-13T18:29:03+00:00

The LIRC_CAN_REC() returns a boolean "flag & LIRC_CAN_REC_MASK"
to check whether the device can receive data.

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: fix potential segfault

2016-07-13T18:28:25+00:00

When opening or closing a lirc character device, the framework
provides to the user the possibility to keep track of opening or
closing of the device by calling two functions:

 - set_use_inc() when opening the device
 - set_use_dec() when closing the device

if those are not set by the lirc user, the system segfaults.
Check the pointer value before calling the above functions.

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: extremely trivial comment style fix

2016-07-13T18:27:16+00:00

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: fix error return value

2016-07-13T18:26:52+00:00

If ioctl is called, it cannot be a case of invalid system call
number (ENOSYS), that is a ENOTTY case which means that the
device doesn't support that specific ioctl command.

So, replace ENOSYS with ENOTTY.

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: fix variable constant comparisons

2016-07-13T18:25:41+00:00

When comparing a variable with a constant, the comparison should
start from the variable and not from the constant. It's also
written in the human DNA.

Swap the terms of comparisons whenever the constant comes first
and fix the following checkpatch warning:

  WARNING: Comparisons should place the constant on the right side of the test

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: merge three if statements in only one

2016-07-13T18:24:28+00:00

The three if statements check the same thing, merge them in only
one statement.

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: remove double if ... else statement

2016-07-13T18:09:05+00:00

There are two if ... else which check the same thing in different
part of the code, they can be merged in a single check.

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab

[media] lirc_dev: simplify if statement in lirc_add_to_buf

2016-07-13T18:06:29+00:00

The whole function is inside an 'if' statement
("if (ir->d.add_to_buf)").

Check the opposite of that statement at the beginning and exit,
this way we can have one level less of indentation.

Signed-off-by: Andi Shyti 
Signed-off-by: Mauro Carvalho Chehab