Fix section 3.8 number #76

ruckuus · 2014-03-05T08:16:58Z

No description provided.

After commit bcdde7e (sysfs: make __sysfs_remove_dir() recursive) I'm seeing traces analogous to the one below in Thunderbolt testing: WARNING: CPU: 3 PID: 76 at /scratch/rafael/work/linux-pm/fs/sysfs/group.c:214 sysfs_remove_group+0x59/0xe0() sysfs group ffffffff81c6c500 not found for kobject '0000:08' Modules linked in: ... CPU: 3 PID: 76 Comm: kworker/u16:7 Not tainted 3.13.0-rc1+ torvalds#76 Hardware name: Acer Aspire S5-391/Venus , BIOS V1.02 05/29/2012 Workqueue: kacpi_hotplug acpi_hotplug_work_fn 0000000000000009 ffff8801644b9ac8 ffffffff816b23bf 0000000000000007 ffff8801644b9b18 ffff8801644b9b08 ffffffff81046607 ffff88016925b800 0000000000000000 ffffffff81c6c500 ffff88016924f928 ffff88016924f800 Call Trace: [<ffffffff816b23bf>] dump_stack+0x4e/0x71 [<ffffffff81046607>] warn_slowpath_common+0x87/0xb0 [<ffffffff810466d1>] warn_slowpath_fmt+0x41/0x50 [<ffffffff811e42ef>] ? sysfs_get_dirent_ns+0x6f/0x80 [<ffffffff811e5389>] sysfs_remove_group+0x59/0xe0 [<ffffffff8149f00b>] dpm_sysfs_remove+0x3b/0x50 [<ffffffff81495818>] device_del+0x58/0x1c0 [<ffffffff814959c8>] device_unregister+0x48/0x60 [<ffffffff813254fe>] pci_remove_bus+0x6e/0x80 [<ffffffff81325548>] pci_remove_bus_device+0x38/0x110 [<ffffffff8132555d>] pci_remove_bus_device+0x4d/0x110 [<ffffffff81325639>] pci_stop_and_remove_bus_device+0x19/0x20 [<ffffffff813418d0>] disable_slot+0x20/0xe0 [<ffffffff81341a38>] acpiphp_check_bridge+0xa8/0xd0 [<ffffffff813427ad>] hotplug_event+0x17d/0x220 [<ffffffff81342880>] hotplug_event_work+0x30/0x70 [<ffffffff8136d665>] acpi_hotplug_work_fn+0x18/0x24 [<ffffffff81061331>] process_one_work+0x261/0x450 [<ffffffff81061a7e>] worker_thread+0x21e/0x370 [<ffffffff81061860>] ? rescuer_thread+0x300/0x300 [<ffffffff81068342>] kthread+0xd2/0xe0 [<ffffffff81068270>] ? flush_kthread_worker+0x70/0x70 [<ffffffff816c19bc>] ret_from_fork+0x7c/0xb0 [<ffffffff81068270>] ? flush_kthread_worker+0x70/0x70 (Mika Westerberg sees them too in his tests). Some investigation documented in kernel bug #65281 led me to the conclusion that the source of the problem is the device_del() in pci_stop_dev() as it now causes the sysfs directory of the device to be removed recursively along with all of its subdirectories. That includes the sysfs directory of the device's subordinate bus (dev->subordinate) and its "power" group. Consequently, when pci_remove_bus() is called for dev->subordinate in pci_remove_bus_device(), it calls device_unregister(&bus->dev), but at this point the sysfs directory of bus->dev doesn't exist any more and its "power" group doesn't exist either. Thus, when dpm_sysfs_remove() called from device_del() tries to remove that group, it triggers the above warning. That indicates a logical mistake in the design of pci_stop_and_remove_bus_device(), which causes bus device objects to be left behind their parents (bridge device objects) and can be fixed by moving the device_del() from pci_stop_dev() into pci_destroy_dev(), so pci_remove_bus() can be called for the device's subordinate bus before the device itself is unregistered from the hierarchy. Still, the driver, if any, should be detached from the device in pci_stop_dev(), so use device_release_driver() directly from there. References: https://bugzilla.kernel.org/show_bug.cgi?id=65281#c6 Reported-by: Mika Westerberg <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>

