Move the OOM killer's extern function prototypes to include/linux/oom.h and
include it where necessary.

[clg@fr.ibm.com: build fix]
Cc: Andrea Arcangeli <andrea@suse.de>
Acked-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

provide BDI constructor/destructor hooks

[akpm@linux-foundation.org: compile fix]
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Move AGP and DRM menus into the video graphics support menu.
  They use 'menuconfig' so that they can all be disabled with
  one selection.
Make the console menu use 'menuconfig' so that it can all be
  disabled with one selection.
Make the frame buffer menu use 'menuconfig' so that it can all be
  disabled with one selection.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NAntonino Daplas <adaplas@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Various console drivers are able to resize the screen via the con_resize()
hook.  This hook is also visible in userspace via the TIOCWINSZ, VT_RESIZE and
VT_RESIZEX ioctl's.  One particular utility, SVGATextMode, expects that
con_resize() of the VGA console will always return success even if the
resulting screen is not compatible with the hardware.  However, this
particular behavior of the VGA console, as reported in Kernel Bugzilla Bug
7513, can cause undefined behavior if the user starts with a console size
larger than 80x25.

To work around this problem, add an extra parameter to con_resize().  This
parameter is ignored by drivers except for vgacon.  If this parameter is
non-zero, then the resize request came from a VT_RESIZE or VT_RESIZEX ioctl
and vgacon will always return success.  If this parameter is zero, vgacon will
return -EINVAL if the requested size is not compatible with the hardware.  The
latter is the more correct behavior.

With this change, SVGATextMode should still work correctly while in-kernel and
stty resize calls can expect correct behavior from vgacon.
Signed-off-by: NAntonino Daplas <adaplas@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

radeon_driver_vblank_do_wait() can become static.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The checks for node_online in the uncached allocator are made to make sure
that memory is available on these nodes.  Thus switch all the checks to use
N_HIGH_MEMORY and to N_ONLINE.
Signed-off-by: NChristoph Lameter <clameter@sgi.com>
Signed-off-by: NJes Sorensen <jes@sgi.com>
Acked-by: NLee Schermerhorn <lee.schermerhorn@hp.com>
Acked-by: NBob Picco <bob.picco@hp.com>
Cc: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Mel Gorman <mel@skynet.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The commit b5810039 contains the note

  A last caveat: the ZERO_PAGE is now refcounted and managed with rmap
  (and thus mapcounted and count towards shared rss).  These writes to
  the struct page could cause excessive cacheline bouncing on big
  systems.  There are a number of ways this could be addressed if it is
  an issue.

