* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ryusuke/nilfs2:
nilfs2: fix typo "numer" -> "number" in alloc.c
nilfs2: Remove an uninitialization warning in nilfs_btree_propagate_v()
nilfs2: fix a wrong type conversion in nilfs_ioctl()
Otherwise we might be mapping in a page in a new mapping, but that page
(through the swapcache) would later be mapped into an old mapping too.
The page->mapping must be the case that works for everybody, not just
the mapping that happened to page it in first.
Here's the scenario:
- page gets allocated/mapped by process A. Let's call the anon_vma we
associate the page with 'A' to keep it easy to track.
- Process A forks, creating process B. The anon_vma in B is 'B', and has
a chain that looks like 'B' -> 'A'. Everything is fine.
- Swapping happens. The page (with mapping pointing to 'A') gets swapped
out (perhaps not to disk - it's enough to assume that it's just not
mapped any more, and lives entirely in the swap-cache)
- Process B pages it in, which goes like this:
do_swap_page ->
page = lookup_swap_cache(entry);
...
set_pte_at(mm, address, page_table, pte);
page_add_anon_rmap(page, vma, address);
And think about what happens here!
In particular, what happens is that this will now be the "first"
mapping of that page, so page_add_anon_rmap() used to do
if (first)
__page_set_anon_rmap(page, vma, address);
and notice what anon_vma it will use? It will use the anon_vma for
process B!
What happens then? Trivial: process 'A' also pages it in (nothing
happens, it's not the first mapping), and then process 'B' execve's
or exits or unmaps, making anon_vma B go away.
End result: process A has a page that points to anon_vma B, but
anon_vma B does not exist any more. This can go on forever. Forget
about RCU grace periods, forget about locking, forget anything like
that. The bug is simply that page->mapping points to an anon_vma
that was correct at one point, but was _not_ the one that was shared
by all users of that possible mapping.
Changing it to always use the deepest anon_vma in the anonvma chain gets
us to the safest model.
This can be improved in certain cases: if we know the page is private to
just this particular mapping (for example, it's a new page, or it is the
only swapcache entry), we could pick the top (most specific) anon_vma.
But that's a future optimization. Make it _work_ reliably first.
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Borislav Petkov <bp@alien8.de> [ "What do you know, I think you fixed it!" ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We want to walk the chain in reverse order when cloning it, so that the
order of the result chain will be the same as the order in the source
chain. When we add entries to the chain, they go at the head of the
chain, so we want to add the source head last.
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Borislav Petkov <bp@alien8.de> [ "No, it still oopses" ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When we move the boundaries between two vma's due to things like
mprotect, we need to make sure that the anon_vma of the pages that got
moved from one vma to another gets properly copied around. And that was
not always the case, in this rather hard-to-follow code sequence.
Clarify the code, and fix it so that it copies the anon_vma from the
right source.
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Borislav Petkov <bp@alien8.de> [ "Yeah, not so much this one either" ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This changes the anon_vma reuse case to require that we only reuse
simple anon_vma's - ie the case when the vma only has a single anon_vma
associated with it.
This means that a reuse of an anon_vma from an adjacent vma will always
guarantee that both vma's are associated not only with the same
anon_vma, they will also have the same anon_vma chain (of just a single
entry in this case).
And since anon_vma re-use was the only case where the same anon_vma
might be associated with different chains of anon_vma's, we now have the
case that every vma that shares the same anon_vma will always also have
the same chain. That makes it much easier to think about merging vma's
that share the same anon_vma's: you can always just drop the other
anon_vma chain in anon_vma_merge() since you know that they are always
identical.
This also splits up the function to validate the anon_vma re-use, and
adds a lot of commentary about the possible races.
Reviewed-by: Rik van Riel <riel@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Tested-by: Borislav Petkov <bp@alien8.de> [ "That didn't fix it" ]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When filldir returned an error (e.g. buffer full for a large directory),
we would leak a dentry reference, causing an oops on umount.
Signed-off-by: Sage Weil <sage@newdream.net>
dq_flags are modified non-atomically in do_set_dqblk via __set_bit calls and
atomically for example in mark_dquot_dirty or clear_dquot_dirty. Hence a
change done by an atomic operation can be overwritten by a change done by a
non-atomic one. Fix the problem by using atomic bitops even in do_set_dqblk.
Signed-off-by: Andrew Perepechko <andrew.perepechko@sun.com>
Signed-off-by: Jan Kara <jack@suse.cz>
For a root filesystem write to the filesystem before quota is turned on happens
regularly and there's no way around it because of writes to syslog, /etc/mtab,
and similar. So the warning is rather pointless for ordinary users. It's
still useful during development so we just hide the warning behind
__DQUOT_PARANOIA config option.
Signed-off-by: Jan Kara <jack@suse.cz>
generic setattr implementation is no longer responsible for
quota transfer so synlinks must be handled via ext3_setattr.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
generic setattr implementation is no longer responsible for
quota transfer so synlinks must be handled via ext2_setattr.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Jan Kara <jack@suse.cz>
The ebase is relative to CKSEG0 not CAC_BASE. On a 32-bit kernel they
are the same thing, for a 64-bit kernel they are not.
It happens to kind of work on a 64-bit kernel as they both reference
the same physical memory. However since the CPU uses the CKSEG0 base,
determining if a J instruction will reach always gives the wrong result
unless we use the same number the CPU uses.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1093/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
While playing with the out-of-tree MAE driver module, the system would
panic after a while in the db1200 custom wait code after wakeup due to
a clobbered k0 register being used as target address of a store op.
Remove the custom wait implementation and revert back to the Alchemy-
recommended implementation already set as default.
Signed-off-by: Manuel Lauss <manuel.lauss@gmail.com>
To: Linux-MIPS <linux-mips@linux-mips.org>
Patchwork: http://patchwork.linux-mips.org/patch/1092/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit b3594a089f1c17ff919f8f78505c3f20e1f6f8ce (lmo) rsp.
351336929c (kernel.org) break non-GPL modules
that use __vmalloc() or any of the vmap(), vm_map_ram(), etc functions on
MIPS.
All those functions are EXPORT_SYMBOL() so are meant to be allowed to be
used by non-GPL kernel modules. These calls all take page protection as
an argument which is normally a constant like PAGE_KERNEL.
This commit causes all protection constants like PAGE_KERNEL to not be
constants and instead to contain the GPL-only symbol _page_cachable_default.
This means that all calls to __vmalloc(), vmap(), etc, cause non-GPL
modules to fail to link with the complaint that they are trying to use the
GPL-only symbol _page_cachable_default...
Change EXPORT_SYMBOL_GPL(_page_cachable_default) to EXPORT_SYMBOL() for
non-GPL modules that call __vmalloc(), vmap(), vm_map_ram() etc.
Signed-off-by: Anton Altaparmakov <aia21@cantab.net>
Cc: Chris Dearman <chris@mips.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: http://patchwork.linux-mips.org/patch/1084/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Since 2083e8327aeeaf818b0e4522a9d2539835c60423, the SPROM is now registered
in the board_prom_init callback, but it references variables and functions
which are declared below. Move the variables and functions above
board_prom_init.
Signed-off-by: Florian Fainelli <ffainelli@freebox.fr>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1077/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Previously it was unconditionally used on all Sibyte family SOCs. The
M3 bug has to be handled in the TLB exception handler which is extremly
performance sensitive, so this modification is expected to deliver around
2-3% performance improvment. This is important as required changes to the
M3 workaround will make it more costly.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
To avoid a glitch during GPIO initialisation read GPIO output register
values left by the firmware.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/903/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Fix typo: CONFIG_BCMCPU_IS_63xx does not exist;
CONFIG_BCM63XX_CPU_63xx is the valid config option.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
To: linux-mips@linux-mips.org
Cc: Maxime Bizon <mbizon@freebox.fr>
Patchwork: http://patchwork.linux-mips.org/patch/901/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The BCm63xx SOC has two uarts. Some boards use the second one for
bluetooth. This patch changes platform device registration code to
handle this. Changes to the UART driver were already merged in
6a2c7eabfd.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
To: linux-mips@linux-mips.org
Cc: Maxime Bizon <mbizon@freebox.fr>
Patchwork: http://patchwork.linux-mips.org/patch/900/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
bcm63xx_gpio_init is already called from prom_init to allow board to use
them early, so we can remove the unneeded arch_initcall.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
To: linux-mips@linux-mips.org
Cc: Maxime Bizon <mbizon@freebox.fr>
Patchwork: http://patchwork.linux-mips.org/patch/899/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This is a follow on to the vdso patch.
Since all processes now have signal trampolines permanently mapped, we
can use those instead of putting the trampoline on the stack and
invalidating the corresponding icache across all CPUs. We also get rid
of a bunch of ICACHE_REFILLS_WORKAROUND_WAR code.
[Ralf: GDB 7.1 which has the necessary modifications to allow backtracing
over signal frames will supposedly be released tomorrow. The old signal
frame format obsoleted by this patch exists in two variations, for sane
processors and for those requiring ICACHE_REFILLS_WORKAROUND_WAR. So
there was never a GDB which did support backtracing over signal frames
on all MIPS systems. This convinved me this series should be applied and
pushed upstream as soon as possible.]
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/974/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
This is a preliminary patch to add a vdso to all user processes. Still
missing are ELF headers and .eh_frame information. But it is enough to
allow us to move signal trampolines off of the stack. Note that emulation
of branch delay slots in the FPU emulator still requires the stack.
We allocate a single page (the vdso) and write all possible signal
trampolines into it. The stack is moved down by one page and the vdso is
mapped into this space.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/975/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The SSB PCIcore code reused the IO resource fixup code from the original
2.4.x Broadcom patch for BCM47xx based devices, which was a quick hack
for doing PCI IO resource configuration back then (the boot loader
doesn't configure PCI devices on this platform).
However, this code is no longer necessary since the kernel now can do
PCI resource management fine all by itself, so remove the old code.
When removing the code, it becomes obvious that the mem_offset setting
in the PCIcore driver was wrong, however this was masked by the fixup
code before, except in a few cases involving yenta_socket. For BCM47xx,
the correct offset is 0, and since this is the only device using PCIcore
in host mode, the offset can simply be removed unconditionally.
Signed-off-by: Andreas Ferber <af@chaos-agency.de>
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Cc: Markus Wigge <markus@cultcom.de>
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1070/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Seems I trimmed one too many lines in
29ca2d81bd2a62fa86bc9a72ddadcf03d7daf795 (lmo) rsp
7084338eb8 (kernel.org) which led to no
functioning Ethernet on my WAG54Gv2. This patch restores the AWOL line.
Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1065/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Seems in my whitespace cleanup 0f2536082d01448daeced8d9e82c3ba1751fefa3
(lmo) rsp. 8c2961da46abd85a71d20f2b169bf80618e (kernel.org) caused AR7
to no longer get as far as init. Fixed my phat fingering.
Signed-off-by: Alexander Clouter <alex@digriz.org.uk>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1064/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
On Lemote 2F CS5536 MSRs are accessed through a index / data register pair.
The access sequence must be protected by a spinlock to be atomic.
Without this rebooting in fs2f_reboot() may fail.
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: David Daney <ddaney@caviumnetworks.com>
Patchwork: http://patchwork.linux-mips.org/patch/1058/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
kernel/elfcore.c includes <linux/elf.h> which includes the <asm/elf.h>. In
<asm/elf.h>, struct pt_regs is declared inside the parameter list of the
elf_dump_regs function which causes a kernel build warning.
Fixed by adding a forward declaration of struct pt_regs.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
octeon_reserve32_memory is defined In Octeon's setup.c, so remove the
redundant extern declaration of this variable.
Signed-off-by: Yang Shi <yang.shi@windriver.com>
To: f.fainelli@gmail.com
Cc: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1022/
Acked-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Like x86 did in arch/x86/kernel/{process_32.c,process_64.c}, also don't
trace irqsoff for idle.
If there's no useful work to be done, we don't care about the irqsoff
duration. If we trace the idle process, the max duration of irqsoff will
be the idle time and make the irqsoff tracer useless.
Signed-off-by: Wu Zhangjin <wuzhangjin@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>
Patchwork: http://patchwork.linux-mips.org/patch/1044/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The config option CAVIUM_RESERVE32_USE_WIRED_TLB is not supported.
Remove the dead code controlled by it.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
To: linux-mips@linux-mips.org
Patchwork: http://patchwork.linux-mips.org/patch/1028/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Caused by 38b7827fcd - no, cpu_local_* was
not unused.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Cc: Christoph Lameter <cl@linux-foundation.org>
Acked-by: David Daney <ddaney@caviumnetworks.com>
Arnaud Giersch reports that NFSv4 locking is broken when we hold a
delegation since commit 8e469ebd6d (NFSv4:
Don't allow posix locking against servers that don't support it).
According to Arnaud, the lock succeeds the first time he opens the file
(since we cannot do a delegated open) but then fails after we start using
delegated opens.
The following patch fixes it by ensuring that locking behaviour is
governed by a per-filesystem capability flag that is initially set, but
gets cleared if the server ever returns an OPEN without the
NFS4_OPEN_RESULT_LOCKTYPE_POSIX flag being set.
Reported-by: Arnaud Giersch <arnaud.giersch@iut-bm.univ-fcomte.fr>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: stable@kernel.org
This reverts commit 2626419ad5.
It causes regressions for people with IGB cards. Connection
requests don't complete etc. The true cause of the issue is
still not known, but we should sort this out in net-next-2.6
not net-2.6
Signed-off-by: David S. Miller <davem@davemloft.net>