After commit bcdde7e (sysfs: make __sysfs_remove_dir() recursive) I'm seeing traces analogous to the one below in Thunderbolt testing: WARNING: CPU: 3 PID: 76 at /scratch/rafael/work/linux-pm/fs/sysfs/group.c:214 sysfs_remove_group+0x59/0xe0() sysfs group ffffffff81c6c500 not found for kobject '0000:08' Modules linked in: ... CPU: 3 PID: 76 Comm: kworker/u16:7 Not tainted 3.13.0-rc1+ torvalds#76 Hardware name: Acer Aspire S5-391/Venus , BIOS V1.02 05/29/2012 Workqueue: kacpi_hotplug acpi_hotplug_work_fn 0000000000000009 ffff8801644b9ac8 ffffffff816b23bf 0000000000000007 ffff8801644b9b18 ffff8801644b9b08 ffffffff81046607 ffff88016925b800 0000000000000000 ffffffff81c6c500 ffff88016924f928 ffff88016924f800 Call Trace: [<ffffffff816b23bf>] dump_stack+0x4e/0x71 [<ffffffff81046607>] warn_slowpath_common+0x87/0xb0 [<ffffffff810466d1>] warn_slowpath_fmt+0x41/0x50 [<ffffffff811e42ef>] ? sysfs_get_dirent_ns+0x6f/0x80 [<ffffffff811e5389>] sysfs_remove_group+0x59/0xe0 [<ffffffff8149f00b>] dpm_sysfs_remove+0x3b/0x50 [<ffffffff81495818>] device_del+0x58/0x1c0 [<ffffffff814959c8>] device_unregister+0x48/0x60 [<ffffffff813254fe>] pci_remove_bus+0x6e/0x80 [<ffffffff81325548>] pci_remove_bus_device+0x38/0x110 [<ffffffff8132555d>] pci_remove_bus_device+0x4d/0x110 [<ffffffff81325639>] pci_stop_and_remove_bus_device+0x19/0x20 [<ffffffff813418d0>] disable_slot+0x20/0xe0 [<ffffffff81341a38>] acpiphp_check_bridge+0xa8/0xd0 [<ffffffff813427ad>] hotplug_event+0x17d/0x220 [<ffffffff81342880>] hotplug_event_work+0x30/0x70 [<ffffffff8136d665>] acpi_hotplug_work_fn+0x18/0x24 [<ffffffff81061331>] process_one_work+0x261/0x450 [<ffffffff81061a7e>] worker_thread+0x21e/0x370 [<ffffffff81061860>] ? rescuer_thread+0x300/0x300 [<ffffffff81068342>] kthread+0xd2/0xe0 [<ffffffff81068270>] ? flush_kthread_worker+0x70/0x70 [<ffffffff816c19bc>] ret_from_fork+0x7c/0xb0 [<ffffffff81068270>] ? flush_kthread_worker+0x70/0x70 (Mika Westerberg sees them too in his tests). Some investigation documented in kernel bug #65281 led me to the conclusion that the source of the problem is the device_del() in pci_stop_dev() as it now causes the sysfs directory of the device to be removed recursively along with all of its subdirectories. That includes the sysfs directory of the device's subordinate bus (dev->subordinate) and its "power" group. Consequently, when pci_remove_bus() is called for dev->subordinate in pci_remove_bus_device(), it calls device_unregister(&bus->dev), but at this point the sysfs directory of bus->dev doesn't exist any more and its "power" group doesn't exist either. Thus, when dpm_sysfs_remove() called from device_del() tries to remove that group, it triggers the above warning. That indicates a logical mistake in the design of pci_stop_and_remove_bus_device(), which causes bus device objects to be left behind their parents (bridge device objects) and can be fixed by moving the device_del() from pci_stop_dev() into pci_destroy_dev(), so pci_remove_bus() can be called for the device's subordinate bus before the device itself is unregistered from the hierarchy. Still, the driver, if any, should be detached from the device in pci_stop_dev(), so use device_release_driver() directly from there. References: https://bugzilla.kernel.org/show_bug.cgi?id=65281#c6 Reported-by: Mika Westerberg <[email protected]> Signed-off-by: Rafael J. Wysocki <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]>

