-
Notifications
You must be signed in to change notification settings - Fork 54.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update acct.c #104
Closed
Closed
Update acct.c #104
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hubcapsc
pushed a commit
to hubcapsc/linux
that referenced
this pull request
Jul 2, 2014
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 torvalds#6 torvalds#7 [ 0.603005] .... node #1, CPUs: torvalds#8 torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 [ 1.200005] .... node #2, CPUs: torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23 [ 1.796005] .... node #3, CPUs: torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 [ 2.393005] .... node #4, CPUs: torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 [ 2.996005] .... node #5, CPUs: torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47 [ 3.600005] .... node torvalds#6, CPUs: torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 [ 4.202005] .... node torvalds#7, CPUs: torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 [ 4.811005] .... node torvalds#8, CPUs: torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71 [ 5.421006] .... node torvalds#9, CPUs: torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 [ 6.032005] .... node torvalds#10, CPUs: torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 [ 6.648006] .... node torvalds#11, CPUs: torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95 [ 7.262005] .... node torvalds#12, CPUs: torvalds#96 torvalds#97 torvalds#98 torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103 [ 7.865005] .... node torvalds#13, CPUs: torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111 [ 8.466005] .... node torvalds#14, CPUs: torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119 [ 9.073006] .... node torvalds#15, CPUs: torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: huawei.libin@huawei.com Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
tom3q
pushed a commit
to tom3q/linux
that referenced
this pull request
Oct 2, 2014
At boot we display a bunch of low level settings which can be useful to know, and can help to spot bugs when things are fundamentally misconfigured. At the moment they are very widely spaced, so that we can accommodate the line: ppc64_caches.dcache_line_size = 0xYY But we only print that line when the cache line size is not 128, ie. almost never, so it just makes the display look odd usually. The ppc64_caches prefix is redundant so remove it, which means we can align things a bit closer for the common case. While we're there replace the last use of camelCase (physicalMemorySize), and use phys_mem_size. Before: Starting Linux PPC64 torvalds#104 SMP Wed Aug 6 18:41:34 EST 2014 ----------------------------------------------------- ppc64_pft_size = 0x1a physicalMemorySize = 0x200000000 ppc64_caches.dcache_line_size = 0xf0 ppc64_caches.icache_line_size = 0xf0 htab_address = 0xdeadbeef htab_hash_mask = 0x7ffff physical_start = 0xf000bar ----------------------------------------------------- After: Starting Linux PPC64 torvalds#103 SMP Wed Aug 6 18:38:04 EST 2014 ----------------------------------------------------- ppc64_pft_size = 0x1a phys_mem_size = 0x200000000 dcache_line_size = 0xf0 icache_line_size = 0xf0 htab_address = 0xdeadbeef htab_hash_mask = 0x7ffff physical_start = 0xf000bar ----------------------------------------------------- This patch is final, no bike shedding ;) Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
aryabinin
referenced
this pull request
in aryabinin/linux
Oct 3, 2014
GIT 6fe676b243e5a0cb4cc4d9a4b094de8db0cdbf74 commit e500f488c27659bb6f5d313b336621f3daa67701 Author: Fabian Frederick <fabf@skynet.be> Date: Wed Oct 1 06:52:06 2014 +0200 net/dccp/ccid.c: add __init to ccid_activate ccid_activate is only called by __init ccid_initialize_builtins in same module. Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net> commit 0c5b8a46294d43fc63788839d3c18de0961ec1bc Author: Fabian Frederick <fabf@skynet.be> Date: Wed Oct 1 06:48:03 2014 +0200 net/dccp/proto.c: add __init to dccp_mib_init dccp_mib_init is only called by __init dccp_init in same module. Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net> commit 082f58ac4a48d3f5cb4597232cb2ac6823a96f43 Author: Quinn Tran <quinn.tran@qlogic.com> Date: Thu Sep 25 06:22:28 2014 -0400 target: Fix queue full status NULL pointer for SCF_TRANSPORT_TASK_SENSE During temporary resource starvation at lower transport layer, command is placed on queue full retry path, which expose this problem. The TCM queue full handling of SCF_TRANSPORT_TASK_SENSE currently sends the same cmd twice to lower layer. The 1st time led to cmd normal free path. The 2nd time cause Null pointer access. This regression bug was originally introduced v3.1-rc code in the following commit: commit e057f53308a5f071556ee80586b99ee755bf07f5 Author: Christoph Hellwig <hch@infradead.org> Date: Mon Oct 17 13:56:41 2011 -0400 target: remove the transport_qf_callback se_cmd callback Signed-off-by: Quinn Tran <quinn.tran@qlogic.com> Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com> Cc: <stable@vger.kernel.org> # v3.1+ Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit db3a99b9921f27fe71ca8c0f218ee810e0e7fb69 Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:19 2014 -0400 qla_target: rearrange struct qla_tgt_prm On most (non-x86) 64bit platforms this will remove 8 padding bytes from the structure. Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit f9b6721a9cef94908467abf7a2cacbd15a7d23cb Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:18 2014 -0400 qla_target: improve qlt_unmap_sg() Remove the inline attribute. Modern compilers ignore it and the function has grown beyond where inline made sense anyway. Remove the BUG_ON(!cmd->sg_mapped), and instead return if sg_mapped is not set. Every caller is doing this check, so we might as well have it in one place instead of four. Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit 55a9066fffd2f533e7ed434b072469ef09d6c476 Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:15 2014 -0400 qla_target: make some global functions static Also removes the declarations from the header - including two declarations without function definitions or callers. Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit c57010420654aca179c500f61e86315a337244ca Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:14 2014 -0400 qla_target: remove unused parameter Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit f81ccb489a7a641c1bed41b49cf8d72c199c68d5 Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:13 2014 -0400 target: simplify core_tmr_abort_task list_for_each_entry_safe is necessary if list objects are deleted from the list while traversing it. Not the case here, so we can use the base list_for_each_entry variant. Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit 33940d09937276cd3c81f2874faf43e37c2db0e2 Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:12 2014 -0400 target: encapsulate smp_mb__after_atomic() The target code has a rather generous helping of smp_mb__after_atomic() throughout the code base. Most atomic operations were followed by one and none were preceded by smp_mb__before_atomic(), nor accompanied by a comment explaining the need for a barrier. Instead of trying to prove for every case whether or not it is needed, this patch introduces atomic_inc_mb() and atomic_dec_mb(), which explicitly include the memory barriers before and after the atomic operation. For now they are defined in a target header, although they could be of general use. Most of the existing atomic/mb combinations were replaced by the new helpers. In a few cases the atomic was sandwiched in spin_lock/spin_unlock and I simply removed the barrier. I suspect that in most cases the correct conversion would have been to drop the barrier. I also suspect that a few cases exist where a) the barrier was necessary and b) a second barrier before the atomic would have been necessary and got added by this patch. Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit 74ed7e62289dc6d388996d7c8f89c2e7e95b9657 Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:11 2014 -0400 target: remove some smp_mb__after_atomic()s atomic_inc_return() already does an implicit memory barrier and the second case was moved from an atomic to a plain flag operation. If a barrier were needed in the second case, it would have to be smp_mb(), not a variant optimized away for x86 and other architectures. Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit 8f83269048628d7b139dacbfc6cc97befcbdd2e9 Author: Joern Engel <joern@logfs.org> Date: Tue Sep 16 16:23:10 2014 -0400 target: simplify core_tmr_release_req() And while at it, do minimal coding style fixes in the area. Signed-off-by: Joern Engel <joern@logfs.org> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit 9c7d6154bc4b9dfefd580490cdca5f7c72321464 Author: Andy Grover <agrover@redhat.com> Date: Mon Jun 30 16:39:46 2014 -0700 target: Remove core_tpg_release_virtual_lun0 function Simple and just called from one place. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andy Grover <agrover@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit cd9d7cbaec8b622eee4edcd8bf481c4047f74915 Author: Andy Grover <agrover@redhat.com> Date: Mon Jun 30 16:39:44 2014 -0700 target: Change core_dev_del_lun to take a se_lun instead of unpacked_lun Remove core_tpg_pre_dellun entirely, since we don't need to get/check a pointer we already have. Nothing else can return an error, so core_dev_del_lun can return void. Rename core_tpg_post_dellun to remove_lun - a clearer name, now that pre_dellun is gone. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andy Grover <agrover@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit cc83881f2c57caaf4b14adaffa65595640a59661 Author: Andy Grover <agrover@redhat.com> Date: Mon Jun 30 16:39:43 2014 -0700 target: core_tpg_post_dellun can return void Nothing in it can raise an error. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Andy Grover <agrover@redhat.com> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org> commit 49be17235c0acd96f2ff0fe282867fe3a83f554c Author: hayeswang <hayeswang@realtek.com> Date: Wed Oct 1 13:25:11 2014 +0800 r8152: disable power cut for RTL8153 The firmware would be clear when the power cut is enabled for RTL8153. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 204c8704128943bf3f8b605f4b40bdc2b6bd89dc Author: hayeswang <hayeswang@realtek.com> Date: Wed Oct 1 13:25:10 2014 +0800 r8152: remove clearing bp The xxx_clear_bp() is used to halt the firmware. It only necessary for updating the new firmware. Besides, depend on the version of the current firmware, it may have problem to halt the firmware directly. Finally, halt the firmware would let the firmware code useless, and the bugs which are fixed by the firmware would occur. Signed-off-by: Hayes Wang <hayeswang@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit aa55c8e2f7a395dfc9e67fc6637321e19ce9bfe1 Author: Masahiro Yamada <yamada.m@jp.panasonic.com> Date: Tue Sep 9 20:02:24 2014 +0900 kbuild: handle C=... and M=... after entering into build directory This commit avoids processing C=... and M=... twice when O=... is also given. Besides, we can also remove KBUILD_EXTMOD="$(KBUILD_EXTMOD)" in the sub-make target. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Peter Foley <pefoley2@pefoley.com> Signed-off-by: Michal Marek <mmarek@suse.cz> commit 745a254322c898dadf019342cd7140f7867d2d0f Author: Masahiro Yamada <yamada.m@jp.panasonic.com> Date: Tue Sep 9 20:02:23 2014 +0900 kbuild: use $(Q) for sub-make target Since commit 066b7ed9558087a7957a1128f27d7a3462ff117f (kbuild: Do not print the build directory with make -s), "Q" is defined above the sub-make target. This commit takes advantage of that and replaces "$(if $(KBUILD_VERBOSE:1=),@)" with "$(Q)". Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Peter Foley <pefoley2@pefoley.com> Signed-off-by: Michal Marek <mmarek@suse.cz> commit 7ff525712acf9325e9acdb27bbc93049ea2e850c Author: Masahiro Yamada <yamada.m@jp.panasonic.com> Date: Tue Sep 9 20:02:22 2014 +0900 kbuild: fake the "Entering directory ..." message more simply Commit c2e28dc975ea87feed84415006ae143424912ac7 (kbuild: Print the name of the build directory) added a gimmick to show the "Entering directory ...". Instead of echoing the hard-coded message (that is, we need to know the exact message), moving --no-print-directory would be easier. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: Peter Foley <pefoley2@pefoley.com> Signed-off-by: Michal Marek <mmarek@suse.cz> commit 1b0ecb28b0cc216535ce6477d39aa610c3ff68a1 Author: Vlad Yasevich <vyasevich@gmail.com> Date: Tue Sep 30 19:39:37 2014 -0400 bnx2: Correctly receive full sized 802.1ad fragmes This driver, similar to tg3, has a check that will cause full sized 802.1ad frames to be dropped. The frame will be larger then the standard mtu due to the presense of vlan header that has not been stripped. The driver should not drop this frame and should process it just like it does for 802.1q. CC: Sony Chacko <sony.chacko@qlogic.com> CC: Dept-HSGLinuxNICDev@qlogic.com Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 7d3083ee36b51e425b6abd76778a2046906b0fd3 Author: Vlad Yasevich <vyasevich@gmail.com> Date: Tue Sep 30 19:39:36 2014 -0400 tg3: Allow for recieve of full-size 8021AD frames When receiving a vlan-tagged frame that still contains a vlan header, the length of the packet will be greater then MTU+ETH_HLEN since it will account of the extra vlan header. TG3 checks this for the case for 802.1Q, but not for 802.1ad. As a result, full sized 802.1ad frames get dropped by the card. Add a check for 802.1ad protocol when receving full sized frames. Suggested-by: Prashant Sreedharan <prashant@broadcom.com> CC: Prashant Sreedharan <prashant@broadcom.com> CC: Michael Chan <mchan@broadcom.com> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6 Author: Florian Westphal <fw@strlen.de> Date: Wed Oct 1 13:38:03 2014 +0200 r8169: add support for Byte Queue Limits tested on RTL8168d/8111d model using 'super_netperf 40' with TCP/UDP_STREAM. Output of while true; do for n in inflight limit; do echo -n $n\ ; cat $n; done; sleep 1; done during netperf run, 100mbit peer: inflight 0 limit 3028 inflight 6056 limit 4542 [ trimmed output for brevity, no limit/inflight changes during test steady-state ] limit 4542 inflight 3028 limit 6122 inflight 0 limit 6122 [ changed cable to 1gbit peer, restart netperf ] inflight 37850 limit 36336 inflight 33308 limit 31794 inflight 33308 limit 31794 inflight 27252 limit 25738 [ again, no changes during test ] inflight 27252 limit 25738 inflight 0 limit 28766 [ change cable to 100mbit peer, restart netperf ] limit 28766 inflight 27370 limit 28766 inflight 4542 limit 5990 inflight 6056 limit 4542 [ .. ] inflight 6056 limit 4542 inflight 0 [end of test] Cc: Francois Romieu <romieu@fr.zoreil.com> Cc: Hayes Wang <hayeswang@realtek.com> Signed-off-by: Florian Westphal <fw@strlen.de> Acked-by: Eric Dumazet <edumazet@google.com> Acked-by: Tom Herbert <therbert@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit d0bf4a9e92b9a93ffeeacbd7b6cb83e0ee3dc2ef Author: Eric Dumazet <edumazet@google.com> Date: Mon Sep 29 13:29:15 2014 -0700 net: cleanup and document skb fclone layout Lets use a proper structure to clearly document and implement skb fast clones. Then, we might experiment more easily alternative layouts. This patch adds a new skb_fclone_busy() helper, used by tcp and xfrm, to stop leaking of implementation details. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 0f1ca65ee50df042051e8fa3a14f73b0c71d45b9 Author: Arianna Avanzini <avanzini.arianna@gmail.com> Date: Fri Aug 22 13:20:02 2014 +0200 xen, blkfront: factor out flush-related checks from do_blkif_request() This commit factors out some checks related to the request insertion path, which can be done in an function instead of by itself. Reviewed-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: Arianna Avanzini <avanzini.arianna@gmail.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> commit 61cecca865280bef4f8a9748d0a9afa5df351ac2 Author: Roger Pau Monné <roger.pau@citrix.com> Date: Mon Sep 15 11:55:27 2014 +0200 xen-blkback: fix leak on grant map error path Fix leaking a page when a grant mapping has failed. CC: stable@vger.kernel.org Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Reported-and-Tested-by: Tao Chen <boby.chen@huawei.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> commit 12ea729645ace01e08f9654df155622898d3aae6 Author: Vitaly Kuznetsov <vkuznets@redhat.com> Date: Mon Sep 8 15:21:33 2014 +0200 xen/blkback: unmap all persistent grants when frontend gets disconnected blkback does not unmap persistent grants when frontend goes to Closed state (e.g. when blkfront module is being removed). This leads to the following in guest's dmesg: [ 343.243825] xen:grant_table: WARNING: g.e. 0x445 still in use! [ 343.243825] xen:grant_table: WARNING: g.e. 0x42a still in use! ... When load module -> use device -> unload module sequence is performed multiple times it is possible to hit BUG() condition in blkfront module: [ 343.243825] kernel BUG at drivers/block/xen-blkfront.c:954! [ 343.243825] invalid opcode: 0000 [#1] SMP [ 343.243825] Modules linked in: xen_blkfront(-) ata_generic pata_acpi [last unloaded: xen_blkfront] ... [ 343.243825] Call Trace: [ 343.243825] [<ffffffff814111ef>] ? unregister_xenbus_watch+0x16f/0x1e0 [ 343.243825] [<ffffffffa0016fbf>] blkfront_remove+0x3f/0x140 [xen_blkfront] ... [ 343.243825] RIP [<ffffffffa0016aae>] blkif_free+0x34e/0x360 [xen_blkfront] [ 343.243825] RSP <ffff88001eb8fdc0> We don't need to keep these grants if we're disconnecting as frontend might already forgot about them. Solve the issue by moving xen_blkbk_free_caches() call from xen_blkif_free() to xen_blkif_disconnect(). Now we can see the following: [ 928.590893] xen:grant_table: WARNING: g.e. 0x587 still in use! [ 928.591861] xen:grant_table: WARNING: g.e. 0x372 still in use! ... [ 929.592146] xen:grant_table: freeing g.e. 0x587 [ 929.597174] xen:grant_table: freeing g.e. 0x372 ... Backend does not keep persistent grants any more, reconnect works fine. CC: stable@vger.kernel.org Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> commit b248230c34970a6c1c17c591d63b464e8d2cfc33 Author: Yuchung Cheng <ycheng@google.com> Date: Mon Sep 29 13:20:38 2014 -0700 tcp: abort orphan sockets stalling on zero window probes Currently we have two different policies for orphan sockets that repeatedly stall on zero window ACKs. If a socket gets a zero window ACK when it is transmitting data, the RTO is used to probe the window. The socket is aborted after roughly tcp_orphan_retries() retries (as in tcp_write_timeout()). But if the socket was idle when it received the zero window ACK, and later wants to send more data, we use the probe timer to probe the window. If the receiver always returns zero window ACKs, icsk_probes keeps getting reset in tcp_ack() and the orphan socket can stall forever until the system reaches the orphan limit (as commented in tcp_probe_timer()). This opens up a simple attack to create lots of hanging orphan sockets to burn the memory and the CPU, as demonstrated in the recent netdev post "TCP connection will hang in FIN_WAIT1 after closing if zero window is advertised." http://www.spinics.net/lists/netdev/msg296539.html This patch follows the design in RTO-based probe: we abort an orphan socket stalling on zero window when the probe timer reaches both the maximum backoff and the maximum RTO. For example, an 100ms RTT connection will timeout after roughly 153 seconds (0.3 + 0.6 + .... + 76.8) if the receiver keeps the window shut. If the orphan socket passes this check, but the system already has too many orphans (as in tcp_out_of_resources()), we still abort it but we'll also send an RST packet as the connection may still be active. In addition, we change TCP_USER_TIMEOUT to cover (life or dead) sockets stalled on zero-window probes. This changes the semantics of TCP_USER_TIMEOUT slightly because it previously only applies when the socket has pending transmission. Signed-off-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Reported-by: Andrey Dmitrov <andrey.dmitrov@oktetlabs.ru> Signed-off-by: David S. Miller <davem@davemloft.net> commit 3edfe0030bb7a82dab2a30a29ea6e1800e600c4b Author: Helge Deller <deller@gmx.de> Date: Wed Oct 1 22:11:01 2014 +0200 parisc: Fix serial console for machines with serial port on superio chip Fix the serial console on machines where the serial port is located on the SuperIO chip. Signed-off-by: Helge Deller <deller@gmx.de> Cc: Peter Hurley <peter@hurleysoftware.com> commit baf378126b08474de2e2428b16e62a69df0339d9 Author: Michael Opdenacker <michael.opdenacker@free-electrons.com> Date: Wed Oct 1 14:07:39 2014 -0600 rsxx: Remove deprecated IRQF_DISABLED This removes the use of the IRQF_DISABLED flag from drivers/block/rsxx/core.c It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com> Acked-by Philip Kelleher <pjk1939@linux.vnet.ibm.com> Signed-off-by: Jens Axboe <axboe@fb.com> commit cb57659a15c6c0576493cc8a10474ce7ffd44eb3 Author: Fabian Frederick <fabf@skynet.be> Date: Wed Oct 1 19:30:03 2014 +0200 cipso: add __init to cipso_v4_cache_init cipso_v4_cache_init is only called by __init cipso_v4_init Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net> commit 57a02c39c1c20ed03a86f8014c11a8c18b94cac3 Author: Fabian Frederick <fabf@skynet.be> Date: Wed Oct 1 19:18:57 2014 +0200 inet: frags: add __init to ip4_frags_ctl_register ip4_frags_ctl_register is only called by __init ipfrag_init Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net> commit 47d7a88c188f06ffaea3a539f84fe10cb4e77787 Author: Fabian Frederick <fabf@skynet.be> Date: Wed Oct 1 18:27:50 2014 +0200 tcp: add __init to tcp_init_mem tcp_init_mem is only called by __init tcp_init. Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: David S. Miller <davem@davemloft.net> commit ee7a1beb9759c94aea67dd887faf5e447a5c6710 Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:21 2014 +0800 r8169:call "rtl8168_driver_start" "rtl8168_driver_stop" only when hardware dash function is enabled These two functions are used to inform dash firmware that driver is been brought up or brought down. So call these two functions only when hardware dash function is enabled. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 2a9b4d9670e71784896d95c41c9b0acd50db1dbb Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:20 2014 +0800 r8169:modify the behavior of function "rtl8168_oob_notify" In function "rtl8168_oob_notify", using function "rtl_eri_write" to access eri register 0xe8, instead of using MAC register "ERIDR" and "ERIAR" to access it. For using function "rtl_eri_write" in function "rtl8168_oob_notify", need to move down "rtl8168_oob_notify" related functions under the function "rtl_eri_write". Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 2f8c040ce6791ef0477e6d59768ee3d5fd0df0fd Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:19 2014 +0800 r8169:change the name of function "r8168dp_check_dash" to "r8168_check_dash" DASH function not only RTL8168DP can support, but also RTL8168EP. So change the name of function "r8168dp_check_dash" to "r8168_check_dash". Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 706123d06c18b55da5e9da21e2d138ee789bf8f4 Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:18 2014 +0800 r8169:change the name of function"rtl_w1w0_eri" Change the name of function "rtl_w1w0_eri" to "rtl_w0w1_eri". In this function, the local variable "val" is "write zeros then write ones". Please see below code. (val & ~m) | p In this patch, change the function name from "xx_w1w0_xx" to "xx_w0w1_xx". The changed function name is more suitable for it's behavior. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 7656442824f6174b56a19c664fe560972df56ad4 Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:17 2014 +0800 r8169:for function "rtl_w1w0_phy" change its name and behavior Change function name from "rtl_w1w0_phy" to "rtl_w0w1_phy". And its behavior from "write ones then write zeros" to "write zeros then write ones". In Realtek internal driver, bitwise operations are almost "write zeros then write ones". For easy to port hardware parameters from Realtek internal driver to Linux kernal driver "r8169", we would like to change this function's behavior and its name. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit ac85bcdbc0ffd3903d6db4abcd769ecacf98605b Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:16 2014 +0800 r8169:add more chips to support magic packet v2 For RTL8168F RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8402 RTL8107E, the magic packet enable bit is changed to eri 0xde bit0. In this patch, change magic packet enable bit of these chips to eri 0xde bit0. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 89cceb2729c752e6ff9b3bc8650a70f29884f116 Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:15 2014 +0800 r8169:add support more chips to get mac address from backup mac address register RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8106EUS RTL8402 can support get mac address from backup mac address register. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 42fde7371035144037844f41bd16950de9912bdb Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:14 2014 +0800 r8169:add disable/enable RTL8411B pll function RTL8411B can support disable/enable pll function. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit b8e5e6ad7115befef13a4493f1d2b8e438abc058 Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:13 2014 +0800 r8169:add disable/enable RTL8168G pll function RTL8168G also can disable/enable pll function. Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 05b9687bb3606190304f08c2e4cd63de8717e30b Author: Chun-Hao Lin <hau@realtek.com> Date: Wed Oct 1 23:17:12 2014 +0800 r8169:change uppercase number to lowercase number Signed-off-by: Chun-Hao Lin <hau@realtek.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit a29c9c43bb633a9965909cd548879fee4aa789a4 Author: David L Stevens <david.stevens@oracle.com> Date: Wed Oct 1 11:05:27 2014 -0400 sunvnet: fix potential NULL pointer dereference One of the error cases for vnet_start_xmit()'s "out_dropped" label is port == NULL, so only mess with port->clean_timer when port is not NULL. Signed-off-by: David L Stevens <david.stevens@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit e506d405ac7d34d03996c97ac68aa2ac010be64a Author: Thierry Reding <treding@nvidia.com> Date: Wed Oct 1 13:59:00 2014 +0200 net: dsa: Fix build warning for !PM_SLEEP The dsa_switch_suspend() and dsa_switch_resume() functions are only used when PM_SLEEP is enabled, so they need #ifdef CONFIG_PM_SLEEP protection to avoid a compiler warning. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 84ac1f2ca41f5888cc995944c073a5220f3ed549 Author: Tanmay Inamdar <tinamdar@apm.com> Date: Fri Sep 26 14:08:25 2014 -0700 arm64: dts: Add APM X-Gene PCIe device tree nodes Add the device tree nodes for APM X-Gene PCIe host controller and PCIe clock interface. Since X-Gene SOC supports maximum 5 ports, 5 dts nodes are added. Signed-off-by: Tanmay Inamdar <tinamdar@apm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit 2896e4418b17363f211e084471b589e3c06a7248 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Wed Oct 1 13:01:35 2014 -0600 PCI: xgene: Add APM X-Gene PCIe driver Add the AppliedMicro X-Gene SOC PCIe host controller driver. The X-Gene PCIe controller supports up to 8 lanes and GEN3 speed. The X-Gene SOC supports up to 5 PCIe ports. [bhelgaas: folded in MAINTAINERS and bindings updates] Tested-by: Ming Lei <ming.lei@canonical.com> Tested-by: Dann Frazier <dann.frazier@canonical.com> Signed-off-by: Tanmay Inamdar <tinamdar@apm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Liviu Dudau <Liviu.Dudau@arm.com> (driver) commit 3c87dcbfb36ce6d3d9087f0163c02ba5690d9a85 Author: Subbaraya Sundeep Bhatta <subbaraya.sundeep.bhatta@xilinx.com> Date: Wed Oct 1 11:01:17 2014 +0200 net: ll_temac: Remove unnecessary ether_setup after alloc_etherdev Calling ether_setup is redundant since alloc_etherdev calls it. Signed-off-by: Subbaraya Sundeep Bhatta <sbhatta@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 8493ecca74a7b4a66e19676de1a0f14194179941 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Wed Oct 1 11:59:47 2014 -0400 HID: uHID: fix excepted report type When uhid_get_report() or uhid_set_report() are called, they emit on the char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the protocol says that the user space asnwers with UHID_GET_REPORT_REPLY or UHID_SET_REPORT_REPLY. Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT or UHID_SET_REPORT instead of the reply one. Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the reply, and validate the reply. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> commit c8df6ac9452e8f47a6f660993c526d13e858a6f3 Author: Lucas Stach <l.stach@pengutronix.de> Date: Tue Sep 30 18:36:27 2014 +0200 PCI: designware: Remove open-coded bitmap operations Replace them by using the standard kernel bitmap ops. No functional change, but makes the code a lot cleaner. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Pratyush Anand <pratyush.anand@st.com> Acked-by: Jingoo Han <jg1.han@samsung.com> commit 2199f0608864cf4e8c93d37842a5ee50c8d79843 Author: Mikulas Patocka <mpatocka@redhat.com> Date: Fri Mar 28 15:51:56 2014 -0400 dm crypt: sort writes Write requests are sorted in a red-black tree structure and are submitted in the sorted order. In theory the sorting should be performed by the underlying disk scheduler, however, in practice the disk scheduler only accepts and sorts a finite number of requests. To allow the sorting of all requests, dm-crypt needs to implement its own own sorting. The overhead associated with rbtree-based sorting is considered negligible so it is not used conditionally. Even on SSD sorting can be beneficial since in-order request dispatch promotes lower latency IO completion to the upper layers. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit 648fee35be4c75667aa18bf513f7e7e65c01640b Author: Mikulas Patocka <mpatocka@redhat.com> Date: Fri Mar 28 15:51:56 2014 -0400 dm crypt: offload writes to thread Submitting write bios directly in the encryption thread caused serious performance degradation. On a multiprocessor machine, encryption requests finish in a different order than they were submitted. Consequently, write requests would be submitted in a different order and it could cause severe performance degradation. Move the submission of write requests to a separate thread so that the requests can be sorted before submitting. But this commit improves dm-crypt performance even without having dm-crypt perform request sorting (in particular it enables IO schedulers like CFQ to sort more effectively). Note: it is required that a previous commit ("dm crypt: don't allocate pages for a partial request") be applied before applying this patch. Otherwise, this commit could introduce a crash. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit 4a0d7e0464226eee625a5b77484c339334453882 Author: Mikulas Patocka <mpatocka@redhat.com> Date: Fri Mar 28 15:51:55 2014 -0400 dm crypt: use unbound workqueue for request processing Use unbound workqueue so that work is automatically balanced between available CPUs. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit 72bfc40ca3b393cb0bc6b5e2ce364e6c6ce0f390 Author: Mikulas Patocka <mpatocka@redhat.com> Date: Thu May 29 14:18:12 2014 -0400 dm crypt: remove io_pending refcount member from dm_crypt_io Commit "dm crypt: don't allocate pages for a partial request" changed the code to allocate all pages for one request. There is always just one pending request, so the io_pending refcount may be removed. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit 42196fec8945cc84c032b7f59deaffee82036245 Author: Mikulas Patocka <mpatocka@redhat.com> Date: Fri Mar 28 15:51:56 2014 -0400 dm crypt: remove unused io_pool and _crypt_io_pool The previous commits ("dm crypt: use per-bio data") and ("dm crypt: don't allocate pages for a partial request") stopped using the io_pool slab mempool and backing _crypt_io_pool kmem cache. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit ebfda24b1e1bf483accdb900f8625151d8f01383 Author: Mikulas Patocka <mpatocka@redhat.com> Date: Fri Mar 28 15:51:56 2014 -0400 dm crypt: avoid deadlock in mempools Fix a theoretical deadlock introduced in the previous commit ("dm crypt: don't allocate pages for a partial request"). The function crypt_alloc_buffer may be called concurrently. If we allocate from the mempool concurrently, there is a possibility of deadlock. For example, if we have mempool of 256 pages, two processes, each wanting 256, pages allocate from the mempool concurrently, it may deadlock in a situation where both processes have allocated 128 pages and the mempool is exhausted. In order to avoid such a scenario, we allocate the pages under a mutex. In order to not degrade performance with excessive locking, we try non-blocking allocations without a mutex first and if it fails, we fallback to a blocking allocation with a mutex. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit b9ea7cb3fb237078be400522880932008c630fb7 Author: Mikulas Patocka <mpatocka@redhat.com> Date: Fri Mar 28 15:51:56 2014 -0400 dm crypt: don't allocate pages for a partial request Change crypt_alloc_buffer so that it only ever allocates pages for a full request. This change is a prerequisite for the commit "dm crypt: offload writes to thread". Which implies this change is effectively required for the upcoming cpu parallelization changes. But this change simplifies the dm-crypt code at the expense of reduced throughput in low memory conditions (where allocation for a partial request is most useful). This change also enables the removal of the io_pending refcount. Note: the next commit ("dm-crypt: avoid deadlock in mempools") is needed to fix a theoretical deadlock. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit 117cd3e12232afea97dd31489fbde8888ad22b3e Author: Heinz Mauelshagen <heinzm@redhat.com> Date: Wed Sep 24 17:47:19 2014 +0200 dm raid: add discard support for RAID levels 4, 5 and 6 In case of RAID levels 4, 5 and 6 we have to verify each RAID members' ability to zero data on discards to avoid stripe data corruption -- if discard_zeroes_data is not set for each RAID member discard support must be disabled. Also add an 'ignore_discard' table argument to the target in order to ignore discard processing completely on a RAID array, hence not passing down discards to MD personalities. This 'ignore_discard' control provides the ability to: - prohibit discards in case of _potential_ data corruptions in RAID4/5/6 (e.g. if ability to zero data on discard is flawed in a RAID member) - avoid discard processing overhead Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> commit 04c308f43a90a9b3b84c344b324d6af29288da05 Author: Mikulas Patocka <mpatocka@redhat.com> Date: Wed Oct 1 13:29:48 2014 -0400 dm bufio: when done scanning return from __scan immediately When __scan frees the required number of buffer entries that the shrinker requested (nr_to_scan becomes zero) it must return. Before this fix the __scan code exited only the inner loop and continued in the outer loop. Also, move dm_bufio_cond_resched to __scan's inner loop, so that iterating the bufio client's lru lists doesn't result in scheduling latency. Reported-by: Joe Thornber <thornber@redhat.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Cc: stable@vger.kernel.org # 3.2+ commit 5ec094057c7df5ff80f5e7fe282f47ad205fb976 Author: Bjorn Helgaas <bhelgaas@google.com> Date: Tue Sep 23 14:38:28 2014 -0600 PCI/MSI: Remove unnecessary temporary variable The only use of "status" is to hold a value which is immediately returned, so just return and remove the variable directly. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit 56b72b40957947f7c08771f030102351d4c906df Author: Yijing Wang <wangyijing@huawei.com> Date: Mon Sep 29 18:35:16 2014 -0600 PCI/MSI: Use __write_msi_msg() instead of write_msi_msg() default_restore_msi_irq() already has the struct msi_desc pointer required by __write_msi_msg(), so call it directly instead of having write_msi_msg() look it up from the IRQ. No functional change. [bhelgaas: split into separate patch] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit 1e8f4cc82eded0c3c97ef6e2f119782e42deda35 Author: Yijing Wang <wangyijing@huawei.com> Date: Wed Sep 24 11:09:45 2014 +0800 MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg() rtas_setup_msi_irqs() already has the struct msi_desc pointer required by __read_msi_msg(), so call it directly instead of having read_msi_msg() look it up from the IRQ. No functional change. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> CC: Benjamin Herrenschmidt <benh@kernel.crashing.org> CC: linuxppc-dev@lists.ozlabs.org commit 2b260085e466c345e78f23b1c9ad1d123d509ef8 Author: Yijing Wang <wangyijing@huawei.com> Date: Tue Sep 23 13:27:25 2014 +0800 PCI/MSI: Use __get_cached_msi_msg() instead of get_cached_msi_msg() Both callers of get_cached_msi_msg() start with a struct irq_data pointer, look up the corresponding IRQ number, and pass it to get_cached_msi_msg(), which then uses irq_get_irq_data() to look up the struct irq_data again to call __get_cached_msi_msg(). Since we already have the struct irq_data, call __get_cached_msi_msg() directly and skip the lookup work done by get_cached_msi_msg(). No functional change. [bhelgaas: changelog] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> CC: Tony Luck <tony.luck@intel.com> CC: linux-ia64@vger.kernel.org commit 468ff15a3ab98ed7153c29c68229ffb97f15a251 Author: Yijing Wang <wangyijing@huawei.com> Date: Tue Sep 23 13:27:24 2014 +0800 PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow future driver requests for MSI or MSI-X. Previously, the sysfs file existed for endpoints but did nothing. Add "msi_bus" support for endpoints, so an administrator can prevent the use of MSI and MSI-X for individual devices. Note that as for bridges, these changes only affect future driver requests for MSI or MSI-X, so drivers may need to be reloaded. Add documentation for the "msi_bus" sysfs file. [bhelgaas: changelog, comments, add "subordinate", add endpoint printk, rework bus_flags setting, make bus_flags printk unconditional] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit 48c3c38f003c25d50a09d3da558667c5ecd530aa Author: Yijing Wang <wangyijing@huawei.com> Date: Tue Sep 23 11:02:42 2014 -0600 PCI/MSI: Remove "pos" from the struct msi_desc msi_attrib "msi_attrib.pos" is only used for MSI (not MSI-X), and we already cache the MSI capability offset in "dev->msi_cap". Remove "pos" from the struct msi_attrib and use "dev->msi_cap" directly. [bhelgaas: changelog, fix whitespace] Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit 81052769e48609525c452d8f078a5786b673e178 Author: Yijing Wang <wangyijing@huawei.com> Date: Tue Sep 23 13:27:22 2014 +0800 PCI/MSI: Remove unused kobject from struct msi_desc After commit 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects"), the kobject in struct msi_desc is unused. Remove the unused struct kobject from struct msi_desc. [bhelgaas: changelog] Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects") Signed-off-by: Yijing Wang <wangyijing@huawei.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> commit a06cd74cefe754341f747ddc4cf7b0058fa9bff8 Author: Alexander Gordeev <agordeev@redhat.com> Date: Tue Sep 23 12:45:58 2014 -0600 PCI/MSI: Rename pci_msi_check_device() to pci_msi_supported() Rename pci_msi_check_device() to pci_msi_supported() for clarity. Note that pci_msi_supported() returns true if MSI/MSI-X is supported, so code like: if (pci_msi_supported(...)) reads naturally. [bhelgaas: changelog, split to separate patch, reverse sense] Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit 27e20603c54ba633ed259284d006275f13c9f95b Author: Alexander Gordeev <agordeev@redhat.com> Date: Tue Sep 23 14:25:11 2014 -0600 PCI/MSI: Move D0 check into pci_msi_check_device() Both callers of pci_msi_check_device() check that the device is in D0 state, so move the check from the callers into pci_msi_check_device() itself. In pci_enable_msi_range(), note that pci_msi_check_device() never returns a positive value any more, so the loop that called it until it returns zero or negative is no longer necessary. [bhelgaas: changelog, split to separate patch] Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit ad975ebad4c3ce8dcc7d0bb4db26ea5aca4cfc99 Author: Alexander Gordeev <agordeev@redhat.com> Date: Tue Sep 23 12:39:54 2014 -0600 PCI/MSI: Remove arch_msi_check_device() No architectures implement arch_msi_check_device() or the struct msi_chip .check_device() method, so remove them. Remove the "type" parameter to pci_msi_check_device() because it was only used to call arch_msi_check_device() and is no longer needed. [bhelgaas: changelog, split to separate patch] Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit 3930115e0dd67f61b3b1882c7a34d0baeff1bb4c Author: Alexander Gordeev <agordeev@redhat.com> Date: Sun Sep 7 20:57:54 2014 +0200 irqchip: armada-370-xp: Remove arch_msi_check_device() Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs(). This makes the code more compact and allows removing arch_msi_check_device() from generic MSI code. Tested-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Jason Cooper <jason@lakedaemon.net> CC: Thomas Gleixner <tglx@linutronix.de> commit 6b2fd7efeb888fa781c1f767de6c36497ac1596b Author: Alexander Gordeev <agordeev@redhat.com> Date: Sun Sep 7 20:57:53 2014 +0200 PCI/MSI/PPC: Remove arch_msi_check_device() Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs(). This makes the code more compact and allows removing arch_msi_check_device() from generic MSI code. Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> commit 977104ece1568f2e2ad3f5fd8e55bd640e8ab55a Author: Mark Charlebois <charlebm@gmail.com> Date: Thu Sep 4 14:16:17 2014 -0700 arm: LLVMLinux: Use global stack register variable for percpu Using global current_stack_pointer works on both clang and gcc. current_stack_pointer is an unsigned long and needs to be cast as a pointer to dereference. KernelVersion: 3.17.0-rc6 Signed-off-by: Mark Charlebois <charlebm@gmail.com> Signed-off-by: Behan Webster <behanw@converseincode.com> commit a35dc594542b29935cd3a92e53233ad4ba4e622f Author: Behan Webster <behanw@converseincode.com> Date: Tue Sep 3 22:27:27 2013 -0400 arm: LLVMLinux: Use current_stack_pointer in unwind_backtrace Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and clang. KernelVersion: 3.17.0-rc6 Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> commit 5c5da6724d8e1767405a3f4b611451a11ece99e2 Author: Behan Webster <behanw@converseincode.com> Date: Tue Sep 3 22:27:27 2013 -0400 arm: LLVMLinux: Calculate current_thread_info from current_stack_pointer Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and clang. KernelVersion: 3.17.0-rc6 Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> commit f2b6d8c6c56c9a164a2d885ba34a09d613c959c9 Author: Behan Webster <behanw@converseincode.com> Date: Tue Sep 3 22:27:27 2013 -0400 arm: LLVMLinux: Use current_stack_pointer in save_stack_trace_tsk Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and clang. KernelVersion: 3.17.0-rc6 Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> commit 40802b84566a3d9731a8fea43b144301d9ac450d Author: Behan Webster <behanw@converseincode.com> Date: Tue Sep 3 22:27:27 2013 -0400 arm: LLVMLinux: Use current_stack_pointer for return_address Use the global current_stack_pointer to get the value of the stack pointer. This change supports being able to compile the kernel with both gcc and Clang. KernelVersion: 3.17.0-rc6 Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> commit d80ced5236764b8c4ffda5545d5b357cf88c77c1 Author: Behan Webster <behanw@converseincode.com> Date: Tue Sep 3 22:27:27 2013 -0400 arm: LLVMLinux: Use current_stack_pointer to calculate pt_regs address Use the global current_stack_pointer to calculate the end of the stack for current_pt_regs() KernelVersion: 3.17.0-rc6 Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> commit 9d0d6994806b36891453beb1e94b6253f853af61 Author: Behan Webster <behanw@converseincode.com> Date: Tue Sep 3 22:27:26 2013 -0400 arm: LLVMLinux: Add global named register current_stack_pointer for ARM Define a global named register for current_stack_pointer. The use of this new variable guarantees that both gcc and clang can access this register in C code. KernelVersion: 3.17.0-rc6 Signed-off-by: Behan Webster <behanw@converseincode.com> Reviewed-by: Jan-Simon Möller <dl9pf@gmx.de> Reviewed-by: Mark Charlebois <charlebm@gmail.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Nicolas Pitre <nico@linaro.org> commit 2c804d0f8fc7799981d9fdd8c88653541b28c1a7 Author: Eric Dumazet <edumazet@google.com> Date: Tue Sep 30 22:12:05 2014 -0700 ipv4: mentions skb_gro_postpull_rcsum() in inet_gro_receive() Proper CHECKSUM_COMPLETE support needs to adjust skb->csum when we remove one header. Its done using skb_gro_postpull_rcsum() In the case of IPv4, we know that the adjustment is not really needed, because the checksum over IPv4 header is 0. Lets add a comment to ease code comprehension and avoid copy/paste errors. Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit eb51bbaf8dedf142a54a7ff58514a29b40d515bb Author: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed Oct 1 17:00:49 2014 +1000 fm10k: using vmalloc requires including linux/vmalloc.h Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 078efae00ffc76381c3248006e9cf0988163488f Author: Anish Bhatt <anish@chelsio.com> Date: Mon Sep 15 17:44:18 2014 -0700 [SCSI] cxgb4i: avoid holding mutex in interrupt context cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu protected list while finding netdev. This is observed as a scheduling in atomic oops when running over ipv6. Fixes: fc8d0590d914 ("libcxgbi: Add ipv6 api to driver") Fixes: 759a0cc5a3e1 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api") Signed-off-by: Anish Bhatt <anish@chelsio.com> Signed-off-by: Karen Xie <kxie@chelsio.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: James Bottomley <JBottomley@Parallels.com> commit 34549ab09e62db9703811c6ed4715f2ffa1fd7fb Author: Jeff Layton <jlayton@primarydata.com> Date: Wed Oct 1 08:05:22 2014 -0400 nfsd: eliminate "to_delegation" define We now have cb_to_delegation and to_delegation, which do the same thing and are defined separately in different .c files. Move the cb_to_delegation definition into a header file and eliminate the redundant to_delegation definition. Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jeff Layton <jlayton@primarydata.com> commit 4a0efdc933680d908de11712a774a2c9492c3d5a Author: Hannes Reinecke <hare@suse.de> Date: Wed Oct 1 14:32:31 2014 +0200 block: misplaced rq_complete tracepoint The rq_complete tracepoint was never issued for empty requests, causing the resulting blktrace information to never show any completion for those request. Signed-off-by: Hannes Reinecke <hare@suse.de> Acked-by: Tejun Heo <tj@kernel.org> Signed-off-by: Jens Axboe <axboe@fb.com> commit fc2021fb9baf9ed375c8161b40b68e120e75c60e Author: Michael Opdenacker <michael.opdenacker@free-electrons.com> Date: Wed Oct 1 12:07:07 2014 +0200 block: hd: remove deprecated IRQF_DISABLED This patch removes the use of the IRQF_DISABLED flag from drivers/block/hd.c It's a NOOP since 2.6.35 and it will be removed one day. This also removes a related comment which is obsolete too. Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com> Signed-off-by: Jens Axboe <axboe@fb.com> commit 19aeb5a65f1a6504fc665466c188241e7393d66f Author: Bob Peterson <rpeterso@redhat.com> Date: Mon Sep 29 08:52:04 2014 -0400 GFS2: Make rename not save dirent location This patch fixes a regression in the patch "GFS2: Remember directory insert point", commit 2b47dad866d04f14c328f888ba5406057b8c7d33. The problem had to do with the rename function: The function found space for the new dirent, and remembered that location. But then the old dirent was removed, which often moved the eligible location for the renamed dirent. Putting the new dirent at the saved location caused file system corruption. This patch adds a new "save_loc" variable to struct gfs2_diradd. If 1, the dirent location is saved. If 0, the dirent location is not saved and the buffer_head is released as per previous behavior. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> commit 5235166fbc332c8b5dcf49e3a498a8b510a77449 Author: Oliver Neukum <oneukum@suse.de> Date: Tue Sep 30 12:54:56 2014 +0200 HID: usbhid: add another mouse that needs QUIRK_ALWAYS_POLL There is a second mouse sharing the same vendor strings but different IDs. Signed-off-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz> commit 2013add4ce73c93ae2148969a9ec3ecc8b1e26fa Author: Gavin Shan <gwshan@linux.vnet.ibm.com> Date: Wed Oct 1 14:34:51 2014 +1000 powerpc/eeh: Show hex prefix for PE state sysfs As Michael suggested, the hex prefix for the output of EEH PE state sysfs entry (/sys/bus/pci/devices/xxx/eeh_pe_state) is always informative to users. Suggested-by: Michael Ellerman <mpe@ellerman.id.au> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> commit 24c20f10583647e30afe87b6f6d5e14bc7b1cbc6 Author: Christoph Hellwig <hch@lst.de> Date: Tue Sep 30 16:43:46 2014 +0200 scsi: add a CONFIG_SCSI_MQ_DEFAULT option Add a Kconfig option to enable the blk-mq path for SCSI by default to ease testing and deployment in setups that know they benefit from blk-mq. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Robert Elliott <elliott@hp.com> Tested-by: Robert Elliott <elliott@hp.com> commit e785060ea3a1c8e37a8bc1449c79e36bff2b5b13 Author: Dolev Raviv <draviv@codeaurora.org> Date: Thu Sep 25 15:32:36 2014 +0300 ufs: definitions for phy interface - Adding some of the definitions missing in unipro.h, including power enumeration. - Read Modify Write Line helper function - Indication for the type of suspend Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 374a246e4ebda1fc55d537877bf2412e511ecc7b Author: Subhash Jadavani <subhashj@codeaurora.org> Date: Thu Sep 25 15:32:35 2014 +0300 ufs: tune bkops while power managment events Add capability to control the auto bkops during suspend. If host explicitly enables the auto bkops (background operation) on device then only device would perform the bkops on its own. If auto bkops is not enabled explicitly and if the device reaches to state where it must do background operation, device would raise the urgent bkops exception event to host and then host will enable the auto bkops on device. This patch adds the option to choose whether auto bkops should be enabled during runtime suspend or not. Since we don't want to keep the device active to perform the non critical bkops, host will enable urgent bkops only. Keep auto-bkops enabled after resume if urgent bkops needed. If device bkops status shows that its in critical need of executing background operations, host should allow the device to continue doing background operations. Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 856b348305c98d4e0c8e5eafa97c61443197f8d3 Author: Sahitya Tummala <stummala@codeaurora.org> Date: Thu Sep 25 15:32:34 2014 +0300 ufs: Add support for clock scaling using devfreq framework The clocks for UFS device will be managed by generic DVFS (Dynamic Voltage and Frequency Scaling) framework within kernel. This devfreq framework works with different governors to scale the clocks. By default, UFS devices uses simple_ondemand governor which scales the clocks up if the load is more than upthreshold and scales down if the load is less than downthreshold. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 4cff6d991e4a291cf50fe2659da2ea9ad46620bf Author: Sahitya Tummala <stummala@codeaurora.org> Date: Thu Sep 25 15:32:33 2014 +0300 ufs: Add freq-table-hz property for UFS device Add freq-table-hz propery for UFS device to keep track of <min max> frequencies supported by UFS clocks. Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 1ab27c9cf8b63dd8dec9e17b5c17721c7f3b6cc7 Author: Sahitya Tummala <stummala@codeaurora.org> Date: Thu Sep 25 15:32:32 2014 +0300 ufs: Add support for clock gating The UFS controller clocks can be gated after certain period of inactivity, which is typically less than runtime suspend timeout. In addition to clocks the link will also be put into Hibern8 mode to save more power. The clock gating can be turned on by enabling the capability UFSHCD_CAP_CLK_GATING. To enable entering into Hibern8 mode as part of clock gating, set the capability UFSHCD_CAP_HIBERN8_WITH_CLK_GATING. The tracing events for clock gating can be enabled through debugfs as: echo 1 > /sys/kernel/debug/tracing/events/ufs/ufshcd_clk_gating/enable cat /sys/kernel/debug/tracing/trace_pipe Signed-off-by: Sahitya Tummala <stummala@codeaurora.org> Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 7eb584db73bebbc9852a14341431ed6935419bec Author: Dolev Raviv <draviv@codeaurora.org> Date: Thu Sep 25 15:32:31 2014 +0300 ufs: refactor configuring power mode Sometimes, the device shall report its maximum power and speed capabilities, but we might not wish to configure it to use those maximum capabilities. This change adds support for the vendor specific host driver to implement power change notify callback. To enable configuring different power modes (number of lanes, gear number and fast/slow modes) it is necessary to split the configuration stage from the stage that reads the device max power mode. In addition, it is not required to read the configuration more than once, thus the configuration is stored after reading it once. Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 57d104c153d3d6d7bea60089e80f37501851ed2c Author: Subhash Jadavani <subhashj@codeaurora.org> Date: Thu Sep 25 15:32:30 2014 +0300 ufs: add UFS power management support This patch adds support for UFS device and UniPro link power management during runtime/system PM. Main idea is to define multiple UFS low power levels based on UFS device and UFS link power states. This would allow any specific platform or pci driver to choose the best suited low power level during runtime and system suspend based on their power goals. bkops handlig: To put the UFS device in sleep state when bkops is disabled, first query the bkops status from the device and enable bkops on device only if device needs time to perform the bkops. START_STOP handling: Before sending START_STOP_UNIT to the device well-known logical unit (w-lun) to make sure that the device w-lun unit attention condition is cleared. Write protection: UFS device specification allows LUs to be write protected, either permanently or power on write protected. If any LU is power on write protected and if the card is power cycled (by powering off VCCQ and/or VCC rails), LU's write protect status would be lost. So this means those LUs can be written now. To ensures that UFS device is power cycled only if the power on protect is not set for any of the LUs, check if power on write protect is set and if device is in sleep/power-off state & link in inactive state (Hibern8 or OFF state). If none of the Logical Units on UFS device is power on write protected then all UFS device power rails (VCC, VCCQ & VCCQ2) can be turned off if UFS device is in power-off state and UFS link is in OFF state. But current implementation would disable all device power rails even if UFS link is not in OFF state. Low power mode: If UFS link is in OFF state then UFS host controller can be power collapsed to avoid leakage current from it. Note that if UFS host controller is power collapsed, full UFS reinitialization will be required on resume to re-establish the link between host and device. Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 0ce147d48a3e3352859f0c185e98e8392bee7a25 Author: Subhash Jadavani <subhashj@codeaurora.org> Date: Thu Sep 25 15:32:29 2014 +0300 ufs: introduce well known logical unit in ufs UFS device may have standard LUs and LUN id could be from 0x00 to 0x7F. UFS device specification use "Peripheral Device Addressing Format" (SCSI SAM-5) for standard LUs. UFS device may also have the Well Known LUs (also referred as W-LU) which again could be from 0x00 to 0x7F. For W-LUs, UFS device specification only allows the "Extended Addressing Format" (SCSI SAM-5) which means the W-LUNs would start from 0xC100 onwards. This means max. LUN number reported from UFS device could be 0xC17F hence this patch advertise the "max_lun" as 0xC17F which will allow SCSI mid layer to detect the W-LUs as well. But once the W-LUs are detected, UFSHCD driver may get the commands with SCSI LUN id upto 0xC17F but UPIU LUN id field is only 8-bit wide so it requires the mapping of SCSI LUN id to UPIU LUN id. This patch also add support for this mapping. Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Signed-off-by: Christoph Hellwig <hch@lst.de> commit 2a8fa600445c45222632810a4811ce820279d106 Author: Subhash Jadavani <su…
pstglia
pushed a commit
to pstglia/linux
that referenced
this pull request
Oct 6, 2014
This reverts commit 716fb91. That commit caused a regression which would end up in a kernel BUG() as below: [ 101.554300] g_ether gadget: full-speed config #1: CDC Subset/SAFE [ 101.585186] ------------[ cut here ]------------ [ 101.600587] kernel BUG at include/linux/netdevice.h:495! [ 101.615850] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM [ 101.645539] Modules linked in: [ 101.660483] CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1+ torvalds#104 [ 101.690175] task: c05dc5c8 ti: c05d2000 task.ti: c05d2000 [ 101.705579] PC is at eth_start+0x64/0x8c [ 101.720981] LR is at __netif_schedule+0x7c/0x90 [ 101.736455] pc : [<c0299174>] lr : [<c036a134>] psr: 60000093 [ 101.736455] sp : c05d3d18 ip : c05d3cf8 fp : c05d3d2c [ 101.782340] r10: 00000000 r9 : c196c1f0 r8 : c196c1a0 [ 101.797823] r7 : 00000000 r6 : 00000002 r5 : c1976400 r4 : c1976400 [ 101.828058] r3 : 00000000 r2 : c05d3ce8 r1 : 00000001 r0 : 00000002 [ 101.858722] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel Reported-by: Robert Jarzmik <robert.jarzmik@free.fr> Signed-of-by: Felipe Balbi <balbi@ti.com>
torvalds
pushed a commit
that referenced
this pull request
Nov 7, 2014
If PM_RUNTIME is enabled, it is easy to trigger the following backtrace on pxa2xx hosts: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8() Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104 [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14) [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c) [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24) [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8) [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34) [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54) [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74) [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8) [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208) [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0) [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8) [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc) [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc) [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4) [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec) [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24) ---[ end trace 46524156d8faa4f6 ]--- This happens because suspend function tries to disable a clock that is already disabled by runtime_suspend callback. Add if (!pm_runtime_suspended()) checks to suspend/resume path. Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM) Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Reported-by: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
dabrace
referenced
this pull request
in dabrace/linux
Nov 10, 2014
If PM_RUNTIME is enabled, it is easy to trigger the following backtrace on pxa2xx hosts: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8() Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104 [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14) [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c) [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24) [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8) [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34) [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54) [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74) [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8) [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208) [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0) [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8) [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc) [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc) [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4) [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec) [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24) ---[ end trace 46524156d8faa4f6 ]--- This happens because suspend function tries to disable a clock that is already disabled by runtime_suspend callback. Add if (!pm_runtime_suspended()) checks to suspend/resume path. Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM) Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Reported-by: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org
kernelOfTruth
pushed a commit
to kernelOfTruth/linux
that referenced
this pull request
Nov 14, 2014
commit 2b9375b upstream. If PM_RUNTIME is enabled, it is easy to trigger the following backtrace on pxa2xx hosts: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8() Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty torvalds#104 [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14) [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c) [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24) [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8) [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34) [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54) [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74) [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8) [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208) [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0) [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8) [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc) [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc) [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4) [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec) [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24) ---[ end trace 46524156d8faa4f6 ]--- This happens because suspend function tries to disable a clock that is already disabled by runtime_suspend callback. Add if (!pm_runtime_suspended()) checks to suspend/resume path. Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM) Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Reported-by: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mdrjr
referenced
this pull request
in hardkernel/linux
Nov 21, 2014
commit 2b9375b upstream. If PM_RUNTIME is enabled, it is easy to trigger the following backtrace on pxa2xx hosts: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8() Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104 [<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14) [<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c) [<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24) [<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8) [<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34) [<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54) [<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74) [<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8) [<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208) [<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0) [<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8) [<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc) [<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc) [<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4) [<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec) [<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24) ---[ end trace 46524156d8faa4f6 ]--- This happens because suspend function tries to disable a clock that is already disabled by runtime_suspend callback. Add if (!pm_runtime_suspended()) checks to suspend/resume path. Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM) Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Reported-by: Andrea Adami <andrea.adami@gmail.com> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sashalevin
added a commit
to sashalevin/linux-stable-security
that referenced
this pull request
Apr 29, 2016
[ Upstream commit 84768ed ] l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha torvalds#104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
sashalevin
added a commit
to sashalevin/linux-stable-security
that referenced
this pull request
Apr 29, 2016
[ Upstream commit 84768ed ] l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha torvalds#104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
sashalevin
added a commit
to sashalevin/linux-stable-security
that referenced
this pull request
Apr 29, 2016
[ Upstream commit 84768ed ] l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha torvalds#104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 4, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a ("bpf: allow bpf programs to tail-call other bpf programs"). bpf_tail_call() arguments: ctx - context pointer passed to next program array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY index - index inside array that selects specific program to run In this implementation arm64 JIT jumps into callee program after prologue, so callee program reuses the same stack. For tail_call_cnt, we use the callee-saved R26 (which was already saved/restored but previously unused by JIT). With this patch a tail call generates the following code on arm64: if (index >= array->map.max_entries) goto out; 34: mov x10, #0x10 // torvalds#16 38: ldr w10, [x1,x10] 3c: cmp w2, w10 40: b.ge 0x0000000000000074 if (tail_call_cnt > MAX_TAIL_CALL_CNT) goto out; tail_call_cnt++; 44: mov x10, #0x20 // torvalds#32 48: cmp x26, x10 4c: b.gt 0x0000000000000074 50: add x26, x26, #0x1 prog = array->ptrs[index]; if (prog == NULL) goto out; 54: mov x10, #0x68 // torvalds#104 58: ldr x10, [x1,x10] 5c: ldr x11, [x10,x2] 60: cbz x11, 0x0000000000000074 goto *(prog->bpf_func + prologue_size); 64: mov x10, #0x20 // torvalds#32 68: ldr x10, [x11,x10] 6c: add x10, x10, #0x20 70: br x10 74: Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
zlim
added a commit
to zlim/linux
that referenced
this pull request
Jun 7, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a ("bpf: allow bpf programs to tail-call other bpf programs"). bpf_tail_call() arguments: ctx - context pointer passed to next program array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY index - index inside array that selects specific program to run In this implementation arm64 JIT jumps into callee program after prologue, so callee program reuses the same stack. For tail_call_cnt, we use the callee-saved R26 (which was already saved/restored but previously unused by JIT). With this patch a tail call generates the following code on arm64: if (index >= array->map.max_entries) goto out; 34: mov x10, #0x10 // torvalds#16 38: ldr w10, [x1,x10] 3c: cmp w2, w10 40: b.ge 0x0000000000000074 if (tail_call_cnt > MAX_TAIL_CALL_CNT) goto out; tail_call_cnt++; 44: mov x10, #0x20 // torvalds#32 48: cmp x26, x10 4c: b.gt 0x0000000000000074 50: add x26, x26, #0x1 prog = array->ptrs[index]; if (prog == NULL) goto out; 54: mov x10, #0x68 // torvalds#104 58: ldr x10, [x1,x10] 5c: ldr x11, [x10,x2] 60: cbz x11, 0x0000000000000074 goto *(prog->bpf_func + prologue_size); 64: mov x10, #0x20 // torvalds#32 68: ldr x10, [x11,x10] 6c: add x10, x10, #0x20 70: br x10 74: Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
zlim
added a commit
to zlim/linux
that referenced
this pull request
Jun 9, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a ("bpf: allow bpf programs to tail-call other bpf programs"). bpf_tail_call() arguments: ctx - context pointer passed to next program array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY index - index inside array that selects specific program to run In this implementation arm64 JIT jumps into callee program after prologue, so callee program reuses the same stack. For tail_call_cnt, we use the callee-saved R26 (which was already saved/restored but previously unused by JIT). With this patch a tail call generates the following code on arm64: if (index >= array->map.max_entries) goto out; 34: mov x10, #0x10 // torvalds#16 38: ldr w10, [x1,x10] 3c: cmp w2, w10 40: b.ge 0x0000000000000074 if (tail_call_cnt > MAX_TAIL_CALL_CNT) goto out; tail_call_cnt++; 44: mov x10, #0x20 // torvalds#32 48: cmp x26, x10 4c: b.gt 0x0000000000000074 50: add x26, x26, #0x1 prog = array->ptrs[index]; if (prog == NULL) goto out; 54: mov x10, #0x68 // torvalds#104 58: ldr x10, [x1,x10] 5c: ldr x11, [x10,x2] 60: cbz x11, 0x0000000000000074 goto *(prog->bpf_func + prologue_size); 64: mov x10, #0x20 // torvalds#32 68: ldr x10, [x11,x10] 6c: add x10, x10, #0x20 70: br x10 74: Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 9, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a ("bpf: allow bpf programs to tail-call other bpf programs"). bpf_tail_call() arguments: ctx - context pointer passed to next program array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY index - index inside array that selects specific program to run In this implementation arm64 JIT jumps into callee program after prologue, so callee program reuses the same stack. For tail_call_cnt, we use the callee-saved R26 (which was already saved/restored but previously unused by JIT). With this patch a tail call generates the following code on arm64: if (index >= array->map.max_entries) goto out; 34: mov x10, #0x10 // torvalds#16 38: ldr w10, [x1,x10] 3c: cmp w2, w10 40: b.ge 0x0000000000000074 if (tail_call_cnt > MAX_TAIL_CALL_CNT) goto out; tail_call_cnt++; 44: mov x10, #0x20 // torvalds#32 48: cmp x26, x10 4c: b.gt 0x0000000000000074 50: add x26, x26, #0x1 prog = array->ptrs[index]; if (prog == NULL) goto out; 54: mov x10, #0x68 // torvalds#104 58: ldr x10, [x1,x10] 5c: ldr x11, [x10,x2] 60: cbz x11, 0x0000000000000074 goto *(prog->bpf_func + prologue_size); 64: mov x10, #0x20 // torvalds#32 68: ldr x10, [x11,x10] 6c: add x10, x10, #0x20 70: br x10 74: Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com>
0day-ci
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jun 11, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a ("bpf: allow bpf programs to tail-call other bpf programs"). bpf_tail_call() arguments: ctx - context pointer passed to next program array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY index - index inside array that selects specific program to run In this implementation arm64 JIT jumps into callee program after prologue, so callee program reuses the same stack. For tail_call_cnt, we use the callee-saved R26 (which was already saved/restored but previously unused by JIT). With this patch a tail call generates the following code on arm64: if (index >= array->map.max_entries) goto out; 34: mov x10, #0x10 // torvalds#16 38: ldr w10, [x1,x10] 3c: cmp w2, w10 40: b.ge 0x0000000000000074 if (tail_call_cnt > MAX_TAIL_CALL_CNT) goto out; tail_call_cnt++; 44: mov x10, #0x20 // torvalds#32 48: cmp x26, x10 4c: b.gt 0x0000000000000074 50: add x26, x26, #0x1 prog = array->ptrs[index]; if (prog == NULL) goto out; 54: mov x10, #0x68 // torvalds#104 58: ldr x10, [x1,x10] 5c: ldr x11, [x10,x2] 60: cbz x11, 0x0000000000000074 goto *(prog->bpf_func + prologue_size); 64: mov x10, #0x20 // torvalds#32 68: ldr x10, [x11,x10] 6c: add x10, x10, #0x20 70: br x10 74: Signed-off-by: Zi Shen Lim <zlim.lnx@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
torvalds
pushed a commit
that referenced
this pull request
Aug 13, 2016
When nvme_delete_queue fails in the first pass of the nvme_disable_io_queues() loop, we return early, failing to suspend all of the IO queues. Later, on the nvme_pci_disable path, this causes us to disable MSI without actually having freed all the IRQs, which triggers the BUG_ON in free_msi_irqs(), as show below. This patch refactors nvme_disable_io_queues to suspend all queues before start submitting delete queue commands. This way, we ensure that we have at least returned every IRQ before continuing with the removal path. [ 487.529200] kernel BUG at ../drivers/pci/msi.c:368! cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650] pc: c000000000627a50: free_msi_irqs+0x90/0x200 lr: c000000000627a40: free_msi_irqs+0x80/0x200 sp: c0000078c5b838d0 msr: 9000000100029033 current = 0xc0000078c5b40000 paca = 0xc000000002bd7600 softe: 0 irq_happened: 0x01 pid = 1376, comm = kworker/70:1H kernel BUG at ../drivers/pci/msi.c:368! Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413 (Ubuntu/IBM 5.3.1-14ubuntu2.1) ) #104 SMP Fri Jul 29 09:20:17 CDT 2016 enter ? for help [c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme] [c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme] [c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110 [c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170 [c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110 [c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0 [c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590 [c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660 [c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130 [c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Brian King <brking@linux.vnet.ibm.com> Cc: Keith Busch <keith.busch@intel.com> Cc: linux-nvme@lists.infradead.org Signed-off-by: Jens Axboe <axboe@fb.com>
bgly
pushed a commit
to powervm/ibmvscsis
that referenced
this pull request
Nov 2, 2016
BugLink: http://bugs.launchpad.net/bugs/1602724 When nvme_delete_queue fails in the first pass of the nvme_disable_io_queues() loop, we return early, failing to suspend all of the IO queues. Later, on the nvme_pci_disable path, this causes us to disable MSI without actually having freed all the IRQs, which triggers the BUG_ON in free_msi_irqs(), as show below. This patch refactors nvme_disable_io_queues to suspend all queues before start submitting delete queue commands. This way, we ensure that we have at least returned every IRQ before continuing with the removal path. [ 487.529200] kernel BUG at ../drivers/pci/msi.c:368! cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650] pc: c000000000627a50: free_msi_irqs+0x90/0x200 lr: c000000000627a40: free_msi_irqs+0x80/0x200 sp: c0000078c5b838d0 msr: 9000000100029033 current = 0xc0000078c5b40000 paca = 0xc000000002bd7600 softe: 0 irq_happened: 0x01 pid = 1376, comm = kworker/70:1H kernel BUG at ../drivers/pci/msi.c:368! Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413 (Ubuntu/IBM 5.3.1-14ubuntu2.1) ) torvalds#104 SMP Fri Jul 29 09:20:17 CDT 2016 enter ? for help [c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme] [c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme] [c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110 [c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170 [c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110 [c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0 [c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590 [c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660 [c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130 [c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Cc: Brian King <brking@linux.vnet.ibm.com> Cc: Keith Busch <keith.busch@intel.com> Cc: linux-nvme@lists.infradead.org Signed-off-by: Jens Axboe <axboe@fb.com> (cherry picked from commit c21377f) Signed-off-by: Tim Gardner <tim.gardner@canonical.com> Acked-by: Stefan Bader <stefan.bader@canonical.com> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
laijs
pushed a commit
to laijs/linux
that referenced
this pull request
Feb 13, 2017
lkl: Don't specify different compiler/linker flags for elf32-littlearm.
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Apr 22, 2017
systemd-sysctl is triggering a suspicious RCU usage message when net.ipv4.tcp_early_demux or net.ipv4.udp_early_demux is changed via a sysctl config file: [ 33.896184] =============================== [ 33.899558] [ ERR: suspicious RCU usage. ] [ 33.900624] 4.11.0-rc7+ torvalds#104 Not tainted [ 33.901698] ------------------------------- [ 33.903059] /home/dsa/kernel-2.git/net/ipv4/sysctl_net_ipv4.c:305 suspicious rcu_dereference_check() usage! [ 33.905724] other info that might help us debug this: [ 33.907656] rcu_scheduler_active = 2, debug_locks = 0 [ 33.909288] 1 lock held by systemd-sysctl/143: [ 33.910373] #0: (sb_writers#5){.+.+.+}, at: [<ffffffff8123a370>] file_start_write+0x45/0x48 [ 33.912407] stack backtrace: [ 33.914018] CPU: 0 PID: 143 Comm: systemd-sysctl Not tainted 4.11.0-rc7+ torvalds#104 [ 33.915631] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014 [ 33.917870] Call Trace: [ 33.918431] dump_stack+0x81/0xb6 [ 33.919241] lockdep_rcu_suspicious+0x10f/0x118 [ 33.920263] proc_configure_early_demux+0x65/0x10a [ 33.921391] proc_udp_early_demux+0x3a/0x41 add rcu locking to proc_configure_early_demux. Fixes: dddb64b ("net: Add sysctl to toggle early demux for tcp and udp") Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 21, 2018
GIT dda3e15231b35840fe6f0973f803cc70ddb86281 commit b0f2853b56a2acaff19cca2c6a608f8ec268d21a Author: Christoph Hellwig <hch@lst.de> Date: Wed Jan 17 22:04:38 2018 +0100 nvme-pci: take sglist coalescing in dma_map_sg into account Some iommu implementations can merge physically and/or virtually contiguous segments inside sg_map_dma. The NVMe SGL support does not take this into account and will warn because of falling off a loop. Pass the number of mapped segments to nvme_pci_setup_sgls so that the SGL setup can take the number of mapped segments into account. Reported-by: Fangjian (Turing) <f.fangjian@huawei.com> Fixes: a7a7cbe3 ("nvme-pci: add SGL support") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Keith Busch <keith.busch@intel.com> Reviewed-by: Sagi Grimberg <sagi@rimberg.me> Signed-off-by: Jens Axboe <axboe@kernel.dk> commit 20469a37aed12a886d0deda5a07c04037923144a Author: Keith Busch <keith.busch@intel.com> Date: Wed Jan 17 22:04:37 2018 +0100 nvme-pci: check segement valid for SGL use The driver needs to verify there is a payload with a command before seeing if it should use SGLs to map it. Fixes: 955b1b5a00ba ("nvme-pci: move use_sgl initialization to nvme_init_iod()") Reported-by: Paul Menzel <pmenzel+linux-nvme@molgen.mpg.de> Reviewed-by: Paul Menzel <pmenzel+linux-nvme@molgen.mpg.de> Signed-off-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Jens Axboe <axboe@kernel.dk> commit 091f02483df7b56615b524491f404e574c5e0668 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 12:11:26 2018 +0000 ARM: net: bpf: clarify tail_call index As per 90caccdd8cc0 ("bpf: fix bpf_tail_call() x64 JIT"), the index used for array lookup is defined to be 32-bit wide. Update a misleading comment that suggests it is 64-bit wide. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit ec19e02b343db991d2d1610c409efefebf4e2ca9 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 21:06:16 2018 +0000 ARM: net: bpf: fix LDX instructions When the source and destination register are identical, our JIT does not generate correct code, which leads to kernel oopses. Fix this by (a) generating more efficient code, and (b) making use of the temporary earlier if we will overwrite the address register. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 02088d9b392f605c892894b46aa8c83e3abd0115 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 22:38:18 2018 +0000 ARM: net: bpf: fix register saving When an eBPF program tail-calls another eBPF program, it enters it after the prologue to avoid having complex stack manipulations. This can lead to kernel oopses, and similar. Resolve this by always using a fixed stack layout, a CPU register frame pointer, and using this when reloading registers before returning. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 0005e55a79cfda88199e41a406a829c88d708c67 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 22:51:27 2018 +0000 ARM: net: bpf: correct stack layout documentation The stack layout documentation incorrectly suggests that the BPF JIT scratch space starts immediately below BPF_FP. This is not correct, so let's fix the documentation to reflect reality. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 70ec3a6c2c11e4b0e107a65de943a082f9aff351 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 21:26:14 2018 +0000 ARM: net: bpf: move stack documentation Move the stack documentation towards the top of the file, where it's relevant for things like the register layout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit d1220efd23484c72c82d5471f05daeb35b5d1916 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 16:10:07 2018 +0000 ARM: net: bpf: fix stack alignment As per 2dede2d8e925 ("ARM EABI: stack pointer must be 64-bit aligned after a CPU exception") the stack should be aligned to a 64-bit boundary on EABI systems. Ensure that the eBPF JIT appropraitely aligns the stack. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit f4483f2cc1fdc03488c8a1452e545545ae5bda93 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 11:39:54 2018 +0000 ARM: net: bpf: fix tail call jumps When a tail call fails, it is documented that the tail call should continue execution at the following instruction. An example tail call sequence is: 12: (85) call bpf_tail_call#12 13: (b7) r0 = 0 14: (95) exit The ARM assembler for the tail call in this case ends up branching to instruction 14 instead of instruction 13, resulting in the BPF filter returning a non-zero value: 178: ldr r8, [sp, #588] ; insn 12 17c: ldr r6, [r8, r6] 180: ldr r8, [sp, #580] 184: cmp r8, r6 188: bcs 0x1e8 18c: ldr r6, [sp, #524] 190: ldr r7, [sp, #528] 194: cmp r7, #0 198: cmpeq r6, #32 19c: bhi 0x1e8 1a0: adds r6, r6, #1 1a4: adc r7, r7, #0 1a8: str r6, [sp, #524] 1ac: str r7, [sp, #528] 1b0: mov r6, #104 1b4: ldr r8, [sp, #588] 1b8: add r6, r8, r6 1bc: ldr r8, [sp, #580] 1c0: lsl r7, r8, #2 1c4: ldr r6, [r6, r7] 1c8: cmp r6, #0 1cc: beq 0x1e8 1d0: mov r8, #32 1d4: ldr r6, [r6, r8] 1d8: add r6, r6, #44 1dc: bx r6 1e0: mov r0, #0 ; insn 13 1e4: mov r1, #0 1e8: add sp, sp, #596 ; insn 14 1ec: pop {r4, r5, r6, r7, r8, sl, pc} For other sequences, the tail call could end up branching midway through the following BPF instructions, or maybe off the end of the function, leading to unknown behaviours. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit e9062481824384f00299971f923fecf6b3668001 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 11:35:15 2018 +0000 ARM: net: bpf: avoid 'bx' instruction on non-Thumb capable CPUs Avoid the 'bx' instruction on CPUs that have no support for Thumb and thus do not implement this instruction by moving the generation of this opcode to a separate function that selects between: bx reg and mov pc, reg according to the capabilities of the CPU. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 45d55e7bac4028af93f5fa324e69958a0b868e96 Author: Thomas Gleixner <tglx@linutronix.de> Date: Tue Jan 16 12:20:18 2018 +0100 x86/apic/vector: Fix off by one in error path Keith reported the following warning: WARNING: CPU: 28 PID: 1420 at kernel/irq/matrix.c:222 irq_matrix_remove_managed+0x10f/0x120 x86_vector_free_irqs+0xa1/0x180 x86_vector_alloc_irqs+0x1e4/0x3a0 msi_domain_alloc+0x62/0x130 The reason for this is that if the vector allocation fails the error handling code tries to free the failed vector as well, which causes the above imbalance warning to trigger. Adjust the error path to handle this correctly. Fixes: b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors") Reported-by: Keith Busch <keith.busch@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Keith Busch <keith.busch@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161217300.1823@nanos commit d47924417319e3b6a728c0b690f183e75bc2a702 Author: Thomas Gleixner <tglx@linutronix.de> Date: Tue Jan 16 19:59:59 2018 +0100 x86/intel_rdt/cqm: Prevent use after free intel_rdt_iffline_cpu() -> domain_remove_cpu() frees memory first and then proceeds accessing it. BUG: KASAN: use-after-free in find_first_bit+0x1f/0x80 Read of size 8 at addr ffff883ff7c1e780 by task cpuhp/31/195 find_first_bit+0x1f/0x80 has_busy_rmid+0x47/0x70 intel_rdt_offline_cpu+0x4b4/0x510 Freed by task 195: kfree+0x94/0x1a0 intel_rdt_offline_cpu+0x17d/0x510 Do the teardown first and then free memory. Fixes: 24247aeeabe9 ("x86/intel_rdt/cqm: Improve limbo list processing") Reported-by: Joseph Salisbury <joseph.salisbury@canonical.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Ravi Shankar <ravi.v.shankar@intel.com> Cc: Peter Zilstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Vikas Shivappa <vikas.shivappa@linux.intel.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: "Roderick W. Smith" <rod.smith@canonical.com> Cc: 1733662@bugs.launchpad.net Cc: Fenghua Yu <fenghua.yu@intel.com> Cc: Tony Luck <tony.luck@intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161957510.2366@nanos commit 6cfb521ac0d5b97470883ff9b7facae264b7ab12 Author: Andi Kleen <ak@linux.intel.com> Date: Tue Jan 16 12:52:28 2018 -0800 module: Add retpoline tag to VERMAGIC Add a marker for retpoline to the module VERMAGIC. This catches the case when a non RETPOLINE compiled module gets loaded into a retpoline kernel, making it insecure. It doesn't handle the case when retpoline has been runtime disabled. Even in this case the match of the retcompile status will be enforced. This implies that even with retpoline run time disabled all modules loaded need to be recompiled. Signed-off-by: Andi Kleen <ak@linux.intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Cc: rusty@rustcorp.com.au Cc: arjan.van.de.ven@intel.com Cc: jeyu@kernel.org Cc: torvalds@linux-foundation.org Link: https://lkml.kernel.org/r/20180116205228.4890-1-andi@firstfloor.org commit 4fdec2034b7540dda461c6ba33325dfcff345c64 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Tue Jan 16 16:42:25 2018 +0100 x86/cpufeature: Move processor tracing out of scattered features Processor tracing is already enumerated in word 9 (CPUID[7,0].EBX), so do not duplicate it in the scattered features word. Besides being more tidy, this will be useful for KVM when it presents processor tracing to the guests. KVM selects host features that are supported by both the host kernel (depending on command line options, CPU errata, or whatever) and KVM. Whenever a full feature word exists, KVM's code is written in the expectation that the CPUID bit number matches the X86_FEATURE_* bit number, but this is not the case for X86_FEATURE_INTEL_PT. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Cc: Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Luwei Kang <luwei.kang@intel.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: kvm@vger.kernel.org Link: http://lkml.kernel.org/r/1516117345-34561-1-git-send-email-pbonzini@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> commit 07c7b6a52503ac13ae357a8b3ef3456590a64b65 Author: Linus Walleij <linus.walleij@linaro.org> Date: Tue Jan 16 09:51:51 2018 +0100 gpio: mmio: Also read bits that are zero The code for .get_multiple() has bugs: 1. The simple .get_multiple() just reads a register, masks it and sets the return value. This is not correct: we only want to assign values (whether 0 or 1) to the bits that are set in the mask. Fix this by using &= ~mask to clear all bits in the mask and then |= val & mask to set the corresponding bits from the read. 2. The bgpio_get_multiple_be() call has a similar problem: it uses the |= operator to set the bits, so only the bits in the mask are affected, but it misses to clear all returned bits from the mask initially, so some bits will be returned erroneously set to 1. 3. The bgpio_get_set_multiple() again fails to clear the bits from the mask. 4. find_next_bit() wasn't handled correctly, use a totally different approach for one function and change the other function to follow the design pattern of assigning the first bit to -1, then use bit + 1 in the for loop and < num_iterations as break condition. Fixes: 80057cb417b2 ("gpio-mmio: Use the new .get_multiple() callback") Cc: Bartosz Golaszewski <brgl@bgdev.pl> Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com> Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com> Reported-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> commit 81d947e2b8dd2394586c3eaffdd2357797d3bf59 Author: Daniel Borkmann <daniel@iogearbox.net> Date: Mon Jan 15 23:12:09 2018 +0100 net, sched: fix panic when updating miniq {b,q}stats While working on fixing another bug, I ran into the following panic on arm64 by simply attaching clsact qdisc, adding a filter and running traffic on ingress to it: [...] [ 178.188591] Unable to handle kernel read from unreadable memory at virtual address 810fb501f000 [ 178.197314] Mem abort info: [ 178.200121] ESR = 0x96000004 [ 178.203168] Exception class = DABT (current EL), IL = 32 bits [ 178.209095] SET = 0, FnV = 0 [ 178.212157] EA = 0, S1PTW = 0 [ 178.215288] Data abort info: [ 178.218175] ISV = 0, ISS = 0x00000004 [ 178.222019] CM = 0, WnR = 0 [ 178.224997] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000023cb3f33 [ 178.231531] [0000810fb501f000] *pgd=0000000000000000 [ 178.236508] Internal error: Oops: 96000004 [#1] SMP [...] [ 178.311855] CPU: 73 PID: 2497 Comm: ping Tainted: G W 4.15.0-rc7+ #5 [ 178.319413] Hardware name: FOXCONN R2-1221R-A4/C2U4N_MB, BIOS G31FB18A 03/31/2017 [ 178.326887] pstate: 60400005 (nZCv daif +PAN -UAO) [ 178.331685] pc : __netif_receive_skb_core+0x49c/0xac8 [ 178.336728] lr : __netif_receive_skb+0x28/0x78 [ 178.341161] sp : ffff00002344b750 [ 178.344465] x29: ffff00002344b750 x28: ffff810fbdfd0580 [ 178.349769] x27: 0000000000000000 x26: ffff000009378000 [...] [ 178.418715] x1 : 0000000000000054 x0 : 0000000000000000 [ 178.424020] Process ping (pid: 2497, stack limit = 0x000000009f0a3ff4) [ 178.430537] Call trace: [ 178.432976] __netif_receive_skb_core+0x49c/0xac8 [ 178.437670] __netif_receive_skb+0x28/0x78 [ 178.441757] process_backlog+0x9c/0x160 [ 178.445584] net_rx_action+0x2f8/0x3f0 [...] Reason is that sch_ingress and sch_clsact are doing mini_qdisc_pair_init() which sets up miniq pointers to cpu_{b,q}stats from the underlying qdisc. Problem is that this cannot work since they are actually set up right after the qdisc ->init() callback in qdisc_create(), so first packet going into sch_handle_ingress() tries to call mini_qdisc_bstats_cpu_update() and we therefore panic. In order to fix this, allocation of {b,q}stats needs to happen before we call into ->init(). In net-next, there's already such option through commit d59f5ffa59d8 ("net: sched: a dflt qdisc may be used with per cpu stats"). However, the bug needs to be fixed in net still for 4.15. Thus, include these bits to reduce any merge churn and reuse the static_flags field to set TCQ_F_CPUSTATS, and remove the allocation from qdisc_create() since there is no other user left. Prashant Bhole ran into the same issue but for net-next, thus adding him below as well as co-author. Same issue was also reported by Sandipan Das when using bcc. Fixes: 46209401f8f6 ("net: core: introduce mini_Qdisc and eliminate usage of tp->q for clsact fastpath") Reference: https://lists.iovisor.org/pipermail/iovisor-dev/2018-January/001190.html Reported-by: Sandipan Das <sandipan@linux.vnet.ibm.com> Co-authored-by: Prashant Bhole <bhole_prashant_q7@lab.ntt.co.jp> Co-authored-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: Jiri Pirko <jiri@resnulli.us> Signed-off-by: David S. Miller <davem@davemloft.net> commit 70eeff66c4696cee4076d6388b6bede5bd7ff71c Author: Roland Dreier <roland@purestorage.com> Date: Mon Jan 15 12:24:49 2018 -0800 qed: Fix potential use-after-free in qed_spq_post() We need to check if p_ent->comp_mode is QED_SPQ_MODE_EBLOCK before calling qed_spq_add_entry(). The test is fine is the mode is EBLOCK, but if it isn't then qed_spq_add_entry() might kfree(p_ent). Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 0d9c9f0f40ca262b67fc06a702b85f3976f5e1a1 Author: Jakub Kicinski <jakub.kicinski@netronome.com> Date: Mon Jan 15 11:47:53 2018 -0800 nfp: use the correct index for link speed table sts variable is holding link speed as well as state. We should be using ls to index into ls_to_ethtool. Fixes: 265aeb511bd5 ("nfp: add support for .get_link_ksettings()") Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit a5b1379afbfabf91e3a689e82ac619a7157336b3 Author: Yuiko Oshino <yuiko.oshino@microchip.com> Date: Mon Jan 15 13:24:28 2018 -0500 lan78xx: Fix failure in USB Full Speed Fix initialize the uninitialized tx_qlen to an appropriate value when USB Full Speed is used. Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver") Signed-off-by: Yuiko Oshino <yuiko.oshino@microchip.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit c5006b8aa74599ce19104b31d322d2ea9ff887cc Author: Xin Long <lucien.xin@gmail.com> Date: Mon Jan 15 17:02:00 2018 +0800 sctp: do not allow the v4 socket to bind a v4mapped v6 address The check in sctp_sockaddr_af is not robust enough to forbid binding a v4mapped v6 addr on a v4 socket. The worse thing is that v4 socket's bind_verify would not convert this v4mapped v6 addr to a v4 addr. syzbot even reported a crash as the v4 socket bound a v6 addr. This patch is to fix it by doing the common sa.sa_family check first, then AF_INET check for v4mapped v6 addrs. Fixes: 7dab83de50c7 ("sctp: Support ipv6only AF_INET6 sockets.") Reported-by: syzbot+7b7b518b1228d2743963@syzkaller.appspotmail.com Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit a0ff660058b88d12625a783ce9e5c1371c87951f Author: Xin Long <lucien.xin@gmail.com> Date: Mon Jan 15 17:01:36 2018 +0800 sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf After commit cea0cc80a677 ("sctp: use the right sk after waking up from wait_buf sleep"), it may change to lock another sk if the asoc has been peeled off in sctp_wait_for_sndbuf. However, the asoc's new sk could be already closed elsewhere, as it's in the sendmsg context of the old sk that can't avoid the new sk's closing. If the sk's last one refcnt is held by this asoc, later on after putting this asoc, the new sk will be freed, while under it's own lock. This patch is to revert that commit, but fix the old issue by returning error under the old sk's lock. Fixes: cea0cc80a677 ("sctp: use the right sk after waking up from wait_buf sleep") Reported-by: syzbot+ac6ea7baa4432811eb50@syzkaller.appspotmail.com Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 625637bf4afa45204bd87e4218645182a919485a Author: Xin Long <lucien.xin@gmail.com> Date: Mon Jan 15 17:01:19 2018 +0800 sctp: reinit stream if stream outcnt has been change by sinit in sendmsg After introducing sctp_stream structure, sctp uses stream->outcnt as the out stream nums instead of c.sinit_num_ostreams. However when users use sinit in cmsg, it only updates c.sinit_num_ostreams in sctp_sendmsg. At that moment, stream->outcnt is still using previous value. If it's value is not updated, the sinit_num_ostreams of sinit could not really work. This patch is to fix it by updating stream->outcnt and reiniting stream if stream outcnt has been change by sinit in sendmsg. Fixes: a83863174a61 ("sctp: prepare asoc stream for stream reconf") Signed-off-by: Xin Long <lucien.xin@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 3d1661304f0b2b51a8a43785b764822611dbdd53 Author: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Date: Wed Jan 10 19:39:52 2018 -0600 ibmvnic: Fix pending MAC address changes Due to architecture limitations, the IBM VNIC client driver is unable to perform MAC address changes unless the device has "logged in" to its backing device. Currently, pending MAC changes are handled before login, resulting in an error and failure to change the MAC address. Moving that chunk to the end of the ibmvnic_login function, when we are sure that it was successful, fixes that. The MAC address can be changed when the device is up or down, so only check if the device is in a "PROBED" state before setting the MAC address. Fixes: c26eba03e407 ("ibmvnic: Update reset infrastructure to support tunable parameters") Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com> Reviewed-by: John Allen <jallen@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit c96f5471ce7d2aefd0dda560cc23f08ab00bc65d Author: Josh Snyder <joshs@netflix.com> Date: Mon Dec 18 16:15:10 2017 +0000 delayacct: Account blkio completion on the correct task Before commit: e33a9bba85a8 ("sched/core: move IO scheduling accounting from io_schedule_timeout() into scheduler") delayacct_blkio_end() was called after context-switching into the task which completed I/O. This resulted in double counting: the task would account a delay both waiting for I/O and for time spent in the runqueue. With e33a9bba85a8, delayacct_blkio_end() is called by try_to_wake_up(). In ttwu, we have not yet context-switched. This is more correct, in that the delay accounting ends when the I/O is complete. But delayacct_blkio_end() relies on 'get_current()', and we have not yet context-switched into the task whose I/O completed. This results in the wrong task having its delay accounting statistics updated. Instead of doing that, pass the task_struct being woken to delayacct_blkio_end(), so that it can update the statistics of the correct task. Signed-off-by: Josh Snyder <joshs@netflix.com> Acked-by: Tejun Heo <tj@kernel.org> Acked-by: Balbir Singh <bsingharora@gmail.com> Cc: <stable@vger.kernel.org> Cc: Brendan Gregg <bgregg@netflix.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-block@vger.kernel.org Fixes: e33a9bba85a8 ("sched/core: move IO scheduling accounting from io_schedule_timeout() into scheduler") Link: http://lkml.kernel.org/r/1513613712-571-1-git-send-email-joshs@netflix.com Signed-off-by: Ingo Molnar <mingo@kernel.org> commit 107cd2532181b96c549e8f224cdcca8631c3076b Author: Tom Lendacky <thomas.lendacky@amd.com> Date: Wed Jan 10 13:26:34 2018 -0600 x86/mm: Encrypt the initrd earlier for BSP microcode update Currently the BSP microcode update code examines the initrd very early in the boot process. If SME is active, the initrd is treated as being encrypted but it has not been encrypted (in place) yet. Update the early boot code that encrypts the kernel to also encrypt the initrd so that early BSP microcode updates work. Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180110192634.6026.10452.stgit@tlendack-t1.amdoffice.net Signed-off-by: Ingo Molnar <mingo@kernel.org> commit cc5f01e28d6c60f274fd1e33b245f679f79f543c Author: Tom Lendacky <thomas.lendacky@amd.com> Date: Wed Jan 10 13:26:26 2018 -0600 x86/mm: Prepare sme_encrypt_kernel() for PAGE aligned encryption In preparation for encrypting more than just the kernel, the encryption support in sme_encrypt_kernel() needs to support 4KB page aligned encryption instead of just 2MB large page aligned encryption. Update the routines that populate the PGD to support non-2MB aligned addresses. This is done by creating PTE page tables for the start and end portion of the address range that fall outside of the 2MB alignment. This results in, at most, two extra pages to hold the PTE entries for each mapping of a range. Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180110192626.6026.75387.stgit@tlendack-t1.amdoffice.net Signed-off-by: Ingo Molnar <mingo@kernel.org> commit 2b5d00b6c2cdd94f6d6a494a6f6c0c0fc7b8e711 Author: Tom Lendacky <thomas.lendacky@amd.com> Date: Wed Jan 10 13:26:16 2018 -0600 x86/mm: Centralize PMD flags in sme_encrypt_kernel() In preparation for encrypting more than just the kernel during early boot processing, centralize the use of the PMD flag settings based on the type of mapping desired. When 4KB aligned encryption is added, this will allow either PTE flags or large page PMD flags to be used without requiring the caller to adjust. Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180110192615.6026.14767.stgit@tlendack-t1.amdoffice.net Signed-off-by: Ingo Molnar <mingo@kernel.org> commit bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4 Author: Tom Lendacky <thomas.lendacky@amd.com> Date: Wed Jan 10 13:26:05 2018 -0600 x86/mm: Use a struct to reduce parameters for SME PGD mapping In preparation for follow-on patches, combine the PGD mapping parameters into a struct to reduce the number of function arguments and allow for direct updating of the next pagetable mapping area pointer. Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180110192605.6026.96206.stgit@tlendack-t1.amdoffice.net Signed-off-by: Ingo Molnar <mingo@kernel.org> commit 1303880179e67c59e801429b7e5d0f6b21137d99 Author: Tom Lendacky <thomas.lendacky@amd.com> Date: Wed Jan 10 13:25:56 2018 -0600 x86/mm: Clean up register saving in the __enc_copy() assembly code Clean up the use of PUSH and POP and when registers are saved in the __enc_copy() assembly function in order to improve the readability of the code. Move parameter register saving into general purpose registers earlier in the code and move all the pushes to the beginning of the function with corresponding pops at the end. We do this to prepare fixes. Tested-by: Gabriel Craciunescu <nix.or.die@gmail.com> Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Reviewed-by: Borislav Petkov <bp@suse.de> Cc: Borislav Petkov <bp@alien8.de> Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20180110192556.6026.74187.stgit@tlendack-t1.amdoffice.net Signed-off-by: Ingo Molnar <mingo@kernel.org> commit 385d11b152c4eb638eeb769edcb3249533bb9a00 Author: Josh Poimboeuf <jpoimboe@redhat.com> Date: Mon Jan 15 08:17:08 2018 -0600 objtool: Improve error message for bad file argument If a nonexistent file is supplied to objtool, it complains with a non-helpful error: open: No such file or directory Improve it to: objtool: Can't open 'foo': No such file or directory Reported-by: Markus <M4rkusXXL@web.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/406a3d00a21225eee2819844048e17f68523ccf6.1516025651.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> commit 2a0098d70640dda192a79966c14d449e7a34d675 Author: Josh Poimboeuf <jpoimboe@redhat.com> Date: Mon Jan 15 08:17:07 2018 -0600 objtool: Fix seg fault with gold linker Objtool segfaults when the gold linker is used with CONFIG_MODVERSIONS=y and CONFIG_UNWINDER_ORC=y. With CONFIG_MODVERSIONS=y, the .o file gets passed to the linker before being passed to objtool. The gold linker seems to strip unused ELF symbols by default, which confuses objtool and causes the seg fault when it's trying to generate ORC metadata. Objtool should really be running immediately after GCC anyway, without a linker call in between. Change the makefile ordering so that objtool is called before the linker. Reported-and-tested-by: Markus <M4rkusXXL@web.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder") Link: http://lkml.kernel.org/r/355f04da33581f4a3bf82e5b512973624a1e23a2.1516025651.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org> commit ae59c3f0b6cfd472fed96e50548a799b8971d876 Author: Leon Romanovsky <leonro@mellanox.com> Date: Fri Jan 12 07:58:39 2018 +0200 RDMA/mlx5: Fix out-of-bound access while querying AH The rdma_ah_find_type() accesses the port array based on an index controlled by userspace. The existing bounds check is after the first use of the index, so userspace can generate an out of bounds access, as shown by the KASN report below. ================================================================== BUG: KASAN: slab-out-of-bounds in to_rdma_ah_attr+0xa8/0x3b0 Read of size 4 at addr ffff880019ae2268 by task ibv_rc_pingpong/409 CPU: 0 PID: 409 Comm: ibv_rc_pingpong Not tainted 4.15.0-rc2-00031-gb60a3faf5b83-dirty #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Call Trace: dump_stack+0xe9/0x18f print_address_description+0xa2/0x350 kasan_report+0x3a5/0x400 to_rdma_ah_attr+0xa8/0x3b0 mlx5_ib_query_qp+0xd35/0x1330 ib_query_qp+0x8a/0xb0 ib_uverbs_query_qp+0x237/0x7f0 ib_uverbs_write+0x617/0xd80 __vfs_write+0xf7/0x500 vfs_write+0x149/0x310 SyS_write+0xca/0x190 entry_SYSCALL_64_fastpath+0x18/0x85 RIP: 0033:0x7fe9c7a275a0 RSP: 002b:00007ffee5498738 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fe9c7ce4b00 RCX: 00007fe9c7a275a0 RDX: 0000000000000018 RSI: 00007ffee5498800 RDI: 0000000000000003 RBP: 000055d0c8d3f010 R08: 00007ffee5498800 R09: 0000000000000018 R10: 00000000000000ba R11: 0000000000000246 R12: 0000000000008000 R13: 0000000000004fb0 R14: 000055d0c8d3f050 R15: 00007ffee5498560 Allocated by task 1: __kmalloc+0x3f9/0x430 alloc_mad_private+0x25/0x50 ib_mad_post_receive_mads+0x204/0xa60 ib_mad_init_device+0xa59/0x1020 ib_register_device+0x83a/0xbc0 mlx5_ib_add+0x50e/0x5c0 mlx5_add_device+0x142/0x410 mlx5_register_interface+0x18f/0x210 mlx5_ib_init+0x56/0x63 do_one_initcall+0x15b/0x270 kernel_init_freeable+0x2d8/0x3d0 kernel_init+0x14/0x190 ret_from_fork+0x24/0x30 Freed by task 0: (stack is not available) The buggy address belongs to the object at ffff880019ae2000 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 104 bytes to the right of 512-byte region [ffff880019ae2000, ffff880019ae2200) The buggy address belongs to the page: page:000000005d674e18 count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x4000000000008100(slab|head) raw: 4000000000008100 0000000000000000 0000000000000000 00000001000c000c raw: dead000000000100 dead000000000200 ffff88001a402000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff880019ae2100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff880019ae2180: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc >ffff880019ae2200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff880019ae2280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff880019ae2300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ================================================================== Disabling lock debugging due to kernel taint Cc: <stable@vger.kernel.org> Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types") Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> commit 6311b7ce42e0c1d6d944bc099dc47e936c20cf11 Author: Johannes Berg <johannes.berg@intel.com> Date: Mon Jan 15 12:42:25 2018 +0100 netlink: extack: avoid parenthesized string constant warning NL_SET_ERR_MSG() and NL_SET_ERR_MSG_ATTR() lead to the following warning in newer versions of gcc: warning: array initialized from parenthesized string constant Just remove the parentheses, they're not needed in this context since anyway since there can be no operator precendence issues or similar. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit cd9ff4de0107c65d69d02253bb25d6db93c3dbc1 Author: Jim Westfall <jwestfall@surrealistic.net> Date: Sun Jan 14 04:18:51 2018 -0800 ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY Map all lookup neigh keys to INADDR_ANY for loopback/point-to-point devices to avoid making an entry for every remote ip the device needs to talk to. This used the be the old behavior but became broken in a263b3093641f (ipv4: Make neigh lookups directly in output packet path) and later removed in 0bb4087cbec0 (ipv4: Fix neigh lookup keying over loopback/point-to-point devices) because it was broken. Signed-off-by: Jim Westfall <jwestfall@surrealistic.net> Signed-off-by: David S. Miller <davem@davemloft.net> commit 096b9854c04df86f03b38a97d40b6506e5730919 Author: Jim Westfall <jwestfall@surrealistic.net> Date: Sun Jan 14 04:18:50 2018 -0800 net: Allow neigh contructor functions ability to modify the primary_key Use n->primary_key instead of pkey to account for the possibility that a neigh constructor function may have modified the primary_key value. Signed-off-by: Jim Westfall <jwestfall@surrealistic.net> Signed-off-by: David S. Miller <davem@davemloft.net> commit 17d0fb0caa68f2bfd8aaa8125ff15abebfbfa1d7 Author: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Date: Sat Jan 13 20:22:01 2018 +0300 sh_eth: fix dumping ARSTR ARSTR is always located at the start of the TSU register region, thus using add_reg() instead of add_tsu_reg() in __sh_eth_get_regs() to dump it causes EDMR or EDSR (depending on the register layout) to be dumped instead of ARSTR. Use the correct condition/macro there... Fixes: 6b4b4fead342 ("sh_eth: Implement ethtool register dump operations") Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 95a332088ecb113c2e8753fa3f1df9b0dda9beec Author: William Tu <u9012063@gmail.com> Date: Fri Jan 12 12:29:22 2018 -0800 Revert "openvswitch: Add erspan tunnel support." This reverts commit ceaa001a170e43608854d5290a48064f57b565ed. The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr should be designed as a nested attribute to support all ERSPAN v1 and v2's fields. The current attr is a be32 supporting only one field. Thus, this patch reverts it and later patch will redo it using nested attr. Signed-off-by: William Tu <u9012063@gmail.com> Cc: Jiri Benc <jbenc@redhat.com> Cc: Pravin Shelar <pshelar@ovn.org> Acked-by: Jiri Benc <jbenc@redhat.com> Acked-by: Pravin B Shelar <pshelar@ovn.org> Signed-off-by: David S. Miller <davem@davemloft.net> commit 30be8f8dba1bd2aff73e8447d59228471233a3d4 Author: r.hering@avm.de <r.hering@avm.de> Date: Fri Jan 12 15:42:06 2018 +0100 net/tls: Fix inverted error codes to avoid endless loop sendfile() calls can hang endless with using Kernel TLS if a socket error occurs. Socket error codes must be inverted by Kernel TLS before returning because they are stored with positive sign. If returned non-inverted they are interpreted as number of bytes sent, causing endless looping of the splice mechanic behind sendfile(). Signed-off-by: Robert Hering <r.hering@avm.de> Signed-off-by: David S. Miller <davem@davemloft.net> commit 95ef498d977bf44ac094778fd448b98af158a3e6 Author: Eric Dumazet <edumazet@google.com> Date: Thu Jan 11 22:31:18 2018 -0800 ipv6: ip6_make_skb() needs to clear cork.base.dst In my last patch, I missed fact that cork.base.dst was not initialized in ip6_make_skb() : If ip6_setup_cork() returns an error, we might attempt a dst_release() on some random pointer. Fixes: 862c03ee1deb ("ipv6: fix possible mem leaks in ipv6_make_skb()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 68e76e034b6b1c1ce2eece1ab8ae4008e14be470 Author: Randy Dunlap <rdunlap@infradead.org> Date: Mon Jan 15 11:07:27 2018 -0800 tracing: Prevent PROFILE_ALL_BRANCHES when FORTIFY_SOURCE=y I regularly get 50 MB - 60 MB files during kernel randconfig builds. These large files mostly contain (many repeats of; e.g., 124,594): In file included from ../include/linux/string.h:6:0, from ../include/linux/uuid.h:20, from ../include/linux/mod_devicetable.h:13, from ../scripts/mod/devicetable-offsets.c:3: ../include/linux/compiler.h:64:4: warning: '______f' is static but declared in inline function 'strcpy' which is not static [enabled by default] ______f = { \ ^ ../include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if' ^ ../include/linux/string.h:425:2: note: in expansion of macro 'if' if (p_size == (size_t)-1 && q_size == (size_t)-1) ^ This only happens when CONFIG_FORTIFY_SOURCE=y and CONFIG_PROFILE_ALL_BRANCHES=y, so prevent PROFILE_ALL_BRANCHES if FORTIFY_SOURCE=y. Link: http://lkml.kernel.org/r/9199446b-a141-c0c3-9678-a3f9107f2750@infradead.org Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> commit 37f47bc90c7481e7959703ad1defc4fc9f5d85e3 Author: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Date: Thu Jan 11 14:22:06 2018 -0200 sctp: avoid compiler warning on implicit fallthru These fall-through are expected. Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Acked-by: Neil Horman <nhorman@tuxdriver.com> Reviewed-by: Xin Long <lucien.xin@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 6503a30440962f1e1ccb8868816b4e18201218d4 Author: Lorenzo Colitti <lorenzo@google.com> Date: Thu Jan 11 18:36:26 2018 +0900 net: ipv4: Make "ip route get" match iif lo rules again. Commit 3765d35ed8b9 ("net: ipv4: Convert inet_rtm_getroute to rcu versions of route lookup") broke "ip route get" in the presence of rules that specify iif lo. Host-originated traffic always has iif lo, because ip_route_output_key_hash and ip6_route_output_flags set the flow iif to LOOPBACK_IFINDEX. Thus, putting "iif lo" in an ip rule is a convenient way to select only originated traffic and not forwarded traffic. inet_rtm_getroute used to match these rules correctly because even though it sets the flow iif to 0, it called ip_route_output_key which overwrites iif with LOOPBACK_IFINDEX. But now that it calls ip_route_output_key_hash_rcu, the ifindex will remain 0 and not match the iif lo in the rule. As a result, "ip route get" will return ENETUNREACH. Fixes: 3765d35ed8b9 ("net: ipv4: Convert inet_rtm_getroute to rcu versions of route lookup") Tested: https://android.googlesource.com/kernel/tests/+/master/net/test/multinetwork_test.py passes again Signed-off-by: Lorenzo Colitti <lorenzo@google.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit cbbdf8433a5f117b1a2119ea30fc651b61ef7570 Author: David Ahern <dsahern@gmail.com> Date: Wed Jan 10 13:00:39 2018 -0800 netlink: extack needs to be reset each time through loop syzbot triggered the WARN_ON in netlink_ack testing the bad_attr value. The problem is that netlink_rcv_skb loops over the skb repeatedly invoking the callback and without resetting the extack leaving potentially stale data. Initializing each time through avoids the WARN_ON. Fixes: 2d4bc93368f5a ("netlink: extended ACK reporting") Reported-by: syzbot+315fa6766d0f7c359327@syzkaller.appspotmail.com Signed-off-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 59b36613e85fb16ebf9feaf914570879cd5c2a21 Author: Cong Wang <xiyou.wangcong@gmail.com> Date: Wed Jan 10 12:50:25 2018 -0800 tipc: fix a memory leak in tipc_nl_node_get_link() When tipc_node_find_by_name() fails, the nlmsg is not freed. While on it, switch to a goto label to properly free it. Fixes: be9c086715c ("tipc: narrow down exposure of struct tipc_node") Reported-by: Dmitry Vyukov <dvyukov@google.com> Cc: Jon Maloy <jon.maloy@ericsson.com> Cc: Ying Xue <ying.xue@windriver.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Acked-by: Ying Xue <ying.xue@windriver.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 749439bfac6e1a2932c582e2699f91d329658196 Author: Mike Maloney <maloney@google.com> Date: Wed Jan 10 12:45:10 2018 -0500 ipv6: fix udpv6 sendmsg crash caused by too small MTU The logic in __ip6_append_data() assumes that the MTU is at least large enough for the headers. A device's MTU may be adjusted after being added while sendmsg() is processing data, resulting in __ip6_append_data() seeing any MTU. For an mtu smaller than the size of the fragmentation header, the math results in a negative 'maxfraglen', which causes problems when refragmenting any previous skb in the skb_write_queue, leaving it possibly malformed. Instead sendmsg returns EINVAL when the mtu is calculated to be less than IPV6_MIN_MTU. Found by syzkaller: kernel BUG at ./include/linux/skbuff.h:2064! invalid opcode: 0000 [#1] SMP KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 1 PID: 14216 Comm: syz-executor5 Not tainted 4.13.0-rc4+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 task: ffff8801d0b68580 task.stack: ffff8801ac6b8000 RIP: 0010:__skb_pull include/linux/skbuff.h:2064 [inline] RIP: 0010:__ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617 RSP: 0018:ffff8801ac6bf570 EFLAGS: 00010216 RAX: 0000000000010000 RBX: 0000000000000028 RCX: ffffc90003cce000 RDX: 00000000000001b8 RSI: ffffffff839df06f RDI: ffff8801d9478ca0 RBP: ffff8801ac6bf780 R08: ffff8801cc3f1dbc R09: 0000000000000000 R10: ffff8801ac6bf7a0 R11: 43cb4b7b1948a9e7 R12: ffff8801cc3f1dc8 R13: ffff8801cc3f1d40 R14: 0000000000001036 R15: dffffc0000000000 FS: 00007f43d740c700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f7834984000 CR3: 00000001d79b9000 CR4: 00000000001406e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ip6_finish_skb include/net/ipv6.h:911 [inline] udp_v6_push_pending_frames+0x255/0x390 net/ipv6/udp.c:1093 udpv6_sendmsg+0x280d/0x31a0 net/ipv6/udp.c:1363 inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762 sock_sendmsg_nosec net/socket.c:633 [inline] sock_sendmsg+0xca/0x110 net/socket.c:643 SYSC_sendto+0x352/0x5a0 net/socket.c:1750 SyS_sendto+0x40/0x50 net/socket.c:1718 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4512e9 RSP: 002b:00007f43d740bc08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00000000007180a8 RCX: 00000000004512e9 RDX: 000000000000002e RSI: 0000000020d08000 RDI: 0000000000000005 RBP: 0000000000000086 R08: 00000000209c1000 R09: 000000000000001c R10: 0000000000040800 R11: 0000000000000216 R12: 00000000004b9c69 R13: 00000000ffffffff R14: 0000000000000005 R15: 00000000202c2000 Code: 9e 01 fe e9 c5 e8 ff ff e8 7f 9e 01 fe e9 4a ea ff ff 48 89 f7 e8 52 9e 01 fe e9 aa eb ff ff e8 a8 b6 cf fd 0f 0b e8 a1 b6 cf fd <0f> 0b 49 8d 45 78 4d 8d 45 7c 48 89 85 78 fe ff ff 49 8d 85 ba RIP: __skb_pull include/linux/skbuff.h:2064 [inline] RSP: ffff8801ac6bf570 RIP: __ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617 RSP: ffff8801ac6bf570 Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Mike Maloney <maloney@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 6200b430220f3b9207861b16f57916950f4ecd8e Author: Arnd Bergmann <arnd@arndb.de> Date: Wed Jan 10 17:30:22 2018 +0100 net: cs89x0: add MODULE_LICENSE This driver lacks a MODULE_LICENSE tag, leading to a Kbuild warning: WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/cirrus/cs89x0.o This adds license, author, and description according to the comment block at the start of the file. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: David S. Miller <davem@davemloft.net> commit 0171c41835591e9aa2e384b703ef9a6ae367c610 Author: Guillaume Nault <g.nault@alphalink.fr> Date: Wed Jan 10 16:24:45 2018 +0100 ppp: unlock all_ppp_mutex before registering device ppp_dev_uninit(), which is the .ndo_uninit() handler of PPP devices, needs to lock pn->all_ppp_mutex. Therefore we mustn't call register_netdevice() with pn->all_ppp_mutex already locked, or we'd deadlock in case register_netdevice() fails and calls .ndo_uninit(). Fortunately, we can unlock pn->all_ppp_mutex before calling register_netdevice(). This lock protects pn->units_idr, which isn't used in the device registration process. However, keeping pn->all_ppp_mutex locked during device registration did ensure that no device in transient state would be published in pn->units_idr. In practice, unlocking it before calling register_netdevice() doesn't change this property: ppp_unit_register() is called with 'ppp_mutex' locked and all searches done in pn->units_idr hold this lock too. Fixes: 8cb775bc0a34 ("ppp: fix device unregistration upon netns deletion") Reported-and-tested-by: syzbot+367889b9c9e279219175@syzkaller.appspotmail.com Signed-off-by: Guillaume Nault <g.nault@alphalink.fr> Signed-off-by: David S. Miller <davem@davemloft.net> commit 66940f35d5a81d5969bb5543171c70a434fc5110 Author: Michael S. Tsirkin <mst@redhat.com> Date: Wed Jan 10 16:03:05 2018 +0200 ptr_ring: document usage around __ptr_ring_peek This explains why is the net usage of __ptr_ring_peek actually ok without locks. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: John Fastabend <john.fastabend@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit d542296a4d0d9f41d0186edcac2baba1b674d02f Author: Stephen Hemminger <stephen@networkplumber.org> Date: Mon Jan 8 08:23:18 2018 -0800 9p: add missing module license for xen transport The 9P of Xen module is missing required license and module information. See https://bugzilla.kernel.org/show_bug.cgi?id=198109 Reported-by: Alan Bartlett <ajb@elrepo.org> Fixes: 868eb122739a ("xen/9pfs: introduce Xen 9pfs transport driver") Signed-off-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net> commit a0e3a18f4baf8e3754ac1e56f0ade924d0c0c721 Author: Steven Rostedt (VMware) <rostedt@goodmis.org> Date: Mon Jan 15 10:47:09 2018 -0500 ring-buffer: Bring back context level recursive checks Commit 1a149d7d3f45 ("ring-buffer: Rewrite trace_recursive_(un)lock() to be simpler") replaced the context level recursion checks with a simple counter. This would prevent the ring buffer code from recursively calling itself more than the max number of contexts that exist (Normal, softirq, irq, nmi). But this change caused a lockup in a specific case, which was during suspend and resume using a global clock. Adding a stack dump to see where this occurred, the issue was in the trace global clock itself: trace_buffer_lock_reserve+0x1c/0x50 __trace_graph_entry+0x2d/0x90 trace_graph_entry+0xe8/0x200 prepare_ftrace_return+0x69/0xc0 ftrace_graph_caller+0x78/0xa8 queued_spin_lock_slowpath+0x5/0x1d0 trace_clock_global+0xb0/0xc0 ring_buffer_lock_reserve+0xf9/0x390 The function graph tracer traced queued_spin_lock_slowpath that was called by trace_clock_global. This pointed out that the trace_clock_global() is not reentrant, as it takes a spin lock. It depended on the ring buffer recursive lock from letting that happen. By removing the context detection and adding just a max number of allowable recursions, it allowed the trace_clock_global() to be entered again and try to retake the spinlock it already held, causing a deadlock. Fixes: 1a149d7d3f45 ("ring-buffer: Rewrite trace_recursive_(un)lock() to be simpler") Reported-by: David Weinehall <david.weinehall@gmail.com> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> commit 499ed50f603b4c9834197b2411ba3bd9aaa624d4 Author: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> Date: Sun Jan 14 19:43:05 2018 +0100 mmc: sdhci-esdhc-imx: Fix i.MX53 eSDHCv3 clock Commit 5143c953a786 ("mmc: sdhci-esdhc-imx: Allow all supported prescaler values") made it possible to set SYSCTL.SDCLKFS to 0 in SDR mode, thus bypassing the SD clock frequency prescaler, in order to be able to get higher SD clock frequencies in some contexts. However, that commit missed the fact that this value is illegal on the eSDHCv3 instance of the i.MX53. This seems to be the only exception on i.MX, this value being legal even for the eSDHCv2 instances of the i.MX53. Fix this issue by changing the minimum prescaler value if the i.MX53 eSDHCv3 is detected. According to the i.MX53 reference manual, if DLLCTRL[10] can be set, then the controller is eSDHCv3, else it is eSDHCv2. This commit fixes the following issue, which was preventing the i.MX53 Loco (IMX53QSB) board from booting Linux 4.15.0-rc5: [ 1.882668] mmcblk1: error -84 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc00 [ 2.002255] mmcblk1: error -84 transferring data, sector 2050, nr 6, cmd response 0x900, card status 0xc00 [ 12.645056] mmc1: Timeout waiting for hardware interrupt. [ 12.650473] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [ 12.656921] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00001201 [ 12.663366] mmc1: sdhci: Blk size: 0x00000004 | Blk cnt: 0x00000000 [ 12.669813] mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013 [ 12.676258] mmc1: sdhci: Present: 0x01f8028f | Host ctl: 0x00000013 [ 12.682703] mmc1: sdhci: Power: 0x00000002 | Blk gap: 0x00000000 [ 12.689148] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x0000003f [ 12.695594] mmc1: sdhci: Timeout: 0x0000008e | Int stat: 0x00000000 [ 12.702039] mmc1: sdhci: Int enab: 0x107f004b | Sig enab: 0x107f004b [ 12.708485] mmc1: sdhci: AC12 err: 0x00000000 | Slot int: 0x00001201 [ 12.714930] mmc1: sdhci: Caps: 0x07eb0000 | Caps_1: 0x08100810 [ 12.721375] mmc1: sdhci: Cmd: 0x0000163a | Max curr: 0x00000000 [ 12.727821] mmc1: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x00000000 [ 12.734265] mmc1: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 12.740709] mmc1: sdhci: Host ctl2: 0x00000000 [ 12.745157] mmc1: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0xc8049200 [ 12.751601] mmc1: sdhci: ============================================ [ 12.758110] print_req_error: I/O error, dev mmcblk1, sector 2050 [ 12.764135] Buffer I/O error on dev mmcblk1p1, logical block 0, lost sync page write [ 12.775163] EXT4-fs (mmcblk1p1): mounted filesystem without journal. Opts: (null) [ 12.782746] VFS: Mounted root (ext4 filesystem) on device 179:9. [ 12.789151] mmcblk1: response CRC error sending SET_BLOCK_COUNT command, card status 0x900 Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> Reported-by: Wladimir J. van der Laan <laanwj@gmail.com> Tested-by: Wladimir J. van der Laan <laanwj@gmail.com> Fixes: 5143c953a786 ("mmc: sdhci-esdhc-imx: Allow all supported prescaler values") Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> commit 59b179b48ce2a6076448a44531242ac2b3f6cef2 Author: Johannes Berg <johannes.berg@intel.com> Date: Mon Jan 15 09:58:27 2018 +0100 cfg80211: check dev_set_name() return value syzbot reported a warning from rfkill_alloc(), and after a while I think that the reason is that it was doing fault injection and the dev_set_name() failed, leaving the name NULL, and we didn't check the return value and got to rfkill_alloc() with a NULL name. Since we really don't want a NULL name, we ought to check the return value. Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()") Reported-by: syzbot+1ddfb3357e1d7bb5b5d3@syzkaller.appspotmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com> commit 51a1aaa631c90223888d8beac4d649dc11d2ca55 Author: Johannes Berg <johannes.berg@intel.com> Date: Mon Jan 15 09:32:36 2018 +0100 mac80211_hwsim: validate number of different channels When creating a new radio on the fly, hwsim allows this to be done with an arbitrary number of channels, but cfg80211 only supports a limited number of simultaneous channels, leading to a warning. Fix this by validating the number - this requires moving the define for the maximum out to a visible header file. Reported-by: syzbot+8dd9051ff19940290931@syzkaller.appspotmail.com Fixes: b59ec8dd4394 ("mac80211_hwsim: fix number of channels in interface combinations") Signed-off-by: Johannes Berg <johannes.berg@intel.com> commit b71d856ab536f25eb97c011a351ecddf5518de41 Author: Benjamin Beichler <benjamin.beichler@uni-rostock.de> Date: Wed Jan 10 17:42:51 2018 +0100 mac80211_hwsim: add workqueue to wait for deferred radio deletion on mod unload When closing multiple wmediumd instances with many radios and try to unload the mac80211_hwsim module, it may happen that the work items live longer than the module. To wait especially for this deletion work items, add a work queue, otherwise flush_scheduled_work would be necessary. Signed-off-by: Benjamin Beichler <benjamin.beichler@uni-rostock.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> commit 7a94b8c2eee7083ddccd0515830f8c81a8e44b1a Author: Dominik Brodowski <linux@dominikbrodowski.net> Date: Mon Jan 15 08:12:15 2018 +0100 nl80211: take RCU read lock when calling ieee80211_bss_get_ie() As ieee80211_bss_get_ie() derefences an RCU to return ssid_ie, both the call to this function and any operation on this variable need protection by the RCU read lock. Fixes: 44905265bc15 ("nl80211: don't expose wdev->ssid for most interfaces") Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Johannes Berg <johannes.berg@intel.com> commit a48a52b7bea81c046fe1c1288f84d0eba214cba0 Author: Johannes Berg <johannes.berg@intel.com> Date: Mon Jan 15 09:12:05 2018 +0100 cfg80211: fully initialize old channel for event Paul reported that he got a report about undefined behaviour that seems to me to originate in using uninitialized memory when the channel structure here is used in the event code in nl80211 later. He never reported whether this fixed it, and I wasn't able to trigger this so far, but we should do the right thing and fully initialize the on-stack structure anyway. Reported-by: Paul Menzel <pmenzel+linux-wireless@molgen.mpg.de> Signed-off-by: Johannes Berg <johannes.berg@intel.com> commit 28d437d550e1e39f805d99f9f8ac399c778827b7 Author: Tom Lendacky <thomas.lendacky@amd.com> Date: Sat Jan 13 17:27:30 2018 -0600 x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros The PAUSE instruction is currently used in the retpoline and RSB filling macros as a speculation trap. The use of PAUSE was originally suggested because it showed a very, very small difference in the amount of cycles/time used to execute the retpoline as compared to LFENCE. On AMD, the PAUSE instruction is not a serializing instruction, so the pause/jmp loop will use excess power as it is speculated over waiting for return to mispredict to the correct target. The RSB filling macro is applicable to AMD, and, if software is unable to verify that LFENCE is serializing on AMD (possible when running under a hypervisor), the generic retpoline support will be used and, so, is also applicable to AMD. Keep the current usage of PAUSE for Intel, but add an LFENCE instruction to the speculation trap for AMD. The same sequence has been adopted by GCC for the GCC generated retpolines. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Borislav Petkov <bp@alien8.de> Acked-by: David Woodhouse <dwmw@amazon.co.uk> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Paul Turner <pjt@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Kees Cook <keescook@google.com> Link: https://lkml.kernel.org/r/20180113232730.31060.36287.stgit@tlendack-t1.amdoffice.net commit c995efd5a740d9cbafbf58bde4973e8b50b4d761 Author: David Woodhouse <dwmw@amazon.co.uk> Date: Fri Jan 12 17:49:25 2018 +0000 x86/retpoline: Fill RSB on context switch for affected CPUs On context switch from a shallow call stack to a deeper one, as the CPU does 'ret' up the deeper side it may encounter RSB entries (predictions for where the 'ret' goes to) which were populated in userspace. This is problematic if neither SMEP nor KPTI (the latter of which marks userspace pages as NX for the kernel) are active, as malicious code in userspace may then be executed speculatively. Overwrite the CPU's return prediction stack with calls which are predicted to return to an infinite loop, to "capture" speculation if this happens. This is required both for retpoline, and also in conjunction with IBRS for !SMEP && !KPTI. On Skylake+ the problem is slightly different, and an *underflow* of the RSB may cause errant branch predictions to occur. So there it's not so much overwrite, as *filling* the RSB to attempt to prevent it getting empty. This is only a partial solution for Skylake+ since there are many other conditions which may result in the RSB becoming empty. The full solution on Skylake+ is to use IBRS, which will prevent the problem even when the RSB becomes empty. With IBRS, the RSB-stuffing will not be required on context switch. [ tglx: Added missing vendor check and slighty massaged comments and changelog ] Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Arjan van de Ven <arjan@linux.intel.com> Cc: gnomes@lxorguk.ukuu.org.uk Cc: Rik van Riel <riel@redhat.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: thomas.lendacky@amd.com Cc: Peter Zijlstra <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jiri Kosina <jikos@kernel.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Kees Cook <keescook@google.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Greg Kroah-Hartman <gregkh@linux-foundation.org> Cc: Paul Turner <pjt@google.com> Link: https://lkml.kernel.org/r/1515779365-9032-1-git-send-email-dwmw@amazon.co.uk commit 0d39e…
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jan 21, 2018
GIT d320e9ba19cf1a183eb5c6a677b7ff541c317d15 commit 666b9a02698f3b52f3530536e130e54965af650b Author: Arnd Bergmann <arnd@arndb.de> Date: Wed Jan 17 16:16:48 2018 +0100 scsi: fnic: use 64-bit timestamps struct timespec is deprecated since it overflows in 2038 on 32-bit architectures, so we should use timespec64 consistently. I'm slightly adapting the format strings here, to make sure we print the nanoseconds with the correct number of leading zeroes. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Satish Kharat <satishkh@cisco.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> commit 8d0130d42a361ff98020d39a3e31f4a691cec573 Author: Wei Yongjun <weiyongjun1@huawei.com> Date: Wed Jan 17 12:42:41 2018 +0000 scsi: qedf: Fix error return code in __qedf_probe() Fix to return error code -ENOMEM from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> commit e65935969d0fac9df28d9c49bdbab5d8d8286a20 Author: Jiong Wang <jiong.wang@netronome.com> Date: Tue Jan 16 16:05:21 2018 -0800 tools: bpftool: improve architecture detection by using ifindex The current architecture detection method in bpftool is designed for host case. For offload case, we can't use the architecture of "bpftool" itself. Instead, we could call the existing "ifindex_to_name_ns" to get DEVNAME, then read pci id from /sys/class/dev/DEVNAME/device/vendor, finally we map vendor id to bfd arch name which will finally be used to select bfd backend for the disassembler. Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> commit eb1d7db927a9653f1402473c777839e0456a7836 Author: Jiong Wang <jiong.wang@netronome.com> Date: Tue Jan 16 16:05:20 2018 -0800 nfp: bpf: set new jit info fields This patch set those new jit info fields introduced in this patch set. Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> commit fcfb126defda3cee3f1d9460dbe9a2ccac4fbd21 Author: Jiong Wang <jiong.wang@netronome.com> Date: Tue Jan 16 16:05:19 2018 -0800 bpf: add new jited info fields in bpf_dev_offload and bpf_prog_info For host JIT, there are "jited_len"/"bpf_func" fields in struct bpf_prog used by all host JIT targets to get jited image and it's length. While for offload, targets are likely to have different offload mechanisms that these info are kept in device private data fields. Therefore, BPF_OBJ_GET_INFO_BY_FD syscall needs an unified way to get JIT length and contents info for offload targets. One way is to introduce new callback to parse device private data then fill those fields in bpf_prog_info. This might be a little heavy, the other way is to add generic fields which will be initialized by all offload targets. This patch follow the second approach to introduce two new fields in struct bpf_dev_offload and teach bpf_prog_get_info_by_fd about them to fill correct jited_prog_len and jited_prog_insns in bpf_prog_info. Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Acked-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> commit ae17a87dd7c79fa742ef5dcf06d1095eec4e1925 Author: Masanari Iida <standby24x7@gmail.com> Date: Thu Jan 11 20:00:28 2018 +0900 linux-next: docs-rst: Fix typos in kfigure.py This patch fixes some spelling typos found in kfigure.py Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> commit 5d87a33782d36c5f2192c93612262deaaa57ad50 Author: Masanari Iida <standby24x7@gmail.com> Date: Thu Jan 11 22:28:37 2018 +0900 linux-next: DOC: HWPOISON: Fix path to debugfs in hwpoison.txt This patch fixes an incorrect path for debugfs in hwpoison.txt Signed-off-by: Masanari Iida <standby24x7@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> commit 423860a65ae54fa1fbd3abb224bdc62124dcdb90 Author: Matthew Wilcox <mawilcox@microsoft.com> Date: Tue Jan 16 19:40:55 2018 -0800 Documentation: Fix misconversion of #if At some stage of the conversion pipeline, something thought that the DocBook entity # should be rendered as NUM instead of #. Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> commit 5bacb56b2b56283ab26fea9e15f06ebe27afbe3d Author: Wolfram Sang <wsa@the-dreams.de> Date: Thu Jan 18 00:18:17 2018 +0100 i2c: rk3x: add proper kerneldoc header gcc noticed the kerneldoc was wrongly formatted. Fix it! drivers/i2c/busses/i2c-rk3x.c:164: warning: Cannot understand * @grf_offset: ... on line 164 - I thought it was a doc line Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Reviewed-by: Heiko Stuebner <heiko@sntech.de> commit d032a2eb2e3b9fc2def41c22bfb58e1efc2c6823 Author: Julia Lawall <Julia.Lawall@lip6.fr> Date: Tue Jan 2 14:28:03 2018 +0100 i2c: rk3x: account for const type of of_device_id.data This driver creates a number of const structures that it stores in the data field of an of_device_id array. The data field of an of_device_id structure has type const void *, so there is no need for a const-discarding cast when putting const values into such a structure. Furthermore, adding const to the declaration of the location that receives a const value from such a field ensures that the compiler will continue to check that the value is not modified. The const-discarding cast on the extraction from the data field is thus no longer needed. Done using Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit f89813ec8ba4b46c7926325eb9835ef1c6793496 Author: Wolfram Sang <wsa@the-dreams.de> Date: Mon Jan 15 18:41:39 2018 +0100 i2c: acorn: remove outdated path from file header That path has gone away for a long time. Move the HW name upwards for a proper header. Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit e199c285b66705bec2f63a9230f50dadfa6dc0fb Author: Arnd Bergmann <arnd@arndb.de> Date: Mon Jan 15 21:28:39 2018 +0100 i2c: acorn: add MODULE_LICENSE tag As of v4.15, Kbuild warns about missing MODULE_LICENSE tags: WARNING: modpost: missing MODULE_LICENSE() in drivers/i2c/busses/i2c-acorn.o This adds a license, author and description tag, matching the comment at the start of the acorn i2c driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> commit 5ef7e0ba1039d65c4eefde92056769548b214273 Author: Luis de Bethencourt <luisbg@kernel.org> Date: Tue Jan 16 15:03:32 2018 +0000 vxlan: Fix trailing semicolon The trailing semicolon is an empty statement that does no operation. It is completely stripped out by the compiler. Removing it since it doesn't do anything. Fixes: 5f35227ea34b ("net: Generalize ndo_gso_check to ndo_features_check") Signed-off-by: Luis de Bethencourt <luisbg@kernel.org> Acked-by: Stephen Hemminger <stephen@networkplumber.org> Signed-off-by: David S. Miller <davem@davemloft.net> commit baf5086840ab1815003e6ece5a51c1a803f81f47 Author: Ganesh Goudar <ganeshgr@chelsio.com> Date: Tue Jan 16 16:17:40 2018 +0530 cxgb4: restructure VF mgmt code restructure the code which adds support for configuring PCIe VF via mgmt netdevice. which was added by commit 7829451c695e ("cxgb4: Add control net_device for configuring PCIe VF") Original work by: Casey Leedom <leedom@chelsio.com> Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 793e4f7551c7b637952405d35282d3cc5f1a779f Author: Sascha Hauer <s.hauer@pengutronix.de> Date: Fri Nov 24 12:17:14 2017 +0100 ubi: Fix copy/paste error in function documentation The function documentation of leb_write_trylock is copied from leb_write_lock. Replace the function name with the correct one. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at> commit 0e099a38ea5a8d546a9ca8bac1fc43c61b210df6 Author: Sascha Hauer <s.hauer@pengutronix.de> Date: Fri Nov 24 12:14:06 2017 +0100 ubi: Fastmap: Fix typo Fix misspelling of 'available' in function name. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Richard Weinberger <richard@nod.at> commit 088594d6d8eb16ae2f43c032d46901c6237e7658 Author: Rock Lee <rli@sierrawireless.com> Date: Wed Jan 10 21:08:24 2018 -0500 ubifs: remove error message in ubifs_xattr_get There is a situation that other modules, like overlayfs, try to get xattr value with a small buffer, if they get -ERANGE, they will try again with the proper buffer size. No need to report an error. Signed-off-by: Rock Lee <rli@sierrawireless.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit 9a2cebc6e2368072490a574eafe0f0747d330bbd Author: Eric Biggers <ebiggers@google.com> Date: Fri Jan 5 11:30:03 2018 -0800 ubifs: free the encrypted symlink target ubifs_symlink() forgot to free the kmalloc()'ed buffer holding the encrypted symlink target, creating a memory leak. Fix it. (UBIFS could actually encrypt directly into ui->data, removing the temporary buffer, but that is left for the patch that switches to use the symlink helper functions.) Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks") Cc: <stable@vger.kernel.org> # v4.10+ Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c Author: Sascha Hauer <s.hauer@pengutronix.de> Date: Tue Dec 5 16:01:20 2017 +0100 ubi: fastmap: Erase outdated anchor PEBs during attach The fastmap update code might erase the current fastmap anchor PEB in case it doesn't find any new free PEB. When a power cut happens in this situation we must not have any outdated fastmap anchor PEB on the device, because that would be used to attach during next boot. The easiest way to make that sure is to erase all outdated fastmap anchor PEBs synchronously during attach. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Richard Weinberger <richard@nod.at> Fixes: dbb7d2a88d2a ("UBI: Add fastmap core") Cc: <stable@vger.kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at> commit 252153ba518ac0bcde6b7152c63380d4415bfe5d Author: Eric Biggers <ebiggers@google.com> Date: Wed Nov 29 12:43:17 2017 -0800 ubifs: switch to fscrypt_prepare_setattr() Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit a0b3ccd9636014664e5dec80a86ef624399c105c Author: Eric Biggers <ebiggers@google.com> Date: Wed Nov 29 12:43:16 2017 -0800 ubifs: switch to fscrypt_prepare_lookup() Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit 0c1ad5242d4f7c155661449a766e98f0018799ee Author: Eric Biggers <ebiggers@google.com> Date: Wed Nov 29 12:43:15 2017 -0800 ubifs: switch to fscrypt_prepare_rename() Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit 5653878c8ca417b2f7b283df0db0141bb3c185f7 Author: Eric Biggers <ebiggers@google.com> Date: Wed Nov 29 12:43:14 2017 -0800 ubifs: switch to fscrypt_prepare_link() Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit 7e35c4dac3e7b02bbf1588af52edf155537e5b61 Author: Eric Biggers <ebiggers@google.com> Date: Wed Nov 29 12:43:13 2017 -0800 ubifs: switch to fscrypt_file_open() Signed-off-by: Eric Biggers <ebiggers@google.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit f50629df49f59b044c89f99a4bcd02cafdb38258 Author: Colin Ian King <colin.king@canonical.com> Date: Sun Oct 29 13:14:26 2017 +0000 ubi: fastmap: Clean up the initialization of pointer p The pointer p is being initialized with one value and a few lines later being set to a newer replacement value. Clean up the code by using the latter assignment to p as the initial value. Cleans up clang warning: drivers/mtd/ubi/fastmap.c:217:19: warning: Value stored to 'p' during its initialization is never read Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit af7bcee27652bbf2502207500ad200763707a160 Author: Pan Bian <bianpan2016@163.com> Date: Sun Oct 29 20:40:02 2017 +0800 ubi: fastmap: Use kmem_cache_free to deallocate memory Memory allocated by kmem_cache_alloc() should not be deallocated with kfree(). Use kmem_cache_free() instead. Signed-off-by: Pan Bian <bianpan2016@163.com> Reviewed-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Richard Weinberger <richard@nod.at> commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6 Author: Clay McClure <clay@daemons.net> Date: Thu Sep 21 19:01:34 2017 -0700 ubi: Fix race condition between ubi volume creation and udev Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi device creation and udev"), we should make the volume active before registering it. Signed-off-by: Clay McClure <clay@daemons.net> Cc: <stable@vger.kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at> commit 42157277af17d5c05946c700eb03877d60760d3c Author: Kirill Tkhai <ktkhai@virtuozzo.com> Date: Tue Jan 16 12:31:54 2018 +0300 net: Remove spinlock from get_net_ns_by_id() idr_find() is safe under rcu_read_lock() and maybe_get_net() guarantees that net is alive. Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 0c06bea919f3289368a023d1a62a1bc319617fa3 Author: Kirill Tkhai <ktkhai@virtuozzo.com> Date: Tue Jan 16 12:31:41 2018 +0300 net: Fix possible race in peernet2id_alloc() peernet2id_alloc() is racy without rtnl_lock() as refcount_read(&peer->count) under net->nsid_lock does not guarantee, peer is alive: rcu_read_lock() peernet2id_alloc() .. spin_lock_bh(&net->nsid_lock) .. refcount_read(&peer->count) (!= 0) .. .. put_net() .. cleanup_net() .. for_each_net(tmp) .. spin_lock_bh(&tmp->nsid_lock) .. __peernet2id(tmp, net) == -1 .. .. .. .. __peernet2id_alloc(alloc == true) .. .. .. rcu_read_unlock() .. .. synchronize_rcu() .. kmem_cache_free(net) After the above situation, net::netns_id contains id pointing to freed memory, and any other dereferencing by the id will operate with this freed memory. Currently, peernet2id_alloc() is used under rtnl_lock() everywhere except ovs_vport_cmd_fill_info(), and this race can't occur. But peernet2id_alloc() is generic interface, and better we fix it before someone really starts use it in wrong context. v2: Don't place refcount_read(&net->count) under net->nsid_lock as suggested by Eric W. Biederman <ebiederm@xmission.com> v3: Rebase on top of net-next Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 0b1655143df00ac5349f27b765b2ed13a3ac40ca Author: Kai-Heng Feng <kai.heng.feng@canonical.com> Date: Tue Jan 16 16:46:27 2018 +0800 r8152: disable RX aggregation on Dell TB16 dock r8153 on Dell TB15/16 dock corrupts rx packets. This change is suggested by Realtek. They guess that the XHCI controller doesn't have enough buffer, and their guesswork is correct, once the RX aggregation gets disabled, the issue is gone. ASMedia is currently working on a real sulotion for this issue. Dell and ODM confirm the bcdDevice and iSerialNumber is unique for TB16. Note that TB15 has different bcdDevice and iSerialNumber, which are not unique values. If you still have TB15, please contact Dell to replace it with TB16. BugLink: https://bugs.launchpad.net/bugs/1729674 Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit aff3d70a07fffc0abb53663e4a4acb059d2f36af Author: Jason Wang <jasowang@redhat.com> Date: Tue Jan 16 16:31:02 2018 +0800 tun: allow to attach ebpf socket filter This patch allows userspace to attach eBPF filter to tun. This will allow to implement VM dataplane filtering in a more efficient way compared to cBPF filter by allowing either qemu or libvirt to attach eBPF filter to tun. Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit cd5681d7d8903bf43a571aaf96cf6d2e2e00118c Author: Jason Wang <jasowang@redhat.com> Date: Tue Jan 16 16:31:01 2018 +0800 tuntap: rename struct tun_steering_prog to struct tun_prog To be reused by other eBPF program other than queue selection. Signed-off-by: Jason Wang <jasowang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 8bbfbc2df6e9a37bc5c9ee674c496ea277b0bd39 Author: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Date: Wed Jan 17 16:39:17 2018 +0300 ARCv2: cache: fix slc_entire_op: flush only instead of flush-n-inv slc_entire_op with OP_FLUSH command also invalidates it. This is a preventive fix as the current use of slc_entire_op is only with OP_FLUSH_N_INV where the invalidate is required. Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> [vgupta: fixed changelog] Signed-off-by: Vineet Gupta <vgupta@synopsys.com> commit 01353bbea50334847d4a7f9e0e8a31c609a21300 Author: Fengguang Wu <fengguang.wu@intel.com> Date: Thu Jan 18 01:51:18 2018 +0800 phy: brcm-sata: fix semicolon.cocci warnings drivers/phy/broadcom/phy-brcm-sata.c:534:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: 3e507769d15e ("phy: brcm-sata: Implement calibrate callback") CC: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Tejun Heo <tj@kernel.org> commit 4df0bfc79904b7169dc77dcce44598b1545721f9 Author: Cong Wang <xiyou.wangcong@gmail.com> Date: Mon Jan 15 11:37:29 2018 -0800 tun: fix a memory leak for tfile->tx_array tfile->tun could be detached before we close the tun fd, via tun_detach_all(), so it should not be used to check for tfile->tx_array. As Jason suggested, we probably have to clean it up unconditionally both in __tun_deatch() and tun_detach_all(), but this requires to check if it is initialized or not. Currently skb_array_cleanup() doesn't have such a check, so I check it in the caller and introduce a helper function, it is a bit ugly but we can always improve it in net-next. Reported-by: Dmitry Vyukov <dvyukov@google.com> Fixes: 1576d9860599 ("tun: switch to use skb array for tx") Cc: Jason Wang <jasowang@redhat.com> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 4b23258d6a1b0040c1e7d2d997800cfd09294b7f Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:57 2018 +0100 mlxsw: spectrum_acl: Pass mlxsw_sp_port down to ruleset bind/unbind ops No need to convert from mlxsw_sp_port to net_device and back again. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 3aaff323044e221b7233eddcc2fe094c662df3b0 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:56 2018 +0100 mlxsw: spectrum_acl: Implement TC block sharing Benefit from the prepared TC and in-driver ACL infrastructure and introduce block sharing offload. For that, a new struct "block" is introduced in spectrum_acl in order to hold a list of specific block-port bindings. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 02caf4995ad07c592d5bbf045f6198c08cd63e87 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:55 2018 +0100 mlxsw: spectrum_acl: Don't store netdev and ingress for ruleset unbind Instead, pass netdev and ingress flag to ruleset unbind op. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 9fe5fdf27e543c340d97f69f379bcd29a59f5723 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:54 2018 +0100 mlxsw: spectrum_acl: Reshuffle code around mlxsw_sp_acl_ruleset_create/destroy In order to prepare for follow-up changes, make the bind/unbind helpers very simple. That required move of ht insertion/removal and bind/unbind calls into mlxsw_sp_acl_ruleset_create/destroy. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 51ab2994c387c80b45caf8b8067b3f3b97771d25 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:53 2018 +0100 net: sched: allow ingress and clsact qdiscs to share filter blocks Benefit from the previously introduced shared filter blocks infrastructure and allow ingress and clsact qdisc instances to share filter blocks. The block index is coming from userspace as qdisc option. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit d47a6b0e7c492a4ba4524d557db388e34fd0a47a Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:52 2018 +0100 net: sched: introduce ingress/egress block index attributes for qdisc Introduce two new attributes to be used for qdisc creation and dumping. One for ingress block, one for egress block. Introduce a set of ops that qdisc which supports block sharing would implement. Passing block indexes in qdisc change is not supported yet and it is checked and forbidded. In future, these attributes are to be reused for specifying block indexes for classes as well. As of this moment however, it is not supported so a check is in place to forbid it. Suggested-by: Roopa Prabhu <roopa@cumulusnetworks.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 7960d1daf278cbe23bb48974fe6ae6a1e44c3c15 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:51 2018 +0100 net: sched: use block index as a handle instead of qdisc when block is shared As the tcm_ifindex with value TCM_IFINDEX_MAGIC_BLOCK is invalid ifindex, use it to indicate that we work with block, instead of qdisc. So if tcm_ifindex is set to TCM_IFINDEX_MAGIC_BLOCK, tcm_parent is used to carry block_index. If the block is set to be shared between at least 2 qdiscs, it is forbidden to use the qdisc handle to add/delete filters. In that case, userspace has to pass block_index. Also, for dump of the filters, in case the block is shared in between at least 2 qdiscs, the each filter is dumped with tcm_ifindex value TCM_IFINDEX_MAGIC_BLOCK and tcm_parent set to block_index. That gives the user clear indication, that the filter belongs to a shared block and not only to one qdisc under which it is dumped. Suggested-by: David Ahern <dsahern@gmail.com> Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit caa7260156eb3a1496348a2c69fa68e85183d5d7 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:50 2018 +0100 net: sched: keep track of offloaded filters and check tc offload feature During block bind, we need to check tc offload feature. If it is disabled yet still the block contains offloaded filters, forbid the bind. Also forbid to register callback for a block that already contains offloaded filters, as the play back is not supported now. For keeping track of offloaded filters there is a new counter introduced, alongside with couple of helpers called from cls_* code. These helpers set and clear TCA_CLS_FLAGS_IN_HW flag. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit edf6711c9840fd92e0047f98c411c94114168f19 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:49 2018 +0100 net: sched: remove classid and q fields from tcf_proto Both are no longer used, so remove them. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit f36fe1c498c8959812415c57b683abaa4527dec5 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:48 2018 +0100 net: sched: introduce block mechanism to handle netif_keep_dst calls Couple of classifiers call netif_keep_dst directly on q->dev. That is not possible to do directly for shared blocke where multiple qdiscs are owning the block. So introduce a infrastructure to keep track of the block owners in list and use this list to implement block variant of netif_keep_dst. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 9d3aaff3d8523264ff7082a90759cb8a340200be Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:47 2018 +0100 net: sched: avoid usage of tp->q in tcf_classify Use block index in the messages instead. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 4861738775d70e0165d04fe014f32b41bcb5414a Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:46 2018 +0100 net: sched: introduce shared filter blocks infrastructure Allow qdiscs to share filter blocks among them. Each qdisc type has to use block get/put extended modifications that enable sharing. Shared blocks are tracked within each net namespace and identified by u32 index. This index is passed from user during the qdisc creation. If user passes index that is not used by any other qdisc, new block is created. If user passes index that is already used, the existing block will be re-used. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit a9b19443edbaac97c5c094f3cc903c1f1548b3f5 Author: Jiri Pirko <jiri@mellanox.com> Date: Wed Jan 17 11:46:45 2018 +0100 net: sched: introduce support for multiple filter chain pointers registration So far, there was possible only to register a single filter chain pointer to block->chain[0]. However, when the blocks will get shareable, we need to allow multiple filter chain pointers registration. Signed-off-by: Jiri Pirko <jiri@mellanox.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Acked-by: David Ahern <dsahern@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit dd4ea1da12495e1b3c400a28df11528892199f68 Author: Sathya Perla <sathya.perla@broadcom.com> Date: Wed Jan 17 03:21:16 2018 -0500 bnxt_en: export a common switchdev PARENT_ID for all reps of an adapter Currently the driver exports different switchdev PARENT_IDs for representors belonging to different SR-IOV PF-pools of an adapter. This is not correct as the adapter can switch across all vports of an adapter. This patch fixes this by exporting a common switchdev PARENT_ID for all reps of an adapter. The PCIE DSN is used as the id. Signed-off-by: Sathya Perla <sathya.perla@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit c3480a603773cfc5d8aa44dbbee6c96e0f9d4d9d Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:15 2018 -0500 bnxt_en: Add cache line size setting to optimize performance. The chip supports 64-byte and 128-byte cache line size for more optimal DMA performance when matched to the CPU cache line size. The default is 64. If the system is using 128-byte cache line size, set it to 128. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 91cdda40714178497cbd182261b2ea6ec5cb9276 Author: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Date: Wed Jan 17 03:21:14 2018 -0500 bnxt_en: Forward VF MAC address to the PF. Forward hwrm_func_vf_cfg command from VF to PF driver, to store VF MAC address in PF's context. This will allow "ip link show" to display all VF MAC addresses. Maintain 2 locations of MAC address in VF info structure, one for a PF assigned MAC and one for VF assigned MAC. Display VF assigned MAC in "ip link show", only if PF assigned MAC is not valid. Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 92abef361bd233ea2a99db9e9a637626f523f82e Author: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Date: Wed Jan 17 03:21:13 2018 -0500 bnxt_en: Add BCM5745X NPAR device IDs Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 8f23d638b36b4ff0fe5785cf01f9bdc41afb9c06 Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:12 2018 -0500 bnxt_en: Expand bnxt_check_rings() to check all resources. bnxt_check_rings() is called by ethtool, XDP setup, and ndo_setup_tc() to see if there are enough resources to support the new configuration. Expand the call to test all resources if the firmware supports the new API. With the more flexible resource allocation scheme, this call must be made to check that all resources are available before committing to allocate the resources. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 4673d66468b80dc37abd1159a4bd038128173d48 Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:11 2018 -0500 bnxt_en: Implement new method for the PF to assign SRIOV resources. Instead of the old method of evenly dividing the resources to the VFs, use the new firmware API to specify min and max resources for each VF. This way, there is more flexibility for each VF to allocate more or less resources. The min is the absolute minimum for each VF to function. The max is the global resources minus the resources used by the PF. Each VF is guaranteed the min. Up to max resources may be available for some VFs. The PF driver can use one of 2 strategies specified in NVRAM to assign the resources. The old legacy strategy of evenly dividing the resources or the new flexible strategy. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 6a1eef5b9079742ecfad647892669bd5fe6b0e3f Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:10 2018 -0500 bnxt_en: Reserve resources for RFS. In bnxt_rfs_capable(), add call to reserve vnic resources to support NTUPLE. Return true if we can successfully reserve enough vnics. Otherwise, reserve the minimum 1 VNIC for normal operations not supporting NTUPLE and return false. Also, suppress warning message about not enough resources for NTUPLE when only 1 RX ring is in use. NTUPLE filters by definition require multiple RX rings. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 674f50a5b026151f4109992cb594d89f5334adde Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:09 2018 -0500 bnxt_en: Implement new method to reserve rings. The new method will call firmware to reserve the desired tx, rx, cmpl rings, ring groups, stats context, and vnic resources. A second query call will check the actual resources that firmware is able to reserve. The driver will then trim and adjust based on the actual resources provided by firmware. The driver will then reserve the final resources in use. This method is a more flexible way of using hardware resources. The resources are not fixed and can by adjusted by firmware. The driver adapts to the available resources that the firmware can reserve for the driver. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 58ea801ac4c166cdcaa399ce7f9b3e9095ff2842 Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:08 2018 -0500 bnxt_en: Set initial default RX and TX ring numbers the same in combined mode. In combined mode, the driver is currently not setting RX and TX ring numbers the same when firmware can allocate more RX than TX or vice versa. This will confuse the user as the ethtool convention assumes they are the same in combined mode. Fix it by adding bnxt_trim_dflt_sh_rings() to trim RX and TX ring numbers to be the same as the completion ring number in combined mode. Note that if TCs are enabled and/or XDP is enabled, the number of TX rings will not be the same as RX rings in combined mode. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit be0dd9c4100c9549fe50258e3d928072e6c31590 Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:07 2018 -0500 bnxt_en: Add the new firmware API to query hardware resources. The new API HWRM_FUNC_RESOURCE_QCAPS provides min and max hardware resources. Use the new API when it is supported by firmware. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 6a4f29470569c5a158c1871a2f752ca22e433420 Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:06 2018 -0500 bnxt_en: Refactor hardware resource data structures. In preparation for new firmware APIs to allocate hardware resources, add a new struct bnxt_hw_resc to hold various min, max and reserved resources. This new structure is common for PFs and VFs. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 80fcaf46c09262a71f32bb577c976814c922f864 Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:05 2018 -0500 bnxt_en: Restore MSIX after disabling SRIOV. After SRIOV has been enabled and disabled, the MSIX vectors assigned to the VFs have to be re-initialized. Otherwise they cannot be re-used by the PF. For example, increasing the number of PF rings after disabling SRIOV may fail if the PF uses MSIX vectors previously assigned to the VFs. To fix this, we add logic in bnxt_restore_pf_fw_resources() to close the NIC, clear and re-init MSIX, and re-open the NIC. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 86e953db0114f396f916344395160aa267bf2627 Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:04 2018 -0500 bnxt_en: Refactor bnxt_close_nic(). Add a new __bnxt_close_nic() function to do all the work previously done in bnxt_close_nic() except waiting for SRIOV configuration. The new function will be used in the next patch as part of SRIOV cleanup. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 894aa69a90932907f3de9d849ab9970884151d0e Author: Michael Chan <michael.chan@broadcom.com> Date: Wed Jan 17 03:21:03 2018 -0500 bnxt_en: Update firmware interface to 1.9.0. The version has new firmware APIs to allocate PF/VF resources more flexibly. New toolchains were used to generate this file, resulting in a one-time large diffstat. Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 4ec1dea0b2d2404200c348517bfca8b72037632d Author: Bjorn Helgaas <bhelgaas@google.com> Date: Tue Jan 16 17:37:50 2018 -0600 PCI/DPC: Add and use DPC Status register field definitions Add definitions for DPC Status register fields and use them in the code. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> commit fb7d38a70e1d8ffd54f7a7464dcc4889d7e490ad Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Date: Mon Jan 15 18:10:15 2018 +0100 net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock On Meson8b the only valid input clock is MPLL2. The bootloader configures that to run at 500002394Hz which cannot be divided evenly down to 125MHz using the m250_div clock. Currently the common clock framework chooses a m250_div of 2 - with the internal fixed "divide by 10" this results in a RGMII TX clock of 125001197Hz (120Hz above the requested 125MHz). Letting the common clock framework propagate the rate changes up to the parent of m250_mux allows us to get the best possible clock rate. With this patch the common clock framework calculates a rate of very-close-to-250MHz (249999701Hz to be exact) for the MPLL2 clock (which is the mux input). Dividing that by 2 (which is an internal, fixed divider for the RGMII TX clock) gives us an RGMII TX clock of 124999850Hz (which is only 150Hz off the requested 125MHz, compared to 1197Hz based on the MPLL2 rate set by u-boot and the Amlogic GPL kernel sources). SoCs from the Meson GX series are not affected by this change because the input clock is FCLK_DIV2 whose rate cannot be changed (which is fine since it's running at 1GHz, so it's already a multiple of 250MHz and 125MHz). Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Suggested-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 433c6cab9d298687c097f6ee82e49157044dc7c6 Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Date: Mon Jan 15 18:10:14 2018 +0100 net: stmmac: dwmac-meson8b: fix setting the RGMII TX clock on Meson8b Meson8b only supports MPLL2 as clock input. The rate of the MPLL2 clock set by Odroid-C1's u-boot is close to (but not exactly) 500MHz. The exact rate is 500002394Hz, which is calculated in drivers/clk/meson/clk-mpll.c using the following formula: DIV_ROUND_UP_ULL((u64)parent_rate * SDM_DEN, (SDM_DEN * n2) + sdm) Odroid-C1's u-boot configures MPLL2 with the following values: - SDM_DEN = 16384 - SDM = 1638 - N2 = 5 The 250MHz clock (m250_div) inside dwmac-meson8b driver is derived from the MPLL2 clock. Due to MPLL2 running slightly faster than 500MHz the common clock framework chooses a divider which is too big to generate the 250MHz clock (a divider of 2 would be needed, but this is rounded up to a divider of 3). This breaks the RTL8211F RGMII PHY on Odroid-C1 because it requires a (close to) 125MHz RGMII TX clock (on Gbit speeds, the IP block internally divides that down to 25MHz on 100Mbit/s connections and 2.5MHz on 10Mbit/s connections - we don't need any special configuration for that). Round the divider to the closest value to prevent this issue on Meson8b. This means we'll now end up with a clock rate for the RGMII TX clock of 125001197Hz (= 125MHz plus 1197Hz), which is close-enough to 125MHz. This has no effect on the Meson GX SoCs since there fclk_div2 is used as input clock, which has a rate of 1000MHz (and thus is divisible cleanly to 250MHz and 125MHz). Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Reported-by: Emiliano Ingrassia <ingrassia@epigenesys.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 4f6a71b84e1afdf13827741e7421a844203cf8d0 Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Date: Mon Jan 15 18:10:13 2018 +0100 net: stmmac: dwmac-meson8b: fix internal RGMII clock configuration Tests (using an oscilloscope and an Odroid-C1 board with a RTL8211F RGMII PHY) have shown that the PRG_ETH0 register behaves as follows: - bit 4 is a mux to choose between two parent clocks. according to the public S805 datasheet the only supported parent clock is MPLL2 (this was not verified using the oscilloscope). The public S805/S905 datasheet claims that this bit is reserved. - bits 9:7 control a one-based divider (register value 1 means "divide by 1", etc.) for the input clock. we call this clock the "m250_div" clock because it's value is always supposed to be (close to) 250MHz (see below for an explanation). The description in the public S805/S905 datasheet is a bit cryptic, but it comes down to "input clock = 250MHz * value" (which could also be expressed as "250MHz = input clock / value") - there seems to be an internal fixed divide-by-2 clock which takes the output from the m250_div and divides it by 2. This is not unusual on Amlogic SoCs, since the SDIO (MMC) driver also uses an internal fixed divide-by-2 clock. This is not documented in the public S805/S905 datasheet - bit 10 controls a gate clock which enables or disables the RGMII TX clock (which is an output on the MAC/SoC and an input in the PHY). we call this the "rgmii_tx_en" clock. if this bit is set to "0" the RGMII TX clock output is close to 0 The description for this bit in the public S805/S905 datasheet is "Generate 25MHz clock for PHY". Based on these tests it's believed that this is wrong, and should probably read "Generate the 125MHz RGMII TX clock for the PHY" - the RGMII TX clock has to be set to 125MHz - the IP block adjusts the output (automatically) depending on the line speed (RGMII specifies that Gbit connections use a 125MHz clock, 100Mbit/s connections use a 25MHz clock and 10Mbit/s connections use a 2.5MHz clock. only Gbit and 100Mbit/s were tested with an oscilloscope). Due to the requirement that this clock always has to be set to 125MHz and due to the fixed divide-by-2 parent clock this means that m250_div will always end up with a rate of (close to) 250MHz. - bits 6:5 are the TX delay, which is also named "clock phase" in some of Amlogic's older GPL kernel sources. The PHY also has an XTAL_IN pin where a 25MHz clock has to be provided. Tests with the oscilloscope have shown that this is routed to a crystal right next to the RTL8211F PHY. The same seems to be true on the Khadas VIM2 (which uses a GXM SoC) board - however the 25MHz crystal is on the other side of the PCB there. This updates the clocks in the dwmac-meson8b driver by replacing the "m25_div" with the "rgmii_tx_en" clock and additionally introducing a fixed divide-by-2 clock between "m250_div" and "rgmii_tx_en". Now we also need to set a frequency of 125MHz on the RGMII clock (opposed to the 25MHz we set before, with that non-existing divide-by-5-or-10 divider). Special thanks go to Linus Lüssing for testing the various bits and checking the results with an oscilloscope on his Odroid-C1! Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Reported-by: Emiliano Ingrassia <ingrassia@epigenesys.com> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Jerome Brunet <jbrunet@baylibre.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 37512b42f082d784a012c3734ef109f25d199786 Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Date: Mon Jan 15 18:10:12 2018 +0100 net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode Neither the m25_div_clk nor the m250_div_clk or m250_mux_clk are used in RMII mode. The m25_div_clk output is routed to the RGMII PHY's "RGMII clock". This means that we don't need to configure the clocks in RMII mode. The driver however did this - with no effect since the clocks are not routed to the PHY in RMII mode. While here also rename meson8b_init_clk to meson8b_init_rgmii_tx_clk to make it easier to understand the code. Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Tested-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit 091f02483df7b56615b524491f404e574c5e0668 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 12:11:26 2018 +0000 ARM: net: bpf: clarify tail_call index As per 90caccdd8cc0 ("bpf: fix bpf_tail_call() x64 JIT"), the index used for array lookup is defined to be 32-bit wide. Update a misleading comment that suggests it is 64-bit wide. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit ec19e02b343db991d2d1610c409efefebf4e2ca9 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 21:06:16 2018 +0000 ARM: net: bpf: fix LDX instructions When the source and destination register are identical, our JIT does not generate correct code, which leads to kernel oopses. Fix this by (a) generating more efficient code, and (b) making use of the temporary earlier if we will overwrite the address register. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 02088d9b392f605c892894b46aa8c83e3abd0115 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 22:38:18 2018 +0000 ARM: net: bpf: fix register saving When an eBPF program tail-calls another eBPF program, it enters it after the prologue to avoid having complex stack manipulations. This can lead to kernel oopses, and similar. Resolve this by always using a fixed stack layout, a CPU register frame pointer, and using this when reloading registers before returning. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 0005e55a79cfda88199e41a406a829c88d708c67 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 22:51:27 2018 +0000 ARM: net: bpf: correct stack layout documentation The stack layout documentation incorrectly suggests that the BPF JIT scratch space starts immediately below BPF_FP. This is not correct, so let's fix the documentation to reflect reality. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 70ec3a6c2c11e4b0e107a65de943a082f9aff351 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 21:26:14 2018 +0000 ARM: net: bpf: move stack documentation Move the stack documentation towards the top of the file, where it's relevant for things like the register layout. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit d1220efd23484c72c82d5471f05daeb35b5d1916 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 16:10:07 2018 +0000 ARM: net: bpf: fix stack alignment As per 2dede2d8e925 ("ARM EABI: stack pointer must be 64-bit aligned after a CPU exception") the stack should be aligned to a 64-bit boundary on EABI systems. Ensure that the eBPF JIT appropraitely aligns the stack. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit f4483f2cc1fdc03488c8a1452e545545ae5bda93 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 11:39:54 2018 +0000 ARM: net: bpf: fix tail call jumps When a tail call fails, it is documented that the tail call should continue execution at the following instruction. An example tail call sequence is: 12: (85) call bpf_tail_call#12 13: (b7) r0 = 0 14: (95) exit The ARM assembler for the tail call in this case ends up branching to instruction 14 instead of instruction 13, resulting in the BPF filter returning a non-zero value: 178: ldr r8, [sp, #588] ; insn 12 17c: ldr r6, [r8, r6] 180: ldr r8, [sp, #580] 184: cmp r8, r6 188: bcs 0x1e8 18c: ldr r6, [sp, #524] 190: ldr r7, [sp, #528] 194: cmp r7, #0 198: cmpeq r6, #32 19c: bhi 0x1e8 1a0: adds r6, r6, #1 1a4: adc r7, r7, #0 1a8: str r6, [sp, #524] 1ac: str r7, [sp, #528] 1b0: mov r6, #104 1b4: ldr r8, [sp, #588] 1b8: add r6, r8, r6 1bc: ldr r8, [sp, #580] 1c0: lsl r7, r8, #2 1c4: ldr r6, [r6, r7] 1c8: cmp r6, #0 1cc: beq 0x1e8 1d0: mov r8, #32 1d4: ldr r6, [r6, r8] 1d8: add r6, r6, #44 1dc: bx r6 1e0: mov r0, #0 ; insn 13 1e4: mov r1, #0 1e8: add sp, sp, #596 ; insn 14 1ec: pop {r4, r5, r6, r7, r8, sl, pc} For other sequences, the tail call could end up branching midway through the following BPF instructions, or maybe off the end of the function, leading to unknown behaviours. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit e9062481824384f00299971f923fecf6b3668001 Author: Russell King <rmk+kernel@armlinux.org.uk> Date: Sat Jan 13 11:35:15 2018 +0000 ARM: net: bpf: avoid 'bx' instruction on non-Thumb capable CPUs Avoid the 'bx' instruction on CPUs that have no support for Thumb and thus do not implement this instruction by moving the generation of this opcode to a separate function that selects between: bx reg and mov pc, reg according to the capabilities of the CPU. Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> commit 416ef9b15c688b91edbf654ebe7bc349c9151147 Author: Jakub Kicinski <jakub.kicinski@netronome.com> Date: Sun Jan 14 20:01:26 2018 -0800 net: sched: red: don't reset the backlog on every stat dump Commit 0dfb33a0d7e2 ("sch_red: report backlog information") copied child's backlog into RED's backlog. Back then RED did not maintain its own backlog counts. This has changed after commit 2ccccf5fb43f ("net_sched: update hierarchical backlog too") and commit d7f4f332f082 ("sch_red: update backlog as well"). Copying is no longer necessary. Tested: $ tc -s qdisc show dev veth0 qdisc red 1: root refcnt 2 limit 400000b min 30000b max 30000b ecn Sent 20942 bytes 221 pkt (dropped 0, overlimits 0 requeues 0) backlog 1260b 14p requeues 14 marked 0 early 0 pdrop 0 other 0 qdisc tbf 2: parent 1: rate 1Kbit burst 15000b lat 3585.0s Sent 20942 bytes 221 pkt (dropped 0, overlimits 138 requeues 0) backlog 1260b 14p requeues 14 Recently RED offload was added. We need to make sure drivers don't depend on resetting the stats. This means backlog should be treated like any other statistic: total_stat = new_hw_stat - prev_hw_stat; Adjust mlxsw. Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com> Acked-by: Nogah Frankel <nogahf@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> commit c0e860ba034ead2a0f47052c87266e90f23cdb7b Author: Jeff Westfahl <jeff.westfahl@ni.com> Date: Tue Jan 10 13:30:18 2017 -0600 mtd: ubi: Use 'max_bad_blocks' to compute bad_peb_limit if available If the user has not set max_beb_per1024 using either the cmdline or Kconfig options for doing so, use the MTD function 'max_bad_blocks' to compute the UBI bad_peb_limit. Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com> Signed-off-by: Zach Brown <zach.brown@ni.com> Acked-by: Boris Brezillon <boris.brezillon@free-electron.com> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Richard Weinberger <richard@nod.at> commit c877154d307f4a91e0b5b85b75535713dab945ae Author: Geert Uytterhoeven <geert@linux-m68k.org> Date: Sun Sep 17 10:32:20 2017 +0200 ubifs: Fix uninitialized variable in search_dh_cookie() fs/ubifs/tnc.c: In function ‘search_dh_cookie’: fs/ubifs/tnc.c:1893: warning: ‘err’ is used uninitialized in this function Indeed, err is always used uninitialized. According to an original review comment from Hyunchul, acknowledged by Richard, err should be initialized to -ENOENT to avoid the first call to tnc_next(). But we can achieve the same by reordering the code. Fixes: 781f675e2d7e ("ubifs: Fix unlink code wrt. double hash lookups") Reported-by: Hyunchul Lee <hyc.lee@gmail.com> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Richard Weinberger <richard@nod.at> commit 698c03b4745006e14eccb8270f714d52fac1c97e Author: Julia Lawall <Julia.Lawall@lip6.fr> Date: Tue Jan 16 16:56:54 2018 -0800 Input: inline macros for MODULE_LICENSE, etc Inline macro for MODULE_LICENSE to make the license information easy to find, eg with grep. Inline the other module-related macros at the same time. A simplified version of the semantic patch for the MODULE_LICENSE case is as follows: (http://coccinelle.lip6.fr/) // <smpl> @s@ identifier i; expression e; @@ @@ declarer name MODULE_LICENSE; identifier s.i; expression s.e; @@ MODULE_LICENSE( - i + e ); // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> [dtor: added a couple of drivers missed by the script, removed a few unused DRIVER_VERSION macros] Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> commit 75ea1aabdba38daaeaaa4e5922ac85907b0a68b0 Author: Ulf Magnusson <ulfalizer@gmail.com> Date: Sun Jan 14 10:56:20 2018 +0100 kconfig: Document SYMBOL_OPTIONAL logic Not obvious, especially if you don't already know how choices are implemented. No functional changes. Only comments added. Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> commit 9afcc6e739403694593a6cdfde09d87f0c2c81b1 Author: Masahiro Yamada <yamada.masahiro@socionext.com> Date: Fri Jan 12 00:51:52 2018 +0900 kbuild: remove unnecessary LEX_PREFIX and YACC_PREFIX Kconfig was the only user of these. With Kconfig converted to use the default 'yy' prefix, we do not need them any more. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com> commit bb6e15ae0127436cf4cbc10e7f82696538b7cabc Author: Masahiro Yamada <yamada.masahiro@socionext.com> Date: Fri Jan 12 00:50:50 2018 +0900 kconfig: use default 'yy' prefix for lexer and parser Flex and Bison provide an option to change the prefix of globally- visible symbols. This is useful to link multiple lexers and/or parsers into the same executable. However, Kconfig (and any other host programs in kernel) uses a single lexer and parser. I do not see a good reason to change the default 'yy' prefix. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com> commit de99a346884f019387230bc549de74456daca248 Author: Bart Van Assche <bart.vanassche@wdc.com> Date: Tue Jan 16 10:31:39 2018 -0800 block: Fix __bio_integrity_endio() documentation Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio") Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> commit 5badd82f5ac0a2945914e6fe973cd79ec63c3c2f Author: Masahiro Yamada <yamada.masahiro@socionext.com> Date: Thu Jan 11 22:39:41 2018 +0900 kconfig: make conf_unsaved a local variable of conf_read() conf_unsaved is initialized by conf_read_simple(), but it is possible to move it to conf_read() so that it can be a local variable. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> commit d7daabf8e860fd0a9c2f8a3acac09ff2d4375fd2 Author: Masahiro Yamada <yamada.masahiro@socionext.com> Date: Thu Jan 11 22:39:40 2018 +0900 kconfig: make xfgets() really static Sparse reports: warning: symbol 'xfgets' was not declared. Should it be static? It is declared as static, but it is missing in the definition part. Move the definition up and remove the forward declaration. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> commit 1c884d196f50442206f4f4797123062da4ff8a62 Author: Masahiro Yamada <yamada.masahiro@socionext.com> Date: Thu Jan 11 22:39:39 2018 +0900 kconfig: make input_mode static Sparse reports: warning: symbol 'input_mode' was not declared. Should it be static? Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> commit 4c93867aeb260b01a7983f9aaff39b61067dea97 Author: Lucas Stach <l.stach@pengutronix.de> Date: Wed Dec 6 10:53:27 2017 +0100 drm/etnaviv: replace hangcheck with scheduler timeout This replaces the etnaviv internal hangcheck logic with the job timeout handling provided by the DRM scheduler. This simplifies the driver further and allows to replay jobs after a GPU reset, so only minimal state is lost. This introduces a user-visible change in that we don't allow jobs to run indefinitely as long as they make progress anymore, as this introduces quality of service issues when multiple processes are using the GPU. Userspace is now responsible to flush jobs in a way that the finish in a reasonable time, where reasonable is currently defined as less than 500ms. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> commit a5a76c4b88c8fa50ae58fd55f023116a04cb6e70 Author: Lucas Stach <l.stach@pengutronix.de> Date: Tue Dec 5 10:55:02 2017 +0100 drm/etnaviv: lock BOs after all other submit work is done Populating objects, adding them to the GPU VM and patching/validating the command stream might take a lot of CPU time. There is no reason to hold all object reservations during that time. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> commit b98a98076f6951408e054247e32951cf858d5772 Author: Lucas Stach <l.stach@pengutronix.de> Date: Mon Dec 4 19:24:06 2017 +0100 drm/etnaviv: move dependency handling to scheduler Move the fence dependency handling to the scheduler where it belongs. Jobs with unsignaled dependencies just get to sit in the scheduler queue without holding any locks. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> commit 2ffdcf4aca80379a99386b750b0fc8a80e62d702 Author: Lucas Stach <l.stach@pengutronix.de> Date: Mon Dec 4 18:41:58 2017 +0100 drm/etnaviv: hook up DRM GPU scheduler This hooks in the DRM GPU scheduler. No improvement yet, as all the dependency handling is still done in etnaviv_gem_submit. This just replaces the actual GPU submit by passing through the scheduler. Allows to get rid of the retire worker, as this is now driven by the scheduler. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> commit 9e97d2951a7e6ee6e204f87f6bda4ff754a8cede Author: Mike Snitzer <snitzer@redhat.com> Date: Wed Jan 17 11:25:58 2018 -0500 blk-mq-sched: remove unused 'can_block' arg from blk_mq_sched_insert_request After commit: 923218f6166a ("blk-mq: don't allocate driver tag upfront for flush rq") we no longer use the 'can_block' argument in blk_mq_sched_insert_request(). Kill it. Signed-off-by: Mike Snitzer <snitzer@redhat.com> Added actual commit message as to why it's being removed. Signed-off-by: Jens Axboe <axboe@kernel.dk> commit 47b8e8ce7ddc72710feda874bb9732a3c2156204 Author: Lucas Stach <l.stach@pengutronix.de> Date: Wed Nov 29 14:49:04 2017 +0100 drm/etnaviv: track fences by IDR instead of seqno This moves away from using the internal seqno as the userspace fence reference. By moving to a generic ID, we can later replace the internal fence by something different than the etnaviv seqno fence. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> commit 82fc7a3eea66fec5c8a3eaaaaac9fd88f8ab5a31 Author: Lucas Stach <l.stach@pengutronix.de> Date: Thu Jan 4 13:50:14 2018 +0100 drm/etnaviv: add missing major features field to debugfs This can be useful when dealing with a new GPU core. Signed-off-by: Lucas Stach <l.stach@pengutronix.de> commit 16f9560aa73331fb9311418de36b573a1b65d08f Aut…
otavio
referenced
this pull request
in Freescale/linux-fslc
Feb 1, 2018
commit f4483f2 upstream. When a tail call fails, it is documented that the tail call should continue execution at the following instruction. An example tail call sequence is: 12: (85) call bpf_tail_call#12 13: (b7) r0 = 0 14: (95) exit The ARM assembler for the tail call in this case ends up branching to instruction 14 instead of instruction 13, resulting in the BPF filter returning a non-zero value: 178: ldr r8, [sp, #588] ; insn 12 17c: ldr r6, [r8, r6] 180: ldr r8, [sp, #580] 184: cmp r8, r6 188: bcs 0x1e8 18c: ldr r6, [sp, #524] 190: ldr r7, [sp, #528] 194: cmp r7, #0 198: cmpeq r6, #32 19c: bhi 0x1e8 1a0: adds r6, r6, #1 1a4: adc r7, r7, #0 1a8: str r6, [sp, #524] 1ac: str r7, [sp, #528] 1b0: mov r6, #104 1b4: ldr r8, [sp, #588] 1b8: add r6, r8, r6 1bc: ldr r8, [sp, #580] 1c0: lsl r7, r8, #2 1c4: ldr r6, [r6, r7] 1c8: cmp r6, #0 1cc: beq 0x1e8 1d0: mov r8, #32 1d4: ldr r6, [r6, r8] 1d8: add r6, r6, #44 1dc: bx r6 1e0: mov r0, #0 ; insn 13 1e4: mov r1, #0 1e8: add sp, sp, #596 ; insn 14 1ec: pop {r4, r5, r6, r7, r8, sl, pc} For other sequences, the tail call could end up branching midway through the following BPF instructions, or maybe off the end of the function, leading to unknown behaviours. Fixes: 39c13c2 ("arm: eBPF JIT compiler") Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iaguis
pushed a commit
to kinvolk/linux
that referenced
this pull request
Feb 6, 2018
Rebase patches onto 4.13.11
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
May 13, 2018
This addresses 3 separate problems: 1. When using NVME over Fabrics we may end up sending IP packets in interrupt context, we should defer this work to a tasklet. [ 50.939957] WARNING: CPU: 3 PID: 0 at kernel/softirq.c:161 __local_bh_enable_ip+0x1f/0xa0 [ 50.942602] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G W 4.17.0-rc3-ARCH+ torvalds#104 [ 50.945466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 [ 50.948163] RIP: 0010:__local_bh_enable_ip+0x1f/0xa0 [ 50.949631] RSP: 0018:ffff88009c183900 EFLAGS: 00010006 [ 50.951029] RAX: 0000000080010403 RBX: 0000000000000200 RCX: 0000000000000001 [ 50.952636] RDX: 0000000000000000 RSI: 0000000000000200 RDI: ffffffff817e04ec [ 50.954278] RBP: ffff88009c183910 R08: 0000000000000001 R09: 0000000000000614 [ 50.956000] R10: ffffea00021d5500 R11: 0000000000000001 R12: ffffffff817e04ec [ 50.957779] R13: 0000000000000000 R14: ffff88009566f400 R15: ffff8800956c7000 [ 50.959402] FS: 0000000000000000(0000) GS:ffff88009c180000(0000) knlGS:0000000000000000 [ 50.961552] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 50.963798] CR2: 000055c4ec0ccac0 CR3: 0000000002209001 CR4: 00000000000606e0 [ 50.966121] Call Trace: [ 50.966845] <IRQ> [ 50.967497] __dev_queue_xmit+0x62d/0x690 [ 50.968722] dev_queue_xmit+0x10/0x20 [ 50.969894] neigh_resolve_output+0x173/0x190 [ 50.971244] ip_finish_output2+0x2b8/0x370 [ 50.972527] ip_finish_output+0x1d2/0x220 [ 50.973785] ? ip_finish_output+0x1d2/0x220 [ 50.975010] ip_output+0xd4/0x100 [ 50.975903] ip_local_out+0x3b/0x50 [ 50.976823] rxe_send+0x74/0x120 [ 50.977702] rxe_requester+0xe3b/0x10b0 [ 50.978881] ? ip_local_deliver_finish+0xd1/0xe0 [ 50.980260] rxe_do_task+0x85/0x100 [ 50.981386] rxe_run_task+0x2f/0x40 [ 50.982470] rxe_post_send+0x51a/0x550 [ 50.983591] nvmet_rdma_queue_response+0x10a/0x170 [ 50.985024] __nvmet_req_complete+0x95/0xa0 [ 50.986287] nvmet_req_complete+0x15/0x60 [ 50.987469] nvmet_bio_done+0x2d/0x40 [ 50.988564] bio_endio+0x12c/0x140 [ 50.989654] blk_update_request+0x185/0x2a0 [ 50.990947] blk_mq_end_request+0x1e/0x80 [ 50.991997] nvme_complete_rq+0x1cc/0x1e0 [ 50.993171] nvme_pci_complete_rq+0x117/0x120 [ 50.994355] __blk_mq_complete_request+0x15e/0x180 [ 50.995988] blk_mq_complete_request+0x6f/0xa0 [ 50.997304] nvme_process_cq+0xe0/0x1b0 [ 50.998494] nvme_irq+0x28/0x50 [ 50.999572] __handle_irq_event_percpu+0xa2/0x1c0 [ 51.000986] handle_irq_event_percpu+0x32/0x80 [ 51.002356] handle_irq_event+0x3c/0x60 [ 51.003463] handle_edge_irq+0x1c9/0x200 [ 51.004473] handle_irq+0x23/0x30 [ 51.005363] do_IRQ+0x46/0xd0 [ 51.006182] common_interrupt+0xf/0xf [ 51.007129] </IRQ> 2. Work must always be offloaded to tasklet for rxe_post_send_kernel() when using NVMEoF in order to solve lock ordering between neigh->ha_lock seqlock and the nvme queue lock: [ 77.833783] Possible interrupt unsafe locking scenario: [ 77.833783] [ 77.835831] CPU0 CPU1 [ 77.837129] ---- ---- [ 77.838313] lock(&(&n->ha_lock)->seqcount); [ 77.839550] local_irq_disable(); [ 77.841377] lock(&(&nvmeq->q_lock)->rlock); [ 77.843222] lock(&(&n->ha_lock)->seqcount); [ 77.845178] <Interrupt> [ 77.846298] lock(&(&nvmeq->q_lock)->rlock); [ 77.847986] [ 77.847986] *** DEADLOCK *** 3. Same goes for the lock ordering between sch->q.lock and nvme queue lock: [ 47.634271] Possible interrupt unsafe locking scenario: [ 47.634271] [ 47.636452] CPU0 CPU1 [ 47.637861] ---- ---- [ 47.639285] lock(&(&sch->q.lock)->rlock); [ 47.640654] local_irq_disable(); [ 47.642451] lock(&(&nvmeq->q_lock)->rlock); [ 47.644521] lock(&(&sch->q.lock)->rlock); [ 47.646480] <Interrupt> [ 47.647263] lock(&(&nvmeq->q_lock)->rlock); [ 47.648492] [ 47.648492] *** DEADLOCK *** Using NVMEoF after this patch seems to finally be stable, without it, rxe eventually deadlocks the whole system and causes RCU stalls. Signed-off-by: Alexandru Moise <00moses.alexander00@gmail.com> Reviewed-by: Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
alaahl
pushed a commit
to alaahl/linux
that referenced
this pull request
May 17, 2018
This addresses 3 separate problems: 1. When using NVME over Fabrics we may end up sending IP packets in interrupt context, we should defer this work to a tasklet. [ 50.939957] WARNING: CPU: 3 PID: 0 at kernel/softirq.c:161 __local_bh_enable_ip+0x1f/0xa0 [ 50.942602] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G W 4.17.0-rc3-ARCH+ torvalds#104 [ 50.945466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014 [ 50.948163] RIP: 0010:__local_bh_enable_ip+0x1f/0xa0 [ 50.949631] RSP: 0018:ffff88009c183900 EFLAGS: 00010006 [ 50.951029] RAX: 0000000080010403 RBX: 0000000000000200 RCX: 0000000000000001 [ 50.952636] RDX: 0000000000000000 RSI: 0000000000000200 RDI: ffffffff817e04ec [ 50.954278] RBP: ffff88009c183910 R08: 0000000000000001 R09: 0000000000000614 [ 50.956000] R10: ffffea00021d5500 R11: 0000000000000001 R12: ffffffff817e04ec [ 50.957779] R13: 0000000000000000 R14: ffff88009566f400 R15: ffff8800956c7000 [ 50.959402] FS: 0000000000000000(0000) GS:ffff88009c180000(0000) knlGS:0000000000000000 [ 50.961552] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 50.963798] CR2: 000055c4ec0ccac0 CR3: 0000000002209001 CR4: 00000000000606e0 [ 50.966121] Call Trace: [ 50.966845] <IRQ> [ 50.967497] __dev_queue_xmit+0x62d/0x690 [ 50.968722] dev_queue_xmit+0x10/0x20 [ 50.969894] neigh_resolve_output+0x173/0x190 [ 50.971244] ip_finish_output2+0x2b8/0x370 [ 50.972527] ip_finish_output+0x1d2/0x220 [ 50.973785] ? ip_finish_output+0x1d2/0x220 [ 50.975010] ip_output+0xd4/0x100 [ 50.975903] ip_local_out+0x3b/0x50 [ 50.976823] rxe_send+0x74/0x120 [ 50.977702] rxe_requester+0xe3b/0x10b0 [ 50.978881] ? ip_local_deliver_finish+0xd1/0xe0 [ 50.980260] rxe_do_task+0x85/0x100 [ 50.981386] rxe_run_task+0x2f/0x40 [ 50.982470] rxe_post_send+0x51a/0x550 [ 50.983591] nvmet_rdma_queue_response+0x10a/0x170 [ 50.985024] __nvmet_req_complete+0x95/0xa0 [ 50.986287] nvmet_req_complete+0x15/0x60 [ 50.987469] nvmet_bio_done+0x2d/0x40 [ 50.988564] bio_endio+0x12c/0x140 [ 50.989654] blk_update_request+0x185/0x2a0 [ 50.990947] blk_mq_end_request+0x1e/0x80 [ 50.991997] nvme_complete_rq+0x1cc/0x1e0 [ 50.993171] nvme_pci_complete_rq+0x117/0x120 [ 50.994355] __blk_mq_complete_request+0x15e/0x180 [ 50.995988] blk_mq_complete_request+0x6f/0xa0 [ 50.997304] nvme_process_cq+0xe0/0x1b0 [ 50.998494] nvme_irq+0x28/0x50 [ 50.999572] __handle_irq_event_percpu+0xa2/0x1c0 [ 51.000986] handle_irq_event_percpu+0x32/0x80 [ 51.002356] handle_irq_event+0x3c/0x60 [ 51.003463] handle_edge_irq+0x1c9/0x200 [ 51.004473] handle_irq+0x23/0x30 [ 51.005363] do_IRQ+0x46/0xd0 [ 51.006182] common_interrupt+0xf/0xf [ 51.007129] </IRQ> 2. Work must always be offloaded to tasklet for rxe_post_send_kernel() when using NVMEoF in order to solve lock ordering between neigh->ha_lock seqlock and the nvme queue lock: [ 77.833783] Possible interrupt unsafe locking scenario: [ 77.833783] [ 77.835831] CPU0 CPU1 [ 77.837129] ---- ---- [ 77.838313] lock(&(&n->ha_lock)->seqcount); [ 77.839550] local_irq_disable(); [ 77.841377] lock(&(&nvmeq->q_lock)->rlock); [ 77.843222] lock(&(&n->ha_lock)->seqcount); [ 77.845178] <Interrupt> [ 77.846298] lock(&(&nvmeq->q_lock)->rlock); [ 77.847986] [ 77.847986] *** DEADLOCK *** 3. Same goes for the lock ordering between sch->q.lock and nvme queue lock: [ 47.634271] Possible interrupt unsafe locking scenario: [ 47.634271] [ 47.636452] CPU0 CPU1 [ 47.637861] ---- ---- [ 47.639285] lock(&(&sch->q.lock)->rlock); [ 47.640654] local_irq_disable(); [ 47.642451] lock(&(&nvmeq->q_lock)->rlock); [ 47.644521] lock(&(&sch->q.lock)->rlock); [ 47.646480] <Interrupt> [ 47.647263] lock(&(&nvmeq->q_lock)->rlock); [ 47.648492] [ 47.648492] *** DEADLOCK *** Using NVMEoF after this patch seems to finally be stable, without it, rxe eventually deadlocks the whole system and causes RCU stalls. Signed-off-by: Alexandru Moise <00moses.alexander00@gmail.com> Reviewed-by: Zhu Yanjun <yanjun.zhu@oracle.com> Signed-off-by: Doug Ledford <dledford@redhat.com>
mrchapp
pushed a commit
to mrchapp/linux
that referenced
this pull request
Apr 1, 2020
commit d0bab0c upstream. On a system with only one CPU online, when another one CPU panics while starting-up, smp_send_stop() will fail to send any STOP message to the other already online core, resulting in a system still responsive and alive at the end of the panic procedure. [ 186.700083] CPU3: shutdown [ 187.075462] CPU2: shutdown [ 187.162869] CPU1: shutdown [ 188.689998] ------------[ cut here ]------------ [ 188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886! [ 188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 188.692444] Modules linked in: [ 188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104 [ 188.693175] Hardware name: Foundation-v8A (DT) [ 188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO) [ 188.694183] pc : has_cpuid_feature+0xf0/0x348 [ 188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8 [ 188.694410] sp : ffff800011b1bf60 [ 188.694536] x29: ffff800011b1bf60 x28: 0000000000000000 [ 188.694707] x27: 0000000000000000 x26: 0000000000000000 [ 188.694801] x25: 0000000000000000 x24: ffff80001189a25c [ 188.694905] x23: 0000000000000000 x22: 0000000000000000 [ 188.694996] x21: ffff8000114aa018 x20: ffff800011156a38 [ 188.695089] x19: ffff800010c944a0 x18: 0000000000000004 [ 188.695187] x17: 0000000000000000 x16: 0000000000000000 [ 188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa [ 188.695371] x13: 0000000000000002 x12: 0000000000002592 [ 188.695472] x11: 0000000000000080 x10: 00400032b5503510 [ 188.695572] x9 : 0000000000000000 x8 : ffff800010c80204 [ 188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001 [ 188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000 [ 188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8 [ 188.695919] x1 : 0000000000180420 x0 : 0000000000180480 [ 188.696253] Call trace: [ 188.696410] has_cpuid_feature+0xf0/0x348 [ 188.696504] verify_local_elf_hwcaps+0x84/0xe8 [ 188.696591] check_local_cpu_capabilities+0x44/0x128 [ 188.696666] secondary_start_kernel+0xf4/0x188 [ 188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000) [ 188.698639] ---[ end trace 3f12ca47652f7b72 ]--- [ 188.699160] Kernel panic - not syncing: Attempted to kill the idle task! [ 188.699546] Kernel Offset: disabled [ 188.699828] CPU features: 0x00004,20c02008 [ 188.700012] Memory Limit: none [ 188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- [root@arch ~]# echo Helo Helo [root@arch ~]# cat /proc/cpuinfo | grep proce processor : 0 Make smp_send_stop() account also for the online status of the calling CPU while evaluating how many CPUs are effectively online: this way, the right number of STOPs is sent, so enforcing a proper freeze of the system at the end of panic even under the above conditions. Fixes: 08e875c ("arm64: SMP support") Reported-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Apr 2, 2020
commit d0bab0c upstream. On a system with only one CPU online, when another one CPU panics while starting-up, smp_send_stop() will fail to send any STOP message to the other already online core, resulting in a system still responsive and alive at the end of the panic procedure. [ 186.700083] CPU3: shutdown [ 187.075462] CPU2: shutdown [ 187.162869] CPU1: shutdown [ 188.689998] ------------[ cut here ]------------ [ 188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886! [ 188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 188.692444] Modules linked in: [ 188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104 [ 188.693175] Hardware name: Foundation-v8A (DT) [ 188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO) [ 188.694183] pc : has_cpuid_feature+0xf0/0x348 [ 188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8 [ 188.694410] sp : ffff800011b1bf60 [ 188.694536] x29: ffff800011b1bf60 x28: 0000000000000000 [ 188.694707] x27: 0000000000000000 x26: 0000000000000000 [ 188.694801] x25: 0000000000000000 x24: ffff80001189a25c [ 188.694905] x23: 0000000000000000 x22: 0000000000000000 [ 188.694996] x21: ffff8000114aa018 x20: ffff800011156a38 [ 188.695089] x19: ffff800010c944a0 x18: 0000000000000004 [ 188.695187] x17: 0000000000000000 x16: 0000000000000000 [ 188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa [ 188.695371] x13: 0000000000000002 x12: 0000000000002592 [ 188.695472] x11: 0000000000000080 x10: 00400032b5503510 [ 188.695572] x9 : 0000000000000000 x8 : ffff800010c80204 [ 188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001 [ 188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000 [ 188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8 [ 188.695919] x1 : 0000000000180420 x0 : 0000000000180480 [ 188.696253] Call trace: [ 188.696410] has_cpuid_feature+0xf0/0x348 [ 188.696504] verify_local_elf_hwcaps+0x84/0xe8 [ 188.696591] check_local_cpu_capabilities+0x44/0x128 [ 188.696666] secondary_start_kernel+0xf4/0x188 [ 188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000) [ 188.698639] ---[ end trace 3f12ca47652f7b72 ]--- [ 188.699160] Kernel panic - not syncing: Attempted to kill the idle task! [ 188.699546] Kernel Offset: disabled [ 188.699828] CPU features: 0x00004,20c02008 [ 188.700012] Memory Limit: none [ 188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- [root@arch ~]# echo Helo Helo [root@arch ~]# cat /proc/cpuinfo | grep proce processor : 0 Make smp_send_stop() account also for the online status of the calling CPU while evaluating how many CPUs are effectively online: this way, the right number of STOPs is sent, so enforcing a proper freeze of the system at the end of panic even under the above conditions. Fixes: 08e875c ("arm64: SMP support") Reported-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Apr 2, 2020
commit d0bab0c upstream. On a system with only one CPU online, when another one CPU panics while starting-up, smp_send_stop() will fail to send any STOP message to the other already online core, resulting in a system still responsive and alive at the end of the panic procedure. [ 186.700083] CPU3: shutdown [ 187.075462] CPU2: shutdown [ 187.162869] CPU1: shutdown [ 188.689998] ------------[ cut here ]------------ [ 188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886! [ 188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 188.692444] Modules linked in: [ 188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104 [ 188.693175] Hardware name: Foundation-v8A (DT) [ 188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO) [ 188.694183] pc : has_cpuid_feature+0xf0/0x348 [ 188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8 [ 188.694410] sp : ffff800011b1bf60 [ 188.694536] x29: ffff800011b1bf60 x28: 0000000000000000 [ 188.694707] x27: 0000000000000000 x26: 0000000000000000 [ 188.694801] x25: 0000000000000000 x24: ffff80001189a25c [ 188.694905] x23: 0000000000000000 x22: 0000000000000000 [ 188.694996] x21: ffff8000114aa018 x20: ffff800011156a38 [ 188.695089] x19: ffff800010c944a0 x18: 0000000000000004 [ 188.695187] x17: 0000000000000000 x16: 0000000000000000 [ 188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa [ 188.695371] x13: 0000000000000002 x12: 0000000000002592 [ 188.695472] x11: 0000000000000080 x10: 00400032b5503510 [ 188.695572] x9 : 0000000000000000 x8 : ffff800010c80204 [ 188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001 [ 188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000 [ 188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8 [ 188.695919] x1 : 0000000000180420 x0 : 0000000000180480 [ 188.696253] Call trace: [ 188.696410] has_cpuid_feature+0xf0/0x348 [ 188.696504] verify_local_elf_hwcaps+0x84/0xe8 [ 188.696591] check_local_cpu_capabilities+0x44/0x128 [ 188.696666] secondary_start_kernel+0xf4/0x188 [ 188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000) [ 188.698639] ---[ end trace 3f12ca47652f7b72 ]--- [ 188.699160] Kernel panic - not syncing: Attempted to kill the idle task! [ 188.699546] Kernel Offset: disabled [ 188.699828] CPU features: 0x00004,20c02008 [ 188.700012] Memory Limit: none [ 188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- [root@arch ~]# echo Helo Helo [root@arch ~]# cat /proc/cpuinfo | grep proce processor : 0 Make smp_send_stop() account also for the online status of the calling CPU while evaluating how many CPUs are effectively online: this way, the right number of STOPs is sent, so enforcing a proper freeze of the system at the end of panic even under the above conditions. Fixes: 08e875c ("arm64: SMP support") Reported-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari
pushed a commit
to Noltari/linux
that referenced
this pull request
Apr 2, 2020
commit d0bab0c upstream. On a system with only one CPU online, when another one CPU panics while starting-up, smp_send_stop() will fail to send any STOP message to the other already online core, resulting in a system still responsive and alive at the end of the panic procedure. [ 186.700083] CPU3: shutdown [ 187.075462] CPU2: shutdown [ 187.162869] CPU1: shutdown [ 188.689998] ------------[ cut here ]------------ [ 188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886! [ 188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 188.692444] Modules linked in: [ 188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104 [ 188.693175] Hardware name: Foundation-v8A (DT) [ 188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO) [ 188.694183] pc : has_cpuid_feature+0xf0/0x348 [ 188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8 [ 188.694410] sp : ffff800011b1bf60 [ 188.694536] x29: ffff800011b1bf60 x28: 0000000000000000 [ 188.694707] x27: 0000000000000000 x26: 0000000000000000 [ 188.694801] x25: 0000000000000000 x24: ffff80001189a25c [ 188.694905] x23: 0000000000000000 x22: 0000000000000000 [ 188.694996] x21: ffff8000114aa018 x20: ffff800011156a38 [ 188.695089] x19: ffff800010c944a0 x18: 0000000000000004 [ 188.695187] x17: 0000000000000000 x16: 0000000000000000 [ 188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa [ 188.695371] x13: 0000000000000002 x12: 0000000000002592 [ 188.695472] x11: 0000000000000080 x10: 00400032b5503510 [ 188.695572] x9 : 0000000000000000 x8 : ffff800010c80204 [ 188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001 [ 188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000 [ 188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8 [ 188.695919] x1 : 0000000000180420 x0 : 0000000000180480 [ 188.696253] Call trace: [ 188.696410] has_cpuid_feature+0xf0/0x348 [ 188.696504] verify_local_elf_hwcaps+0x84/0xe8 [ 188.696591] check_local_cpu_capabilities+0x44/0x128 [ 188.696666] secondary_start_kernel+0xf4/0x188 [ 188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000) [ 188.698639] ---[ end trace 3f12ca47652f7b72 ]--- [ 188.699160] Kernel panic - not syncing: Attempted to kill the idle task! [ 188.699546] Kernel Offset: disabled [ 188.699828] CPU features: 0x00004,20c02008 [ 188.700012] Memory Limit: none [ 188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- [root@arch ~]# echo Helo Helo [root@arch ~]# cat /proc/cpuinfo | grep proce processor : 0 Make smp_send_stop() account also for the online status of the calling CPU while evaluating how many CPUs are effectively online: this way, the right number of STOPs is sent, so enforcing a proper freeze of the system at the end of panic even under the above conditions. Fixes: 08e875c ("arm64: SMP support") Reported-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jackpot51
referenced
this pull request
in pop-os/linux
Apr 13, 2020
BugLink: https://bugs.launchpad.net/bugs/1869061 commit d0bab0c upstream. On a system with only one CPU online, when another one CPU panics while starting-up, smp_send_stop() will fail to send any STOP message to the other already online core, resulting in a system still responsive and alive at the end of the panic procedure. [ 186.700083] CPU3: shutdown [ 187.075462] CPU2: shutdown [ 187.162869] CPU1: shutdown [ 188.689998] ------------[ cut here ]------------ [ 188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886! [ 188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 188.692444] Modules linked in: [ 188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 #104 [ 188.693175] Hardware name: Foundation-v8A (DT) [ 188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO) [ 188.694183] pc : has_cpuid_feature+0xf0/0x348 [ 188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8 [ 188.694410] sp : ffff800011b1bf60 [ 188.694536] x29: ffff800011b1bf60 x28: 0000000000000000 [ 188.694707] x27: 0000000000000000 x26: 0000000000000000 [ 188.694801] x25: 0000000000000000 x24: ffff80001189a25c [ 188.694905] x23: 0000000000000000 x22: 0000000000000000 [ 188.694996] x21: ffff8000114aa018 x20: ffff800011156a38 [ 188.695089] x19: ffff800010c944a0 x18: 0000000000000004 [ 188.695187] x17: 0000000000000000 x16: 0000000000000000 [ 188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa [ 188.695371] x13: 0000000000000002 x12: 0000000000002592 [ 188.695472] x11: 0000000000000080 x10: 00400032b5503510 [ 188.695572] x9 : 0000000000000000 x8 : ffff800010c80204 [ 188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001 [ 188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000 [ 188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8 [ 188.695919] x1 : 0000000000180420 x0 : 0000000000180480 [ 188.696253] Call trace: [ 188.696410] has_cpuid_feature+0xf0/0x348 [ 188.696504] verify_local_elf_hwcaps+0x84/0xe8 [ 188.696591] check_local_cpu_capabilities+0x44/0x128 [ 188.696666] secondary_start_kernel+0xf4/0x188 [ 188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000) [ 188.698639] ---[ end trace 3f12ca47652f7b72 ]--- [ 188.699160] Kernel panic - not syncing: Attempted to kill the idle task! [ 188.699546] Kernel Offset: disabled [ 188.699828] CPU features: 0x00004,20c02008 [ 188.700012] Memory Limit: none [ 188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- [root@arch ~]# echo Helo Helo [root@arch ~]# cat /proc/cpuinfo | grep proce processor : 0 Make smp_send_stop() account also for the online status of the calling CPU while evaluating how many CPUs are effectively online: this way, the right number of STOPs is sent, so enforcing a proper freeze of the system at the end of panic even under the above conditions. Fixes: 08e875c ("arm64: SMP support") Reported-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com>
lag-linaro
pushed a commit
to lag-linaro/linux
that referenced
this pull request
Apr 16, 2020
commit d0bab0c upstream. On a system with only one CPU online, when another one CPU panics while starting-up, smp_send_stop() will fail to send any STOP message to the other already online core, resulting in a system still responsive and alive at the end of the panic procedure. [ 186.700083] CPU3: shutdown [ 187.075462] CPU2: shutdown [ 187.162869] CPU1: shutdown [ 188.689998] ------------[ cut here ]------------ [ 188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886! [ 188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP [ 188.692444] Modules linked in: [ 188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104 [ 188.693175] Hardware name: Foundation-v8A (DT) [ 188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO) [ 188.694183] pc : has_cpuid_feature+0xf0/0x348 [ 188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8 [ 188.694410] sp : ffff800011b1bf60 [ 188.694536] x29: ffff800011b1bf60 x28: 0000000000000000 [ 188.694707] x27: 0000000000000000 x26: 0000000000000000 [ 188.694801] x25: 0000000000000000 x24: ffff80001189a25c [ 188.694905] x23: 0000000000000000 x22: 0000000000000000 [ 188.694996] x21: ffff8000114aa018 x20: ffff800011156a38 [ 188.695089] x19: ffff800010c944a0 x18: 0000000000000004 [ 188.695187] x17: 0000000000000000 x16: 0000000000000000 [ 188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa [ 188.695371] x13: 0000000000000002 x12: 0000000000002592 [ 188.695472] x11: 0000000000000080 x10: 00400032b5503510 [ 188.695572] x9 : 0000000000000000 x8 : ffff800010c80204 [ 188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001 [ 188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000 [ 188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8 [ 188.695919] x1 : 0000000000180420 x0 : 0000000000180480 [ 188.696253] Call trace: [ 188.696410] has_cpuid_feature+0xf0/0x348 [ 188.696504] verify_local_elf_hwcaps+0x84/0xe8 [ 188.696591] check_local_cpu_capabilities+0x44/0x128 [ 188.696666] secondary_start_kernel+0xf4/0x188 [ 188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000) [ 188.698639] ---[ end trace 3f12ca47652f7b72 ]--- [ 188.699160] Kernel panic - not syncing: Attempted to kill the idle task! [ 188.699546] Kernel Offset: disabled [ 188.699828] CPU features: 0x00004,20c02008 [ 188.700012] Memory Limit: none [ 188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- [root@arch ~]# echo Helo Helo [root@arch ~]# cat /proc/cpuinfo | grep proce processor : 0 Make smp_send_stop() account also for the online status of the calling CPU while evaluating how many CPUs are effectively online: this way, the right number of STOPs is sent, so enforcing a proper freeze of the system at the end of panic even under the above conditions. Fixes: 08e875c ("arm64: SMP support") Reported-by: Dave Martin <Dave.Martin@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Change-Id: I0c793f1f6bd21b038a15ef577345432dc4d7e3ca
torvalds
pushed a commit
that referenced
this pull request
Jun 11, 2020
While testing io_uring in arm, we found sometimes io_sq_thread() keeps polling io requests even though there are not inflight io requests in block layer. After some investigations, found a possible race about io_kiocb.flags, see below race codes: 1) in the end of io_write() or io_read() req->flags &= ~REQ_F_NEED_CLEANUP; kfree(iovec); return ret; 2) in io_complete_rw_iopoll() if (res != -EAGAIN) req->flags |= REQ_F_IOPOLL_COMPLETED; In IOPOLL mode, io requests still maybe completed by interrupt, then above codes are not safe, concurrent modifications to req->flags, which is not protected by lock or is not atomic modifications. I also had disassemble io_complete_rw_iopoll() in arm: req->flags |= REQ_F_IOPOLL_COMPLETED; 0xffff000008387b18 <+76>: ldr w0, [x19,#104] 0xffff000008387b1c <+80>: orr w0, w0, #0x1000 0xffff000008387b20 <+84>: str w0, [x19,#104] Seems that the "req->flags |= REQ_F_IOPOLL_COMPLETED;" is load and modification, two instructions, which obviously is not atomic. To fix this issue, add a new iopoll_completed in io_kiocb to indicate whether io request is completed. Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
snajpa
pushed a commit
to vpsfreecz/linux
that referenced
this pull request
Jun 24, 2020
[ Upstream commit 65a6543 ] While testing io_uring in arm, we found sometimes io_sq_thread() keeps polling io requests even though there are not inflight io requests in block layer. After some investigations, found a possible race about io_kiocb.flags, see below race codes: 1) in the end of io_write() or io_read() req->flags &= ~REQ_F_NEED_CLEANUP; kfree(iovec); return ret; 2) in io_complete_rw_iopoll() if (res != -EAGAIN) req->flags |= REQ_F_IOPOLL_COMPLETED; In IOPOLL mode, io requests still maybe completed by interrupt, then above codes are not safe, concurrent modifications to req->flags, which is not protected by lock or is not atomic modifications. I also had disassemble io_complete_rw_iopoll() in arm: req->flags |= REQ_F_IOPOLL_COMPLETED; 0xffff000008387b18 <+76>: ldr w0, [x19,torvalds#104] 0xffff000008387b1c <+80>: orr w0, w0, #0x1000 0xffff000008387b20 <+84>: str w0, [x19,torvalds#104] Seems that the "req->flags |= REQ_F_IOPOLL_COMPLETED;" is load and modification, two instructions, which obviously is not atomic. To fix this issue, add a new iopoll_completed in io_kiocb to indicate whether io request is completed. Signed-off-by: Xiaoguang Wang <xiaoguang.wang@linux.alibaba.com> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 9, 2021
This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#19: FILE: hal/HalBtc8723b2Ant.h:19: +typedef enum _BT_INFO_SRC_8723B_2ANT { WARNING: do not add new typedefs torvalds#26: FILE: hal/HalBtc8723b2Ant.h:26: +typedef enum _BT_8723B_2ANT_BT_STATUS { WARNING: do not add new typedefs torvalds#36: FILE: hal/HalBtc8723b2Ant.h:36: +typedef enum _BT_8723B_2ANT_COEX_ALGO { WARNING: do not add new typedefs torvalds#51: FILE: hal/HalBtc8723b2Ant.h:51: +typedef struct _COEX_DM_8723B_2ANT { WARNING: do not add new typedefs torvalds#104: FILE: hal/HalBtc8723b2Ant.h:104: +typedef struct _COEX_STA_8723B_2ANT { Signed-off-by: Marco Cesati <marco.cesati@gmail.com> Link: https://lore.kernel.org/r/20210305101151.13137-1-marco.cesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 10, 2021
This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#19: FILE: hal/HalBtc8723b2Ant.h:19: +typedef enum _BT_INFO_SRC_8723B_2ANT { WARNING: do not add new typedefs torvalds#26: FILE: hal/HalBtc8723b2Ant.h:26: +typedef enum _BT_8723B_2ANT_BT_STATUS { WARNING: do not add new typedefs torvalds#36: FILE: hal/HalBtc8723b2Ant.h:36: +typedef enum _BT_8723B_2ANT_COEX_ALGO { WARNING: do not add new typedefs torvalds#51: FILE: hal/HalBtc8723b2Ant.h:51: +typedef struct _COEX_DM_8723B_2ANT { WARNING: do not add new typedefs torvalds#104: FILE: hal/HalBtc8723b2Ant.h:104: +typedef struct _COEX_STA_8723B_2ANT { Signed-off-by: Marco Cesati <marco.cesati@gmail.com> Link: https://lore.kernel.org/r/20210305101151.13137-1-marco.cesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 15, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #70: FILE: ./hal/hal_btcoex.c:70: +static u8 halbtcoutsrc_IsBtCoexistAvailable(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#104: FILE: ./hal/hal_btcoex.c:104: +static void halbtcoutsrc_LeaveLps(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#117: FILE: ./hal/hal_btcoex.c:117: +static void halbtcoutsrc_EnterLps(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#130: FILE: ./hal/hal_btcoex.c:130: +static void halbtcoutsrc_NormalLps(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#152: FILE: ./hal/hal_btcoex.c:152: +static void halbtcoutsrc_LeaveLowPower(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#187: FILE: ./hal/hal_btcoex.c:187: +static void halbtcoutsrc_NormalLowPower(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#196: FILE: ./hal/hal_btcoex.c:196: +static void halbtcoutsrc_DisableLowPower(struct BTC_COEXIST * pBtCoexist, u8 bLowPwrDisable) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#205: FILE: ./hal/hal_btcoex.c:205: +static void halbtcoutsrc_AggregationCheck(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#283: FILE: ./hal/hal_btcoex.c:283: +static u32 halbtcoutsrc_GetWifiLinkStatus(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#311: FILE: ./hal/hal_btcoex.c:311: +static u32 halbtcoutsrc_GetBtPatchVer(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#342: FILE: ./hal/hal_btcoex.c:342: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#448: FILE: ./hal/hal_btcoex.c:448: + struct RT_LINK_DETECT_T * plinkinfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#510: FILE: ./hal/hal_btcoex.c:510: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#645: FILE: ./hal/hal_btcoex.c:645: +static void halbtcoutsrc_DisplayFwPwrModeCmd(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#661: FILE: ./hal/hal_btcoex.c:661: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#673: FILE: ./hal/hal_btcoex.c:673: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#685: FILE: ./hal/hal_btcoex.c:685: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#697: FILE: ./hal/hal_btcoex.c:697: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#709: FILE: ./hal/hal_btcoex.c:709: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#749: FILE: ./hal/hal_btcoex.c:749: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#761: FILE: ./hal/hal_btcoex.c:761: + struct BTC_COEXIST * pBtCoexist = (struct BTC_COEXIST *)pBtcContext; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#772: FILE: ./hal/hal_btcoex.c:772: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #785: FILE: ./hal/hal_btcoex.c:785: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#797: FILE: ./hal/hal_btcoex.c:797: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#809: FILE: ./hal/hal_btcoex.c:809: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#821: FILE: ./hal/hal_btcoex.c:821: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#857: FILE: ./hal/hal_btcoex.c:857: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#869: FILE: ./hal/hal_btcoex.c:869: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#891: FILE: ./hal/hal_btcoex.c:891: + struct BTC_COEXIST * pBtCoexist = &GLBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#917: FILE: ./hal/hal_btcoex.c:917: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#963: FILE: ./hal/hal_btcoex.c:963: +void EXhalbtcoutsrc_PowerOnSetting(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#975: FILE: ./hal/hal_btcoex.c:975: +void EXhalbtcoutsrc_InitHwConfig(struct BTC_COEXIST * pBtCoexist, u8 bWifiOnly) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#988: FILE: ./hal/hal_btcoex.c:988: +void EXhalbtcoutsrc_InitCoexDm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1003: FILE: ./hal/hal_btcoex.c:1003: +void EXhalbtcoutsrc_IpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1030: FILE: ./hal/hal_btcoex.c:1030: +void EXhalbtcoutsrc_LpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1053: FILE: ./hal/hal_btcoex.c:1053: +void EXhalbtcoutsrc_ScanNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1082: FILE: ./hal/hal_btcoex.c:1082: +void EXhalbtcoutsrc_ConnectNotify(struct BTC_COEXIST * pBtCoexist, u8 action) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1108: FILE: ./hal/hal_btcoex.c:1108: +void EXhalbtcoutsrc_MediaStatusNotify(struct BTC_COEXIST * pBtCoexist, enum RT_MEDIA_STATUS mediaStatus) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1135: FILE: ./hal/hal_btcoex.c:1135: +void EXhalbtcoutsrc_SpecialPacketNotify(struct BTC_COEXIST * pBtCoexist, u8 pktType) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1166: FILE: ./hal/hal_btcoex.c:1166: +void EXhalbtcoutsrc_BtInfoNotify(struct BTC_COEXIST * pBtCoexist, u8 *tmpBuf, u8 length) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1184: FILE: ./hal/hal_btcoex.c:1184: +void EXhalbtcoutsrc_HaltNotify(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1197: FILE: ./hal/hal_btcoex.c:1197: +void EXhalbtcoutsrc_PnpNotify(struct BTC_COEXIST * pBtCoexist, u8 pnpState) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1213: FILE: ./hal/hal_btcoex.c:1213: +void EXhalbtcoutsrc_Periodical(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1258: FILE: ./hal/hal_btcoex.c:1258: +void EXhalbtcoutsrc_DisplayBtCoexInfo(struct BTC_COEXIST * pBtCoexist) Signed-off-by: Marco Cesati <marcocesati@gmail.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Mar 16, 2021
This commit fixes the following checkpatch.pl errors: ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #70: FILE: ./hal/hal_btcoex.c:70: +static u8 halbtcoutsrc_IsBtCoexistAvailable(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#104: FILE: ./hal/hal_btcoex.c:104: +static void halbtcoutsrc_LeaveLps(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#117: FILE: ./hal/hal_btcoex.c:117: +static void halbtcoutsrc_EnterLps(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#130: FILE: ./hal/hal_btcoex.c:130: +static void halbtcoutsrc_NormalLps(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#152: FILE: ./hal/hal_btcoex.c:152: +static void halbtcoutsrc_LeaveLowPower(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#187: FILE: ./hal/hal_btcoex.c:187: +static void halbtcoutsrc_NormalLowPower(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#196: FILE: ./hal/hal_btcoex.c:196: +static void halbtcoutsrc_DisableLowPower(struct BTC_COEXIST * pBtCoexist, u8 bLowPwrDisable) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#205: FILE: ./hal/hal_btcoex.c:205: +static void halbtcoutsrc_AggregationCheck(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#283: FILE: ./hal/hal_btcoex.c:283: +static u32 halbtcoutsrc_GetWifiLinkStatus(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#311: FILE: ./hal/hal_btcoex.c:311: +static u32 halbtcoutsrc_GetBtPatchVer(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#342: FILE: ./hal/hal_btcoex.c:342: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#448: FILE: ./hal/hal_btcoex.c:448: + struct RT_LINK_DETECT_T * plinkinfo; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#510: FILE: ./hal/hal_btcoex.c:510: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#645: FILE: ./hal/hal_btcoex.c:645: +static void halbtcoutsrc_DisplayFwPwrModeCmd(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#661: FILE: ./hal/hal_btcoex.c:661: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#673: FILE: ./hal/hal_btcoex.c:673: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#685: FILE: ./hal/hal_btcoex.c:685: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#697: FILE: ./hal/hal_btcoex.c:697: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#709: FILE: ./hal/hal_btcoex.c:709: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#749: FILE: ./hal/hal_btcoex.c:749: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#761: FILE: ./hal/hal_btcoex.c:761: + struct BTC_COEXIST * pBtCoexist = (struct BTC_COEXIST *)pBtcContext; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#772: FILE: ./hal/hal_btcoex.c:772: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #785: FILE: ./hal/hal_btcoex.c:785: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#797: FILE: ./hal/hal_btcoex.c:797: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#809: FILE: ./hal/hal_btcoex.c:809: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#821: FILE: ./hal/hal_btcoex.c:821: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#857: FILE: ./hal/hal_btcoex.c:857: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#869: FILE: ./hal/hal_btcoex.c:869: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#891: FILE: ./hal/hal_btcoex.c:891: + struct BTC_COEXIST * pBtCoexist = &GLBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#917: FILE: ./hal/hal_btcoex.c:917: + struct BTC_COEXIST * pBtCoexist; ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#963: FILE: ./hal/hal_btcoex.c:963: +void EXhalbtcoutsrc_PowerOnSetting(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#975: FILE: ./hal/hal_btcoex.c:975: +void EXhalbtcoutsrc_InitHwConfig(struct BTC_COEXIST * pBtCoexist, u8 bWifiOnly) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#988: FILE: ./hal/hal_btcoex.c:988: +void EXhalbtcoutsrc_InitCoexDm(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1003: FILE: ./hal/hal_btcoex.c:1003: +void EXhalbtcoutsrc_IpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1030: FILE: ./hal/hal_btcoex.c:1030: +void EXhalbtcoutsrc_LpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1053: FILE: ./hal/hal_btcoex.c:1053: +void EXhalbtcoutsrc_ScanNotify(struct BTC_COEXIST * pBtCoexist, u8 type) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" torvalds#1082: FILE: ./hal/hal_btcoex.c:1082: +void EXhalbtcoutsrc_ConnectNotify(struct BTC_COEXIST * pBtCoexist, u8 action) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1108: FILE: ./hal/hal_btcoex.c:1108: +void EXhalbtcoutsrc_MediaStatusNotify(struct BTC_COEXIST * pBtCoexist, enum RT_MEDIA_STATUS mediaStatus) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1135: FILE: ./hal/hal_btcoex.c:1135: +void EXhalbtcoutsrc_SpecialPacketNotify(struct BTC_COEXIST * pBtCoexist, u8 pktType) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1166: FILE: ./hal/hal_btcoex.c:1166: +void EXhalbtcoutsrc_BtInfoNotify(struct BTC_COEXIST * pBtCoexist, u8 *tmpBuf, u8 length) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1184: FILE: ./hal/hal_btcoex.c:1184: +void EXhalbtcoutsrc_HaltNotify(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1197: FILE: ./hal/hal_btcoex.c:1197: +void EXhalbtcoutsrc_PnpNotify(struct BTC_COEXIST * pBtCoexist, u8 pnpState) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1213: FILE: ./hal/hal_btcoex.c:1213: +void EXhalbtcoutsrc_Periodical(struct BTC_COEXIST * pBtCoexist) ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar" #1258: FILE: ./hal/hal_btcoex.c:1258: +void EXhalbtcoutsrc_DisplayBtCoexInfo(struct BTC_COEXIST * pBtCoexist) Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Marco Cesati <marcocesati@gmail.com> Link: https://lore.kernel.org/r/20210315170618.2566-18-marcocesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ojeda
pushed a commit
to ojeda/linux
that referenced
this pull request
Mar 17, 2021
Add a condition variable implementation to the `sync` module.
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 21, 2021
Performing the following: ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\ > events/sched/sched_switch/trigger ># echo 1 > events/synthetic/enable Crashed the kernel: BUG: kernel NULL pointer dereference, address: 000000000000001b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 9 f8 c3 31 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018 FS: 0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0 Call Trace: trace_event_raw_event_synth+0x90/0x1d0 action_trace+0x5b/0x70 event_hist_trigger+0x4bd/0x4e0 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.0+0xf6/0x840 ? __lock_acquire.constprop.0+0x125/0x550 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? update_load_avg+0x8c/0x6f0 ? enqueue_entity+0x18a/0x920 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x1ae/0x240 trace_event_raw_event_sched_switch+0x114/0x170 __traceiter_sched_switch+0x39/0x50 __schedule+0x431/0xb00 schedule_idle+0x28/0x40 do_idle+0x198/0x2e0 cpu_startup_entry+0x19/0x20 secondary_startup_64_no_verify+0xc2/0xcb The reason is that the dynamic events array keeps track of the field position of the fields array, via the field_pos variable in the synth_field structure. Unfortunately, that field is a boolean for some reason, which means any field_pos greater than 1 will be a bug (in this case it was 2). Cc: stable@vger.kernel.org Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events") Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Jul 23, 2021
Performing the following: ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\ > events/sched/sched_switch/trigger ># echo 1 > events/synthetic/enable Crashed the kernel: BUG: kernel NULL pointer dereference, address: 000000000000001b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 9 f8 c3 31 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018 FS: 0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0 Call Trace: trace_event_raw_event_synth+0x90/0x1d0 action_trace+0x5b/0x70 event_hist_trigger+0x4bd/0x4e0 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.0+0xf6/0x840 ? __lock_acquire.constprop.0+0x125/0x550 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? update_load_avg+0x8c/0x6f0 ? enqueue_entity+0x18a/0x920 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x1ae/0x240 trace_event_raw_event_sched_switch+0x114/0x170 __traceiter_sched_switch+0x39/0x50 __schedule+0x431/0xb00 schedule_idle+0x28/0x40 do_idle+0x198/0x2e0 cpu_startup_entry+0x19/0x20 secondary_startup_64_no_verify+0xc2/0xcb The reason is that the dynamic events array keeps track of the field position of the fields array, via the field_pos variable in the synth_field structure. Unfortunately, that field is a boolean for some reason, which means any field_pos greater than 1 will be a bug (in this case it was 2). Link: https://lkml.kernel.org/r/20210721191008.638bce34@oasis.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: stable@vger.kernel.org Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events") Reviewed-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
torvalds
pushed a commit
that referenced
this pull request
Jul 23, 2021
Performing the following: ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\ > events/sched/sched_switch/trigger ># echo 1 > events/synthetic/enable Crashed the kernel: BUG: kernel NULL pointer dereference, address: 000000000000001b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ #104 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 9 f8 c3 31 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018 FS: 0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0 Call Trace: trace_event_raw_event_synth+0x90/0x1d0 action_trace+0x5b/0x70 event_hist_trigger+0x4bd/0x4e0 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.0+0xf6/0x840 ? __lock_acquire.constprop.0+0x125/0x550 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? update_load_avg+0x8c/0x6f0 ? enqueue_entity+0x18a/0x920 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x1ae/0x240 trace_event_raw_event_sched_switch+0x114/0x170 __traceiter_sched_switch+0x39/0x50 __schedule+0x431/0xb00 schedule_idle+0x28/0x40 do_idle+0x198/0x2e0 cpu_startup_entry+0x19/0x20 secondary_startup_64_no_verify+0xc2/0xcb The reason is that the dynamic events array keeps track of the field position of the fields array, via the field_pos variable in the synth_field structure. Unfortunately, that field is a boolean for some reason, which means any field_pos greater than 1 will be a bug (in this case it was 2). Link: https://lkml.kernel.org/r/20210721191008.638bce34@oasis.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: stable@vger.kernel.org Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events") Reviewed-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
intersectRaven
pushed a commit
to intersectRaven/linux
that referenced
this pull request
Jul 28, 2021
commit 3b13911 upstream. Performing the following: ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\ > events/sched/sched_switch/trigger ># echo 1 > events/synthetic/enable Crashed the kernel: BUG: kernel NULL pointer dereference, address: 000000000000001b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 9 f8 c3 31 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018 FS: 0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0 Call Trace: trace_event_raw_event_synth+0x90/0x1d0 action_trace+0x5b/0x70 event_hist_trigger+0x4bd/0x4e0 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.0+0xf6/0x840 ? __lock_acquire.constprop.0+0x125/0x550 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? update_load_avg+0x8c/0x6f0 ? enqueue_entity+0x18a/0x920 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x1ae/0x240 trace_event_raw_event_sched_switch+0x114/0x170 __traceiter_sched_switch+0x39/0x50 __schedule+0x431/0xb00 schedule_idle+0x28/0x40 do_idle+0x198/0x2e0 cpu_startup_entry+0x19/0x20 secondary_startup_64_no_verify+0xc2/0xcb The reason is that the dynamic events array keeps track of the field position of the fields array, via the field_pos variable in the synth_field structure. Unfortunately, that field is a boolean for some reason, which means any field_pos greater than 1 will be a bug (in this case it was 2). Link: https://lkml.kernel.org/r/20210721191008.638bce34@oasis.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: stable@vger.kernel.org Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events") Reviewed-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
snajpa
pushed a commit
to vpsfreecz/linux
that referenced
this pull request
Jul 30, 2021
commit 3b13911 upstream. Performing the following: ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\ > events/sched/sched_switch/trigger ># echo 1 > events/synthetic/enable Crashed the kernel: BUG: kernel NULL pointer dereference, address: 000000000000001b #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016 RIP: 0010:strlen+0x0/0x20 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc 20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 9 f8 c3 31 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018 FS: 0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0 Call Trace: trace_event_raw_event_synth+0x90/0x1d0 action_trace+0x5b/0x70 event_hist_trigger+0x4bd/0x4e0 ? cpumask_next_and+0x20/0x30 ? update_sd_lb_stats.constprop.0+0xf6/0x840 ? __lock_acquire.constprop.0+0x125/0x550 ? find_held_lock+0x32/0x90 ? sched_clock_cpu+0xe/0xd0 ? lock_release+0x155/0x440 ? update_load_avg+0x8c/0x6f0 ? enqueue_entity+0x18a/0x920 ? __rb_reserve_next+0xe5/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 event_triggers_call+0x52/0xe0 trace_event_buffer_commit+0x1ae/0x240 trace_event_raw_event_sched_switch+0x114/0x170 __traceiter_sched_switch+0x39/0x50 __schedule+0x431/0xb00 schedule_idle+0x28/0x40 do_idle+0x198/0x2e0 cpu_startup_entry+0x19/0x20 secondary_startup_64_no_verify+0xc2/0xcb The reason is that the dynamic events array keeps track of the field position of the fields array, via the field_pos variable in the synth_field structure. Unfortunately, that field is a boolean for some reason, which means any field_pos greater than 1 will be a bug (in this case it was 2). Link: https://lkml.kernel.org/r/20210721191008.638bce34@oasis.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: stable@vger.kernel.org Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events") Reviewed-by: Tom Zanussi <zanussi@kernel.org> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 21, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak") breaks boot on EFI systems with kmemleak and VM_DEBUG enabled: efi: Processing EFI memory map: efi: 0x000090000000-0x000091ffffff [Conventional| | | | | | | | | | |WB|WT|WC|UC] efi: 0x000092000000-0x0000928fffff [Runtime Data|RUN| | | | | | | | | |WB|WT|WC|UC] ------------[ cut here ]------------ kernel BUG at mm/kmemleak.c:1140! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ torvalds#104 pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kmemleak_free_part_phys+0x64/0x8c lr : kmemleak_free_part_phys+0x38/0x8c sp : ffff800011eafbc0 x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068 x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0 x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000 x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7 x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000 x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0 x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99 x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff Call trace: kmemleak_free_part_phys+0x64/0x8c memblock_mark_nomap+0x5c/0x78 reserve_regions+0x294/0x33c efi_init+0x2d0/0x490 setup_arch+0x80/0x138 start_kernel+0xa0/0x3ec __primary_switched+0xc0/0xc8 Code: 34000041 97d526e7 f9418e80 36000040 (d4210000) random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0 ---[ end trace 0000000000000000 ]--- The crash happens because kmemleak_free_part_phys() tries to use __va() before memstart_addr is initialized and this triggers a VM_BUG_ON() in arch/arm64/include/asm/memory.h: Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"), the issue it is fixing will be fixed differently. Reported-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
torvalds
pushed a commit
that referenced
this pull request
Oct 22, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak") breaks boot on EFI systems with kmemleak and VM_DEBUG enabled: efi: Processing EFI memory map: efi: 0x000090000000-0x000091ffffff [Conventional| | | | | | | | | | |WB|WT|WC|UC] efi: 0x000092000000-0x0000928fffff [Runtime Data|RUN| | | | | | | | | |WB|WT|WC|UC] ------------[ cut here ]------------ kernel BUG at mm/kmemleak.c:1140! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ #104 pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kmemleak_free_part_phys+0x64/0x8c lr : kmemleak_free_part_phys+0x38/0x8c sp : ffff800011eafbc0 x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068 x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0 x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000 x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7 x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000 x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0 x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99 x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff Call trace: kmemleak_free_part_phys+0x64/0x8c memblock_mark_nomap+0x5c/0x78 reserve_regions+0x294/0x33c efi_init+0x2d0/0x490 setup_arch+0x80/0x138 start_kernel+0xa0/0x3ec __primary_switched+0xc0/0xc8 Code: 34000041 97d526e7 f9418e80 36000040 (d4210000) random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0 ---[ end trace 0000000000000000 ]--- The crash happens because kmemleak_free_part_phys() tries to use __va() before memstart_addr is initialized and this triggers a VM_BUG_ON() in arch/arm64/include/asm/memory.h: Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"), the issue it is fixing will be fixed differently. Reported-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
staging-kernelci-org
pushed a commit
to kernelci/linux
that referenced
this pull request
Oct 23, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak") breaks boot on EFI systems with kmemleak and VM_DEBUG enabled: efi: Processing EFI memory map: efi: 0x000090000000-0x000091ffffff [Conventional| | | | | | | | | | |WB|WT|WC|UC] efi: 0x000092000000-0x0000928fffff [Runtime Data|RUN| | | | | | | | | |WB|WT|WC|UC] ------------[ cut here ]------------ kernel BUG at mm/kmemleak.c:1140! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ torvalds#104 pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kmemleak_free_part_phys+0x64/0x8c lr : kmemleak_free_part_phys+0x38/0x8c sp : ffff800011eafbc0 x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068 x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0 x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000 x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7 x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000 x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0 x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99 x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff Call trace: kmemleak_free_part_phys+0x64/0x8c memblock_mark_nomap+0x5c/0x78 reserve_regions+0x294/0x33c efi_init+0x2d0/0x490 setup_arch+0x80/0x138 start_kernel+0xa0/0x3ec __primary_switched+0xc0/0xc8 Code: 34000041 97d526e7 f9418e80 36000040 (d4210000) random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0 ---[ end trace 0000000000000000 ]--- The crash happens because kmemleak_free_part_phys() tries to use __va() before memstart_addr is initialized and this triggers a VM_BUG_ON() in arch/arm64/include/asm/memory.h: Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"), the issue it is fixing will be fixed differently. Reported-by: Qian Cai <quic_qiancai@quicinc.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com>
fengguang
pushed a commit
to 0day-ci/linux
that referenced
this pull request
Oct 25, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak") breaks boot on EFI systems with kmemleak and VM_DEBUG enabled: efi: Processing EFI memory map: efi: 0x000090000000-0x000091ffffff [Conventional| | | | | | | | | | |WB|WT|WC|UC] efi: 0x000092000000-0x0000928fffff [Runtime Data|RUN| | | | | | | | | |WB|WT|WC|UC] ------------[ cut here ]------------ kernel BUG at mm/kmemleak.c:1140! Internal error: Oops - BUG: 0 [#1] SMP Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ torvalds#104 pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kmemleak_free_part_phys+0x64/0x8c lr : kmemleak_free_part_phys+0x38/0x8c sp : ffff800011eafbc0 x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068 x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0 x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000 x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730 x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7 x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000 x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0 x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99 x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff Call trace: kmemleak_free_part_phys+0x64/0x8c memblock_mark_nomap+0x5c/0x78 reserve_regions+0x294/0x33c efi_init+0x2d0/0x490 setup_arch+0x80/0x138 start_kernel+0xa0/0x3ec __primary_switched+0xc0/0xc8 Code: 34000041 97d526e7 f9418e80 36000040 (d4210000) random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0 ---[ end trace 0000000000000000 ]--- The crash happens because kmemleak_free_part_phys() tries to use __va() before memstart_addr is initialized and this triggers a VM_BUG_ON() in arch/arm64/include/asm/memory.h: Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"), the issue it is fixing will be fixed differently. Reported-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Mike Rapoport <rppt@linux.ibm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Reviewed-by: David Hildenbrand <david@redhat.com>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Nov 20, 2021
statfs calculates Total/Used/Avail disk space in block unit, so we should translate soft/hard prjquota limit to block unit as well. Below testing result shows the block/inode numbers of Total/Used/Avail from df command are all correct afer applying this patch. [root@localhost quota-tools]\# ./repquota -P /dev/sdb1 *** Report for project quotas on device /dev/sdb1 Block grace time: 7days; Inode grace time: 7days Block limits File limits Project used soft hard grace used soft hard grace ----------------------------------------------------------- \#0 -- 4 0 0 1 0 0 \torvalds#101 -- 0 0 0 2 0 0 \torvalds#102 -- 0 10240 0 2 10 0 \torvalds#103 -- 0 0 20480 2 0 20 \torvalds#104 -- 0 10240 20480 2 10 20 \torvalds#105 -- 0 20480 10240 2 20 10 [root@localhost sdb1]\# lsattr -p t{1,2,3,4,5} 101 ----------------N-- t1/a1 102 ----------------N-- t2/a2 103 ----------------N-- t3/a3 104 ----------------N-- t4/a4 105 ----------------N-- t5/a5 [root@localhost sdb1]\# df -hi t{1,2,3,4,5} Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 2.4M 21 2.4M 1% /mnt/sdb1 /dev/sdb1 10 2 8 20% /mnt/sdb1 /dev/sdb1 20 2 18 10% /mnt/sdb1 /dev/sdb1 10 2 8 20% /mnt/sdb1 /dev/sdb1 10 2 8 20% /mnt/sdb1 [root@localhost sdb1]\# df -h t{1,2,3,4,5} Filesystem Size Used Avail Use% Mounted on /dev/sdb1 10G 489M 9.6G 5% /mnt/sdb1 /dev/sdb1 10M 0 10M 0% /mnt/sdb1 /dev/sdb1 20M 0 20M 0% /mnt/sdb1 /dev/sdb1 10M 0 10M 0% /mnt/sdb1 /dev/sdb1 10M 0 10M 0% /mnt/sdb1 Fixes: 909110c ("f2fs: choose hardlimit when softlimit is larger than hardlimit in f2fs_statfs_project()") Signed-off-by: Chengguang Xu <cgxu519@mykernel.net> Reviewed-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Mar 25, 2022
The BPF STX/LDX instruction uses offset relative to the FP to address stack space. Since the BPF_FP locates at the top of the frame, the offset is usually a negative number. However, arm64 str/ldr immediate instruction requires that offset be a positive number. Therefore, this patch tries to convert the offsets. The method is to find the negative offset furthest from the FP firstly. Then add it to the FP, calculate a bottom position, called FPB, and then adjust the offsets in other STR/LDX instructions relative to FPB. FPB is saved using the callee-saved register x27 of arm64 which is not used yet. Before adjusting the offset, the patch checks every instruction to ensure that the FP does not change in run-time. If the FP may change, no offset is adjusted. For example, for the following bpftrace command: bpftrace -e 'kprobe:do_sys_open { printf("opening: %s\n", str(arg1)); }' Without this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: mov x25, sp 1c: mov x26, #0x0 // #0 20: bti j 24: sub sp, sp, #0x90 28: add x19, x0, #0x0 2c: mov x0, #0x0 // #0 30: mov x10, #0xffffffffffffff78 // #-136 34: str x0, [x25, x10] 38: mov x10, #0xffffffffffffff80 // #-128 3c: str x0, [x25, x10] 40: mov x10, #0xffffffffffffff88 // #-120 44: str x0, [x25, x10] 48: mov x10, #0xffffffffffffff90 // #-112 4c: str x0, [x25, x10] 50: mov x10, #0xffffffffffffff98 // #-104 54: str x0, [x25, x10] 58: mov x10, #0xffffffffffffffa0 // #-96 5c: str x0, [x25, x10] 60: mov x10, #0xffffffffffffffa8 // #-88 64: str x0, [x25, x10] 68: mov x10, #0xffffffffffffffb0 // #-80 6c: str x0, [x25, x10] 70: mov x10, #0xffffffffffffffb8 // #-72 74: str x0, [x25, x10] 78: mov x10, #0xffffffffffffffc0 // #-64 7c: str x0, [x25, x10] 80: mov x10, #0xffffffffffffffc8 // #-56 84: str x0, [x25, x10] 88: mov x10, #0xffffffffffffffd0 // #-48 8c: str x0, [x25, x10] 90: mov x10, #0xffffffffffffffd8 // #-40 94: str x0, [x25, x10] 98: mov x10, #0xffffffffffffffe0 // #-32 9c: str x0, [x25, x10] a0: mov x10, #0xffffffffffffffe8 // #-24 a4: str x0, [x25, x10] a8: mov x10, #0xfffffffffffffff0 // #-16 ac: str x0, [x25, x10] b0: mov x10, #0xfffffffffffffff8 // #-8 b4: str x0, [x25, x10] b8: mov x10, #0x8 // torvalds#8 bc: ldr x2, [x19, x10] [...] With this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: stp x27, x28, [sp, #-16]! 1c: mov x25, sp 20: sub x27, x25, #0x88 24: mov x26, #0x0 // #0 28: bti j 2c: sub sp, sp, #0x90 30: add x19, x0, #0x0 34: mov x0, #0x0 // #0 38: str x0, [x27] 3c: str x0, [x27, torvalds#8] 40: str x0, [x27, torvalds#16] 44: str x0, [x27, torvalds#24] 48: str x0, [x27, torvalds#32] 4c: str x0, [x27, torvalds#40] 50: str x0, [x27, torvalds#48] 54: str x0, [x27, torvalds#56] 58: str x0, [x27, torvalds#64] 5c: str x0, [x27, torvalds#72] 60: str x0, [x27, torvalds#80] 64: str x0, [x27, torvalds#88] 68: str x0, [x27, torvalds#96] 6c: str x0, [x27, torvalds#104] 70: str x0, [x27, torvalds#112] 74: str x0, [x27, torvalds#120] 78: str x0, [x27, torvalds#128] 7c: ldr x2, [x19, torvalds#8] [...] Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
ammarfaizi2
pushed a commit
to ammarfaizi2/linux-fork
that referenced
this pull request
Mar 31, 2022
The BPF STX/LDX instruction uses offset relative to the FP to address stack space. Since the BPF_FP locates at the top of the frame, the offset is usually a negative number. However, arm64 str/ldr immediate instruction requires that offset be a positive number. Therefore, this patch tries to convert the offsets. The method is to find the negative offset furthest from the FP firstly. Then add it to the FP, calculate a bottom position, called FPB, and then adjust the offsets in other STR/LDX instructions relative to FPB. FPB is saved using the callee-saved register x27 of arm64 which is not used yet. Before adjusting the offset, the patch checks every instruction to ensure that the FP does not change in run-time. If the FP may change, no offset is adjusted. For example, for the following bpftrace command: bpftrace -e 'kprobe:do_sys_open { printf("opening: %s\n", str(arg1)); }' Without this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: mov x25, sp 1c: mov x26, #0x0 // #0 20: bti j 24: sub sp, sp, #0x90 28: add x19, x0, #0x0 2c: mov x0, #0x0 // #0 30: mov x10, #0xffffffffffffff78 // #-136 34: str x0, [x25, x10] 38: mov x10, #0xffffffffffffff80 // #-128 3c: str x0, [x25, x10] 40: mov x10, #0xffffffffffffff88 // #-120 44: str x0, [x25, x10] 48: mov x10, #0xffffffffffffff90 // #-112 4c: str x0, [x25, x10] 50: mov x10, #0xffffffffffffff98 // #-104 54: str x0, [x25, x10] 58: mov x10, #0xffffffffffffffa0 // #-96 5c: str x0, [x25, x10] 60: mov x10, #0xffffffffffffffa8 // #-88 64: str x0, [x25, x10] 68: mov x10, #0xffffffffffffffb0 // #-80 6c: str x0, [x25, x10] 70: mov x10, #0xffffffffffffffb8 // #-72 74: str x0, [x25, x10] 78: mov x10, #0xffffffffffffffc0 // #-64 7c: str x0, [x25, x10] 80: mov x10, #0xffffffffffffffc8 // #-56 84: str x0, [x25, x10] 88: mov x10, #0xffffffffffffffd0 // #-48 8c: str x0, [x25, x10] 90: mov x10, #0xffffffffffffffd8 // #-40 94: str x0, [x25, x10] 98: mov x10, #0xffffffffffffffe0 // #-32 9c: str x0, [x25, x10] a0: mov x10, #0xffffffffffffffe8 // #-24 a4: str x0, [x25, x10] a8: mov x10, #0xfffffffffffffff0 // #-16 ac: str x0, [x25, x10] b0: mov x10, #0xfffffffffffffff8 // #-8 b4: str x0, [x25, x10] b8: mov x10, #0x8 // torvalds#8 bc: ldr x2, [x19, x10] [...] With this patch, jited code(fragment): 0: bti c 4: stp x29, x30, [sp, #-16]! 8: mov x29, sp c: stp x19, x20, [sp, #-16]! 10: stp x21, x22, [sp, #-16]! 14: stp x25, x26, [sp, #-16]! 18: stp x27, x28, [sp, #-16]! 1c: mov x25, sp 20: sub x27, x25, #0x88 24: mov x26, #0x0 // #0 28: bti j 2c: sub sp, sp, #0x90 30: add x19, x0, #0x0 34: mov x0, #0x0 // #0 38: str x0, [x27] 3c: str x0, [x27, torvalds#8] 40: str x0, [x27, torvalds#16] 44: str x0, [x27, torvalds#24] 48: str x0, [x27, torvalds#32] 4c: str x0, [x27, torvalds#40] 50: str x0, [x27, torvalds#48] 54: str x0, [x27, torvalds#56] 58: str x0, [x27, torvalds#64] 5c: str x0, [x27, torvalds#72] 60: str x0, [x27, torvalds#80] 64: str x0, [x27, torvalds#88] 68: str x0, [x27, torvalds#96] 6c: str x0, [x27, torvalds#104] 70: str x0, [x27, torvalds#112] 74: str x0, [x27, torvalds#120] 78: str x0, [x27, torvalds#128] 7c: ldr x2, [x19, torvalds#8] [...] Signed-off-by: Xu Kuohai <xukuohai@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20220321152852.2334294-4-xukuohai@huawei.com
lluchs
pushed a commit
to KIT-OSGroup/linux
that referenced
this pull request
May 10, 2022
nova/Kconfig: Add LIBNVDIMM dependency
Damenly
pushed a commit
to Damenly/linux
that referenced
this pull request
Jul 25, 2023
Signed-off-by: ZHANG Yuntian <yt@radxa.com>
mj22226
pushed a commit
to mj22226/linux
that referenced
this pull request
Jul 30, 2023
Signed-off-by: ZHANG Yuntian <yt@radxa.com>
logic10492
pushed a commit
to logic10492/linux-amd-zen2
that referenced
this pull request
Jan 18, 2024
Allow dispatching from ops.select_cpu()
intel-lab-lkp
pushed a commit
to intel-lab-lkp/linux
that referenced
this pull request
Aug 4, 2024
The kernel sleep profile is no longer working due to a recursive locking bug introduced by commit 42a20f8 ("sched: Add wrapper for get_wchan() to keep task blocked"); either booting with profile=sleep kernel command line option added or executing # echo -n sleep > /sys/kernel/profiling after boot causes the system to lock up. ============================================ WARNING: possible recursive locking detected 5.15.0-rc4+ torvalds#104 Not tainted -------------------------------------------- kthreadd/3 is trying to acquire lock: ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: get_wchan+0x32/0x70 but task is already holding lock: ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: try_to_wake_up+0x53/0x370 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&p->pi_lock); lock(&p->pi_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by kthreadd/3: #0: ffffae5ac2833d68 (&x->wait){....}-{2:2}, at: complete+0x18/0x40 #1: ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: try_to_wake_up+0x53/0x370 #2: ffff93ad29fe9458 (&rq->__lock){-...}-{2:2}, at: try_to_wake_up+0x19f/0x370 stack backtrace: CPU: 0 PID: 3 Comm: kthreadd Not tainted 5.15.0-rc4+ torvalds#104 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: dump_stack_lvl+0x57/0x72 validate_chain.cold+0x122/0x127 __lock_acquire+0x4d2/0x930 lock_acquire+0xc8/0x2f0 ? get_wchan+0x32/0x70 ? rcu_read_lock_sched_held+0x3f/0x80 _raw_spin_lock_irq+0x47/0x90 ? get_wchan+0x32/0x70 get_wchan+0x32/0x70 __update_stats_enqueue_sleeper+0x151/0x430 enqueue_entity+0x4b0/0x520 enqueue_task_fair+0x92/0x6b0 ? lock_is_held_type+0xa7/0x120 ttwu_do_activate+0x73/0x140 try_to_wake_up+0x213/0x370 swake_up_locked+0x20/0x50 complete+0x2f/0x40 ? __cancel_work_timer+0x1b0/0x1b0 kthread+0xfb/0x180 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 However, since nobody noticed this regression for more than 2 years, let's remove profile=sleep support based on an assumption that nobody needs this functionality. Fixes: 42a20f8 ("sched: Add wrapper for get_wchan() to keep task blocked") Cc: stable@vger.kernel.org # v5.16+ Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.