kernel/linux.git, branch v4.19.8

Linux 4.19.8

2018-12-08T11:59:10+00:00

blk-mq: punt failed direct issue to dispatch list

2018-12-08T11:59:10+00:00

commit c616cbee97aed4bc6178f148a7240206dcdb85a6 upstream. After the direct dispatch corruption fix, we permanently disallow direct dispatch of non read/write requests. This works fine off the normal IO path, as they will be retried like any other failed direct dispatch request. But for the blk_insert_cloned_request() that only DM uses to bypass the bottom level scheduler, we always first attempt direct dispatch. For some types of requests, that's now a permanent failure, and no amount of retrying will make that succeed. This results in a livelock. Instead of making special cases for what we can direct issue, and now having to deal with DM solving the livelock while still retaining a BUSY condition feedback loop, always just add a request that has been through ->queue_rq() to the hardware queue dispatch list. These are safe to use as no merging can take place there. Additionally, if requests do have prepped data from drivers, we aren't dependent on them not sharing space in the request structure to safely add them to the IO scheduler lists. This basically reverts ffe81d45322c and is based on a patch from Ming, but with the list insert case covered as well. Fixes: ffe81d45322c ("blk-mq: fix corruption with direct issue") Cc: stable@vger.kernel.org Suggested-by: Ming Lei Reported-by: Bart Van Assche Tested-by: Ming Lei Acked-by: Mike Snitzer Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

tipc: use destination length for copy string

2018-12-08T11:59:10+00:00

commit 29e270fc32192e7729057963ae7120663856c93e upstream. Got below warning with gcc 8.2 compiler. net/tipc/topsrv.c: In function ‘tipc_topsrv_start’: net/tipc/topsrv.c:660:2: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] strncpy(srv->name, name, strlen(name) + 1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/tipc/topsrv.c:660:27: note: length computed here strncpy(srv->name, name, strlen(name) + 1); ^~~~~~~~~~~~ So change it to correct length and use strscpy. Signed-off-by: Guoqing Jiang Acked-by: Ying Xue Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

arc: [devboards] Add support of NFSv3 ACL

2018-12-08T11:59:10+00:00

commit 6b04114f6fae5e84d33404c2970b1949c032546e upstream. By default NFSv3 doesn't support ACL (Access Control Lists) which might be quite convenient to have so that mounted NFS behaves exactly as any other local file-system. In particular missing support of ACL makes umask useless. This among other thigs fixes Glibc's "nptl/tst-umask1". Signed-off-by: Alexey Brodkin Cc: Cupertino Miranda Cc: stable@vger.kernel.org #4.14+ Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

ARC: change defconfig defaults to ARCv2

2018-12-08T11:59:10+00:00

commit b7cc40c32a8bfa6f2581a71747f6a7d491fe43ba upstream. Change the default defconfig (used with 'make defconfig') to the ARCv2 nsim_hs_defconfig, and also switch the default Kconfig ISA selection to ARCv2. This allows several default defconfigs (e.g. make defconfig, make allnoconfig, make tinyconfig) to all work with ARCv2 by default. Note since we change default architecture from ARCompact to ARCv2 it's required to explicitly mention architecture type in ARCompact defconfigs otherwise ARCv2 will be implied and binaries will be generated for ARCv2. Cc: # 4.4.x Signed-off-by: Kevin Hilman Signed-off-by: Alexey Brodkin Signed-off-by: Vineet Gupta Signed-off-by: Greg Kroah-Hartman

btrfs: tree-checker: Don't check max block group size as current max chunk size limit is unreliable

2018-12-08T11:59:10+00:00

commit 10950929e994c5ecee149ff0873388d3c98f12b5 upstream. [BUG] A completely valid btrfs will refuse to mount, with error message like: BTRFS critical (device sdb2): corrupt leaf: root=2 block=239681536 slot=172 \ bg_start=12018974720 bg_len=10888413184, invalid block group size, \ have 10888413184 expect (0, 10737418240] This has been reported several times as the 4.19 kernel is now being used. The filesystem refuses to mount, but is otherwise ok and booting 4.18 is a workaround. Btrfs check returns no error, and all kernels used on this fs is later than 2011, which should all have the 10G size limit commit. [CAUSE] For a 12 devices btrfs, we could allocate a chunk larger than 10G due to stripe stripe bump up. __btrfs_alloc_chunk() |- max_stripe_size = 1G |- max_chunk_size = 10G |- data_stripe = 11 |- if (1G * 11 > 10G) { stripe_size = 976128930; stripe_size = round_up(976128930, SZ_16M) = 989855744 However the final stripe_size (989855744) * 11 = 10888413184, which is still larger than 10G. [FIX] For the comprehensive check, we need to do the full check at chunk read time, and rely on bg <-> chunk mapping to do the check. We could just skip the length check for now. Fixes: fce466eab7ac ("btrfs: tree-checker: Verify block_group_item") Cc: stable@vger.kernel.org # v4.19+ Reported-by: Wang Yugui Signed-off-by: Qu Wenruo Reviewed-by: David Sterba Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman

Input: elan_i2c - add support for ELAN0621 touchpad

2018-12-08T11:59:09+00:00

commit bf87ade0dd7f8cf19dac4d3161d5e86abe0c062b upstream. Added the ability to detect the ELAN0621 touchpad found in some Lenovo laptops. Signed-off-by: Adam Wong Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15ARR

2018-12-08T11:59:09+00:00

commit ad33429cd02565c28404bb16ae7a4c2bdfda6626 upstream. Add ELAN061E to the ACPI table to support Elan touchpad found in Lenovo IdeaPad 330-15ARR. Signed-off-by: Noah Westervelt Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: elan_i2c - add ELAN0620 to the ACPI table

2018-12-08T11:59:09+00:00

commit 3ed64da3b790be7c63601e8ca6341b7dff74a660 upstream. Add ELAN0620 to the ACPI table to support the elan touchpad in the Lenovo IdeaPad 130-15IKB. Signed-off-by: Patrick Gaskin Cc: stable@vger.kernel.org Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman

Input: cros_ec_keyb - fix button/switch capability reports

2018-12-08T11:59:09+00:00

commit ac5722c1643a2fb75224c79b578214956d34f989 upstream. The cros_ec_keyb_bs array lists buttons and switches together, expecting that its users will match the appropriate type and bit fields. But cros_ec_keyb_register_bs() only checks the 'bit' field, which causes misreported input capabilities in some cases. For example, tablets (e.g., Scarlet -- a.k.a. Acer Chromebook Tab 10) were reporting a SW_LID capability, because EC_MKBP_POWER_BUTTON and EC_MKBP_LID_OPEN happen to share the same bit. (This has comedic effect on a tablet, in which a power-management daemon then thinks this "lid" is closed, and so puts the system to sleep as soon as it boots!) To fix this, check both the 'ev_type' and 'bit' fields before reporting the capability. Tested with a lid (Kevin / Samsung Chromebook Plus) and without a lid (Scarlet / Acer Chromebook Tab 10). This error got introduced when porting the feature from the downstream Chromium OS kernel to be upstreamed. Fixes: cdd7950e7aa4 ("input: cros_ec_keyb: Add non-matrix buttons and switches") Cc: Signed-off-by: Brian Norris Reviewed-by: Heiko Stuebner Signed-off-by: Dmitry Torokhov Signed-off-by: Greg Kroah-Hartman