Merge pull request #2 from torvalds/master #134

dabrace · 2014-11-09T17:52:34Z

Sync as of 10272014

WARNING: 'dependant' may be misspelled - perhaps 'dependent'? torvalds#134: FILE: include/uapi/linux/msg.h:66: + * size. The optimal value is application dependant. total: 0 errors, 1 warnings, 378 lines checked ./patches/ipc-msg-increase-msgmni-remove-scaling.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: Davidlohr Bueso <dave@stgolabs.net> Cc: Manfred Spraul <manfred@colorfullife.com> Cc: Rafael Aquini <aquini@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

When tiecap is used as a module, then while doing a rmmod I get the following dump. root@am437x-evm:/# rmmod pwm_tiecap [ 219.539245] [ 219.540771] ====================================================== [ 219.546936] [ INFO: possible circular locking dependency detected ] [ 219.553192] 3.12.4-01557-g9921cde-dirty torvalds#134 Not tainted [ 219.558471] ------------------------------------------------------- [ 219.564727] rmmod/1517 is trying to acquire lock: [ 219.569427] (s_active#35){++++.+}, at: [<c017ab00>] sysfs_hash_and_remove+0x4c/0x8c [ 219.577239] [ 219.577239] but task is already holding lock: [ 219.583068] (pwm_lock){+.+.+.}, at: [<c0303598>] pwmchip_remove+0x14/0xf8 [ 219.589996] [ 219.589996] which lock already depends on the new lock. [ 219.589996] [ 219.598144] [ 219.598144] the existing dependency chain (in reverse order) is: [ 219.605590] -> #1 (pwm_lock){+.+.+.}: [ 219.609497] [<c00a2d1c>] lock_acquire+0x9c/0x128 [ 219.614746] [<c0639bc0>] mutex_lock_nested+0x50/0x3dc [ 219.620391] [<c0303974>] pwm_request_from_chip+0x38/0x6c [ 219.626312] [<c0303fe0>] pwm_export_store+0x50/0x140 [ 219.631896] [<c039aba8>] dev_attr_store+0x18/0x24 [ 219.637207] [<c017aff0>] sysfs_write_file+0x16c/0x1a0 [ 219.642883] [<c0119084>] vfs_write+0xb0/0x188 [ 219.647857] [<c0119478>] SyS_write+0x3c/0x70 [ 219.652770] [<c0014100>] ret_fast_syscall+0x0/0x48 [ 219.658172] -> #0 (s_active#35){++++.+}: [ 219.662353] [<c00a2778>] __lock_acquire+0x1b28/0x1b70 [ 219.667999] [<c00a2d1c>] lock_acquire+0x9c/0x128 [ 219.673248] [<c017c780>] sysfs_addrm_finish+0xe8/0x158 [ 219.678985] [<c017ab00>] sysfs_hash_and_remove+0x4c/0x8c [ 219.684906] [<c017e224>] remove_files+0x38/0x74 [ 219.690063] [<c017e2a4>] sysfs_remove_group+0x44/0x108 [ 219.695800] [<c017e38c>] sysfs_remove_groups+0x24/0x34 [ 219.701538] [<c039bc2c>] device_del+0xec/0x178 [ 219.706604] [<c039bcc4>] device_unregister+0xc/0x18 [ 219.712097] [<c0303658>] pwmchip_remove+0xd4/0xf8 [ 219.717407] [<c039fdc4>] platform_drv_remove+0x18/0x1c [ 219.723175] [<c039e6c4>] __device_release_driver+0x70/0xc8 [ 219.729248] [<c039eec8>] driver_detach+0xb4/0xb8 [ 219.734497] [<c039e4ec>] bus_remove_driver+0x8c/0xd0 [ 219.740081] [<c00abd2c>] SyS_delete_module+0x118/0x22c [ 219.745819] [<c0014100>] ret_fast_syscall+0x0/0x48 [ 219.751220] [ 219.751220] other info that might help us debug this: [ 219.751220] [ 219.759216] Possible unsafe locking scenario: [ 219.759216] [ 219.765106] CPU0 CPU1 [ 219.769622] ---- ---- [ 219.774139] lock(pwm_lock); [ 219.777130] lock(s_active#35); [ 219.782897] lock(pwm_lock); [ 219.788391] lock(s_active#35); [ 219.791656] [ 219.791656] *** DEADLOCK *** [ 219.791656] [ 219.797546] 3 locks held by rmmod/1517: [ 219.801391] #0: (&__lockdep_no_validate__){......}, at: [<c039ee58>] driver_detach+0x44/0xb8 [ 219.810028] #1: (&__lockdep_no_validate__){......}, at: [<c039ee64>] driver_detach+0x50/0xb8 [ 219.818695] #2: (pwm_lock){+.+.+.}, at: [<c0303598>] pwmchip_remove+0x14/0xf8 [ 219.826049] [ 219.826049] stack backtrace: [ 219.830413] CPU: 0 PID: 1517 Comm: rmmod Not tainted 3.12.4-01557-g9921cde-dirty torvalds#134 [ 219.838256] [<c001cc98>] (unwind_backtrace+0x0/0xf0) from [<c0018124>] (show_stack+0x10/0x14) [ 219.846771] [<c0018124>] (show_stack+0x10/0x14) from [<c0636728>] (dump_stack+0x74/0xb4) [ 219.854858] [<c0636728>] (dump_stack+0x74/0xb4) from [<c06344e4>] (print_circular_bug+0x284/0x2d8) [ 219.863830] [<c06344e4>] (print_circular_bug+0x284/0x2d8) from [<c00a2778>] (__lock_acquire+0x1b28/0x1b70) [ 219.873443] [<c00a2778>] (__lock_acquire+0x1b28/0x1b70) from [<c00a2d1c>] (lock_acquire+0x9c/0x128) [ 219.882476] [<c00a2d1c>] (lock_acquire+0x9c/0x128) from [<c017c780>] (sysfs_addrm_finish+0xe8/0x158) [ 219.891601] [<c017c780>] (sysfs_addrm_finish+0xe8/0x158) from [<c017ab00>] (sysfs_hash_and_remove+0x4c/0x8c) [ 219.901397] [<c017ab00>] (sysfs_hash_and_remove+0x4c/0x8c) from [<c017e224>] (remove_files+0x38/0x74) [ 219.910614] [<c017e224>] (remove_files+0x38/0x74) from [<c017e2a4>] (sysfs_remove_group+0x44/0x108) [ 219.919647] [<c017e2a4>] (sysfs_remove_group+0x44/0x108) from [<c017e38c>] (sysfs_remove_groups+0x24/0x34) [ 219.929260] [<c017e38c>] (sysfs_remove_groups+0x24/0x34) from [<c039bc2c>] (device_del+0xec/0x178) [ 219.938201] [<c039bc2c>] (device_del+0xec/0x178) from [<c039bcc4>] (device_unregister+0xc/0x18) [ 219.946899] [<c039bcc4>] (device_unregister+0xc/0x18) from [<c0303658>] (pwmchip_remove+0xd4/0xf8) [ 219.955841] [<c0303658>] (pwmchip_remove+0xd4/0xf8) from [<c039fdc4>] (platform_drv_remove+0x18/0x1c) [ 219.965057] [<c039fdc4>] (platform_drv_remove+0x18/0x1c) from [<c039e6c4>] (__device_release_driver+0x70/0xc8) [ 219.975006] [<c039e6c4>] (__device_release_driver+0x70/0xc8) from [<c039eec8>] (driver_detach+0xb4/0xb8) [ 219.984466] [<c039eec8>] (driver_detach+0xb4/0xb8) from [<c039e4ec>] (bus_remove_driver+0x8c/0xd0) [ 219.993438] [<c039e4ec>] (bus_remove_driver+0x8c/0xd0) from [<c00abd2c>] (SyS_delete_module+0x118/0x22c) [ 220.002899] [<c00abd2c>] (SyS_delete_module+0x118/0x22c) from [<c0014100>] (ret_fast_syscall+0x0/0x48) Looks like s_active lock cannot be held while pwm lock is held. The patch fixes the above issue by unlocking the pwm lock before acquiring the sysfs lock. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>

