| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In our VGIC implementation we limit the number of SPIs to a number
that the userland application told us. Accordingly we limit the
allocation of memory for virtual IRQs to that number.
However in our MMIO dispatcher we didn't check if we ever access an
IRQ beyond that limit, leading to out-of-bound accesses.
Add a test against the number of allocated SPIs in check_region().
Adjust the VGIC_ADDR_TO_INT macro to avoid an actual division, which
is not implemented on ARM(32).
[maz: cleaned-up original patch]
Cc: [email protected]
Reviewed-by: Christoffer Dall <[email protected]>
Signed-off-by: Andre Przywara <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
|
|
single CPU
Architecturally, TLBs are private to the (physical) CPU they're
associated with. But when multiple vcpus from the same VM are
being multiplexed on the same CPU, the TLBs are not private
to the vcpus (and are actually shared across the VMID).
Let's consider the following scenario:
- vcpu-0 maps PA to VA
- vcpu-1 maps PA' to VA
If run on the same physical CPU, vcpu-1 can hit TLB entries generated
by vcpu-0 accesses, and access the wrong physical page.
The solution to this is to keep a per-VM map of which vcpu ran last
on each given physical CPU, and invalidate local TLBs when switching
to a different vcpu from the same VM.
Reviewed-by: Christoffer Dall <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
|
|
If VRAM allocation fails, the error handling path crashes in
msm_drm_uninit(). The following changes are made to fix this:
msm_gem_shrinker_cleanup() is fixed to unregister the shrinker only
if it was init-ed in the first place.
Before calling kms->funcs->destroy(), we check if kms->funcs is also
non-NULL. This is needed for MDP5, since during msm_drm_int(), priv->kms
becomes non-NULL early, but msm_kms_init() is called on it only later
in mdp5_kms_init().
Signed-off-by: Archit Taneja <[email protected]>
Signed-off-by: Rob Clark <[email protected]>
Reviewed-by: Andy Gross <[email protected]>
|
|
Signed-off-by: Jike Song <[email protected]>
Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
The user of page_track might needs extra information, so pass
the kvm_page_track_notifier_node to callbacks.
Signed-off-by: Jike Song <[email protected]>
Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
When a memory slot is being moved or removed users of page track
can be notified. So users can drop write-protection for the pages
in that memory slot.
This notifier type is needed by KVMGT to sync up its shadow page
table when memory slot is being moved or removed.
Register the notifier type track_flush_slot to receive memslot move
and remove event.
Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Chen Xiaoguang <[email protected]>
[Squashed commits to avoid bisection breakage and reworded the subject.]
Signed-off-by: Radim Krčmář <[email protected]>
|
|
When low memory doesn't reach HIGHMEM_START (e.g. up to 256MB at PA=0 is
common) and highmem is present above HIGHMEM_START (e.g. on Malta the
RAM overlayed by the IO region is aliased at PA=0x90000000), max_low_pfn
will be initially calculated very large and then clipped down to
HIGHMEM_START.
This causes crashes when reading /sys/kernel/mm/page_idle/bitmap
(i.e. CONFIG_IDLE_PAGE_TRACKING=y) when highmem is disabled. pfn_valid()
will compare against max_mapnr which is derived from max_low_pfn when
there is no highend_pfn set up, and will return true for PFNs right up
to HIGHMEM_START, even though they are beyond the end of low memory and
no page structs will actually exist for these PFNs.
This is fixed by skipping high memory regions when initially calculating
max_low_pfn if highmem is disabled, so it doesn't get clipped too high.
We also clip regions which overlap the highmem boundary when highmem is
disabled, so that max_pfn doesn't extend into highmem either.
Signed-off-by: James Hogan <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14490/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Complement commit 80cbfad79096 ("MIPS: Correct MIPS I FP context
layout") and correct the way Floating Point General registers are stored
in a signal context with MIPS I hardware.
Use the S.D and L.D assembly macros to have pairs of SWC1 instructions
and pairs of LWC1 instructions produced, respectively, in an arrangement
which makes the memory representation of floating-point data passed
compatible with that used by hardware SDC1 and LDC1 instructions, where
available, regardless of the hardware endianness used. This matches the
layout used by r4k_fpu.S, ensuring run-time compatibility for MIPS I
software across all o32 hardware platforms.
Define an EX2 macro to handle exceptions from both hardware instructions
implicitly produced from S.D and L.D assembly macros.
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14477/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Fix a regression introduced with commit 2db9ca0a3551 ("MIPS: Use struct
mips_abi offsets to save FP context") for MIPS I/I FP signal contexts,
by converting save/restore code to the updated internal API. Start FGR
offsets from 0 rather than SC_FPREGS from $a0 and use $a1 rather than
the offset of SC_FPC_CSR from $a0 for the Floating Point Control/Status
Register (FCSR).
Document the new internal API and adjust assembly code formatting for
consistency.
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14476/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Complement commit e50c0a8fa60d ("Support the MIPS32 / MIPS64 DSP ASE.")
and remove the Floating Point Implementation Register (FIR) from the FP
register set recorded in a signal context with MIPS I processors too, in
line with the change applied to r4k_fpu.S.
The `sc_fpc_eir' slot is unused according to our current ABI and the FIR
register is read-only and always directly accessible from user software.
[[email protected]: This is also required because the next commit depends
on it.]
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14475/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Complement commit 0ae8dceaebe3 ("Merge with 2.3.10.") and use the local
`fault' handler to recover from FP sigcontext access violation faults,
like corresponding code does in r4k_fpu.S. The `bad_stack' handler is
in syscall.c and is not suitable here as we want to propagate the error
condition up through the caller rather than killing the thread outright.
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14474/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Sanitize FCSR Cause bit handling, following a trail of past attempts:
* commit 4249548454f7 ("MIPS: ptrace: Fix FP context restoration FCSR
regression"),
* commit 443c44032a54 ("MIPS: Always clear FCSR cause bits after
emulation"),
* commit 64bedffe4968 ("MIPS: Clear [MSA]FPE CSR.Cause after
notify_die()"),
* commit b1442d39fac2 ("MIPS: Prevent user from setting FCSR cause
bits"),
* commit b54d2901517d ("Properly handle branch delay slots in connection
with signals.").
Specifically do not mask these bits out in ptrace(2) processing and send
a SIGFPE signal instead whenever a matching pair of an FCSR Cause and
Enable bit is seen as execution of an affected context is about to
resume. Only then clear Cause bits, and even then do not clear any bits
that are set but masked with the respective Enable bits. Adjust Cause
bit clearing throughout code likewise, except within the FPU emulator
proper where they are set according to IEEE 754 exceptions raised as the
operation emulated executed. Do so so that any IEEE 754 exceptions
subject to their default handling are recorded like with operations
executed by FPU hardware.
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14460/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Complement commit ac9ad83bc318 ("MIPS: prevent FP context set via ptrace
being discarded") and also initialize the FP context whenever FCSR alone
is written with a PTRACE_POKEUSR request addressing FPC_CSR, rather than
along with the full FPU register set in the case of the PTRACE_SETFPREGS
request.
Signed-off-by: Maciej W. Rozycki <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14459/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from TLB dumps on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to
provide the appropriate markers & restore the expected output.
Continuation is also used for the second line of each TLB entry printed
in dump_tlb.c even though it has a newline, since it is a continuation
of the interpretation of the same TLB entry. For example:
[ 46.371884] Index: 0 pgmask=16kb va=77654000 asid=73 gid=00
[ri=0 xi=0 pa=ffc18000 c=5 d=0 v=1 g=0] [ri=0 xi=0 pa=ffc1c000 c=5 d=0 v=1 g=0]
[ 46.385380] Index: 12 pgmask=16kb va=004b4000 asid=73 gid=00
[ri=0 xi=0 pa=00000000 c=0 d=0 v=0 g=0] [ri=0 xi=0 pa=ffb00000 c=5 d=1 v=1 g=0]
Signed-off-by: James Hogan <[email protected]>
Cc: Maciej W. Rozycki <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14444/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from __show_regs() on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to
provide the appropriate markers & restore the expected register output.
Signed-off-by: Paul Burton <[email protected]>
Signed-off-by: Matt Redfearn <[email protected]>
Cc: Maciej W. Rozycki <[email protected]>
Cc: James Hogan <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14432/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from show_code on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to
provide the appropriate markers & restore the expected output.
Signed-off-by: Matt Redfearn <[email protected]>
Cc: Maciej W. Rozycki <[email protected]>
Cc: James Hogan <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14431/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from show_stacktrace on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to
provide the appropriate markers & restore the expected output. Also
start a new line with printk such that the presence of timing
information does not interfere with output.
Signed-off-by: Matt Redfearn <[email protected]>
Cc: Maciej W. Rozycki <[email protected]>
Cc: James Hogan <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14430/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Since commit 4bcc595ccd80 ("printk: reinstate KERN_CONT for printing
continuation lines") the output from show_backtrace on MIPS has been
pretty unreadable due to the lack of KERN_CONT markers. Use pr_cont to
provide the appropriate markers & restore the expected output.
Signed-off-by: Matt Redfearn <[email protected]>
Cc: Maciej W. Rozycki <[email protected]>
Cc: James Hogan <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14429/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Changes introduced to arch/mips/Makefile for the generic kernel resulted
in build errors when making a compressed image if platform-y has multiple
values, like this:
make[2]: *** No rule to make target `alchemy/'.
make[1]: *** [vmlinuz] Error 2
make[1]: Target `_all' not remade because of errors.
make: *** [sub-make] Error 2
make: Target `_all' not remade because of errors.
Fix this by quoting $(platform-y) as it is passed to the Makefile in
arch/mips/boot/compressed/Makefile
Reported-by: kernelci.org bot <[email protected]>
Link: https://storage.kernelci.org/next/next-20161017/mips-gpr_defconfig/build.log
Signed-off-by: Matt Redfearn <[email protected]>
Reviewed-by: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14405/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
The KASLR code requires that the plat_get_fdt() function return the
address of the device tree, and it must be available early in the boot,
before prom_init() is called. Move the code determining the address of
the device tree into plat_get_fdt, and call that from prom_init().
The fdt pointer will be set up by plat_get_fdt() called from
relocate_kernel initially and once the relocated kernel has started,
prom_init() will use it again to determine the address in the relocated
image.
Fixes: eed0eabd12ef ("MIPS: generic: Introduce generic DT-based board support")
Signed-off-by: Matt Redfearn <[email protected]>
Reviewed-by: James Hogan <[email protected]>
Reviewed-by: Paul Burton <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14415/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
If platform code returns a NULL pointer to the FDT, initial_boot_params
will not get set to a valid pointer and attempting to find the /chosen
node in it will cause a NULL pointer dereference and the kernel to crash
immediately on startup - with no output to the console.
Fix this by checking that initial_boot_params is valid before using it.
Fixes: 405bc8fd12f5 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")
Cc: [email protected] # 4.7+
Signed-off-by: Matt Redfearn <[email protected]>
Cc: [email protected]
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14414/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Commit 10b6ea0959de ("MIPS: Malta: Use syscon-reboot driver to reboot")
converted the Malta board to use the generic syscon-reboot driver to
handle reboots, but incorrectly used the value 0x4d rather than 0x42 as
the magic to write to the reboot register.
I also incorrectly believed that syscon/regmap would default to native
endianness, but this isn't the case. Force this by specifying with a
native-endian property in the devicetree.
Signed-off-by: Paul Burton <[email protected]>
Fixes: 10b6ea0959de ("MIPS: Malta: Use syscon-reboot driver to reboot")
Reported-by: Guenter Roeck <[email protected]>
Cc: [email protected]
Tested-by: Guenter Roeck <[email protected]>
Tested-by: Maciej W. Rozycki <[email protected]>
Patchwork: https://patchwork.linux-mips.org/patch/14396/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Provide a default implementation of mips_cpc_default_phys_base() which
simply returns 0, and adjust mips_cpc_phys_base() to allow for
mips_cpc_default_phys_base() returning 0. This allows kernels which
include CPC support to be built without platform code & simply ignore
the CPC if it wasn't already enabled by the bootloader.
This fixes link failures such as the following from generic defconfigs:
arch/mips/built-in.o: In function `mips_cpc_phys_base':
arch/mips/kernel/mips-cpc.c:47: undefined reference to `mips_cpc_default_phys_base'
[[email protected]: changed prototype for coding style compliance.]
Signed-off-by: Paul Burton <[email protected]>
Reported-by: kbuild test robot <[email protected]>
Cc: [email protected]
Patchwork: https://patchwork.linux-mips.org/patch/14401/
Signed-off-by: Ralf Baechle <[email protected]>
|
|
Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.
Signed-off-by: Oliver Neukum <[email protected]>
CC: [email protected]
Signed-off-by: Jiri Kosina <[email protected]>
|
|
Fix
drivers/hid/intel-ish-hid/ipc/pci-ish.c:247:12: warning: ‘ish_suspend’ defined but not used [-Wunused-function]
static int ish_suspend(struct device *device)
^
drivers/hid/intel-ish-hid/ipc/pci-ish.c:282:12: warning: ‘ish_resume’ defined but not used [-Wunused-function]
static int ish_resume(struct device *device)
^
by sticking them in the CONFIG_PM range too.
Signed-off-by: Borislav Petkov <[email protected]>
Cc: Srinivas Pandruvada <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Benjamin Tissoires <[email protected]>
Cc: Wei Yongjun <[email protected]>
Cc: [email protected]
Acked-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
|
|
When report count is more than one and report size is not 4 bytes, then we
need some packing into result buffer from the caller of function
sensor_hub_get_feature.
By default the value extracted from a field is 4 bytes from hid core
(using hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT)), even
if report size if less than 4 byte. So when we copy data to user buffer in
sensor_hub_get_feature, we need to only copy report size bytes even
when report count is more than 1. This is
not an issue for most of the sensor hub fields as report count will be 1
where we already copy only report size bytes, but some string fields
like description, it is a problem as the report count will be more than 1.
For example:
Field(6)
Physical(Sensor.OtherCustom)
Application(Sensor.Sensor)
Usage(11)
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Report Size(16)
Report Count(11)
Here since the report size is 2 bytes, we will have 2 additional bytes of
0s copied into user buffer, if we directly copy to user buffer from
report->field[]->value
This change will copy report size bytes into the buffer of caller for each
usage report->field[]->value. So for example without this change, the
data displayed for a custom sensor field "sensor-model":
76 00 101 00 110 00 111 00 118 00 111
(truncated to report count of 11)
With change
76 101 110 111 118 111 32 89 111 103 97
("Lenovo Yoga" in ASCII )
Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Jiri Kosina <[email protected]>
|
|
We used to use generic implementation of dma_map_ops.mmap which is
dma_common_mmap() but that only worked for simpler cached mappings when
vaddr = paddr.
If a driver requests uncached DMA buffer kernel maps it to virtual
address so that MMU gets involved and page uncached status takes into
account. In that case usage of dma_common_mmap() lead to mapping of
vaddr to vaddr for user-space which is obviously wrong. For more detals
please refer to verbose explanation here [1].
So here we implement our own version of mmap() which always deals
with dma_addr and maps underlying memory to user-space properly
(note that DMA buffer mapped to user-space is always uncached
because there's no way to properly manage cache from user-space).
[1] https://lkml.org/lkml/2016/10/26/973
Reviewed-by: Catalin Marinas <[email protected]>
Cc: Marek Szyprowski <[email protected]>
Cc: <[email protected]> #4.5+
Signed-off-by: Alexey Brodkin <[email protected]>
Signed-off-by: Vineet Gupta <[email protected]>
|
|
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: [email protected]
Signed-off-by: Stefan Richter <[email protected]>
|
|
The IP-over-1394 driver firewire-net lacked input validation when
handling incoming fragmented datagrams. A maliciously formed fragment
with a respectively large datagram_offset would cause a memcpy past the
datagram buffer.
So, drop any packets carrying a fragment with offset + length larger
than datagram_size.
In addition, ensure that
- GASP header, unfragmented encapsulation header, or fragment
encapsulation header actually exists before we access it,
- the encapsulated datagram or fragment is of nonzero size.
Reported-by: Eyal Itkin <[email protected]>
Reviewed-by: Eyal Itkin <[email protected]>
Fixes: CVE 2016-8633
Cc: [email protected]
Signed-off-by: Stefan Richter <[email protected]>
|
|
On some benchmarks (e.g. netperf with ioeventfd disabled), APICv
posted interrupts turn out to be slower than interrupt injection via
KVM_REQ_EVENT.
This patch optimizes a bit the IRR update, avoiding expensive atomic
operations in the common case where PI.ON=0 at vmentry or the PIR vector
is mostly zero. This saves at least 20 cycles (1%) per vmexit, as
measured by kvm-unit-tests' inl_from_qemu test (20 runs):
| enable_apicv=1 | enable_apicv=0
| mean stdev | mean stdev
----------|-----------------|------------------
before | 5826 32.65 | 5765 47.09
after | 5809 43.42 | 5777 77.02
Of course, any change in the right column is just placebo effect. :)
The savings are bigger if interrupts are frequent.
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
In sched_show_task() we print out a useless hex number, not even a
symbol, and there's a big question mark whether this even makes sense
anyway, I suspect we should just remove it all.
Signed-off-by: Linus Torvalds <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Link: http://lkml.kernel.org/r/CA+55aFzphURPFzAvU4z6Moy7ZmimcwPuUdYU8bj9z0J+S8X1rw@mail.gmail.com
Signed-off-by: Ingo Molnar <[email protected]>
|
|
When CONFIG_THREAD_INFO_IN_TASK=y, it is possible that an exited thread
remains in the task list after its stack pointer was already set to NULL.
Therefore, thread_saved_pc() and stack_not_used() in sched_show_task()
will trigger NULL pointer dereference if an attempt to dump such thread's
traces (e.g. SysRq-t, khungtaskd) is made.
Since show_stack() in sched_show_task() calls try_get_task_stack() and
sched_show_task() is called from interrupt context, calling
try_get_task_stack() from sched_show_task() will be safe as well.
Signed-off-by: Tetsuo Handa <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: [email protected]
Cc: [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://anongit.freedesktop.org/drm-intel into drm-fixes
batch of scattered i915 fixes.
* tag 'drm-intel-fixes-2016-11-01' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation
drm/i915: Remove two invalid warns
drm/i915: Rotated view does not need a fence
drm/i915/fbc: fix CFB size calculation for gen8+
drm: i915: Wait for fences on new fb, not old
drm/i915: Clean up DDI DDC/AUX CH sanitation
drm/i915: Respect alternate_aux_channel for all DDI ports
drm/i915/gen9: fix watermarks when using the pipe scaler
drm/i915: Fix mismatched INIT power domain disabling during suspend
drm/i915: fix a read size argument
drm/i915: Use fence_write() from rpm resume
drm/i915/gen9: fix DDB partitioning for multi-screen cases
drm/i915: workaround sparse warning on variable length arrays
drm/i915: keep declarations in i915_drv.h
|
|
into drm-fixes
imx-drm plane, build warning, and error handling fixes
- some fixes for active plane reconfiguration support
- hide unused label in case of disabled CONFIG_DRM_FBDEV_EMULATION,
which caused a build warning
- fixed error handling in imx_drm_bind
- disallow odd x/y plane offsets for chroma subsampled formats
- disable local alpha when switching from a format with alpha
channel to an opaque format
* tag 'imx-drm-fixes-20161021' of git://git.pengutronix.de/pza/linux:
drm/imx: ipuv3-plane: disable local alpha for planes without alpha channel
drm/imx: ipuv3-plane: make sure x/y offsets are even in case of chroma subsampling
drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12
drm/imx: drm_dev_alloc() returns error pointers
drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't need modeset
drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset
gpu: ipu-v3: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
drm/imx: hide an unused label
|
|
virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and
because of that it must be called for disabled planes too. Ask
drm_atomic_helper_commit_planes to do that.
v2: update to use new drm_atomic_helper_commit_planes() API.
Signed-off-by: Gerd Hoffmann <[email protected]>
Signed-off-by: Gustavo Padovan <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
|
|
Signed-off-by: Helge Deller <[email protected]>
|
|
LINUX_GATEWAY_ADDR is defined in unistd.h. Let's use it.
Signed-off-by: Helge Deller <[email protected]>
|
|
We have one critical section in the syscall entry path in which we switch from
the userspace stack to kernel stack. In the event of an external interrupt, the
interrupt code distinguishes between those two states by analyzing the value of
sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
the value of sr7 is in sync with the currently enabled stack.
This patch now disables interrupts while executing the critical section. This
prevents the interrupt handler to possibly see an inconsistent state which in
the worst case can lead to crashes.
Interestingly, in the syscall exit path interrupts were already disabled in the
critical section which switches back to the userspace stack.
Cc: <[email protected]>
Signed-off-by: John David Anglin <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
|
|
There is no need to trash sr2 and sr3 in the Light-weight syscall (LWS). sr2
already points to kernel space (it's zero in userspace, otherwise syscalls
wouldn't work), and since the LWS code is executed in userspace, we can simply
ignore to preload sr3.
Signed-off-by: John David Anglin <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
|
|
Recent changes to printk require KERN_CONT uses to continue logging messages.
So add KERN_CONT to output of device inventory.
Signed-off-by: Helge Deller <[email protected]>
|
|
These are never used by the host, but they can still be reflected to
the guest.
Tested-by: Ladi Prosek <[email protected]>
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
The base clock for the LAPIC timer is always CLOCK_MONOTONIC.
Signed-off-by: Paolo Bonzini <[email protected]>
|
|
Most windows guests still utilize APIC Timer periodic/oneshot mode
instead of tsc-deadline mode, and the APIC Timer periodic/oneshot
mode are still emulated by high overhead hrtimer on host. This patch
converts the expected expire time of the periodic/oneshot mode to
guest deadline tsc in order to leverage VMX preemption timer logic
for APIC Timer tsc-deadline mode. After each preemption timer vmexit
preemption timer is restarted to emulate LVTT current-count register
is automatically reloaded from the initial-count register when the
count reaches 0. This patch reduces ~5600 cycles for each APIC Timer
periodic mode operation virtualization.
Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Yunhong Jiang <[email protected]>
Signed-off-by: Wanpeng Li <[email protected]>
[Squashed with my fixes that were reviewed-by Paolo.]
Signed-off-by: Radim Krčmář <[email protected]>
|
|
Rename start/cancel_hv_tscdeadline to start/cancel_hv_timer since
they will handle both APIC Timer periodic/oneshot mode and tsc-deadline
mode.
Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Yunhong Jiang <[email protected]>
Signed-off-by: Wanpeng Li <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
Introdce kvm_get_lapic_target_expiration_tsc() to get APIC Timer target
deadline tsc.
Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Yunhong Jiang <[email protected]>
Signed-off-by: Wanpeng Li <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
Check apic_lvtt_tscdeadline() mode directly instead of apic_lvtt_oneshot()
and apic_lvtt_period() to guarantee the timer is in tsc-deadline mode when
rdmsr MSR_IA32_TSCDEADLINE.
Suggested-by: Radim Krčmář <[email protected]>
Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Yunhong Jiang <[email protected]>
Signed-off-by: Wanpeng Li <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
Extract start_sw_period() to handle periodic/oneshot mode, it will be
used by later patch.
Cc: Paolo Bonzini <[email protected]>
Cc: Radim Krčmář <[email protected]>
Cc: Yunhong Jiang <[email protected]>
Signed-off-by: Wanpeng Li <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
Various kvm vm and vcpu stats are provided via debugfs entries.
Currently there is no way to reset these stats back to zero.
Add the ability to clear (reset back to zero) these stats on a per stat
basis by writing to the debugfs files. Only a write value of 0 is accepted.
Signed-off-by: Suraj Jitindar Singh <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
Since Paolo has removed irq-enable-operation in vmx_handle_external_intr
(KVM: x86: use guest_exit_irqoff), the original comment about the IF bit
in rflags is incorrect and stale now, so remove it.
Signed-off-by: Longpeng(Mike) <[email protected]>
Signed-off-by: Radim Krčmář <[email protected]>
|
|
When a memory slot is being moved or removed users of page track
can be notified. So users can drop write-protection for the pages
in that memory slot.
This notifier type is needed by KVMGT to sync up its shadow page
table when memory slot is being moved or removed.
Register the notifier type track_flush_slot to receive memslot move
and remove event.
Reviewed-by: Xiao Guangrong <[email protected]>
Signed-off-by: Chen Xiaoguang <[email protected]>
[Squashed commits to avoid bisection breakage and reworded the subject.]
Signed-off-by: Radim Krčmář <[email protected]>
|