Update bcm4709-netgear-r8000.dts #319

adityaxavier · 2016-09-06T07:06:23Z

Including missing WAN GPIO and LED Switch.

awaismasood · 2016-09-09T06:48:32Z

Please see:

I don't do github pull requests.

github throws away all the relevant information, like having even a
valid email address for the person asking me to pull. The diffstat is
also deficient and useless.

Git comes with a nice pull-request generation module, but github
instead decided to replace it with their own totally inferior version.
As a result, I consider github useless for these kinds of things. It's
fine for hosting, but the pull requests and the online commit
editing, are just pure garbage.

I've told github people about my concerns, they didn't think they
mattered, so I gave up. Feel free to make a bugreport to github.
              Linus

lkl: add LKL_HIJACK_SYSCTL to configure sysctl values

Fix checkpatch errors: ERROR: else should follow close brace '}' torvalds#121: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c:121: + } + else WARNING: line over 80 characters torvalds#150: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c:150: + pinfo->tx_fifosize), (void __force *)pinfo->mem_addr, WARNING: Block comments should align the * on each line torvalds#66: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:66: + * Check, if transmit buffers are processed +*/ WARNING: braces {} are not necessary for any arm of this statement torvalds#170: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:170: + if (IS_SMC(pinfo)) { [...] + } else { [...] WARNING: labels should not be indented torvalds#292: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:292: + error_return: ERROR: code indent should use tabs where possible torvalds#299: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:299: +^I^I BD_SC_OV | BD_SC_ID);$ WARNING: labels should not be indented torvalds#319: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:319: + handle_error: WARNING: line over 80 characters torvalds#423: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:423: + setbits32(&pinfo->sccp->scc_gsmrl, (SCC_GSMRL_ENR | SCC_GSMRL_ENT)); ERROR: space required before the open parenthesis '(' torvalds#451: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:451: + while(!cpm_uart_tx_empty(port)) { WARNING: Missing a blank line after declarations torvalds#462: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:462: + smc_t __iomem *smcp = pinfo->smcp; + clrbits16(&smcp->smc_smcmr, SMCMR_REN | SMCMR_TEN); WARNING: line over 80 characters torvalds#466: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:466: + clrbits32(&sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT); WARNING: Missing a blank line after declarations torvalds#466: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:466: + scc_t __iomem *sccp = pinfo->sccp; + clrbits32(&sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT); ERROR: code indent should use tabs where possible torvalds#484: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:484: + struct ktermios *termios,$ WARNING: please, no spaces at the start of a line torvalds#484: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:484: + struct ktermios *termios,$ ERROR: code indent should use tabs where possible torvalds#485: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:485: + struct ktermios *old)$ WARNING: please, no spaces at the start of a line torvalds#485: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:485: + struct ktermios *old)$ WARNING: line over 80 characters torvalds#624: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:624: + /* Output in *one* operation, so we don't interrupt RX/TX if they WARNING: Block comments use a trailing */ on a separate line torvalds#625: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:625: + * were already enabled. */ WARNING: line over 80 characters torvalds#629: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:629: + out_be16(&pinfo->sccup->scc_genscc.scc_mrblr, pinfo->rx_fifosize); WARNING: line over 80 characters torvalds#773: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:773: + mem_addr = pinfo->mem_addr + L1_CACHE_ALIGN(pinfo->rx_nrfifos * pinfo->rx_fifosize); ERROR: code indent should use tabs where possible torvalds#797: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:797: +^I (u8 __iomem *)pinfo->rx_bd_base - DPRAM_BASE);$ ERROR: code indent should use tabs where possible torvalds#799: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:799: +^I (u8 __iomem *)pinfo->tx_bd_base - DPRAM_BASE);$ ERROR: code indent should use tabs where possible torvalds#836: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:836: +^I SCC_GSMRL_MODE_UART | SCC_GSMRL_TDCR_16 | SCC_GSMRL_RDCR_16);$ ERROR: code indent should use tabs where possible torvalds#859: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:859: +^I (u8 __iomem *)pinfo->rx_bd_base - DPRAM_BASE);$ ERROR: code indent should use tabs where possible torvalds#861: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:861: +^I (u8 __iomem *)pinfo->tx_bd_base - DPRAM_BASE);$ WARNING: space prohibited between function name and open parenthesis '(' torvalds#866: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:866: +#if defined (CONFIG_I2C_SPI_SMC1_UCODE_PATCH) WARNING: line over 80 characters torvalds#921: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:921: + clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT); WARNING: Missing a blank line after declarations torvalds#462: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:462: + smc_t __iomem *smcp = pinfo->smcp; + clrbits16(&smcp->smc_smcmr, WARNING: Missing a blank line after declarations torvalds#467: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:467: + scc_t __iomem *sccp = pinfo->sccp; + clrbits32(&sccp->scc_gsmrl, ERROR: code indent should use tabs where possible torvalds#1151: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1151: + struct uart_cpm_port *pinfo)$ WARNING: please, no spaces at the start of a line torvalds#1151: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1151: + struct uart_cpm_port *pinfo)$ ERROR: "(foo*)" should be "(foo *)" torvalds#1161: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1161: + struct clk *clk = clk_get(NULL, (const char*)data); WARNING: Missing a blank line after declarations torvalds#1162: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1162: + struct clk *clk = clk_get(NULL, (const char*)data); + if (!IS_ERR(clk)) ERROR: code indent should use tabs where possible torvalds#1169: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1169: +^I^I^I "fsl,cpm-brg property.\n", np);$ ERROR: code indent should use tabs where possible torvalds#1178: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1178: +^I^I "fsl,cpm-command property.\n", np);$ ERROR: code indent should use tabs where possible torvalds#1192: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1192: WARNING: braces {} are not necessary for any arm of this statement torvalds#1279: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1279: + if (unlikely(nolock)) { [...] + } else { [...] WARNING: braces {} are not necessary for any arm of this statement torvalds#1287: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1287: + if (unlikely(nolock)) { [...] + } else { [...] WARNING: line over 80 characters torvalds#1354: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1354: + clrbits32(&pinfo->sccp->scc_gsmrl, SCC_GSMRL_ENR | SCC_GSMRL_ENT); ERROR: Macros with complex values should be enclosed in parentheses #1394: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1394: +#define CPM_UART_CONSOLE &cpm_scc_uart_console WARNING: Missing a blank line after declarations #1437: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1437: + struct uart_cpm_port *pinfo = platform_get_drvdata(ofdev); + return uart_remove_one_port(&cpm_reg, &pinfo->port); WARNING: please, no spaces at the start of a line #1464: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1464: + };$ WARNING: Missing a blank line after declarations #1469: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1469: + int ret = uart_register_driver(&cpm_reg); + if (ret) WARNING: Missing a blank line after declarations #1062: FILE: drivers/tty/serial/cpm_uart/cpm_uart_core.c:1062: + int i; + volatile cbd_t *bdp; ERROR: "foo * bar" should be "foo *bar" torvalds#19: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm1.h:19: +static inline void cpm_set_scc_fcr(scc_uart_t __iomem * sup) ERROR: "foo * bar" should be "foo *bar" torvalds#25: FILE: drivers/tty/serial/cpm_uart/cpm_uart_cpm1.h:25: +static inline void cpm_set_smc_fcr(smc_uart_t __iomem * up) WARNING: Improper SPDX comment style for 'drivers/tty/serial/cpm_uart/cpm_uart.h', please use '/*' instead #1: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:1: +// SPDX-License-Identifier: GPL-2.0 WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #1: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:1: +// SPDX-License-Identifier: GPL-2.0 WARNING: Block comments use * on subsequent lines torvalds#106: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:106: +/* + virtual to phys transtalion ERROR: code indent should use tabs where possible torvalds#109: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:109: + struct uart_cpm_port *pinfo)$ WARNING: please, no spaces at the start of a line torvalds#109: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:109: + struct uart_cpm_port *pinfo)$ ERROR: code indent should use tabs where possible torvalds#125: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:125: + struct uart_cpm_port *pinfo)$ WARNING: please, no spaces at the start of a line torvalds#125: FILE: drivers/tty/serial/cpm_uart/cpm_uart.h:125: + struct uart_cpm_port *pinfo)$ Signed-off-by: Enrico Weigelt <info@metux.net>