…heckpatch-fixes ERROR: code indent should use tabs where possible torvalds#120: FILE: include/linux/capability.h:220: + return true;$ WARNING: please, no spaces at the start of a line torvalds#120: FILE: include/linux/capability.h:220: + return true;$ ERROR: code indent should use tabs where possible torvalds#125: FILE: include/linux/capability.h:225: + return true;$ WARNING: please, no spaces at the start of a line torvalds#125: FILE: include/linux/capability.h:225: + return true;$ ERROR: code indent should use tabs where possible torvalds#129: FILE: include/linux/capability.h:229: + return true;$ WARNING: please, no spaces at the start of a line torvalds#129: FILE: include/linux/capability.h:229: + return true;$ ERROR: code indent should use tabs where possible torvalds#134: FILE: include/linux/capability.h:234: + return true;$ WARNING: please, no spaces at the start of a line torvalds#134: FILE: include/linux/capability.h:234: + return true;$ ERROR: code indent should use tabs where possible torvalds#170: FILE: include/linux/cred.h:79: + return 1;$ WARNING: please, no spaces at the start of a line torvalds#170: FILE: include/linux/cred.h:79: + return 1;$ ERROR: code indent should use tabs where possible torvalds#174: FILE: include/linux/cred.h:83: + return 1;$ WARNING: please, no spaces at the start of a line torvalds#174: FILE: include/linux/cred.h:83: + return 1;$ total: 6 errors, 6 warnings, 310 lines checked NOTE: whitespace errors detected, you may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/kernel-conditionally-support-non-root-users-groups-and-capabilities.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: Iulia Manda <iulia.manda21@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Cc: David Rientjes <rientjes@google.com> WARNING: line over 80 characters torvalds#99: FILE: mm/page_alloc.c:2965: + * zone list (with a backoff mechanism which is a function of no_progress_loops). WARNING: line over 80 characters torvalds#129: FILE: mm/page_alloc.c:2995: + * Keep reclaiming pages while there is a chance this will lead somewhere. WARNING: line over 80 characters torvalds#134: FILE: mm/page_alloc.c:3000: + for_each_zone_zonelist_nodemask(zone, z, ac->zonelist, ac->high_zoneidx, ac->nodemask) { WARNING: line over 80 characters torvalds#138: FILE: mm/page_alloc.c:3004: + available -= DIV_ROUND_UP(no_progress_loops * available, MAX_RECLAIM_RETRIES); WARNING: line over 80 characters torvalds#142: FILE: mm/page_alloc.c:3008: + * Would the allocation succeed if we reclaimed the whole available? WARNING: line over 80 characters torvalds#146: FILE: mm/page_alloc.c:3012: + /* Wait for some write requests to complete then retry */ total: 0 errors, 6 warnings, 202 lines checked ./patches/mm-oom-rework-oom-detection.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: David Rientjes <rientjes@google.com> Cc: Hillf Danton <hillf.zj@alibaba-inc.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Mel Gorman <mgorman@suse.de> Cc: Michal Hocko <mhocko@suse.com> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Reported by checkpatch: security/selinux/nlmsgtab.c --------------------------- ERROR: that open brace { should be on the previous line torvalds#29: FILE: security/selinux/nlmsgtab.c:29: +static const struct nlmsg_perm nlmsg_route_perms[] = +{ ERROR: that open brace { should be on the previous line torvalds#97: FILE: security/selinux/nlmsgtab.c:97: +static const struct nlmsg_perm nlmsg_tcpdiag_perms[] = +{ ERROR: that open brace { should be on the previous line torvalds#105: FILE: security/selinux/nlmsgtab.c:105: +static const struct nlmsg_perm nlmsg_xfrm_perms[] = +{ ERROR: that open brace { should be on the previous line torvalds#134: FILE: security/selinux/nlmsgtab.c:134: +static const struct nlmsg_perm nlmsg_audit_perms[] = +{ security/selinux/ss/policydb.c ------------------------------ ERROR: that open brace { should be on the previous line torvalds#318: FILE: security/selinux/ss/policydb.c:318: +static int (*destroy_f[SYM_NUM]) (void *key, void *datum, void *datap) = +{ ERROR: that open brace { should be on the previous line torvalds#674: FILE: security/selinux/ss/policydb.c:674: +static int (*index_f[SYM_NUM]) (void *key, void *datum, void *datap) = +{ ERROR: that open brace { should be on the previous line #1643: FILE: security/selinux/ss/policydb.c:1643: +static int (*read_f[SYM_NUM]) (struct policydb *p, struct symtab *s, void *fp) = +{ ERROR: that open brace { should be on the previous line #3246: FILE: security/selinux/ss/policydb.c:3246: + void *datap) = +{ Signed-off-by: Christian Göttsche <cgzones@googlemail.com>

