Lothar Waßmann [Wed, 3 Jun 2015 06:11:46 +0000 (08:11 +0200)]
Input: edt-ft5x06: prevent using on-stack buffer for I2C transfer
Using this driver with a DMA enabled I2C controller produces the
following warning (with CONFIG_DMA_API_DEBUG enabled):
|at91_i2c f8014000.i2c: DMA-API: device driver maps memory from stack [addr=8f847e29]
Lothar Waßmann [Wed, 3 Jun 2015 05:49:23 +0000 (07:49 +0200)]
i2c: at91: use correct length in dma_unmap_single()
The driver calls dma_map_single() with either 'dev->buf_len' or
'dev->buf_len - 2' as length argument, but always uses 'dev->buf_len'
in dma_unmap_single(). This produces the warning:
at91_i2c f8014000.i2c: DMA-API: device driver frees DMA memory with different size [device address=0x000000002fbf9240] [map size=20 bytes] [unmap size=22 bytes]
with CONFIG_DMA_API_DEBUG enabled.
Use dma_sg_len() as argument for dma_unmap_single() which is always
set to the correct length.
However the feature can be useful for other relatively slow or untrusted
BDIs like USB flash drives and DVD+RW. The patch adds a knob to enable
the feature:
echo 1 > /sys/class/bdi/X:Y/strictlimit
Being enabled, the feature enforces bdi max_ratio limit even if global
(10%) dirty limit is not reached. Of course, the effect is not visible
until /sys/class/bdi/X:Y/max_ratio is decreased to some reasonable value.
Signed-off-by: Maxim Patlasov <MPatlasov@parallels.com> Cc: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Theodore Ts'o <tytso@mit.edu> Cc: "Artem S. Tashkinov" <t.artem@lycos.com> Cc: Mel Gorman <mel@csn.ul.ie> Cc: Jan Kara <jack@suse.cz> Cc: Wu Fengguang <fengguang.wu@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
drivers/w1/w1_int.c: call put_device if device_register fails
Currently, memsetting and kfreeing the device is bad behaviour. The
device will have a reference count of 1 and hence can cause trouble
because it has kfree'd. Proper way to handle a failed device_register is
to call put_device right after it fails.
mtrr, mm, x86: enhance MTRR checks for KVA huge page mapping
This patch adds an additional argument, 'uniform', to mtrr_type_lookup(),
which returns 1 when a given range is covered uniformly by MTRRs, i.e.
the range is fully covered by a single MTRR entry or the default type.
pud_set_huge() and pmd_set_huge() are changed to check the new 'uniform'
flag to see if it is safe to create a huge page mapping to the range.
This allows them to create a huge page mapping to a range covered by a
single MTRR entry of any memory type. It also detects a non-optimal
request properly. They continue to check with the WB type since the WB
type has no effect even if a request spans multiple MTRR entries.
pmd_set_huge() logs a warning message to a non-optimal request so that
driver writers will be aware of such a case. Drivers should make a
mapping request aligned to a single MTRR entry when the range is covered
by MTRRs.
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>
MTRRs contain fixed and variable entries. mtrr_type_lookup() may
repeatedly call __mtrr_type_lookup() to handle a request that overlaps
with variable entries. However, __mtrr_type_lookup() also handles the
fixed entries, which do not have to be repeated. Therefore, this patch
creates separate functions, mtrr_type_lookup_fixed() and
mtrr_type_lookup_variable(), to handle the fixed and variable ranges
respectively.
The patch also updates the function headers to clarify the return values
and output argument. It updates comments to clarify that the repeating is
necessary to handle overlaps with the default type, since overlaps with
multiple entries alone can be handled without such repeating.
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>
mtrr, x86: define MTRR_TYPE_INVALID for mtrr_type_lookup()
mtrr_type_lookup() returns 0xFF when it cannot return a valid MTRR memory
type since MTRRs are disabled. This patch defines MTRR_TYPE_INVALID to
clarify the meaning of this value, and documents its usage.
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>
mtrr, x86: fix MTRR state checks in mtrr_type_lookup()
'mtrr_state.enabled' contains the FE (fixed MTRRs enabled)
and E (MTRRs enabled) flags in MSR_MTRRdefType. Intel SDM,
section 11.11.2.1, defines these flags as follows:
- All MTRRs are disabled when the E flag is clear.
The FE flag has no affect when the E flag is clear.
- The default type is enabled when the E flag is set.
- MTRR variable ranges are enabled when the E flag is set.
- MTRR fixed ranges are enabled when both E and FE flags
are set.
MTRR state checks in __mtrr_type_lookup() do not match with
SDM. Hence, this patch makes the following changes:
- The current code detects MTRRs disabled when both E and
FE flags are clear in mtrr_state.enabled. Fix to detect
MTRRs disabled when the E flag is clear.
- The current code does not check if the FE bit is set in
mtrr_state.enabled when looking into the fixed entries.
Fix to check the FE flag.
- The current code returns the default type when the E flag
is clear in mtrr_state.enabled. However, the default type
is also disabled when the E flag is clear. Fix to remove
the code as this case is handled as MTRR disabled with
the 1st change.
In addition, this patch defines the E and FE flags in
mtrr_state.enabled as follows.
- FE flag: MTRR_STATE_MTRR_FIXED_ENABLED
- E flag: MTRR_STATE_MTRR_ENABLED
print_mtrr_state() is also updated accordingly.
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>
mtrr, x86: remove a wrong address check in __mtrr_type_lookup()
__mtrr_type_lookup() checks MTRR fixed ranges when mtrr_state.have_fixed
is set and start is less than 0x100000. However, the 'else if (start <
0x1000000)' in the code checks with a wrong address as it has an
extra-zero in the address. The code still runs correctly as this check is
meaningless, though.
This patch replaces the wrong address check with 'else' with no condition.
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>
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.