WARNING: quoted string split across lines torvalds#60: FILE: fs/isofs/compress.c:163: " page idx = %d, bh idx = %d," + " avail_in = %ld," WARNING: quoted string split across lines torvalds#61: FILE: fs/isofs/compress.c:164: + " avail_in = %ld," + " avail_out = %ld\n", WARNING: missing space after return type torvalds#76: FILE: include/linux/decompress/bunzip2.h:5: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#77: FILE: include/linux/decompress/bunzip2.h:6: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#94: FILE: include/linux/decompress/generic.h:5: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#95: FILE: include/linux/decompress/generic.h:6: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#122: FILE: include/linux/decompress/inflate.h:5: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#123: FILE: include/linux/decompress/inflate.h:6: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#140: FILE: include/linux/decompress/unlz4.h:5: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#141: FILE: include/linux/decompress/unlz4.h:6: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#158: FILE: include/linux/decompress/unlzma.h:5: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#159: FILE: include/linux/decompress/unlzma.h:6: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#177: FILE: include/linux/decompress/unlzo.h:5: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#178: FILE: include/linux/decompress/unlzo.h:6: + long(*flush)(void*, unsigned long), WARNING: please, no spaces at the start of a line torvalds#210: FILE: include/linux/zlib.h:86: + uLong avail_in; /* number of bytes available at next_in */$ WARNING: please, no spaces at the start of a line torvalds#215: FILE: include/linux/zlib.h:90: + uLong avail_out; /* remaining free space at next_out */$ WARNING: __initdata should be placed after count torvalds#259: FILE: init/initramfs.c:177: +static __initdata unsigned long count; WARNING: __initdata should be placed after remains torvalds#268: FILE: init/initramfs.c:189: +static __initdata long remains; WARNING: missing space after return type torvalds#385: FILE: lib/decompress_bunzip2.c:679: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#386: FILE: lib/decompress_bunzip2.c:680: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#401: FILE: lib/decompress_bunzip2.c:747: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#402: FILE: lib/decompress_bunzip2.c:748: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#427: FILE: lib/decompress_inflate.c:37: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#428: FILE: lib/decompress_inflate.c:38: + long(*flush)(void*, unsigned long), WARNING: Unnecessary space before function pointer arguments torvalds#456: FILE: lib/decompress_unlz4.c:35: + long (*fill) (void *, unsigned long), WARNING: Unnecessary space before function pointer arguments torvalds#457: FILE: lib/decompress_unlz4.c:36: + long (*flush) (void *, unsigned long), WARNING: missing space after return type torvalds#479: FILE: lib/decompress_unlz4.c:179: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#480: FILE: lib/decompress_unlz4.c:180: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#529: FILE: lib/decompress_unlzma.c:283: + long(*flush)(void*, unsigned long); WARNING: missing space after return type torvalds#541: FILE: lib/decompress_unlzma.c:538: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#542: FILE: lib/decompress_unlzma.c:539: + long(*flush)(void*, unsigned long), WARNING: missing space after return type torvalds#557: FILE: lib/decompress_unlzma.c:671: + long(*fill)(void*, unsigned long), WARNING: missing space after return type torvalds#558: FILE: lib/decompress_unlzma.c:672: + long(*flush)(void*, unsigned long), WARNING: Unnecessary space before function pointer arguments torvalds#586: FILE: lib/decompress_unlzo.c:112: + long (*fill) (void *, unsigned long), WARNING: Unnecessary space before function pointer arguments torvalds#587: FILE: lib/decompress_unlzo.c:113: + long (*flush) (void *, unsigned long), total: 0 errors, 35 warnings, 479 lines checked ./patches/initramfs-support-initramfs-that-is-more-than-2g.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Yinghai Lu <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

WARNING: Missing a blank line after declarations torvalds#76: FILE: mm/zpool.c:79: + bool got = try_module_get(driver->owner); + spin_unlock(&drivers_lock); total: 0 errors, 1 warnings, 94 lines checked ./patches/mm-zpool-prevent-zbud-zsmalloc-from-unloading-when-used.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Dan Streetman <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

Elizafox · 2015-01-08T14:07:59Z

Useless. And Linus doesn't accept PR's, to add insult to injury.

swarren · 2015-01-09T04:41:29Z

Eliza, I would not say that fixing documentation is useless. That's a little demeaning.

FWIW, this bug is fixed upstream already by 49d063c "proc: show mnt_id in /proc/pid/fdinfo".

ERROR: code indent should use tabs where possible torvalds#76: FILE: mm/cma_debug.c:88: + int pages = val;$ WARNING: please, no spaces at the start of a line torvalds#76: FILE: mm/cma_debug.c:88: + int pages = val;$ ERROR: code indent should use tabs where possible torvalds#79: FILE: mm/cma_debug.c:91: + return cma_free_mem(cma, pages);$ WARNING: please, no spaces at the start of a line torvalds#79: FILE: mm/cma_debug.c:91: + return cma_free_mem(cma, pages);$ total: 2 errors, 2 warnings, 69 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-cma-release-trigger.patch has style problems, please review. If any of these errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Sasha Levin <[email protected]> Signed-off-by: Andrew Morton <[email protected]>

Oversun's MFC and CEC fixes

ARM64: hi6220: enable ldo21 by default

While disabling ConfigFS Android gadget, android_disconnect() calls kill_all_hid_devices(), if CONFIG_USB_CONFIGFS_F_ACC is enabled, to free the registered HIDs without checking whether the USB accessory device really exist or not. If USB accessory device doesn't exist then we run into following kernel panic: ----8<---- [ 136.724761] Unable to handle kernel NULL pointer dereference at virtual address 00000064 [ 136.724809] pgd = c0204000 [ 136.731924] [00000064] *pgd=00000000 [ 136.737830] Internal error: Oops: 5 [#1] SMP ARM [ 136.738108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-rc4-00400-gf75300e-dirty torvalds#76 [ 136.742788] task: c0fb19d8 ti: c0fa4000 task.ti: c0fa4000 [ 136.750890] PC is at _raw_spin_lock_irqsave+0x24/0x60 [ 136.756246] LR is at kill_all_hid_devices+0x24/0x114 ---->8---- This patch adds a test to check if USB Accessory device exists before freeing HIDs. Change-Id: Ie229feaf0de3f4f7a151fcaa9a994e34e15ff73b Signed-off-by: Amit Pundir <[email protected]>

@offset

