- 26 Jan, 2017 13 commits
-
-
Mel Gorman authored
BugLink: https://bugs.launchpad.net/bugs/1655842 alloc_flags is a bitmask of flags but it is signed which does not necessarily generate the best code depending on the compiler. Even without an impact, it makes more sense that this be unsigned. Signed-off-by:
Mel Gorman <mgorman@techsingularity.net> Acked-by:
Vlastimil Babka <vbabka@suse.cz> Cc: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> (backported from commit c603844b) [cascardo: keep ALLOC_CPUSET at __alloc_pages_nodemask] Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Acked-by:
Brad Figg <brad.figg@canonical.com>
-
Bryant G. Ly authored
BugLink: http://bugs.launchpad.net/bugs/1657194 If srp_transfer_data fails within ibmvscsis_write_pending, then the most likely scenario is that the client timed out the op and removed the TCE mapping. Thus it will loop forever retrying the op that is pretty much guaranteed to fail forever. A better return code would be EIO instead of EAGAIN. Cc: stable@vger.kernel.org Reported-by:
Steven Royer <seroyer@linux.vnet.ibm.com> Tested-by:
Bryant G. Ly <bgly@us.ibm.com> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Bryant G. Ly authored
BugLink: http://bugs.launchpad.net/bugs/1657194 Currently, dma_alloc_coherent is being called with a GFP_KERNEL flag which allows it to sleep in an interrupt context, need to change to GFP_ATOMIC. Cc: stable@vger.kernel.org Tested-by:
Michael Cyr <mikecyr@linux.vnet.ibm.com> Signed-off-by:
Bryant G. Ly <bryantly@linux.vnet.ibm.com> Signed-off-by:
-
Bryant G. Ly authored
BugLink: http://bugs.launchpad.net/bugs/1657194 Current code incorrectly calculates the max transfer length, since it is assuming a 4k page table, but ppc64 all run on 64k page tables. Cc: stable@vger.kernel.org Reported-by:
-
Guilherme G. Piccoli authored
BugLink: http://bugs.launchpad.net/bugs/1656913 Commit 54adc010 ("nvme/quirk: Add a delay before checking for adapter readiness") introduced a quirk to adapters that cannot read the bit NVME_CSTS_RDY right after register NVME_REG_CC is set; these adapters need a delay or else the action of reading the bit NVME_CSTS_RDY could somehow corrupt adapter's registers state and it never recovers. When this quirk was added, we checked ctrl->tagset in order to avoid quirking in probe time, supposing we would never require such delay during probe. Well, it was too optimistic; we in fact need this quirk at probe time in some cases, like after a kexec. In some experiments, after abnormal shutdown of machine (aka power cord unplug), we booted into our bootloader in Power, which is a Linux kernel, and kexec'ed into another distro. If this kexec is too quick, we end up reaching the probe of NVMe adapter in that distro when adapter is in bad state (not fully initialized on our bootloader). What happens next is that nvme_wait_ready() is unable to complete, except if the quirk is enabled. So, this patch removes the original ctrl->tagset verification in order to enable the quirk even on probe time. Fixes: 54adc010 ("nvme/quirk: Add a delay before checking for adapter readiness") Reported-by:
Andrew Byrne <byrneadw@ie.ibm.com> Reported-by:
Jaime A. H. Gomez <jahgomez@mx1.ibm.com> Reported-by:
Zachary D. Myers <zdmyers@us.ibm.com> Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Acked-by:
Jeffrey Lien <Jeff.Lien@wdc.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> (cherry picked from commit b5a10c5f) Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1625318 pci_update_resource() updates a hardware BAR so its address matches the kernel's struct resource UNLESS it's a disabled ROM BAR. We only update those when we enable the ROM. It's not obvious from the code why ROM BARs should be handled specially. Apparently there are Matrox devices with defective ROM BARs that read as zero when disabled. That means that if pci_enable_rom() reads the disabled BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and writes it back, it would enable the ROM at address zero. Add comments and references to explain why we can't make the code look more rational. The code changes are from 755528c8 ("Ignore disabled ROM resources at setup") and 8085ce08 ("[PATCH] Fix PCI ROM mapping"). Link: https://lkml.org/lkml/2005/8/30/138Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> (back ported from commit 0b457dde) Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1625318 Remove the assumption that IORESOURCE_ROM_ENABLE == PCI_ROM_ADDRESS_ENABLE. PCI_ROM_ADDRESS_ENABLE is the ROM enable bit defined by the PCI spec, so if we're reading or writing a BAR register value, that's what we should use. IORESOURCE_ROM_ENABLE is a corresponding bit in struct resource flags. Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1625318 pci_std_update_resource() only deals with standard BARs, so we don't have to worry about the complications of VF BARs in an SR-IOV capability. Compute the BAR address inline and remove pci_resource_bar(). That makes pci_iov_resource_bar() unused, so remove that as well. Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1625318 If we update a VF BAR while it's enabled, there are two potential problems: 1) Any driver that's using the VF has a cached BAR value that is stale after the update, and 2) We can't update 64-bit BARs atomically, so the intermediate state (new lower dword with old upper dword) may conflict with another device, and an access by a driver unrelated to the VF may cause a bus error. Warn about attempts to update VF BARs while they are enabled. This is a programming error, so use dev_WARN() to get a backtrace. Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1625318 Previously pci_update_resource() used the same code path for updating standard BARs and VF BARs in SR-IOV capabilities. Split the VF BAR update into a new pci_iov_update_resource() internal interface, which makes it simpler to compute the BAR address (we can get rid of pci_resource_bar() and pci_iov_resource_bar()). This patch: - Renames pci_update_resource() to pci_std_update_resource(), - Adds pci_iov_update_resource(), - Makes pci_update_resource() a wrapper that calls the appropriate one, No functional change intended. Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1625318 The BAR property bits (0-3 for memory BARs, 0-1 for I/O BARs) are supposed to be read-only, but we do save them in res->flags and include them when updating the BAR. Mask the I/O property bits with ~PCI_BASE_ADDRESS_IO_MASK (0x3) instead of PCI_REGION_FLAG_MASK (0xf) to make it obvious that we can't corrupt bits 2-3 of I/O addresses. Use PCI_ROM_ADDRESS_MASK for ROM BARs. This means we'll only check the top 21 bits (instead of the 28 bits we used to check) of a ROM BAR to see if the update was successful. Signed-off-by:
-
Bjorn Helgaas authored
BugLink: http://bugs.launchpad.net/bugs/1625318 VF BARs are read-only zero, so updating VF BARs will not have any effect. See the SR-IOV spec r1.1, sec 3.4.1.11. We already ignore these updates because of 70675e0b ("PCI: Don't try to restore VF BARs"); this merely restructures it slightly to make it easier to split updates for standard and SR-IOV BARs. Signed-off-by:
-
Gavin Shan authored
BugLink: http://bugs.launchpad.net/bugs/1625318 Previously we enabled VFs and enable their memory space before calling pcibios_sriov_enable(). But pcibios_sriov_enable() may update the VF BARs: for example, on PPC PowerNV we may change them to manage the association of VFs to PEs. Because 64-bit BARs cannot be updated atomically, it's unsafe to update them while they're enabled. The half-updated state may conflict with other devices in the system. Call pcibios_sriov_enable() before enabling the VFs so any BAR updates happen while the VF BARs are disabled. [bhelgaas: changelog] Tested-by:
Carol Soto <clsoto@us.ibm.com> Signed-off-by:
-
- 25 Jan, 2017 3 commits
-
-
Joerg Roedel authored
BugLink: http://bugs.launchpad.net/bugs/1649718 Using the vector stored at interrupt delivery makes the eoi matching safe agains irq migration in the ioapic. Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 4d99ba89) Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
-
Joerg Roedel authored
BugLink: http://bugs.launchpad.net/bugs/1649718 This allows backtracking later in case the rtc irq has been moved to another vcpu/vector. Signed-off-by:
-
Joerg Roedel authored
BugLink: http://bugs.launchpad.net/bugs/1649718 Currently this is a bitmap which tracks which CPUs we expect an EOI from. Move this bitmap to a struct so that we can track additional information there. Signed-off-by:
-
- 20 Jan, 2017 24 commits
-
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1658091Signed-off-by:
Luis Henriques <luis.henriques@canonical.com>
-
Niklas Söderlund authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 5d7400c4 upstream. Always stating PIN_CONFIG_BIAS_DISABLE is supported gives untrue output when examining /sys/kernel/debug/pinctrl/e6060000.pfc/pinconf-pins if the operation get_bias() is implemented but the pin is not handled by the get_bias() implementation. In that case the output will state that "input bias disabled" indicating that this pin has bias control support. Make support for PIN_CONFIG_BIAS_DISABLE depend on that the pin either supports SH_PFC_PIN_CFG_PULL_UP or SH_PFC_PIN_CFG_PULL_DOWN. This also solves the issue where SoC specific implementations print error messages if their particular implementation of {set,get}_bias() is called with a pin it does not know about. Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit fe0f3168 upstream. Make sure to drop any reference taken by bus_find_device() in the sysfs callbacks that are used to create and destroy devices based on device-tree entries. Fixes: 6bccf755 ("[POWERPC] ibmebus: dynamic addition/removal of adapters, some code cleanup") Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 815a7141 upstream. Make sure to drop any reference taken by bus_find_device() when creating devices during init and driver registration. Fixes: 55347cc9 ("[POWERPC] ibmebus: Add device creation and bus probing based on of_device") Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit c090959b upstream. Make sure to drop the reference to the parent device taken by class_find_device() after populating the bus. Fixes: 3b9334ac ("mfd: vexpress: Convert custom func API to regmap") Acked-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit c02ebfdd upstream. Commit 0e87e58b ("blk-mq: improve warning for running a queue on the wrong CPU") attempts to avoid triggering the WARN_ON in __blk_mq_run_hw_queue when the expected CPU is dead. Problem is, in the last batch execution before round robin, blk_mq_hctx_next_cpu can schedule a dead CPU and also update next_cpu to the next alive CPU in the mask, which will trigger the WARN_ON despite the previous workaround. The following patch fixes this scenario by always scheduling the value in hctx->next_cpu. This changes the moment when we round-robin the CPU running the hctx, but it really doesn't matter, since it still executes BLK_MQ_CPU_WORK_BATCH times in a row before switching to another CPU. Fixes: 0e87e58b ("blk-mq: improve warning for running a queue on the wrong CPU") Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Prarit Bhargava authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit a545715d upstream. When removing and adding cpu 0 on a system with GHES NMI the following stack trace is seen when re-adding the cpu: WARNING: CPU: 0 PID: 0 at arch/x86/kernel/apic/apic.c:1349 setup_local_APIC+ Modules linked in: nfsv3 rpcsec_gss_krb5 nfsv4 nfs fscache coretemp intel_ra CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc6+ #2 Call Trace: dump_stack+0x63/0x8e __warn+0xd1/0xf0 warn_slowpath_null+0x1d/0x20 setup_local_APIC+0x275/0x370 apic_ap_setup+0xe/0x20 start_secondary+0x48/0x180 set_init_arg+0x55/0x55 early_idt_handler_array+0x120/0x120 x86_64_start_reservations+0x2a/0x2c x86_64_start_kernel+0x13d/0x14c During the cpu bringup, wakeup_cpu_via_init_nmi() is called and issues an NMI on CPU 0. The GHES NMI handler, ghes_notify_nmi() runs the ghes_proc_irq_work work queue which ends up setting IRQ_WORK_VECTOR (0xf6). The "faulty" IR line set at arch/x86/kernel/apic/apic.c:1349 is also 0xf6 (specifically APIC IRR for irqs 255 to 224 is 0x400000) which confirms that something has set the IRQ_WORK_VECTOR line prior to the APIC being initialized. Commit 2383844d ("GHES: Elliminate double-loop in the NMI handler") incorrectly modified the behavior such that the handler returns NMI_HANDLED only if an error was processed, and incorrectly runs the ghes work queue for every NMI. This patch modifies the ghes_proc_irq_work() to run as it did prior to 2383844d ("GHES: Elliminate double-loop in the NMI handler") by properly returning NMI_HANDLED and only calling the work queue if NMI_HANDLED has been set. Fixes: 2383844d (GHES: Elliminate double-loop in the NMI handler) Signed-off-by:
Prarit Bhargava <prarit@redhat.com> Reviewed-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Tejun Heo authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit ebc4ff66 upstream. cfq_cpd_alloc() which is the cpd_alloc_fn implementation for cfq was incorrectly hard coding GFP_KERNEL instead of using the mask specified through the @gfp parameter. This currently doesn't cause any actual issues because all current callers specify GFP_KERNEL. Fix it. Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Fixes: e4a9bde9 ("blkcg: replace blkcg_policy->cpd_size with ->cpd_alloc/free_fn() methods") Signed-off-by:
-
Denis Kirjanov authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 8a10c06a upstream. With preemption turned on we can read incorrect throttling state while being switched to CPU on a different chip. BUG: using smp_processor_id() in preemptible [00000000] code: cat/7343 caller is .powernv_cpufreq_throttle_check+0x2c/0x710 CPU: 13 PID: 7343 Comm: cat Not tainted 4.8.0-rc5-dirty #1 Call Trace: [c0000007d25b75b0] [c000000000971378] .dump_stack+0xe4/0x150 (unreliable) [c0000007d25b7640] [c0000000005162e4] .check_preemption_disabled+0x134/0x150 [c0000007d25b76e0] [c0000000007b63ac] .powernv_cpufreq_throttle_check+0x2c/0x710 [c0000007d25b7790] [c0000000007b6d18] .powernv_cpufreq_target_index+0x288/0x360 [c0000007d25b7870] [c0000000007acee4] .__cpufreq_driver_target+0x394/0x8c0 [c0000007d25b7920] [c0000000007b22ac] .cpufreq_set+0x7c/0xd0 [c0000007d25b79b0] [c0000000007adf50] .store_scaling_setspeed+0x80/0xc0 [c0000007d25b7a40] [c0000000007ae270] .store+0xa0/0x100 [c0000007d25b7ae0] [c0000000003566e8] .sysfs_kf_write+0x88/0xb0 [c0000007d25b7b70] [c0000000003553b8] .kernfs_fop_write+0x178/0x260 [c0000007d25b7c10] [c0000000002ac3cc] .__vfs_write+0x3c/0x1c0 [c0000007d25b7cf0] [c0000000002ad584] .vfs_write+0xc4/0x230 [c0000007d25b7d90] [c0000000002aeef8] .SyS_write+0x58/0x100 [c0000007d25b7e30] [c00000000000bfec] system_call+0x38/0xfc Fixes: 09a972d1 (cpufreq: powernv: Report cpu frequency throttling) Reviewed-by:
Gautham R. Shenoy <ego@linux.vnet.ibm.com> Signed-off-by:
Denis Kirjanov <kda@linux-powerpc.org> Signed-off-by:
-
NeilBrown authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit cfd278c2 upstream. Various places assume that if nfs4_fl_prepare_ds() turns a non-NULL 'ds', then ds->ds_clp will also be non-NULL. This is not necessasrily true in the case when the process received a fatal signal while nfs4_pnfs_ds_connect is waiting in nfs4_wait_ds_connect(). In that case ->ds_clp may not be set, and the devid may not recently have been marked unavailable. So add a test for ds_clp == NULL and return NULL in that case. Fixes: c23266d5 ("NFS4.1 Fix data server connection race") Signed-off-by:
NeilBrown <neilb@suse.com> Acked-by:
Olga Kornievskaia <aglo@umich.edu> Acked-by:
Adamson, Andy <William.Adamson@netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 79f687a3 upstream. Ben Coddington reports that commit 311324ad, by adding the function nfs_dir_mapping_need_revalidate() that checks page cache validity on each call to nfs_readdir() causes a performance regression when the directory is being modified. If the directory is changing while we're iterating through the directory, POSIX does not require us to invalidate the page cache unless the user calls rewinddir(). However, we still do want to ensure that we use readdirplus in order to avoid a load of stat() calls when the user is doing an 'ls -l' workload. The fix should be to invalidate the page cache immediately when we're setting the NFS_INO_ADVISE_RDPLUS bit. Reported-by:
Benjamin Coddington <bcodding@redhat.com> Fixes: 311324ad ("NFS: Be more aggressive in using readdirplus...") Reviewed-by:
-
Trond Myklebust authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit ee284e35 upstream. We must put the task to sleep while holding the inode->i_lock in order to ensure atomicity with the test for NFS_LAYOUT_RETURN. Fixes: 500d701f ("NFS41: make close wait for layoutreturn") Signed-off-by:
-
Neil Armstrong authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit f24d311f upstream. The pinctrl_gpio_request is called with the "full" gpio number, already containing the base, then meson_pmx_request_gpio is then called with the final pin number. Remove the base addition when calling meson_pmx_disable_other_groups. Fixes: 6ac73095 ("pinctrl: add driver for Amlogic Meson SoCs") CC: Beniamino Galvani <b.galvani@gmail.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
Kevin Hilman <khilman@baylibre.com> Acked-by:
Beniamino Galvani <b.galvani@gmail.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jeff Mahoney authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit aa7c8da3 upstream. In __btrfs_run_delayed_refs, the error path when run_delayed_extent_op fails sets locked_ref->processing = 0 but doesn't re-increment delayed_refs->num_heads_ready. As a result, we end up triggering the WARN_ON in btrfs_select_ref_head. Fixes: d7df2c79 (Btrfs: attach delayed ref updates to delayed ref heads) Reported-by:
Jon Nelson <jnelson-suse@jamponi.net> Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Reviewed-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Jeff Mahoney authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit d0280996 upstream. In __btrfs_run_delayed_refs, when we put back a delayed ref that's too new, we have already dropped the lock on locked_ref when we set ->processing = 0. This patch keeps the lock to cover that assignment. Fixes: d7df2c79 (Btrfs: attach delayed ref updates to delayed ref heads) Signed-off-by:
-
Lukasz Odzioba authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit dd853fd2 upstream. A negative number can be specified in the cmdline which will be used as setup_clear_cpu_cap() argument. With that we can clear/set some bit in memory predceeding boot_cpu_data/cpu_caps_cleared which may cause kernel to misbehave. This patch adds lower bound check to setup_disablecpuid(). Boris Petkov reproduced a crash: [ 1.234575] BUG: unable to handle kernel paging request at ffffffff858bd540 [ 1.236535] IP: memcpy_erms+0x6/0x10 Signed-off-by:
Lukasz Odzioba <lukasz.odzioba@intel.com> Acked-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 030ee7ae upstream. The modem-control signals are managed by the tty-layer during open and should not be asserted prematurely when set_termios is called from driver open. Also make sure that the signals are asserted only when changing speed from B0. Fixes: 664d5df9 ("USB: usb-serial ch341: support for DTR/RTS/CTS") Signed-off-by:
-
Johan Hovold authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit ce5e2928 upstream. Fix reset-resume handling which failed to resubmit the read and interrupt URBs, thereby leaving a port that was open before suspend in a broken state until closed and reopened. Fixes: 1ded7ea4 ("USB: ch341 serial: fix port number changed after resume") Fixes: 2bfd1c96 ("USB: serial: ch341: remove reset_resume callback") Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 8a08403b upstream. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98897 https://bugs.launchpad.net/bugs/1651981Acked-by:
Edward O'Callaghan <funfunctor@folklore1984.net> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Cc: Adrian Fiergolski <A.Fiergolski@gmail.com> Signed-off-by:
-
Zhou Chengming authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 93362fa4 upstream. Fixes CVE-2016-9191, proc_sys_readdir doesn't drop reference added by grab_header when return from !dir_emit_dots path. It can cause any path called unregister_sysctl_table will wait forever. The calltrace of CVE-2016-9191: [ 5535.960522] Call Trace: [ 5535.963265] [<ffffffff817cdaaf>] schedule+0x3f/0xa0 [ 5535.968817] [<ffffffff817d33fb>] schedule_timeout+0x3db/0x6f0 [ 5535.975346] [<ffffffff817cf055>] ? wait_for_completion+0x45/0x130 [ 5535.982256] [<ffffffff817cf0d3>] wait_for_completion+0xc3/0x130 [ 5535.988972] [<ffffffff810d1fd0>] ? wake_up_q+0x80/0x80 [ 5535.994804] [<ffffffff8130de64>] drop_sysctl_table+0xc4/0xe0 [ 5536.001227] [<ffffffff8130de17>] drop_sysctl_table+0x77/0xe0 [ 5536.007648] [<ffffffff8130decd>] unregister_sysctl_table+0x4d/0xa0 [ 5536.014654] [<ffffffff8130deff>] unregister_sysctl_table+0x7f/0xa0 [ 5536.021657] [<ffffffff810f57f5>] unregister_sched_domain_sysctl+0x15/0x40 [ 5536.029344] [<ffffffff810d7704>] partition_sched_domains+0x44/0x450 [ 5536.036447] [<ffffffff817d0761>] ? __mutex_unlock_slowpath+0x111/0x1f0 [ 5536.043844] [<ffffffff81167684>] rebuild_sched_domains_locked+0x64/0xb0 [ 5536.051336] [<ffffffff8116789d>] update_flag+0x11d/0x210 [ 5536.057373] [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450 [ 5536.064186] [<ffffffff81167acb>] ? cpuset_css_offline+0x1b/0x60 [ 5536.070899] [<ffffffff810fce3d>] ? trace_hardirqs_on+0xd/0x10 [ 5536.077420] [<ffffffff817cf61f>] ? mutex_lock_nested+0x2df/0x450 [ 5536.084234] [<ffffffff8115a9f5>] ? css_killed_work_fn+0x25/0x220 [ 5536.091049] [<ffffffff81167ae5>] cpuset_css_offline+0x35/0x60 [ 5536.097571] [<ffffffff8115aa2c>] css_killed_work_fn+0x5c/0x220 [ 5536.104207] [<ffffffff810bc83f>] process_one_work+0x1df/0x710 [ 5536.110736] [<ffffffff810bc7c0>] ? process_one_work+0x160/0x710 [ 5536.117461] [<ffffffff810bce9b>] worker_thread+0x12b/0x4a0 [ 5536.123697] [<ffffffff810bcd70>] ? process_one_work+0x710/0x710 [ 5536.130426] [<ffffffff810c3f7e>] kthread+0xfe/0x120 [ 5536.135991] [<ffffffff817d4baf>] ret_from_fork+0x1f/0x40 [ 5536.142041] [<ffffffff810c3e80>] ? kthread_create_on_node+0x230/0x230 One cgroup maintainer mentioned that "cgroup is trying to offline a cpuset css, which takes place under cgroup_mutex. The offlining ends up trying to drain active usages of a sysctl table which apprently is not happening." The real reason is that proc_sys_readdir doesn't drop reference added by grab_header when return from !dir_emit_dots path. So this cpuset offline path will wait here forever. See here for details: http://www.openwall.com/lists/oss-security/2016/11/04/13 Fixes: f0c3b509 ("[readdir] convert procfs") Reported-by:
CAI Qian <caiqian@redhat.com> Tested-by:
Yang Shukui <yangshukui@huawei.com> Signed-off-by:
Zhou Chengming <zhouchengming1@huawei.com> Acked-by:
Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Signed-off-by:
-
Akinobu Mita authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 802c0388 upstream. The sysrq input handler should be attached to the input device which has a left alt key. On 32-bit kernels, some input devices which has a left alt key cannot attach sysrq handler. Because the keybit bitmap in struct input_device_id for sysrq is not correctly initialized. KEY_LEFTALT is 56 which is greater than BITS_PER_LONG on 32-bit kernels. I found this problem when using a matrix keypad device which defines a KEY_LEFTALT (56) but doesn't have a KEY_O (24 == 56%32). Cc: Jiri Slaby <jslaby@suse.com> Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Acked-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Richard Genoud authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 89d82324 upstream. If we don't disable the transmitter in atmel_stop_tx, the DMA buffer continues to send data until it is emptied. This cause problems with the flow control (CTS is asserted and data are still sent). So, disabling the transmitter in atmel_stop_tx is a sane thing to do. Tested on at91sam9g35-cm(DMA) Tested for regressions on sama5d2-xplained(Fifo) and at91sam9g20ek(PDC) Signed-off-by:
Richard Genoud <richard.genoud@gmail.com> Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Eric W. Biederman authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit 3895dbf8 upstream. Protecting the mountpoint hashtable with namespace_sem was sufficient until a call to umount_mnt was added to mntput_no_expire. At which point it became possible for multiple calls of put_mountpoint on the same hash chain to happen on the same time. Kristen Johansen <kjlx@templeofstupid.com> reported: > This can cause a panic when simultaneous callers of put_mountpoint > attempt to free the same mountpoint. This occurs because some callers > hold the mount_hash_lock, while others hold the namespace lock. Some > even hold both. > > In this submitter's case, the panic manifested itself as a GP fault in > put_mountpoint() when it called hlist_del() and attempted to dereference > a m_hash.pprev that had been poisioned by another thread. Al Viro observed that the simple fix is to switch from using the namespace_sem to the mount_lock to protect the mountpoint hash table. I have taken Al's suggested patch moved put_mountpoint in pivot_root (instead of taking mount_lock an additional time), and have replaced new_mountpoint with get_mountpoint a function that does the hash table lookup and addition under the mount_lock. The introduction of get_mounptoint ensures that only the mount_lock is needed to manipulate the mountpoint hashtable. d_set_mounted is modified to only set DCACHE_MOUNTED if it is not already set. This allows get_mountpoint to use the setting of DCACHE_MOUNTED to ensure adding a struct mountpoint for a dentry happens exactly once. Fixes: ce07d891 ("mnt: Honor MNT_LOCKED when detaching mounts") Reported-by:
Krister Johansen <kjlx@templeofstupid.com> Suggested-by:
-
Augusto Mecking Caringi authored
BugLink: http://bugs.launchpad.net/bugs/1658091 commit c8a6a09c upstream. In ca91cx42_slave_get function, the value pointed by vme_base pointer is set through: *vme_base = ioread32(bridge->base + CA91CX42_VSI_BS[i]); So it must be dereferenced to be used in calculation of pci_base: *pci_base = (dma_addr_t)*vme_base + pci_offset; This bug was caught thanks to the following gcc warning: drivers/vme/bridges/vme_ca91cx42.c: In function ‘ca91cx42_slave_get’: drivers/vme/bridges/vme_ca91cx42.c:467:14: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] *pci_base = (dma_addr_t)vme_base + pci_offset; Signed-off-by:
Augusto Mecking Caringi <augustocaringi@gmail.com> Acked-By:
Martyn Welch <martyn@welchs.me.uk> Signed-off-by:
-
