drm/i915/crt: Remove 0xa0 probe for VGA

This is a moral revert of 6ec3d0c0e9c0c605696e91048eebaca7b0c36695.

Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that the code
is broken. Shock.

There are a number of issues, but following a key insight from Dave
Airlie, that 0xA0 is an invalid address on a 7-bit bus (though not if we
were to enable 10-bit addressing), and would look like the EDID port
0x50, it is possible to see where the confusion starts.

In short, a write to 0xA0 is accepted by the GMBUS controller which we
interpreted as meaning the existence of a connection (a slave on the
other end of the wire ACKing the write). That was false.

During testing with a broken GMBUS implementation, which never reset an
earlier NAK, this test always reported a NAK and so we proceeded on to
the next test.

Reported-and-tested-by: Sitsofe Wheeler <sitsofe@yahoo.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35904
Reported-and-tested-by: Riccardo Magliocchetti <riccardo.magliocchetti@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=32612
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@linux.ie>
Signed-off-by: Keith Packard <keithp@keithp.com>

drm/i915: Reset GMBUS controller after NAK

Once a NAK has been asserted by the slave, we need to reset the GMBUS
controller in order to continue. This is done by asserting the Software
Clear Interrupt bit and then clearing it again to restore operations.

If we don't clear the NAK, then all future GMBUS xfers will fail,
including DDC probes and EDID retrieval.

v2: Add some comments as suggested by Keith Packard.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35781
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: "Mengmeng Meng" <mengmeng.meng@intel.com>

drm/i915: Busy-spin wait_for condition in atomic contexts

During modesetting, we need to wait for the hardware to report
readiness by polling the registers. Normally, we call msleep() between
reads, because some state changes may take a whole vblank or more
to complete. However during a panic, we are in an atomic context and
cannot sleep. Instead, busy spin polling the termination condition.

References: https://bugzilla.kernel.org/show_bug.cgi?id=31772
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

drm/i915/lvds: Always return connected in the absence of better information

The LVDS connector should default to connected. We tried our best to
verify the claims of the BIOS that the hardware exists during init(),
and then during detect() we then try to verify that the panel is open.
In the event of an unsuccessful query, we should then always report
that the LVDS panel is connected. This was only the case for gen2/3,
later generations leaked the return value from the panel probe instead.

Reported-and-tested-by: Alessandro Suardi <alessandro.suardi@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>

Revert "drm/i915: Don't save/restore hardware status page address register"

This reverts commit a7a75c8f70d6f6a2f16c9f627f938bbee2d32718.

There are two different variations on how Intel hardware addresses the
"Hardware Status Page". One as a location in physical memory and the
other as an offset into the virtual memory of the GPU, used in more
recent chipsets. (The HWS itself is a cacheable region of memory which
the GPU can write to without requiring CPU synchronisation, used for
updating various details of hardware state, such as the position of
the GPU head in the ringbuffer, the last breadcrumb seqno, etc).

These two types of addresses were updated in different locations of code
- one inline with the ringbuffer initialisation, and the other during
device initialisation. (The HWS page is logically associated with
the rings, and there is one HWS page per ring.) During resume, only the
ringbuffers were being re-initialised along with the virtual HWS page,
leaving the older physical address HWS untouched. This then caused a
hang on the older gen3/4 (915GM, 945GM, 965GM) the first time we tried
to synchronise the GPU as the breadcrumbs were never being updated.

Reported-and-tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Reported-by: Jan Niehusmann <jan@gondor.com>
Reported-and-tested-by: Justin P. Mattock <justinmattock@gmail.com>
Reported-and-tested-by: Michael "brot" Groh <brot@minad.de>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>

drm/i915: Avoid unmapping pages from a NULL address space

Found by gem_stress.

As we perform retirement from a workqueue, it is possible for us to free
and unbind objects after the last close on the device, and so after the
address space has been torn down and reset to NULL:

BUG: unable to handle kernel NULL pointer dereference at 00000054
IP: [<c1295a20>] mutex_lock+0xf/0x27
*pde = 00000000
Oops: 0002 [#1] SMP
last sysfs file: /sys/module/vt/parameters/default_utf8

Pid: 5, comm: kworker/u:0 Not tainted 2.6.38+ #214
EIP: 0060:[<c1295a20>] EFLAGS: 00010206 CPU: 1
EIP is at mutex_lock+0xf/0x27
EAX: 00000054 EBX: 00000054 ECX: 00000000 EDX: 00012fff
ESI: 00000028 EDI: 00000000 EBP: f706fe20 ESP: f706fe18
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process kworker/u:0 (pid: 5, ti=f706e000 task=f7060d00 task.ti=f706e000)
Stack:
 f5aa3c60 00000000 f706fe74 c107e7df 00000246 dea55380 00000054 f5aa3c60
 f706fe44 00000061 f70b4000 c13fff84 00000008 f706fe54 00000000 00000000
 00012f00 00012fff 00000028 c109e575 f6b36700 00100000 00000000 f706fe90
Call Trace:
 [<c107e7df>] unmap_mapping_range+0x7d/0x1e6
 [<c109e575>] ? mntput_no_expire+0x52/0xb6
 [<c11c12f6>] i915_gem_release_mmap+0x49/0x58
 [<c11c3449>] i915_gem_object_unbind+0x4c/0x125
 [<c11c353f>] i915_gem_free_object_tail+0x1d/0xdb
 [<c11c55a2>] i915_gem_free_object+0x3d/0x41
 [<c11a6be2>] ? drm_gem_object_free+0x0/0x27
 [<c11a6c07>] drm_gem_object_free+0x25/0x27
 [<c113c3ca>] kref_put+0x39/0x42
 [<c11c0a59>] drm_gem_object_unreference+0x16/0x18
 [<c11c0b15>] i915_gem_object_move_to_inactive+0xba/0xbe
 [<c11c0c87>] i915_gem_retire_requests_ring+0x16e/0x1a5
 [<c11c3645>] i915_gem_retire_requests+0x48/0x63
 [<c11c36ac>] i915_gem_retire_work_handler+0x4c/0x117
 [<c10385d1>] process_one_work+0x140/0x21b
 [<c103734c>] ? __need_more_worker+0x13/0x2a
 [<c10373b1>] ? need_to_create_worker+0x1c/0x35
 [<c11c3660>] ? i915_gem_retire_work_handler+0x0/0x117
 [<c1038faf>] worker_thread+0xd4/0x14b
 [<c1038edb>] ? worker_thread+0x0/0x14b
 [<c103be1b>] kthread+0x68/0x6d
 [<c103bdb3>] ? kthread+0x0/0x6d
 [<c12970f6>] kernel_thread_helper+0x6/0x10
Code: 00 e8 98 fe ff ff 5d c3 55 89 e5 3e 8d 74 26 00 ba 01 00 00 00 e8
84 fe ff ff 5d c3 55 89 e5 53 8d 64 24 fc 3e 8d 74 26 00 89 c3 <f0> ff
08 79 05 e8 ab ff ff ff 89 e0 25 00 e0 ff ff 89 43 10 58
EIP: [<c1295a20>] mutex_lock+0xf/0x27 SS:ESP 0068:f706fe18
CR2: 0000000000000054

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>

drm/i915: Fix use after free within tracepoint

Detected by scripts/coccinelle/free/kfree.cocci.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>

drm/i915: Restore missing command flush before interrupt on BLT ring

We always skipped flushing the BLT ring if the request flush did not
include the RENDER domain. However, this neglects that we try to flush
the COMMAND domain after every batch and before the breadcrumb interrupt
(to make sure the batch is indeed completed prior to the interrupt
firing and so insuring CPU coherency). As a result of the missing flush,
incoherency did indeed creep in, most notable when using lots of command
buffers and so potentially rewritting an active command buffer (i.e.
the GPU was still executing from it even though the following interrupt
had already fired and the request/buffer retired).

As all ring->flush routines now have the same preconditions, de-duplicate
and move those checks up into i915_gem_flush_ring().

Fixes gem_linear_blit.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35284
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: mengmeng.meng@intel.com

drm/i915: Disable pagefaults along execbuffer relocation fast path

Along the fast path for relocation handling, we attempt to copy directly
from the user data structures whilst holding our mutex. This causes
lockdep to warn about circular lock dependencies if we need to pagefault
the user pages. [Since when handling a page fault on a mmapped bo, we
need to acquire the struct mutex whilst already holding the mm
semaphore, it is then verboten to acquire the mm semaphore when already
holding the struct mutex. The likelihood of the user passing in the
relocations contained in a GTT mmaped bo is low, but conceivable for
extreme pathology.] In order to force the mm to return EFAULT rather
than handle the pagefault, we therefore need to disable pagefaults
across the relocation fast path.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>

drm/i915: Fix computation of pitch for dumb bo creator

Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: report correct render clock frequencies on SNB

Fix up the debug file to report the right frequencies.  On SNB, we program
the PCU with a frequency ratio, which is multiplied by 100MHz on the CPU
side.  But GFX only runs at half that, so report it as such to avoid
confusion.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>

drm/i915/dp: Correct the order of deletion for ghost eDP devices

The order of the calls does matter indeed.  Swapping the call order of
intel_dp_destroy() and intel_dp_encoder_destroy() fixes the problem.
This is because i2c_del_adapter unregisters the device which parent is
intel_connector, and connectors are removed in intel_dp_destroy().  Thus
intel_dp_encoder_destroy() must be called before intel_dp_destroy().

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>

drm/i915: Fix tiling corruption from pipelined fencing

... even though it was disabled. A mistake in the handling of fence reuse
caused us to skip the vital delay of waiting for the object to finish
rendering before changing the register. This resulted in us changing the
fence register whilst the bo was active and so causing the blits to
complete using the wrong stride or even the wrong tiling. (Visually the
effect is that small blocks of the screen look like they have been
interlaced). The fix is to wait for the GPU to finish using the memory
region pointed to by the fence before changing it.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34584
Cc: Andy Whitcroft <apw@canonical.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Note for 2.6.38-stable, we need to reintroduce the interruptible passing]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Dave Airlie <airlied@linux.ie>

