aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-12-20perf annotate: Don't throw error for zero length symbolsRavi Bangoria1-1/+2
'perf report --tui' exits with error when it finds a sample of zero length symbol (i.e. addr == sym->start == sym->end). Actually these are valid samples. Don't exit TUI and show report with such symbols. Reported-and-Tested-by: Anton Blanchard <[email protected]> Link: https://lkml.org/lkml/2016/10/8/189 Signed-off-by: Ravi Bangoria <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Chris Riyder <[email protected]> Cc: [email protected] Cc: Masami Hiramatsu <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Paul Mackerras <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: [email protected] # v4.9+ Link: http://lkml.kernel.org/r/1479804050-5028-1-git-send-email-ravi.bangoria@linux.vnet.ibm.com Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-12-20drm/i915: skip the first 4k of stolen memory on everything >= gen8Paulo Zanoni1-3/+2
BSpec got updated and this workaround is now listed as standard required programming for all subsequent projects. This is confirmed to fix Skylake screen flickering issues (probably caused by the fact that we initialized a ring in the first page of stolen, but I didn't 100% confirm this theory). v2: this is the patch that fixes the screen flickering, document it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94605 Cc: [email protected] Tested-by: Dominik Klementowski <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Acked-by: Chris Wilson <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit d43537610470d8829ebd17cd7842f47176e35ebd) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915: Fallback to single PAGE_SIZE segments for DMA remappingChris Wilson1-4/+22
If we at first do not succeed with attempting to remap our physical pages using a coalesced scattergather list, try again with one scattergather entry per page. This should help with swiotlb as it uses a limited buffer size and only searches for contiguous chunks within its buffer aligned up to the next boundary - i.e. we may prematurely cause a failure as we are unable to utilize the unused space between large chunks and trigger an error such as: i915 0000:00:02.0: swiotlb buffer is full (sz: 1630208 bytes) Reported-by: Juergen Gross <[email protected]> Tested-by: Juergen Gross <[email protected]> Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size") Signed-off-by: Chris Wilson <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Imre Deak <[email protected]> Cc: <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]> (cherry picked from commit d766ef53006c2c38a7fe2bef0904105a793383f2) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915: Fix use after free in logical_render_ring_initTvrtko Ursulin1-6/+1
Commit 3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines") introduced the dynanically allocated engine instances and created an potential use after free scenario in logical_render_ring_init where lrc_destroy_wa_ctx_obj could be called after the engine instance has been freed. This can only happen during engine setup/init error handling which luckily does not happen ever in practice. Fix is to not call lrc_destroy_wa_ctx_obj since it would have already been executed from the preceding engine cleanup. Signed-off-by: Tvrtko Ursulin <[email protected]> Reported-by: Dan Carpenter <[email protected]> Fixes: 3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the enabled engines") Cc: Chris Wilson <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit d038fc7e4fff14d6b026130007faef35cbf5e956) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915: disable PSR by default on HSW/BDWPaulo Zanoni1-7/+3
We've been ignoring the poor bugzilla reporters that say PSR causes system lockups and all other sorts of problems. The earliest bug report is from April, so I think we can use the "revert the offending commit if no fixes are presented within 8 months" rule here. Fixes: 9b58e352b463 ("drm/i915: Enable PSR by default on Haswell and Broadwell.") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97602 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97515 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96736 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96704 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96569 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95176 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94985 Cc: <[email protected]> # v4.6+ Cc: Rodrigo Vivi <[email protected]> Cc: Jim Bride <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2ee7dc497e348eecbb82adbb1ea9e9a7e29fe921) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915: Fix setting of boost freq tunableMika Kuoppala1-1/+1
For limiting the max frequency of gpu, the max freq tunable is not enough to hard limit the max gap. We now have also per client boost max freq. When this tunable was introduced, it was mistakenly made read only. Allow user to gain control by setting it writable. Fixes: 29ecd78d3b79 ("drm/i915: Define a separate variable and control for RPS waitboost frequency") Cc: <[email protected]> # v4.9+ Cc: Chris Wilson <[email protected]> Cc: Mika Kuoppala <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Jani Nikula <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 73a798711314b54cbd4fe224e24db92c306a8d8c) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915: tune down the fast link training vs boot failDaniel Vetter1-2/+2
It's been unfixed since a while and no one is immediately working on this. And we have the FIXME already. And now also a task in the DP team's backlog. Cc: Linus Torvalds <[email protected]> Cc: [email protected] Cc: Ville Syrjälä <[email protected]> References: https://lists.freedesktop.org/archives/intel-gfx/2016-July/101951.html Acked-by: Ville Syrjälä <[email protected]> [danvet: Adjust comment per Ville's feedback.] Signed-off-by: Daniel Vetter <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2dd85aeb5bc99e3763dd192cdb95ff405a102c8a) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915: Reorder phys backing storage releaseChris Wilson1-19/+34
In commit a4f5ea64f0a8 ("drm/i915: Refactor object page API"), I reordered the object->pages teardown to be more friendly wrt to a separate obj->mm.lock. However, I overlooked the phys object and left it with a dangling use-after-free of its phys_handle. Move the allocation of the phys handle to get_pages and it release to put_pages to prevent the invalid access and to improve symmetry. v2: Add commentary about always aligning to page size. Testcase: igt/drv_selftest/objects Reported-by: Ville Syrjälä <[email protected]> Fixes: a4f5ea64f0a8 ("drm/i915: Refactor object page API") Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Cc: Joonas Lahtinen <[email protected]> Reviewed-by: Joonas Lahtinen <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit dbb4351bab0a8440f6b02895c142bce6c30b7097) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915/gen9: Fix PCODE polling during SAGV disablingImre Deak1-25/+9
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 <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Chris Wilson <[email protected]> Fixes: 656d1b89e5ff ("drm/i915/skl: Add support for the SAGV, fix underrun hangs") Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Lyude <[email protected]> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit b3b8e99984a4eace91bc097e8f8cec71441cae16) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915/gen9: Fix PCODE polling during CDCLK change notificationImre Deak3-21/+87
commit 848496e5902833600f7992f4faa82dc1546051ba Author: Ville Syrjälä <[email protected]> Date: Wed Jul 13 16:32:03 2016 +0300 drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL increased the timeout to match the spec, but we still see a timeout on at least one SKL. A CDCLK change request following the failed one will succeed nevertheless. I could reproduce this problem easily by running kms_pipe_crc_basic in a loop. In all failure cases _wait_for() was pre-empted for >3ms and so in the worst case - when the pre-emption happened right after calculating timeout__ in _wait_for() - we called skl_cdclk_wait_for_pcu_ready() only once which failed and so _wait_for() timed out. As opposed to this the spec says to keep retrying the request for at most a 3ms period. To fix this send the first request explicitly to guarantee that there is 3ms between the first and last request. Though this matches the spec, I noticed that in rare cases this can still time out if we sent only a few requests (in the worst case 2) _and_ PCODE is busy for some reason even after a previous request and a 3ms delay. To work around this retry the polling with pre-emption disabled to maximize the number of requests. Also increase the timeout to 10ms to account for interrupts that could reduce the number of requests. With this change I couldn't trigger the problem. v2: - Use 1ms poll period instead of 10us. (Chris) v3: - Poll with pre-emption disabled to increase the number of request attempts. (Ville, Chris) - Factor out a helper to poll, it's also needed by the next patch. v4: - Pass reply_mask, reply to skl_pcode_request(), instead of assuming the reply is generic. (Ville) v5: - List the request specific timeout values as code comment. (Ville) v6: - Try the poll first with preemption enabled. - Add code comment about first request being queued by PCODE. (Art) - Add timeout_base_ms argument. (Ville) v7: - Clarify code comment about first queued request. (Chris) Cc: Ville Syrjälä <[email protected]> Cc: Chris Wilson <[email protected]> Cc: Art Runyan <[email protected]> Cc: <[email protected]> # v4.2- : 3b2c171 : drm/i915: Wait up to 3ms Cc: <[email protected]> # v4.2- Fixes: 5d96d8afcfbb ("drm/i915/skl: Deinit/init the display at suspend/resume") Reference: https://bugs.freedesktop.org/show_bug.cgi?id=97929 Testcase: igt/kms_pipe_crc_basic/suspend-read-crc-pipe-B Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit a0b8a1fe34430c3a82258e8cb45f5968bdf31afd) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is settingHans de Goede1-1/+2
Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") Cc: [email protected] Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit b2b45fcd921e864a5e9bbc7aa55dee96d5e11c06) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESETHans de Goede2-5/+11
Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline i915 code was doing the same. That commits effectively swaps the calling of MIPI_SEQ_ASSERT_RESET / MIPI_SEQ_DEASSERT_RESET. Looking at the naming of the sequences that is the right thing to do, but the problem is, that the old mainline code and the ADF code was actually calling the right sequence (tested on a cube iwork8 air tablet), and the swapping of the calling breaks things. This breakage was likely not noticed in testing because on cherrytrail, currently chv_exec_gpio ends up disabling the gpio pins rather then setting them (this is fixed in the next patch in this patch-set). This commit fixes the swapping by fixing MIPI_SEQ_ASSERT/DEASSERT_RESET's places in the enum defining them, so that their (new) names match their actual use. Changes in v2: -Add a comment to the enum explaining that the assert/reassert names are swapped in the spec Fixes: b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences...") Cc: Jani Nikula <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit 2b8208ac93be2783edc627fc02d9ca50cc479923) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from ↵Hans de Goede1-1/+12
vlv_init_display_clock_gating On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by vlv_init_display_clock_gating() clearing the DPOUNIT_CLOCK_GATE_DISABLE bit in DSPCLK_GATE_D when called from chv_pipe_power_well_ops.enable() on driver load, while a pipe is enabled driving the DSI LCD by the BIOS. Clearing this bit while DSI is in use is a known issue and intel_dsi_pre_enable() / intel_dsi_post_disable() already set / clear it as appropriate. This commit modifies vlv_init_display_clock_gating() to leave the DPOUNIT_CLOCK_GATE_DISABLE bit alone fixing the pipe getting stuck. Changes in v2: -Replace PIPE-A with "a pipe" or "the pipe" in the commit msg and comment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97330 Cc: [email protected] Signed-off-by: Hans de Goede <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Ville Syrjälä <[email protected]> (cherry picked from commit 721d484563e1a51ada760089c490cbc47e909756) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20drm/i915: drop the struct_mutex when wedged or trying to resetMatthew Auld1-1/+2
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged or a reset is in progress we bail early but never seem to actually release the lock. Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in display pageflips") Cc: Chris Wilson <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Joonas Lahtinen <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Cc: <[email protected]> # v4.7+ (cherry picked from commit ddbb271aea87fc6004d3c8bcdb0710e980c7ec85) Signed-off-by: Jani Nikula <[email protected]> (cherry picked from commit e411072d5740a49cdc9d0713798c30440757e451) Signed-off-by: Jani Nikula <[email protected]>
2016-12-20brcmfmac: fix uninitialized field in scheduled scan ssid configurationArend Van Spriel1-0/+1
The scheduled scan ssid configuration in firmware has a flags field that was not initialized resulting in unexpected behaviour. Fixes: e3bdb7cc0300 ("brcmfmac: fix handling ssids in .sched_scan_start() callback") Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2016-12-20brcmfmac: fix memory leak in brcmf_cfg80211_attach()Arend Van Spriel1-2/+5
In brcmf_cfg80211_attach() there was one error path not properly handled as it leaked memory allocated in brcmf_btcoex_attach(). Reviewed-by: Hante Meuleman <[email protected]> Reviewed-by: Pieter-Paul Giesberts <[email protected]> Reviewed-by: Franky Lin <[email protected]> Signed-off-by: Arend van Spriel <[email protected]> Signed-off-by: Kalle Valo <[email protected]>
2016-12-20perf bench futex: Fix lock-pi help stringDavidlohr Bueso1-1/+1
Obvious copy/paste typo from the requeue program. Signed-off-by: Davidlohr Bueso <[email protected]> Cc: Davidlohr Bueso <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-12-20perf trace: Check if MAP_32BIT is defined (again)Jiri Olsa1-0/+2
There might be systems where MAP_32BIT is not defined, like some some RHEL7 powerpc versions. Signed-off-by: Jiri Olsa <[email protected]> Cc: David Ahern <[email protected]> Cc: Kyle McMartin <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Peter Zijlstra <[email protected]> Fixes: 256763b01741 ("perf trace beauty mmap: Add more conditional defines") Link: http://lkml.kernel.org/r/[email protected] [ Changed the Fixme cset to the one removing the conditional switch case for MAP_32BIT ] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-12-20samples/bpf: Make perf_event_read() staticArnaldo Carvalho de Melo1-1/+1
While testing Joe's conversion of samples/bpf/ to use tools/lib/bpf/ I noticed some warnings building samples/bpf/ on a Fedora Rawhide container, with clang/llvm 3.9 I noticed this: [root@1e797fdfbf4f linux]# make -j4 O=/tmp/build/linux/ samples/bpf/ make[1]: Entering directory '/tmp/build/linux' CHK include/config/kernel.release GEN ./Makefile CHK include/generated/uapi/linux/version.h Using /git/linux as source for kernel <SNIP> HOSTCC samples/bpf/trace_output_user.o /git/linux/samples/bpf/trace_output_user.c:64:6: warning: no previous prototype for 'perf_event_read' [-Wmissing-prototypes] void perf_event_read(print_fn fn) ^~~~~~~~~~~~~~~ HOSTLD samples/bpf/trace_output make[1]: Leaving directory '/tmp/build/linux' Shut up the compiler by making that function static. Acked-by: Daniel Borkmann <[email protected]> Cc: Alexei Starovoitov <[email protected]> Cc: Joe Stringer <[email protected]> Cc: Wang Nan <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Arnaldo Carvalho de Melo <[email protected]>
2016-12-20mmc: core: Further fix thread wake-upAdrian Hunter1-7/+5
Commit e0097cf5f2f1 ("mmc: queue: Fix queue thread wake-up") did not go far enough. mmc_wait_for_data_req_done() still contains some problems and can be further simplified. First it should not touch context_info->is_waiting_last_req because that is a wake-up control used by the owner of the context. Secondly, it should always return when one of its wake-up conditions is met because, again, that is contolled by the owner of the context. While the current block driver does not have an issue, these problems were exposed during testing of the Software Command Queue patches. Fixes: e0097cf5f2f1 ("mmc: queue: Fix queue thread wake-up") Signed-off-by: Adrian Hunter <[email protected]> Tested-by: Harjani Ritesh <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-12-20mmc: sdhci: Fix to handle MMC_POWER_UNDEFINEDAdrian Hunter1-14/+19
Since commit c2c24819b280 ("mmc: core: Don't power off the card when starting the host"), the power state can still be MMC_POWER_UNDEFINED after mmc_start_host() is called. That can trigger a warning in SDHCI during runtime resume as it tries to restore the I/O state. Handle MMC_POWER_UNDEFINED simply by not updating the I/O state in that case. Fixes: c2c24819b280 ("mmc: core: Don't power off the card when starting the host") Signed-off-by: Adrian Hunter <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-12-20mmc: sdhci-cadence: add Socionext UniPhier specific compatible stringMasahiro Yamada2-2/+5
Add a Socionext SoC specific compatible (suggested by Rob Herring). No SoC specific data are associated with the compatible strings for now, but other SoC vendors may use this IP and want to differentiate IP variants in the future. Signed-off-by: Masahiro Yamada <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-12-20x86/platform/intel/quark: Add printf attribute to imr_self_test_result()Nicolas Iooss1-1/+2
__printf() attributes help detecting issues in printf() format strings at compile time. Even though imr_selftest.c is only compiled with CONFIG_DEBUG_IMR_SELFTEST=y, GCC complains about a missing format attribute when compiling allmodconfig with -Wmissing-format-attribute. Silence this warning by adding the attribute. Signed-off-by: Nicolas Iooss <[email protected]> Acked-by: Bryan O'Donoghue <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-12-20x86/platform/intel-mid: Switch MPU3050 driver to IIOLinus Walleij1-1/+1
The Intel Mid goes in and creates a I2C device for the MPU3050 if the input driver for MPU-3050 is activated. As of commit: 3904b28efb2c ("iio: gyro: Add driver for the MPU-3050 gyroscope") .. there is a proper and fully featured IIO driver for this device, so deprecate the use of the incomplete input driver by augmenting the device population code to react to the presence of the IIO driver's Kconfig symbol instead. Signed-off-by: Linus Walleij <[email protected]> Acked-by: Andy Shevchenko <[email protected]> Cc: Dmitry Torokhov <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-12-20x86/alternatives: Do not use sync_core() to serialize I$Borislav Petkov1-5/+10
We use sync_core() in the alternatives code to stop speculative execution of prefetched instructions because we are potentially changing them and don't want to execute stale bytes. What it does on most machines is call CPUID which is a serializing instruction. And that's expensive. However, the instruction cache is serialized when we're on the local CPU and are changing the data through the same virtual address. So then, we don't need the serializing CPUID but a simple control flow change. Last being accomplished with a CALL/RET which the noinline causes. Suggested-by: Linus Torvalds <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Andy Lutomirski <[email protected]> Cc: Andrew Cooper <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Brian Gerst <[email protected]> Cc: Henrique de Moraes Holschuh <[email protected]> Cc: Matthew Whitehead <[email protected]> Cc: One Thousand Gnomes <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2016-12-20x86/topology: Document cpu_llc_idBorislav Petkov1-0/+9
It means different things on Intel and AMD so write it down so that there's no confusion. Signed-off-by: Borislav Petkov <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Yazen Ghannam <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2016-12-20x86/hyperv: Handle unknown NMIs on one CPU when unknown_nmi_panicVitaly Kuznetsov1-0/+24
There is a feature in Hyper-V ('Debug-VM --InjectNonMaskableInterrupt') which injects NMI to the guest. We may want to crash the guest and do kdump on this NMI by enabling unknown_nmi_panic. To make kdump succeed we need to allow the kdump kernel to re-establish VMBus connection so it will see VMBus devices (storage, network,..). To properly unload VMBus making it possible to start over during kdump we need to do the following: - Send an 'unload' message to the hypervisor. This can be done on any CPU so we do this the crashing CPU. - Receive the 'unload finished' reply message. WS2012R2 delivers this message to the CPU which was used to establish VMBus connection during module load and this CPU may differ from the CPU sending 'unload'. Receiving a VMBus message means the following: - There is a per-CPU slot in memory for one message. This slot can in theory be accessed by any CPU. - We get an interrupt on the CPU when a message was placed into the slot. - When we read the message we need to clear the slot and signal the fact to the hypervisor. In case there are more messages to this CPU pending the hypervisor will deliver the next message. The signaling is done by writing to an MSR so this can only be done on the appropriate CPU. To avoid doing cross-CPU work on crash we have vmbus_wait_for_unload() function which checks message slots for all CPUs in a loop waiting for the 'unload finished' messages. However, there is an issue which arises when these conditions are met: - We're crashing on a CPU which is different from the one which was used to initially contact the hypervisor. - The CPU which was used for the initial contact is blocked with interrupts disabled and there is a message pending in the message slot. In this case we won't be able to read the 'unload finished' message on the crashing CPU. This is reproducible when we receive unknown NMIs on all CPUs simultaneously: the first CPU entering panic() will proceed to crash and all other CPUs will stop themselves with interrupts disabled. The suggested solution is to handle unknown NMIs for Hyper-V guests on the first CPU which gets them only. This will allow us to rely on VMBus interrupt handler being able to receive the 'unload finish' message in case it is delivered to a different CPU. The issue is not reproducible on WS2016 as Debug-VM delivers NMI to the boot CPU only, WS2012R2 and earlier Hyper-V versions are affected. Signed-off-by: Vitaly Kuznetsov <[email protected]> Acked-by: K. Y. Srinivasan <[email protected]> Cc: [email protected] Cc: Haiyang Zhang <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]> Signed-off-by: Ingo Molnar <[email protected]>
2016-12-19NFSv4: Retry the DELEGRETURN if the embedded GETATTR is rejected with EACCESTrond Myklebust2-4/+15
If our DELEGRETURN RPC call is rejected with an EACCES call, then we should remove the GETATTR call from the compound RPC and retry. This could potentially happen when there is a conflict between an ACL denying attribute reads and our use of SP4_MACH_CRED. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Retry the CLOSE if the embedded GETATTR is rejected with EACCESTrond Myklebust1-0/+10
If our CLOSE RPC call is rejected with an EACCES call, then we should remove the GETATTR call from the compound RPC and retry. This could potentially happen when there is a conflict between an ACL denying attribute reads and our use of SP4_MACH_CRED. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFSv4: Place the GETATTR operation before the CLOSETrond Myklebust2-12/+12
In order to benefit from the DENY share lock protection, we should put the GETATTR operation before the CLOSE. Otherwise, we might race with a Windows machine that thinks it is now safe to modify the file. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFSv4: Also ask for attributes when downgrading to a READ-only stateTrond Myklebust1-1/+2
If we're downgrading from a READ+WRITE mode to a READ-only mode, then ask for cache consistency attributes so that we avoid the revalidation in nfs_close_context() Fixes: 3947b74d0f9d ("NFSv4: Don't request a GETATTR on open_downgrade.") Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Don't abuse NFS_INO_REVAL_FORCED in nfs_post_op_update_inode_locked()Trond Myklebust1-7/+0
The NFS_INO_REVAL_FORCED flag now really only has meaning for the case when we've just been handed a delegation for a file that was already cached, and we're unsure about that cache. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19pNFS: Return RW layouts on OPEN_DOWNGRADETrond Myklebust1-3/+13
If the client holds no more writeable open state, and does not hold a write delegation, then send a layoutreturn as part of the OPEN_DOWNGRADE. We do this only for writes, since some layout drivers may require you to also hold a read layout if you are doing a R/W workload. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFSv4: Add encode/decode of the layoutreturn op in OPEN_DOWNGRADETrond Myklebust1-0/+10
While we do not need to return the RW layout when downgrading from a read/write open state to read-only, we might want to do so in order to reduce the burden on the metadataserver so that it does not need to check for changed data when responding to GETATTR requests. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Don't disconnect open-owner on NFS4ERR_BAD_SEQIDNeilBrown1-16/+13
When an NFS4ERR_BAD_SEQID is received the open-owner is removed from the ->state_owners rbtree so that it will no longer be used. If any stateids attached to this open-owner are still in use, and if a request using one gets an NFS4ERR_BAD_STATEID reply, this can for bad. The state is marked as needing recovery and the nfs4_state_manager() is scheduled to clean up. nfs4_state_manager() finds states to be recovered by walking the state_owners rbtree. As the open-owner is not in the rbtree, the bad state is not found so nfs4_state_manager() completes having done nothing. The request is then retried, with a predicatable result (indefinite retries). If the stateid is for a delegation, this open_owner will be used to open files when the delegation is returned. For that to work, a new open-owner needs to be presented to the server. This patch changes NFS4ERR_BAD_SEQID handling to leave the open-owner in the rbtree but updates the 'create_time' so it looks like a new open-owner. With this the indefinite retries no longer happen. Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFSv4: ensure __nfs4_find_lock_state returns consistent result.NeilBrown1-8/+20
If a file has both flock locks and OFD locks, then it is possible that two different nfs4 lock states could apply to file accesses from a single process. It is not possible to know, efficiently, which one is "correct". Presumably the state which represents a lock that covers the region undergoing IO would be the "correct" one to use, but finding that has a non-trivial cost and would provide miniscule value. Currently we just return whichever is first in the list, which could result in inconsistent behaviour if an application ever put it self in this position. As consistent behaviour is preferable (when perfectly correct behaviour is not available), change the search to return a consistent result in this circumstance. Specifically: if there is both a flock and OFD lock state, always return the flock one. Reviewed-by: Jeff Layton <[email protected]> Signed-off-by: NeilBrown <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFSv4.1: nfs4_fl_prepare_ds must be careful about reporting success.NeilBrown1-1/+2
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: c23266d532b4 ("NFS4.1 Fix data server connection race") Signed-off-by: NeilBrown <[email protected]> Acked-by: Olga Kornievskaia <[email protected]> Acked-by: Adamson, Andy <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19pNFS/flexfiles: delete deviceid, don't mark inactiveWeston Andros Adamson2-3/+5
Instead of marking a device inactive, remove it from the cache entirely. Flexfiles has a way to report errors back to the server, so we don't want to stop devices from being tried again for 120 seconds. Signed-off-by: Weston Andros Adamson <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Clean up nfs_attribute_timeout()Trond Myklebust2-8/+7
It can be made static. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Remove unused function nfs_revalidate_inode_rcu()Trond Myklebust2-10/+0
Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Fix and clean up the access cache validity checkingTrond Myklebust1-9/+9
The access cache needs to check whether or not the mode bits, ownership, or ACL has changed or the cache has timed out. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Only look at the change attribute cache state in nfs_weak_revalidate()Trond Myklebust1-2/+3
Just like in nfs_check_verifier(), we want to use nfs_mapping_need_revalidate_inode() to check our knowledge of the change attribute is up to date. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Clean up cache validity checkingTrond Myklebust3-22/+34
Consolidate the open-coded checking of NFS_I(inode)->cache_validity into a couple of helper functions. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFS: Don't revalidate the file on close if we hold a delegationTrond Myklebust1-0/+2
If we're holding a delegation, we can skip sending the close-to-open GETATTR until we're returning that delegation. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFSv4: Don't discard the attributes returned by asynchronous DELEGRETURNTrond Myklebust1-4/+1
DELEGRETURN will always carry a reference to the inode except when the latter is being freed, so let's ensure that we always use that inode information to ensure close-to-open cache consistency, even when the DELEGRETURN call is asynchronous. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19NFSv4: Update the attribute cache info in update_changeattrTrond Myklebust1-1/+8
If we successfully updated the change attribute, we should timestamp the cache. While we do know that the other attributes are not completely up to date, we have the NFS_INO_INVALID_ATTR flag that let us know that, so it is valid to say that the cache has not timed out. We can also clear NFS_INO_REVAL_PAGECACHE, since our change attribute is now known to be valid. Conversely, if the change attribute did not match, we should make sure to also revalidate the access and ACL caches. Signed-off-by: Trond Myklebust <[email protected]>
2016-12-19drm/amdgpu: fix cursor setting of dce6/dce8Flora Cui2-7/+1
Fixes: 7c83d7abc999 ("drm/amdgpu: Only update the CUR_SIZE register when necessary") Signed-off-by: Flora Cui <[email protected]> Reviewed-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2016-12-19ARC: mm: arc700: Don't assume 2 colours for aliasing VIPT dcacheVineet Gupta2-6/+13
An ARC700 customer reported linux boot crashes when upgrading to bigger L1 dcache (64K from 32K). Turns out they had an aliasing VIPT config and current code only assumed 2 colours, while theirs had 4. So default to 4 colours and complain if there are fewer. Ideally this needs to be a Kconfig option, but heck that's too much of hassle for a single user. Cc: [email protected] Signed-off-by: Vineet Gupta <[email protected]>
2016-12-19ARC: mm: No need to save cache version in @cpuinfoVineet Gupta2-12/+5
Historical MMU revisions have been paired with Cache revision updates which are captured in MMU and Cache Build Configuration Registers respectively. This was used in boot code to check for configurations mismatches, speically in simulations (such as running with non existent caches, non pairing MMU and Cache version etc). This can instead be inferred from other cache params such as line size. So remove @ver from post processed @cpuinfo which could be used later to save soem other interesting info. Signed-off-by: Vineet Gupta <[email protected]>
2016-12-19Merge branch 'for_linus' of ↵Linus Torvalds10-161/+152
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs Pull quota, fsnotify and ext2 updates from Jan Kara: "Changes to locking of some quota operations from dedicated quota mutex to s_umount semaphore, a fsnotify fix and a simple ext2 fix" * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs: quota: Fix bogus warning in dquot_disable() fsnotify: Fix possible use-after-free in inode iteration on umount ext2: reject inodes with negative size quota: Remove dqonoff_mutex ocfs2: Use s_umount for quota recovery protection quota: Remove dqonoff_mutex from dquot_scan_active() ocfs2: Protect periodic quota syncing with s_umount semaphore quota: Use s_umount protection for quota operations quota: Hold s_umount in exclusive mode when enabling / disabling quotas fs: Provide function to get superblock with exclusive s_umount
Powered by cgit, Gruvboxed by Blaster4385.