kernel/linux.git/drivers/media/rc/lirc_dev.c, branch v4.11.5

Merge tag 'media/v4.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2017-03-09T23:50:56+00:00

Pull media fixes from Mauro Carvalho Chehab: "Media regression fixes: - serial_ir: fix a Kernel crash during boot on Kernel 4.11-rc1, due to an IRQ code called too early - other IR regression fixes at lirc and at the raw IR decoding - a deadlock fix at the RC nuvoton driver - fix another issue with DMA on stack at dw2102 driver There's an extra patch there that change a driver interface for the SoC VSP1 driver, with is shared between the DRM and V4L2 driver. The patch itself is trivial, and was acked by David Arlie" * tag 'media/v4.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: [media] v4l: vsp1: Adapt vsp1_du_setup_lif() interface to use a structure [media] dw2102: don't do DMA on stack [media] rc: protocol is not set on register for raw IR devices [media] rc: raw decoder for keymap protocol is not loaded on register [media] rc: nuvoton: fix deadlock in nvt_write_wakeup_codes [media] lirc: fix dead lock between open and wakeup_filter [media] serial_ir: ensure we're ready to receive interrupts

[media] lirc: fix dead lock between open and wakeup_filter

2017-03-03T10:06:57+00:00

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

sched/headers: Prepare to move signal wakeup & sigpending methods from into

2017-03-02T07:42:32+00:00

Fix up affected files that include this signal functionality via sched.h. Acked-by: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar

[media] lirc: cannot read from tx-only device

2017-02-03T16:23:36+00:00

Bail out early, otherwise we follow a null pointer. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

[media] lirc: fix null dereference for tx-only devices

2017-01-31T09:32:27+00:00

tx-only RC devices do not have a receive buffer. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

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

2017-01-30T13:52:28+00:00

Since "273b902 [media] lirc_dev: use LIRC_CAN_REC() define" these ioctls no longer work. Signed-off-by: Sean Young Cc: # v4.8+ Reviewed-by: Andi Shyti Signed-off-by: Mauro Carvalho Chehab

[media] media: Drop FSF's postal address from the source code files

2017-01-27T13:38:09+00:00

Drop the FSF's postal address from the source code files that typically contain mostly the license text. Of the 628 removed instances, 578 are outdated. The patch has been created with the following command without manual edits: git grep -l "675 Mass Ave\|59 Temple Place\|51 Franklin St" -- \ drivers/media/ include/media|while read i; do i=$i perl -e ' open(F,"< $ENV{i}"); $a=join("", ); $a =~ s/[ \t]*\*\n.*You should.*\n.*along with.*\n.*(\n.*USA.*$)?\n//m && $a =~ s/(^.*)Or, (point your browser to) /$1To obtain the license, $2\n$1/m; close(F); open(F, "> $ENV{i}"); print F $a; close(F);'; done Signed-off-by: Sakari Ailus

[media] lirc: fix error paths in lirc_cdev_add()

2016-12-01T14:46:00+00:00

"c77d17c0 [media] lirc: use-after free" introduces two problems: cdev_del() can be called with a NULL argument, and the kobject_put() path will cause a double free. Reported-by: Dan Carpenter Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

[media] lirc: use-after free while reading from device and unplugging

2016-11-21T15:28:11+00:00

Many lirc drivers have their own receive buffers which are freed on unplug (e.g. ir_lirc_unregister). This means that ir->buf->wait_poll will be freed directly after unplug so do not remove yourself from the wait queue. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab

[media] lirc: prevent use-after free

2016-11-21T15:19:56+00:00

If you unplug an lirc device while reading from it, you will get an use after free as the cdev is freed while still in use. Signed-off-by: Sean Young Signed-off-by: Mauro Carvalho Chehab