smc91c92_cs:
* define multicast_table as unsigned char
* remove unnecessary "#ifndef final_version"
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
At this point optlen == sizeof(sfilter) but some compilers are dumb.
Reported-by: Németh Márton <nm127@freemail.h
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Tx ring buffers after tx_ring->next_to_use are volatile and could
change, possibly causing a crash. Stop cleaning when we hit
tx_ring->next_to_use.
Signed-off-by: Terry Loftin <terry.loftin@hp.com>
Acked-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Restrict Wake-on-LAN to first port on 82576 ET2 quad port NICs, as it is
only supported there.
Signed-off-by: Stefan Assmann <sassmann@redhat.com>
Acked-by: Alexander Duyck <alexander.h.duyck@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The commit 29a4f2d3 used writel() at offset 0x26 which is
half-word aligned causing unaligned exceptions on a
Cortex-A8. The original patch solved the "aaci-pl041 fpga:04:
ac97 read back fail" issue on a soft reset. Reading from any
arbitrary aaci register seems to solve this issue.
Signed-off-by: Philby John <pjohn@mvista.com>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Found by kmemleak.
If request_resource() fails, we leak the struct resource we
allocated to represent the IOMMU mapping area.
This actually happens on sun4v machines because the IOMEM area is only
reported sans the IOMMU region, unlike all previous systems. I'll
need to fix that at some point, but for now fix the leak.
Signed-off-by: David S. Miller <davem@davemloft.net>
The only reference we store to this memory is in the form of a
physical address, so kmemleak can't see it.
Add a kmemleak_not_leak() annotation.
It's probably useful to be able to look at a dump of these things
either via debugfs or similar, and thus we could at some point store
them in some kind of table and therefore get rid of this annotation.
Signed-off-by: David S. Miller <davem@davemloft.net>
This adds support for hardware-assisted userspace irq masking for
special priority levels. Due to the SR.IMASK interactivity, only some
platforms implement this in hardware (including but not limited to
SH-4A interrupt controllers, and ARM-based SH-Mobile CPUs). Each CPU
needs to wire this up on its own, for now only SH7786 is wired up as an
example.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
It's the only way we'll be able to implement the function
graph tracer properly.
A positive is that we no longer have to worry about the
linker over-optimizing the tail call, since we don't
use a tail call any more.
Signed-off-by: David S. Miller <davem@davemloft.net>
This keeps us from having to use kstat_irqs_cpu() from the NMI handler,
the former of which is a profiled function.
Instead we use a currently empty slot in the cpu_data
Signed-off-by: David S. Miller <davem@davemloft.net>
These include the timer implementation, perf events support, and the
performance counter register (pcr) programming layer.
Signed-off-by: David S. Miller <davem@davemloft.net>
Check function_trace_stop at ftrace_caller
Toss mcount_call and dummy call of ftrace_stub, unnecessary.
Document problems we'll have if the final kernel image link
ever turns on relaxation.
Properly size 'ftrace_call' so it looks right when inspecting
instructions under gdb et al.
Signed-off-by: David S. Miller <davem@davemloft.net>
If we are in an NMI then doing a plain raw_local_irq_disable() will
write PIL_NORMAL_MAX into %pil, which is lower than PIL_NMI, and thus
we'll re-enable NMIs and recurse.
Doing a simple:
%pil = %pil | PIL_NORMAL_MAX
does what we want, if we're already at PIL_NMI (15) we leave it at
that setting, else we set it to PIL_NORMAL_MAX (14).
This should get the function tracer working on sparc64.
Signed-off-by: David S. Miller <davem@davemloft.net>
This gets rid of a local function (is_kernel_stack()) which tries to
do the same thing, yet poorly in that it doesn't handle IRQ stacks
properly.
Signed-off-by: David S. Miller <davem@davemloft.net>
Add missing sg_init_table for sg_set_buf in virtio_net which
induced in defer skb patch.
Reported-by: Thomas Müller <thomas@mathtm.de>
Tested-by: Thomas Müller <thomas@mathtm.de>
Signed-off-by: Shirley Ma <xma@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The printk loglevels are all over the place, make them a bit more
coherent, and add some registration notification while we're at it.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* anonvma:
anonvma: when setting up page->mapping, we need to pick the _oldest_ anonvma
anon_vma: clone the anon_vma chain in the right order
vma_adjust: fix the copying of anon_vma chains
Simplify and comment on anon_vma re-use for anon_vma_prepare()
* master.kernel.org:/home/rmk/linux-2.6-arm: (21 commits)
ARM: Fix ioremap_cached()/ioremap_wc() for SMP platforms
ARM: 6043/1: AT91 slow-clock resume: Don't wait for a disabled PLL to lock
ARM: 6031/1: fix Thumb-2 decompressor
ARM: 6029/1: ep93xx: gpio.c: local functions should be static
ARM: 6028/1: ARM: add MAINTAINERS for U300
ARM: 6024/1: bcmring: fix missing down on semaphore in dma.c
MXC: mach_armadillo5x0: Add USB Host support.
ARM mach-mx3: duplicated include
ARM mach-mx3: duplicated include
imx31: add watchdog device on litekit board.
imx3: Add watchdog platform device support
MXC: mach-mx31_3ds: add support for freescale mc13783 power management device.
MXC: mach-mx31_3ds: Add SPI1 device support.
MXC: mach-mx31_3ds: Add support for on board NAND Flash.
MXC: mach-mx31_3ds: Update variable names over recent mach name modification.
imx31: fix parent clock for rtc
i.MX51: remove NFC AXI static mapping
i.MX51: determine silicon revision dynamically
i.MX51: map TZIC dynamically
i.MX51: Use correct clock for gpt
...
* 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
Btrfs: make sure the chunk allocator doesn't create zero length chunks
Btrfs: fix data enospc check overflow
* 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs-2.6:
quota: Fix possible dq_flags corruption
quota: Hide warnings about writes to the filesystem before quota was turned on
ext3: symlink must be handled via filesystem specific operation
ext2: symlink must be handled via filesystem specific operation
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: (36 commits)
MIPS: Calculate proper ebase value for 64-bit kernels
MIPS: Alchemy: DB1200: Remove custom wait implementation
MIPS: Big Sur: Make defconfig more useful.
MIPS: Fix __vmalloc() etc. on MIPS for non-GPL modules
MIPS: Sibyte: Fix M3 TLB exception handler workaround.
MIPS: BCM63xx: Fix build failure in board_bcm963xx.c
MIPS: uasm: Add OR instruction.
MIPS: Sibyte: Apply M3 workaround only on affected chip types and versions.
MIPS: BCM63xx: Initialize gpio_out_low & out_high to current value at boot.
MIPS: BCM63xx: Register SSB SPROM fallback in board's first stage callback
MIPS: BCM63xx: Fix typo in cpu-feature-overrides file.
MIPS: BCM63xx: Add support for second uart.
MIPS: BCM63xx: Fix double gpio registration.
MIPS: BCM63xx: Add DWVS0 board
MIPS: BCM63xx: Add the RTA1025W-16 BCM6348-based board to suppported boards.
MIPS: BCM63xx: Fix BCM6338 and BCM6345 gpio count
MIPS: libgcc.h: Checkpatch cleanup
MIPS: Loongson-2F: Flush the branch target history in BTB and RAS
MIPS: Move signal trampolines off of the stack.
MIPS: Preliminary VDSO
...
* '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()
Presently the sysdevs are simply numbered based on the list position,
without having any direct way of figuring out which controller these are
actually mapping to. This provides a name attr for mapping out the chip
name.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
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>
-tip testing found:
eeepc-wmi.c:(.text+0x36673c): undefined reference to `sparse_keymap_report_event'
drivers/built-in.o: In function `eeepc_wmi_init':
eeepc-wmi.c:(.init.text+0x19cd0): undefined reference to `sparse_keymap_setup'
eeepc-wmi.c:(.init.text+0x19cf0): undefined reference to `sparse_keymap_free'
eeepc-wmi.c:(.init.text+0x19d0b): undefined reference to `sparse_keymap_free'
drivers/built-in.o: In function `eeepc_wmi_exit':
eeepc-wmi.c:(.exit.text+0x2e87): undefined reference to `sparse_keymap_free'
To fix this select INPUT_SPARSEKMAP, like the ASUS driver does.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
We were storing -1 as an unsigned int and as a result the effect of
passing -1 was the same as using 1.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Corentin Chary <corentincj@iksaif.net>
The output of wmi_get_event_data shall be freed before return.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Yong Wang <yong.y.wang@linux.intel.com>
Add backlight support for WMI based Eee PC laptops.
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Corentin Chary <corentincj@iksaif.net>
Add a platform device and use it as the parent device of all sub-devices.
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Corentin Chary <corentincj@iksaif.net>
Add an eeepc_wmi context structure to manage all the sub-devices
that will be implemented later on. Put input device into it first.
Signed-off-by: Yong Wang <yong.y.wang@intel.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Reviewed-by: Corentin Chary <corentincj@iksaif.net>
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>