I've observed various spew (KASAN, warnings, oopses, etc.) that seem to stem from incorrect cloning of dccp_sock in dccp_create_openreq_child(). The problem is that struct dccp_sock's ->dccps_hc_rx_ackvec, ->dccps_hc_rx_ccid, and ->dccps_hc_tx_ccid members are pointers to memory which is not reference counted and not protected by any locks, so sharing them between original sock and the clone seems like a bad idea. The usual symptom would be a use-after-free which happens when an operation on the original sock causes any of these pointers to be freed followed by an operation on the cloned sock: ================================================================== BUG: KASAN: use-after-free in dccp_sync_mss+0x45/0x160 at addr ffff880012c65780 Read of size 8 by task a.out/987 ============================================================================= BUG ccid2_hc_tx_sock (Tainted: G W ): kasan: bad access detected ----------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Allocated in ccid_new+0x1b4/0x270 age=64589 cpu=0 pid=986 ___slab_alloc+0x724/0x810 __slab_alloc.isra.49+0x86/0xc0 kmem_cache_alloc+0x25a/0x2d0 ccid_new+0x1b4/0x270 dccp_hdlr_ccid+0x26/0xe0 __dccp_feat_activate+0xc3/0x180 dccp_feat_activate_values+0x2fa/0x4c0 dccp_rcv_state_process+0x814/0xa80 dccp_v4_do_rcv+0x6a/0x100 release_sock+0x168/0x330 inet_stream_connect+0x6d/0x90 SYSC_connect+0x1d0/0x200 SyS_connect+0x11/0x20 entry_SYSCALL_64_fastpath+0x12/0x71 INFO: Freed in ccid_hc_tx_delete+0x7d/0x90 age=11330 cpu=1 pid=989 __slab_free+0x1f0/0x360 kmem_cache_free+0x2b6/0x300 ccid_hc_tx_delete+0x7d/0x90 dccp_hdlr_ccid+0x65/0xe0 __dccp_feat_activate+0xc3/0x180 dccp_feat_activate_values+0x2fa/0x4c0 dccp_create_openreq_child+0x1fc/0x290 dccp_v4_request_recv_sock+0x67/0x430 dccp_check_req+0x248/0x330 dccp_v4_rcv+0x2a8/0xd50 ip_local_deliver_finish+0x160/0x4c0 ip_local_deliver+0x175/0x230 ip_rcv_finish+0x119/0x750 ip_rcv+0x678/0x960 __netif_receive_skb_core+0xe64/0x1810 __netif_receive_skb+0x41/0xf0 INFO: Slab 0xffffea00004b1800 objects=20 used=9 fp=0xffff880012c644c0 flags=0x100000000004080 INFO: Object 0xffff880012c65780 @offset=22400 fp=0xffff880012c60c80 [...] CPU: 0 PID: 987 Comm: a.out Tainted: G B W 4.4.0-rc5+ torvalds#76 ffffea00004b1800 ffff88001304fa40 ffffffff8169ed5b ffff88001422e800 ffff88001304fa70 ffffffff812e36ec ffff88001422e800 ffffea00004b1800 ffff880012c65780 000000000000ffff ffff88001304fa98 ffffffff812e946f Call Trace: [<ffffffff8169ed5b>] dump_stack+0x8d/0xe2 [<ffffffff812e36ec>] print_trailer+0x13c/0x1b0 [<ffffffff812e946f>] object_err+0x3f/0x50 [<ffffffff812f02c3>] kasan_report_error+0x2e3/0x6e0 [<ffffffff8108d321>] ? kvm_clock_get_cycles+0x11/0x20 [<ffffffff81e8fb33>] ? secure_dccp_sequence_number+0x133/0x1d0 [<ffffffff812f0704>] kasan_report+0x44/0x50 [<ffffffff82207155>] ? dccp_sync_mss+0x45/0x160 [<ffffffff812ef403>] __asan_load8+0x93/0xe0 [<ffffffff82207155>] dccp_sync_mss+0x45/0x160 [<ffffffff822080df>] dccp_connect+0x7f/0x2a0 [<ffffffff82217632>] dccp_v4_connect+0x612/0x960 [<ffffffff81ff20a7>] __inet_stream_connect+0x1d7/0x6a0 [<ffffffff8110438b>] ? preempt_count_sub+0x1b/0x170 [<ffffffff824cd007>] ? _raw_spin_unlock_irqrestore+0x47/0x90 [<ffffffff81ff1ed0>] ? inet_sendpage+0x200/0x200 [<ffffffff811302c1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [<ffffffff8110438b>] ? preempt_count_sub+0x1b/0x170 [<ffffffff810baa41>] ? __local_bh_enable_ip+0x61/0x110 [<ffffffff81ff25c1>] inet_stream_connect+0x51/0x90 [<ffffffff81e671a0>] SYSC_connect+0x1d0/0x200 [<ffffffff81ff2570>] ? __inet_stream_connect+0x6a0/0x6a0 [<ffffffff81e66fd0>] ? ___sys_recvmsg+0x3d0/0x3d0 [<ffffffff81384490>] ? SyS_epoll_create+0x1a0/0x1a0 [<ffffffff813372e5>] ? __fget+0x115/0x180 [<ffffffff8133739d>] ? __fget_light+0x4d/0xf0 [<ffffffff813822e0>] ? ep_poll_wakeup_proc+0x30/0x30 [<ffffffff81e69e71>] SyS_connect+0x11/0x20 [<ffffffff824cdd6e>] entry_SYSCALL_64_fastpath+0x12/0x71 I'm not really sure if setting them to NULL is really the correct solution -- maybe we should try to duplicate the pointed-to memory instead? Anyway, this is a tentative patch that explains the issue and fixes this particular problem -- dccp fuzzing now runs for minutes rather than seconds before encountering a crash. I haven't tested any real world workloads on this patch. Signed-off-by: Vegard Nossum <[email protected]>