…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com>

…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Current JIT includes fall-back code for byte-swapping on older ARM archs, but fails tests from module test_bpf: test_bpf: torvalds#299 ALU_END_FROM_BE 64: 0x0123456789abcdef >> 32 -> 0x01234567 jited:1 ret 4530944 != -271733879 (0x452300 != 0xefcdab89)FAIL (1 times) test_bpf: torvalds#303 ALU_END_FROM_BE 64: 0xfedcba9876543210 >> 32 -> 0xfedcba98 jited:1 ret 12246016 != 271733878 (0xbadc00 != 0x10325476)FAIL (1 times) test_bpf: torvalds#315 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89 jited:1 ret 4530944 != -271733879 (0x452300 != 0xefcdab89)FAIL (1 times) test_bpf: torvalds#319 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476 jited:1 ret 12246016 != 271733878 (0xbadc00 != 0x10325476)FAIL (1 times) These problems can be traced back to emit_rev32(). Rewrite as simpler code, going from 10 insns to 4 and dropping use of 2 temp registers, while also fixing the test failures above. Signed-off-by: Tony Ambardar <tony.ambardar@gmail.com>

I have been observing a number of systems aborting at insert_dev_extents() in btrfs_create_pending_block_groups(). The following is a sample stack trace of such an abort coming form forced chunk allocation (typically behind CONFIG_BTRFS_EXPERIMENTAL) but this can theoretically happen to any DUP chunk allocation. [ 81.801251] ------------[ cut here ]------------ [ 81.801587] BTRFS: Transaction aborted (error -17) [ 81.801924] WARNING: fs/btrfs/block-group.c:2876 at btrfs_create_pending_block_groups+0x721/0x770 [btrfs], CPU#1: bash/319 [ 81.802764] Modules linked in: virtio_net btrfs xor zstd_compress raid6_pq null_blk [ 81.803310] CPU: 1 UID: 0 PID: 319 Comm: bash Kdump: loaded Not tainted 6.19.0-rc6+ torvalds#319 NONE [ 81.803916] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014 [ 81.804552] RIP: 0010:btrfs_create_pending_block_groups+0x723/0x770 [btrfs] [ 81.805074] Code: 0b 00 00 4c 89 ff 4c 89 54 24 10 48 c7 c6 00 30 6a c0 e8 c0 14 02 00 4c 8b 54 24 10 e9 4c fa ff ff 48 8d 3d ef c6 08 00 89 ee <67> 48 0f b9 3a 4c 8b 54 24 10 41 b8 01 00 00 00 e9 f4 5e 03 00 48 [ 81.806305] RSP: 0018:ffffa36241a6bce8 EFLAGS: 00010282 [ 81.806673] RAX: 000000000000000d RBX: ffff8e699921e400 RCX: 0000000000000000 [ 81.807154] RDX: 0000000002040001 RSI: 00000000ffffffef RDI: ffffffffc0608bf0 [ 81.807658] RBP: 00000000ffffffef R08: ffff8e69830f6000 R09: 0000000000000007 [ 81.808145] R10: ffff8e699921e5e8 R11: 0000000000000000 R12: ffff8e6999228000 [ 81.808676] R13: ffff8e6984d82000 R14: ffff8e69966a69c0 R15: ffff8e69aa47b000 [ 81.809162] FS: 00007fec6bdd9740(0000) GS:ffff8e6b1b379000(0000) knlGS:0000000000000000 [ 81.809725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 81.810114] CR2: 00005604833670f0 CR3: 0000000116679000 CR4: 00000000000006f0 [ 81.810631] Call Trace: [ 81.810821] <TASK> [ 81.810978] __btrfs_end_transaction+0x3e/0x2b0 [btrfs] [ 81.811368] btrfs_force_chunk_alloc_store+0xcd/0x140 [btrfs] [ 81.811823] kernfs_fop_write_iter+0x15f/0x240 [ 81.812128] vfs_write+0x264/0x500 [ 81.812365] ksys_write+0x6c/0xe0 [ 81.812640] do_syscall_64+0x66/0x770 [ 81.812909] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 81.813246] RIP: 0033:0x7fec6be66197 [ 81.813521] Code: 48 89 fa 4c 89 df e8 98 af 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff [ 81.814798] RSP: 002b:00007fffb159dd30 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 [ 81.815292] RAX: ffffffffffffffda RBX: 00007fec6bdd9740 RCX: 00007fec6be66197 [ 81.815822] RDX: 0000000000000002 RSI: 0000560483374f80 RDI: 0000000000000001 [ 81.816289] RBP: 0000560483374f80 R08: 0000000000000000 R09: 0000000000000000 [ 81.816861] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002 [ 81.817327] R13: 00007fec6bfb85c0 R14: 00007fec6bfb5ee0 R15: 00005604833729c0 [ 81.817837] </TASK> [ 81.817993] irq event stamp: 20039 [ 81.818224] hardirqs last enabled at (20047): [<ffffffff99a68302>] __up_console_sem+0x52/0x60 [ 81.818815] hardirqs last disabled at (20056): [<ffffffff99a682e7>] __up_console_sem+0x37/0x60 [ 81.819375] softirqs last enabled at (19470): [<ffffffff999d2b46>] __irq_exit_rcu+0x96/0xc0 [ 81.819990] softirqs last disabled at (19463): [<ffffffff999d2b46>] __irq_exit_rcu+0x96/0xc0 [ 81.820611] ---[ end trace 0000000000000000 ]--- [ 81.820949] BTRFS: error (device dm-7 state A) in btrfs_create_pending_block_groups:2876: errno=-17 Object already exists Inspecting these aborts with drgn, I observed a pattern of overlapping chunk_maps. Note how stripe 1 of the first chunk overlaps in physical address with stripe 0 of the second chunk. Physical Start Physical End Length Logical Type Stripe ---------------------------------------------------------------------------------------------------- 0x0000000102500000 0x0000000142500000 1.0G 0x0000000641d00000 META|DUP 0/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000641d00000 META|DUP 1/2 0x0000000142500000 0x0000000182500000 1.0G 0x0000000601d00000 META|DUP 0/2 0x0000000182500000 0x00000001c2500000 1.0G 0x0000000601d00000 META|DUP 1/2 Now how could this possibly happen? All chunk allocation is protected by the chunk_mutex so racing allocations should see a consistent view of the CHUNK_ALLOCATED bit in the chunk allocation extent-io-tree (device->alloc_state as set by chunk_map_device_set_bits()) The tree itself is protected by a spin lock, and clearing/setting the bits is always protected by fs_info->mapping_tree_lock, so no race is apparent. It turns out that there is a subtle bug in the logic regarding chunk allocations that have happened in the current transaction, known as "pending extents". The chunk allocation as defined in find_free_dev_extent() is a loop which searches the commit root of the dev_root and looks for gaps between DEV_EXTENT items. For those gaps, it then checks alloc_state bitmap for any pending extents and adjusts the hole that it finds accordingly. However, the logic in that adjustment assumes that the first pending extent is the only one in that range. e.g., given a layout with two non-consecutive pending extents in a hole passed to dev_extent_hole_check() via *hole_start and *hole_size: |----pending A----| real hole |----pending B----| | candidate hole | *hole_start *hole_start + *hole_size the code incorrectly returns a "hole" from the end of pending extent A until the passed in hole end, failing to account for pending B. However, it is not entirely obvious that it is actually possible to produce such a layout. I was able to reproduce it, but with some contortions: I continued to use the force chunk allocation sysfs file and I introduced a long delay (10 seconds) into the start of the cleaner thread. I also prevented the unused bgs cleaning logic from ever deleting metadata bgs. These help make it easier to deterministically produce the condition but shouldn't really matter if you imagine the conditions happening by race/luck. Allocations/frees can happen concurrently with the cleaner thread preparing to process an unused extent and both create some used chunks with an unused chunk interleaved, all during one transaction. Then btrfs_delete_unused_bgs() sees the unused one and clears it, leaving a range with several pending chunk allocations and a gap in the middle. The basic idea is that the unused_bgs cleanup work happens on a worker so if we allocate 3 block groups in one transaction, then the cleaner work kicked off by the previous transaction comes through and deletes the middle one of the 3, then the commit root shows no dev extents and we have the bad pattern in the extent-io-tree. One final consideration is that the code happens to loop to the next hole if there are no more extents at all, so we need one more dev extent way past the area we are working in. Something like the following demonstrates the technique: # push the BG frontier out to 20G fallocate -l 20G $mnt/foo # allocate one more that will prevent the "no more dev extents" luck fallocate -l 1G $mnt/sticky # sync sync # clear out the allocation area rm $mnt/foo sync _cleaner # let everything quiesce sleep 20 sync # dev tree should have one bg 20G out and the rest at the beginning.. # sort of like an empty FS but with a random sticky chunk. # kick off the cleaner in the background, remember it will sleep 10s # before doing interesting work _cleaner & sleep 3 # create 3 trivial block groups, all empty, all immediately marked as unused. echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" echo 1 > "$(_btrfs_sysfs_space_info $dev data)/force_chunk_alloc" echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" # let the cleaner thread definitely finish, it will remove the data bg sleep 10 # this allocation sees the non-consecutive pending metadata chunks with # data chunk gap of 1G and allocates a 2G extent in that hole. ENOSPC! echo 1 > "$(_btrfs_sysfs_space_info $dev metadata)/force_chunk_alloc" As for the fix, it is not that obvious. I could not see a trivial way to do it even by adding backup loops into find_free_dev_extent(), so I opted to change the semantics of dev_extent_hole_check() to not stop looping until it finds a sufficiently big hole. For clarity, this also required changing the helper function contains_pending_extent() into two new helpers which find the first pending extent and the first suitable hole in a range. I attempted to clean up the documentation and range calculations to be as consistent and clear as possible for the future. I also looked at the zoned case and concluded that the loop there is different and not to be unified with this one. As far as I can tell, the zoned check will only further constrain the hole so looping back to find more holes is acceptable. Though given that zoned really only appends, I find it highly unlikely that it is susceptible to this bug. Fixes: 1b98450 ("Btrfs: fix find_free_dev_extent() malfunction in case device tree has hole") Reported-by: Dimitrios Apostolou <jimis@gmx.net> Closes: https://lore.kernel.org/linux-btrfs/q7760374-q1p4-029o-5149-26p28421s468@tzk.arg/ Signed-off-by: Boris Burkov <boris@bur.io>

Update bcm4709-netgear-r8000.dts

8d7a38a

Including missing WAN GPIO and LED Switch.

adityaxavier closed this Sep 6, 2016

adityaxavier reopened this Sep 6, 2016

laijs pushed a commit to laijs/linux that referenced this pull request Feb 14, 2017

Merge pull request torvalds#319 from libos-nuse/feature-conf-sysctl

45caa74

lkl: add LKL_HIJACK_SYSCTL to configure sysctl values

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update bcm4709-netgear-r8000.dts #319

Update bcm4709-netgear-r8000.dts #319

Uh oh!

adityaxavier commented Sep 6, 2016

Uh oh!

awaismasood commented Sep 9, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Update bcm4709-netgear-r8000.dts #319

Update bcm4709-netgear-r8000.dts #319

Uh oh!

Conversation

adityaxavier commented Sep 6, 2016

Uh oh!

awaismasood commented Sep 9, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants