Upon a cursory examinination the uid and gid of a fuse request are
necessary for correct operation. Failing a fuse request where those
values are not reliable seems a straight forward and reliable means of
ensuring that fuse requests with bad data are not sent or processed.
In most cases the vfs will avoid actions it suspects will cause
an inode write back of an inode with an invalid uid or gid. But that does
not map precisely to what fuse is doing, so test for this and solve
this at the fuse level as well.
Performing this work in fuse_req_init_context is cheap as the code is
already performing the translation here and only needs to check the
result of the translation to see if things are not representable in
a form the fuse server can handle.
[SzM] Don't zero the context for the nofail case, just keep using the
munging version (makes sense for debugging and doesn't hurt).
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
At the point of fuse_dev_do_read the user space process that initiated the
action on the fuse filesystem may no longer exist. The process have been
killed or may have fired an asynchronous request and exited.
If the initial process has exited, the code "pid_vnr(find_pid_ns(in->h.pid,
fc->pid_ns)" will either return a pid of 0, or in the unlikely event that
the pid has been reallocated it can return practically any pid. Any pid is
possible as the pid allocator allocates pid numbers in different pid
namespaces independently.
The only way to make translation in fuse_dev_do_read reliable is to call
get_pid in fuse_req_init_context, and pid_vnr followed by put_pid in
fuse_dev_do_read. That reference counting in other contexts has been shown
to bounce cache lines between processors and in general be slow. So that
is not desirable.
The only known user of running the fuse server in a different pid namespace
from the filesystem does not care what the pids are in the fuse messages so
removing this code should not matter.
Getting the translation to a server running outside of the pid namespace of
a container can still be achieved by playing setns games at mount time. It
is also possible to add an option to pass a pid namespace into the fuse
filesystem at mount time.
Fixes: 5d6d3a301c ("fuse: allow server to run in different pid_ns")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Currently the userspace has no way of knowing whether the fuse
connection ended because of umount or abort via sysfs. It makes it hard
for filesystems to free the mountpoint after abort without worrying
about removing some new mount.
The patch fixes it by returning different errors when userspace reads
from /dev/fuse (-ENODEV for umount and -ECONNABORTED for abort).
Add a new capability flag FUSE_ABORT_ERROR. If set and the connection is
gone because of sysfs abort, reading from the device will return
-ECONNABORTED.
Signed-off-by: Szymon Lukasz <noh4hss@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fuse has an "atomic_o_trunc" mode, where userspace filesystem uses the
O_TRUNC flag in the OPEN request to truncate the file atomically with the
open.
In this mode there's no need to send a SETATTR request to userspace after
the open, so fuse_do_setattr() checks this mode and returns. But this
misses the important step of truncating the pagecache.
Add the missing parts of truncation to the ATTR_OPEN branch.
Reported-by: Chad Austin <chadaustin@fb.com>
Fixes: 6ff958edbf ("fuse: add atomic open+truncate support")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: <stable@vger.kernel.org>
Pull x86/pti updates from Thomas Gleixner:
"Another set of melted spectrum updates:
- Iron out the last late microcode loading issues by actually
checking whether new microcode is present and preventing the CPU
synchronization to run into a timeout induced hang.
- Remove Skylake C2 from the microcode blacklist according to the
latest Intel documentation
- Fix the VM86 POPF emulation which traps if VIP is set, but VIF is
not. Enhance the selftests to catch that kind of issue
- Annotate indirect calls/jumps for objtool on 32bit. This is not a
functional issue, but for consistency sake its the right thing to
do.
- Fix a jump label build warning observed on SPARC64 which uses 32bit
storage for the code location which is casted to 64 bit pointer w/o
extending it to 64bit first.
- Add two new cpufeature bits. Not really an urgent issue, but
provides them for both x86 and x86/kvm work. No impact on the
current kernel"
* 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/microcode: Fix CPU synchronization routine
x86/microcode: Attempt late loading only when new microcode is present
x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist
jump_label: Fix sparc64 warning
x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels
x86/vm86/32: Fix POPF emulation
selftests/x86/entry_from_vm86: Add test cases for POPF
selftests/x86/entry_from_vm86: Exit with 1 if we fail
x86/cpufeatures: Add Intel PCONFIG cpufeature
x86/cpufeatures: Add Intel Total Memory Encryption cpufeature
Pull x86 fix from Thomas Gleixner:
"A single fix for vmalloc_fault() which uses p*d_huge() unconditionally
whether CONFIG_HUGETLBFS is set or not. In case of CONFIG_HUGETLBFS=n
this results in a crash as p*d_huge() returns 0 in that case"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mm: Fix vmalloc_fault to use pXd_large
Pull irq fixes from Thomas Gleixner:
"Three fixes for irq chip drivers:
- Make sure the allocations in the GIC-V3 ITS driver are large enough
to accomodate the interrupt space
- Fix a misplaced __iomem annotation which causes a splat of 26
sparse warnings
- Remove an unused function in the IMX GPCV2 driver which causes
build warnings"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/irq-imx-gpcv2: Remove unused function
irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis
irqchip/gic-v3-its: Fix misplaced __iomem annotations
Pull EFI fix from Thomas Gleixner:
"A single fix to prevent partially initialized pointers in mixed mode
(64bit kernel on 32bit UEFI)"
* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi/libstub/tpm: Initialize pointer variables to zero for mixed mode
lockups on POWER9.
* ARM: locking fix, reset fix, GICv2 multi-source SGI injection fix,
GICv2-on-v3 MMIO synchronization fix, make the console less verbose.
* x86: fix device passthrough on AMD SME.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJariCQAAoJEL/70l94x66D6j4H/iS51f1EFRjTXbM+/D0BxpOD
hTz3tiV4JNezwXkxm9FMr7e5sfONTsqZodzCeXbz9XRmb6lwkEIbaPC4G2ALJeBH
V1Gpy2NsoBNCaU6Ci7SGqs1PG7wmG1tGMkzgkUoi2mwJRbA7UfnPmL1bTRESc4/w
oYN5xPj1/bLYWnok2cEJevND2VUTy+/dazpm+9gZzHqeoBnRRhhNluLW11A7yi2U
mSxAZrCH8X9EejIEhU8jAah4PYZ9tP8TmvUcnAPYpNgDh2JH6tlkGAYSbpadiCvf
FJNhtev67uDL1jPzqQJLNo5Z04cg06M+9cYqrLD1q287LXsKs+LHXJY/AI56oIM=
=YHkv
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"PPC:
- fix bug leading to lost IPIs and smp_call_function_many() lockups
on POWER9
ARM:
- locking fix
- reset fix
- GICv2 multi-source SGI injection fix
- GICv2-on-v3 MMIO synchronization fix
- make the console less verbose.
x86:
- fix device passthrough on AMD SME"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
KVM: x86: Fix device passthrough when SME is active
kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3
KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid
KVM: arm/arm64: Reduce verbosity of KVM init log
KVM: arm/arm64: Reset mapped IRQs on VM reset
KVM: arm/arm64: Avoid vcpu_load for other vcpu ioctls than KVM_RUN
KVM: arm/arm64: vgic: Add missing irq_lock to vgic_mmio_read_pending
KVM: PPC: Book3S HV: Fix trap number return from __kvmppc_vcore_entry
Just when I had decided that flush_cache_range() was always called with
a valid context, Helge reported two cases where the
"BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd:
kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587!
CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1
Workqueue: events free_ioctx
IAOQ[0]: flush_cache_range+0x164/0x168
IAOQ[1]: flush_cache_page+0x0/0x1c8
RP(r2): unmap_page_range+0xae8/0xb88
Backtrace:
[<00000000404a6980>] unmap_page_range+0xae8/0xb88
[<00000000404a6ae0>] unmap_single_vma+0xc0/0x188
[<00000000404a6cdc>] zap_page_range_single+0x134/0x1f8
[<00000000404a702c>] unmap_mapping_range+0x1cc/0x208
[<0000000040461518>] truncate_pagecache+0x98/0x108
[<0000000040461624>] truncate_setsize+0x9c/0xb8
[<00000000405d7f30>] put_aio_ring_file+0x80/0x100
[<00000000405d803c>] aio_free_ring+0x8c/0x290
[<00000000405d82c0>] free_ioctx+0x80/0x180
[<0000000040284e6c>] process_one_work+0x21c/0x668
[<00000000402854c4>] worker_thread+0x20c/0x778
[<0000000040291d44>] kthread+0x2d4/0x2e0
[<0000000040204020>] end_fault_vector+0x20/0xc0
This indicates that we need to handle the no context case in
flush_cache_range() as we do in flush_cache_mm().
In thinking about this, I realized that we don't need to flush the TLB
when there is no context. So, I added context checks to the large flush
cases in flush_cache_mm() and flush_cache_range(). The large flush case
occurs frequently in flush_cache_mm() and the change should improve fork
performance.
The v2 version of this change removes the BUG_ON from flush_cache_page()
by skipping the TLB flush when there is no context. I also added code
to flush the TLB in flush_cache_mm() and flush_cache_range() when we
have a context that's not current. Now all three routines handle TLB
flushes in a similar manner.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller <deller@gmx.de>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAlqrzY4ACgkQxWXV+ddt
WDtV4BAAiiv5XECNB3lIvcoFjst8E7xIJNeKKzFZh8HNm+L94zP00uqrpHkwQSUv
tk9TGSYgbJJZMhw6I1rwYSKsoTkvP6NVMQZjpkJktWto9NXObKPvJzjKMdB+GYQR
TWGLBaHsMhruMTOewhdVsxA5od5+LravygHaLmTDQmho8jZSSEe0qqpqlakRI9sQ
+VZv1PDEI68IDMKMjOT7de7Ssq9c99BpGNXxvi5fy5kijyfgrs/BUfHBNV5r66MS
y0Yw1Ab+nlLC7cE5Ql24/snDojcLoSl7f5eYt7ib+DAmsJucYQzTfUetFcrYf8IC
EAmFs5Br6pbopi5M1IOxGZABNbr0qMS+zLvoF52cyka32nrmK/IMWl1s8bW0xfva
gxkjouzJDOTMq28asSdyu73i9yFyLB+tEHpojECljo+K5ASzvDad34xqVRlxY6vN
UJm4d76OqTfAyTRo7sQRWfLz/Cb1W+/v0mPotPWHWVyF0bUNsBgX5YKJhma3pU/z
rHwhI/fqg0NTXBcNUMCosEwS2u5vnjIfiOHkDTl1Dv747S/jM0AaNEvpjDo1cOuk
lsl4xKoDkQ6RpBCeFxRCW0wk1Nl/Su6RQ217xTtND+aIa4c6G7A9X8QAjj2XNAuK
CktJJD7wHYSBTu1sQ+u2R/c2QEgkAxABr4NpmWTPCBNlIKEjd4A=
=bXFe
-----END PGP SIGNATURE-----
Merge tag 'for-4.16-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
"There's an important revert in this pull request that needs to go to
stable as it causes a corruption on big endian machines.
The other fix is for FIEMAP incorrectly reporting shared extents
before a sync and one fix for a crash in raid56.
So far we got only one report about the BE corruption, the stable
kernels were out for like a week, so hopefully the scope of the damage
is low"
* tag 'for-4.16-rc5-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
Revert "btrfs: use proper endianness accessors for super_copy"
btrfs: add missing initialization in btrfs_check_shared
btrfs: Fix NULL pointer exception in find_bio_stripe
Emanuel reported an issue with a hang during microcode update because my
dumb idea to use one atomic synchronization variable for both rendezvous
- before and after update - was simply bollocks:
microcode: microcode_reload_late: late_cpus: 4
microcode: __reload_late: cpu 2 entered
microcode: __reload_late: cpu 1 entered
microcode: __reload_late: cpu 3 entered
microcode: __reload_late: cpu 0 entered
microcode: __reload_late: cpu 1 left
microcode: Timeout while waiting for CPUs rendezvous, remaining: 1
CPU1 above would finish, leave and the others will still spin waiting for
it to join.
So do two synchronization atomics instead, which makes the code a lot more
straightforward.
Also, since the update is serialized and it also takes quite some time per
microcode engine, increase the exit timeout by the number of CPUs on the
system.
That's ok because the moment all CPUs are done, that timeout will be cut
short.
Furthermore, panic when some of the CPUs timeout when returning from a
microcode update: we can't allow a system with not all cores updated.
Also, as an optimization, do not do the exit sync if microcode wasn't
updated.
Reported-by: Emanuel Czirai <xftroxgpx@protonmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Emanuel Czirai <xftroxgpx@protonmail.com>
Tested-by: Ashok Raj <ashok.raj@intel.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20180314183615.17629-2-bp@alien8.de
Return UCODE_NEW from the scanning functions to denote that new microcode
was found and only then attempt the expensive synchronization dance.
Reported-by: Emanuel Czirai <xftroxgpx@protonmail.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Emanuel Czirai <xftroxgpx@protonmail.com>
Tested-by: Ashok Raj <ashok.raj@intel.com>
Tested-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lkml.kernel.org/r/20180314183615.17629-1-bp@alien8.de
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJaqzIoAAoJEAx081l5xIa+8NQQAI87FM1TuO8SthUB91dtztk5
zj2BGLp8XKxhZwLxCdax5B8xZrXDR0tcNQZ1/anwMIm8mq3EyJ8XrfSBhz031UHJ
dsDghvGe3ib66NGdqDQ5oFkWGwxJb5t23ze6hIRiEABC5jDCc47pKHaehWCMjcbX
fkwSyQMRePtjXDy5McY3jfL4kwsNvHcWW/ZvCF2veUNsWuowLtbGalsS4DckkiXI
+tbOvxuCY631BkNhoOk9ZaFlXXvgYduSWF7zOYLHmVKngO0AscatuSqOV7d4o5+y
9ZLOSBesuXhizoWaJQhkRN5QK20JebnuOuSpDfJCybaxvdu8fM7QVckjwaSxUW0Q
d+UwxQU1H4k/pi6z76ScPzmdG19ozyCAP16mzL/OfPG4IF2H97vKlV1YIOp1K8X4
/iKgBEm1gCEZFgZyIt8ATTqkMxS2O5Q+emQB7yRrXMOFzDa9z2DhcC5zUyJqKbnd
QoYWzCFDFIRNSgncH7CSmwBIK40H31I1sGtH6UOMbE8p8zh7bWVCssHU2IytBY1d
xd97F7uPjSDDW8ASakRcEot2vuMJvgvsJJd3cZkbrwZ5hCON1eRAeWxowKTP6r5H
sSm4bdMjFSPKORQP+oMzKBfmBPn1ZOtsVMOkMPsS2DrVzx6f8QmL0GYHWNYhqXNy
powhJPt4kyssA0i3SoBj
=lSpS
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-for-v4.16-rc6' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"i915, amd and nouveau fixes.
i915:
- backlight fix for some panels
- pm fix
- fencing fix
- some GVT fixes
amdgpu:
- backlight fix across suspend/resume
- object destruction ordering issue fix
- displayport fix
nouveau:
- two backlight fixes
- fix for some lockups
Pretty quiet week, seems like everyone was fixing backlights"
* tag 'drm-fixes-for-v4.16-rc6' of git://people.freedesktop.org/~airlied/linux:
drm/nouveau/bl: fix backlight regression
drm/nouveau/bl: Fix oops on driver unbind
drm/nouveau/mmu: ALIGN_DOWN correct variable
drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field
drm/i915/gvt: Correct the privilege shadow batch buffer address
drm/amdgpu/dce: Don't turn off DP sink when disconnected
drm/amdgpu: save/restore backlight level in legacy dce code
drm/radeon: fix prime teardown order
drm/amdgpu: fix prime teardown order
drm/i915: Kick the rps worker when changing the boost frequency
drm/i915: Only prune fences after wait-for-all
drm/i915: Enable VBT based BL control for DP
drm/i915/gvt: keep oa config in shadow ctx
drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio
This reverts commit 3c181c12c4.
The offending patch was merged in 4.16-rc4 and was promptly applied to
stable kernels 4.14.25 and 4.15.8.
The patch causes a corruption in several superblock items on big-endian
machines because of messed up endianity conversions. The damage is
manually repairable. A filesystem cannot be mounted again after it has
been unmounted once.
We do a full revert and not a fixup so stable can pick that patch ASAP.
Fixes: 3c181c12c4 ("btrfs: use proper endianness accessors for super_copy")
Link: https://lkml.kernel.org/r/1521139304@msgid.manchmal.in-ulm.de
CC: stable@vger.kernel.org # 4.14+
Reported-by: Christoph Biedl <linux-kernel.bfrz@manchmal.in-ulm.de>
Signed-off-by: David Sterba <dsterba@suse.com>
When using device passthrough with SME active, the MMIO range that is
mapped for the device should not be mapped encrypted. Add a check in
set_spte() to insure that a page is not mapped encrypted if that page
is a device MMIO page as indicated by kvm_is_mmio_pfn().
Cc: <stable@vger.kernel.org> # 4.14.x-
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Microblaze doesn't set CONFIG_NO_BOOTMEM and so memblock_virt_alloc()
doesn't work for CONFIG_HAVE_MEMBLOCK && !CONFIG_NO_BOOTMEM.
Similar change was already done by others architectures
"ARM: mm: Remove bootmem code and switch to NO_BOOTMEM"
(sha1: 84f452b1e8)
or
"openrisc: Consolidate setup to use memblock instead of bootmem"
(sha1: 266c7fad15)
or
"parisc: Drop bootmem and switch to memblock"
(sha1: 4fe9e1d957)
or
"powerpc: Remove bootmem allocator"
(sha1: 10239733ee)
or
"s390/mm: Convert bootmem to memblock"
(sha1: 50be634507)
or
"sparc64: Convert over to NO_BOOTMEM."
(sha1: 625d693e97)
or
"xtensa: drop sysmem and switch to memblock"
(sha1: 0e46c1115f)
Issue was introduced by:
"of/fdt: use memblock_virt_alloc for early alloc"
(sha1: 0fa1c57934)
Signed-off-by: Rob Herring <robh@kernel.org>
Tested-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
Tested-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
The patch:
"microblaze: Setup proper dependency for optimized lib functions"
(sha1: 7b6ce52be3)
didn't setup all dependencies properly.
Optimized lib functions in C are also present for little endian
and optimized library functions in assembler are implemented only for
big endian version.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
In accordance with Intel's microcode revision guidance from March 6 MCU
rev 0xc2 is cleared on both Skylake H/S and Skylake Xeon E3 processors
that share CPUID 506E3.
Signed-off-by: Alexander Sergeyev <sergeev917@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Jia Zhang <qianyue.zj@alibaba-inc.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Kyle Huey <me@kylehuey.com>
Cc: David Woodhouse <dwmw@amazon.co.uk>
Link: https://lkml.kernel.org/r/20180313193856.GA8580@localhost.localdomain
- Two warnings fix for runtime pm and usr copy (Xiong, Zhenyu)
- OA context fix for vGPU profiling (Min)
- privilege batch buffer reloc fix (Fred)
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJaqwRYAAoJEPpiX2QO6xPKZT0H/30rwEPNL0Z9LMrZY/WC4Yr8
0Hbc7jn0pYgCV+Cm8E1OPwQv2lqZMx5VAPV7ggQqaVjQam629NVODVUVNyMorQ7l
uy3kbi3vAcazuvaApUchMDppfl919FP5QXFKaEm8HU3C8oROaKO6lZKc6OJFd1Bu
eNLwg3FqI0JXRUqfggzyaqtpV8bMXzLVeQh98wlGbpkEF0yvXlTPProLJx4WX2kq
/8OULi2k7g9QxOd8S9l3TdSHpOJKPzoDecvGW6WFM+0q5POs+Ybk69yU32irt/Fk
2dNbqn8GgPXTkFMaBzlBFqq6Kgh4y1b6eQDjQC1oZGOyjK/HwtNteZHREEzg15A=
=fg6j
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-fixes-2018-03-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
Only GVT fixes:
- Two warnings fix for runtime pm and usr copy (Xiong, Zhenyu)
- OA context fix for vGPU profiling (Min)
- privilege batch buffer reloc fix (Fred)
* tag 'drm-intel-fixes-2018-03-15' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915/gvt: fix user copy warning by whitelist workload rb_tail field
drm/i915/gvt: Correct the privilege shadow batch buffer address
drm/i915/gvt: keep oa config in shadow ctx
drm/i915/gvt: Add runtime_pm_get/put into gvt_switch_mmio
Pull vfs fixes from Al Viro:
- backport-friendly part of lock_parent() race fix
- a fix for an assumption in the heurisic used by path_connected() that
is not true on NFS
- livelock fixes for d_alloc_parallel()
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
fs: Teach path_connected to handle nfs filesystems with multiple roots.
fs: dcache: Use READ_ONCE when accessing i_dir_seq
fs: dcache: Avoid livelock between d_alloc_parallel and __d_add
lock_parent() needs to recheck if dentry got __dentry_kill'ed under it
Unbinding nouveau on a dual GPU MacBook Pro oopses because we iterate
over the bl_connectors list in nouveau_backlight_exit() but skipped
initializing it in nouveau_backlight_init(). Stacktrace for posterity:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: nouveau_backlight_exit+0x2b/0x70 [nouveau]
nouveau_display_destroy+0x29/0x80 [nouveau]
nouveau_drm_unload+0x65/0xe0 [nouveau]
drm_dev_unregister+0x3c/0xe0 [drm]
drm_put_dev+0x2e/0x60 [drm]
nouveau_drm_device_remove+0x47/0x70 [nouveau]
pci_device_remove+0x36/0xb0
device_release_driver_internal+0x157/0x220
driver_detach+0x39/0x70
bus_remove_driver+0x51/0xd0
pci_unregister_driver+0x2a/0xa0
nouveau_drm_exit+0x15/0xfb0 [nouveau]
SyS_delete_module+0x18c/0x290
system_call_fast_compare_end+0xc/0x6f
Fixes: b53ac1ee12 ("drm/nouveau/bl: Do not register interface if Apple GMUX detected")
Cc: stable@vger.kernel.org # v4.10+
Cc: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit 7110c89bb8852ff8b0f88ce05b332b3fe22bd11e ("mmu: swap out round
for ALIGN") replaced two calls to round/rounddown with ALIGN/ALIGN_DOWN,
but erroneously applied ALIGN_DOWN to a different variable (addr) and left
intended variable (tail) not rounded/ALIGNed.
As a result screen corruption, X lockups are observable. An example of kernel
log of affected system with NV98 card where it was bisected:
nouveau 0000:01:00.0: gr: TRAP_M2MF 00000002 [IN]
nouveau 0000:01:00.0: gr: TRAP_M2MF 00320951 400007c0 00000000 04000000
nouveau 0000:01:00.0: gr: 00200000 [] ch 1 [000fbbe000 DRM] subc 4 class 5039
mthd 0100 data 00000000
nouveau 0000:01:00.0: fb: trapped read at 0040000000 on channel 1
[0fbbe000 DRM]
engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] reason 00000006
[NULL_DMAOBJ]
Fixes bug 105173 ("[MCP79][Regression] Unhandled NULL pointer dereference in
nvkm_object_unmap since kernel 4.15")
https://bugs.freedesktop.org/show_bug.cgi?id=105173
Fixes: 7110c89bb885 ("mmu: swap out round for ALIGN ")
Tested-by: Pierre Moreau <pierre.morrow@free.fr>
Reviewed-by: Pierre Moreau <pierre.morrow@free.fr>
Signed-off-by: Maris Nartiss <maris.nartiss@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org # v4.15+
On nfsv2 and nfsv3 the nfs server can export subsets of the same
filesystem and report the same filesystem identifier, so that the nfs
client can know they are the same filesystem. The subsets can be from
disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no
way to find the common root of all directory trees exported form the
server with the same filesystem identifier.
The practical result is that in struct super s_root for nfs s_root is
not necessarily the root of the filesystem. The nfs mount code sets
s_root to the root of the first subset of the nfs filesystem that the
kernel mounts.
This effects the dcache invalidation code in generic_shutdown_super
currently called shrunk_dcache_for_umount and that code for years
has gone through an additional list of dentries that might be dentry
trees that need to be freed to accomodate nfs.
When I wrote path_connected I did not realize nfs was so special, and
it's hueristic for avoiding calling is_subdir can fail.
The practical case where this fails is when there is a move of a
directory from the subtree exposed by one nfs mount to the subtree
exposed by another nfs mount. This move can happen either locally or
remotely. With the remote case requiring that the move directory be cached
before the move and that after the move someone walks the path
to where the move directory now exists and in so doing causes the
already cached directory to be moved in the dcache through the magic
of d_splice_alias.
If someone whose working directory is in the move directory or a
subdirectory and now starts calling .. from the initial mount of nfs
(where s_root == mnt_root), then path_connected as a heuristic will
not bother with the is_subdir check. As s_root really is not the root
of the nfs filesystem this heuristic is wrong, and the path may
actually not be connected and path_connected can fail.
The is_subdir function might be cheap enough that we can call it
unconditionally. Verifying that will take some benchmarking and
the result may not be the same on all kernels this fix needs
to be backported to. So I am avoiding that for now.
Filesystems with snapshots such as nilfs and btrfs do something
similar. But as the directory tree of the snapshots are disjoint
from one another and from the main directory tree rename won't move
things between them and this problem will not occur.
Cc: stable@vger.kernel.org
Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Fixes: 397d425dc2 ("vfs: Test for and handle paths that are unreachable from their mnt_root")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
pmdp_invalidate() was changed to update the pmd atomically
(to not lose dirty/access bits) and return the original pmd
value.
However, in doing so, we lost a lot of the essential work that
set_pmd_at() does, namely to update hugepage mapping counts and
queuing up the batched TLB flush entry.
Thus we were not flushing entries out of the TLB when making
such PMD changes.
Fix this by abstracting the accounting work of set_pmd_at() out into a
separate function, and call it from pmdp_establish().
Fixes: a8e654f01c ("sparc64: update pmdp_invalidate() to return old pmd value")
Signed-off-by: David S. Miller <davem@davemloft.net>
- Fix bug leading to lost IPIs on POWER9 and hence to other CPUs reporting
lockups in smp_call_function_many().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJaqNxFAAoJEJ2a6ncsY3GfmwQH/3wz36kFHufskFhqtr3kQKYS
/LFsydZKF/8puR8CobVcvqRX/KP/WpjTvpC4GhYrto7IVPJBpuJuozSY5LDLVg9s
kw5uNQeZREFjua2Lo78/YUh+wN7Xx3LtBC/ass6QOM51dGnfeUpSiSuzGQhMrpaf
CaDVT/0M1zPcQqDvQSinsTJm5xNTJ2cO6Q2tTFtHOWQGBKB1uGxexBx9NAEO71vh
6KOgU9uIW83Vy2tubOEN6vaDEOUtm6MOwaTbFQo3Dvt7VPDoUmU099K0+EI8UBDF
/PQ/yXWaAkSrZdyDFsLWONd9jX0LrvhdNOw1bh46fPdr+SCTNp9pFRCcq3P+MhI=
=44ey
-----END PGP SIGNATURE-----
Merge tag 'kvm-ppc-fixes-4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc into kvm-master
Fix for PPC KVM for 4.16
- Fix bug leading to lost IPIs on POWER9 and hence to other CPUs reporting
lockups in smp_call_function_many().
- Peace of mind locking fix in vgic_mmio_read_pending
- Allow hw-mapped interrupts to be reset when the VM resets
- Fix GICv2 multi-source SGI injection
- Fix MMIO synchronization for GICv2 on v3 emulation
- Remove excess verbosity on the console
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEn9UcU+C1Yxj9lZw9I9DQutE9ekMFAlqqp/cVHG1hcmMuenlu
Z2llckBhcm0uY29tAAoJECPQ0LrRPXpDAGkP/2LMhFN561PKlqgu5V4hFvowJiXb
Gbb/qi095vtDGccbKmJKAZp3jyOM2oJEMUkx5RBYglWjW0mxb3zPAAxhldXiqv/2
CrOGGlS/FwfyIjCt7870pltDOIgRmk8Fv/MyQjjGKF6VAghd6yVHIZiOUjiriUyz
6hNyc2znLm0tBqm4j3HTXKHpD23YseW387pQoeQ03/WiXiZ60O3e3k0yppXO81qE
b7TGT4Bz04mxlAISZVZeTmG7P7P4ej6+NhOH+1kxacseLzHdECPBA0JRcwRpfLkP
5JFodUOX7/KHpvpMLUxRNRnLBei9WUL4o2LAEV0qDaj7nlAud0kKUm22RLaVKDm+
8FSUQ12XKqnZsRrl6IizU1oAb1I1iV3j9HF5iNf3mk9AO27REGk0b8fDyRzDj300
xpySgvIgA+f+EyY+3ve0AmEUa5QKz/WLuik2ZCqpVOuufrO8XpS+zjn1L1tzTlkR
95EahDA7enutw47G0uWtxoPMeU4HTZS/CAiFwUbq8BEK7T3Rct7UySPLwgeYBoji
MUlCRhPyAANCJmtO6rpOS3htkQ3XkkO1DVIGLuWC5Zl00W1T5I5+VRrVL1YI4v3O
d2ui9r5X5Vmg4OUdhr2D9fXgPWWKEbqD90jv40rGLsMl0g/IwrC+o2VxgYxSeu5x
CLUYILwEA5NDZSof
=iyYE
-----END PGP SIGNATURE-----
Merge tag 'kvm-arm-fixes-for-v4.16-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
kvm/arm fixes for 4.16, take 2
- Peace of mind locking fix in vgic_mmio_read_pending
- Allow hw-mapped interrupts to be reset when the VM resets
- Fix GICv2 multi-source SGI injection
- Fix MMIO synchronization for GICv2 on v3 emulation
- Remove excess verbosity on the console
A series of small fixes in ASoC, HD-audio and core stuff:
- A UAF fix in ALSA PCM core
- Yet more hardening for ALSA sequencer
- A regression fix for the previous HD-audio power_save option change
- Various ASoC codec fixes (sgtl5000, rt5651, hdmi-codec, wm_adsp)
- Minor ASoC platform fixes (AMD ACP, sun4i)
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAlqqprkOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE+Fow//b3ud9UpNKYArnADF+jt5rhXHKPZdQf4W9Thy
RVCv4twJzB2kT7gxw/x5dghMBYYWbHtOMqHtanwqIu9YehQ6XiKyRsAQrD5PFAzM
27h+bNNBIEAJ+jSuJS8pp2T6mQ8KTyMt8lCpsA5yhuBIWahraTJ76tk3CmkXrKwe
Stk0RxSDjH4TVbPSHbBc064freBuJcLvDNXSKMxxYc/0mJ2qatvdcKevDeISjvwB
yQkDiyHdfpOugYxMVx0H8T1bIM1esUg19+CF9E8/JuKKibKRkOPHPCLjPI8sXVSV
zYpfbH5SZT69H7VQRlX1y9rqQycTeMyZyDZBQlTx2KoDh+KnQJ6JKH9NoKg9l5o0
GPr6zMBaIxCI4mAJd5VMOfMCQVGa1pU6KD7dnRbBtFDlSsO93IGf1EMi9L+Yh2KC
GV6EJxo82h7JPZotYTQEh9C4OvStIKxdm8kmy3Yd1N7MOAy0TpemC41rYp3KAaET
W2GrT39c1uyPMRU27GVb08X64itDIpAFGvA3sEaT7TGoO3mAv30tfN4SUu8Ls3n/
0dCnKN68yAGISogz6fbrvSz2tQoZQf1ACz548zony753tOvmxndtvgPIvGDDa/j3
z/FYfoCMTF/KijQhEKK7pOu5lwEaOd66VC3XZgyYgCON0SZbzcStqQF33kGuIlhT
BcmjHOI=
=mCc/
-----END PGP SIGNATURE-----
Merge tag 'sound-4.16-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"A series of small fixes in ASoC, HD-audio and core stuff:
- a UAF fix in ALSA PCM core
- yet more hardening for ALSA sequencer
- a regression fix for the previous HD-audio power_save option change
- various ASoC codec fixes (sgtl5000, rt5651, hdmi-codec, wm_adsp)
- minor ASoC platform fixes (AMD ACP, sun4i)"
* tag 'sound-4.16-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: hda - Revert power_save option default value
ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()
ALSA: seq: Clear client entry before deleting else at closing
ALSA: seq: Fix possible UAF in snd_seq_check_queue()
ASoC: amd: 16bit resolution support for i2s sp instance
ASoC: wm_adsp: For TLV controls only register TLV get/set
ASoC: sun4i-i2s: Fix RX slot number of SUN8I
ASoC: hdmi-codec: Fix module unloading caused kernel crash
ASoC: rt5651: Fix regcache sync errors on resume
ASoC: sgtl5000: Fix suspend/resume
MAINTAINERS: Add myself as sgtl5000 maintainer
ASoC: samsung: Add the DT binding files entry to MAINTAINERS
sgtl5000: change digital_mute policy
- 2 DM multipath fixes for a fix that was merged into 4.15-rc5
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJaqoz6AAoJEMUj8QotnQNaNtEH/37YSs5yBXSzbsvRQuVsht1G
C5qXrTB22JczSBNBfC+i0h5o9bXSm5brL/lOcP0qEokXnhEFgVK/nfcJmDRErUuJ
7TJhvYPptrFJ0hR7uMzqXxqp5ZDY+/mmzj69s0ZGZyhVacvO/CDW9CPUg7vgROp2
lEUohb3vi1ZaaHavbb/di4/m88+niJw5Yi/TBV24O7UxixQ3F1aeC5UENbfOt9re
5CauY3OcosS0Z+Kr8rmOzy2l/yBd2bYl8YGf4sJHWp4hmPec9PXUBOAK9wca9ouA
UNVh/2SBddjmM8wsDzUGsJJyZW+YN2eh2fzs9eJIDfrOFt4BhueUVUzKcxXo+RE=
=XErm
-----END PGP SIGNATURE-----
Merge tag 'for-4.16/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
- a stable DM multipath fix to restore ability to pass integrity data
- two DM multipath fixes for a fix that was merged into 4.16-rc5
* tag 'for-4.16/dm-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm mpath: fix passing integrity data
dm mpath: eliminate need to use scsi_device_from_queue
dm mpath: fix uninitialized 'pg_init_wait' waitqueue_head NULL pointer
Once the ring buffer is copied to ring_scan_buffer and scanned,
the shadow batch buffer start address is only updated into
ring_scan_buffer, not the real ring address allocated through
intel_ring_begin in later copy_workload_to_ring_buffer.
This patch is only to set the right shadow batch buffer address
from Ring buffer, not include the shadow_wa_ctx.
v2:
- refine some comments. (Zhenyu)
v3:
- fix typo in title. (Zhenyu)
v4:
- remove the unnecessary comments. (Zhenyu)
- add comments in bb_start_cmd_va update. (Zhenyu)
Fixes: 0a53bc07f0 ("drm/i915/gvt: Separate cmd scan from request allocation")
Cc: stable@vger.kernel.org # v4.15
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Yulei Zhang <yulei.zhang@intel.com>
Signed-off-by: fred gao <fred.gao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
This is four patches, consisting of one regression from the merge
window (qla2xxx) one lonstanding memory leak (sd_zbc) one event queue
mislabelling which we want to eliminate to discourage the pattern
(mpt3sas) and one behaviour change because re-reading the partition
table shouldn't clear the ro flag.
Signed-off-by: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCWqmwAyYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishXztAQCYs0s/
oysGLnl2qkuSC8u7vzzLURfQ6l2MGq4ic8Y/mQD/ZgTvf9eGj5OhARcRk29D3XRJ
zDY3KbkNIajadXlN3LY=
=eu2i
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"This is four patches, consisting of one regression from the merge
window (qla2xxx), one long-standing memory leak (sd_zbc), one event
queue mislabelling which we want to eliminate to discourage the
pattern (mpt3sas), and one behaviour change because re-reading the
partition table shouldn't clear the ro flag"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: sd: Keep disk read-only when re-reading partition
scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure
scsi: sd_zbc: Fix potential memory leak
scsi: mpt3sas: Do not mark fw_event workqueue as WQ_MEM_RECLAIM
geo->keylen cannot be larger than 4. So we might as well make
fixed-size allocations.
Given the one remaining user, geo->keylen cannot even be larger than 1.
Logfs used to have 64bit and 128bit keys, tcm_qla2xxx only has 32bit
keys. But let's not break the code if we don't have to.
Signed-off-by: Joern Engel <joern@purestorage.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull percpu_ref rcu fixes from Tejun Heo:
"Jann Horn found that aio was depending on the internal RCU grace
periods of percpu-ref and that it's broken because aio uses regular
RCU while percpu_ref uses sched-RCU.
Depending on percpu_ref's internal grace periods isn't a good idea
because
- The RCU type might not match.
- percpu_ref's grace periods are used to switch to atomic mode. They
aren't between the last put and the invocation of the last release.
This is easy to get confused about and can lead to subtle bugs.
- percpu_ref might not have grace periods at all depending on its
current operation mode.
This patchset audits and fixes percpu_ref users for their RCU usages"
[ There's a continuation of this series that clarifies percpu_ref
documentation that the internal grace periods must not be depended
upon, and introduces rcu_work to simplify bouncing to a workqueue
after an RCU grace period.
That will go in for 4.17 - this is just the minimal set with the fixes
that are tagged for -stable ]
* 'percpu_ref-rcu-audit-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc:
RDMAVT: Fix synchronization around percpu_ref
fs/aio: Use RCU accessors for kioctx_table->table[]
fs/aio: Add explicit RCU grace period when freeing kioctx
This reverts commit 864b75f9d6.
Commit 864b75f9d6 ("mm/page_alloc: fix memmap_init_zone pageblock
alignment") modified the logic in memmap_init_zone() to initialize
struct pages associated with invalid PFNs, to appease a VM_BUG_ON()
in move_freepages(), which is redundant by its own admission, and
dereferences struct page fields to obtain the zone without checking
whether the struct pages in question are valid to begin with.
Commit 864b75f9d6 only makes it worse, since the rounding it does
may cause pfn assume the same value it had in a prior iteration of
the loop, resulting in an infinite loop and a hang very early in the
boot. Also, since it doesn't perform the same rounding on start_pfn
itself but only on intermediate values following an invalid PFN, we
may still hit the same VM_BUG_ON() as before.
So instead, let's fix this at the core, and ensure that the BUG
check doesn't dereference struct page fields of invalid pages.
Fixes: 864b75f9d6 ("mm/page_alloc: fix memmap_init_zone pageblock alignment")
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
Cc: Daniel Vacek <neelx@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Paul Burton <paul.burton@imgtec.com>
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
- 1 gem fix for fences
- 1 gem/pm fix for rps freq
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJaqaYoAAoJEPpiX2QO6xPKYO0IAK/D3aEm3faXYlvV11rZswib
K2T/E58xe5MfzRzJjN0tIPv1HnPlfQ3YOvXj4d9qDr/98UcPG9FqGi6V0N7yNy6M
t/uKN5itnrR23Mx6rLJ6VnPkNAsK7JtJySvAmncFZsPcFrbxzyThanxUFcSQziHf
aWa9OANVGbD+nwOON1+rIMHm5ZDRX+HiiRKE9CNVwyOfwMlIN21m8UwVc8yh1ga7
P6kYpfXYlw2ujN/InHHf+mLz8LE9ooZeaeVOLqOefjoTkCLWMnNDdRpwb4p3vHYk
2nP7bDFYq0vsKMCeXYeH+hacKr+d+YopfbWU4A6DIUgbaJQ6wtDjPUaOwWtlBho=
=c0/4
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-fixes-2018-03-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
- 1 display fix for bxt
- 1 gem fix for fences
- 1 gem/pm fix for rps freq
* tag 'drm-intel-fixes-2018-03-14' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915: Kick the rps worker when changing the boost frequency
drm/i915: Only prune fences after wait-for-all
drm/i915: Enable VBT based BL control for DP
A few fixes for 4.16:
- Fix a backlight S/R regression on amdgpu
- Fix prime teardown on radeon and amdgpu
- DP fix for amdgpu
* 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux:
drm/amdgpu/dce: Don't turn off DP sink when disconnected
drm/amdgpu: save/restore backlight level in legacy dce code
drm/radeon: fix prime teardown order
drm/amdgpu: fix prime teardown order
This patch addresses an issue that causes fiemap to falsely
report a shared extent. The test case is as follows:
xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5
sync
xfs_io -c "fiemap -v" /media/scratch/file5
which gives the resulting output:
wrote 65536/65536 bytes at offset 0
64 KiB, 4 ops; 0.0000 sec (121.359 MiB/sec and 7766.9903 ops/sec)
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x2001
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
This is because btrfs_check_shared calls find_parent_nodes
repeatedly in a loop, passing a share_check struct to report
the count of shared extent. But btrfs_check_shared does not
re-initialize the count value to zero for subsequent calls
from the loop, resulting in a false share count value. This
is a regressive behavior from 4.13.
With proper re-initialization the test result is as follows:
wrote 65536/65536 bytes at offset 0
64 KiB, 4 ops; 0.0000 sec (110.035 MiB/sec and 7042.2535 ops/sec)
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
/media/scratch/file5:
EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS
0: [0..127]: 24576..24703 128 0x1
which corrects the regression.
Fixes: 3ec4d3238a ("btrfs: allow backref search checks for shared extents")
Signed-off-by: Edmund Nadolski <enadolski@suse.com>
[ add text from cover letter to changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
Turning off the sink in this case causes various issues, because
userspace expects it to stay on until it turns it off explicitly.
Instead, turn the sink off and back on when a display is connected
again. This dance seems necessary for link training to work correctly.
Bugzilla: https://bugs.freedesktop.org/105308
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Save/restore the backlight level scratch register in S3/S4 so the
backlight level comes back at the previously requested level.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=199047
Fixes: 4ec6ecf48c (drm/amdgpu: drop scratch regs save and restore from S3/S4 handling)
Acked-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We unmapped imported DMA-bufs when the GEM handle was dropped, not when the
hardware was done with the buffere.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We unmapped imported DMA-bufs when the GEM handle was dropped, not when the
hardware was done with the buffere.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
CC: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
DELL_SMBIOS conditionally depends on ACPI_WMI in the same way it depends
on DCDBAS, update the Kconfig accordingly. Correct the driver init order
to ensure that the driver dependencies are met, avoiding race conditions
resulting in boot failure on certain systems when the drivers are
built-in.
The following is an automated git shortlog grouped by driver:
dell-smbios and related drivers:
- Fix dell driver init order
- Resolve dependency error on ACPI_WMI
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJaqWWlAAoJEKbMaAwKp364y2gH/RUWyV2snZKLQNSzi9w5xdxb
G99n0Hsy5ugUcnqDx6jK7Hgy0Lm7D7Gs4+ePlY0AuPZN99ywTNfUQkr6Tbdns/wv
CKJtToA6DRh/fbvHDbNMsFEiv9a/Xdf21925K73KWqTN6RK/dWZVffafvRh0UmQe
ffGYccVNdxsOI4e8qNzk2++3QfxSsH97nDHDFDVA0lRWdKljK3DJTSzeUOhoRErf
YsyjUydVcnmlLmaoDt6xNAJIYcSqUqKwvIgX20hbeBYRBDLLZyjSpDjSW0F3NT2H
LZKq3hBoVzyp9ta3uZEwIZIdBk+5prR44ugFZZjOVsr7xvaMcKczerDPQEw9lgo=
=WjAI
-----END PGP SIGNATURE-----
Merge tag 'platform-drivers-x86-v4.16-7' of git://git.infradead.org/linux-platform-drivers-x86
Pull x86 platform drives fixes from Darren Hart:
- DELL_SMBIOS conditionally depends on ACPI_WMI in the same way it
depends on DCDBAS, update the Kconfig accordingly.
- fix the dell driver init order to ensure that the driver dependencies
are met, avoiding race conditions resulting in boot failure on
certain systems when the drivers are built-in.
* tag 'platform-drivers-x86-v4.16-7' of git://git.infradead.org/linux-platform-drivers-x86:
platform/x86: Fix dell driver init order
platform/x86: dell-smbios: Resolve dependency error on ACPI_WMI
