There is a race in the COW logic. It contains a shortcut to avoid the
COW and reuse the page if we have the sole reference on the page,
however it is possible to have two racing do_wp_page()ers with one
causing the other to mistakenly believe it is safe to take the shortcut
when it is not. This could lead to data corruption.
Process 1 and process2 each have a wp pte of the same anon page (ie.
one forked the other). The page's mapcount is 2. Then they both
attempt to write to it around the same time...
proc1 proc2 thr1 proc2 thr2
CPU0 CPU1 CPU3
do_wp_page() do_wp_page()
trylock_page()
can_share_swap_page()
load page mapcount (==2)
reuse = 0
pte unlock
copy page to new_page
pte lock
page_remove_rmap(page);
trylock_page()
can_share_swap_page()
load page mapcount (==1)
reuse = 1
ptep_set_access_flags (allow W)
write private key into page
read from page
ptep_clear_flush()
set_pte_at(pte of new_page)
Fix this by moving the page_remove_rmap of the old page after the pte
clear and flush. Potentially the entire branch could be moved down
here, but in order to stay consistent, I won't (should probably move all
the *_mm_counter stuff with one patch).
Signed-off-by: Nick Piggin <npiggin@suse.de>
Acked-by: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 89f5b7da2a ("Reinstate ZERO_PAGE
optimization in 'get_user_pages()' and fix XIP") broke vmware, as
reported by Jeff Chua:
"This broke vmware 6.0.4.
Jun 22 14:53:03.845: vmx| NOT_IMPLEMENTED
/build/mts/release/bora-93057/bora/vmx/main/vmmonPosix.c:774"
and the reason seems to be that there's an old bug in how we handle do
FOLL_ANON on VM_SHARED areas in get_user_pages(), but since it only
triggered if the whole page table was missing, nobody had apparently hit
it before.
The recent changes to 'follow_page()' made the FOLL_ANON logic trigger
not just for whole missing page tables, but for individual pages as
well, and exposed this problem.
This fixes it by making the test for when FOLL_ANON is used more
careful, and also makes the code easier to read and understand by moving
the logic to a separate inline function.
Reported-and-tested-by: Jeff Chua <jeff.chua.linux@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I noted that the 'struct tty_struct *real_tty' is not used in this
function, so I removed the code about 'real_tty'.
Signed-off-by: Gustavo Fernando Padovan <gustavo@las.ic.unicamp.br>
Acked-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some of the requirement rules are now more relaxed. Also correct a
contradiction in the previous update
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Current memfree FW has a bug which in some cases, assumes that ICM
pages passed to it are cleared. This patch uses __GFP_ZERO to
allocate all ICM pages passed to the FW. Once firmware with a fix is
released, we can make the workaround conditional on firmware version.
This fixes the bug reported by Arthur Kepner <akepner@sgi.com> here:
http://lists.openfabrics.org/pipermail/general/2008-May/050026.html
Cc: <stable@kernel.org>
Signed-off-by: Eli Cohen <eli@mellanox.co.il>
[ Rewritten to be a one-liner using __GFP_ZERO instead of vmap()ing
ICM memory and memset()ing it to 0. - Roland ]
Signed-off-by: Roland Dreier <rolandd@cisco.com>
This patch addresses a very sporadic pi-futex related failure in
highly threaded java apps on large SMP systems.
David Holmes reported that the pi_state consistency check in
lookup_pi_state triggered with his test application. This means that
the kernel internal pi_state and the user space futex variable are out
of sync. First we assumed that this is a user space data corruption,
but deeper investigation revieled that the problem happend because the
pi-futex code is not handling a fault in the futex_lock_pi path when
the user space variable needs to be fixed up.
The fault happens when a fork mapped the anon memory which contains
the futex readonly for COW or the page got swapped out exactly between
the unlock of the futex and the return of either the new futex owner
or the task which was the expected owner but failed to acquire the
kernel internal rtmutex. The current futex_lock_pi() code drops out
with an inconsistent in case it faults and returns -EFAULT to user
space. User space has no way to fixup that state.
When we wrote this code we thought that we could not drop the hash
bucket lock at this point to handle the fault.
After analysing the code again it turned out to be wrong because there
are only two tasks involved which might modify the pi_state and the
user space variable:
- the task which acquired the rtmutex
- the pending owner of the pi_state which did not get the rtmutex
Both tasks drop into the fixup_pi_state() function before returning to
user space. The first task which acquired the hash bucket lock faults
in the fixup of the user space variable, drops the spinlock and calls
futex_handle_fault() to fault in the page. Now the second task could
acquire the hash bucket lock and tries to fixup the user space
variable as well. It either faults as well or it succeeds because the
first task already faulted the page in.
One caveat is to avoid a double fixup. After returning from the fault
handling we reacquire the hash bucket lock and check whether the
pi_state owner has been modified already.
Reported-by: David Holmes <david.holmes@sun.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: David Holmes <david.holmes@sun.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
kernel/futex.c | 93 ++++++++++++++++++++++++++++++++++++++++++++-------------
1 file changed, 73 insertions(+), 20 deletions(-)
snd_assert() in save_mixer() and restore_mixer() in sb_mixer.c is
just wrong. The debug code wasn't tested at all, obviously...
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The irq handler may be called before the proper initialization of hardware.
Call snd_aw2_saa7146_setup() before the irq handler registration.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The Marvell Discovery Duo (MV78xx0) is a family of ARM SoCs featuring
(depending on the model) one or two Feroceon CPU cores with 512K of L2
cache and VFP coprocessors running at (depending on the model) between
800 MHz and 1.2 GHz, and features a DDR2 controller, two PCIe
interfaces that can each run either in x4 or quad x1 mode, three USB
2.0 interfaces, two 3Gb/s SATA II interfaces, a SPI interface, two
TWSI interfaces, a crypto accelerator, IDMA/XOR engines, a SPI
interface, four UARTs, and depending on the model, two or four gigabit
ethernet interfaces.
This patch adds basic support for the platform, and allows booting
on the MV78x00 development board, with functional UARTs, SATA, PCIe,
GigE and USB ports.
Signed-off-by: Stanislav Samsonov <samsonov@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
The Discovery Duo (MV78xx0) has two x4 PCIe ports which can either
be used in x4 mode or in quad x1 mode. This patch adds an accessor
function to the generic plat-orion PCIe handling code to detect in
which of the two modes we're running (which is determined by strap
pins and/or configured by the bootloader).
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Add support for the Feroceon 88fr571-vd CPU core as found in e.g.
the Marvell Discovery Duo family of ARM SoCs.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
The Marvell Kirkwood (88F6000) is a family of ARM SoCs based on a
Shiva CPU core, and features a DDR2 controller, a x1 PCIe interface,
a USB 2.0 interface, a SPI controller, a crypto accelerator, a TS
interface, and IDMA/XOR engines, and depending on the model, also
features one or two Gigabit Ethernet interfaces, two SATA II
interfaces, one or two TWSI interfaces, one or two UARTs, a
TDM/SLIC interface, a NAND controller, an I2S/SPDIF interface, and
an SDIO interface.
This patch adds supports for the Marvell DB-88F6281-BP Development
Board and the RD-88F6192-NAS and the RD-88F6281 Reference Designs,
enabling support for the PCIe interface, the USB interface, the
ethernet interfaces, the SATA interfaces, the TWSI interfaces, the
UARTs, and the NAND controller.
Signed-off-by: Saeed Bishara <saeed@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Add support for the Shiva 88fr131 CPU core as found in e.g. the
Marvell Kirkwood family of ARM SoCs.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
This patch adds support for the unified Feroceon L2 cache controller
as found in e.g. the Marvell Kirkwood and Marvell Discovery Duo
families of ARM SoCs.
Note that:
- Page table walks are outer uncacheable on Kirkwood and Discovery
Duo, since the ARMv5 spec provides no way to indicate outer
cacheability of page table walks (specifying it in TTBR[4:3] is
an ARMv6+ feature).
This requires adding L2 cache clean instructions to
proc-feroceon.S (dcache_clean_area(), set_pte()) as well as to
tlbflush.h ({flush,clean}_pmd_entry()). The latter case is handled
by defining a new TLB type (TLB_FEROCEON) which is almost identical
to the v4wbi one but provides a TLB_L2CLEAN_FR flag.
- The Feroceon L2 cache controller supports L2 range (i.e. 'clean L2
range by MVA' and 'invalidate L2 range by MVA') operations, and this
patch uses those range operations for all Linux outer cache
operations, as they are faster than the regular per-line operations.
L2 range operations are not interruptible on this hardware, which
avoids potential livelock issues, but can be bad for interrupt
latency, so there is a compile-time tunable (MAX_RANGE_SIZE) which
allows you to select the maximum range size to operate on at once.
(Valid range is between one cache line and one 4KiB page, and must
be a multiple of the line size.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
This patch adds support for the L1 D cache range operations that
are supported by the Marvell Discovery Duo and Marvell Kirkwood
ARM SoCs.
Signed-off-by: Stanislav Samsonov <samsonov@marvell.com>
Acked-by: Saeed Bishara <saeed@marvell.com>
Reviewed-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
The Marvell Loki (88RC8480) is an ARM SoC based on a Feroceon CPU
core running at between 400 MHz and 1.0 GHz, and features a 64 bit
DDR controller, 512K of internal SRAM, two x4 PCI-Express ports,
two Gigabit Ethernet ports, two 4x SAS/SATA controllers, two UARTs,
two TWSI controllers, and IDMA/XOR engines.
This patch adds support for the Marvell LB88RC8480 Development
Board, enabling the use of the PCIe interfaces, the ethernet
interfaces, the TWSI interfaces and the UARTs.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Some Feroceon-based SoCs have an MBUS bridge interrupt controller
that requires writing a one instead of a zero to clear edge
interrupt sources such as timer expiry.
This patch adds a new BRIDGE_INT_TIMER1_CLR define, which platform
code can set to either ~BRIDGE_INT_TIMER1 (write-zero-to-clear) or
BRIDGE_INT_TIMER1 (write-one-to-clear) depending on the platform.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
There are a couple more Feroceon-based SoCs out in the field that use
different Variant and Architecture fields in their Main ID registers
-- this patch tweaks the processor match/mask in proc-feroceon.S to
catch those SoCs as well.
Signed-off-by: Ke Wei <kewei@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Tweak the Feroceon match/mask in arch/arm/boot/compressed/head.S to
match a couple of newer Feroceon cores (such as the 88fr571vd with
CPU ID 0x56155710, and the 88fr131 with CPU ID 0x56251310) as well.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Flushing the L1 D cache with a test/clean/invalidate loop is very
easy in software, but it is not the quickest way of doing it, as
there is a lot of overhead involved in re-scanning the cache from
the beginning every time we hit a dirty line.
This patch makes proc-feroceon.S use "clean+invalidate by set/way"
loops according to possible cache configuration of Feroceon CPUs
(either direct-mapped or 4-way set associative).
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
This patch adds support for the Maxtor Shared Storage II hardware.
Signed-off-by: Sylver Bruneau <sylver.bruneau@googlemail.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
This patch implements the communication with the microcontroller on the
Kurobox Pro and Linkstation Pro/Live boards. This is allowing to send
the commands needed to power-off the board correctly.
Signed-off-by: Sylver Bruneau <sylver.bruneau@googlemail.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
The mv643xx_eth platform data field ->force_phy_addr only needs
to be set if the passed-in ->phy_addr field is zero (to distinguish
the case of not having specified a phy address
(force_phy_addr = 0) from the case where a phy address of zero needs
to be used (force_phy_addr = 1.))
Also, the ->force_phy_addr field will hopefully disappear in a
future mv643xx_eth reorganisation.
Therefore, this patch deletes the ->force_phy_addr field initialiser
from all Orion board code.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
If all PCI devices are working as expected, the error printks in the
various implementations of ->map_irq() doesn't really provide any
useful info. And if something is not working as expected, turning
on pci=debug gives you more useful information than the printk calls
in ->map_irq(), since the former also tells you which devices _did_
get IRQs successfully assigned. Therefore, delete these printks
entirely.
Spotted by Russell King.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
Instead of having board code poke directly into the MPP configuration
registers, and separately calling orion5x_gpio_set_valid_pins() to
indicate which MPP pins can be used as GPIO pins, introduce a helper
function for configuring the roles of each of the MPP pins, and have
that helper function handle gpio validity internally.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Sylver Bruneau <sylver.bruneau@googlemail.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
It makes no sense to do PCIe WA window setup in the individual
board support files while the decision whether or not to use the
PCIe WA access method is made in a different place, in the PCIe
support code.
This patch moves the configuration of a PCIe WA window from the
individual Orion board support files to the central Orion PCIe
support code.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
This patch moves initialisation of EHCI/I2C/UART platform devices
from the common orion5x_init() into the board support code.
The rationale behind this is that only the board support code knows
whether certain peripherals have been brought out on the board, and
not initialising peripherals that haven't been brought out is
desirable for example:
- to reduce user confusion (e.g. seeing both 'eth0' and 'eth1'
appear while there is only one ethernet port on the board); and
- to allow for future power savings (peripherals that have not
been brought out can be clock gated off entirely).
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
This define isn't used anywhere in the kernel tree -- nuke it.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
Make it clear that Orion top-level IRQs are level-triggered. This
means that we don't need an ->ack() handler, or at least, we don't
need the ->ack() handler (or the acking part of the ->mask_ack()
handler) to actually do anything.
Given that, we might as well point our ->mask_ack() handler at the
->mask() handler instead of providing a dummy ->ack() handler, since
providing a ->mask_ack() handler on level IRQ sources will prevent
->ack() from ever being called.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
Annotate the entries for the 88fr531-vd CPU core in
arch/arm/boot/compressed/head.S and arch/arm/mm/proc-feroceon.S
with the full name of the core.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
The DRAM base address and size fields in the CPU's MBUS bridge have
64KiB granularity, instead of the currently used 16MiB. Since all
of the currently supported MBUS peripherals support 64KiB granularity
as well, this patch changes the Orion address map code to stop
rounding base addresses down and sizes up to multiples of 16MiB.
Found by Ke Wei <kewei@marvell.com>.
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
Currently, Orion window setup uses hardcoded window indexes for each
of the boot/cs0/cs1/cs2/PCIe WA windows. The static window allocation
used can clash if board support code will ever attempt to configure
both a dev2 and a PCIe WA window, as both of those use CPU mbus window
#7 at present.
This patch keeps track of the last used window, and opens subsequently
requested windows sequentially, starting from 4. (Windows 0-3 are used
as MEM/IO windows for the PCI/PCIe buses.)
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
More cosmetic cleanup:
- Replace 8-space indents by proper tab indents.
- In structure initialisers, use a trailing comma for every member.
- Collapse "},\n{" in structure initialiers to "}, {".
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Acked-by: Russell King <linux@arm.linux.org.uk>
This is a natural extension following the previous patch.
Non Feroceon based targets are unchanged.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
The implementation for memory copy functions on ARM had a (disabled)
provision for aligning the source pointer before loading registers with
data. Turns out that aligning the _destination_ pointer is much more
useful, as the read side is already sufficiently helped with the use of
preload.
So this changes the definition of the CALGN() macro to target the
destination pointer instead, and turns it on for Feroceon processors
where the gain is very noticeable.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
This code is currently disabled, which explains why no one was affected.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
Linus Torvalds