mtrr, x86: fix MTRR lookup to handle inclusive entry
When an MTRR entry is inclusive to a requested range, i.e. the start and
end of the request are not within the MTRR entry range but the range
contains the MTRR entry entirely, __mtrr_type_lookup() ignores such a case
because both start_state and end_state are set to zero.
This bug can cause the following issues:
1) reserve_memtype() tracks an effective memory type in case a request
type is WB (ex. /dev/mem blindly uses WB). Missing to track with its
effective type causes a subsequent request to map the same range with
the effective type to fail.
2) pud_set_huge() and pmd_set_huge() check if a requested range has any
overlap with MTRRs. Missing to detect an overlap may cause a
performance penalty or undefined behavior.
This patch fixes the bug by adding a new flag, 'inclusive', to detect the
inclusive case. This case is then handled in the same way as
(!start_state && end_state). With this fix, __mtrr_type_lookup() handles
the inclusive case properly.
Signed-off-by: Toshi Kani <toshi.kani@hp.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Robert Elliott <Elliott@hp.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
This patchset enhances MTRR checks for the kernel huge I/O mapping, which
was enabled by the patchset below:
https://lkml.org/lkml/2015/3/3/589
The following functional changes are made in patch 7/7.
- Allow pud_set_huge() and pmd_set_huge() to create a huge page
mapping to a range covered by a single MTRR entry of any memory
type.
- Log a pr_warn() message when a specified PMD map range spans more
than a single MTRR entry. Drivers should make a mapping request
aligned to a single MTRR entry when the range is covered by MTRRs.
This patch (of 7):
Document the return values of KVA mapping functions, pud_set_huge(),
pmd_set_huge, pud_clear_huge() and pmd_clear_huge().
Simplify the conditions to select HAVE_ARCH_HUGE_VMAP in the Kconfig,
since X86_PAE depends on X86_32.
There is no functional change in this patch.
Signed-off-by: Toshi Kani <toshi.kani@hp.com> Cc: Dave Hansen <dave.hansen@intel.com> Cc: Robert Elliott <Elliott@hp.com> Cc: Paul Bolle <pebolle@tiscali.nl> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Ben Dooks [Tue, 7 Apr 2015 23:57:07 +0000 (09:57 +1000)]
drivers/rtc/rtc-at91rm9200.c: make IO endian agnostic
Change the __raw IO calls to readl/write_relaxed which makes the driver
endian agnostic to run properly on big endian systems.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Andrew Victor <linux@maxim.org.za> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
drivers/rtc/rtc-s5m.c: allow usage on device type different than main MFD type
The RTC driver supports two flavors of S5M devices: S5M8767-like and
S2MPS14-like.
On S2MPS13 and S2MPS14 devices the RTC module is the same so we want to
re-use the existing support of S2MPS14. However device type was passed
from parent MFD driver in platform data structure. This way for the
S2MPS13 device the main MFD driver passed device type of 'S2MPS13X'.
Instead decouple detecting of device type between main MFD and RTC driver.
This allows adding support for other S2MPS14 variations (like S2MPS11 and
S2MPS13) easily by adding to mfd/sec-core.c:
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# linux-4.0.0-rc3-next-20150313-150225--x86.tar
This patch makes git ignore *.tar files.
Running 'git ls-files -i --exclude-standard' does not show any
tar files excluded from tracking after the change.
Signed-off-by: Andrey Skvortsov <andrej.skvortzov@gmail.com> Cc: Michal Marek <mmarek@suse.cz> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Boaz Harrosh <boaz@plexistor.com> Cc: Andi Kleen <ak@linux.intel.com> Cc: Benjamin Romer <benjamin.romer@unisys.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
prctl: avoid using mmap_sem for exe_file serialization
Oleg cleverly suggested using xchg() to set the new mm->exe_file instead
of calling set_mm_exe_file() which requires some form of serialization --
mmap_sem in this case. For archs that do not have atomic rmw instructions
we still fallback to a spinlock alternative, so this should always be
safe. As such, we only need the mmap_sem for looking up the backing
vm_file, which can be done sharing the lock. Naturally, this means we
need to manually deal with both the new and old file reference counting,
and we need not worry about the MMF_EXE_FILE_CHANGED bits, which can
probably be deleted in the future anyway.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Suggested-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The mm->exe_file is currently serialized with mmap_sem (shared) in order
to both safely (1) read the file and (2) compute the realpath by calling
tomoyo_realpath_from_path, making it an absolute overkill. Good users
will, on the other hand, make use of the more standard get_mm_exe_file(),
requiring only holding the mmap_sem to read the value, and relying on
reference
Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: James Morris <jmorris@namei.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
powerpc/oprofile: reduce mmap_sem hold for exe_file
In the future mm->exe_file will be done without mmap_sem serialization,
thus isolate and reorganize the related code to make the transition
easier. Good users will, make use of the more standard get_mm_exe_file(),
requiring only holding the mmap_sem to read the value, and relying on
reference counting to make sure that the exe file won't dissappear
underneath us while getting the dcookie.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Robert Richter <rric@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
sync_buffer() needs the mmap_sem for two distinct operations, both only
occurring upon user context switch handling:
1) Dealing with the exe_file.
2) Adding the dcookie data as we need to lookup the vma that
backs it. This is done via add_sample() and add_data().
This patch isolates 1), for it will no longer need the mmap_sem for
serialization. However, for now, make of the more standard
get_mm_exe_file(), requiring only holding the mmap_sem to read the value,
and relying on reference counting to make sure that the exe file won't
dissappear underneath us while doing the get dcookie.
As a consequence, for 2) we move the mmap_sem locking into where we really
need it, in lookup_dcookie(). The benefits are twofold: reduce mmap_sem
hold times, and cleaner code.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Cc: Robert Richter <rric@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mips: ip32: add platform data hooks to use DS1685 driver
This modifies the IP32 (SGI O2) platform and reset code to utilize the new
rtc-ds1685 driver. The old mc146818rtc.h header is removed and ip32_defconfig
is updated as well.
projects / karo-tx-linux.git / log