And indeed this cacheline bouncing has shown up on large SGI systems.
There was a situation where an Altix system was essentially livelocked
tearing down ZERO_PAGE pagetables when an HPC app aborted during startup.
This situation can be avoided in userspace, but it does highlight the
potential scalability problem with refcounting ZERO_PAGE, and corner
cases where it can really hurt (we don't want the system to livelock!).

There are several broad ways to fix this problem:
1. add back some special casing to avoid refcounting ZERO_PAGE
2. per-node or per-cpu ZERO_PAGES
3. remove the ZERO_PAGE completely

I will argue for 3. The others should also fix the problem, but they
result in more complex code than does 3, with little or no real benefit
that I can see.

Why? Inserting a ZERO_PAGE for anonymous read faults appears to be a
false optimisation: if an application is performance critical, it would
not be doing many read faults of new memory, or at least it could be
expected to write to that memory soon afterwards. If cache or memory use
is critical, it should not be working with a significant number of
ZERO_PAGEs anyway (a more compact representation of zeroes should be
used).

As a sanity check -- mesuring on my desktop system, there are never many
mappings to the ZERO_PAGE (eg. 2 or 3), thus memory usage here should not
increase much without it.

When running a make -j4 kernel compile on my dual core system, there are
about 1,000 mappings to the ZERO_PAGE created per second, but about 1,000
ZERO_PAGE COW faults per second (less than 1 ZERO_PAGE mapping per second
is torn down without being COWed). So removing ZERO_PAGE will save 1,000
page faults per second when running kbuild, while keeping it only saves
less than 1 page clearing operation per second. 1 page clear is cheaper
than a thousand faults, presumably, so there isn't an obvious loss.

Neither the logical argument nor these basic tests give a guarantee of no
regressions. However, this is a reasonable opportunity to try to remove
the ZERO_PAGE from the pagefault path. If it is found to cause regressions,
we can reintroduce it and just avoid refcounting it.

The /dev/zero ZERO_PAGE usage and TLB tricks also get nuked.  I don't see
much use to them except on benchmarks.  All other users of ZERO_PAGE are
converted just to use ZERO_PAGE(0) for simplicity. We can look at
replacing them all and maybe ripping out ZERO_PAGE completely when we are
more satisfied with this solution.
Signed-off-by: NNick Piggin <npiggin@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus "snif" Torvalds <torvalds@linux-foundation.org>

0x1106, 0x7204 is unknown and thus is not an IGP/GPU.
0x1106, 0x3304 is K8M800 hostbridge, not an IGP/GPU.
None of them are in drm git tree.
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes sure each blit starts as early as possible, which may improve
texture upload performance in some cases.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Oops...
Signed-off-by: NDave Airlie <airlied@linux.ie>

The data is now in kernel space, copied in/out as appropriate according to t
This results in DRM_COPY_{TO,FROM}_USER going away, and error paths to deal
with those failures.  This also means that XFree86 4.2.0 support for i810 DR
is lost.
Signed-off-by: NDave Airlie <airlied@linux.ie>

These are no longer needed or being used.
Signed-off-by: NDave Airlie <airlied@redhat.com>

As a fallout, replace filp storage with file_priv storage for "unique
identifier of a client" all over the DRM.  There is a 1:1 mapping, so this
should be a noop.  This could be a minor performance improvement, as everyth
on Linux dereferenced filp to get file_priv anyway, while only the mmap ioct
went the other direction.
Signed-off-by: NDave Airlie <airlied@linux.ie>

This was used to make all ioctl handlers return -errno on linux and errno on
*BSD.  Instead, just return -errno in shared code, and flip sign on return f
shared code to *BSD code.
Signed-off-by: NDave Airlie <airlied@linux.ie>

Coverity spotted a "use after free" bug in
drivers/char/agp/amd-k7-agp.c::amd_create_gatt_pages().

The problem is this:
	If "entry = kzalloc(sizeof(struct amd_page_map), GFP_KERNEL);"
fails, then there's a loop in the function to free all entries
allocated so far and break out of the allocation loop. That in itself
is pretty sane, but then the (now freed) 'tables' is assigned to
amd_irongate_private.gatt_pages and 'retval' is set to -ENOMEM which
causes amd_free_gatt_pages(); to be called at the end of the function.
The problem with this is that amd_free_gatt_pages() will then loop
'amd_irongate_private.num_tables' times and try to free each entry in
tables[] - this is bad since tables has already been freed and
furthermore it will call kfree(tables) at the end - a double free.

This patch removes the freeing loop in amd_create_gatt_pages() and
instead relies entirely on the call to amd_free_gatt_pages() to free
everything we allocated in case of an error. It also sets
amd_irongate_private.num_tables to the actual number of entries
allocated instead of just using the value passed in from the caller -
this ensures that amd_free_gatt_pages() will only attempt to free
stuff that was actually allocated.
Signed-off-by: NJesper Juhl <jesper.juhl@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

With Andi's clflush fixup, we were getting hangs on server exit, flushing the
mappings after freeing each page helped.

This showed up a race condition where the pages after being freed could be
reused before the agp mappings had been flushed.  Flushing after each single
page is a bad thing for future drm work, so make the page destroy a two pass
unmapping all the pages, flushing the mappings, and then destroying the pages.
Signed-off-by: NDave Airlie <airlied@linux.ie>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>

... should be unsigned int
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

deal with signedness of the stuff passed to set_bit() et.al.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Convert from class_device to device in drivers/char.
Signed-off-by: NTony Jones <tonyj@suse.de>
Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

struct cdev does not need the kobject name to be set, as it is never
used.  This patch fixes up the few places it is set.
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
Acked-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Now we will only have entries in the device tree for the actual existing
devices (including their OS/400 properties).  This way viotape.c gets
all the information about the devices from the device tree.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

It was only being used to carry around dma_iommu_ops and vio_iommu_table
which we can use directly instead.  This also means that vio_bus_device
doesn't need to refer to them either.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NJens Axboe <jens.axboe@oracle.com>
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Three main sets of changes:

1) dmi_get_system_info() return value should have been marked const,
   since callers should not be changing that data.