Reported by checkpatch: security/selinux/nlmsgtab.c --------------------------- ERROR: that open brace { should be on the previous line torvalds#29: FILE: security/selinux/nlmsgtab.c:29: +static const struct nlmsg_perm nlmsg_route_perms[] = +{ ERROR: that open brace { should be on the previous line torvalds#97: FILE: security/selinux/nlmsgtab.c:97: +static const struct nlmsg_perm nlmsg_tcpdiag_perms[] = +{ ERROR: that open brace { should be on the previous line torvalds#105: FILE: security/selinux/nlmsgtab.c:105: +static const struct nlmsg_perm nlmsg_xfrm_perms[] = +{ ERROR: that open brace { should be on the previous line torvalds#134: FILE: security/selinux/nlmsgtab.c:134: +static const struct nlmsg_perm nlmsg_audit_perms[] = +{ security/selinux/ss/policydb.c ------------------------------ ERROR: that open brace { should be on the previous line torvalds#318: FILE: security/selinux/ss/policydb.c:318: +static int (*destroy_f[SYM_NUM]) (void *key, void *datum, void *datap) = +{ ERROR: that open brace { should be on the previous line torvalds#674: FILE: security/selinux/ss/policydb.c:674: +static int (*index_f[SYM_NUM]) (void *key, void *datum, void *datap) = +{ ERROR: that open brace { should be on the previous line #1643: FILE: security/selinux/ss/policydb.c:1643: +static int (*read_f[SYM_NUM]) (struct policydb *p, struct symtab *s, void *fp) = +{ ERROR: that open brace { should be on the previous line #3246: FILE: security/selinux/ss/policydb.c:3246: + void *datap) = +{ Signed-off-by: Christian Göttsche <cgzones@googlemail.com> Signed-off-by: Paul Moore <paul@paul-moore.com>

…-fixes WARNING: 'an user' may be misspelled - perhaps 'a user'? torvalds#33: address may not always an user address, so introduce a new copy_mc flag in ^^^^^^^ WARNING: please, no spaces at the start of a line torvalds#133: FILE: lib/iov_iter.c:637: + if (iov_iter_is_copy_mc(i))$ WARNING: suspect code indent for conditional statements (7, 15) torvalds#133: FILE: lib/iov_iter.c:637: + if (iov_iter_is_copy_mc(i)) + return (void *)copy_mc_to_kernel(to, from, size); ERROR: code indent should use tabs where possible torvalds#134: FILE: lib/iov_iter.c:638: + return (void *)copy_mc_to_kernel(to, from, size);$ WARNING: please, no spaces at the start of a line torvalds#134: FILE: lib/iov_iter.c:638: + return (void *)copy_mc_to_kernel(to, from, size);$ total: 1 errors, 4 warnings, 118 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-hwpoison-coredump-support-recovery-from-dump_user_range.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi>

LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi>

LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>

[ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>

BugLink: https://bugs.launchpad.net/bugs/2035588 [ Upstream commit 7f74563 ] LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 torvalds#129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 torvalds#132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 torvalds#133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 torvalds#134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 torvalds#135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 torvalds#136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Andrea Righi <andrea.righi@canonical.com>

This reverts commit c3c7041. We hit a locking ordering issue in the other direction. Let's revert for now. [ 9.378773] ====================================================== [ 9.379476] WARNING: possible circular locking dependency detected [ 9.379532] 6.6.0-work-10442-ga7150a9168f8-dirty torvalds#134 Not tainted [ 9.379532] ------------------------------------------------------ [ 9.379532] scx_rustland/1622 is trying to acquire lock: [ 9.379532] ffffffff8325f828 (cpu_hotplug_lock){++++}-{0:0}, at: bpf_scx_reg+0xe4/0xcf0 [ 9.379532] [ 9.379532] but task is already holding lock: [ 9.379532] ffffffff83271be8 (scx_cgroup_rwsem){++++}-{0:0}, at: bpf_scx_reg+0xdf/0xcf0 [ 9.379532] [ 9.379532] which lock already depends on the new lock. [ 9.379532] [ 9.379532] [ 9.379532] the existing dependency chain (in reverse order) is: [ 9.379532] [ 9.379532] -> #2 (scx_cgroup_rwsem){++++}-{0:0}: [ 9.379532] percpu_down_read+0x2e/0xb0 [ 9.379532] scx_cgroup_can_attach+0x25/0x200 [ 9.379532] cpu_cgroup_can_attach+0xe/0x10 [ 9.379532] cgroup_migrate_execute+0xaf/0x450 [ 9.379532] cgroup_apply_control+0x227/0x2a0 [ 9.379532] cgroup_subtree_control_write+0x425/0x4b0 [ 9.379532] cgroup_file_write+0x82/0x260 [ 9.379532] kernfs_fop_write_iter+0x131/0x1c0 [ 9.379532] vfs_write+0x1f9/0x270 [ 9.379532] ksys_write+0x62/0xc0 [ 9.379532] __x64_sys_write+0x1b/0x20 [ 9.379532] do_syscall_64+0x40/0xe0 [ 9.379532] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 9.379532] [ 9.379532] -> #1 (cgroup_threadgroup_rwsem){++++}-{0:0}: [ 9.379532] percpu_down_write+0x35/0x1e0 [ 9.379532] cgroup_procs_write_start+0x8a/0x210 [ 9.379532] __cgroup_procs_write+0x4c/0x160 [ 9.379532] cgroup_procs_write+0x17/0x30 [ 9.379532] cgroup_file_write+0x82/0x260 [ 9.379532] kernfs_fop_write_iter+0x131/0x1c0 [ 9.379532] vfs_write+0x1f9/0x270 [ 9.379532] ksys_write+0x62/0xc0 [ 9.379532] __x64_sys_write+0x1b/0x20 [ 9.379532] do_syscall_64+0x40/0xe0 [ 9.379532] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 9.379532] [ 9.379532] -> #0 (cpu_hotplug_lock){++++}-{0:0}: [ 9.379532] __lock_acquire+0x142d/0x2a30 [ 9.379532] lock_acquire+0xbf/0x1f0 [ 9.379532] cpus_read_lock+0x2f/0xc0 [ 9.379532] bpf_scx_reg+0xe4/0xcf0 [ 9.379532] bpf_struct_ops_link_create+0xb6/0x100 [ 9.379532] link_create+0x49/0x200 [ 9.379532] __sys_bpf+0x351/0x3e0 [ 9.379532] __x64_sys_bpf+0x1c/0x20 [ 9.379532] do_syscall_64+0x40/0xe0 [ 9.379532] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 9.379532] [ 9.379532] other info that might help us debug this: [ 9.379532] [ 9.379532] Chain exists of: [ 9.379532] cpu_hotplug_lock --> cgroup_threadgroup_rwsem --> scx_cgroup_rwsem [ 9.379532] [ 9.379532] Possible unsafe locking scenario: [ 9.379532] [ 9.379532] CPU0 CPU1 [ 9.379532] ---- ---- [ 9.379532] lock(scx_cgroup_rwsem); [ 9.379532] lock(cgroup_threadgroup_rwsem); [ 9.379532] lock(scx_cgroup_rwsem); [ 9.379532] rlock(cpu_hotplug_lock); [ 9.379532] [ 9.379532] *** DEADLOCK *** [ 9.379532] [ 9.379532] 3 locks held by scx_rustland/1622: [ 9.379532] #0: ffffffff83272708 (scx_ops_enable_mutex){+.+.}-{3:3}, at: bpf_scx_reg+0x2a/0xcf0 [ 9.379532] #1: ffffffff83271aa0 (scx_fork_rwsem){++++}-{0:0}, at: bpf_scx_reg+0xd3/0xcf0 [ 9.379532] #2: ffffffff83271be8 (scx_cgroup_rwsem){++++}-{0:0}, at: bpf_scx_reg+0xdf/0xcf0 [ 9.379532] [ 9.379532] stack backtrace: [ 9.379532] CPU: 7 PID: 1622 Comm: scx_rustland Not tainted 6.6.0-work-10442-ga7150a9168f8-dirty torvalds#134 [ 9.379532] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022 [ 9.379532] Sched_ext: rustland (prepping) [ 9.379532] Call Trace: [ 9.379532] <TASK> [ 9.379532] dump_stack_lvl+0x55/0x70 [ 9.379532] dump_stack+0x10/0x20 [ 9.379532] print_circular_bug+0x2ea/0x2f0 [ 9.379532] check_noncircular+0xe2/0x100 [ 9.379532] __lock_acquire+0x142d/0x2a30 [ 9.379532] ? lock_acquire+0xbf/0x1f0 [ 9.379532] ? rcu_sync_func+0x2c/0xa0 [ 9.379532] lock_acquire+0xbf/0x1f0 [ 9.379532] ? bpf_scx_reg+0xe4/0xcf0 [ 9.379532] cpus_read_lock+0x2f/0xc0 [ 9.379532] ? bpf_scx_reg+0xe4/0xcf0 [ 9.379532] bpf_scx_reg+0xe4/0xcf0 [ 9.379532] ? alloc_file+0xa4/0x160 [ 9.379532] ? alloc_file_pseudo+0x99/0xd0 [ 9.379532] ? anon_inode_getfile+0x79/0xc0 [ 9.379532] ? bpf_link_prime+0xe2/0x1a0 [ 9.379532] bpf_struct_ops_link_create+0xb6/0x100 [ 9.379532] link_create+0x49/0x200 [ 9.379532] __sys_bpf+0x351/0x3e0 [ 9.379532] __x64_sys_bpf+0x1c/0x20 [ 9.379532] do_syscall_64+0x40/0xe0 [ 9.379532] ? sysvec_apic_timer_interrupt+0x44/0x80 [ 9.379532] entry_SYSCALL_64_after_hwframe+0x46/0x4e [ 9.379532] RIP: 0033:0x7fc391f7473d [ 9.379532] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 95 0c 00 f7 d8 64 89 01 48 [ 9.379532] RSP: 002b:00007ffeb4fe4108 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 [ 9.379532] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc391f7473d [ 9.379532] RDX: 0000000000000030 RSI: 00007ffeb4fe4120 RDI: 000000000000001c [ 9.379532] RBP: 000000000000000c R08: 000000000000000c R09: 000055d0a75b1a10 [ 9.379532] R10: 0000000000000050 R11: 0000000000000246 R12: 000000000000002c [ 9.379532] R13: 00007ffeb4fe4628 R14: 0000000000000000 R15: 00007ffeb4fe4328 [ 9.379532] </TASK>

* rk3588-fxblox-rk1a dd edp and user leds to dts * Update rk3588-fxblox-rk1.dts

In the current interrupt reporting mode, each CQ entry reports an interrupt. However, when there are a large number of I/O hardware completion interrupts, the following issue may occur: [ 4682.678657][ C129] irq 134: nobody cared (try booting with the "irqpoll" option) [ 4682.708455][ C129] Call trace: [ 4682.711589][ C129] dump_backtrace+0x0/0x1e4 [ 4682.715934][ C129] show_stack+0x20/0x2c [ 4682.719933][ C129] dump_stack+0xd8/0x140 [ 4682.724017][ C129] __report_bad_irq+0x54/0x180 [ 4682.728625][ C129] note_interrupt+0x1ec/0x2f0 [ 4682.733143][ C129] handle_irq_event+0x118/0x1ac [ 4682.737834][ C129] handle_fasteoi_irq+0xc8/0x200 [ 4682.742613][ C129] __handle_domain_irq+0x84/0xf0 [ 4682.747391][ C129] gic_handle_irq+0x88/0x2c0 [ 4682.751822][ C129] el1_irq+0xbc/0x140 [ 4682.755648][ C129] _find_next_bit.constprop.0+0x20/0x94 [ 4682.761036][ C129] cpumask_next+0x24/0x30 [ 4682.765208][ C129] gic_ipi_send_mask+0x48/0x170 [ 4682.769900][ C129] __ipi_send_mask+0x34/0x110 [ 4682.775720][ C129] smp_cross_call+0x3c/0xcc [ 4682.780064][ C129] arch_send_call_function_single_ipi+0x38/0x44 [ 4682.786146][ C129] send_call_function_single_ipi+0xd0/0xe0 [ 4682.791794][ C129] generic_exec_single+0xb4/0x170 [ 4682.796659][ C129] smp_call_function_single_async+0x2c/0x40 [ 4682.802395][ C129] blk_mq_complete_request_remote.part.0+0xec/0x100 [ 4682.808822][ C129] blk_mq_complete_request+0x30/0x70 [ 4682.813950][ C129] scsi_mq_done+0x48/0xac [ 4682.818128][ C129] sas_scsi_task_done+0xb0/0x150 [libsas] [ 4682.823692][ C129] slot_complete_v3_hw+0x230/0x710 [hisi_sas_v3_hw] [ 4682.830120][ C129] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw] [ 4682.836114][ C129] irq_thread_fn+0x34/0xa4 [ 4682.840371][ C129] irq_thread+0xc4/0x130 [ 4682.844455][ C129] kthread+0x108/0x13c [ 4682.848365][ C129] ret_from_fork+0x10/0x18 [ 4682.852621][ C129] handlers: [ 4682.855577][ C129] [<00000000949e52bf>] cq_interrupt_v3_hw [hisi_sas_v3_hw] threaded [<000000005d8e3b68>] cq_thread_v3_hw [hisi_sas_v3_hw] [ 4682.868084][ C129] Disabling IRQ torvalds#134 When the IRQ management layer processes each hardware interrupt, if the return value of the interrupt handler is IRQ_WAKE_THREAD, it will wake up the handler thread for this interrupt action and set IRQTF_RUNTHREAD flag, wait for the interrupt handling thread to clear the IRQTF_RUNTHREAD flag after execution. Later in note_interrupt(), use irq_count to count hardware interrupts and irqs_unhandled to count interrupts for which no thread handler is responsible. When irq_count reaches 100000 and irqs_unhandled reaches 99000, irq will be disabled. In the performance test scenario, I/O completion hardware interrupts are continuously and quickly generated. As a result, the interrupt processing thread is cyclically called in irq_thread() and does not exit, this affects the response of the interrupt thread to the hardware interrupt and causes irqs_unhandled to grow to 99000. Finally, the irq is disabled. Therefore, default enable interrupt coalescing to reduce the generation of hardware interrupts, this helps interrupt processing threads to stop calling in irq_thread(). For interrupt coalescing, according to the actual performance test, set the count of CQ entries to 10 and the interrupt coalescing timeout period to 10us based on the actual performance test. Before and after interrupt coalescing is enabled, the 4K read/write performance is improved by about 3%, and the 256K read/write performance is basically the same. Signed-off-by: Yihang Li <liyihang9@huawei.com> Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com>

In the current interrupt reporting mode, each CQ entry reports an interrupt. However, when there are a large number of I/O hardware completion interrupts, the following issue may occur: [ 4682.678657][ C129] irq 134: nobody cared (try booting with the "irqpoll" option) [ 4682.708455][ C129] Call trace: [ 4682.711589][ C129] dump_backtrace+0x0/0x1e4 [ 4682.715934][ C129] show_stack+0x20/0x2c [ 4682.719933][ C129] dump_stack+0xd8/0x140 [ 4682.724017][ C129] __report_bad_irq+0x54/0x180 [ 4682.728625][ C129] note_interrupt+0x1ec/0x2f0 [ 4682.733143][ C129] handle_irq_event+0x118/0x1ac [ 4682.737834][ C129] handle_fasteoi_irq+0xc8/0x200 [ 4682.742613][ C129] __handle_domain_irq+0x84/0xf0 [ 4682.747391][ C129] gic_handle_irq+0x88/0x2c0 [ 4682.751822][ C129] el1_irq+0xbc/0x140 [ 4682.755648][ C129] _find_next_bit.constprop.0+0x20/0x94 [ 4682.761036][ C129] cpumask_next+0x24/0x30 [ 4682.765208][ C129] gic_ipi_send_mask+0x48/0x170 [ 4682.769900][ C129] __ipi_send_mask+0x34/0x110 [ 4682.775720][ C129] smp_cross_call+0x3c/0xcc [ 4682.780064][ C129] arch_send_call_function_single_ipi+0x38/0x44 [ 4682.786146][ C129] send_call_function_single_ipi+0xd0/0xe0 [ 4682.791794][ C129] generic_exec_single+0xb4/0x170 [ 4682.796659][ C129] smp_call_function_single_async+0x2c/0x40 [ 4682.802395][ C129] blk_mq_complete_request_remote.part.0+0xec/0x100 [ 4682.808822][ C129] blk_mq_complete_request+0x30/0x70 [ 4682.813950][ C129] scsi_mq_done+0x48/0xac [ 4682.818128][ C129] sas_scsi_task_done+0xb0/0x150 [libsas] [ 4682.823692][ C129] slot_complete_v3_hw+0x230/0x710 [hisi_sas_v3_hw] [ 4682.830120][ C129] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw] [ 4682.836114][ C129] irq_thread_fn+0x34/0xa4 [ 4682.840371][ C129] irq_thread+0xc4/0x130 [ 4682.844455][ C129] kthread+0x108/0x13c [ 4682.848365][ C129] ret_from_fork+0x10/0x18 [ 4682.852621][ C129] handlers: [ 4682.855577][ C129] [<00000000949e52bf>] cq_interrupt_v3_hw [hisi_sas_v3_hw] threaded [<000000005d8e3b68>] cq_thread_v3_hw [hisi_sas_v3_hw] [ 4682.868084][ C129] Disabling IRQ torvalds#134 When the IRQ management layer processes each hardware interrupt, if the return value of the interrupt handler is IRQ_WAKE_THREAD, it will wake up the handler thread for this interrupt action and set IRQTF_RUNTHREAD flag, wait for the interrupt handling thread to clear the IRQTF_RUNTHREAD flag after execution. Later in note_interrupt(), use irq_count to count hardware interrupts and irqs_unhandled to count interrupts for which no thread handler is responsible. When irq_count reaches 100000 and irqs_unhandled reaches 99000, irq will be disabled. In the performance test scenario, I/O completion hardware interrupts are continuously and quickly generated. As a result, the interrupt processing thread is cyclically called in irq_thread() and does not exit, this affects the response of the interrupt thread to the hardware interrupt and causes irqs_unhandled to grow to 99000. Finally, the irq is disabled. Therefore, default enable interrupt coalescing to reduce the generation of hardware interrupts, this helps interrupt processing threads to stop calling in irq_thread(). For interrupt coalescing, according to the actual performance test, set the count of CQ entries to 10 and the interrupt coalescing timeout period to 10us based on the actual performance test. Before and after interrupt coalescing is enabled, the 4K read/write performance is improved by about 3%, and the 256K read/write performance is basically the same. Signed-off-by: Yihang Li <liyihang9@huawei.com> Link: https://lore.kernel.org/r/20241008021822.2617339-9-liyihang9@huawei.com Reviewed-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