Fixed compilation for linux kernel < 3.3.0

While disabling ConfigFS Android gadget, android_disconnect() calls kill_all_hid_devices(), if CONFIG_USB_CONFIGFS_F_ACC is enabled, to free the registered HIDs without checking whether the USB accessory device really exist or not. If USB accessory device doesn't exist then we run into following kernel panic: ----8<---- [ 136.724761] Unable to handle kernel NULL pointer dereference at virtual address 00000064 [ 136.724809] pgd = c0204000 [ 136.731924] [00000064] *pgd=00000000 [ 136.737830] Internal error: Oops: 5 [#1] SMP ARM [ 136.738108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-rc4-00400-gf75300e-dirty torvalds#76 [ 136.742788] task: c0fb19d8 ti: c0fa4000 task.ti: c0fa4000 [ 136.750890] PC is at _raw_spin_lock_irqsave+0x24/0x60 [ 136.756246] LR is at kill_all_hid_devices+0x24/0x114 ---->8---- This patch adds a test to check if USB Accessory device exists before freeing HIDs. Change-Id: Ie229feaf0de3f4f7a151fcaa9a994e34e15ff73b Signed-off-by: Amit Pundir <[email protected]>

This string is used by dump_stack and as we now support more SoC's than just STiH415/6 it is misleading to have the current string in the stack trace. This patch updates it to be more generic for the STi family of SoCs. So instead of looking like this [ 271.672555] Hardware name: STiH415/416 SoC with Flattened Device Tree [ 271.678998] [<c0310490>] (unwind_backtrace) from [<c030bb54>] (show_stack+0x10/0x14) [ 271.686746] [<c030bb54>] (show_stack) from [<c058bc4c>] (dump_stack+0x98/0xac) [snip] it now looks like this: [ 2.669879] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3-00026-g38a1ce6-dirty torvalds#76 [ 2.677973] Hardware name: STi SoC with Flattened Device Tree [ 2.683723] [<c0310490>] (unwind_backtrace) from [<c030bb54>] (show_stack+0x10/0x14) [ 2.691472] [<c030bb54>] (show_stack) from [<c058bc0c>] (dump_stack+0x98/0xac) [snip] Signed-off-by: Peter Griffin <[email protected]>

While disabling ConfigFS Android gadget, android_disconnect() calls kill_all_hid_devices(), if CONFIG_USB_CONFIGFS_F_ACC is enabled, to free the registered HIDs without checking whether the USB accessory device really exist or not. If USB accessory device doesn't exist then we run into following kernel panic: ----8<---- [ 136.724761] Unable to handle kernel NULL pointer dereference at virtual address 00000064 [ 136.724809] pgd = c0204000 [ 136.731924] [00000064] *pgd=00000000 [ 136.737830] Internal error: Oops: 5 [linaro-swg#1] SMP ARM [ 136.738108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-rc4-00400-gf75300e-dirty linaro-swg#76 [ 136.742788] task: c0fb19d8 ti: c0fa4000 task.ti: c0fa4000 [ 136.750890] PC is at _raw_spin_lock_irqsave+0x24/0x60 [ 136.756246] LR is at kill_all_hid_devices+0x24/0x114 ---->8---- This patch adds a test to check if USB Accessory device exists before freeing HIDs. Change-Id: Ie229feaf0de3f4f7a151fcaa9a994e34e15ff73b Signed-off-by: Amit Pundir <[email protected]>

This string is used by dump_stack and as we now support more SoC's than just STiH415/6 it is misleading to have the current string in the stack trace. This patch updates it to be more generic for the STi family of SoCs. So instead of looking like this [ 271.672555] Hardware name: STiH415/416 SoC with Flattened Device Tree [ 271.678998] [<c0310490>] (unwind_backtrace) from [<c030bb54>] (show_stack+0x10/0x14) [ 271.686746] [<c030bb54>] (show_stack) from [<c058bc4c>] (dump_stack+0x98/0xac) [snip] it now looks like this: [ 2.669879] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc3-00026-g38a1ce6-dirty torvalds#76 [ 2.677973] Hardware name: STi SoC with Flattened Device Tree [ 2.683723] [<c0310490>] (unwind_backtrace) from [<c030bb54>] (show_stack+0x10/0x14) [ 2.691472] [<c030bb54>] (show_stack) from [<c058bc0c>] (dump_stack+0x98/0xac) [snip] Signed-off-by: Peter Griffin <[email protected]> Acked-by: Patrice Chotard <[email protected]>

