- 06 Feb, 2019 40 commits
-
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Kleber Sacilotto de Souza <kleber.souza@canonical.com> Signed-off-by:
-
Andy Whitcroft authored
When we are signing for an architecture switch to producing a linux-image-unsigned package from the primary source. linux-signed will then produce the linux-image package which will be signed. We expect all consumers to use the signed form even if they are not utilising the signature. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
When we install linux-image we have to run kernel postinst.d support in case this kernel has no linux-image-extra. Should it have an extra and we install we then have to assume that is being installed cold and that the same processing is neeed. If we are installing both at the same time, we necessarily trigger kernel postinst.d twice. As this includes rebuilding the initramfs and reconfiguring the boot loader this is very inefficient. For removal of linux-image-extra when we remove the package we also need to run postinst.d handling in order to pare down the initramfs to linux-image contents only. However when we are removing both packages we immediatly remove the rebuilt initramfs. Doubly annoying. This patch switches us to using a trigger against the linux-image package for all postinst.d and postrm.d handling. On installation postinst.d gets triggered twice once by linux-image and once by linux-image-extra. As triggers are non-cumulative we will only run this processing once. When removing both packages we will trigger postinst.d from linux-image-extra and then in linux-image postrm.d we effectivly ignore the pending trigger and simply run the postrm.d. This prevents us from rebuilding the initramfs. BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1764794Signed-off-by:
-
Siva Rebbagondla authored
BugLink: https://bugs.launchpad.net/bugs/1813869 When mac spoof is enabled in userspace and scan gets triggered with custom mac address, driver is not handling custom mac addresses properly and causing kernel crash. This could be fixed by copying custom mac addess to mac address. ...skipping... [ 49.130185] BUG: unable to handle kernel NULL pointer dereference at 0000000000000134 [ 49.138969] IP: [<ffffffffc0517c03>] rsi_prepare_mgmt_desc+0xd3/0x2d0 [ven_rsi_91x] [ 49.147555] PGD 0 [ 49.149799] Oops: 0000 [#1] SMP [ 49.244030] CPU: 0 PID: 31 Comm: kworker/u4:1 Not tainted 4.4.0-139-generic #165-Ubuntu [ 49.252988] Hardware name: Dell Inc. Edge Gateway 3001/, BIOS 01.00.00 04/17/2017 [ 49.261374] Workqueue: rsi_scan_worker rsi_scan_start [ven_rsi_91x] [ 49.357435] Stack: [ 49.359675] ffff88007542d7c0 ffff88005c290dd8 ffff880077894000 0000000000000000 [ 49.367971] ffff8800747aa640 ffff88006928a500 ffff8800785e7d78 ffffffffc0516457 [ 49.376267] 00000046785e7d48 ffff8800778950e0 ffff8800747aa640 ffff880075438000 [ 49.384561] Call Trace: [ 49.387307] [<ffffffffc0516457>] rsi_send_probe_request+0x2c7/0x350 [ven_rsi_91x] [ 49.395784] [<ffffffffc0516702>] rsi_scan_start+0x222/0x380 [ven_rsi_91x] [ 49.403486] [<ffffffff818530c1>] ? __schedule+0x301/0x7f0 [ 49.409633] [<ffffffff8109ee4b>] process_one_work+0x16b/0x490 [ 49.416164] [<ffffffff8109f1bb>] worker_thread+0x4b/0x4d0 [ 49.422306] [<ffffffff8109f170>] ? process_one_work+0x490/0x490 [ 49.429032] [<ffffffff810a5587>] kthread+0xe7/0x100 [ 49.434589] [<ffffffff818530c1>] ? __schedule+0x301/0x7f0 [ 49.440731] [<ffffffff810a54a0>] ? kthread_create_on_node+0x1e0/0x1e0 [ 49.448042] [<ffffffff81857bf5>] ret_from_fork+0x55/0x80 [ 49.454086] [<ffffffff810a54a0>] ? kthread_create_on_node+0x1e0/0x1e0 Signed-off-by:
Siva Rebbagondla <siva.rebbagondla@redpinesignals.com> Acked-by:
Khalid Elmously <khalid.elmously@canonical.com>
-
Juerg Haefliger authored
BugLink: https://bugs.launchpad.net/bugs/1764956 IBRS in Ubuntu can be controlled dynamically from userspace. Make sure the correct state is restored on VMEXIT. Suggested-by:
Gavin Guo <gavin.guo@canonical.com> Signed-off-by:
Juerg Haefliger <juergh@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Greg Kroah-Hartman authored
BugLink: https://bugs.launchpad.net/bugs/1811647Signed-off-by:
-
Lubomir Rintel authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit ed54ffbe upstream. According to [1] and [2], the temperature values are in tenths of degree Celsius. Exposing the Celsius value makes the battery appear on fire: $ upower -i /org/freedesktop/UPower/devices/battery_olpc_battery ... temperature: 236.9 degrees C Tested on OLPC XO-1 and OLPC XO-1.75 laptops. [1] include/linux/power_supply.h [2] Documentation/power/power_supply_class.txt Fixes: fb972873 ("[BATTERY] One Laptop Per Child power/battery driver") Cc: stable@vger.kernel.org Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Acked-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Alexander Shishkin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit ec5b5ad6 upstream. The 'nr_pages' attribute of the 'msc' subdevices parses a comma-separated list of window sizes, passed from userspace. However, there is a bug in the string parsing logic wherein it doesn't exclude the comma character from the range of characters as it consumes them. This leads to an out-of-bounds access given a sufficiently long list. For example: > # echo 8,8,8,8 > /sys/bus/intel_th/devices/0-msc0/nr_pages > ================================================================== > BUG: KASAN: slab-out-of-bounds in memchr+0x1e/0x40 > Read of size 1 at addr ffff8803ffcebcd1 by task sh/825 > > CPU: 3 PID: 825 Comm: npktest.sh Tainted: G W 4.20.0-rc1+ > Call Trace: > dump_stack+0x7c/0xc0 > print_address_description+0x6c/0x23c > ? memchr+0x1e/0x40 > kasan_report.cold.5+0x241/0x308 > memchr+0x1e/0x40 > nr_pages_store+0x203/0xd00 [intel_th_msu] Fix this by accounting for the comma character. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Fixes: ba82664c ("intel_th: Add Memory Storage Unit driver") Cc: stable@vger.kernel.org # v4.4+ Signed-off-by:
-
Christian Borntraeger authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit fdd66968 upstream. Calling the test program genwqe_cksum with the default buffer size of 2MB triggers the following kernel warning on s390: WARNING: CPU: 30 PID: 9311 at mm/page_alloc.c:3189 __alloc_pages_nodemask+0x45c/0xbe0 CPU: 30 PID: 9311 Comm: genwqe_cksum Kdump: loaded Not tainted 3.10.0-957.el7.s390x #1 task: 00000005e5d13980 ti: 00000005e7c6c000 task.ti: 00000005e7c6c000 Krnl PSW : 0704c00180000000 00000000002780ac (__alloc_pages_nodemask+0x45c/0xbe0) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3 Krnl GPRS: 00000000002932b8 0000000000b73d7c 0000000000000010 0000000000000009 0000000000000041 00000005e7c6f9b8 0000000000000001 00000000000080d0 0000000000000000 0000000000b70500 0000000000000001 0000000000000000 0000000000b70528 00000000007682c0 0000000000277df2 00000005e7c6f9a0 Krnl Code: 000000000027809e: de7195001000 ed 1280(114,%r9),0(%r1) 00000000002780a4: a774fead brc 7,277dfe #00000000002780a8: a7f40001 brc 15,2780aa >00000000002780ac: 92011000 mvi 0(%r1),1 00000000002780b0: a7f4fea7 brc 15,277dfe 00000000002780b4: 9101c6b6 tm 1718(%r12),1 00000000002780b8: a784ff3a brc 8,277f2c 00000000002780bc: a7f4fe2e brc 15,277d18 Call Trace: ([<0000000000277df2>] __alloc_pages_nodemask+0x1a2/0xbe0) [<000000000013afae>] s390_dma_alloc+0xfe/0x310 [<000003ff8065f362>] __genwqe_alloc_consistent+0xfa/0x148 [genwqe_card] [<000003ff80658f7a>] genwqe_mmap+0xca/0x248 [genwqe_card] [<00000000002b2712>] mmap_region+0x4e2/0x778 [<00000000002b2c54>] do_mmap+0x2ac/0x3e0 [<0000000000292d7e>] vm_mmap_pgoff+0xd6/0x118 [<00000000002b081c>] SyS_mmap_pgoff+0xdc/0x268 [<00000000002b0a34>] SyS_old_mmap+0x8c/0xb0 [<000000000074e518>] sysc_tracego+0x14/0x1e [<000003ffacf87dc6>] 0x3ffacf87dc6 turns out the check in __genwqe_alloc_consistent uses "> MAX_ORDER" while the mm code uses ">= MAX_ORDER". Fix genwqe. Cc: stable@vger.kernel.org Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Frank Haverkamp <haver@linux.vnet.ibm.com> Signed-off-by:
-
Yan, Zheng authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 3c1392d4 upstream. Updating mseq makes client think importer mds has accepted all prior cap messages and importer mds knows what caps client wants. Actually some cap messages may have been dropped because of mseq mismatch. If mseq is left untouched, importing cap's mds_wanted later will get reset by cap import message. Cc: stable@vger.kernel.org Signed-off-by:
"Yan, Zheng" <zyan@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Sohil Mehta authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 3569dd07 upstream. The Intel IOMMU driver opportunistically skips a few top level page tables from the domain paging directory while programming the IOMMU context entry. However there is an implicit assumption in the code that domain's adjusted guest address width (agaw) would always be greater than IOMMU's agaw. The IOMMU capabilities in an upcoming platform cause the domain's agaw to be lower than IOMMU's agaw. The issue is seen when the IOMMU supports both 4-level and 5-level paging. The domain builds a 4-level page table based on agaw of 2. However the IOMMU's agaw is set as 3 (5-level). In this case the code incorrectly tries to skip page page table levels. This causes the IOMMU driver to avoid programming the context entry. The fix handles this case and programs the context entry accordingly. Fixes: de24e553 ("iommu/vt-d: Simplify domain_context_mapping_one") Cc: <stable@vger.kernel.org> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Jacob Pan <jacob.jun.pan@linux.intel.com> Cc: Lu Baolu <baolu.lu@linux.intel.com> Reviewed-by:
Lu Baolu <baolu.lu@linux.intel.com> Reported-by:
Ramos Falcon, Ernesto R <ernesto.r.ramos.falcon@intel.com> Tested-by:
Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Signed-off-by:
Sohil Mehta <sohil.mehta@intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Dominique Martinet authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 574d356b upstream. If the requested msize is too small (either from command line argument or from the server version reply), we won't get any work done. If it's *really* too small, nothing will work, and this got caught by syzbot recently (on a new kmem_cache_create_usercopy() call) Just set a minimum msize to 4k in both code paths, until someone complains they have a use-case for a smaller msize. We need to check in both mount option and server reply individually because the msize for the first version request would be unchecked with just a global check on clnt->msize. Link: http://lkml.kernel.org/r/1541407968-31350-1-git-send-email-asmadeus@codewreck.org Reported-by: syzbot+0c1d61e4db7db94102ca@syzkaller.appspotmail.com Signed-off-by:
Dominique Martinet <dominique.martinet@cea.fr> Cc: Eric Van Hensbergen <ericvh@gmail.com> Cc: Latchesar Ionkov <lucho@ionkov.net> Cc: stable@vger.kernel.org Signed-off-by:
-
Larry Finger authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 8ea3819c upstream. The cordic routine for calculating sines and cosines that was added in commit 6f98e62a ("b43: update cordic code to match current specs") contains an error whereby a quantity declared u32 can in fact go negative. This problem was detected by Priit Laes who is switching b43 to use the routine in the library functions of the kernel. Fixes: 98650454 ("b43: make cordic common (LP-PHY and N-PHY need it)") Reported-by:
Priit Laes <plaes@plaes.org> Cc: Rafał Miłecki <zajec5@gmail.com> Cc: Stable <stable@vger.kernel.org> # 2.6.34 Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Andreas Gruenbacher authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 2d29f6b9 upstream. Fix the resource group wrap-around logic in gfs2_rbm_find that commit e579ed4f broke. The bug can lead to unnecessary repeated scanning of the same bitmaps; there is a risk that future changes will turn this into an endless loop. Fixes: e579ed4f ("GFS2: Introduce rbm field bii") Cc: stable@vger.kernel.org # v3.13+ Signed-off-by:
Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit d47b41ac upstream. According to comment in dlm_user_request() ua should be freed in dlm_free_lkb() after successful attach to lkb. However ua is attached to lkb not in set_lock_args() but later, inside request_lock(). Fixes 597d0cae ("[DLM] dlm: user locks") Cc: stable@kernel.org # 2.6.19 Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit c0174726 upstream. Fixes 6d40c4a7 ("dlm: improve error and debug messages") Cc: stable@kernel.org # 3.5 Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 23851e97 upstream. Fixes 3d6aa675 ("dlm: keep lkbs in idr") Cc: stable@kernel.org # 3.1 Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit b982896c upstream. If allocation fails on last elements of array need to free already allocated elements. v2: just move existing out_rsbtbl label to right place Fixes 789924ba635f ("dlm: fix race between remove and lookup") Cc: stable@kernel.org # 3.6 Signed-off-by:
-
Hui Peng authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit cbb2ebf7 upstream. In `create_composite_quirk`, the terminating condition of for loops is `quirk->ifnum < 0`. So any composite quirks should end with `struct snd_usb_audio_quirk` object with ifnum < 0. for (quirk = quirk_comp->data; quirk->ifnum >= 0; ++quirk) { ..... } the data field of Bower's & Wilkins PX headphones usb device device quirks do not end with {.ifnum = -1}, wihch may result in out-of-bound read. This Patch fix the bug by adding an ending quirk object. Fixes: 240a8af9 ("ALSA: usb-audio: Add a quirck for B&W PX headphones") Signed-off-by:
Hui Peng <benquike@163.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit f4351a19 upstream. The parser for the processing unit reads bNrInPins field before the bLength sanity check, which may lead to an out-of-bound access when a malformed descriptor is given. Fix it by assignment after the bLength check. Cc: <stable@vger.kernel.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 1524f4e4 upstream. The "chip->dsp_spos_instance" can be NULL on some of the ealier error paths in snd_cs46xx_create(). Reported-by:
"Yavuz, Tuba" <tuba@ece.ufl.edu> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Eric Biggers authored
BugLink: https://bugs.launchpad.net/bugs/1811647 In chacha20-simd, clear the MAY_SLEEP flag in the blkcipher_desc to prevent sleeping with preemption disabled, under kernel_fpu_begin(). This was fixed upstream incidentally by a large refactoring, commit 9ae433bc ("crypto: chacha20 - convert generic and x86 versions to skcipher"). But syzkaller easily trips over this when running on older kernels, as it's easily reachable via AF_ALG. Therefore, this patch makes the minimal fix for older kernels. Fixes: c9320b6d ("crypto: chacha20 - Add a SSSE3 SIMD variant for x86_64") Cc: linux-crypto@vger.kernel.org Cc: Martin Willi <martin@strongswan.org> Signed-off-by:
Eric Biggers <ebiggers@google.com> Acked-by:
Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit b8be5674 upstream. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Vasily Averin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 4ecd55ea upstream. After commit d202cce8, an expired cache_head can be removed from the cache_detail's hash. However, the expired cache_head may be waiting for a reply from a previously submitted request. Such a cache_head has an increased refcounter and therefore it won't be freed after cache_put(freeme). Because the cache_head was removed from the hash it cannot be found during cache_clean() and can be leaked forever, together with stalled cache_request and other taken resources. In our case we noticed it because an entry in the export cache was holding a reference on a filesystem. Fixes d202cce8 ("sunrpc: never return expired entries in sunrpc_cache_lookup") Cc: Pavel Tikhomirov <ptikhomirov@virtuozzo.com> Cc: stable@kernel.org # 2.6.35 Signed-off-by:
NeilBrown <neilb@suse.com> Signed-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 06489cfb upstream. Given the fact that devm_memremap_pages() requires a percpu_ref that is torn down by devm_memremap_pages_release() the current support for mapping RAM is broken. Support for remapping "System RAM" has been broken since the beginning and there is no existing user of this this code path, so just kill the support and make it an explicit error. This cleanup also simplifies a follow-on patch to fix the error path when setting a devm release action for devm_memremap_pages_release() fails. Link: http://lkml.kernel.org/r/154275557997.76910.14689813630968180480.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
Dan Williams <dan.j.williams@intel.com> Reviewed-by:
"Jérôme Glisse" <jglisse@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Logan Gunthorpe <logang@deltatee.com> Cc: Balbir Singh <bsingharora@gmail.com> Cc: Michal Hocko <mhocko@suse.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Dan Williams authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 808153e1 upstream. devm_memremap_pages() is a facility that can create struct page entries for any arbitrary range and give drivers the ability to subvert core aspects of page management. Specifically the facility is tightly integrated with the kernel's memory hotplug functionality. It injects an altmap argument deep into the architecture specific vmemmap implementation to allow allocating from specific reserved pages, and it has Linux specific assumptions about page structure reference counting relative to get_user_pages() and get_user_pages_fast(). It was an oversight and a mistake that this was not marked EXPORT_SYMBOL_GPL from the outset. Again, devm_memremap_pagex() exposes and relies upon core kernel internal assumptions and will continue to evolve along with 'struct page', memory hotplug, and support for new memory types / topologies. Only an in-kernel GPL-only driver is expected to keep up with this ongoing evolution. This interface, and functionality derived from this interface, is not suitable for kernel-external drivers. Link: http://lkml.kernel.org/r/154275557457.76910.16923571232582744134.stgit@dwillia2-desk3.amr.corp.intel.comSigned-off-by:
Michal Hocko <mhocko@suse.com> Cc: "Jérôme Glisse" <jglisse@redhat.com> Cc: Balbir Singh <bsingharora@gmail.com> Cc: Logan Gunthorpe <logang@deltatee.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Michal Hocko authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit b15c8726 upstream. We have received a bug report that an injected MCE about faulty memory prevents memory offline to succeed on 4.4 base kernel. The underlying reason was that the HWPoison page has an elevated reference count and the migration keeps failing. There are two problems with that. First of all it is dubious to migrate the poisoned page because we know that accessing that memory is possible to fail. Secondly it doesn't make any sense to migrate a potentially broken content and preserve the memory corruption over to a new location. Oscar has found out that 4.4 and the current upstream kernels behave slightly differently with his simply testcase === int main(void) { int ret; int i; int fd; char *array = malloc(4096); char *array_locked = malloc(4096); fd = open("/tmp/data", O_RDONLY); read(fd, array, 4095); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; ret = mlock((void *)PAGE_ALIGN((unsigned long)array_locked), sizeof(array_locked)); if (ret) perror("mlock"); sleep (20); ret = madvise((void *)PAGE_ALIGN((unsigned long)array_locked), 4096, MADV_HWPOISON); if (ret) perror("madvise"); for (i = 0; i < 4096; i++) array_locked[i] = 'd'; return 0; } === + offline this memory. In 4.4 kernels he saw the hwpoisoned page to be returned back to the LRU list kernel: [<ffffffff81019ac9>] dump_trace+0x59/0x340 kernel: [<ffffffff81019e9a>] show_stack_log_lvl+0xea/0x170 kernel: [<ffffffff8101ac71>] show_stack+0x21/0x40 kernel: [<ffffffff8132bb90>] dump_stack+0x5c/0x7c kernel: [<ffffffff810815a1>] warn_slowpath_common+0x81/0xb0 kernel: [<ffffffff811a275c>] __pagevec_lru_add_fn+0x14c/0x160 kernel: [<ffffffff811a2eed>] pagevec_lru_move_fn+0xad/0x100 kernel: [<ffffffff811a334c>] __lru_cache_add+0x6c/0xb0 kernel: [<ffffffff81195236>] add_to_page_cache_lru+0x46/0x70 kernel: [<ffffffffa02b4373>] extent_readpages+0xc3/0x1a0 [btrfs] kernel: [<ffffffff811a16d7>] __do_page_cache_readahead+0x177/0x200 kernel: [<ffffffff811a18c8>] ondemand_readahead+0x168/0x2a0 kernel: [<ffffffff8119673f>] generic_file_read_iter+0x41f/0x660 kernel: [<ffffffff8120e50d>] __vfs_read+0xcd/0x140 kernel: [<ffffffff8120e9ea>] vfs_read+0x7a/0x120 kernel: [<ffffffff8121404b>] kernel_read+0x3b/0x50 kernel: [<ffffffff81215c80>] do_execveat_common.isra.29+0x490/0x6f0 kernel: [<ffffffff81215f08>] do_execve+0x28/0x30 kernel: [<ffffffff81095ddb>] call_usermodehelper_exec_async+0xfb/0x130 kernel: [<ffffffff8161c045>] ret_from_fork+0x55/0x80 And that latter confuses the hotremove path because an LRU page is attempted to be migrated and that fails due to an elevated reference count. It is quite possible that the reuse of the HWPoisoned page is some kind of fixed race condition but I am not really sure about that. With the upstream kernel the failure is slightly different. The page doesn't seem to have LRU bit set but isolate_movable_page simply fails and do_migrate_range simply puts all the isolated pages back to LRU and therefore no progress is made and scan_movable_pages finds same set of pages over and over again. Fix both cases by explicitly checking HWPoisoned pages before we even try to get reference on the page, try to unmap it if it is still mapped. As explained by Naoya: : Hwpoison code never unmapped those for no big reason because : Ksm pages never dominate memory, so we simply didn't have strong : motivation to save the pages. Also put WARN_ON(PageLRU) in case there is a race and we can hit LRU HWPoison pages which shouldn't happen but I couldn't convince myself about that. Naoya has noted the following: : Theoretically no such gurantee, because try_to_unmap() doesn't have a : guarantee of success and then memory_failure() returns immediately : when hwpoison_user_mappings fails. : Or the following code (comes after hwpoison_user_mappings block) also impli= : es : that the target page can still have PageLRU flag. : : /* : * Torn down by someone else? : */ : if (PageLRU(p) && !PageSwapCache(p) && p->mapping =3D=3D NULL) { : action_result(pfn, MF_MSG_TRUNCATED_LRU, MF_IGNORED); : res =3D -EBUSY; : goto out; : } : : So I think it's OK to keep "if (WARN_ON(PageLRU(page)))" block in : current version of your patch. Link: http://lkml.kernel.org/r/20181206120135.14079-1-mhocko@kernel.orgSigned-off-by:
Oscar Salvador <osalvador@suse.com> Debugged-by:
David Hildenbrand <david@redhat.com> Acked-by:
Naoya Horiguchi <n-horiguchi@ah.jp.nec.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Steffen Maier authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 60a161b7 upstream. Suppose adapter (open) recovery is between opened QDIO queues and before (the end of) initial posting of status read buffers (SRBs). This time window can be seconds long due to FSF_PROT_HOST_CONNECTION_INITIALIZING causing by design looping with exponential increase sleeps in the function performing exchange config data during recovery [zfcp_erp_adapter_strat_fsf_xconf()]. Recovery triggered by local link up. Suppose an event occurs for which the FCP channel would send an unsolicited notification to zfcp by means of a previously posted SRB. We saw it with local cable pull (link down) in multi-initiator zoning with multiple NPIV-enabled subchannels of the same shared FCP channel. As soon as zfcp_erp_adapter_strategy_open_fsf() starts posting the initial status read buffers from within the adapter's ERP thread, the channel does send an unsolicited notification. Since v2.6.27 commit d26ab06e ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall"), zfcp_fsf_status_read_handler() schedules adapter->stat_work to re-fill the just consumed SRB from a work item. Now the ERP thread and the work item post SRBs in parallel. Both contexts call the helper function zfcp_status_read_refill(). The tracking of missing (to be posted / re-filled) SRBs is not thread-safe due to separate atomic_read() and atomic_dec(), in order to depend on posting success. Hence, both contexts can see atomic_read(&adapter->stat_miss) == 1. One of the two contexts posts one too many SRB. Zfcp gets QDIO_ERROR_SLSB_STATE on the output queue (trace tag "qdireq1") leading to zfcp_erp_adapter_shutdown() in zfcp_qdio_handler_error(). An obvious and seemingly clean fix would be to schedule stat_work from the ERP thread and wait for it to finish. This would serialize all SRB re-fills. However, we already have another work item wait on the ERP thread: adapter->scan_work runs zfcp_fc_scan_ports() which calls zfcp_fc_eval_gpn_ft(). The latter calls zfcp_erp_wait() to wait for all the open port recoveries during zfcp auto port scan, but in fact it waits for any pending recovery including an adapter recovery. This approach leads to a deadlock. [see also v3.19 commit 18f87a67 ("zfcp: auto port scan resiliency"); v2.6.37 commit d3e1088d ("[SCSI] zfcp: No ERP escalation on gpn_ft eval"); v2.6.28 commit fca55b6f ("[SCSI] zfcp: fix deadlock between wq triggered port scan and ERP") fixing v2.6.27 commit c57a39a4 ("[SCSI] zfcp: wait until adapter is finished with ERP during auto-port"); v2.6.27 commit cc8c2829 ("[SCSI] zfcp: Automatically attach remote ports")] Instead make the accounting of missing SRBs atomic for parallel execution in both the ERP thread and adapter->stat_work. Signed-off-by:
Steffen Maier <maier@linux.ibm.com> Fixes: d26ab06e ("[SCSI] zfcp: receiving an unsolicted status can lead to I/O stall") Cc: <stable@vger.kernel.org> #2.6.27+ Reviewed-by:
Jens Remus <jremus@linux.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Tony Lindgren authored
BugLink: https://bugs.launchpad.net/bugs/1811647 [ Upstream commit e2ca26ec ] With PM enabled, I noticed that pressing a key on the droid4 keyboard will block deeper idle states for the SoC. Let's fix this by using IRQF_ONESHOT and stop constantly toggling the device OMAP4_KBD_IRQENABLE register as suggested by Dmitry Torokhov <dmitry.torokhov@gmail.com>. From the hardware point of view, looks like we need to manage the registers for OMAP4_KBD_IRQENABLE and OMAP4_KBD_WAKEUPENABLE together to avoid blocking deeper SoC idle states. And with toggling of OMAP4_KBD_IRQENABLE register now gone with IRQF_ONESHOT, also the SoC idle state problem is gone during runtime. We still also need to clear OMAP4_KBD_WAKEUPENABLE in omap4_keypad_close() though to pair it with omap4_keypad_open() to prevent blocking deeper SoC idle states after rmmod omap4-keypad. Reported-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Dan Carpenter authored
BugLink: https://bugs.launchpad.net/bugs/1811647 [ Upstream commit 9ae4f842 ] If "interface" is NULL then we can't release it and trying to will only lead to an Oops. Fixes: aea71a02 ("[SCSI] bnx2fc: Introduce interface structure for each vlan interface") Signed-off-by:
-
Benjamin Poirier authored
BugLink: https://bugs.launchpad.net/bugs/1811647 [ Upstream commit ca92e173 ] sadhcnt is reported by `ip -s xfrm state count` as "buckets count", not the hash mask. Fixes: 28d8909b ("[XFRM]: Export SAD info.") Signed-off-by:
Benjamin Poirier <bpoirier@suse.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Qian Cai authored
BugLink: https://bugs.launchpad.net/bugs/1811647 [ Upstream commit f1733a1d ] There is actually a space after "sp," like this, ffff2000080813c8: a9bb7bfd stp x29, x30, [sp, #-80]! Right now, checkstack.pl isn't able to print anything on aarch64, because it won't be able to match the stating objdump line of a function due to this missing space. Hence, it displays every stack as zero-size. After this patch, checkpatch.pl is able to match the start of a function's objdump, and is then able to calculate each function's stack correctly. Link: http://lkml.kernel.org/r/20181207195843.38528-1-cai@lca.pwSigned-off-by:
Qian Cai <cai@lca.pw> Signed-off-by:
-
Peter Hutterer authored
BugLink: https://bugs.launchpad.net/bugs/1811647 [ Upstream commit c201e380 ] ABS_RESERVED was added in d9ca1c99 and accidentally removed as part of ffe0e7cf when the high-resolution scrolling code was removed. Signed-off-by:
Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by:
Martin Kepplinger <martin.kepplinger@ginzinger.com> Acked-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Acked-by:
-
Anson Huang authored
BugLink: https://bugs.launchpad.net/bugs/1811647 [ Upstream commit 1e434b70 ] The sw2iso count should cover ARM LDO ramp-up time, the MAX ARM LDO ramp-up time may be up to more than 100us on some boards, this patch sets sw2iso to 0xf (~384us) which is the reset value, and it is much more safe to cover different boards, since we have observed that some customer boards failed with current setting of 0x2. Fixes: 05136f08 ("ARM: imx: support arm power off in cpuidle for i.mx6sx") Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
-
Paul Mackerras authored
BugLink: https://bugs.launchpad.net/bugs/1811647 [ Upstream commit 5564597d ] Commit 6975a783 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN", 2011-04-12) changed the procedure descriptor at the start of crt0.S to have a hard-coded start address of 0x500000 rather than a reference to _zimage_start, presumably because having a reference to a symbol introduced a relocation which is awkward to handle in a position-independent executable. Unfortunately, what is at 0x500000 in the COFF image is not the first instruction, but the procedure descriptor itself, that is, a word containing 0x500000, which is not a valid instruction. Hence, booting a COFF zImage results in a "DEFAULT CATCH!, code=FFF00700" message from Open Firmware. This fixes the problem by (a) putting the procedure descriptor in the data section and (b) adding a branch to _zimage_start as the first instruction in the program. Fixes: 6975a783 ("powerpc/boot: Allow building the zImage wrapper as a relocatable ET_DYN") Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Lukas Wunner authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 29bdedfd upstream. Commit e82b0b38 ("spi: bcm2835: Fix race on DMA termination") broke the build with COMPILE_TEST=y on arches whose cmpxchg() requires 32-bit operands (xtensa, older arm ISAs). Fix by changing the dma_pending flag's type from bool to unsigned int. Fixes: e82b0b38 ("spi: bcm2835: Fix race on DMA termination") Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
Mark Brown <broonie@kernel.org> Cc: Frank Pavlic <f.pavlic@kunbus.de> Cc: Martin Sperl <kernel@martin.sperl.org> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Signed-off-by:
-
Vitaly Kuznetsov authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit d391f120 upstream. I was investigating an issue with seabios >= 1.10 which stopped working for nested KVM on Hyper-V. The problem appears to be in handle_ept_violation() function: when we do fast mmio we need to skip the instruction so we do kvm_skip_emulated_instruction(). This, however, depends on VM_EXIT_INSTRUCTION_LEN field being set correctly in VMCS. However, this is not the case. Intel's manual doesn't mandate VM_EXIT_INSTRUCTION_LEN to be set when EPT MISCONFIG occurs. While on real hardware it was observed to be set, some hypervisors follow the spec and don't set it; we end up advancing IP with some random value. I checked with Microsoft and they confirmed they don't fill VM_EXIT_INSTRUCTION_LEN on EPT MISCONFIG. Fix the issue by doing instruction skip through emulator when running nested. Fixes: 68c3b4d1Suggested-by:
Radim Krčmář <rkrcmar@redhat.com> Suggested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> [mhaboustak: backport to 4.9.y] Signed-off-by:
Mike Haboustak <haboustak@gmail.com> Signed-off-by:
-
Georgy A Bystrenin authored
BugLink: https://bugs.launchpad.net/bugs/1811647 commit 9a596f5b upstream. While resolving a bug with locks on samba shares found a strange behavior. When a file locked by one node and we trying to lock it from another node it fail with errno 5 (EIO) but in that case errno must be set to (EACCES | EAGAIN). This isn't happening when we try to lock file second time on same node. In this case it returns EACCES as expected. Also this issue not reproduces when we use SMB1 protocol (vers=1.0 in mount options). Further investigation showed that the mapping from status_to_posix_error is different for SMB1 and SMB2+ implementations. For SMB1 mapping is [NT_STATUS_LOCK_NOT_GRANTED to ERRlock] (See fs/cifs/netmisc.c line 66) but for SMB2+ mapping is [STATUS_LOCK_NOT_GRANTED to -EIO] (see fs/cifs/smb2maperror.c line 383) Quick changes in SMB2+ mapping from EIO to EACCES has fixed issue. BUG: https://bugzilla.kernel.org/show_bug.cgi?id=201971Signed-off-by:
Georgy A Bystrenin <gkot@altlinux.org> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
Steve French <stfrench@microsoft.com> Signed-off-by:
-
