- 18 Jan, 2017 1 commit
-
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
- 16 Jan, 2017 4 commits
-
-
Thadeu Lima de Souza Cascardo authored
Signed-off-by: -
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1656381 Revert the main part of commit: af42b8d1 ("xen: fix MSI setup and teardown for PV on HVM guests") That commit introduced reading the pci device's msi message data to see if a pirq was previously configured for the device's msi/msix, and re-use that pirq. At the time, that was the correct behavior. However, a later change to Qemu caused it to call into the Xen hypervisor to unmap all pirqs for a pci device, when the pci device disables its MSI/MSIX vectors; specifically the Qemu commit: c976437c7dba9c7444fb41df45468968aaa326ad ("qemu-xen: free all the pirqs for msi/msix when driver unload") Once Qemu added this pirq unmapping, it was no longer correct for the kernel to re-use the pirq number cached in the pci device msi message data. All Qemu releases since 2.1.0 contain the patch that unmaps the pirqs when the pci device disables its MSI/MSIX vectors. This bug is causing failures to initialize multiple NVMe controllers under Xen, because the NVMe driver sets up a single MSIX vector for each controller (concurrently), and then after using that to talk to the controller for some configuration data, it disables the single MSIX vector and re-configures all the MSIX vectors it needs. So the MSIX setup code tries to re-use the cached pirq from the first vector for each controller, but the hypervisor has already given away that pirq to another controller, and its initialization fails. This is discussed in more detail at: https://lists.xen.org/archives/html/xen-devel/2017-01/msg00447.html Fixes: af42b8d1 ("xen: fix MSI setup and teardown for PV on HVM guests") Signed-off-by:
Dan Streetman <dan.streetman@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
-
Dan Streetman authored
BugLink: http://bugs.launchpad.net/bugs/1626894 Revert the following commits from Xenial: 8fb7c1f3 ("UBUNTU: (fix) nvme: only require 1 interrupt vector, not 2+") 96fce9e4 ("UBUNTU: SAUCE: (no-up) NVMe: only setup MSIX once") These commits were added to work around a problem that is actually a bug in the Xen kernel code, which prevented multiple NVMe controllers from initializing in a Xen guest. However, they appear to be causing NVMe controller initialization failures in some (but not all) non-Xen environments. Since they are not needed once the actual Xen bug is fixed, they should be reverted so the non-Xen NVMe initialization works again, and the real Xen bugfix applied. Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Ignore: yes Signed-off-by:
-
- 13 Jan, 2017 1 commit
-
-
John Donnelly authored
Signed-off-by:John Donnelly <john.donnelly@canonical.com>
-
- 10 Jan, 2017 34 commits
-
-
Thomas Huth authored
BugLink: http://bugs.launchpad.net/bugs/1634129 If kvmppc_handle_exit_pr() calls kvmppc_emulate_instruction() to emulate one instruction (in the BOOK3S_INTERRUPT_H_EMUL_ASSIST case), it calls kvmppc_core_queue_program() afterwards if kvmppc_emulate_instruction() returned EMULATE_FAIL, so the guest gets an program interrupt for the illegal opcode. However, the kvmppc_emulate_instruction() also tried to inject a program exception for this already, so the program interrupt gets injected twice and the return address in srr0 gets destroyed. All other callers of kvmppc_emulate_instruction() are also injecting a program interrupt, and since the callers have the right knowledge about the srr1 flags that should be used, it is the function kvmppc_emulate_instruction() that should _not_ inject program interrupts, so remove the kvmppc_core_queue_program() here. This fixes the issue discovered by Laurent Vivier with kvm-unit-tests where the logs are filled with these messages when the test tries to execute an illegal instruction: Couldn't emulate instruction 0x00000000 (op 0 xop 0) kvmppc_handle_exit_pr: emulation at 700 failed (00000000) Signed-off-by:
Thomas Huth <thuth@redhat.com> Reviewed-by:
Alexander Graf <agraf@suse.de> Tested-by:
Laurent Vivier <lvivier@redhat.com> Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> (cherry picked from commit 708e75a3) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1560482 The Physical Core events of the 24x7 PMU can be monitored across various domains (physical core, vcpu home core, vcpu home node etc). For each of these core events, we currently create multiple events in sysfs, one for each domain the event can be monitored in. These events are distinguished by their suffixes like __PHYS_CORE, __VCPU_HOME_CORE etc. Rather than creating multiple such entries, we could let the user specify make 'domain' index a required parameter and let the user specify a value for it (like they currently specify the core index). $ cat /sys/bus/event_source/devices/hv_24x7/events/HPM_CCYC domain=?,offset=0x98,core=?,lpar=0x0 $ perf stat -C 0 -e hv_24x7/HPM_CCYC,domain=2,core=1/ true (the 'domain=?' and 'core=?' in sysfs tell perf tool to enforce them as required parameters). This simplifies the interface and allows users to identify events by the name specified in the catalog (User can determine the domain index by referring to '/sys/bus/event_source/devices/hv_24x7/interface/domains'). Eliminating the event suffix eliminates several functions and simplifies code. Note that Physical Chip events can only be monitored in the chip domain so those events have the domain set to 1 (rather than =?) and users don't need to specify the domain index for the Chip events. $ cat /sys/bus/event_source/devices/hv_24x7/events/PM_XLINK_CYCLES domain=1,offset=0x230,chip=?,lpar=0x0 $ perf stat -C 0 -e hv_24x7/PM_XLINK_CYCLES,chip=1/ true Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit 8f69dc70) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1560482 To help users determine domains, display the domain indices used by the kernel in sysfs. $ cat /sys/bus/event_source/devices/hv_24x7/interface/domains 1: Physical Chip 2: Physical Core 3: VCPU Home Core 4: VCPU Home Chip 5: VCPU Home Node 6: VCPU Remote Node Signed-off-by:
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1560482 For 24x7 counters, perf displays the raw value of the 24x7 counter, which is a monotonically increasing value. perf stat -C 0 -e \ 'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \ sleep 1 Performance counter stats for 'CPU(s) 0': 9,105,403,170 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/ 0.000425751 seconds time elapsed In the typical usage of 'perf stat' this counter value is not as useful as the _change_ in the counter value over the duration of the application. Have h_24x7_event_init() set the event's prev_count to the raw value of the 24x7 counter at the time of initialization. When the application terminates, hv_24x7_event_read() will compute the change in value and report to the perf tool. Similarly, for the transaction interface, clear the event count to 0 at the beginning of the transaction. perf stat -C 0 -e \ 'hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/' \ sleep 1 Performance counter stats for 'CPU(s) 0': 245,758 hv_24x7/HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE,core=1/ 1.006366383 seconds time elapsed Signed-off-by:
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1560482 24x7 counters can belong to different domains (core, chip, virtual CPU etc). For events in the 'chip' domain, sysfs entry currently looks like: $ cd /sys/bus/event_source/devices/hv_24x7/events $ cat PM_XLINK_CYCLES__PHYS_CHIP domain=0x1,offset=0x230,core=?,lpar=0x0 where the required parameter, 'core=?' is specified with perf as: perf stat -C 0 -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,core=1/ \ /bin/true This is inconsistent in that 'core' is a required parameter for a chip event. Instead, have the the sysfs entry display 'chip=?' for chip events: $ cd /sys/bus/event_source/devices/hv_24x7/events $ cat PM_XLINK_CYCLES__PHYS_CHIP domain=0x1,offset=0x230,chip=?,lpar=0x0 We also need to add a 'chip' entry in the sysfs format directory: $ ls /sys/bus/event_source/devices/hv_24x7/format chip core domain lpar offset vcpu ^^^^ (new) so the perf tool can automatically check usage and format the chip parameter correctly: $ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/ \ /bin/true Required parameter 'chip' not specified invalid or unsupported event: 'hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP/' $ perf stat -C 0 -v -e hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/ \ /bin/true hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/: 0 6628908 6628908 Performance counter stats for 'CPU(s) 0': 0 hv_24x7/PM_XLINK_CYCLES__PHYS_CHIP,chip=1/ 0.006606970 seconds time elapsed Signed-off-by:
-
Steven Rostedt (Red Hat) authored
BugLink: http://bugs.launchpad.net/bugs/1655040 With new binutils, gcc may get smart with its optimization and change a jmp from a 5 byte jump to a 2 byte one even though it was jumping to a global function. But that global function existed within a 2 byte radius, and gcc was able to optimize it. Unfortunately, that jump was also being modified when function graph tracing begins. Since ftrace expected that jump to be 5 bytes, but it was only two, it overwrote code after the jump, causing a crash. This was fixed for x86_64 with commit 8329e818, with the same subject as this commit, but nothing was done for x86_32. Cc: stable@vger.kernel.org Fixes: d61f82d0 ("ftrace: use dynamic patching for updating mcount calls") Reported-by:
Steven Rostedt <rostedt@goodmis.org> (cherry picked from commit 847fa1a6) Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
Recent git versions have changed the rename detection to default when using git-diff. Previous behavior would allow the reconstruct script to remove the renamed files, which are added in the diff, but not removed. Using --no-renames option will revert to the previous behavior when using those recent git versions. Signed-off-by:
-
Alastair D'Silva authored
BugLink: http://bugs.launchpad.net/bugs/1651322 This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure to automatically load the vmx_crypto module if the CPU supports it. Signed-off-by:
Alastair D'Silva <alastair@d-silva.org> Acked-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Alastair D'Silva authored
BugLink: http://bugs.launchpad.net/bugs/1651322 This patch provides the necessary infrastructure to allow drivers to be automatically loaded via udev. It implements the minimum required to be able to use module_cpu_feature_match() to trigger the GENERIC_CPU_AUTOPROBE mechanisms. The features exposed are a mirror of the cpu_user_features (converted to an offset from a mask). This decision was made to ensure that the behavior between features for module loading and userspace are consistent. Signed-off-by:
-
Michael Hennerich authored
BugLink: https://bugs.launchpad.net/bugs/1654497 This patch adds the ACPI/PNP ID. The AD5592/3 driver core is already designed around the unified device property API. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> (cherry picked from commit 2cc5b0df) (source: git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git) Signed-off-by:
Shrirang Bagul <shrirang.bagul@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Michael Hennerich authored
BugLink: https://bugs.launchpad.net/bugs/1654497 This patch adds the ACPI/PNP ID. The AD5592/3 driver core is already designed around the unified device property API. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1654602Signed-off-by:
-
WANG Cong authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 205e1e25 upstream. Matt reported that we have a NULL pointer dereference in ppp_pernet() from ppp_connect_channel(), i.e. pch->chan_net is NULL. This is due to that a parallel ppp_unregister_channel() could happen while we are in ppp_connect_channel(), during which pch->chan_net set to NULL. Since we need a reference to net per channel, it makes sense to sync the refcnt with the life time of the channel, therefore we should release this reference when we destroy it. Fixes: 1f461dcd ("ppp: take reference on channels netns") Reported-by:
Matt Bennett <Matt.Bennett@alliedtelesis.co.nz> Cc: Paul Mackerras <paulus@samba.org> Cc: linux-ppp@vger.kernel.org Cc: Guillaume Nault <g.nault@alphalink.fr> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: bmajal222 <bmajal222@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Ming Lei authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit cebf8fd1 upstream. The global mutex of 'gdp_mutex' is used to serialize creating/querying glue dir and its cleanup. Turns out it isn't a perfect way because part(kobj_kset_leave()) of the actual cleanup action() is done inside the release handler of the glue dir kobject. That means gdp_mutex has to be held before releasing the last reference count of the glue dir kobject. This patch moves glue dir's cleanup after kobject_del() in device_del() for avoiding the race. Cc: Yijing Wang <wangyijing@huawei.com> Reported-by:
Chandra Sekhar Lingutla <clingutla@codeaurora.org> Signed-off-by:
Ming Lei <ming.lei@canonical.com> Cc: Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Eric Sandeen authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 6b10b23c upstream. xlog_recover_clear_agi_bucket didn't set the type to XFS_BLFT_AGI_BUF, so we got a warning during log replay (or an ASSERT on a debug build). XFS (md0): Unknown buffer type 0! XFS (md0): _xfs_buf_ioapply: no ops on block 0xaea8802/0x1 Fix this, as was done in f19b872b for 2 other locations with the same problem. Signed-off-by:
Eric Sandeen <sandeen@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
Julien Grall authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 24d5373d upstream. The function xen_guest_init is using __alloc_percpu with an alignment which are not power of two. However, the percpu allocator never supported alignments which are not power of two and has always behaved incorectly in thise case. Commit 3ca45a46 "percpu: ensure requested alignment is power of two" introduced a check which trigger a warning [1] when booting linux-next on Xen. But in reality this bug was always present. This can be fixed by replacing the call to __alloc_percpu with alloc_percpu. The latter will use an alignment which are a power of two. [1] [ 0.023921] illegal size (48) or align (48) for percpu allocation [ 0.024167] ------------[ cut here ]------------ [ 0.024344] WARNING: CPU: 0 PID: 1 at linux/mm/percpu.c:892 pcpu_alloc+0x88/0x6c0 [ 0.024584] Modules linked in: [ 0.024708] [ 0.024804] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-rc7-next-20161128 #473 [ 0.025012] Hardware name: Foundation-v8A (DT) [ 0.025162] task: ffff80003d870000 task.stack: ffff80003d844000 [ 0.025351] PC is at pcpu_alloc+0x88/0x6c0 [ 0.025490] LR is at pcpu_alloc+0x88/0x6c0 [ 0.025624] pc : [<ffff00000818e678>] lr : [<ffff00000818e678>] pstate: 60000045 [ 0.025830] sp : ffff80003d847cd0 [ 0.025946] x29: ffff80003d847cd0 x28: 0000000000000000 [ 0.026147] x27: 0000000000000000 x26: 0000000000000000 [ 0.026348] x25: 0000000000000000 x24: 0000000000000000 [ 0.026549] x23: 0000000000000000 x22: 00000000024000c0 [ 0.026752] x21: ffff000008e97000 x20: 0000000000000000 [ 0.026953] x19: 0000000000000030 x18: 0000000000000010 [ 0.027155] x17: 0000000000000a3f x16: 00000000deadbeef [ 0.027357] x15: 0000000000000006 x14: ffff000088f79c3f [ 0.027573] x13: ffff000008f79c4d x12: 0000000000000041 [ 0.027782] x11: 0000000000000006 x10: 0000000000000042 [ 0.027995] x9 : ffff80003d847a40 x8 : 6f697461636f6c6c [ 0.028208] x7 : 6120757063726570 x6 : ffff000008f79c84 [ 0.028419] x5 : 0000000000000005 x4 : 0000000000000000 [ 0.028628] x3 : 0000000000000000 x2 : 000000000000017f [ 0.028840] x1 : ffff80003d870000 x0 : 0000000000000035 [ 0.029056] [ 0.029152] ---[ end trace 0000000000000000 ]--- [ 0.029297] Call trace: [ 0.029403] Exception stack(0xffff80003d847b00 to 0xffff80003d847c30) [ 0.029621] 7b00: 0000000000000030 0001000000000000 ffff80003d847cd0 ffff00000818e678 [ 0.029901] 7b20: 0000000000000002 0000000000000004 ffff000008f7c060 0000000000000035 [ 0.030153] 7b40: ffff000008f79000 ffff000008c4cd88 ffff80003d847bf0 ffff000008101778 [ 0.030402] 7b60: 0000000000000030 0000000000000000 ffff000008e97000 00000000024000c0 [ 0.030647] 7b80: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.030895] 7ba0: 0000000000000035 ffff80003d870000 000000000000017f 0000000000000000 [ 0.031144] 7bc0: 0000000000000000 0000000000000005 ffff000008f79c84 6120757063726570 [ 0.031394] 7be0: 6f697461636f6c6c ffff80003d847a40 0000000000000042 0000000000000006 [ 0.031643] 7c00: 0000000000000041 ffff000008f79c4d ffff000088f79c3f 0000000000000006 [ 0.031877] 7c20: 00000000deadbeef 0000000000000a3f [ 0.032051] [<ffff00000818e678>] pcpu_alloc+0x88/0x6c0 [ 0.032229] [<ffff00000818ece8>] __alloc_percpu+0x18/0x20 [ 0.032409] [<ffff000008d9606c>] xen_guest_init+0x174/0x2f4 [ 0.032591] [<ffff0000080830f8>] do_one_initcall+0x38/0x130 [ 0.032783] [<ffff000008d90c34>] kernel_init_freeable+0xe0/0x248 [ 0.032995] [<ffff00000899a890>] kernel_init+0x10/0x100 [ 0.033172] [<ffff000008082ec0>] ret_from_fork+0x10/0x50 Reported-by:
Wei Chen <wei.chen@arm.com> Link: https://lkml.org/lkml/2016/11/28/669Signed-off-by:
Julien Grall <julien.grall@arm.com> Signed-off-by:
Stefano Stabellini <sstabellini@kernel.org> Reviewed-by:
-
Boris Ostrovsky authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 30faaafd upstream. Commit 9c17d965 ("xen/gntdev: Grant maps should not be subject to NUMA balancing") set VM_IO flag to prevent grant maps from being subjected to NUMA balancing. It was discovered recently that this flag causes get_user_pages() to always fail with -EFAULT. check_vma_flags __get_user_pages __get_user_pages_locked __get_user_pages_unlocked get_user_pages_fast iov_iter_get_pages dio_refill_pages do_direct_IO do_blockdev_direct_IO do_blockdev_direct_IO ext4_direct_IO_read generic_file_read_iter aio_run_iocb (which can happen if guest's vdisk has direct-io-safe option). To avoid this let's use VM_MIXEDMAP flag instead --- it prevents NUMA balancing just as VM_IO does and has no effect on check_vma_flags(). Reported-by:
Olaf Hering <olaf@aepfle.de> Suggested-by:
Hugh Dickins <hughd@google.com> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Acked-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 1f0f30e4 upstream. tpm_chip_unregister can only be called after tpm_chip_register. devm manages the allocation so no unwind is needed here. Fixes: afb5abc2 ("tpm: two-phase chip management functions") Reviewed-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
-
Douglas Anderson authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 2d13bb64 upstream. We've got a delay loop waiting for secondary CPUs. That loop uses loops_per_jiffy. However, loops_per_jiffy doesn't actually mean how many tight loops make up a jiffy on all architectures. It is quite common to see things like this in the boot log: Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=24000) In my case I was seeing lots of cases where other CPUs timed out entering the debugger only to print their stack crawls shortly after the kdb> prompt was written. Elsewhere in kgdb we already use udelay(), so that should be safe enough to use to implement our timeout. We'll delay 1 ms for 1000 times, which should give us a full second of delay (just like the old code wanted) but allow us to notice that we're done every 1 ms. [akpm@linux-foundation.org: simplifications, per Daniel] Link: http://lkml.kernel.org/r/1477091361-2039-1-git-send-email-dianders@chromium.orgSigned-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Daniel Thompson <daniel.thompson@linaro.org> Cc: Jason Wessel <jason.wessel@windriver.com> Cc: Brian Norris <briannorris@chromium.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Konstantin Khlebnikov authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 4d1f0fb0 upstream. NMI handler doesn't call set_irq_regs(), it's set only by normal IRQ. Thus get_irq_regs() returns NULL or stale registers snapshot with IP/SP pointing to the code interrupted by IRQ which was interrupted by NMI. NULL isn't a problem: in this case watchdog calls dump_stack() and prints full stack trace including NMI. But if we're stuck in IRQ handler then NMI watchlog will print stack trace without IRQ part at all. This patch uses registers snapshot passed into NMI handler as arguments: these registers point exactly to the instruction interrupted by NMI. Fixes: 55537871 ("kernel/watchdog.c: perform all-CPU backtrace in case of hard lockup") Link: http://lkml.kernel.org/r/146771764784.86724.6006627197118544150.stgit@buzzSigned-off-by:
Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Ulrich Obergfell <uobergfe@redhat.com> Cc: Aaron Tomlin <atomlin@redhat.com> Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit e3d240e9 upstream. If maxBuf is not 0 but less than a size of SMB2 lock structure we can end up with a memory corruption. Signed-off-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 4772c795 upstream. Acked-by:
Sachin Prabhu <sprabhu@redhat.com> Signed-off-by:
-
Pavel Shilovsky authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 53e0e11e upstream. We can not unlock/lock cifs_tcp_ses_lock while walking through ses and tcon lists because it can corrupt list iterator pointers and a tcon structure can be released if we don't hold an extra reference. Fix it by moving a reconnect process to a separate delayed work and acquiring a reference to every tcon that needs to be reconnected. Also do not send an echo request on newly established connections. Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 2fc995a8 upstream. When ASoC Intel SST Medfield driver is probed but without codec / card assigned, it causes an Oops and freezes the kernel at suspend/resume, PM: Suspending system (freeze) Suspending console(s) (use no_console_suspend to debug) BUG: unable to handle kernel NULL pointer dereference at 0000000000000018 IP: [<ffffffffc09d9409>] sst_soc_prepare+0x19/0xa0 [snd_soc_sst_mfld_platform] Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 1552 Comm: systemd-sleep Tainted: G W 4.9.0-rc6-1.g5f5c2ad-default #1 Call Trace: [<ffffffffb45318f9>] dpm_prepare+0x209/0x460 [<ffffffffb4531b61>] dpm_suspend_start+0x11/0x60 [<ffffffffb40d3cc2>] suspend_devices_and_enter+0xb2/0x710 [<ffffffffb40d462e>] pm_suspend+0x30e/0x390 [<ffffffffb40d2eba>] state_store+0x8a/0x90 [<ffffffffb43c670f>] kobj_attr_store+0xf/0x20 [<ffffffffb42b0d97>] sysfs_kf_write+0x37/0x40 [<ffffffffb42b02bc>] kernfs_fop_write+0x11c/0x1b0 [<ffffffffb422be68>] __vfs_write+0x28/0x140 [<ffffffffb43728a8>] ? apparmor_file_permission+0x18/0x20 [<ffffffffb433b2ab>] ? security_file_permission+0x3b/0xc0 [<ffffffffb422d095>] vfs_write+0xb5/0x1a0 [<ffffffffb422e3d6>] SyS_write+0x46/0xa0 [<ffffffffb4719fbb>] entry_SYSCALL_64_fastpath+0x1e/0xad Add proper NULL checks in the PM code of mdfld driver. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Acked-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Benjamin Marzinski authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 314c25c5 upstream. In dm_sm_metadata_create() we temporarily change the dm_space_map operations from 'ops' (whose .destroy function deallocates the sm_metadata) to 'bootstrap_ops' (whose .destroy function doesn't). If dm_sm_metadata_create() fails in sm_ll_new_metadata() or sm_ll_extend(), it exits back to dm_tm_create_internal(), which calls dm_sm_destroy() with the intention of freeing the sm_metadata, but it doesn't (because the dm_space_map operations is still set to 'bootstrap_ops'). Fix this by setting the dm_space_map operations back to 'ops' if dm_sm_metadata_create() fails when it is set to 'bootstrap_ops'. Signed-off-by:
Benjamin Marzinski <bmarzins@redhat.com> Acked-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Ondrej Kozina authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 265e9098 upstream. In crypt_set_key(), if a failure occurs while replacing the old key (e.g. tfm->setkey() fails) the key must not have DM_CRYPT_KEY_VALID flag set. Otherwise, the crypto layer would have an invalid key that still has DM_CRYPT_KEY_VALID flag set. Signed-off-by:
Ondrej Kozina <okozina@redhat.com> Reviewed-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Wei Yongjun authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit bff7e067 upstream. Fix to return error code -EINVAL instead of 0, as is done elsewhere in this function. Fixes: e80d1c80 ("dm: do not override error code returned from dm_get_device()") Signed-off-by:
Wei Yongjun <weiyj.lk@gmail.com> Signed-off-by:
-
Bart Van Assche authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit bc27c01b upstream. The meaning of the BLK_MQ_S_STOPPED flag is "do not call .queue_rq()". Hence modify blk_mq_make_request() such that requests are queued instead of issued if a queue has been stopped. Reported-by:
Ming Lei <tom.leiming@gmail.com> Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Felipe Balbi authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit eaa496ff upstream. ep->mult is supposed to be set to Isochronous and Interrupt Endapoint's multiplier value. This value is computed from different places depending on the link speed. If we're dealing with HighSpeed, then it's part of bits [12:11] of wMaxPacketSize. This case wasn't taken into consideration before. While at that, also make sure the ep->mult defaults to one so drivers can use it unconditionally and assume they'll never multiply ep->maxpacket to zero. Cc: <stable@vger.kernel.org> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit f84df2a6 upstream. When the user namespace support was merged the need to prevent ptrace from revealing the contents of an unreadable executable was overlooked. Correct this oversight by ensuring that the executed file or files are in mm->user_ns, by adjusting mm->user_ns. Use the new function privileged_wrt_inode_uidgid to see if the executable is a member of the user namespace, and as such if having CAP_SYS_PTRACE in the user namespace should allow tracing the executable. If not update mm->user_ns to the parent user namespace until an appropriate parent is found. Reported-by:
Jann Horn <jann@thejh.net> Fixes: 9e4a36ec ("userns: Fail exec for suid and sgid binaries with ids outside our user namespace.") Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Aleksa Sarai authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 613cc2b6 upstream. If you have a process that has set itself to be non-dumpable, and it then undergoes exec(2), any CLOEXEC file descriptors it has open are "exposed" during a race window between the dumpable flags of the process being reset for exec(2) and CLOEXEC being applied to the file descriptors. This can be exploited by a process by attempting to access /proc/<pid>/fd/... during this window, without requiring CAP_SYS_PTRACE. The race in question is after set_dumpable has been (for get_link, though the trace is basically the same for readlink): [vfs] -> proc_pid_link_inode_operations.get_link -> proc_pid_get_link -> proc_fd_access_allowed -> ptrace_may_access(task, PTRACE_MODE_READ_FSCREDS); Which will return 0, during the race window and CLOEXEC file descriptors will still be open during this window because do_close_on_exec has not been called yet. As a result, the ordering of these calls should be reversed to avoid this race window. This is of particular concern to container runtimes, where joining a PID namespace with file descriptors referring to the host filesystem can result in security issues (since PRCTL_SET_DUMPABLE doesn't protect against access of CLOEXEC file descriptors -- file descriptors which may reference filesystem objects the container shouldn't have access to). Cc: dev@opencontainers.org Cc: <stable@vger.kernel.org> # v3.2+ Reported-by:
Michael Crosby <crosbymichael@gmail.com> Signed-off-by:
Aleksa Sarai <asarai@suse.de> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Shaohua Li authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 5f33a080 upstream. Our system uses significantly more slab memory with memcg enabled with the latest kernel. With 3.10 kernel, slab uses 2G memory, while with 4.6 kernel, 6G memory is used. The shrinker has problem. Let's see we have two memcg for one shrinker. In do_shrink_slab: 1. Check cg1. nr_deferred = 0, assume total_scan = 700. batch size is 1024, then no memory is freed. nr_deferred = 700 2. Check cg2. nr_deferred = 700. Assume freeable = 20, then total_scan = 10 or 40. Let's assume it's 10. No memory is freed. nr_deferred = 10. The deferred share of cg1 is lost in this case. kswapd will free no memory even run above steps again and again. The fix makes sure one memcg's deferred share isn't lost. Link: http://lkml.kernel.org/r/2414be961b5d25892060315fbb56bb19d81d0c07.1476227351.git.shli@fb.comSigned-off-by:
Shaohua Li <shli@fb.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Michal Hocko <mhocko@kernel.org> Cc: Vladimir Davydov <vdavydov@parallels.com> Signed-off-by:
-
Omar Sandoval authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit b4a567e8 upstream. ->queue_rq() should return one of the BLK_MQ_RQ_QUEUE_* constants, not an errno. Fixes: f4aa4c7b ("block: loop: convert to per-device workqueue") Signed-off-by:
Omar Sandoval <osandov@fb.com> Signed-off-by:
-
Nicolai Stange authored
BugLink: http://bugs.launchpad.net/bugs/1654602 commit 05e6ea26 upstream. The struct file_operations instance serving the f2fs/status debugfs file lacks an initialization of its ->owner. This means that although that file might have been opened, the f2fs module can still get removed. Any further operation on that opened file, releasing included, will cause accesses to unmapped memory. Indeed, Mike Marshall reported the following: BUG: unable to handle kernel paging request at ffffffffa0307430 IP: [<ffffffff8132a224>] full_proxy_release+0x24/0x90 <...> Call Trace: [] __fput+0xdf/0x1d0 [] ____fput+0xe/0x10 [] task_work_run+0x8e/0xc0 [] do_exit+0x2ae/0xae0 [] ? __audit_syscall_entry+0xae/0x100 [] ? syscall_trace_enter+0x1ca/0x310 [] do_group_exit+0x44/0xc0 [] SyS_exit_group+0x14/0x20 [] do_syscall_64+0x61/0x150 [] entry_SYSCALL64_slow_path+0x25/0x25 <...> ---[ end trace f22ae883fa3ea6b8 ]--- Fixing recursive fault but reboot is needed! Fix this by initializing the f2fs/status file_operations' ->owner with THIS_MODULE. This will allow debugfs to grab a reference to the f2fs module upon any open on that file, thus preventing it from getting removed. Fixes: 902829aa ("f2fs: move proc files to debugfs") Reported-by:
Mike Marshall <hubcap@omnibond.com> Reported-by:
Martin Brandenburg <martin@omnibond.com> Signed-off-by:
Nicolai Stange <nicstange@gmail.com> Signed-off-by:
Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by:
-
