| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On PLL Enable sequence we need to "Configure DPCLKA_CFGCR0 to turn on
the clock for the DDI and map the DPLL to the DDI"
So we first do the map and then we unset DDI_CLK_OFF to turn the clock
on. We do this in 2 separated steps.
However, on this second step where we should only unset the off bit we are
also unmapping the ddi from the pll. So we end up using the pll 0
for almost everything. Consequently breaking cases with more than one
display.
Fixes: 555e38d27317 ("drm/i915/cnl: DDI - PLL mapping")
Cc: Paulo Zanoni <[email protected]>
Cc: Manasi Navare <[email protected]>
Cc: Kahola, Mika <[email protected]>
Signed-off-by: Rodrigo Vivi <[email protected]>
Reviewed-by: James Ausmus <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 87145d95c3d8297fb74762bd92e022d7f5cc250c)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
The compiler warns:
drivers/gpu/drm/i915/intel_ddi.c:118:35: warning: ‘bdw_ddi_translations_fdi’ defined but not used
Lo and behold, if we look at intel_ddi_get_buf_trans_fdi(), it uses
hsw_ddi_translations_fdi[] for both Haswell and *Broadwell*
Fixes: 7d1c42e679f9 ("drm/i915: Refactor code to select the DDI buf translation table")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: David Weinehall <[email protected]>
Cc: Jani Nikula <[email protected]>
Cc: <[email protected]> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Jani Nikula <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
(cherry picked from commit 1210d3889077653b90b0bfd2cc54e19f4766e4e6)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
In the full-ppgtt world, we can fill the GGTT full of context objects.
These context objects are currently implicitly tracked by the requests
that pin them i.e. they are only unpinned when the request is completed
and retired, but we do not have the link from the vma to the request
(anymore). In order to unpin those contexts, we have to issue another
request and wait upon the switch to the kernel context.
The bug during eviction was that we assumed that a full GGTT meant we
would have requests on the GGTT timeline, and so we missed situations
where those requests where merely in flight (and when even they have not
yet been submitted to hw yet). The fix employed here is to change the
already-is-idle test to no look at the execution timeline, but count the
outstanding requests and then check that we have switched to the kernel
context. Erring on the side of overkill here just means that we stall a
little longer than may be strictly required, but we only expect to hit
this path in extreme corner cases where returning an erroneous error is
worse than the delay.
v2: Logical inversion when swapping over branches.
Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 55b4f1ce2f23692c57205b9974fba61baa4b9321)
Signed-off-by: Rodrigo Vivi <[email protected]>
|
|
drm-intel-fixes
Signed-off-by: Rodrigo Vivi <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
RFC791 specifies the minimum MTU to be 68, while xen-net{front|back}
drivers use a minimum value of 0.
When set MTU to 0~67 with xen_net{front|back} driver, the network
will become unreachable immediately, the guest can no longer be pinged.
xen_net{front|back} should not allow the user to set this value which causes
network problems.
Reported-by: Chen Shi <[email protected]>
Signed-off-by: Mohammed Gamal <[email protected]>
Acked-by: Wei Liu <[email protected]>
Reviewed-by: Boris Ostrovsky <[email protected]>
Signed-off-by: Boris Ostrovsky <[email protected]>
|
|
The last cleanup introduced two harmless warnings:
fs/xfs/xfs_fsmap.c:480:1: warning: '__xfs_getfsmap_rtdev' defined but not used
fs/xfs/xfs_fsmap.c:372:1: warning: 'xfs_getfsmap_rtdev_rtbitmap_helper' defined but not used
This moves those two functions as well.
Fixes: bb9c2e543325 ("xfs: move more RT specific code under CONFIG_XFS_RT")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Brian Foster <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Signed-off-by: Darrick J. Wong <[email protected]>
|
|
The writeback rework in commit fbcc02561359 ("xfs: Introduce
writeback context for writepages") introduced a subtle change in
behavior with regard to the block mapping used across the
->writepages() sequence. The previous xfs_cluster_write() code would
only flush pages up to EOF at the time of the writepage, thus
ensuring that any pages due to file-extending writes would be
handled on a separate cycle and with a new, updated block mapping.
The updated code establishes a block mapping in xfs_writepage_map()
that could extend beyond EOF if the file has post-eof preallocation.
Because we now use the generic writeback infrastructure and pass the
cached mapping to each writepage call, there is no implicit EOF
limit in place. If eofblocks trimming occurs during ->writepages(),
any post-eof portion of the cached mapping becomes invalid. The
eofblocks code has no means to serialize against writeback because
there are no pages associated with post-eof blocks. Therefore if an
eofblocks trim occurs and is followed by a file-extending buffered
write, not only has the mapping become invalid, but we could end up
writing a page to disk based on the invalid mapping.
Consider the following sequence of events:
- A buffered write creates a delalloc extent and post-eof
speculative preallocation.
- Writeback starts and on the first writepage cycle, the delalloc
extent is converted to real blocks (including the post-eof blocks)
and the mapping is cached.
- The file is closed and xfs_release() trims post-eof blocks. The
cached writeback mapping is now invalid.
- Another buffered write appends the file with a delalloc extent.
- The concurrent writeback cycle picks up the just written page
because the writeback range end is LLONG_MAX. xfs_writepage_map()
attributes it to the (now invalid) cached mapping and writes the
data to an incorrect location on disk (and where the file offset is
still backed by a delalloc extent).
This problem is reproduced by xfstests test generic/464, which
triggers racing writes, appends, open/closes and writeback requests.
To address this problem, trim the mapping used during writeback to
within EOF when the mapping is validated. This ensures the mapping
is revalidated for any pages encountered beyond EOF as of the time
the current mapping was cached or last validated.
Reported-by: Eryu Guan <[email protected]>
Diagnosed-by: Eryu Guan <[email protected]>
Signed-off-by: Brian Foster <[email protected]>
Reviewed-by: Dave Chinner <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Signed-off-by: Darrick J. Wong <[email protected]>
|
|
Commit 332391a9935d ("fs: Fix page cache inconsistency when mixing
buffered and AIO DIO") moved page cache invalidation from
iomap_dio_rw() to iomap_dio_complete() for iomap based direct write
path, but before the dio->end_io() call, and it re-introdued the bug
fixed by commit c771c14baa33 ("iomap: invalidate page caches should
be after iomap_dio_complete() in direct write").
I found this because fstests generic/418 started failing on XFS with
v4.14-rc3 kernel, which is the regression test for this specific
bug.
So similarly, fix it by moving dio->end_io() (which does the
unwritten extent conversion) before page cache invalidation, to make
sure next buffer read reads the final real allocations not unwritten
extents. I also add some comments about why should end_io() go first
in case we get it wrong again in the future.
Note that, there's no such problem in the non-iomap based direct
write path, because we didn't remove the page cache invalidation
after the ->direct_IO() in generic_file_direct_write() call, but I
decided to fix dio_complete() too so we don't leave a landmine
there, also be consistent with iomap_dio_complete().
Fixes: 332391a9935d ("fs: Fix page cache inconsistency when mixing buffered and AIO DIO")
Signed-off-by: Eryu Guan <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Signed-off-by: Darrick J. Wong <[email protected]>
Reviewed-by: Jan Kara <[email protected]>
Reviewed-by: Lukas Czerner <[email protected]>
|
|
Recently we've had warnings arise from the vm handing us pages
without bufferheads attached to them. This should not ever occur
in XFS, but we don't defend against it properly if it does. The only
place where we remove bufferheads from a page is in
xfs_vm_releasepage(), but we can't tell the difference here between
"page is dirty so don't release" and "page is dirty but is being
invalidated so release it".
In some places that are invalidating pages ask for pages to be
released and follow up afterward calling ->releasepage by checking
whether the page was dirty and then aborting the invalidation. This
is a possible vector for releasing buffers from a page but then
leaving it in the mapping, so we really do need to avoid dirty pages
in xfs_vm_releasepage().
To differentiate between invalidated pages and normal pages, we need
to clear the page dirty flag when invalidating the pages. This can
be done through xfs_vm_invalidatepage(), and will result
xfs_vm_releasepage() seeing the page as clean which matches the
bufferhead state on the page after calling block_invalidatepage().
Hence we can re-add the page dirty check in xfs_vm_releasepage to
catch the case where we might be releasing a page that is actually
dirty and so should not have the bufferheads on it removed. This
will remove one possible vector of "dirty page with no bufferheads"
and so help narrow down the search for the root cause of that
problem.
Signed-Off-By: Dave Chinner <[email protected]>
Reviewed-by: Darrick J. Wong <[email protected]>
Signed-off-by: Darrick J. Wong <[email protected]>
|
|
We have implemented delayed ring mmio switch mechanism to reduce
unnecessary mmio switch. While the vGPU is being destroyed or
detached from VM, we need to force the ring switch to host context.
The later deadline is missed. Then it got a chance that word load
from VM2 might execute under the ring context of VM1 which was
attached to a same vGPU instance. Finally, the GPU is hang.
This patch guarantee the two deadline are performed.
v2: Remove unused variable 'scheduler'
Signed-off-by: Changbin Du <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
|
|
Add native DSD support quirk for Pro-Ject Pre Box S2 Digital USB id
2772:0230.
Signed-off-by: Jussi Laako <[email protected]>
Cc: <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
|
|
This adds a short document describing the views of how the Linux kernel
community feels about enforcing the license of the kernel.
Acked-by: Al Viro <[email protected]>
Acked-by: Alex Elder (Linaro) <[email protected]>
Acked-by: Andrea Arcangeli <[email protected]>
Acked-by: Andy Gross <[email protected]>
Acked-by: Aneesh Kumar K.V <[email protected]>
Acked-by: Anna Schumaker <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Arvind Yadav <[email protected]>
Acked-by: Bart Van Assche <[email protected]>
Acked-by: Bhumika Goyal <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Acked-by: Christian Borntraeger <[email protected]>
Acked-by: Christian König <[email protected]>
Acked-by: Christophe JAILLET <[email protected]>
Acked-by: Chuck Lever <[email protected]>
Acked-by: Colin Ian King <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Acked-by: Daniel Lezcano <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Darrick J. Wong (Oracle) <[email protected]>
Acked-by: Darrick J. Wong <[email protected]>
Acked-by: David Kershner <[email protected]>
Acked-by: David S. Miller <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Doug Ledford <[email protected]>
Acked-by: Fabio Estevam <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Acked-by: Florian Westphal <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Hannes Reinecke <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Acked-by: Heiko Carstens <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
Acked-by: Heiner Kallweit <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Acked-by: Ivan Safonov <[email protected]>
Acked-by: Jaegeuk Kim <[email protected]>
Acked-by: Jan Kara (SUSE) <[email protected]>
Acked-by: Javier Martinez Canillas <[email protected]>
Acked-by: Jeff Kirsher <[email protected]>
Acked-by: Jens Axboe <[email protected]>
Acked-by: Jes Sorensen <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Acked-by: Jiri Pirko <[email protected]>
Acked-by: Joe Perches <[email protected]>
Acked-by: Joerg Roedel (SUSE) <[email protected]>
Acked-by: Johan Hovold <[email protected]>
Acked-by: Josh Poimboeuf <[email protected]>
Acked-by: Juergen Gross <[email protected]>
Acked-by: Julia Lawall <[email protected]>
Acked-by: K. Y. Srinivasan <[email protected]>
Acked-by: Khalid Aziz <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Kuninori Morimoto <[email protected]>
Acked-by: Larry Finger <[email protected]>
Acked-by: Laura Abbott <[email protected]>
Acked-by: Lee Jones <[email protected]>
Acked-by: Leon Romanovsky <[email protected]>
Acked-by: Linus Walleij (Linaro) <[email protected]>
Acked-by: Lv Zheng <[email protected]>
Acked-by: Martin K. Petersen (Oracle) <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Acked-by: Mel Gorman <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Mike Marshall <[email protected]>
Acked-by: Namhyung Kim <[email protected]>
Acked-by: Neil Armstrong <[email protected]>
Acked-by: Olof Johansson <[email protected]>
Acked-by: Pablo Neira Ayuso <[email protected]>
Acked-by: Paolo Bonzini <[email protected]>
Acked-by: Paul Burton <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Ralf Baechle <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Acked-by: Rob Clark <[email protected]>
Acked-by: Rob Herring <[email protected]>
Acked-by: Sebastian Reichel (Collabora) <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Acked-by: Shuah Khan <[email protected]>
Acked-by: Simon Horman <[email protected]>
Acked-by: Srinivas Kandagatla <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
Acked-by: Sven Eckelmann <[email protected]>
Acked-by: Takashi Iwai (SUSE) <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Acked-by: Tony Luck <[email protected]>
Acked-by: Ulf Hansson <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Acked-by: Vivien Didelot <[email protected]>
Acked-by: Wei Yongjun <[email protected]>
Acked-by: Xin Long <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
zipl from s390-tools generates root=/dev/ram0 kernel cmdline for
zfcpdump, thus BLK_DEV_RAM is required.
zfcpdump initrd mounts DEBUG_FS, thus is also required.
Bug-Ubuntu: https://launchpad.net/bugs/1722735
Bug-Ubuntu: https://launchpad.net/bugs/1719290
Signed-off-by: Dimitri John Ledkov <[email protected]>
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
On CPU hotplug some cpu stats contain bogus values:
$ cat /proc/stat
cpu 0 0 49 1280 0 0 0 3 0 0
cpu0 0 0 49 618 0 0 0 3 0 0
cpu1 0 0 0 662 0 0 0 0 0 0
[...]
$ echo 0 > /sys/devices/system/cpu/cpu1/online
$ echo 1 > /sys/devices/system/cpu/cpu1/online
$ cat /proc/stat
cpu 0 0 49 3200 0 450359962737 450359962737 3 0 0
cpu0 0 0 49 1956 0 0 0 3 0 0
cpu1 0 0 0 1244 0 450359962737 450359962737 0 0 0
[...]
pcpu_attach_task() needs the same assignments as vtime_task_switch.
Signed-off-by: Christian Borntraeger <[email protected]>
Fixes: b7394a5f4ce9 ("sched/cputime, s390: Implement delayed accounting of system time")
Cc: [email protected] # 4.11+
Signed-off-by: Martin Schwidefsky <[email protected]>
|
|
|
|
When components are unbound, DRM driver is unregistered and freed,
so clear drvdata to avoid potential use-after-free issue in
suspend/resume paths.
Signed-off-by: Marek Szyprowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
The patch 6e8edf8a7d8d: "drm/exynos: Fix suspend/resume support" introduced
a new code in suspend/resume paths. However it unconditionally dereference
drm_dev pointer, which might be NULL if suspend/resume happens before
Exynos DRM driver components bind. This patch fixes this issue.
Reported-by: Dan Carpenter <[email protected]>
Fixes: 6e8edf8a7d8d "drm/exynos: Fix suspend/resume support"
Signed-off-by: Marek Szyprowski <[email protected]>
Signed-off-by: Inki Dae <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fixes from Greg KH:
"Here are 4 patches to resolve some char/misc driver issues found these
past weeks.
One of them is a mei bugfix and another is a new mei device id. There
is also a hyper-v fix for a reported issue, and a binder issue fix for
a problem reported by a few people.
All of these have been in my tree for a while, I don't know if
linux-next is really testing much this month. But 0-day is happy with
them :)"
* tag 'char-misc-4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
binder: fix use-after-free in binder_transaction()
Drivers: hv: vmbus: Fix bugs in rescind handling
mei: me: add gemini lake devices id
mei: always use domain runtime pm callbacks.
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb
Pull USB fixes from Greg KH:
"Here are a handful of USB driver fixes for 4.14-rc5.
There is the "usual" usb-serial fixes and device ids, USB gadget
fixes, and some more fixes found by the fuzz testing that is happening
on the USB layer right now.
All of these have been in my tree this week with no reported issues"
* tag 'usb-4.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb:
usb: usbtest: fix NULL pointer dereference
usb: gadget: configfs: Fix memory leak of interface directory data
usb: gadget: composite: Fix use-after-free in usb_composite_overwrite_options
usb: misc: usbtest: Fix overflow in usbtest_do_ioctl()
usb: renesas_usbhs: Fix DMAC sequence for receiving zero-length packet
USB: dummy-hcd: Fix deadlock caused by disconnect detection
usb: phy: tegra: Fix phy suspend for UDC
USB: serial: console: fix use-after-free after failed setup
USB: serial: console: fix use-after-free on disconnect
USB: serial: qcserial: add Dell DW5818, DW5819
USB: serial: cp210x: add support for ELV TFD500
USB: serial: cp210x: fix partnum regression
USB: serial: option: add support for TP-Link LTE module
USB: serial: ftdi_sio: add id for Cypress WICED dev board
|
|
git://git.infradead.org/users/vkoul/slave-dma
Pull dmaengine fixes from Vinod Koul:
"Here are fixes for this round
- fix spinlock usage amd fifo response for altera driver
- fix ti crossbar race condition
- fix edma memcpy align"
* tag 'dmaengine-fix-4.14-rc5' of git://git.infradead.org/users/vkoul/slave-dma:
dmaengine: altera: fix spinlock usage
dmaengine: altera: fix response FIFO emptying
dmaengine: ti-dma-crossbar: Fix possible race condition with dma_inuse
dmaengine: edma: Align the memcpy acnt array size with the transfer
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 fixes from Ingo Molnar:
"A landry list of fixes:
- fix reboot breakage on some PCID-enabled system
- fix crashes/hangs on some PCID-enabled systems
- fix microcode loading on certain older CPUs
- various unwinder fixes
- extend an APIC quirk to more hardware systems and disable APIC
related warning on virtualized systems
- various Hyper-V fixes
- a macro definition robustness fix
- remove jprobes IRQ disabling
- various mem-encryption fixes"
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/microcode: Do the family check first
x86/mm: Flush more aggressively in lazy TLB mode
x86/apic: Update TSC_DEADLINE quirk with additional SKX stepping
x86/apic: Silence "FW_BUG TSC_DEADLINE disabled due to Errata" on hypervisors
x86/mm: Disable various instrumentations of mm/mem_encrypt.c and mm/tlb.c
x86/hyperv: Fix hypercalls with extended CPU ranges for TLB flushing
x86/hyperv: Don't use percpu areas for pcpu_flush/pcpu_flush_ex structures
x86/hyperv: Clear vCPU banks between calls to avoid flushing unneeded vCPUs
x86/unwind: Disable unwinder warnings on 32-bit
x86/unwind: Align stack pointer in unwinder dump
x86/unwind: Use MSB for frame pointer encoding on 32-bit
x86/unwind: Fix dereference of untrusted pointer
x86/alternatives: Fix alt_max_short macro to really be a max()
x86/mm/64: Fix reboot interaction with CR4.PCIDE
kprobes/x86: Remove IRQ disabling from jprobe handlers
kprobes/x86: Set up frame pointer in kprobe trampoline
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull scheduler fixes from Ingo Molnar:
"Three fixes that address an SMP balancing performance regression"
* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/core: Ensure load_balance() respects the active_mask
sched/core: Address more wake_affine() regressions
sched/core: Fix wake_affine() performance regression
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull RAS fixes from Ingo Molnar:
"A boot parameter fix, plus a header export fix"
* 'ras-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86/mce: Hide mca_cfg
RAS/CEC: Use the right length for "cec_disable"
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull perf fixes from Ingo Molnar:
"Some tooling fixes plus three kernel fixes: a memory leak fix, a
statistics fix and a crash fix"
* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf/x86/intel/uncore: Fix memory leaks on allocation failures
perf/core: Fix cgroup time when scheduling descendants
perf/core: Avoid freeing static PMU contexts when PMU is unregistered
tools include uapi bpf.h: Sync kernel ABI header with tooling header
perf pmu: Unbreak perf record for arm/arm64 with events with explicit PMU
perf script: Add missing separator for "-F ip,brstack" (and brstackoff)
perf callchain: Compare dsos (as well) for CCKEY_FUNCTION
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull locking fixes from Ingo Molnar:
"Two lockdep fixes for bugs introduced by the cross-release dependency
tracking feature - plus a commit that disables it because performance
regressed in an absymal fashion on some systems"
* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
locking/lockdep: Disable cross-release features for now
locking/selftest: Avoid false BUG report
locking/lockdep: Fix stacktrace mess
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull irq fixes from Ingo Molnar:
"A CPU hotplug related fix, plus two related sanity checks"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
genirq/cpuhotplug: Enforce affinity setting on startup of managed irqs
genirq/cpuhotplug: Add sanity check for effective affinity mask
genirq: Warn when effective affinity is not updated
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull objtool fix from Ingo Molnar:
"A single objtool fix: avoid silently broken ORC debuginfo builds and
error out instead"
* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
objtool: Upgrade libelf-devel warning to error for CONFIG_ORC_UNWINDER
|
|
On CPUs like AMD's Geode, for example, we shouldn't even try to load
microcode because they do not support the modern microcode loading
interface.
However, we do the family check *after* the other checks whether the
loader has been disabled on the command line or whether we're running in
a guest.
So move the family checks first in order to exit early if we're being
loaded on an unsupported family.
Reported-and-tested-by: Sven Glodowski <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: <[email protected]> # 4.11..
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://bugzilla.suse.com/show_bug.cgi?id=1061396
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
Johan Hovold reported a big lockdep slowdown on his system, caused by lockdep:
> I had noticed that the BeagleBone Black boot time appeared to have
> increased significantly with 4.14 and yesterday I finally had time to
> investigate it.
>
> Boot time (from "Linux version" to login prompt) had in fact doubled
> since 4.13 where it took 17 seconds (with my current config) compared to
> the 35 seconds I now see with 4.14-rc4.
>
> I quick bisect pointed to lockdep and specifically the following commit:
>
> 28a903f63ec0 ("locking/lockdep: Handle non(or multi)-acquisition of a crosslock")
Because the final v4.14 release is close, disable the cross-release lockdep
features for now.
Bisected-by: Johan Hovold <[email protected]>
Debugged-by: Johan Hovold <[email protected]>
Reported-by: Johan Hovold <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Byungchul Park <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Tony Lindgren <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
git://git.linux-mips.org/pub/scm/ralf/upstream-linus
Pull MIPS fixes from Ralf Baechle:
"More MIPS fixes for 4.14:
- Loongson 1: Set the default number of RX and TX queues to
accomodate for recent changes of stmmac driver.
- BPF: Fix uninitialised target compiler error.
- Fix cmpxchg on 32 bit signed ints for 64 bit kernels with
!kernel_uses_llsc
- Fix generic-board-config.sh for builds using O=
- Remove pr_err() calls from fpu_emu() for a case which is not a
kernel error"
* '4.14-fixes' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
MIPS: math-emu: Remove pr_err() calls from fpu_emu()
MIPS: Fix generic-board-config.sh for builds using O=
MIPS: Fix cmpxchg on 32b signed ints for 64b kernel with !kernel_uses_llsc
MIPS: loongson1: set default number of rx and tx queues for stmmac
MIPS: bpf: Fix uninitialised target compiler error
|
|
Since commit:
94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
x86's lazy TLB mode has been all the way lazy: when running a kernel thread
(including the idle thread), the kernel keeps using the last user mm's
page tables without attempting to maintain user TLB coherence at all.
From a pure semantic perspective, this is fine -- kernel threads won't
attempt to access user pages, so having stale TLB entries doesn't matter.
Unfortunately, I forgot about a subtlety. By skipping TLB flushes,
we also allow any paging-structure caches that may exist on the CPU
to become incoherent. This means that we can have a
paging-structure cache entry that references a freed page table, and
the CPU is within its rights to do a speculative page walk starting
at the freed page table.
I can imagine this causing two different problems:
- A speculative page walk starting from a bogus page table could read
IO addresses. I haven't seen any reports of this causing problems.
- A speculative page walk that involves a bogus page table can install
garbage in the TLB. Such garbage would always be at a user VA, but
some AMD CPUs have logic that triggers a machine check when it notices
these bogus entries. I've seen a couple reports of this.
Boris further explains the failure mode:
> It is actually more of an optimization which assumes that paging-structure
> entries are in WB DRAM:
>
> "TlbCacheDis: cacheable memory disable. Read-write. 0=Enables
> performance optimization that assumes PML4, PDP, PDE, and PTE entries
> are in cacheable WB-DRAM; memory type checks may be bypassed, and
> addresses outside of WB-DRAM may result in undefined behavior or NB
> protocol errors. 1=Disables performance optimization and allows PML4,
> PDP, PDE and PTE entries to be in any memory type. Operating systems
> that maintain page tables in memory types other than WB- DRAM must set
> TlbCacheDis to insure proper operation."
>
> The MCE generated is an NB protocol error to signal that
>
> "Link: A specific coherent-only packet from a CPU was issued to an
> IO link. This may be caused by software which addresses page table
> structures in a memory type other than cacheable WB-DRAM without
> properly configuring MSRC001_0015[TlbCacheDis]. This may occur, for
> example, when page table structure addresses are above top of memory. In
> such cases, the NB will generate an MCE if it sees a mismatch between
> the memory operation generated by the core and the link type."
>
> I'm assuming coherent-only packets don't go out on IO links, thus the
> error.
To fix this, reinstate TLB coherence in lazy mode. With this patch
applied, we do it in one of two ways:
- If we have PCID, we simply switch back to init_mm's page tables
when we enter a kernel thread -- this seems to be quite cheap
except for the cost of serializing the CPU.
- If we don't have PCID, then we set a flag and switch to init_mm
the first time we would otherwise need to flush the TLB.
The /sys/kernel/debug/x86/tlb_use_lazy_mode debug switch can be changed
to override the default mode for benchmarking.
In theory, we could optimize this better by only flushing the TLB in
lazy CPUs when a page table is freed. Doing that would require
auditing the mm code to make sure that all page table freeing goes
through tlb_remove_page() as well as reworking some data structures
to implement the improved flush logic.
Reported-by: Markus Trippelsdorf <[email protected]>
Reported-by: Adam Borowski <[email protected]>
Signed-off-by: Andy Lutomirski <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Brian Gerst <[email protected]>
Cc: Daniel Borkmann <[email protected]>
Cc: Eric Biggers <[email protected]>
Cc: Johannes Hirte <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Nadav Amit <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Roman Kagan <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Fixes: 94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
|
|
git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Couple of the arm people seem to wake up so this has imx and msm
fixes, along with a bunch of i915 stable bounds fixes and an amdgpu
regression fix.
All seems pretty okay for now"
* tag 'drm-fixes-for-v4.14-rc5' of git://people.freedesktop.org/~airlied/linux:
drm/msm: fix _NO_IMPLICIT fencing case
drm/msm: fix error path cleanup
drm/msm/mdp5: Remove extra pm_runtime_put call in mdp5_crtc_cursor_set()
drm/msm/dsi: Use correct pm_runtime_put variant during host_init
drm/msm: fix return value check in _msm_gem_kernel_new()
drm/msm: use proper memory barriers for updating tail/head
drm/msm/mdp5: add missing max size for 8x74 v1
drm/amdgpu: fix placement flags in amdgpu_ttm_bind
drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channel
gpu: ipu-v3: pre: implement workaround for ERR009624
gpu: ipu-v3: prg: wait for double buffers to be filled on channel startup
gpu: ipu-v3: Allow channel burst locking on i.MX6 only
drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
drm/i915: Order two completing nop_submit_request
drm/i915: Silence compiler warning for hsw_power_well_enable()
drm/i915: Use crtc_state_is_legacy_gamma in intel_color_check
drm/i915/edp: Increase the T12 delay quirk to 1300ms
drm/i915/edp: Get the Panel Power Off timestamp after panel is off
sync_file: Return consistent status in SYNC_IOC_FILE_INFO
drm/atomic: Unref duplicated drm_atomic_state in drm_atomic_helper_resume()
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
drm/i915 fixes for 4.14-rc5:
Three fixes for stable:
- Use crtc_state_is_legacy_gamma in intel_color_check (Maarten)
- Read timings from the correct transcoder (Ville).
- Fix HDMI on BSW (Jani).
Other fixes:
- eDP fixes (Manasi)
- Silence compiler warnings (Chris)
- Order two completing nop_submit_request (Chris)
* tag 'drm-intel-fixes-2017-10-11' of git://anongit.freedesktop.org/drm/drm-intel:
drm/i915/bios: parse DDI ports also for CHV for HDMI DDC pin and DP AUX channel
drm/i915: Read timings from the correct transcoder in intel_crtc_mode_get()
drm/i915: Order two completing nop_submit_request
drm/i915: Silence compiler warning for hsw_power_well_enable()
drm/i915: Use crtc_state_is_legacy_gamma in intel_color_check
drm/i915/edp: Increase the T12 delay quirk to 1300ms
drm/i915/edp: Get the Panel Power Off timestamp after panel is off
|
|
git://people.freedesktop.org/~robclark/linux into drm-fixes
bunch of msm fixes
* 'msm-fixes-4.14-rc4' of git://people.freedesktop.org/~robclark/linux:
drm/msm: fix _NO_IMPLICIT fencing case
drm/msm: fix error path cleanup
drm/msm/mdp5: Remove extra pm_runtime_put call in mdp5_crtc_cursor_set()
drm/msm/dsi: Use correct pm_runtime_put variant during host_init
drm/msm: fix return value check in _msm_gem_kernel_new()
drm/msm: use proper memory barriers for updating tail/head
drm/msm/mdp5: add missing max size for 8x74 v1
|
|
Merge misc fixes from Andrew Morton:
"18 fixes"
* emailed patches from Andrew Morton <[email protected]>:
mm, swap: use page-cluster as max window of VMA based swap readahead
mm: page_vma_mapped: ensure pmd is loaded with READ_ONCE outside of lock
kmemleak: clear stale pointers from task stacks
fs/binfmt_misc.c: node could be NULL when evicting inode
fs/mpage.c: fix mpage_writepage() for pages with buffers
linux/kernel.h: add/correct kernel-doc notation
tty: fall back to N_NULL if switching to N_TTY fails during hangup
Revert "vmalloc: back off when the current task is killed"
mm/cma.c: take __GFP_NOWARN into account in cma_alloc()
scripts/kallsyms.c: ignore symbol type 'n'
userfaultfd: selftest: exercise -EEXIST only in background transfer
mm: only display online cpus of the numa node
mm: remove unnecessary WARN_ONCE in page_vma_mapped_walk().
mm/mempolicy: fix NUMA_INTERLEAVE_HIT counter
include/linux/of.h: provide of_n_{addr,size}_cells wrappers for !CONFIG_OF
mm/madvise.c: add description for MADV_WIPEONFORK and MADV_KEEPONFORK
lib/Kconfig.debug: kernel hacking menu: runtime testing: keep tests together
mm/migrate: fix indexing bug (off by one) and avoid out of bound access
|
|
When the VMA based swap readahead was introduced, a new knob
/sys/kernel/mm/swap/vma_ra_max_order
was added as the max window of VMA swap readahead. This is to make it
possible to use different max window for VMA based readahead and
original physical readahead. But Minchan Kim pointed out that this will
cause a regression because setting page-cluster sysctl to zero cannot
disable swap readahead with the change.
To fix the regression, the page-cluster sysctl is used as the max window
of both the VMA based swap readahead and original physical swap
readahead. If more fine grained control is needed in the future, more
knobs can be added as the subordinate knobs of the page-cluster sysctl.
The vma_ra_max_order knob is deleted. Because the knob was introduced
in v4.14-rc1, and this patch is targeting being merged before v4.14
releasing, there should be no existing users of this newly added ABI.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: ec560175c0b6fce ("mm, swap: VMA based swap readahead")
Signed-off-by: "Huang, Ying" <[email protected]>
Reported-by: Minchan Kim <[email protected]>
Acked-by: Minchan Kim <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Cc: Johannes Weiner <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Shaohua Li <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Fengguang Wu <[email protected]>
Cc: Tim Chen <[email protected]>
Cc: Dave Hansen <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Loading the pmd without holding the pmd_lock exposes us to races with
concurrent updaters of the page tables but, worse still, it also allows
the compiler to cache the pmd value in a register and reuse it later on,
even if we've performed a READ_ONCE in between and seen a more recent
value.
In the case of page_vma_mapped_walk, this leads to the following crash
when the pmd loaded for the initial pmd_trans_huge check is all zeroes
and a subsequent valid table entry is loaded by check_pmd. We then
proceed into map_pte, but the compiler re-uses the zero entry inside
pte_offset_map, resulting in a junk pointer being installed in
pvmw->pte:
PC is at check_pte+0x20/0x170
LR is at page_vma_mapped_walk+0x2e0/0x540
[...]
Process doio (pid: 2463, stack limit = 0xffff00000f2e8000)
Call trace:
check_pte+0x20/0x170
page_vma_mapped_walk+0x2e0/0x540
page_mkclean_one+0xac/0x278
rmap_walk_file+0xf0/0x238
rmap_walk+0x64/0xa0
page_mkclean+0x90/0xa8
clear_page_dirty_for_io+0x84/0x2a8
mpage_submit_page+0x34/0x98
mpage_process_page_bufs+0x164/0x170
mpage_prepare_extent_to_map+0x134/0x2b8
ext4_writepages+0x484/0xe30
do_writepages+0x44/0xe8
__filemap_fdatawrite_range+0xbc/0x110
file_write_and_wait_range+0x48/0xd8
ext4_sync_file+0x80/0x4b8
vfs_fsync_range+0x64/0xc0
SyS_msync+0x194/0x1e8
This patch fixes the problem by ensuring that READ_ONCE is used before
the initial checks on the pmd, and this value is subsequently used when
checking whether or not the pmd is present. pmd_check is removed and
the pmd_present check is inlined directly.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: f27176cfc363 ("mm: convert page_mkclean_one() to use page_vma_mapped_walk()")
Signed-off-by: Will Deacon <[email protected]>
Tested-by: Yury Norov <[email protected]>
Tested-by: Richard Ruigrok <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: "Paul E. McKenney" <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Kmemleak considers any pointers on task stacks as references. This
patch clears newly allocated and reused vmap stacks.
Link: http://lkml.kernel.org/r/150728990124.744199.8403409836394318684.stgit@buzz
Signed-off-by: Konstantin Khlebnikov <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
inode->i_private is assigned by a Node pointer only after registering a
new binary format, so it could be NULL if inode was created by
bm_fill_super() (or iput() was called by the error path in
bm_register_write()), and this could result in NULL pointer dereference
when evicting such an inode. e.g. mount binfmt_misc filesystem then
umount it immediately:
mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc
umount /proc/sys/fs/binfmt_misc
will result in
BUG: unable to handle kernel NULL pointer dereference at 0000000000000013
IP: bm_evict_inode+0x16/0x40 [binfmt_misc]
...
Call Trace:
evict+0xd3/0x1a0
iput+0x17d/0x1d0
dentry_unlink_inode+0xb9/0xf0
__dentry_kill+0xc7/0x170
shrink_dentry_list+0x122/0x280
shrink_dcache_parent+0x39/0x90
do_one_tree+0x12/0x40
shrink_dcache_for_umount+0x2d/0x90
generic_shutdown_super+0x1f/0x120
kill_litter_super+0x29/0x40
deactivate_locked_super+0x43/0x70
deactivate_super+0x45/0x60
cleanup_mnt+0x3f/0x70
__cleanup_mnt+0x12/0x20
task_work_run+0x86/0xa0
exit_to_usermode_loop+0x6d/0x99
syscall_return_slowpath+0xba/0xf0
entry_SYSCALL_64_fastpath+0xa3/0xa
Fix it by making sure Node (e) is not NULL.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 83f918274e4b ("exec: binfmt_misc: shift filp_close(interp_file) from kill_node() to bm_evict_inode()")
Signed-off-by: Eryu Guan <[email protected]>
Acked-by: Oleg Nesterov <[email protected]>
Cc: Alexander Viro <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
When using FAT on a block device which supports rw_page, we can hit
BUG_ON(!PageLocked(page)) in try_to_free_buffers(). This is because we
call clean_buffers() after unlocking the page we've written. Introduce
a new clean_page_buffers() which cleans all buffers associated with a
page and call it from within bdev_write_page().
[[email protected]: s/PAGE_SIZE/~0U/ per Linus and Matthew]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Matthew Wilcox <[email protected]>
Reported-by: Toshi Kani <[email protected]>
Reported-by: OGAWA Hirofumi <[email protected]>
Tested-by: Toshi Kani <[email protected]>
Acked-by: Johannes Thumshirn <[email protected]>
Cc: Ross Zwisler <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Add kernel-doc notation for some macros. Correct kernel-doc comments &
typos for a few macros.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Randy Dunlap <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
We have seen NULL-pointer dereference crashes in tty->disc_data when the
N_TTY fallback driver failed to open during hangup. The immediate cause
of this open to fail has been addressed in the preceding patch to
vmalloc(), but this code could be more robust.
As Alan pointed out in commit 8a8dabf2dd68 ("tty: handle the case where
we cannot restore a line discipline"), the N_TTY driver, historically
the safe fallback that could never fail, can indeed fail, but the
surrounding code is not prepared to handle this. To avoid crashes he
added a new N_NULL driver to take N_TTY's place as the last resort.
Hook that fallback up to the hangup path. Update tty_ldisc_reinit() to
reflect the reality that n_tty_open can indeed fail.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Johannes Weiner <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: Michal Hocko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
This reverts commits 5d17a73a2ebe ("vmalloc: back off when the current
task is killed") and 171012f56127 ("mm: don't warn when vmalloc() fails
due to a fatal signal").
Commit 5d17a73a2ebe ("vmalloc: back off when the current task is
killed") made all vmalloc allocations from a signal-killed task fail.
We have seen crashes in the tty driver from this, where a killed task
exiting tries to switch back to N_TTY, fails n_tty_open because of the
vmalloc failing, and later crashes when dereferencing tty->disc_data.
Arguably, relying on a vmalloc() call to succeed in order to properly
exit a task is not the most robust way of doing things. There will be a
follow-up patch to the tty code to fall back to the N_NULL ldisc.
But the justification to make that vmalloc() call fail like this isn't
convincing, either. The patch mentions an OOM victim exhausting the
memory reserves and thus deadlocking the machine. But the OOM killer is
only one, improbable source of fatal signals. It doesn't make sense to
fail allocations preemptively with plenty of memory in most cases.
The patch doesn't mention real-life instances where vmalloc sites would
exhaust memory, which makes it sound more like a theoretical issue to
begin with. But just in case, the OOM access to memory reserves has
been restricted on the allocator side in cd04ae1e2dc8 ("mm, oom: do not
rely on TIF_MEMDIE for memory reserves access"), which should take care
of any theoretical concerns on that front.
Revert this patch, and the follow-up that suppresses the allocation
warnings when we fail the allocations due to a signal.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 171012f56127 ("mm: don't warn when vmalloc() fails due to a fatal signal")
Signed-off-by: Johannes Weiner <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Dmitry Vyukov <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
cma_alloc() unconditionally prints an INFO message when the CMA
allocation fails. Make this message conditional on the non-presence of
__GFP_NOWARN in gfp_mask.
This patch aims at removing INFO messages that are displayed when the
VC4 driver tries to allocate buffer objects. From the driver
perspective an allocation failure is acceptable, and the driver can
possibly do something to make following allocation succeed (like
flushing the VC4 internal cache).
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Boris Brezillon <[email protected]>
Acked-by: Laura Abbott <[email protected]>
Cc: Jaewon Kim <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Eric Anholt <[email protected]>
Cc: Joonsoo Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
gcc on aarch64 may emit synbols of type 'n' if the kernel is built with
'-frecord-gcc-switches'. In most cases, those symbols are reported with
nm as
000000000000000e n $d
and with objdump as
0000000000000000 l d .GCC.command.line 0000000000000000 .GCC.command.line
000000000000000e l .GCC.command.line 0000000000000000 $d
Those symbols are detected in is_arm_mapping_symbol() and ignored.
However, if "--prefix-symbols=<prefix>" is configured as well, the
situation is different. For example, in efi/libstub, arm64 images are
built with
'--prefix-alloc-sections=.init --prefix-symbols=__efistub_'.
In combination with '-frecord-gcc-switches', the symbols are now reported
by nm as:
000000000000000e n __efistub_$d
and by objdump as:
0000000000000000 l d .GCC.command.line 0000000000000000 .GCC.command.line
000000000000000e l .GCC.command.line 0000000000000000 __efistub_$d
Those symbols are no longer ignored and included in the base address
calculation. This results in a base address of 000000000000000e, which
in turn causes kallsyms to abort with
kallsyms failure:
relative symbol value 0xffffff900800a000 out of range in relative mode
The problem is seen in little endian arm64 builds with CONFIG_EFI
enabled and with '-frecord-gcc-switches' set in KCFLAGS.
Explicitly ignore symbols of type 'n' since those are clearly debug
symbols.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
I was stress testing some backports and with high load, after some time,
the latest version of the selftest showed some false positive in
connection with the uffdio_copy_retry. This seems to fix it while still
exercising -EEXIST in the background transfer once in a while.
The fork child will quit after the last UFFDIO_COPY is run, so a
repeated UFFDIO_COPY may not return -EEXIST. This change restricts the
-EEXIST stress to the background transfer where the memory can't go away
from under it.
Also updated uffdio_zeropage, so the interface is consistent.
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrea Arcangeli <[email protected]>
Cc: Pavel Emelyanov <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: "Dr. David Alan Gilbert" <[email protected]>
Cc: Mike Kravetz <[email protected]>
Cc: Shuah Khan <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
When I execute numactl -H (which reads /sys/devices/system/node/nodeX/cpumap
and displays cpumask_of_node for each node), I get different result
on X86 and arm64. For each numa node, the former only displayed online
CPUs, and the latter displayed all possible CPUs. Unfortunately, both
Linux documentation and numactl manual have not described it clear.
I sent a mail to ask for help, and Michal Hocko replied that he
preferred to print online cpus because it doesn't really make much sense
to bind anything on offline nodes.
Will said:
"I suspect the vast majority (if not all) code that reads this file was
developed for x86, so having the same behaviour for arm64 sounds like
something we should do ASAP before people try to special case with
things like #ifdef __aarch64__. I'd rather have this in 4.14 if
possible."
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Zhen Lei <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Tianhong Ding <[email protected]>
Cc: Hanjun Guo <[email protected]>
Cc: Libin <[email protected]>
Cc: Kefeng Wang <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
A non present pmd entry can appear after pmd_lock is taken in
page_vma_mapped_walk(), even if THP migration is not enabled. The
WARN_ONCE is unnecessary.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 616b8371539a ("mm: thp: enable thp migration in generic path")
Signed-off-by: Zi Yan <[email protected]>
Reported-by: Abdul Haleem <[email protected]>
Tested-by: Abdul Haleem <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: Anshuman Khandual <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Commit 3a321d2a3dde ("mm: change the call sites of numa statistics
items") separated NUMA counters from zone counters, but the
NUMA_INTERLEAVE_HIT call site wasn't updated to use the new interface.
So alloc_page_interleave() actually increments NR_ZONE_INACTIVE_FILE
instead of NUMA_INTERLEAVE_HIT.
Fix this by using __inc_numa_state() interface to increment
NUMA_INTERLEAVE_HIT.
Link: http://lkml.kernel.org/r/[email protected]
Fixes: 3a321d2a3dde ("mm: change the call sites of numa statistics items")
Signed-off-by: Andrey Ryabinin <[email protected]>
Acked-by: Mel Gorman <[email protected]>
Cc: Kemi Wang <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
The pci-rcar driver is enabled for compile tests, and this has shown that
the driver cannot build without CONFIG_OF, following the inclusion of
commit f8f2fe7355fb ("PCI: rcar: Use new OF interrupt mapping when possible"):
drivers/pci/host/pcie-rcar.c: In function 'pci_dma_range_parser_init':
drivers/pci/host/pcie-rcar.c:1039:2: error: implicit declaration of function 'of_n_addr_cells' [-Werror=implicit-function-declaration]
parser->pna = of_n_addr_cells(node);
^
As pointed out by Ben Dooks and Geert Uytterhoeven, this is actually
supposed to build fine, which we can achieve if we make the declaration
of of_irq_parse_and_map_pci conditional on CONFIG_OF and provide an
empty inline function otherwise, as we do for a lot of other of
interfaces.
This lets us build the rcar_pci driver again without CONFIG_OF for build
testing. All platforms using this driver select OF, so this doesn't
change anything for the users.
[[email protected]: be consistent with surrounding code]
Link: http://lkml.kernel.org/r/[email protected]
Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Frank Rowand <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Cc: Bjorn Helgaas <[email protected]>
Cc: Magnus Damm <[email protected]>
Cc: Ben Dooks <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|