bisecting fixing commit since ff33472c282e209da54cbc0c7c1c06ddfcc93d33 building syzkaller on 32329ceb4bbf58a21007c90edf2fb7ed242345db testing commit ff33472c282e209da54cbc0c7c1c06ddfcc93d33 with gcc (GCC) 8.1.0 kernel signature: 06d3dc7f7b803f235386f57ca78f377e27d3c9c1 run #0: crashed: WARNING in kernfs_get run #1: crashed: WARNING in kernfs_get run #2: crashed: general protection fault in kernfs_add_one run #3: crashed: WARNING: refcount bug in hci_register_dev run #4: crashed: general protection fault in kernfs_add_one run #5: crashed: WARNING in kernfs_get run #6: crashed: WARNING in kernfs_get run #7: crashed: WARNING: refcount bug in hci_register_dev run #8: crashed: WARNING in kernfs_get run #9: crashed: WARNING: refcount bug in hci_register_dev testing current HEAD 4c5bf01e16a7ec59e59a38a61f793c5d1d5560c7 testing commit 4c5bf01e16a7ec59e59a38a61f793c5d1d5560c7 with gcc (GCC) 8.1.0 kernel signature: 0b915dd80235049df79c7b88ab9ac456a83b102e all runs: OK # git bisect start 4c5bf01e16a7ec59e59a38a61f793c5d1d5560c7 ff33472c282e209da54cbc0c7c1c06ddfcc93d33 Bisecting: 1455 revisions left to test after this (roughly 11 steps) [f2ffdcec15f34b9ce0856f42ee6a7ea09767a5bc] ARM: davinci: dm365: Fix McBSP dma_slave_map entry testing commit f2ffdcec15f34b9ce0856f42ee6a7ea09767a5bc with gcc (GCC) 8.1.0 kernel signature: 1521cff0c23e314e991230b83fc4c4d7775117dd all runs: OK # git bisect bad f2ffdcec15f34b9ce0856f42ee6a7ea09767a5bc Bisecting: 727 revisions left to test after this (roughly 10 steps) [ae85d34dd87144a4ab67d63e0ec7df35230f7f7c] PCI: designware-ep: Fix find_first_zero_bit() usage testing commit ae85d34dd87144a4ab67d63e0ec7df35230f7f7c with gcc (GCC) 8.1.0 kernel signature: 1b4b9b59f019b183042e002192739664a2f1413c run #0: crashed: WARNING in kernfs_get run #1: crashed: WARNING in kernfs_get run #2: crashed: WARNING in kernfs_get run #3: crashed: WARNING in kernfs_get run #4: crashed: WARNING in kernfs_get run #5: crashed: WARNING in kernfs_get run #6: crashed: WARNING in kernfs_get run #7: crashed: WARNING in kernfs_get run #8: crashed: general protection fault in kernfs_add_one run #9: crashed: WARNING in kernfs_get # git bisect good ae85d34dd87144a4ab67d63e0ec7df35230f7f7c Bisecting: 363 revisions left to test after this (roughly 9 steps) [500bf0fa349a1627b3507fe41d80a8f838f144ea] xen-netfront: do not use ~0U as error return value for xennet_fill_frags() testing commit 500bf0fa349a1627b3507fe41d80a8f838f144ea with gcc (GCC) 8.1.0 kernel signature: e0017785916356dca6ecaeeb3d7fa5d0083835b0 run #0: crashed: WARNING: ODEBUG bug in netdev_freemem run #1: OK run #2: OK run #3: OK run #4: OK run #5: OK run #6: OK run #7: OK run #8: OK run #9: OK # git bisect good 500bf0fa349a1627b3507fe41d80a8f838f144ea Bisecting: 181 revisions left to test after this (roughly 8 steps) [185b632259e87823a949373324ba1555b5e2b955] arm64: capabilities: Add flags to handle the conflicts on late CPU testing commit 185b632259e87823a949373324ba1555b5e2b955 with gcc (GCC) 8.1.0 kernel signature: 843e1b95dbf0e0a1aca2ceae0726599a7a980445 all runs: OK # git bisect bad 185b632259e87823a949373324ba1555b5e2b955 Bisecting: 90 revisions left to test after this (roughly 7 steps) [bf6d0e32f31ec8270f42573efc8fab53ee25f72e] serial: uartlite: fix exit path null pointer testing commit bf6d0e32f31ec8270f42573efc8fab53ee25f72e with gcc (GCC) 8.1.0 kernel signature: 7f4a8e69c99b5057d8482eff86c4cea59a086601 all runs: OK # git bisect bad bf6d0e32f31ec8270f42573efc8fab53ee25f72e Bisecting: 45 revisions left to test after this (roughly 6 steps) [2289b3ab663d2baa2509d7f078472068d1d3704f] pwm: stm32-lp: Add check in case requested period cannot be achieved testing commit 2289b3ab663d2baa2509d7f078472068d1d3704f with gcc (GCC) 8.1.0 kernel signature: 4189b510ad904ac22ff3ea445ce64e47ef9f94a3 all runs: OK # git bisect bad 2289b3ab663d2baa2509d7f078472068d1d3704f Bisecting: 22 revisions left to test after this (roughly 5 steps) [61a2c2c94422b4d1a07405d1df9408fa3af2b4c6] crypto: skcipher - Unmap pages after an external error testing commit 61a2c2c94422b4d1a07405d1df9408fa3af2b4c6 with gcc (GCC) 8.1.0 kernel signature: 942c311dc7b98e2adb06af3bd4181e27de4e6fbe all runs: OK # git bisect bad 61a2c2c94422b4d1a07405d1df9408fa3af2b4c6 Bisecting: 10 revisions left to test after this (roughly 4 steps) [2f85516a0a65eb53d66cc1f759e0a8945f1326e0] s390/topology: avoid firing events before kobjs are created testing commit 2f85516a0a65eb53d66cc1f759e0a8945f1326e0 with gcc (GCC) 8.1.0 kernel signature: 9493415b725e02c8f78710eff58ffbd56a864c6b all runs: OK # git bisect bad 2f85516a0a65eb53d66cc1f759e0a8945f1326e0 Bisecting: 5 revisions left to test after this (roughly 3 steps) [416a5d0346696d7d70ffeb5e51a911e6709c6575] smack: use GFP_NOFS while holding inode_smack::smk_lock testing commit 416a5d0346696d7d70ffeb5e51a911e6709c6575 with gcc (GCC) 8.1.0 kernel signature: 19cfd3ea2acfbaadafad7eeb0706e108c7650d50 all runs: OK # git bisect bad 416a5d0346696d7d70ffeb5e51a911e6709c6575 Bisecting: 2 revisions left to test after this (roughly 1 step) [1f35e1a1dcb65d81d3268d22cc3cd934ead6c77d] sch_cbq: validate TCA_CBQ_WRROPT to avoid crash testing commit 1f35e1a1dcb65d81d3268d22cc3cd934ead6c77d with gcc (GCC) 8.1.0 kernel signature: 601c66b2b818b92fe756c70761bc0e94b1c2d884 all runs: OK # git bisect bad 1f35e1a1dcb65d81d3268d22cc3cd934ead6c77d Bisecting: 0 revisions left to test after this (roughly 0 steps) [227db8e4c34674124ee6e4a9d534f3a0cc22304c] tipc: fix unlimited bundling of small messages testing commit 227db8e4c34674124ee6e4a9d534f3a0cc22304c with gcc (GCC) 8.1.0 kernel signature: 810ab493c180f179245357c0b4b50bf889530747 all runs: OK # git bisect bad 227db8e4c34674124ee6e4a9d534f3a0cc22304c 227db8e4c34674124ee6e4a9d534f3a0cc22304c is the first bad commit commit 227db8e4c34674124ee6e4a9d534f3a0cc22304c Author: Tuong Lien Date: Wed Oct 2 18:49:43 2019 +0700 tipc: fix unlimited bundling of small messages [ Upstream commit e95584a889e1902fdf1ded9712e2c3c3083baf96 ] We have identified a problem with the "oversubscription" policy in the link transmission code. When small messages are transmitted, and the sending link has reached the transmit window limit, those messages will be bundled and put into the link backlog queue. However, bundles of data messages are counted at the 'CRITICAL' level, so that the counter for that level, instead of the counter for the real, bundled message's level is the one being increased. Subsequent, to-be-bundled data messages at non-CRITICAL levels continue to be tested against the unchanged counter for their own level, while contributing to an unrestrained increase at the CRITICAL backlog level. This leaves a gap in congestion control algorithm for small messages that can result in starvation for other users or a "real" CRITICAL user. Even that eventually can lead to buffer exhaustion & link reset. We fix this by keeping a 'target_bskb' buffer pointer at each levels, then when bundling, we only bundle messages at the same importance level only. This way, we know exactly how many slots a certain level have occupied in the queue, so can manage level congestion accurately. By bundling messages at the same level, we even have more benefits. Let consider this: - One socket sends 64-byte messages at the 'CRITICAL' level; - Another sends 4096-byte messages at the 'LOW' level; When a 64-byte message comes and is bundled the first time, we put the overhead of message bundle to it (+ 40-byte header, data copy, etc.) for later use, but the next message can be a 4096-byte one that cannot be bundled to the previous one. This means the last bundle carries only one payload message which is totally inefficient, as for the receiver also! Later on, another 64-byte message comes, now we make a new bundle and the same story repeats... With the new bundling algorithm, this will not happen, the 64-byte messages will be bundled together even when the 4096-byte message(s) comes in between. However, if the 4096-byte messages are sent at the same level i.e. 'CRITICAL', the bundling algorithm will again cause the same overhead. Also, the same will happen even with only one socket sending small messages at a rate close to the link transmit's one, so that, when one message is bundled, it's transmitted shortly. Then, another message comes, a new bundle is created and so on... We will solve this issue radically by another patch. Fixes: 365ad353c256 ("tipc: reduce risk of user starvation during link congestion") Reported-by: Hoang Le Acked-by: Jon Maloy Signed-off-by: Tuong Lien Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman net/tipc/link.c | 30 +++++++++++++++++++----------- net/tipc/msg.c | 5 +---- 2 files changed, 20 insertions(+), 15 deletions(-) culprit signature: 810ab493c180f179245357c0b4b50bf889530747 parent signature: e0017785916356dca6ecaeeb3d7fa5d0083835b0 revisions tested: 13, total time: 3h56m18.272219992s (build: 1h45m18.853358187s, test: 2h9m13.423755639s) first good commit: 227db8e4c34674124ee6e4a9d534f3a0cc22304c tipc: fix unlimited bundling of small messages cc: ["davem@davemloft.net" "gregkh@linuxfoundation.org" "jon.maloy@ericsson.com" "tuong.t.lien@dektech.com.au"]