2) const-ify DMI internals, since DMI firmware tables should,
   whenever possible, be marked const to ensure we never ever write to
   that data area.

3) const-ify DMI API, to enable marking tables const where possible
   in low-level drivers.

And if we're really lucky, this might enable some additional
optimizations on the part of the compiler.

The bulk of the changes are #2 and #3, which are interrelated.  #1 could
have been a separate patch, but it was so small compared to the others,
it was easier to roll it into this changeset.
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

When building a custom keymap, after setting GENERATE_KEYMAP := 1 in
drivers/char/Makefile, the kernel build fails like this:

    CC      drivers/char/vt.o
  make[2]: *** No rule to make target `drivers/char/%.map', needed by `drivers/char/defkeymap.c'.  Stop.
  make[1]: *** [drivers/char] Error 2
  make: *** [drivers] Error 2

This was caused by commit af8b1287, which
deleted a necessary colon from the Makefile rule that generates the keymap,
since that rule contains both a target and a target-pattern.  The following
patch puts the colon back:
Signed-off-by: NMaarten Bressers <mbres@gentoo.org>
Cc: Yoichi Yuasa <yoichi_yuasa@tripeaks.co.jp>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

We should generally prefer to return ERESTARTNOHAND rather than EINTR,
so that processes with unhandled signals that get ignored don't return
EINTR.

This can help with X startup issues:

    Fatal server error:
    xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call

although the real fix is having the X server always retry EINTR
regardless (since EINTR does happen for signals that have handlers
installed). Keithp has a patch for that.

Regardless, ERESTARTNOHAND is the correct thing to use.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This reverts commit f443675a, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Signed-off-by: NKyle McMartin <kyle@mcmartin.ca>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Zhenyu Wang <zhenyu.z.wang@intel.com>
Acked-by: NKeith Packard <keithp@keithp.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

TCP V4 sequence numbers are 32bits, and RFC 793 assumed a 250 KHz clock.
In order to follow network speed increase, we can use a faster clock, but
we should limit this clock so that the delay between two rollovers is
greater than MSL (TCP Maximum Segment Lifetime : 2 minutes)

Choosing a 64 nsec clock should be OK, since the rollovers occur every
274 seconds.

Problem spotted by Denys Fedoryshchenko

[ This bug was introduced by f8595815 ]
Signed-off-by: NEric Dumazet <dada1@cosmosbay.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When calling the RELDISP VT ioctl, we are reading vt_newvt while the
console workqueue could be messing with it (through change_console()).  We
fix this race by taking the console semaphore before reading vt_newvt.
Signed-off-by: NSamuel Ortiz <sameo@openedhand.com>
Acked-by: NAntonino Daplas <adaplas@gmail.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The new behaviour of CFS exposes a race which occurs if a switch is
requested when vt_mode.mode is VT_PROCESS.

The process with vc->vt_pid is signaled before vc->vt_newvt is set.
This causes the switch to fail when triggered by the monitoing process
because the target is still -1.

[ If the signal sending fails, the subsequent "reset_vc(vc)" will then
  reset vt_newvt to -1, so this works for that case too.   - Linus ]