This commit fixes a stack corruption in the pseries specific code dealing with the huge pages. In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments to the hypervisor is not large enough. This leads to a stack corruption where a previously saved register could be corrupted leading to unexpected result in the caller, like the following panic: Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA pSeries Modules linked in: virtio_balloon ip_tables x_tables autofs4 virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 torvalds#76 task: c000000005394880 task.stack: c000000005570000 NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000 REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 84822884 XER: 20000000 CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1 GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964 GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104 GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5 GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000 GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000 GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000 GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964 GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0 NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470 LR [c00000000027bf64] zap_huge_pmd+0x44/0x470 Call Trace: [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable) [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0 [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120 [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0 [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0 [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0 [c000000005573e30] [c000000000009560] system_call+0x38/0x108 Instruction dump: fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1 7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378 Most of the time, the bug is surfacing in a caller up in the stack from __pSeries_lpar_hugepage_invalidate() which is quite confusing. This bug is pending since v3.11 but was hidden if a caller of the caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped register (r18 in this case) in the stack and is not using it until restoring it. GCC 6.2.0 seems to raise it more frequently. This commit also change the definition of the parameter buffer in pSeries_lpar_flush_hash_range() to rely on the global define PLPAR_HCALL9_BUFSIZE (no functional change here). Fixes: 1a52728 ("powerpc: Optimize hugepage invalidate") Cc: <[email protected]> Cc: Aneesh Kumar K.V <[email protected]> Signed-off-by: Laurent Dufour <[email protected]>

This commit fixes a stack corruption in the pseries specific code dealing with the huge pages. In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments to the hypervisor is not large enough. This leads to a stack corruption where a previously saved register could be corrupted leading to unexpected result in the caller, like the following panic: Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA pSeries Modules linked in: virtio_balloon ip_tables x_tables autofs4 virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 torvalds#76 task: c000000005394880 task.stack: c000000005570000 NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000 REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 84822884 XER: 20000000 CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1 GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964 GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104 GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5 GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000 GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000 GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000 GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964 GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0 NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470 LR [c00000000027bf64] zap_huge_pmd+0x44/0x470 Call Trace: [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable) [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0 [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120 [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0 [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0 [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0 [c000000005573e30] [c000000000009560] system_call+0x38/0x108 Instruction dump: fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1 7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378 Most of the time, the bug is surfacing in a caller up in the stack from __pSeries_lpar_hugepage_invalidate() which is quite confusing. This bug is pending since v3.11 but was hidden if a caller of the caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped register (r18 in this case) in the stack and is not using it until restoring it. GCC 6.2.0 seems to raise it more frequently. This commit also change the definition of the parameter buffer in pSeries_lpar_flush_hash_range() to rely on the global define PLPAR_HCALL9_BUFSIZE (no functional change here). Fixes: 1a52728 ("powerpc: Optimize hugepage invalidate") Cc: [email protected] # v3.11+ Signed-off-by: Laurent Dufour <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Acked-by: Balbir Singh <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>

commit 05af40e upstream. This commit fixes a stack corruption in the pseries specific code dealing with the huge pages. In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments to the hypervisor is not large enough. This leads to a stack corruption where a previously saved register could be corrupted leading to unexpected result in the caller, like the following panic: Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2048 NUMA pSeries Modules linked in: virtio_balloon ip_tables x_tables autofs4 virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 torvalds#76 task: c000000005394880 task.stack: c000000005570000 NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000 REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0) MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 84822884 XER: 20000000 CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1 GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964 GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104 GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5 GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000 GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000 GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000 GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964 GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0 NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470 LR [c00000000027bf64] zap_huge_pmd+0x44/0x470 Call Trace: [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable) [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0 [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120 [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0 [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0 [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0 [c000000005573e30] [c000000000009560] system_call+0x38/0x108 Instruction dump: fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1 7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378 Most of the time, the bug is surfacing in a caller up in the stack from __pSeries_lpar_hugepage_invalidate() which is quite confusing. This bug is pending since v3.11 but was hidden if a caller of the caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped register (r18 in this case) in the stack and is not using it until restoring it. GCC 6.2.0 seems to raise it more frequently. This commit also change the definition of the parameter buffer in pSeries_lpar_flush_hash_range() to rely on the global define PLPAR_HCALL9_BUFSIZE (no functional change here). Fixes: 1a52728 ("powerpc: Optimize hugepage invalidate") Signed-off-by: Laurent Dufour <[email protected]> Reviewed-by: Aneesh Kumar K.V <[email protected]> Acked-by: Balbir Singh <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Signed-off-by: Greg Kroah-Hartman <[email protected]>

While disabling ConfigFS Android gadget, android_disconnect() calls kill_all_hid_devices(), if CONFIG_USB_CONFIGFS_F_ACC is enabled, to free the registered HIDs without checking whether the USB accessory device really exist or not. If USB accessory device doesn't exist then we run into following kernel panic: ----8<---- [ 136.724761] Unable to handle kernel NULL pointer dereference at virtual address 00000064 [ 136.724809] pgd = c0204000 [ 136.731924] [00000064] *pgd=00000000 [ 136.737830] Internal error: Oops: 5 [#1] SMP ARM [ 136.738108] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.18.0-rc4-00400-gf75300e-dirty torvalds#76 [ 136.742788] task: c0fb19d8 ti: c0fa4000 task.ti: c0fa4000 [ 136.750890] PC is at _raw_spin_lock_irqsave+0x24/0x60 [ 136.756246] LR is at kill_all_hid_devices+0x24/0x114 ---->8---- This patch adds a test to check if USB Accessory device exists before freeing HIDs. Change-Id: Ie229feaf0de3f4f7a151fcaa9a994e34e15ff73b Signed-off-by: Amit Pundir <[email protected]>