* rk3588-fxblox-rk1a dd edp and user leds to dts * Update rk3588-fxblox-rk1.dts

tg3 and ds3232 conflict IRQs. This is a work around. SVYzilla: torvalds#134 Signed-off-by: Ben Collins <ben.c@servergy.com>

Fixes issue with hung TX CPU in svyboot. SVYzilla: torvalds#134 Signed-off-by: Ben Collins <ben.c@servergy.com>

When tiecap is used as a module, then while doing a rmmod I get the following dump. root@am437x-evm:/# rmmod pwm_tiecap [ 219.539245] [ 219.540771] ====================================================== [ 219.546936] [ INFO: possible circular locking dependency detected ] [ 219.553192] 3.12.4-01557-g9921cde-dirty torvalds#134 Not tainted [ 219.558471] ------------------------------------------------------- [ 219.564727] rmmod/1517 is trying to acquire lock: [ 219.569427] (s_active#35){++++.+}, at: [<c017ab00>] sysfs_hash_and_remove+0x4c/0x8c [ 219.577239] [ 219.577239] but task is already holding lock: [ 219.583068] (pwm_lock){+.+.+.}, at: [<c0303598>] pwmchip_remove+0x14/0xf8 [ 219.589996] [ 219.589996] which lock already depends on the new lock. [ 219.589996] [ 219.598144] [ 219.598144] the existing dependency chain (in reverse order) is: [ 219.605590] -> #1 (pwm_lock){+.+.+.}: [ 219.609497] [<c00a2d1c>] lock_acquire+0x9c/0x128 [ 219.614746] [<c0639bc0>] mutex_lock_nested+0x50/0x3dc [ 219.620391] [<c0303974>] pwm_request_from_chip+0x38/0x6c [ 219.626312] [<c0303fe0>] pwm_export_store+0x50/0x140 [ 219.631896] [<c039aba8>] dev_attr_store+0x18/0x24 [ 219.637207] [<c017aff0>] sysfs_write_file+0x16c/0x1a0 [ 219.642883] [<c0119084>] vfs_write+0xb0/0x188 [ 219.647857] [<c0119478>] SyS_write+0x3c/0x70 [ 219.652770] [<c0014100>] ret_fast_syscall+0x0/0x48 [ 219.658172] -> #0 (s_active#35){++++.+}: [ 219.662353] [<c00a2778>] __lock_acquire+0x1b28/0x1b70 [ 219.667999] [<c00a2d1c>] lock_acquire+0x9c/0x128 [ 219.673248] [<c017c780>] sysfs_addrm_finish+0xe8/0x158 [ 219.678985] [<c017ab00>] sysfs_hash_and_remove+0x4c/0x8c [ 219.684906] [<c017e224>] remove_files+0x38/0x74 [ 219.690063] [<c017e2a4>] sysfs_remove_group+0x44/0x108 [ 219.695800] [<c017e38c>] sysfs_remove_groups+0x24/0x34 [ 219.701538] [<c039bc2c>] device_del+0xec/0x178 [ 219.706604] [<c039bcc4>] device_unregister+0xc/0x18 [ 219.712097] [<c0303658>] pwmchip_remove+0xd4/0xf8 [ 219.717407] [<c039fdc4>] platform_drv_remove+0x18/0x1c [ 219.723175] [<c039e6c4>] __device_release_driver+0x70/0xc8 [ 219.729248] [<c039eec8>] driver_detach+0xb4/0xb8 [ 219.734497] [<c039e4ec>] bus_remove_driver+0x8c/0xd0 [ 219.740081] [<c00abd2c>] SyS_delete_module+0x118/0x22c [ 219.745819] [<c0014100>] ret_fast_syscall+0x0/0x48 [ 219.751220] [ 219.751220] other info that might help us debug this: [ 219.751220] [ 219.759216] Possible unsafe locking scenario: [ 219.759216] [ 219.765106] CPU0 CPU1 [ 219.769622] ---- ---- [ 219.774139] lock(pwm_lock); [ 219.777130] lock(s_active#35); [ 219.782897] lock(pwm_lock); [ 219.788391] lock(s_active#35); [ 219.791656] [ 219.791656] *** DEADLOCK *** [ 219.791656] [ 219.797546] 3 locks held by rmmod/1517: [ 219.801391] #0: (&__lockdep_no_validate__){......}, at: [<c039ee58>] driver_detach+0x44/0xb8 [ 219.810028] #1: (&__lockdep_no_validate__){......}, at: [<c039ee64>] driver_detach+0x50/0xb8 [ 219.818695] #2: (pwm_lock){+.+.+.}, at: [<c0303598>] pwmchip_remove+0x14/0xf8 [ 219.826049] [ 219.826049] stack backtrace: [ 219.830413] CPU: 0 PID: 1517 Comm: rmmod Not tainted 3.12.4-01557-g9921cde-dirty torvalds#134 [ 219.838256] [<c001cc98>] (unwind_backtrace+0x0/0xf0) from [<c0018124>] (show_stack+0x10/0x14) [ 219.846771] [<c0018124>] (show_stack+0x10/0x14) from [<c0636728>] (dump_stack+0x74/0xb4) [ 219.854858] [<c0636728>] (dump_stack+0x74/0xb4) from [<c06344e4>] (print_circular_bug+0x284/0x2d8) [ 219.863830] [<c06344e4>] (print_circular_bug+0x284/0x2d8) from [<c00a2778>] (__lock_acquire+0x1b28/0x1b70) [ 219.873443] [<c00a2778>] (__lock_acquire+0x1b28/0x1b70) from [<c00a2d1c>] (lock_acquire+0x9c/0x128) [ 219.882476] [<c00a2d1c>] (lock_acquire+0x9c/0x128) from [<c017c780>] (sysfs_addrm_finish+0xe8/0x158) [ 219.891601] [<c017c780>] (sysfs_addrm_finish+0xe8/0x158) from [<c017ab00>] (sysfs_hash_and_remove+0x4c/0x8c) [ 219.901397] [<c017ab00>] (sysfs_hash_and_remove+0x4c/0x8c) from [<c017e224>] (remove_files+0x38/0x74) [ 219.910614] [<c017e224>] (remove_files+0x38/0x74) from [<c017e2a4>] (sysfs_remove_group+0x44/0x108) [ 219.919647] [<c017e2a4>] (sysfs_remove_group+0x44/0x108) from [<c017e38c>] (sysfs_remove_groups+0x24/0x34) [ 219.929260] [<c017e38c>] (sysfs_remove_groups+0x24/0x34) from [<c039bc2c>] (device_del+0xec/0x178) [ 219.938201] [<c039bc2c>] (device_del+0xec/0x178) from [<c039bcc4>] (device_unregister+0xc/0x18) [ 219.946899] [<c039bcc4>] (device_unregister+0xc/0x18) from [<c0303658>] (pwmchip_remove+0xd4/0xf8) [ 219.955841] [<c0303658>] (pwmchip_remove+0xd4/0xf8) from [<c039fdc4>] (platform_drv_remove+0x18/0x1c) [ 219.965057] [<c039fdc4>] (platform_drv_remove+0x18/0x1c) from [<c039e6c4>] (__device_release_driver+0x70/0xc8) [ 219.975006] [<c039e6c4>] (__device_release_driver+0x70/0xc8) from [<c039eec8>] (driver_detach+0xb4/0xb8) [ 219.984466] [<c039eec8>] (driver_detach+0xb4/0xb8) from [<c039e4ec>] (bus_remove_driver+0x8c/0xd0) [ 219.993438] [<c039e4ec>] (bus_remove_driver+0x8c/0xd0) from [<c00abd2c>] (SyS_delete_module+0x118/0x22c) [ 220.002899] [<c00abd2c>] (SyS_delete_module+0x118/0x22c) from [<c0014100>] (ret_fast_syscall+0x0/0x48) Looks like s_active lock cannot be held while pwm lock is held. The patch fixes the above issue by unlocking the pwm lock before acquiring the sysfs lock. Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>