Signed-off-by: NJan Lübbe <jluebbe@lasnet.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This code is ported from the DRM git tree and allows the vblank interrupts
to function on the i965 hw. It also requires a change in Mesa's 965 driver
to actually use them.

[ Without this patch, my 965GM drops vblank interrupts  - Jesse ]
Signed-off-by: NDave Airlie <airlied@linux.ie>
Acked-by: NJesse Barnes <jesse.barnes@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Following patch silents;

...
drivers/char/hpet.c:72: warning: 'clocksource_hpet' defined but not used
drivers/char/hpet.c:81: warning: 'hpet_clocksource' defined but not used
...

build warnings on i386, they appeared after commit 3b2b64fdSigned-off-by: NS.Çağlar Onur <caglar@pardus.org.tr>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
--
 drivers/char/hpet.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

If hpet has been initialized before registering hpet driver, the callback
function of hpet_resources will return the status code of -EBUSY, which is
not defined in the ACPI exception table.  So when ACPI checks the status
code of callback function, it will report the unknown exception code.

So the status code in ACPI is used instead of the generic error code in the
ACPI callback function of hpet_resources.
For example: -EBUSY is replaced by AE_ALREADY_EXISTS
	     -EINVAL is replaced by AE_NO_MEMORY

http://bugzilla.kernel.org/show_bug.cgi?id=8630Signed-off-by: NZhao Yakui  <yakui.zhao@intel.com>
Signed-off-by: NLen Brown <len.brown@intel.com>

The vma_data structure may be shared by vma's from multiple tasks, with no
way of knowing which areas are shared or not shared, so release/clear pages
only when the refcount (of vma's) goes to zero.
Signed-off-by: NCliff Wickman <cpw@sgi.com>
Cc: Jes Sorensen <jes@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The mask on i830 should be 0x70 always, later chips 0xF0 should be okay.
Signed-off-by: NDave Airlie <airlied@linux.ie>
Acked-by: NZhenyu Wang <zhenyu.z.wang@intel.com>
Cc: Michael Haas <laga@laga.ath.cx>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix a couple drivers that do not correctly terminate their pci_device_id
lists.  This results in garbage being spewed into modules.pcimap when the
module happens to not have 28 NULL bytes following the table, and/or the
last PCI ID is actually truncated from the table when calculating the
modules.alias PCI aliases, cause those unfortunate device IDs to not
auto-load.
Signed-off-by: NKees Cook <kees@ubuntu.com>
Acked-by: NCorey Minyard <minyard@acm.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: NJeff Garzik <jeff@garzik.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

The shrinking of a virtual memory area that is mmap(2)'d to a memory
special file (device drivers/char/mspec.c) can cause a panic.

If the mapped size of the vma (vm_area_struct) is very large, mspec allocates
a large vma_data structure with vmalloc(). But such a vma can be shrunk by
an munmap(2).  The current driver uses the current size of each vma to
deduce whether its vma_data structure was allocated by kmalloc() or vmalloc().
So if the vma was shrunk it appears to have been allocated by kmalloc(),
and mspec attempts to free it with kfree().  This results in a panic.

This patch avoids the panic (by preserving the type of the allocation) and
also makes mspec work correctly as the vma is split into pieces by the
munmap(2)'s.

All vma's derived from such a split vma share the same vma_data structure that
represents all the pages mapped into this set of vma's.  The mpec driver
must be made capable of using the right portion of the structure for each
member vma.  In other words, it must index into the array of page addresses
using the portion of the array that represents the current vma. This is
enabled by storing the vma group's vm_start in the vma_data structure.

The shared vma_data's are not protected by mm->mmap_sem in the fork() case
so the reference count is left as atomic_t.
Signed-off-by: NCliff Wickman <cpw@sgi.com>
Acked-by: NJes Sorensen <jes@sgi.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Add Guards around TIOCSLCKTRMIOS and TIOCGLCKTRMIOS.

Several architectures are still broken.  Put temporary-for-2.6.23 ifdef guards
around the offending code.
Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: N: Linus Torvalds <torvalds@linux-foundation.org>