When CONFIG_DEBUG_NET_SMALL_RTNL is off, rtnl_net_dereference() is the static inline wrapper of rtnl_dereference() returning a plain (void *) pointer to make sure net is always evaluated as requested in [0]. But, it makes sparse complain [1] when the pointer has __rcu annotation: net/ipv4/devinet.c:674:47: sparse: warning: incorrect type in argument 2 (different address spaces) net/ipv4/devinet.c:674:47: sparse: expected void *p net/ipv4/devinet.c:674:47: sparse: got struct in_ifaddr [noderef] __rcu * Also, if we evaluate net as (void *) in a macro, then the compiler in turn fails to build due to -Werror=unused-value. #define rtnl_net_dereference(net, p) \ ({ \ (void *)net; \ rtnl_dereference(p); \ }) net/ipv4/devinet.c: In function ‘inet_rtm_deladdr’: ./include/linux/rtnetlink.h:154:17: error: statement with no effect [-Werror=unused-value] 154 | (void *)net; \ net/ipv4/devinet.c:674:21: note: in expansion of macro ‘rtnl_net_dereference’ 674 | (ifa = rtnl_net_dereference(net, *ifap)) != NULL; | ^~~~~~~~~~~~~~~~~~~~ Let's go back to the original simplest macro. Note that checkpatch complains about this approach, but it's one-shot and less noisy than the other two. WARNING: Argument 'net' is not used in function-like macro torvalds#76: FILE: include/linux/rtnetlink.h:142: +#define rtnl_net_dereference(net, p) \ + rtnl_dereference(p) Fixes: 844e5e7 ("rtnetlink: Add assertion helpers for per-netns RTNL.") Link: https://lore.kernel.org/netdev/[email protected]/ [0] Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ [1] Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: NipaLocal <nipa@local>

…syscall The following kernel splat was found when running the Xenomai 3 testsuite in compat on dovetail enabled kernels: [ 513.620975] IRQ pipeline: some code running in oob context 'Xenomai' called an in-band only routine [ 513.620998] CPU: 0 PID: 510 Comm: smokey Not tainted 6.10.0+ torvalds#76 [ 513.621003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 513.621005] IRQ stage: Xenomai [ 513.621007] Call Trace: [ 513.621011] <TASK> [ 513.621015] dump_stack_lvl+0x6f/0xd0 [ 513.621202] __inband_irq_enable+0xb/0x60 [ 513.621249] do_int80_emulation+0x68/0x160 [ 513.621265] asm_int80_emulation+0x1a/0x20 [ 513.621285] RIP: 0023:0xf7f692ba [ 513.621288] Code: Unable to access opcode bytes at 0xf7f69290. [ 513.621303] RSP: 002b:00000000ffeedf40 EFLAGS: 00000282 ORIG_RAX: 0000000000000127 [ 513.621307] RAX: ffffffffffffffda RBX: 00000000ffffff9c RCX: 00000000ffeedfa0 [ 513.621309] RDX: 0000000000088000 RSI: 0000000000000000 RDI: 00000000f7f7aff4 [ 513.621311] RBP: 00000000ffeedf88 R08: 0000000000000000 R09: 0000000000000000 [ 513.621313] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 513.621315] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 513.621319] </TASK> When entering the low level entry code from the out-of-band stage the in-band IRQ state was changed. That is now avoided by calling syscall_enter_from_user_enable_irqs() as all other entry points do. Signed-off-by: Florian Bezdeka <[email protected]>

When CONFIG_DEBUG_NET_SMALL_RTNL is off, rtnl_net_dereference() is the static inline wrapper of rtnl_dereference() returning a plain (void *) pointer to make sure net is always evaluated as requested in [0]. But, it makes sparse complain [1] when the pointer has __rcu annotation: net/ipv4/devinet.c:674:47: sparse: warning: incorrect type in argument 2 (different address spaces) net/ipv4/devinet.c:674:47: sparse: expected void *p net/ipv4/devinet.c:674:47: sparse: got struct in_ifaddr [noderef] __rcu * Also, if we evaluate net as (void *) in a macro, then the compiler in turn fails to build due to -Werror=unused-value. #define rtnl_net_dereference(net, p) \ ({ \ (void *)net; \ rtnl_dereference(p); \ }) net/ipv4/devinet.c: In function ‘inet_rtm_deladdr’: ./include/linux/rtnetlink.h:154:17: error: statement with no effect [-Werror=unused-value] 154 | (void *)net; \ net/ipv4/devinet.c:674:21: note: in expansion of macro ‘rtnl_net_dereference’ 674 | (ifa = rtnl_net_dereference(net, *ifap)) != NULL; | ^~~~~~~~~~~~~~~~~~~~ Let's go back to the original simplest macro. Note that checkpatch complains about this approach, but it's one-shot and less noisy than the other two. WARNING: Argument 'net' is not used in function-like macro torvalds#76: FILE: include/linux/rtnetlink.h:142: +#define rtnl_net_dereference(net, p) \ + rtnl_dereference(p) Fixes: 844e5e7 ("rtnetlink: Add assertion helpers for per-netns RTNL.") Link: https://lore.kernel.org/netdev/[email protected]/ [0] Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ [1] Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: NipaLocal <nipa@local>

