Merge fixes from Andrew Morton:
"11 fixes.
The presence of 'thp: reduce indentation level in change_huge_pmd()'
is unfortunate. But the patchset had been decently reviewed and tested
before we decided it was needed in -stable and I felt it best not to
churn things at the last minute"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mailmap: add Martin Kepplinger's email
zsmalloc: expand class bit
zram: do not use copy_page with non-page aligned address
zram: fix operator precedence to get offset
hugetlbfs: fix offset overflow in hugetlbfs mmap
thp: fix MADV_DONTNEED vs clear soft dirty race
thp: fix MADV_DONTNEED vs. MADV_FREE race
mm: drop unused pmdp_huge_get_and_clear_notify()
thp: fix MADV_DONTNEED vs. numa balancing race
thp: reduce indentation level in change_huge_pmd()
z3fold: fix page locking in z3fold_alloc()
Set the partly deprecated companies' email addresses as alias for the
personal one.
Link: http://lkml.kernel.org/r/1491984622-17321-1-git-send-email-martin.kepplinger@ginzinger.com
Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Now 64K page system, zsamlloc has 257 classes so 8 class bit is not
enough. With that, it corrupts the system when zsmalloc stores
65536byte data(ie, index number 256) so that this patch increases class
bit for simple fix for stable backport. We should clean up this mess
soon.
index size
0 32
1 288
..
..
204 52256
256 65536
Fixes: 3783689a1 ("zsmalloc: introduce zspage structure")
Link: http://lkml.kernel.org/r/1492042622-12074-3-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The copy_page is optimized memcpy for page-alinged address. If it is
used with non-page aligned address, it can corrupt memory which means
system corruption. With zram, it can happen with
1. 64K architecture
2. partial IO
3. slub debug
Partial IO need to allocate a page and zram allocates it via kmalloc.
With slub debug, kmalloc(PAGE_SIZE) doesn't return page-size aligned
address. And finally, copy_page(mem, cmem) corrupts memory.
So, this patch changes it to memcpy.
Actuaully, we don't need to change zram_bvec_write part because zsmalloc
returns page-aligned address in case of PAGE_SIZE class but it's not
good to rely on the internal of zsmalloc.
Note:
When this patch is merged to stable, clear_page should be fixed, too.
Unfortunately, recent zram removes it by "same page merge" feature so
it's hard to backport this patch to -stable tree.
I will handle it when I receive the mail from stable tree maintainer to
merge this patch to backport.
Fixes: 42e99bd ("zram: optimize memory operations with clear_page()/copy_page()")
Link: http://lkml.kernel.org/r/1492042622-12074-2-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In zram_rw_page, the logic to get offset is wrong by operator precedence
(i.e., "<<" is higher than "&"). With wrong offset, zram can corrupt
the user's data. This patch fixes it.
Fixes: 8c7f01025 ("zram: implement rw_page operation of zram")
Link: http://lkml.kernel.org/r/1492042622-12074-1-git-send-email-minchan@kernel.org
Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If mmap() maps a file, it can be passed an offset into the file at which
the mapping is to start. Offset could be a negative value when
represented as a loff_t. The offset plus length will be used to update
the file size (i_size) which is also a loff_t.
Validate the value of offset and offset + length to make sure they do
not overflow and appear as negative.
Found by syzcaller with commit ff8c0c53c4 ("mm/hugetlb.c: don't call
region_abort if region_chg fails") applied. Prior to this commit, the
overflow would still occur but we would luckily return ENOMEM.
To reproduce:
mmap(0, 0x2000, 0, 0x40021, 0xffffffffffffffffULL, 0x8000000000000000ULL);
Resulted in,
kernel BUG at mm/hugetlb.c:742!
Call Trace:
hugetlbfs_evict_inode+0x80/0xa0
evict+0x24a/0x620
iput+0x48f/0x8c0
dentry_unlink_inode+0x31f/0x4d0
__dentry_kill+0x292/0x5e0
dput+0x730/0x830
__fput+0x438/0x720
____fput+0x1a/0x20
task_work_run+0xfe/0x180
exit_to_usermode_loop+0x133/0x150
syscall_return_slowpath+0x184/0x1c0
entry_SYSCALL_64_fastpath+0xab/0xad
Fixes: ff8c0c53c4 ("mm/hugetlb.c: don't call region_abort if region_chg fails")
Link: http://lkml.kernel.org/r/1491951118-30678-1-git-send-email-mike.kravetz@oracle.com
Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Yet another instance of the same race.
Fix is identical to change_huge_pmd().
See "thp: fix MADV_DONTNEED vs. numa balancing race" for more details.
Link: http://lkml.kernel.org/r/20170302151034.27829-5-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Both MADV_DONTNEED and MADV_FREE handled with down_read(mmap_sem).
It's critical to not clear pmd intermittently while handling MADV_FREE
to avoid race with MADV_DONTNEED:
CPU0: CPU1:
madvise_free_huge_pmd()
pmdp_huge_get_and_clear_full()
madvise_dontneed()
zap_pmd_range()
pmd_trans_huge(*pmd) == 0 (without ptl)
// skip the pmd
set_pmd_at();
// pmd is re-established
It results in MADV_DONTNEED skipping the pmd, leaving it not cleared.
It violates MADV_DONTNEED interface and can result is userspace
misbehaviour.
Basically it's the same race as with numa balancing in
change_huge_pmd(), but a bit simpler to mitigate: we don't need to
preserve dirty/young flags here due to MADV_FREE functionality.
[kirill.shutemov@linux.intel.com: Urgh... Power is special again]
Link: http://lkml.kernel.org/r/20170303102636.bhd2zhtpds4mt62a@black.fi.intel.com
Link: http://lkml.kernel.org/r/20170302151034.27829-4-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dave noticed that after fixing MADV_DONTNEED vs numa balancing race the
last pmdp_huge_get_and_clear_notify() user is gone.
Let's drop the helper.
Link: http://lkml.kernel.org/r/20170306112047.24809-1-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
In case prot_numa, we are under down_read(mmap_sem). It's critical to
not clear pmd intermittently to avoid race with MADV_DONTNEED which is
also under down_read(mmap_sem):
CPU0: CPU1:
change_huge_pmd(prot_numa=1)
pmdp_huge_get_and_clear_notify()
madvise_dontneed()
zap_pmd_range()
pmd_trans_huge(*pmd) == 0 (without ptl)
// skip the pmd
set_pmd_at();
// pmd is re-established
The race makes MADV_DONTNEED miss the huge pmd and don't clear it
which may break userspace.
Found by code analysis, never saw triggered.
Link: http://lkml.kernel.org/r/20170302151034.27829-3-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Patch series "thp: fix few MADV_DONTNEED races"
For MADV_DONTNEED to work properly with huge pages, it's critical to not
clear pmd intermittently unless you hold down_write(mmap_sem).
Otherwise MADV_DONTNEED can miss the THP which can lead to userspace
breakage.
See example of such race in commit message of patch 2/4.
All these races are found by code inspection. I haven't seen them
triggered. I don't think it's worth to apply them to stable@.
This patch (of 4):
Restructure code in preparation for a fix.
Link: http://lkml.kernel.org/r/20170302151034.27829-2-kirill.shutemov@linux.intel.com
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Stress testing of the current z3fold implementation on a 8-core system
revealed it was possible that a z3fold page deleted from its unbuddied
list in z3fold_alloc() would be put on another unbuddied list by
z3fold_free() while z3fold_alloc() is still processing it. This has
been introduced with commit 5a27aa822 ("z3fold: add kref refcounting")
due to the removal of special handling of a z3fold page not on any list
in z3fold_free().
To fix this, the z3fold page lock should be taken in z3fold_alloc()
before the pool lock is released. To avoid deadlocking, we just try to
lock the page as soon as we get a hold of it, and if trylock fails, we
drop this page and take the next one.
Signed-off-by: Vitaly Wool <vitalywool@gmail.com>
Cc: Dan Streetman <ddstreet@ieee.org>
Cc: <Oleksiy.Avramchenko@sony.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The ia64 build generates many warnings like this:
WARNING: EXPORT symbol "empty_zero_page" [vmlinux] version generation failed, symbol will not be versioned.
Besides adding the necessary header this also requires fiddling with
some explicit .S -> .o rules.
Cc: IA64-ML <linux-ia64@vger.kernel.org>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This fixes a math error calculating the extra_vecs. The error assumed
only 1 cpu per vector, but the value needs to account for the actual
number of cpus per vector in order to get the correct remainder for
extra CPU assignment.
Fixes: 7bf8222b9b ("irq/affinity: Fix CPU spread for unbalanced nodes")
Reported-by: Xiaolong Ye <xiaolong.ye@intel.com>
Signed-off-by: Keith Busch <keith.busch@intel.com>
Link: http://lkml.kernel.org/r/1492104492-19943-1-git-send-email-keith.busch@intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Current codes invoke wrongly nf_ct_netns_get in the destroy routine,
it should use nf_ct_netns_put, not nf_ct_netns_get.
It could cause some modules could not be unloaded.
Fixes: ecb2421b5d ("netfilter: add and use nf_ct_netns_get/put")
Signed-off-by: Gao Feng <fgao@ikuai8.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
This can prevent the nft utility from printing out the auto generated
seed to the user, which is unnecessary and confusing.
Fixes: cb1b69b0b1 ("netfilter: nf_tables: add hash expression")
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
i915_gem_request_alloc() uses error pointers. It never returns NULLs.
Fixes: 0daf0113cf ("drm/i915: Mock infrastructure for request emission")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170413195217.GA26108@mwanda
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.
This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.
This patch is a resend of the original commit id (233ce881dd
"drm/i915: Implement Link Rate fallback on Link training failure")
which got reverted in this commit id (afc1ebf456 Revert
"drm/i915: Implement Link Rate fallback on Link training failure")
due to CI failures.
After investigating the CI failures it was found that these
were essentially the failures which were always there but hidden because
they used to be DRM_DEBUG_KMS messages for link failures so never got
caught by CI. But now this patch actually throws DRM_ERROR if the link
training fails at RBR and 1 lane. So it caught these link train failures.
There were two failures:
1. On SKL 6700k this was because the machine in CI lab is a SKL desktop
without eDP on Port A. But our VBT initialization code in the driver writes
VBT defaults in a way that it always sets DP flag on Port A and this does
not get cleared after parsing the VBT outputs. This has been fixed in
commit id (bb1d132935 "drm/i915/vbt: split out defaults that are set
when there is no VBT) and (665788572c "drm/i915/vbt: don't propagate
errors from intel_bios_init())
2. On ILK-650 desktop - This was happening because of a bad monitor desktop
combination. I switched the monitor in the CI lab and that helped get rid
of the link failures on ILK system.
v10:
* Rebase on drm-tip and resend after revert
v9:
* Use the trimmed max values of link rate/lane count based on
link train fallback (Daniel Vetter)
v8:
* Set link_status to BAD first and then call mode_valid (Jani Nikula)
v7:
Remove the redundant variable in previous patch itself
v6:
* Obtain link rate index from fallback_link_rate using
the helper intel_dp_link_rate_index (Jani Nikula)
* Include fallback within intel_dp_start_link_train (Jani Nikula)
v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)
Acked-by: Tony Cheng <tony.cheng@amd.com>
Acked-by: Harry Wentland <Harry.wentland@amd.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/16ca48b1e74c618929245e9a085b9e3483c3a16d.1491485983.git.jani.nikula@intel.com
Telit LE920A4 uses the same pid 0x1201 of LE920, but modem
implementation is different, since it requires DTR to be set for
answering to qmi messages.
This patch replaces QMI_FIXED_INTF with QMI_QUIRK_SET_DTR: tests on
LE920 have been performed in order to verify backward compatibility.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Revert commit 57707a9a77 (ACPICA: Resources: Not a valid resource if
buffer length too long) as it is reported to prevent the TPM module
from loading on Lenovo X60 with Coreboot.
It also causes new confusing warnings to show up in the kernel log.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=195311
Reported-by: Paul Menzel <pmenzel@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
- Make the Acer Chromebook keyboard work again with the Intel
Cherryview driver.
- Fix a merge error in the Exynos 5433 driver.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJY72FJAAoJEEEQszewGV1zF3sQAKA6RQnoWStOcjfN/oYBkMB1
5oqY6hAVSKy7lEvSkRM4BSDGIA149UoeDcVcRRRcXqTviuHz4bj8Dp5srqkwqtmX
lFxcwvzvQUjt91UGkez6o06fbKqyCldYsTweSACEoiTjFkbaDeEI0phIUDm053bf
RCIOxreOsRJxnPIYPflWV/ylgAe57FNYu2VPmBF9Tl/oqf6YmxtuJ8j9GiDvo4Us
sHof+Ir1Up4fTOAZPkyjtlWERDyiqKbuXa8tGsWXg1niKdHc8aLDa8vnM53+0v4z
3KqcqA8nPzn+K7BQBk5bIJZXASMx03c6BoctYASO5bret9uukTRXy7EuYc9mkY7N
7RG+6BKN39JqZEhVugiU6Qd6LXQqGwz5HNVto4mPKBkg6+LjybZhBu7he2F6ggFt
mdO8xeg25pZMyM3pfsxOBHY9u7AvahndcxB0civZ6OB6hugK+NQCZYRxsq1hMS2v
EmGtFC4z3X0Ju/tnVumELWt0FQfU7sSR7yRhsvZWNcEgR0c/FZmOvsJ7LpAaoB1k
y64/2OFcWBssslgHb4u7x6cEXsf3MWuxTLiUy7+QmVKlAhWDhPVbnA8XZIVvozD4
fSID6zB7nOWw+WqB4aJ594Fo4Zbfw9Rwf9KU9rp3Yl5pYAJs6+w2ZvJP4gniu3LW
MoSuV9P8P7YRmRuck2NL
=Uh95
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.11-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull pin control fixes from Linus Walleij:
"Two pin control fixes arriving late, these are hopefully the last pin
control fixes I send this kernel cycle. A Chromebook and an Exynos SoC
thingie.
The Exynos patch is pretty big, it is fixing unbroken a breakage
caused by yours truly when trying to figure out the merge mess with
the different Samsung platforms for this merge window. Sorry about
that. We have countered this situation by assigning a Samsung pin
control submaintainer to catch stuff earlier.
Summary:
- Make the Acer Chromebook keyboard work again with the Intel
Cherryview driver.
- Fix a merge error in the Exynos 5433 driver"
* tag 'pinctrl-v4.11-5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: cherryview: Add a quirk to make Acer Chromebook keyboard work again
pinctrl: samsung: Add missing part for PINCFG_TYPE_DRV of Exynos5433
Commit ef65aaede2 ("smb2: Enforce sec= mount option") changed the
behavior of a mount command to enforce a specified security mechanism
during mounting. On another hand according to the spec if SMB3 server
doesn't respond with a security context it implies that it supports
NTLMSSP. The current code doesn't keep it in mind and fails a mount
for such servers if no security mechanism is specified. Fix this by
indicating that a server supports NTLMSSP if a security context isn't
returned during negotiate phase. This allows the code to use NTLMSSP
by default for SMB3 mounts.
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <smfrench@gmail.com>
The switch that conditionally sets CPUPOWER_CAP_HAS_TURBO_RATIO and
CPUPOWER_CAP_IS_SNB flags is missing a break, so all cores get both
flags set and an assumed base clock of 100 MHz for turbo values.
Reported-by: GSR <gsr.bugs@infernal-iceberg.com>
Tested-by: GSR <gsr.bugs@infernal-iceberg.com>
References: https://bugs.debian.org/859978
Fixes: 8fb2e440b2 (cpupower: Show Intel turbo ratio support via ...)
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Pull turbostat utility fixes for v4.11 from Len Brown.
* 'turbostat' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
tools/power turbostat: update version number
tools/power turbostat: fix impossibly large CPU%c1 value
tools/power turbostat: turbostat.8 add missing column definitions
tools/power turbostat: update HWP dump to decimal from hex
tools/power turbostat: enable package THERM_INTERRUPT dump
tools/power turbostat: show missing Core and GFX power on SKL and KBL
tools/power turbostat: bugfix: GFXMHz column not changing
Apparently some DP sinks are a little nuts and cause HPD to drop
intermittently during modesets. This happens eg. on an ASUS PB287Q.
In oder to recover from this we can't really use the previous
connector status to determine if the link needs retraining, so let's
just ignore that piece of information and do the retrain
unconditionally. We do of course still check whether the link is
supposed to be running or not.
To actually get read out the EDID and update things properly we
also need to nuke the goto out added by commit 7d23e3c37b
("drm/i915: Cleaning up intel_dp_hpd_pulse"). I'm actually not sure
why that was there. Perhaps to avoid an EDID read if the connector
status didn't appear to change, but that sort of thing is quite racy
and would have failed anyway if we failed to keep up with the
hotplugs (if we missed the HPD down in between two HPD ups). And
now that we take this codepath unconditionally we definitely need
to drop the goto as otherwise we would never do the EDID read.
v2: Drop the goto that made us skip EDID reads entirely. Doh!
v3: Rebase due to locking changes
s/apparely/apparently/ in the comment (Chris)
Cc: stable@vger.kernel.org
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99766
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/119779.html
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170412193017.21029-1-ville.syrjala@linux.intel.com
The wopcm registers are write-once, so any write after the first one
will just be ignored. The registers survive a GPU reset but not
always a suspend/resume cycle, so to keep things simple keep the
writes in the intel_uc_init_hw function instead of moving it earlier
to make sure we attempt them every time we try to load GuC.
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1491524332-23860-1-git-send-email-daniele.ceraolospurio@intel.com
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJY7ulCAAoJEAx081l5xIa+vZ4P+wSZ41DGfCYO/k5Rg+5+QHW6
k7rPj5m0G/lEKJIb23+3p4SktcoQZpaiic6EtTRDeAStseQodaAFypmXs4uyt3Gs
5/RQelGtJD7xHHq4hYbLNaINBeazE3XErZ1AOC1HRxFpq80qJTeO8AbJez0eF8WK
gBi6A6pSzRIHKsqRE7wPertRm1qpdjOB0dl045ZmRD75AP11+OU1oHjcRv0c+cld
vWfItHpp/sDgcXNGJU3UVbjO6VVfkQjIfPxFNIp/prPCr82S+VoS5VEYe7kz1BY4
Nt3tFzfH50vt7nLr/4V0zKyPYnWwe4Y7ATo5WVCY1FFgwuZvvt7jsC5Q10wNkUMU
OjKf7R5hnMkinOuVBmR/Wdgt1aOtwtUD72oF9YHGIVTsGegkcxHxwyhIxNQ538Bx
tMo5rB4oyp74ov9petc8HhE0jAOtUldxzqpS18ogFgdD3+BDSK2Tm46g3vDP1qdk
I8LFA+4Xwx3EseZhWadtTz5RjeWT9MIUqhnsBWFAWiBPJmm0VgS60VouF1p5LZbC
FtoOoGvhnuClmpo4DV/55dzQqbo2Xct6T9no6TSJimN9xN/4T4M0afr0gN5qea+Z
J93zrTy3GkmdBscZOWbEhYSFc4aFX9prDUPSootqNHA7xXywmFNX41y6JBGCfir3
tU7JYihscCK6rW/+RCwz
=A/S/
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-for-v4.11-rc7' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"i915, gvt, nouveau, udl and etnaviv fixes.
I was away the end of last week, so some of these would have been in
rc6, and it's Easter from tomorrow, so I decided I better dequeue what
I have now.
The nouveau changes, just add a hw enable for GP107 display (like a
pci id addition really), and fix a couple of regressions. i915 has
some more gvt fixes, along with a few run of the mill ones, the rcu
one seems like a few people have hit it.
Otherwise a small udl and small etnaviv fix"
* tag 'drm-fixes-for-v4.11-rc7' of git://people.freedesktop.org/~airlied/linux: (22 commits)
drm/etnaviv: fix missing unlock on error in etnaviv_gpu_submit()
drm/udl: Fix unaligned memory access in udl_render_hline
drm/i915: Don't call synchronize_rcu_expedited under struct_mutex
drm/i915: Suspend GuC prior to GPU Reset during GEM suspend
drm/nouveau: initial support (display-only) for GP107
drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane state
drm/nouveau/kms/nv50: fix setting of HeadSetRasterVertBlankDmi method
drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one
drm/nouveau/mpeg: mthd returns true on success now
drm/i915/gvt: set the correct default value of CTX STATUS PTR
drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state
drm/i915: Use a dummy timeline name for a signaled fence
drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
drm/i915/gvt: remove the redundant info NULL check
drm/i915/gvt: adjust mem size for low resolution type
drm/i915: Avoid lock dropping between rescheduling
drm/i915/gvt: exclude cfg space from failsafe mode
drm/i915/gvt: Activate/de-activate vGPU in mdev ops.
drm/i915/execlists: Wrap tail pointer after reset tweaking
drm/i915/perf: remove user triggerable warn
...
This contain a fix for the atomic update support recently added to the
Rockchip driver where the clock reference count would become unbalanced
and result in the clock feeding the PWM to always be disabled.
Another fix to the Intel LPSS driver that adds an update bit quirk
required for a specific configuration.
-----BEGIN PGP SIGNATURE-----
iQJNBAABCAA3FiEEiOrDCAFJzPfAjcif3SOs138+s6EFAljuaUUZHHRoaWVycnku
cmVkaW5nQGdtYWlsLmNvbQAKCRDdI6zXfz6zofCcEACFRVWCoLjrHSrPsr2HhjLU
2nQTSqXKUNdSxfH9vaGdIKcbogdRDxzynolGGIAPAUo0jarJcyUlRoceH6NwwYVp
0nydLks4hPW6G5Q7R9Wu3SX74C1Wlcgzq39TneuRMUZPhcvl0kqxgIeMkaKLzsWv
a4Az/SxAgREhEz6QmjYBhrL2TXsXw7O4Yz/+2tbmA2f1P33P5NRXarrdFGkvXsyu
zH6vuuyCkklb4OIs+SGzGGSd9v95ROTYJJ9kvlsCDI9vkNX2XIfPUZSl+1zdOE/O
BBCyTledF0gjtNpy+B3VXt8lAw0f3YjSD33Nhm7fPTARZetCo75whAQPpbB8+iam
BXnfhtBHx8vliMhjwdbpRn5aRQWxIjTYiRNTaAJKwZUePl2p5dyp/FHVQNZzXyd1
b7gd3ksXCbTkvMx+yuRVbWu8klQli7lGehatRvOqONz7iUI8DImUnUEFaLM1ol0O
YrKetqxAzApjCsKe4bu9Q+9YnbauzLRa+Qu1eaJ0L3n8tWC64o0uNwcwqyW9Ad/f
IGbXIFA0UprOdLdz6LmlRk/e8wuhuyu8iIywM9MQ4X9DfsU+n/ZzeVixXNfWeOtV
dNJ5daaucSZP9pv72Dea0ZWMX02PHv+FNw4P72A0L+Zndu2wJY3OqBfJd5yQNYDh
t9WREGgKCFdBG88ww3cDcQ==
=ftQo
-----END PGP SIGNATURE-----
Merge tag 'pwm/for-4.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm
Pull pwm fixes from Thierry Reding:
"This contain a fix for the atomic update support recently added to
the Rockchip driver where the clock reference count would become
unbalanced and result in the clock feeding the PWM to always be
disabled.
Another fix to the Intel LPSS driver that adds an update bit quirk
required for a specific configuration"
* tag 'pwm/for-4.11-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm:
pwm: rockchip: State of PWM clock should synchronize with PWM enabled state
pwm: lpss: Set enable-bit before waiting for update-bit to go low
pwm: lpss: Split Tangier configuration
Reserving a runtime region results in splitting the EFI memory
descriptors for the runtime region. This results in runtime region
descriptors with bogus memory mappings, leading to interesting crashes
like the following during a kexec:
general protection fault: 0000 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05 09/30/2016
RIP: 0010:virt_efi_set_variable()
...
Call Trace:
efi_delete_dummy_variable()
efi_enter_virtual_mode()
start_kernel()
? set_init_arg()
x86_64_start_reservations()
x86_64_start_kernel()
start_cpu()
...
Kernel panic - not syncing: Fatal exception
Runtime regions will not be freed and do not need to be reserved, so
skip the memmap modification in this case.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk>
Cc: <stable@vger.kernel.org> # v4.9+
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Fixes: 8e80632fb2 ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
Link: http://lkml.kernel.org/r/20170412152719.9779-2-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
As those debug messages might appear in every timer call for scheduler,
it's too noisy, eat too much log and aren't meaningful. So remove them.
Cc: Ping Gao <ping.a.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Commit 10c7e20b2f (ACPI / scan: fix enumeration (visited) flags for
bus rescans) attempted to fix a problem with ACPI-based enumerateion
of I2C/SPI devices, but it forgot to ensure that the visited flag
will be set for all of the other enumerated devices, so fix that.
Fixes: 10c7e20b2f (ACPI / scan: fix enumeration (visited) flags for bus rescans)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=194885
Reported-and-tested-by: Kevin Locke <kevin@kevinlocke.name>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: 4.8+ <stable@vger.kernel.org> # 4.8+
There is a report that after commit 27622b061e ("cpufreq: Convert
to hotplug state machine"), the normal CPU offline/online cycle
fails on some platforms.
According to the ftrace result, this problem was triggered on
platforms using acpi-cpufreq as the default cpufreq driver,
and due to the lack of some ACPI freq method (eg. _PCT),
cpufreq_online() failed and returned a negative value, so the CPU
hotplug state machine rolled back the CPU online process. Actually,
from the user's perspective, the failure of cpufreq_online() should
not prevent that CPU from being brought up, although cpufreq might
not work on that CPU.
BTW, during system startup cpufreq_online() is not invoked via CPU
online but by the cpufreq device creation process, so the APs can be
brought up even though cpufreq_online() fails in that stage.
This patch ignores the return value of cpufreq_online/offline() and
lets the cpufreq framework deal with the failure. cpufreq_online()
itself will do a proper rollback in that case and if _PCT is missing,
the ACPI cpufreq driver will print a warning if the corresponding
debug options have been enabled.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194581
Fixes: 27622b061e ("cpufreq: Convert to hotplug state machine")
Reported-and-tested-by: Tomasz Maciej Nowak <tmn505@gmail.com>
Signed-off-by: Chen Yu <yu.c.chen@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 4.9+ <stable@vger.kernel.org> # 4.9+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Most CPUs do not have a hardware c1 counter,
and so turbostat derives c1 residency:
c1 = TSC - MPERF - other_core_cstate_counters
As it is not possible to atomically read these coutners,
measurement jitter can case this calcuation to "go negative"
when very close to 0. Turbostat detect that case and
simply prints c1 = 0.00%
But that check neglected to account for systems where the TSC
crystal clock domain and the MPERF BCLK domain are differ by
a small amount. That allowed very small negative c1 numbers
to escape this check and be printed as huge positve numbers.
This code begs for a bit of cleanup, but this patch
is the minimal change to fix the issue.
Signed-off-by: Len Brown <len.brown@intel.com>
Add GFX%rc6 and GFXMHz to the column descriptions section
of the turbostat man page.
Signed-off-by: Doug Smythies <dsmythies@telus.net>
Signed-off-by: Len Brown <len.brown@intel.com>
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x00641400 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x884b0800 (25 C)
cpu0: MSR_IA32_PACKAGE_THERM_INTERRUPT: 0x00000003 (100 C, 100 C)
Enable the same per-core output, but hide it behind --debug
because it is too verbose on big systems.
Signed-off-by: Len Brown <len.brown@intel.com>
While the current SDM is silent on the matter, the Core and GFX
RAPL power meters on SKL and KBL appear to work -- so show them.
Reported-by: Yaroslav Isakov <yaroslav.isakov@gmail.com>
Signed-off-by: Len Brown <len.brown@intel.com>
GP107 modesetting support (just recognising the chipset, no other changes until 4.12)
a couple of regression fixes, one of them a rather serious double-free issue that appeared in 4.10.
* 'linux-4.11' of git://github.com/skeggsb/linux:
drm/nouveau: initial support (display-only) for GP107
drm/nouveau/kms/nv50: fix double dma_fence_put() when destroying plane state
drm/nouveau/kms/nv50: fix setting of HeadSetRasterVertBlankDmi method
drm/nouveau/mmu/nv4a: use nv04 mmu rather than the nv44 one
drm/nouveau/mpeg: mthd returns true on success now
drm/i915 fixes for v4.11-rc7
one rcu related fix, and a few GVT fixes.
* tag 'drm-intel-fixes-2017-04-12' of git://anongit.freedesktop.org/git/drm-intel:
drm/i915: Don't call synchronize_rcu_expedited under struct_mutex
drm/i915: Suspend GuC prior to GPU Reset during GEM suspend
drm/i915/gvt: set the correct default value of CTX STATUS PTR
drm/i915/gvt: Fix firmware loading interface for GVT-g golden HW state
drm/i915: Use a dummy timeline name for a signaled fence
drm/i915: Ironlake do_idle_maps w/a may be called w/o struct_mutex
drm/i915/gvt: remove the redundant info NULL check
drm/i915/gvt: adjust mem size for low resolution type
drm/i915: Avoid lock dropping between rescheduling
drm/i915/gvt: exclude cfg space from failsafe mode
drm/i915/gvt: Activate/de-activate vGPU in mdev ops.
drm/i915/execlists: Wrap tail pointer after reset tweaking
drm/i915/perf: remove user triggerable warn
drm/i915/perf: destroy stream on sample_flags mismatch
drm/i915: Align "unfenced" tiled access on gen2, early gen3
Before we rework the "pmem api" to stop abusing __copy_user_nocache()
for memcpy_to_pmem() we need to fix cases where we may strand dirty data
in the cpu cache. The problem occurs when copy_from_iter_pmem() is used
for arbitrary data transfers from userspace. There is no guarantee that
these transfers, performed by dax_iomap_actor(), will have aligned
destinations or aligned transfer lengths. Backstop the usage
__copy_user_nocache() with explicit cache management in these unaligned
cases.
Yes, copy_from_iter_pmem() is now too big for an inline, but addressing
that is saved for a later patch that moves the entirety of the "pmem
api" into the pmem driver directly.
Fixes: 5de490daec ("pmem: add copy_from_iter_pmem() and clear_pmem()")
Cc: <stable@vger.kernel.org>
Cc: <x86@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Matthew Wilcox <mawilcox@microsoft.com>
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
The following warning triggers with a new unit test that stresses the
device-dax interface.
===============================
[ ERR: suspicious RCU usage. ]
4.11.0-rc4+ #1049 Tainted: G O
-------------------------------
./include/linux/rcupdate.h:521 Illegal context switch in RCU read-side critical section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 0
2 locks held by fio/9070:
#0: (&mm->mmap_sem){++++++}, at: [<ffffffff8d0739d7>] __do_page_fault+0x167/0x4f0
#1: (rcu_read_lock){......}, at: [<ffffffffc03fbd02>] dax_dev_huge_fault+0x32/0x620 [dax]
Call Trace:
dump_stack+0x86/0xc3
lockdep_rcu_suspicious+0xd7/0x110
___might_sleep+0xac/0x250
__might_sleep+0x4a/0x80
__alloc_pages_nodemask+0x23a/0x360
alloc_pages_current+0xa1/0x1f0
pte_alloc_one+0x17/0x80
__pte_alloc+0x1e/0x120
__get_locked_pte+0x1bf/0x1d0
insert_pfn.isra.70+0x3a/0x100
? lookup_memtype+0xa6/0xd0
vm_insert_mixed+0x64/0x90
dax_dev_huge_fault+0x520/0x620 [dax]
? dax_dev_huge_fault+0x32/0x620 [dax]
dax_dev_fault+0x10/0x20 [dax]
__do_fault+0x1e/0x140
__handle_mm_fault+0x9af/0x10d0
handle_mm_fault+0x16d/0x370
? handle_mm_fault+0x47/0x370
__do_page_fault+0x28c/0x4f0
trace_do_page_fault+0x58/0x2a0
do_async_page_fault+0x1a/0xa0
async_page_fault+0x28/0x30
Inserting a page table entry may trigger an allocation while we are
holding a read lock to keep the device instance alive for the duration
of the fault. Use srcu for this keep-alive protection.
Fixes: dee4107924 ("/dev/dax, core: file operations and dax-mmap")
Cc: <stable@vger.kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