drm/i915: Re-enable self-refresh

A broken implementation of is_pot() prevented the detection of when a
singular pipe was enabled. Eric Anholt pointed out the existence of
is_power_of_2() so use that instead of our broken code!

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=35402
Signed-off-by: Yuanhan Liu <yuanhan.liu@intel.com>
Tested-by: xunx.fang@intel.com
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Prevent racy removal of request from client list

When i915_gem_retire_requests_ring calls i915_gem_request_remove_from_client,
the client_list for that request may already be removed in i915_gem_release.
So we may call twice list_del(&request->client_list), resulting in an
oops like this report:

[126167.230394] BUG: unable to handle kernel paging request at 00100104
[126167.230699] IP: [<f8c2ce44>] i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.231042] *pdpt = 00000000314c1001 *pde = 0000000000000000
[126167.231314] Oops: 0002 [#1] SMP
[126167.231471] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT1/current_now
[126167.231901] Modules linked in: snd_seq_dummy nls_utf8 isofs btrfs zlib_deflate libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs cryptd aes_i586 aes_generic binfmt_misc vboxnetadp vboxnetflt vboxdrv parport_pc ppdev snd_hda_codec_hdmi snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq uvcvideo videodev snd_timer snd_seq_device joydev iwlagn iwlcore mac80211 snd cfg80211 soundcore i915 drm_kms_helper snd_page_alloc psmouse drm serio_raw i2c_algo_bit video lp parport usbhid hid sky2 sdhci_pci ahci sdhci libahci
[126167.232018]
[126167.232018] Pid: 1101, comm: Xorg Not tainted 2.6.38-6-generic-pae #34-Ubuntu Gateway                          MC7833U /
[126167.232018] EIP: 0060:[<f8c2ce44>] EFLAGS: 00213246 CPU: 0
[126167.232018] EIP is at i915_gem_retire_requests_ring+0xd4/0x240 [i915]
[126167.232018] EAX: 00200200 EBX: f1ac25b0 ECX: 00000040 EDX: 00100100
[126167.232018] ESI: f1a2801c EDI: e87fc060 EBP: ef4d7dd8 ESP: ef4d7db0
[126167.232018]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[126167.232018] Process Xorg (pid: 1101, ti=ef4d6000 task=f1ba6500 task.ti=ef4d6000)
[126167.232018] Stack:
[126167.232018]  f1a28000 f1a2809c f1a28094 0058bd97 f1aa2400 f1a2801c 0058bd7b 0058bd85
[126167.232018]  f1a2801c f1a28000 ef4d7e38 f8c2e995 ef4d7e30 ef4d7e60 c14d1ebc f6b3a040
[126167.232018]  f1522cc0 000000db 00000000 f1ba6500 ffffffa1 00000000 00000001 f1a29214
[126167.232018] Call Trace:

Unfortunately the call trace reported was cut, but looking at debug
symbols the crash is at __list_del, when probably list_del is called
twice on the same request->client_list, as the dereferenced value is
LIST_POISON1 + 4, and by looking more at the debug symbols before
list_del call it should have being called by
i915_gem_request_remove_from_client

And as I can see in the code, it seems we indeed have the possibility
to remove a request->client_list twice, which would cause the above,
because we do list_del(&request->client_list) on both
i915_gem_request_remove_from_client and i915_gem_release

As Chris Wilson pointed out, it's indeed the case:
"(...) I had thought that the actual insertion/deletion was serialised
under the struct mutex and the intention of the spinlock was to protect
the unlocked list traversal during throttling. However, I missed that
i915_gem_release() is also called without struct mutex and so we do need
the double check for i915_gem_request_remove_from_client()."

This change does the required check to avoid the duplicate remove of
request->client_list.

Bugzilla: http://bugs.launchpad.net/bugs/733780
Cc: stable@kernel.org # 2.6.38
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: skip redundant operations whilst enabling pipes and planes

If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay. Similarly if it is already disabled
when we want to disable it, we can also skip it.

This fixes a regression from b24e717988, which caused the LVDS
output on one PineView machine to become corrupt after changing
orientation several times.

References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Tested-by: mengmeng.meng@intel.com

drm/i915: Remove surplus POSTING_READs before wait_for_vblank

... as wait_for_vblank (and friends) will do a flush of the MMIO writes
anyway.

References: https://bugs.freedesktop.org/show_bug.cgi?id=34601
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>

drm/kernel: vblank wait on crtc > 1

Below is a patch against drm-next branch of 2.6.38-rc8+ kernel that adds
the capability to wait on vblank events for CRTCs that are greater than 1
and thus cannot be represented with primary/secondary flags in the legacy
interface. It was discussed on the dri-devel list in these two threads:

http://lists.freedesktop.org/archives/dri-devel/2011-March/009009.html
http://lists.freedesktop.org/archives/dri-devel/2011-March/009025.html

This patch extends the interface to drm_wait_vblank ioctl so that crtc>1
can be represented. It also adds a new capability to drm_getcap ioctl so
that the user space can check whether the new interface to drm_wait_vblank
is supported (and fall back to the legacy interface if not)

Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>
Reviewed-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>
Acked-by: Mario Kleiner <mario.kleiner at tuebingen.mpg.de>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Tested-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Fix use-after-free in drm_gem_vm_close()

As we may release the last reference, we need to store the device in a
local variable in order to unlock afterwards.

[   60.140768] BUG: unable to handle kernel paging request at 6b6b6b9f
[   60.140973] IP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111
[   60.141014] *pdpt = 0000000024a54001 *pde = 0000000000000000
[   60.141014] Oops: 0002 [#1] PREEMPT SMP
[   60.141014] last sysfs file: /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0C0A:00/power_supply/BAT0/voltage_now
[   60.141014] Modules linked in: uvcvideo ath9k pegasus ath9k_common ath9k_hw hid_egalax ath3k joydev asus_laptop sparse_keymap battery input_polldev
[   60.141014]
[   60.141014] Pid: 771, comm: meego-ux-daemon Not tainted 2.6.37.2-7.1 #1 EXOPC EXOPG06411/EXOPG06411
[   60.141014] EIP: 0060:[<c1536d11>] EFLAGS: 00010046 CPU: 0
[   60.141014] EIP is at __mutex_unlock_slowpath+0x5a/0x111
[   60.141014] EAX: 00000100 EBX: 6b6b6b9b ECX: e9b4a1b0 EDX: e4a4e580
[   60.141014] ESI: db162558 EDI: 00000246 EBP: e480be50 ESP: e480be44
[   60.141014]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
[   60.141014] Process meego-ux-daemon (pid: 771, ti=e480a000 task=e9b4a1b0 task.ti=e480a000)
[   60.141014] Stack:
[   60.141014]  e4a4e580 db162558 f5a2f838 e480be58 c1536dd0 e480be68 c125ab1b db162558
[   60.141014]  db1624e0 e480be78 c10ba071 db162558 f760241c e480be94 c10bb0bc 000155fe
[   60.141014]  f760241c f5a2f838 f5a2f8c8 00000000 e480bea4 c1037c24 00000000 f5a2f838
[   60.141014] Call Trace:
[   60.141014]  [<c1536dd0>] ? mutex_unlock+0x8/0xa
[   60.141014]  [<c125ab1b>] ? drm_gem_vm_close+0x39/0x3d
[   60.141014]  [<c10ba071>] ? remove_vma+0x2d/0x58
[   60.141014]  [<c10bb0bc>] ? exit_mmap+0x126/0x13f
[   60.141014]  [<c1037c24>] ? mmput+0x37/0x9a
[   60.141014]  [<c10d450d>] ? exec_mmap+0x178/0x19c
[   60.141014]  [<c1537f85>] ? _raw_spin_unlock+0x1d/0x36
[   60.141014]  [<c10d4eb0>] ? flush_old_exec+0x42/0x75
[   60.141014]  [<c1104442>] ? load_elf_binary+0x32a/0x922
[   60.141014]  [<c10d3f76>] ? search_binary_handler+0x200/0x2ea
[   60.141014]  [<c10d3ecf>] ? search_binary_handler+0x159/0x2ea
[   60.141014]  [<c1104118>] ? load_elf_binary+0x0/0x922
[   60.141014]  [<c10d56b2>] ? do_execve+0x1ff/0x2e6
[   60.141014]  [<c100970e>] ? sys_execve+0x2d/0x55
[   60.141014]  [<c1002a5a>] ? ptregs_execve+0x12/0x18
[   60.141014]  [<c10029dc>] ? sysenter_do_call+0x12/0x3c
[   60.141014]  [<c1530000>] ? init_centaur+0x9c/0x1ba
[   60.141014] Code: c1 00 75 0f ba 38 01 00 00 b8 8c 3a 6c c1 e8 cc 2e b0 ff 9c 58 8d 74 26 00 89 c7 fa 90 8d 74 26 00 e8 d2 b4 b2 ff b8 00 01 00 00 <f0> 66 0f c1 43 04 38 e0 74 07 f3 90 8a 43 04 eb f5 83 3d 64 ef
[   60.141014] EIP: [<c1536d11>] __mutex_unlock_slowpath+0x5a/0x111 SS:ESP 0068:e480be44
[   60.141014] CR2: 000000006b6b6b9f

Reported-by: Rusty Lynch <rusty.lynch@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: fixup refcounts in radeon dumb create ioctl.

This was using old gem refcounting methods, fix it to be the same
as the normal create ioctl.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: radeon: *_cs_packet_parse_vline() cleanup

Simplify the way the return value is set a number of times (mostly on
error).

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>

radeon: merge list_del()/list_add_tail() to list_move_tail()

Merge list_del() + list_add_tail() to list_move_tail().

Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge commit '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into drm-core-next

This commit changed an internal radeon structure, that meant a new driver
in -next had to be fixed up, merge in the commit and fix up the driver.

Also fixes a trivial nouveau merge.

Conflicts:
drivers/gpu/drm/nouveau/nouveau_mem.c

drm: Retry i2c transfer of EDID block after failure

Usually EDID retrieval is fine. However, sometimes, especially when the
machine is loaded, it fails, but succeeds after a few retries.

Based on a patch by Michael Buesch.

Reported-by: Michael Buesch <mb@bu3sch.de>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon/kms: fix typo in atom overscan setup

Typo in the aspect scale setup.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm: Hold the mode mutex whilst probing for sysfs status

As detect will use hw registers and may modify structures, it needs to be
serialised by use of the dev->mode_config.mutex. Make it so.

Otherwise, we may cause random crashes as the sysfs file is queried
whilst a concurrent hotplug poll is being run. For example:

[ 1189.189626] BUG: unable to handle kernel NULL pointer dereference at 00000100
[ 1189.189821] IP: [<e0c22019>] intel_tv_detect_type+0xa2/0x203 [i915]
[ 1189.190020] *pde = 00000000
[ 1189.190104] Oops: 0000 [#1] SMP
[ 1189.190209] last sysfs file: /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-SVIDEO-1/status
[ 1189.190412] Modules linked in: mperf cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats decnet uinput fuse loop joydev snd_hd a_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm i915 snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer uvcvideo d rm snd_seq_device eeepc_laptop tpm_tis usbhid videodev i2c_algo_bit v4l1_compat snd sparse_keymap i2c_core hid serio_raw tpm psmouse evdev tpm_bios rfkill shpchp ac processor rng_c ore battery video power_supply soundcore pci_hotplug button output snd_page_alloc usb_storage uas ext3 jbd mbcache sd_mod crc_t10dif ata_generic ahci libahci ata_piix libata uhci_h cd ehci_hcd scsi_mod usbcore thermal atl2 thermal_sys nls_base [last unloaded: scsi_wait_scan]
[ 1189.192007]
[ 1189.192007] Pid: 1464, comm: upowerd Not tainted 2.6.37-2-686 #1 ASUSTeK Computer INC. 701/701
[ 1189.192007] EIP: 0060:[<e0c22019>] EFLAGS: 00010246 CPU: 0
[ 1189.192007] EIP is at intel_tv_detect_type+0xa2/0x203 [i915]
[ 1189.192007] EAX: 00000000 EBX: dca74000 ECX: e0f68004 EDX: 00068004
[ 1189.192007] ESI: dd110c00 EDI: 400c0c37 EBP: dca7429c ESP: de365e2c
[ 1189.192007]  DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[ 1189.192007] Process upowerd (pid: 1464, ti=de364000 task=dcc8acb0 task.ti=de364000)
[ 1189.192007] Stack: Mar 15 03:43:23 hostname kernel: [ 1189.192007]  e0c2cda4 70000000 400c0c30 00000000 dd111000 de365e54 de365f24 dd110c00
[ 1189.192007]  e0c22203 01000000 00000003 00000000 00000000 00000000 00000000 4353544e
[ 1189.192007]  30383420 00000069 00000000 00000000 00000000 00000000 00000000 00000000
[ 1189.192007] Call Trace: Mar 15 03:43:23 hostname kernel: [ 1189.192007]  [<e0c22203>] ?  intel_tv_detect+0x89/0x12d [i915]
[ 1189.192007]  [<e0a9dcef>] ?  status_show+0x0/0x2f [drm]
[ 1189.192007]  [<e0a9dd03>] ?  status_show+0x14/0x2f [drm]

[Digression: what is upowerd doing reading those power hungry files?]

Reported-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge remote branch 'nouveau/drm-nouveau-next' of ../drm-nouveau-next into drm-core-next

* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next:
  drm/nouveau: fix __nouveau_fence_wait performance
  drm/nv40: attempt to reserve just enough vram for all 32 channels
  drm/nv50: check for vm traps on every gr irq
  drm/nv50: decode vm faults some more
  drm/nouveau: add nouveau_enum_find() util function
  drm/nouveau: properly handle pushbuffer check failures
  drm/nvc0: remove vm hack forcing large/small pages to not share a PDE

drm/nouveau: fix __nouveau_fence_wait performance

Commit 21e86c1c8a844bf978f8fc431a59c9f5a578812d ("drm/nouveau: remove
cpu_writers lock") turned on lazy waits. Unfortunately
__nouveau_fence_wait was not optimized for this case and on HZ=100
kernel wasted up to 10 ms per call.

Depending on application, it led to 10-30% FPS regression.

Fix it.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>

drm/nv40: attempt to reserve just enough vram for all 32 channels

This also makes the fact we're giving 512MiB of GART space to all PCIE
boards explicit, although the vast majority (if not all) of them will
now have a ramin_rsvd_vram larger than 2MiB anyway.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nv50: check for vm traps on every gr irq

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nv50: decode vm faults some more

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: add nouveau_enum_find() util function

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau: properly handle pushbuffer check failures

When "buffer in list" check does not pass, don't free validation lists - they were
not initialized yet.

Fixes this oops:

[drm] nouveau 0000:02:00.0: push 105 buffer not in list
BUG: unable to handle kernel NULL pointer dereference at 000000000000057c
IP: [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c
PGD 1ac6cb067 PUD 1aaa52067 PMD 0
CPU 0
Modules linked in: nouveau ttm drm_kms_helper snd_hda_codec_realtek snd_hda_intel snd_hda_codec

Pid: 6265, comm: OilRush_x86 Not tainted 2.6.38-rc6-nv+ #632 System manufacturer System Product Name/P6T SE
RIP: 0010:[<ffffffff81236aa4>]  [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c
(...)
Process OilRush_x86 (pid: 6265, threadinfo ffff8801a6aee000, task ffff8801a26c0000)
 0000000000000000 ffff8801ac74c618 0000000000000000 0000000000000578
 0000000000000000 ffff8801ac74c618 0000000000000000 ffff8801bd9d0000
 [<ffffffff81417f78>] _raw_spin_lock+0x1e/0x22
 [<ffffffffa00a2746>] nouveau_bo_fence+0x2e/0x60 [nouveau]
 [<ffffffffa00a540b>] validate_fini_list+0x35/0xeb [nouveau]
 [<ffffffffa00a54d3>] validate_fini+0x12/0x31 [nouveau]
 [<ffffffffa00a6386>] nouveau_gem_ioctl_pushbuf+0xe94/0xf6b [nouveau]
 [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2
 [<ffffffff81417e94>] ? _raw_spin_unlock_irqrestore+0x30/0x4d
 [<ffffffff8105dea2>] ? __wake_up+0x3f/0x48
 [<ffffffff812aebb4>] drm_ioctl+0x289/0x361
 [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2
 [<ffffffffa00a54f2>] ? nouveau_gem_ioctl_pushbuf+0x0/0xf6b [nouveau]
 [<ffffffff8141ac56>] ? sub_preempt_count+0x9e/0xb2
 [<ffffffffa010caa2>] nouveau_compat_ioctl+0x16/0x1c [nouveau]
 [<ffffffff81142c0d>] compat_sys_ioctl+0x1c8/0x12d7
 [<ffffffff814179ca>] ? trace_hardirqs_off_thunk+0x3a/0x6c
 [<ffffffff81058099>] sysenter_dispatch+0x7/0x30
 [<ffffffff8141798e>] ? trace_hardirqs_on_thunk+0x3a/0x3c
RIP  [<ffffffff81236aa4>] do_raw_spin_lock+0x14/0x13c
 RSP <ffff8801a6aefb88>
---[ end trace 0014d5d93e6147e1 ]---

Additionally, don't call validate_fini twice in case of validation failure.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nvc0: remove vm hack forcing large/small pages to not share a PDE

Appears to be fixed with commit:

"drm/nv50-nvc0: make sure vma is definitely unmapped when destroying bo"

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/i915: disable opregion lid detection for now.

At least on my HP 2540p this is wrong at bootup, fine
at any other time once a lid event has occured. This is due to
_REG vs _INI ordering in the ACPI tables.

Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge remote branch 'intel/drm-intel-next' of ../drm-next into drm-core-next

* 'intel/drm-intel-next' of ../drm-next: (755 commits)
  drm/i915: Only wait on a pending flip if we intend to write to the buffer
  drm/i915/dp: Sanity check eDP existence
  drm/i915: Rebind the buffer if its alignment constraints changes with tiling
  drm/i915: Disable GPU semaphores by default
  drm/i915: Do not overflow the MMADDR write FIFO
  Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"
  drm/i915: Don't save/restore hardware status page address register
  drm/i915: don't store the reg value for HWS_PGA
  drm/i915: fix memory corruption with GM965 and >4GB RAM
  Linux 2.6.38-rc7
  Revert "TPM: Long default timeout fix"
  drm/i915: Re-enable GPU semaphores for SandyBridge mobile
  drm/i915: Replace vblank PM QoS with "Interrupt-Based AGPBUSY#"
  Revert "drm/i915: Use PM QoS to prevent C-State starvation of gen3 GPU"
  drm/i915: Allow relocation deltas outside of target bo
  drm/i915: Silence an innocuous compiler warning for an unused variable
  fs/block_dev.c: fix new kernel-doc warning
  ACPI: Fix build for CONFIG_NET unset
  mm: <asm-generic/pgtable.h> must include <linux/mm_types.h>
  x86: Use u32 instead of long to set reset vector back to 0
  ...

Conflicts:
drivers/gpu/drm/i915/i915_gem.c

drm/radeon: fix problem with changing active VRAM size. (v2)

So we used to use lpfn directly to restrict VRAM when we couldn't
access the unmappable area, however this was removed in
93225b0d7bc030f4a93165347a65893685822d70 as it also restricted
the gtt placements. However it was only later noticed that this
broke on some hw.

This removes the active_vram_size, and just explicitly sets it
when it changes, TTM/drm_mm will always use the real_vram_size,
and the active vram size will change the TTM size used for lpfn
setting.

We should re-work the fpfn/lpfn to per-placement at some point
I suspect, but that is too late for this kernel.

Hopefully this addresses:
https://bugs.freedesktop.org/show_bug.cgi?id=35254

v2: fix reported useful VRAM size to userspace to be correct.

Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: fix page flipping hangs on r300/r400

We've been getting reports of complete system lockups with rv3xx hw on
AGP and PCIE when running gnome-shell or kwin with compositing.

It appears the hw really doesn't like setting these registers while
stuff is running, this moves the setting of the registers into the modeset
since they aren't required to be changed anywhere else.

fixes: https://bugs.freedesktop.org/show_bug.cgi?id=35183

Reported-and-tested-by: Álmos <aaalmosss@gmail.com
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon: add pageflip hooks for fusion

Looks like these got passed over with both being merged at the same
time but not quite meeting in the middle.

should fix: https://bugs.freedesktop.org/show_bug.cgi?id=34137
along with Michael's phoronix article.

Reported-by: Chi-Thanh Christopher Nguyen
Article-written-by: Michael Larabel @ phoronix
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge branch 'media_fixes' of git://git./linux/kernel/git/mchehab/linux-2.6

* 'media_fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6:
  [media] mantis_pci: remove asm/pgtable.h include
  [media] tda829x: fix regression in probe functions
  [media] mceusb: don't claim multifunction device non-IR parts
  [media] nuvoton-cir: fix wake from suspend
  [media] cx18: Add support for Hauppauge HVR-1600 models with s5h1411
  [media] ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hang
  [media] cx25840: fix probing of cx2583x chips
  [media] cx23885: Remove unused 'err:' labels to quiet compiler warning
  [media] cx23885: Revert "Check for slave nack on all transactions"
  [media] DiB7000M: add pid filtering
  [media] Fix sysfs rc protocol lookup for rc-5-sz
  [media] au0828: fix VBI handling when in V4L2 streaming mode
  [media] ir-raw: Properly initialize the IR event (BZ#27202)
  [media] s2255drv: firmware re-loading changes
  [media] Fix double free of video_device in mem2mem_testdev
  [media] DM04/QQBOX memcpy to const char fix

ipmi: Fix IPMI errors due to timing problems

This patch fixes an issue in OpenIPMI module where sometimes an ABORT command
is sent after sending an IPMI request to BMC causing the IPMI request to fail.

Signed-off-by: YiCheng Doe <yicheng.doe@hp.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Acked-by: Tom Mingarelli <thomas.mingarelli@hp.com>
Tested-by: Andy Cress <andy.cress@us.kontron.com>
Tested-by: Mika Lansirine <Mika.Lansirinne@stonesoft.com>
Tested-by: Brian De Wolf <bldewolf@csupomona.edu>
Cc: Jean Michel Audet <Jean-Michel.Audet@ca.Kontron.com>
Cc: Jozef Sudelsky <jozef.sudolsky@elbiahosting.sk>
Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/vfs-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
  fs/dcache: allow d_obtain_alias() to return unhashed dentries
  Check for immutable/append flag in fallocate path
  sysctl: the include of rcupdate.h is only needed in the kernel
  fat: fix d_revalidate oopsen on NFS exports
  jfs: fix d_revalidate oopsen on NFS exports
  ocfs2: fix d_revalidate oopsen on NFS exports
  gfs2: fix d_revalidate oopsen on NFS exports
  fuse: fix d_revalidate oopsen on NFS exports
  ceph: fix d_revalidate oopsen on NFS exports
  reiserfs xattr ->d_revalidate() shouldn't care about RCU
  /proc/self is never going to be invalidated...

Merge branch 'x86-fixes-for-linus' of git://git./linux/kernel/git/tip/linux-2.6-tip

* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86, UV: Initialize the broadcast assist unit base destination node id properly
  x86, numa: Fix numa_emulation code with memory-less node0
  x86, build: Make sure mkpiggy fails on read error

Merge branch 'sched-fixes-for-linus' of git://git./linux/kernel/git/tip/linux-2.6-tip

* 'sched-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  sched: Fix sched rt group scheduling when hierachy is enabled

Merge branch 'perf/urgent' of git://git./linux/kernel/git/tip/linux-2.6-tip

* 'perf/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf symbols: Avoid resolving [kernel.kallsyms] to real path for buildid cache
  perf symbols: Fix vmlinux path when not using --symfs

drm/i915: Revive combination mode for backlight control

This reverts commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb

    drm/i915: Do not handle backlight combination mode specially

since this commit introduced other regressions due to untouched LBPC
register, e.g. the backlight dimmed after resume.

In addition to the revert, this patch includes a fix for the original
issue (weird backlight levels) by removing the wrong bit shift for
computing the current backlight level.
Also, including typo fixes (lpbc -> lbpc).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524
Acked-by: Indan Zupancic <indan@nul.nu>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

fs/dcache: allow d_obtain_alias() to return unhashed dentries

Without this patch, inodes are not promptly freed on last close of an
unlinked file by an nfs client:

client$ mount -tnfs4 server:/export/ /mnt/
client$ tail -f /mnt/FOO
...
server$ df -i /export
server$ rm /export/FOO
(^C the tail -f)
server$ df -i /export
server$ echo 2 >/proc/sys/vm/drop_caches
server$ df -i /export

the df's will show that the inode is not freed on the filesystem until
the last step, when it could have been freed after killing the client's
tail -f. On-disk data won't be deallocated either, leading to possible
spurious ENOSPC.

This occurs because when the client does the close, it arrives in a
compound with a putfh and a close, processed like:

- putfh: look up the filehandle.  The only alias found for the
  inode will be DCACHE_UNHASHED alias referenced by the filp
  this, so it creates a new DCACHE_DISCONECTED dentry and
  returns that instead.
- close: closes the existing filp, which is destroyed
  immediately by dput() since it's DCACHE_UNHASHED.
- end of the compound: release the reference
  to the current filehandle, and dput() the new
  DCACHE_DISCONECTED dentry, which gets put on the
  unused list instead of being destroyed immediately.

Nick Piggin suggested fixing this by allowing d_obtain_alias to return
the unhashed dentry that is referenced by the filp, instead of making it
create a new dentry.

Leave __d_find_alias() alone to avoid changing behavior of other
callers.

Also nfsd doesn't need all the checks of __d_find_alias(); any dentry,
hashed or unhashed, disconnected or not, should work.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Check for immutable/append flag in fallocate path

In the fallocate path the kernel doesn't check for the immutable/append
flag. It's possible to have a race condition in this scenario: an
application open a file in read/write and it does something, meanwhile
root set the immutable flag on the file, the application at that point
can call fallocate with success. In addition, we don't allow to do any
unreserve operation on an append only file but only the reserve one.

Signed-off-by: Marco Stornelli <marco.stornelli@gmail.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

sysctl: the include of rcupdate.h is only needed in the kernel

Fixes this built error:

include/linux/sysctl.h:28: included file 'linux/rcupdate.h' is not exported

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

fat: fix d_revalidate oopsen on NFS exports

can't blindly check nd->flags in ->d_revalidate()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

jfs: fix d_revalidate oopsen on NFS exports

can't blindly check nd->flags in ->d_revalidate()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

ocfs2: fix d_revalidate oopsen on NFS exports

can't blindly check nd->flags in ->d_revalidate()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

gfs2: fix d_revalidate oopsen on NFS exports

can't blindly check nd->flags in ->d_revalidate()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

fuse: fix d_revalidate oopsen on NFS exports

can't blindly check nd->flags in ->d_revalidate()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

ceph: fix d_revalidate oopsen on NFS exports

can't blindly check nd->flags in ->d_revalidate()

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

reiserfs xattr ->d_revalidate() shouldn't care about RCU

... it returns an error unconditionally

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

/proc/self is never going to be invalidated...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc/pseries: Disable VPNH feature
  powerpc/iseries: Fix early init access to lppaca

Merge branch 'for-linus' of git://git./linux/kernel/git/jmorris/security-testing-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6:
  net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules

sysctl: the include of rcupdate.h is only needed in the kernel

Fixes this build-check error:

  include/linux/sysctl.h:28: included file 'linux/rcupdate.h' is not exported

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

net: don't allow CAP_NET_ADMIN to load non-netdev kernel modules

Since a8f80e8ff94ecba629542d9b4b5f5a8ee3eb565c any process with
CAP_NET_ADMIN may load any module from /lib/modules/.  This doesn't mean
that CAP_NET_ADMIN is a superset of CAP_SYS_MODULE as modules are
limited to /lib/modules/**.  However, CAP_NET_ADMIN capability shouldn't
allow anybody load any module not related to networking.

This patch restricts an ability of autoloading modules to netdev modules
with explicit aliases.  This fixes CVE-2011-1019.

Arnd Bergmann suggested to leave untouched the old pre-v2.6.32 behavior
of loading netdev modules by name (without any prefix) for processes
with CAP_SYS_MODULE to maintain the compatibility with network scripts
that use autoloading netdev modules by aliases like "eth0", "wlan0".

Currently there are only three users of the feature in the upstream
kernel: ipip, ip_gre and sit.

    root@albatros:~# capsh --drop=$(seq -s, 0 11),$(seq -s, 13 34) --
    root@albatros:~# grep Cap /proc/$$/status
    CapInh: 0000000000000000
    CapPrm: fffffff800001000
    CapEff: fffffff800001000
    CapBnd: fffffff800001000
    root@albatros:~# modprobe xfs
    FATAL: Error inserting xfs
    (/lib/modules/2.6.38-rc6-00001-g2bf4ca3/kernel/fs/xfs/xfs.ko): Operation not permitted
    root@albatros:~# lsmod | grep xfs
    root@albatros:~# ifconfig xfs
    xfs: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep xfs
    root@albatros:~# lsmod | grep sit
    root@albatros:~# ifconfig sit
    sit: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep sit
    root@albatros:~# ifconfig sit0
    sit0      Link encap:IPv6-in-IPv4
      NOARP  MTU:1480  Metric:1

    root@albatros:~# lsmod | grep sit
    sit                    10457  0
    tunnel4                 2957  1 sit

For CAP_SYS_MODULE module loading is still relaxed:

    root@albatros:~# grep Cap /proc/$$/status
    CapInh: 0000000000000000
    CapPrm: ffffffffffffffff
    CapEff: ffffffffffffffff
    CapBnd: ffffffffffffffff
    root@albatros:~# ifconfig xfs
    xfs: error fetching interface information: Device not found
    root@albatros:~# lsmod | grep xfs
    xfs                   745319  0

Reference: https://lkml.org/lkml/2011/2/24/203

Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Kees Cook <kees.cook@canonical.com>
Signed-off-by: James Morris <jmorris@namei.org>

powerpc/pseries: Disable VPNH feature

This feature triggers nasty races in the scheduler between the
rebuilding of the topology and the load balancing code, causing
the machine to hang.

Disable it for now until the races are fixed.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

powerpc/iseries: Fix early init access to lppaca

The combination of commit

8154c5d22d91cd16bd9985b0638c8957e4688d0e and
93c22703efa72c7527dbd586d1951c1f4a85fd70

Broke boot on iSeries.

The problem is that iSeries very early boot code, which generates
the device-tree and runs before our normal early initializations
does need access the lppaca's very early, before the PACA array is
initialized, and in fact even before the boot PACA has been
initialized (it contains all 0's at this stage).

However, the first patch above makes that code use the new
llpaca_of(cpu) accessor, which itself is changed by the second patch to
use the PACA array.

We fix that by reverting iSeries to directly dereferencing the array. In
addition, we fix all iterators in the iSeries code to always skip CPU
whose number is above 63 which is the maximum size of that array and
the maximum number of supported CPUs on these machines.

Additionally, we make sure the boot_paca is properly initialized
in our early startup code.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Merge branch 'for-2.6.38' of git://linux-nfs.org/~bfields/linux

* 'for-2.6.38' of git://linux-nfs.org/~bfields/linux:
  nfsd: wrong index used in inner loop
  nfsd4: fix bad pointer on failure to find delegation
  NFSD: fix decode_cb_sequence4resok

Merge git://git./linux/kernel/git/wim/linux-2.6-watchdog

* git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog:
  watchdog: sbc_fitpc2_wdt, fix crash on systems without DMI_BOARD_NAME

Merge branch 'for-2639-rc7/i2c-fixes' of git://git.fluff.org/bjdooks/linux

* 'for-2639-rc7/i2c-fixes' of git://git.fluff.org/bjdooks/linux:
  i2c-eg20t: include slab.h for memory allocations
  i2c-ocores: Fix pointer type mismatch error
  i2c-omap: Program I2C_WE on OMAP4 to enable i2c wakeup

alpha: fix compile error from IRQ clean up

Signed-off-by: Matt Turner <mattst88@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'fixes' of git://git./linux/kernel/git/davej/cpufreq

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
  [CPUFREQ] pcc-cpufreq: don't load driver if get_freq fails during init.

Merge branch 'for-linus' of git://git./linux/kernel/git/cjb/mmc

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
  mmc: fix CONFIG_MMC_UNSAFE_RESUME regression

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/vfs-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
  nd->inode is not set on the second attempt in path_walk()
  unfuck proc_sysctl ->d_compare()
  minimal fix for do_filp_open() race

watchdog: sbc_fitpc2_wdt, fix crash on systems without DMI_BOARD_NAME

Some systems don't provide DMI_BOARD_NAME in their DMI tables. Avoid
crash in such situations in fitpc2_wdt_init.

The fix is to check if the dmi_get_system_info return value is NULL.

The oops:
BUG: unable to handle kernel NULL pointer dereference at           (null)
IP: [<ffffffff81253ae6>] strstr+0x26/0xa0
PGD 3966e067 PUD 39605067 PMD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_map
CPU 1
Modules linked in: ...
Pid: 1748, comm: modprobe Not tainted 2.6.37-22-default #1 /Bochs
RIP: 0010:[<ffffffff81253ae6>]  [<ffffffff81253ae6>] strstr+0x26/0xa0
RSP: 0018:ffff88003ad73f18  EFLAGS: 00010206
RAX: 0000000000000000 RBX: 00000000ffffffed RCX: 00000000ffffffff
RDX: ffffffffa003f4cc RSI: ffffffffa003f4c2 RDI: 0000000000000000
...
CR2: 0000000000000000 CR3: 000000003b7ac000 CR4: 00000000000006e0
...
Process modprobe (pid: 1748, threadinfo ffff88003ad72000, task ffff88002e6365c0)
Stack: ...
Call Trace:
 [<ffffffffa004201f>] fitpc2_wdt_init+0x1f/0x13c [sbc_fitpc2_wdt]
 [<ffffffff810002da>] do_one_initcall+0x3a/0x170
...
Code: f3 c3 0f 1f 00 80 3e 00 53 48 89 f8 74 1b 48 89 f2 0f 1f 40 00 48 83 c2 01 80 3a 00 75 f7 49 89 d0 48 89 f8 49 29 f0 75 02 5b c3 <80> 3f 00 74 0e 0f 1f 44 00 00 48 83 c0 01 80 38 00 75 f7 49 89

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

[CPUFREQ] pcc-cpufreq: don't load driver if get_freq fails during init.

Return 0 on failure. This will cause the initialization of the driver
to fail and prevent the driver from loading if the BIOS cannot handle
the PCC interface command to "get frequency". Otherwise, the driver
will load and display a very high value like "4294967274" (which is
actually -EINVAL) for frequency:

# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
4294967274

Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com>
CC: stable@kernel.org
Signed-off-by: Dave Jones <davej@redhat.com>

perf symbols: Avoid resolving [kernel.kallsyms] to real path for buildid cache

kallsyms has a virtual file name [kernel.kallsyms].  Currently, it can't
be added to buildid cache successfully because the code
(build_id_cache__add_s) tries to resolve [kernel.kallsyms] to a real
absolute pathname and that fails.

Fixes it by not resolving it and just use the name [kernel.kallsyms].
So dir ~/.debug/[kernel.kallsyms] is created.

Original bug report at:
https://lkml.org/lkml/2011/3/1/524

Tested-by: Han Pingtian <phan@redhat.com>
Cc: Han Pingtian <phan@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1299165837-27817-1-git-send-email-ming.m.lin@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

x86, UV: Initialize the broadcast assist unit base destination node id properly

The BAU's initialization of the broadcast description header is
lacking the coherence domain (high bits) in the nasid.  This
causes a catastrophic system failure when running on a system
with multiple coherence domains.

Signed-off-by: Cliff Wickman <cpw@sgi.com>
LKML-Reference: <E1PxKBB-0005F0-3U@eag09.americas.sgi.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

nd->inode is not set on the second attempt in path_walk()

We leave it at whatever it had been pointing to after the
first link_path_walk() had failed with -ESTALE.  Things
do not work well after that...

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

nfsd: wrong index used in inner loop

Index i was already used in the outer loop

Cc: stable@kernel.org
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

i2c-eg20t: include slab.h for memory allocations

Fixes (with v2.6.38-rc3/parisc/parisc-allmodconfig):
  src/drivers/i2c/busses/i2c-eg20t.c:720: error: implicit declaration of function 'kzalloc'
  src/drivers/i2c/busses/i2c-eg20t.c:790: error: implicit declaration of function 'kfree'

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Tomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

i2c-ocores: Fix pointer type mismatch error

ocores_i2c_of_probe needs to use a const __be32 type for handing
device tree property values.  This patch fixed the following build
warning:

 CC      drivers/i2c/busses/i2c-ocores.o
  drivers/i2c/busses/i2c-ocores.c: In function 'ocores_i2c_of_probe':
  drivers/i2c/busses/i2c-ocores.c:254: warning: assignment discards qualifiers from pointer target type
  drivers/i2c/busses/i2c-ocores.c:261: warning: assignment discards qualifiers from pointer target type

Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Cc: Ben Dooks <ben-linux@fluff.org>
Cc: linux-i2c@vger.kernel.org
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

mmc: fix CONFIG_MMC_UNSAFE_RESUME regression

30201e7f3 ("mmc: skip detection of nonremovable cards on rescan")
allowed skipping detection of nonremovable cards on mmc_rescan().
The intention was to only skip detection of hardwired cards that
cannot be removed, so make sure this is indeed the case by directly
checking for (lack of) MMC_CAP_NONREMOVABLE, instead of using
mmc_card_is_removable(), which is overloaded with
CONFIG_MMC_UNSAFE_RESUME semantics.

The user-visible symptom of the bug this patch fixes is that no
"mmc: card XXXX removed" message appears in dmesg when a card is
removed and CONFIG_MMC_UNSAFE_RESUME=y.

Reported-and-tested-by: Dmitry Shmidt <dimitrysh@google.com>
Reported-and-tested-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

unfuck proc_sysctl ->d_compare()

a) struct inode is not going to be freed under ->d_compare();
however, the thing PROC_I(inode)->sysctl points to just might.
Fortunately, it's enough to make freeing that sucker delayed,
provided that we don't step on its ->unregistering, clear
the pointer to it in PROC_I(inode) before dropping the reference
and check if it's NULL in ->d_compare().

b) I'm not sure that we *can* walk into NULL inode here (we recheck
dentry->seq between verifying that it's still hashed / fetching
dentry->d_inode and passing it to ->d_compare() and there's no
negative hashed dentries in /proc/sys/*), but if we can walk into
that, we really should not have ->d_compare() return 0 on it!
Said that, I really suspect that this check can be simply killed.
Nick?

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

Linux 2.6.38-rc8

Merge branch 's5p-fixes-for-linus' of git://git./linux/kernel/git/kgene/linux-samsung

* 's5p-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung:
  ARM: S3C64XX: Update regulator names for debugfs compatiblity on SMDK6410
  ARM: S3C64XX: Fix build with WM1190 disabled and WM1192 enabled on SMDK6410
  ARM: S3C64XX: Reduce output of s3c64xx_dma_init1()
  ARM: S3C64XX: Tone down SDHCI debugging
  ARM: S3C64XX: Add clock for i2c1
  ARM: S3C64XX: Staticise non-exported GPIO to interrupt functions
  ARM: SAMSUNG: Include devs.h in dev-uart.c to prototype devices
  ARM: S3C64XX: Fix keypad setup to configure correct number of rows
  ARM: S3C2440: Fix usage gpio bank j pin definitions on GTA02
  ARM: S5P64X0: Fix number of GPIO lines in Bank F
  ARM: S3C2440: Select missing S3C_DEV_USB_HOST on GTA02

Merge branch 'fixes' of /home/rmk/linux-2.6-arm

* 'fixes' of master.kernel.org:/home/rmk/linux-2.6-arm:
  davinci: cpufreq: fix section mismatch warning
  DaVinci: fix compilation warnings in <mach/clkdev.h>
  davinci: tnetv107x: fix register indexing for GPIOs numbers > 31
  davinci: da8xx/omap-l1x: add platform device for davinci-pcm-audio
  ARM: pxa/tosa: register wm9712 codec device
  ARM: pxa: enable pxa-pcm-audio on pxa210/pxa25x platform
  ARM: pxa/colibri: don't register pxa2xx-pcmcia nodes on non-colibri platforms
  ARM: pxa/tosa: drop setting LED trigger name, as it's unsupported now
  ARM: 6762/1: Update number of VIC for S5P6442 and S5PC100
  ARM: 6761/1: Update number of VIC for S5PV210
  ARM: 6768/1: hw_breakpoint: ensure debug logic is powered up on v7 cores
  ARM: 6767/1: ptrace: fix register indexing in GETHBPREGS request
  ARM: 6765/1: remove obsolete comment from asm/mach/arch.h
  ARM: 6757/1: fix tlb.h induced linux/swap.h build failure

Merge branch 'for-linus' of git://git./linux/kernel/git/cjb/mmc

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc:
  mmc: sdio: Allow sdio operations in other threads during sdio_add_func()

Merge branch 'drm-fixes' of git://git./linux/kernel/git/airlied/drm-2.6

* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
  drm: index i shadowed in 2nd loop
  drm/nv50-nvc0: prevent multiple vm/bar flushes occuring simultanenously
  drm/nouveau: fix regression causing ttm to not be able to evict vram
  drm/i915: Rebind the buffer if its alignment constraints changes with tiling
  drm/i915: Disable GPU semaphores by default
  drm/i915: Do not overflow the MMADDR write FIFO
  Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"

drm: index i shadowed in 2nd loop

Index i was already used in thhe first loop

Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

mmc: sdio: Allow sdio operations in other threads during sdio_add_func()

This fixes a bug introduced by 807e8e40673d ("mmc: Fix sd/sdio/mmc
initialization frequency retries") that prevented SDIO drivers from
performing SDIO commands in their probe routines -- the above patch
called mmc_claim_host() before sdio_add_func(), which causes a deadlock
if an external SDIO driver calls sdio_claim_host().

Fix tested on an OLPC XO-1.75 with libertas on SDIO.

Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
Reviewed-and-Tested-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

Merge remote branch 'ickle/drm-intel-fixes' into drm-fixes

* ickle/drm-intel-fixes:
  drm/i915: Rebind the buffer if its alignment constraints changes with tiling
  drm/i915: Disable GPU semaphores by default
  drm/i915: Do not overflow the MMADDR write FIFO
  Revert "drm/i915: fix corruptions on i8xx due to relaxed fencing"

Merge branch 'omap-fixes-for-linus' of git://git./linux/kernel/git/tmlind/linux-omap-2.6

* 'omap-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6:
  omap: mailbox: resolve hang issue
  OMAP2+: PM: SmartReflex: fix memory leaks in Smartreflex driver
  arm: mach-omap2: smartreflex: fix another memory leak

Merge branch 'for-linus' of git://git390.marist.edu/linux-2.6

* 'for-linus' of git://git390.marist.edu/pub/scm/linux-2.6:
  [S390] tape: deadlock on system work queue
  [S390] keyboard: integer underflow bug
  [S390] xpram: remove __initdata attribute from module parameters

drm/nv50-nvc0: prevent multiple vm/bar flushes occuring simultanenously

The per-vm mutex doesn't prevent this completely, a flush coming from the
BAR VM could potentially happen at the same time as one for the channel
VM.  Not to mention that if/when we get per-client/channel VM, this will
happen far more frequently.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/nouveau: fix regression causing ttm to not be able to evict vram

TTM assumes an error condition from man->func->get_node() means that
something went horribly wrong, and causes it to bail.

The driver is supposed to return 0, and leave mm_node == NULL to
signal that it couldn't allocate any memory.

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

nfsd4: fix bad pointer on failure to find delegation

In case of a nonempty list, the return on error here is obviously bogus;
it ends up being a pointer to the list head instead of to any valid
delegation on the list.

In particular, if nfsd4_delegreturn() hits this case, and you're quite unlucky,
then renew_client may oops, and it may take an embarassingly long time to
figure out why.  Facepalm.

BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
IP: [<ffffffff81292965>] nfsd4_delegreturn+0x125/0x200
...

Cc: stable@kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

Merge branch 'drm-intel-fixes' into drm-intel-next

Apply the trivial conflicting regression fixes, but keep GPU semaphores
enabled.

Conflicts:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/i915_gem_execbuffer.c

drm/i915: Only wait on a pending flip if we intend to write to the buffer

... as if we are only reading from it, we can do that concurrently with
the queue flip.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915/dp: Sanity check eDP existence

Some hardware claims to have both an LVDS panel and an eDP output.
Whilst this may be true in a rare case, more often it is just broken
hardware. If we see an eDP device we know that it must be connected and
so we can confirm its existence with a simple probe.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34165
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24822
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Rebind the buffer if its alignment constraints changes with tiling

Early gen3 and gen2 chipset do not have the relaxed per-surface tiling
constraints of the later chipsets, so we need to check that the GTT
alignment is correct for the new tiling. If it is not, we need to
rebind.

Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: Disable GPU semaphores by default

Andi Kleen narrowed his GPU hangs on his Sugar Bay (SNB desktop) rev 09
down to the use of GPU semaphores, and we already know that they appear
broken up to Huron River (mobile) rev 08. (I'm optimistic that disabling
GPU semaphores is simply hiding another bug by the latency and
side-effects of the additional device interaction it introduces...)

However, use of semaphores is a massive performance improvement... Only
as long as the system remains stable. Enable at your peril.

Reported-by: Andi Kleen <andi-fd@firstfloor.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33921
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

i2c-omap: Program I2C_WE on OMAP4 to enable i2c wakeup

For the I2C module to be wakeup capable, programming I2C_WE register (which
was skipped for OMAP4430) is needed even on OMAP4.

This fixes i2c controller timeouts which were seen recently with the static
dependency being cleared between MPU and L4PER clockdomains.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
[ben-linux@fluff.org: re-flowed description]
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

Merge branch 'for-linus' of git://git./linux/kernel/git/tiwai/sound-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
  ALSA: hda - Don't set to D3 in Cirrus errata init verbs
  ALSA: hda - add new Fermi 5xx codec IDs to snd-hda
  ASoC: WM8994: Ensure late enable events are processed for the ADCs
  ASoC: WM8994: Don't disable the AIF[1|2]CLK_ENA unconditionaly
  ASoC: Fix WM9081 platform data initialisation
  ALSA: hda - Fix unable to record issue on ASUS N82JV
  ALSA: HDA: Realtek: Fixup jack detection to input subsystem