- 19 Jan, 2017 40 commits
-
-
Wei Yongjun authored
commit 1d701d3d upstream. Fix to return a negative error code from the st_rproc_state() error handling case instead of 0, as done elsewhere in this function. Fixes: 63edb031 ("remoteproc: Supply controller driver for ST's Remote Processors") Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bjorn Andersson authored
commit 6de1a507 upstream. The tie between the main WCNSS driver and the IRIS driver causes a circular dependency between the two modules. Neither part makes sense to have on their own so lets merge them into one module. For the sake of picking up the clock and regulator resources described in the iris of_node we need an associated struct device. But, to keep the size of the patch down we continue to represent the IRIS part as its own platform_driver, within the same module, rather than setting up a dummy device. Fixes: aed361ad ("remoteproc: qcom: Introduce WCNSS peripheral image loader") Reported-by:
Andreas Färber <afaerber@suse.de> Signed-off-by:
-
Chris Wilson authored
commit cc98e6ce upstream. commit 202b52b7 ("drm: Track drm_mm nodes with an interval tree") introduced a requirement that the special drm_mm.head_node was initialised and marked as not being allocated. It is a very special node that has no side but has a hole that represents the drm_mm address space, and holds the list of nodes. Since it is not a real node, it is not part of the node rbtree and we detect this as it being unallocated. This presumed that drm_mm_init() was initialising it to zero. It happens that i915 kzallocs its objects and so it was accidentally setting it, but for generic use we cannot make that assumption. [ 22.981519] general protection fault: 0000 [#1] SMP [ 22.981521] Modules linked in: test_drm_mm(+) ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac rfcomm bnep snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel dcdbas snd_hda_codec x86_pkg_temp_thermal intel_powerclamp btusb snd_hda_core coretemp crct10dif_pclmul cfg80211 btrtl btbcm btintel bluetooth crc32_pclmul ghash_clmulni_intel aesni_intel snd_pcm i2c_hid aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_timer hid_multitouch snd joydev serio_raw lpc_ich mfd_core i2c_designware_platform i2c_designware_core 8250_dw binfmt_misc soundcore acpi_pad nls_iso8859_1 usbhid hid psmouse ahci libahci [last unloaded: test_drm_mm] [ 22.981544] CPU: 1 PID: 2088 Comm: drm_mm Tainted: G W 4.9.0-rc7+ #234 [ 22.981545] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015 [ 22.981546] task: ffff88020c971cc0 task.stack: ffffc90001728000 [ 22.981547] RIP: 0010:[<ffffffff814050f0>] [<ffffffff814050f0>] drm_mm_interval_tree_add_node+0xa0/0xd0 [ 22.981551] RSP: 0018:ffffc9000172ba98 EFLAGS: 00010202 [ 22.981552] RAX: 0f0000c69cf63d80 RBX: ffff88020be00000 RCX: ffff88020be00000 [ 22.981553] RDX: 0000000000000fff RSI: ffffc9000172bc48 RDI: ffffffff810ac4df [ 22.981553] RBP: ffffc9000172bb08 R08: ffffc9000172bc70 R09: 0000000000000fff [ 22.981554] R10: ffffffff810ac4d7 R11: 4dc04d8b4cffffe5 R12: 0000000000001000 [ 22.981555] R13: ffffc9000172bbd0 R14: ffffc9000172bbe0 R15: 0000000002000000 [ 22.981556] FS: 00007f80c9fab740(0000) GS:ffff88021f480000(0000) knlGS:0000000000000000 [ 22.981557] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 22.981558] CR2: 00007f80c9fd5000 CR3: 000000020c191000 CR4: 00000000003406e0 [ 22.981559] Stack: [ 22.981560] ffffffff81405d09 ffff88020be00000 ffffc9000172bbe0 000000000172bb08 [ 22.981562] ffffffffffffffff 0000000000000000 0000000000000000 0000000000000000 [ 22.981563] 0000000002000000 0000000002000000 ffffffffa02f3000 ffff88020be00000 [ 22.981565] Call Trace: [ 22.981568] [<ffffffff81405d09>] ? drm_mm_insert_node_generic+0x229/0x310 [ 22.981570] [<ffffffffa02f3000>] ? 0xffffffffa02f3000 [ 22.981572] [<ffffffffa02903c1>] __subtest_insert_range.constprop.7+0xd1/0x5b0 [test_drm_mm] [ 22.981575] [<ffffffff81081222>] ? default_wake_function+0x12/0x20 [ 22.981576] [<ffffffff81096905>] ? __wake_up_common+0x55/0x90 [ 22.981578] [<ffffffff81085f42>] ? sched_clock_cpu+0x72/0xa0 [ 22.981581] [<ffffffff811308ad>] ? irq_work_queue+0xd/0x80 [ 22.981582] [<ffffffff810abcc4>] ? wake_up_klogd+0x34/0x40 [ 22.981584] [<ffffffff810ac19d>] ? console_unlock+0x4cd/0x530 [ 22.981585] [<ffffffff810ac4d7>] ? vprintk_emit+0x2d7/0x490 [ 22.981587] [<ffffffff810ac82f>] ? vprintk_default+0x1f/0x30 [ 22.981589] [<ffffffff81146e1c>] ? printk+0x4d/0x4f [ 22.981590] [<ffffffffa02f3000>] ? 0xffffffffa02f3000 [ 22.981592] [<ffffffffa02908b5>] subtest_insert_range+0x15/0x80 [test_drm_mm] [ 22.981594] [<ffffffffa02f3088>] test_drm_mm_init+0x88/0x1000 [test_drm_mm] [ 22.981597] [<ffffffff8100043d>] do_one_initcall+0x3d/0x150 [ 22.981600] [<ffffffff8119dfbf>] ? kfree+0x13f/0x180 [ 22.981602] [<ffffffff811471f2>] do_init_module+0x60/0x1f1 [ 22.981606] [<ffffffff810db878>] load_module+0x2228/0x2790 [ 22.981608] [<ffffffff810d8590>] ? __symbol_put+0x40/0x40 [ 22.981612] [<ffffffff811c52b1>] ? kernel_read+0x41/0x60 [ 22.981614] [<ffffffff810dbfb6>] SYSC_finit_module+0x96/0xd0 [ 22.981617] [<ffffffff810dc00e>] SyS_finit_module+0xe/0x10 [ 22.981620] [<ffffffff816e7aa4>] entry_SYSCALL_64_fastpath+0x17/0x98 [ 22.981622] Code: c7 41 30 00 00 00 00 48 89 e5 48 89 3a 48 c7 c2 20 4e 40 81 e8 b2 a1 f0 ff 5d c3 48 8d 56 78 45 31 d2 48 89 d6 eb 25 48 8b 51 58 <48> 39 50 38 73 04 48 89 50 38 4c 8b 58 28 4c 39 59 48 48 8d 50 [ 22.981651] RIP [<ffffffff814050f0>] drm_mm_interval_tree_add_node+0xa0/0xd0 [ 22.981655] RSP <ffffc9000172ba98> Testcase: igt/drm_mm Fixes: 202b52b7 ("drm: Track drm_mm nodes with an interval tree") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.9-rc1+ Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20161130205126.31106-1-chris@chris-wilson.co.ukSigned-off-by:
-
Ville Syrjälä authored
commit 00b2b728 upstream. Trying to determine the pixel rate of the pipe can't be done until we know the clock, which means it can't be done until the encoder .get_config() hooks have been called. So let's move the min_pixclk[] stuff to the end of intel_modeset_readout_hw_state() when we actually have gathered all the required infromation. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 565602d7 ("drm/i915: Do not acquire crtc state to check clock during modeset, v4.") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161220153902.15621-1-ville.syrjala@linux.intel.comReviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (cherry picked from commit aca1ebf4) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chen-Yu Tsai authored
commit 230c5b44 upstream. In the loop on .timings, we should check .num_timings to see if it's the only mode specified, not .num_modes, which should be used with .modes. Fixes: cda55372 ("drm/panel: simple: Set appropriate mode type") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Arnd Bergmann authored
commit cff52e5f upstream. gcc warns about the timestamp in drm_wait_vblank being possibly used without an initialization: drivers/gpu/drm/drm_irq.c: In function 'drm_crtc_send_vblank_event': drivers/gpu/drm/drm_irq.c:992:24: error: 'now.tv_usec' may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/gpu/drm/drm_irq.c:1069:17: note: 'now.tv_usec' was declared here drivers/gpu/drm/drm_irq.c:991:23: error: 'now.tv_sec' may be used uninitialized in this function [-Werror=maybe-uninitialized] This can happen if drm_vblank_count_and_time() returns 0 in its error path. To sanitize the error case, I'm changing that function to return a zero timestamp when it fails. Fixes: e6ae8687 ("drm: idiot-proof vblank") Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by:
-
Imre Deak authored
commit dccf82ad upstream. According to the previous patch, it's possible atm that we call intel_do_sagv_disable() only once during the 1ms period and time out if that call fails. As opposed to this the spec says that we need to keep retrying this request for a 1ms duration, so let's do this similarly to the CDCLK change notification request. v4-5: - Rebased on the reply_mask, reply change. v6: - Remove w/s change. (Lyude) - Rebased on the timeout_base argument change. Cc: Lyude <cpaul@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Fixes: 656d1b89 ("drm/i915/skl: Add support for the SAGV, fix underrun hangs") Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by: Lyude <lyude@redhat.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1480955258-26311-2-git-send-email-imre.deak@intel.com (cherry picked from commit b3b8e999) Signed-off-by:
-
Russell King authored
commit 7f638c1c upstream. smbus functions return -ve on error, 0 on success. However, __i2c_transfer() have a different return signature - -ve on error, or number of buffers transferred (which may be zero or greater.) The upshot of this is that the sense of the test is reversed when using the mux on a bus supporting the master_xfer method: we cache the value and never retry if we fail to transfer any buffers, but if we succeed, we clear the cached value. Fix this by making pca954x_reg_write() return a negative error code for all failure cases. Fixes: 463e8f84 ("i2c: mux: pca954x: retry updating the mux selection on failure") Acked-by:
Peter Rosin <peda@axentia.se> Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
NeilBrown authored
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
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
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:
-
Wei Yongjun authored
commit f36ab161 upstream. Fix typo in parameter description. Fixes: 5405fc44 ("NFSv4.x: Add kernel parameter to control the callback server") Signed-off-by:
-
Neil Armstrong authored
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
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
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:
-
Guilherme G. Piccoli authored
commit b5a10c5f upstream. 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> Signed-off-by:
-
Lukasz Odzioba authored
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:
Borislav Petkov <bp@suse.de> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: andi.kleen@intel.com Cc: bp@alien8.de Cc: dave.hansen@linux.intel.com Cc: luto@kernel.org Cc: slaoub@gmail.com Fixes: ac72e788 ("x86: add generic clearcpuid=... option") Link: http://lkml.kernel.org/r/1482933340-11857-1-git-send-email-lukasz.odzioba@intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Ricardo Ribalda Delgado authored
commit 701dc207 upstream. On AMD's SB800 and upwards, the SMBus is shared with the Integrated Micro Controller (IMC). The platform provides a hardware semaphore to avoid race conditions among them. (Check page 288 of the SB800-Series Southbridges Register Reference Guide http://support.amd.com/TechDocs/45482.pdf) Without this patch, many access to the SMBus end with an invalid transaction or even with the bus stalled. Reported-by:
Alexandre Desnoyers <alex@qtec.com> Signed-off-by:
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>: Signed-off-by:
-
Daniel Jurgens authored
commit 5e44fca5 upstream. Do not attempt to drain the health workqueue when unloading the device in the recovery flow, this can cause a deadlock when the recovery work tries to cancel itself with sync. Because the work is no longer unconditionally canceled when unloading, it must be explicitly canceled in the AER flow. fixes: 689a248d ("net/mlx5: Cancel recovery work in remove flow") Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Johan Hovold authored
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 <johan@kernel.org> Signed-off-by:
-
Alex Deucher authored
commit 7192c54a upstream. Port of radeon change to amdgpu. Acked-by:
Edward O'Callaghan <funfunctor@folklore1984.net> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Flora Cui authored
commit 5165484b upstream. Use the appropriate smc firmware for each chip revision. Using the wrong one can cause stability issues. Acked-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 8a08403b upstream. fixes: https://bugs.freedesktop.org/show_bug.cgi?id=98897 https://bugs.launchpad.net/bugs/1651981Acked-by:
-
Alex Deucher authored
commit 6458bd4d upstream. Use the appropriate smc firmware for each chip revision. Using the wrong one can cause stability issues. Acked-by:
-
Laurent Pinchart authored
commit aebe55c2 upstream. If waiting for fences fails for blocking commits, planes must be cleaned up before returning. Fixes: f6ce410a ("drm/fence: allow fence waiting to be interrupted by userspace") Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Imre Deak authored
The backport of 2c7d0602 - "Fix PCODE polling during CDCLK change notification" to the 4.9 stable tree used an incorrect timeout value. Fix this up so the backport matches the upstream commit. Reported-by:
Thomas Backlund <tmb@mageia.org> Signed-off-by:
-
Julian Wiedmann authored
commit dc5367bc upstream. With commit e5374399 ("af_iucv: use paged SKBs for big outbound messages"), we transmit paged skbs for both of AF_IUCV's transport modes (IUCV or HiperSockets). The qeth driver for Layer 3 HiperSockets currently doesn't support NETIF_F_SG, so these skbs would just be linearized again by the stack. Avoid that overhead by using paged skbs only for IUCV transport. cc stable, since this also circumvents a significant skb leak when sending large messages (where the skb then needs to be linearized). Signed-off-by:
Julian Wiedmann <jwi@linux.vnet.ibm.com> Signed-off-by:
Ursula Braun <ubraun@linux.vnet.ibm.com> Fixes: e5374399 ("af_iucv: use paged SKBs for big outbound messages") Signed-off-by:
-
Zhou Chengming authored
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:
-
Daniel Jedrychowski authored
commit 2bed8a8e upstream. When in RS485 emulation mode, __do_stop_tx_rs485() calls serial8250_clear_fifos(). This not only clears the FIFOs, but also sets all bits in their control register (UART_FCR) to 0. One of the effects of this is the disabling of the FIFOs, which turns them into single-byte holding registers. The rest of the driver doesn't know this, which results in the lions share of characters passed into a write call to be dropped. (I can supply logic analyzer screenshots if necessary) This fix replaces the serial8250_clear_fifos() call to serial8250_clear_and_reinit_fifos() - this prevents the "dropped characters" issue from manifesting again while retaining the requirement of clearing the RX FIFO after transmission if the SER_RS485_RX_DURING_TX flag is disabled. Signed-off-by:
Daniel Jedrychowski <avistel@gmail.com> Signed-off-by:
-
Pan Bian authored
commit 5b11ebed upstream. Function get_zeroed_page() returns a NULL pointer if there is no enough memory. In function extcon_sync(), it returns 0 if the call to get_zeroed_page() fails. The return value 0 indicates success in the context, which is incosistent with the execution status. This patch fixes the bug by returning -ENOMEM. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=188611Signed-off-by:
Pan Bian <bianpan2016@163.com> Fixes: a580982fAcked-by:
Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by:
-
Akinobu Mita authored
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:
-
Andrew Lutomirski authored
commit 570b90fa upstream. Eric Biggers pointed out that the orinoco driver pointed scatterlists at the stack. Fix it by switching from ahash to shash. The result should be simpler, faster, and more correct. kvalo: cherry picked from commit 1fef293b as I accidentally applied this patch to wireless-drivers-next when I was supposed to apply this wireless-drivers Reported-by:
Eric Biggers <ebiggers3@gmail.com> Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Bryant G. Ly authored
commit 7c9d8d0c upstream. 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. Reported-by:
Steven Royer <seroyer@linux.vnet.ibm.com> Tested-by:
Bryant G. Ly <bgly@us.ibm.com> Signed-off-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Richard Genoud authored
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:
-
Richard Genoud authored
commit b389f173 upstream. When using RS485 in half duplex, RX should be enabled when TX is finished, and stopped when TX starts. Before commit 0058f087 ("tty/serial: atmel: fix RS485 half duplex with DMA"), RX was not disabled in atmel_start_tx() if the DMA was used. So, collisions could happened. But disabling RX in atmel_start_tx() uncovered another bug: RX was enabled again in the wrong place (in atmel_tx_dma) instead of being enabled when TX is finished (in atmel_complete_tx_dma), so the transmission simply stopped. This bug was not triggered before commit 0058f087 ("tty/serial: atmel: fix RS485 half duplex with DMA") because RX was never disabled before. Moving atmel_start_rx() in atmel_complete_tx_dma() corrects the problem. Reported-by:
Gil Weber <webergil@gmail.com> Fixes: 0058f087Tested-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Christoph Hellwig authored
commit a14d749f upstream. Most users of BLOCK_PC requests allocate the sense buffer on the stack, so to avoid DMA to the stack copy them to a field in the heap allocated virtblk_req structure. Without that any attempt at SCSI passthrough I/O, including the SG_IO ioctl from userspace will crash the kernel. Note that this includes running tools like hdparm even when the host does not have SCSI passthrough enabled. Signed-off-by:
Jens Axboe <axboe@fb.com> Signed-off-by:
-
Peter Ujfalusi authored
commit 836c3ce2 upstream. The original patch did not done what it was supposed to be doing and even worst it broke legacy boot (OMAP1). The lch_map size should be the number of available logical channels in sDMA and the od->dma_requests should store the number of available DMA request lines usable in sDMA. In legacy mode we do not have a way to get the DMA request count, in that case we use OMAP_SDMA_REQUESTS (127), despite the fact that OMAP1510 have only 31 DMA request line. Fixes: 2d1a9a94 ("dmaengine: omap-dma: Dynamically allocate memory for lch_map") Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Robin Murphy authored
commit 488debb9 upstream. When borrowing the pfn_valid() check from mmap_kmem(), somebody managed to get physical and virtual addresses spectacularly muddled up, such that we've ended up with checks for one being the other. Whilst this does indeed prevent out-of-bounds accesses crashing, on most systems it also prevents the more desirable use-case of working at all ever. Check the *virtual* offset correctly for what it is. Furthermore, do so in the right place - a read or write may span multiple pages, so a single up-front check is insufficient. High memory accesses already have a similar validity check just before the copy_to_user() call, so just make the low memory path fully consistent with that. Reported-by:
Jason A. Donenfeld <Jason@zx2c4.com> Fixes: 148a1bc8 ("drivers: char: mem: Check {read,write}_kmem() addresses") Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Signed-off-by:
-
Eric W. Biederman authored
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:
-
Andrei Vagin authored
commit add7c65c upstream. ========================================================= [ INFO: possible irq lock inversion dependency detected ] 4.10.0-rc2-00024-g4aecec9-dirty #118 Tainted: G W --------------------------------------------------------- swapper/1/0 just changed the state of lock: (&(&sighand->siglock)->rlock){-.....}, at: [<ffffffffbd0a1bc6>] __lock_task_sighand+0xb6/0x2c0 but this lock took another, HARDIRQ-unsafe lock in the past: (ucounts_lock){+.+...} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Chain exists of: &(&sighand->siglock)->rlock --> &(&tty->ctrl_lock)->rlock --> ucounts_lock Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(ucounts_lock); local_irq_disable(); lock(&(&sighand->siglock)->rlock); lock(&(&tty->ctrl_lock)->rlock); <Interrupt> lock(&(&sighand->siglock)->rlock); *** DEADLOCK *** This patch removes a dependency between rlock and ucount_lock. Fixes: f333c700 ("pidns: Add a limit on the number of pid namespaces") Signed-off-by:
Andrei Vagin <avagin@openvz.org> Acked-by:
-