Merge pull request #1 from torvalds/master

a1d0b61

Sync as of 10272014

dabrace closed this Nov 9, 2014

rpardini pushed a commit to rpardini/linux that referenced this pull request Jul 9, 2024

arm64: dts: rk3588-fxblox-rk1: add edp and user leds (torvalds#134)

408b805

* rk3588-fxblox-rk1a dd edp and user leds to dts * Update rk3588-fxblox-rk1.dts

hbiyik pushed a commit to hbiyik/linux that referenced this pull request Nov 25, 2024

arm64: dts: rk3588-fxblox-rk1: add edp and user leds (torvalds#134)

4552637

* rk3588-fxblox-rk1a dd edp and user leds to dts * Update rk3588-fxblox-rk1.dts

benmcollins pushed a commit to benmcollins/linux that referenced this pull request Mar 5, 2025

SVY: jade-config: Enable MSI

9c33b66

tg3 and ds3232 conflict IRQs. This is a work around. SVYzilla: torvalds#134 Signed-off-by: Ben Collins <ben.c@servergy.com>

benmcollins pushed a commit to benmcollins/linux that referenced this pull request Mar 5, 2025

SVY: tg3: Update to version from 3.11 kernel

65c0a70

Fixes issue with hung TX CPU in svyboot. SVYzilla: torvalds#134 Signed-off-by: Ben Collins <ben.c@servergy.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Merge pull request #2 from torvalds/master #134

Merge pull request #2 from torvalds/master #134

dabrace commented Nov 9, 2014

Merge pull request #2 from torvalds/master #134

Merge pull request #2 from torvalds/master #134

Conversation

dabrace commented Nov 9, 2014