When CONFIG_DEBUG_NET_SMALL_RTNL is off, rtnl_net_dereference() is the static inline wrapper of rtnl_dereference() returning a plain (void *) pointer to make sure net is always evaluated as requested in [0]. But, it makes sparse complain [1] when the pointer has __rcu annotation: net/ipv4/devinet.c:674:47: sparse: warning: incorrect type in argument 2 (different address spaces) net/ipv4/devinet.c:674:47: sparse: expected void *p net/ipv4/devinet.c:674:47: sparse: got struct in_ifaddr [noderef] __rcu * Also, if we evaluate net as (void *) in a macro, then the compiler in turn fails to build due to -Werror=unused-value. #define rtnl_net_dereference(net, p) \ ({ \ (void *)net; \ rtnl_dereference(p); \ }) net/ipv4/devinet.c: In function ‘inet_rtm_deladdr’: ./include/linux/rtnetlink.h:154:17: error: statement with no effect [-Werror=unused-value] 154 | (void *)net; \ net/ipv4/devinet.c:674:21: note: in expansion of macro ‘rtnl_net_dereference’ 674 | (ifa = rtnl_net_dereference(net, *ifap)) != NULL; | ^~~~~~~~~~~~~~~~~~~~ Let's go back to the original simplest macro. Note that checkpatch complains about this approach, but it's one-shot and less noisy than the other two. WARNING: Argument 'net' is not used in function-like macro torvalds#76: FILE: include/linux/rtnetlink.h:142: +#define rtnl_net_dereference(net, p) \ + rtnl_dereference(p) Fixes: 844e5e7 ("rtnetlink: Add assertion helpers for per-netns RTNL.") Link: https://lore.kernel.org/netdev/[email protected]/ [0] Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ [1] Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Simon Horman <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>

…syscall The following kernel splat was found when running the Xenomai 3 testsuite in compat on dovetail enabled kernels: [ 513.620975] IRQ pipeline: some code running in oob context 'Xenomai' called an in-band only routine [ 513.620998] CPU: 0 PID: 510 Comm: smokey Not tainted 6.10.0+ torvalds#76 [ 513.621003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 513.621005] IRQ stage: Xenomai [ 513.621007] Call Trace: [ 513.621011] <TASK> [ 513.621015] dump_stack_lvl+0x6f/0xd0 [ 513.621202] __inband_irq_enable+0xb/0x60 [ 513.621249] do_int80_emulation+0x68/0x160 [ 513.621265] asm_int80_emulation+0x1a/0x20 [ 513.621285] RIP: 0023:0xf7f692ba [ 513.621288] Code: Unable to access opcode bytes at 0xf7f69290. [ 513.621303] RSP: 002b:00000000ffeedf40 EFLAGS: 00000282 ORIG_RAX: 0000000000000127 [ 513.621307] RAX: ffffffffffffffda RBX: 00000000ffffff9c RCX: 00000000ffeedfa0 [ 513.621309] RDX: 0000000000088000 RSI: 0000000000000000 RDI: 00000000f7f7aff4 [ 513.621311] RBP: 00000000ffeedf88 R08: 0000000000000000 R09: 0000000000000000 [ 513.621313] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 513.621315] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 513.621319] </TASK> When entering the low level entry code from the out-of-band stage the in-band IRQ state was changed. That is now avoided by calling syscall_enter_from_user_enable_irqs() as all other entry points do. Signed-off-by: Florian Bezdeka <[email protected]>

Fix section 3.8 number

a4a39c7

tobetter pushed a commit to tobetter/linux that referenced this pull request May 12, 2015

Merge pull request torvalds#76 from gripped/xbmc-fixes

0834510

Oversun's MFC and CEC fixes

hzhuang1 pushed a commit to hzhuang1/linux that referenced this pull request Jun 2, 2015

Merge pull request torvalds#76 from hzhuang1/enable_ldo21

ae4cdb9

ARM64: hi6220: enable ldo21 by default

diaevd referenced this pull request in diaevd/zen-kernel Dec 30, 2015

Merge pull request zen-kernel#76 from sh0dow/master

42635ed

Fixed compilation for linux kernel < 3.3.0

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix section 3.8 number #76

Fix section 3.8 number #76

ruckuus commented Mar 5, 2014

Elizafox commented Jan 8, 2015

swarren commented Jan 9, 2015

Fix section 3.8 number #76

Are you sure you want to change the base?

Fix section 3.8 number #76

Conversation

ruckuus commented Mar 5, 2014

Elizafox commented Jan 8, 2015

swarren commented Jan 9, 2015