memcg: more mem_cgroup_uncharge() batching

It seems odd that truncate_inode_pages_range(), called not only when
truncating but also when evicting inodes, has mem_cgroup_uncharge_start
and _end() batching in its second loop to clear up a few leftovers, but
not in its first loop that does almost all the work: add them there too.

Signed-off-by: Hugh Dickins <hughd@google.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Acked-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

thp: fix interleaving for transparent hugepages

The THP code didn't pass the correct interleaving shift to the memory
policy code.  Fix this here by adjusting for the order.

Signed-off-by: Andi Kleen <ak@linux.intel.com>
Reviewed-by: Christoph Lameter <cl@linux.com>
Acked-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

aio: fix race between io_destroy() and io_submit()

A race can occur when io_submit() races with io_destroy():

 CPU1 CPU2
io_submit()
  do_io_submit()
    ...
    ctx = lookup_ioctx(ctx_id);
io_destroy()
    Now do_io_submit() holds the last reference to ctx.
    ...
    queue new AIO
    put_ioctx(ctx) - frees ctx with active AIOs

We solve this issue by checking whether ctx is being destroyed in AIO
submission path after adding new AIO to ctx.  Then we are guaranteed that
either io_destroy() waits for new AIO or we see that ctx is being
destroyed and bail out.

Cc: Nick Piggin <npiggin@kernel.dk>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

aio: fix rcu ioctx lookup

aio-dio-invalidate-failure GPFs in aio_put_req from io_submit.

lookup_ioctx doesn't implement the rcu lookup pattern properly.
rcu_read_lock does not prevent refcount going to zero, so we might take
a refcount on a zero count ioctx.

Fix the bug by atomically testing for zero refcount before incrementing.

[jack@suse.cz: added comment into the code]
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Nick Piggin <npiggin@kernel.dk>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: fix dubious code in __count_immobile_pages()

When pfn_valid_within() failed 'iter' was incremented twice.

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/rtc/rtc-ds3232.c: fix time range difference between linux and RTC chip

In linux rtc_time struct, tm_mon range is 0~11, tm_wday range is 0~6,
while in RTC HW REG, month range is 1~12, day of the week range is 1~7,
this patch adjusts difference of them.

The efect of this bug was that most of month will be operated on as the
next month by the hardware (When in Jan it maybe even worse).  For
example, if in May, software wrote 4 to the hardware, which handled it as
April.  Then the logic would be different between software and hardware,
which would cause weird things to happen.

Signed-off-by: Lei Xu <B33228@freescale.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Jack Lan <jack.lan@freescale.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

ldm: corrupted partition table can cause kernel oops

The kernel automatically evaluates partition tables of storage devices.
The code for evaluating LDM partitions (in fs/partitions/ldm.c) contains
a bug that causes a kernel oops on certain corrupted LDM partitions.  A
kernel subsystem seems to crash, because, after the oops, the kernel no
longer recognizes newly connected storage devices.

The patch changes ldm_parse_vmdb() to Validate the value of vblk_size.

Signed-off-by: Timo Warns <warns@pre-sense.de>
Cc: Eugene Teo <eugeneteo@kernel.sg>
Acked-by: Richard Russon <ldm@flatcap.org>
Cc: Harvey Harrison <harvey.harrison@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: vmscan: stop reclaim/compaction earlier due to insufficient progress if !__GFP_REPEAT

should_continue_reclaim() for reclaim/compaction allows scanning to
continue even if pages are not being reclaimed until the full list is
scanned.  In terms of allocation success, this makes sense but potentially
it introduces unwanted latency for high-order allocations such as
transparent hugepages and network jumbo frames that would prefer to fail
the allocation attempt and fallback to order-0 pages.  Worse, there is a
potential that the full LRU scan will clear all the young bits, distort
page aging information and potentially push pages into swap that would
have otherwise remained resident.

This patch will stop reclaim/compaction if no pages were reclaimed in the
last SWAP_CLUSTER_MAX pages that were considered.  For allocations such as
hugetlbfs that use __GFP_REPEAT and have fewer fallback options, the full
LRU list may still be scanned.

Order-0 allocation should not be affected because RECLAIM_MODE_COMPACTION
is not set so the following avoids the gfp_mask being examined:

        if (!(sc->reclaim_mode & RECLAIM_MODE_COMPACTION))
                return false;

A tool was developed based on ftrace that tracked the latency of
high-order allocations while transparent hugepage support was enabled and
three benchmarks were run.  The "fix-infinite" figures are 2.6.38-rc4 with
Johannes's patch "vmscan: fix zone shrinking exit when scan work is done"
applied.

  STREAM Highorder Allocation Latency Statistics
                 fix-infinite     break-early
  1 :: Count            10298           10229
  1 :: Min             0.4560          0.4640
  1 :: Mean            1.0589          1.0183
  1 :: Max            14.5990         11.7510
  1 :: Stddev          0.5208          0.4719
  2 :: Count                2               1
  2 :: Min             1.8610          3.7240
  2 :: Mean            3.4325          3.7240
  2 :: Max             5.0040          3.7240
  2 :: Stddev          1.5715          0.0000
  9 :: Count           111696          111694
  9 :: Min             0.5230          0.4110
  9 :: Mean           10.5831         10.5718
  9 :: Max            38.4480         43.2900
  9 :: Stddev          1.1147          1.1325

Mean time for order-1 allocations is reduced.  order-2 looks increased but
with so few allocations, it's not particularly significant.  THP mean
allocation latency is also reduced.  That said, allocation time varies so
significantly that the reductions are within noise.

Max allocation time is reduced by a significant amount for low-order
allocations but reduced for THP allocations which presumably are now
breaking before reclaim has done enough work.

  SysBench Highorder Allocation Latency Statistics
                 fix-infinite     break-early
  1 :: Count            15745           15677
  1 :: Min             0.4250          0.4550
  1 :: Mean            1.1023          1.0810
  1 :: Max            14.4590         10.8220
  1 :: Stddev          0.5117          0.5100
  2 :: Count                1               1
  2 :: Min             3.0040          2.1530
  2 :: Mean            3.0040          2.1530
  2 :: Max             3.0040          2.1530
  2 :: Stddev          0.0000          0.0000
  9 :: Count             2017            1931
  9 :: Min             0.4980          0.7480
  9 :: Mean           10.4717         10.3840
  9 :: Max            24.9460         26.2500
  9 :: Stddev          1.1726          1.1966

Again, mean time for order-1 allocations is reduced while order-2
allocations are too few to draw conclusions from.  The mean time for THP
allocations is also slightly reduced albeit the reductions are within
varianes.

Once again, our maximum allocation time is significantly reduced for
low-order allocations and slightly increased for THP allocations.

  Anon stream mmap reference Highorder Allocation Latency Statistics
  1 :: Count             1376            1790
  1 :: Min             0.4940          0.5010
  1 :: Mean            1.0289          0.9732
  1 :: Max             6.2670          4.2540
  1 :: Stddev          0.4142          0.2785
  2 :: Count                1               -
  2 :: Min             1.9060               -
  2 :: Mean            1.9060               -
  2 :: Max             1.9060               -
  2 :: Stddev          0.0000               -
  9 :: Count            11266           11257
  9 :: Min             0.4990          0.4940
  9 :: Mean        27250.4669      24256.1919
  9 :: Max      11439211.0000    6008885.0000
  9 :: Stddev     226427.4624     186298.1430

This benchmark creates one thread per CPU which references an amount of
anonymous memory 1.5 times the size of physical RAM.  This pounds swap
quite heavily and is intended to exercise THP a bit.

Mean allocation time for order-1 is reduced as before.  It's also reduced
for THP allocations but the variations here are pretty massive due to
swap.  As before, maximum allocation times are significantly reduced.

Overall, the patch reduces the mean and maximum allocation latencies for
the smaller high-order allocations.  This was with Slab configured so it
would be expected to be more significant with Slub which uses these size
allocations more aggressively.

The mean allocation times for THP allocations are also slightly reduced.
The maximum latency was slightly increased as predicted by the comments
due to reclaim/compaction breaking early.  However, workloads care more
about the latency of lower-order allocations than THP so it's an
acceptable trade-off.

Signed-off-by: Mel Gorman <mel@csn.ul.ie>
Acked-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Johannes Weiner <hannes@cmpxchg.org>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
Acked-by: Andrea Arcangeli <aarcange@redhat.com>
Acked-by: Rik van Riel <riel@redhat.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Kent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/nfc/pn544.c: add missing regulator

The regulator framework is used for power management.  The regulators are
only named in the driver code, the actual control stuff is in the board
file for each architecture or use case.

The PN544 chip has three regulators that can be controlled or not -
depending on the architecture where the chip is being used.  So some of
the regulators may not be controllable.  In our current case the third
regulator, which was missing from the code, went unnoticed because we
didn't need to control it.  To be as general as possible - in this respect
- the driver needs to list all regulators.  Then the board file can be
used to actually set the usage.

Signed-off-by: Matti J. Aaltonen <matti.j.aaltonen@nokia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drivers/nfc/Kconfig: use full form of the NFC acronym

Spell out the NFC acronym when it's shown for the first time.

Signed-off-by: Matti J. Aaltonen <matti.j.aaltonen@nokia.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

swiotlb: fix wrong panic

swiotlb's map_page wrongly calls panic() when it can't find a buffer fit
for device's dma mask.  It should return an error instead.

Devices with an odd dma mask (i.e.  under 4G) like b44 network card hit
this bug (the system crashes):

   http://marc.info/?l=linux-kernel&m=129648943830106&w=2

If swiotlb returns an error, b44 driver can use the own bouncing
mechanism.

Reported-by: Chuck Ebbert <cebbert@redhat.com>
Signed-off-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

MAINTAINERS: add Chinese documentation maintainer

I have translated some kernel documentation so I wish to maintain the
Chinese documentation in our kernel directories.

Signed-off-by: Harry Wei <harryxiyou@gmail.com>
Cc: Joe Perches <joe@perches.com>
Cc: Greg KH <greg@kroah.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: grab rcu read lock in move_pages()

The move_pages() usage of find_task_by_vpid() requires rcu_read_lock() to
prevent free_pid() from reclaiming the pid.

Without this patch, RCU warnings are printed in v2.6.38-rc4 move_pages()
with:

  CONFIG_LOCKUP_DETECTOR=y
  CONFIG_PREEMPT=y
  CONFIG_LOCKDEP=y
  CONFIG_PROVE_LOCKING=y
  CONFIG_PROVE_RCU=y

Previously, migrate_pages() went through a similar transformation
replacing usage of tasklist_lock with rcu read lock:

  commit 55cfaa3cbdd29c4919ecb5fb8965c310f357e48c
  Author: Zeng Zhaoming <zengzm.kernel@gmail.com>
  Date:   Thu Dec 2 14:31:13 2010 -0800

      mm/mempolicy.c: add rcu read lock to protect pid structure

  commit 1e50df39f6e2c3a4a3394df62baa8a213df16c54
  Author: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
  Date:   Thu Jan 13 15:46:14 2011 -0800

      mempolicy: remove tasklist_lock from migrate_pages

Signed-off-by: Greg Thelen <gthelen@google.com>
Cc: Mel Gorman <mel@csn.ul.ie>
Cc: Minchan Kim <minchan.kim@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Zeng Zhaoming <zengzm.kernel@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

epoll: prevent creating circular epoll structures

In several places, an epoll fd can call another file's ->f_op->poll()
method with ep->mtx held.  This is in general unsafe, because that other
file could itself be an epoll fd that contains the original epoll fd.

The code defends against this possibility in its own ->poll() method using
ep_call_nested, but there are several other unsafe calls to ->poll
elsewhere that can be made to deadlock.  For example, the following simple
program causes the call in ep_insert recursively call the original fd's
->poll, leading to deadlock:

 #include <unistd.h>
 #include <sys/epoll.h>

 int main(void) {
     int e1, e2, p[2];
     struct epoll_event evt = {
         .events = EPOLLIN
     };

     e1 = epoll_create(1);
     e2 = epoll_create(2);
     pipe(p);

     epoll_ctl(e2, EPOLL_CTL_ADD, e1, &evt);
     epoll_ctl(e1, EPOLL_CTL_ADD, p[0], &evt);
     write(p[1], p, sizeof p);
     epoll_ctl(e1, EPOLL_CTL_ADD, e2, &evt);

     return 0;
 }

On insertion, check whether the inserted file is itself a struct epoll,
and if so, do a recursive walk to detect whether inserting this file would
create a loop of epoll structures, which could lead to deadlock.

[nelhage@ksplice.com: Use epmutex to serialize concurrent inserts]
Signed-off-by: Davide Libenzi <davidel@xmailserver.org>
Signed-off-by: Nelson Elhage <nelhage@ksplice.com>
Reported-by: Nelson Elhage <nelhage@ksplice.com>
Tested-by: Nelson Elhage <nelhage@ksplice.com>
Cc: <stable@kernel.org> [2.6.34+, possibly earlier]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'for-linus' of git://git./linux/kernel/git/lrg/voltage-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6:
  regulator, mc13xxx: Remove pointless test for unsigned less than zero
  regulator: Fix warning with CONFIG_BUG disabled

Merge git://git./linux/kernel/git/mason/btrfs-unstable

* git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable:
  Btrfs: fix fiemap bugs with delalloc
  Btrfs: set FMODE_EXCL in btrfs_device->mode
  Btrfs: make btrfs_rm_device() fail gracefully
  Btrfs: Avoid accessing unmapped kernel address
  Btrfs: Fix BTRFS_IOC_SUBVOL_SETFLAGS ioctl
  Btrfs: allow balance to explicitly allocate chunks as it relocates
  Btrfs: put ENOSPC debugging under a mount option

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 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems
  x86/mrst: Fix apb timer rating when lapic timer is used
  x86: Fix reboot problem on VersaLogic Menlow boards

RTC: fix typo in drivers/rtc/rtc-at91sam9.c

The member of the rtc_class_ops struct is called alarm_irq_enable and
not alarm_irq_enabled

CC: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jelle Martijn Kok <jmkok@youcom.nl>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'usb-linus' of git://git./linux/kernel/git/gregkh/usb-2.6

* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
  usb: musb: core: set has_tt flag
  USB: xhci: mark local functions as static
  USB: xhci: fix couple sparse annotations
  USB: xhci: rework xhci_print_ir_set() to get ir set from xhci itself
  USB: Reset USB 3.0 devices on (re)discovery
  xhci: Fix an error in count_sg_trbs_needed()
  xhci: Fix errors in the running total calculations in the TRB math
  xhci: Clarify some expressions in the TRB math
  xhci: Avoid BUG() in interrupt context

Merge branch 'for-linus' of git://neil.brown.name/md

* 'for-linus' of git://neil.brown.name/md:
  md: Fix - again - partition detection when array becomes active
  Fix over-zealous flush_disk when changing device size.
  md: avoid spinlock problem in blk_throtl_exit
  md: correctly handle probe of an 'mdp' device.
  md: don't set_capacity before array is active.
  md: Fix raid1->raid0 takeover

RxRPC: Allocate tokens with kzalloc to avoid oops in rxrpc_destroy

With slab poisoning enabled, I see the following oops:

  Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6b73
  ...
  NIP [c0000000006bc61c] .rxrpc_destroy+0x44/0x104
  LR [c0000000006bc618] .rxrpc_destroy+0x40/0x104
  Call Trace:
  [c0000000feb2bc00] [c0000000006bc618] .rxrpc_destroy+0x40/0x104 (unreliable)
  [c0000000feb2bc90] [c000000000349b2c] .key_cleanup+0x1a8/0x20c
  [c0000000feb2bd40] [c0000000000a2920] .process_one_work+0x2f4/0x4d0
  [c0000000feb2be00] [c0000000000a2d50] .worker_thread+0x254/0x468
  [c0000000feb2bec0] [c0000000000a868c] .kthread+0xbc/0xc8
  [c0000000feb2bf90] [c000000000020e00] .kernel_thread+0x54/0x70

We aren't initialising token->next, but the code in destroy_context relies
on the list being NULL terminated. Use kzalloc to zero out all the fields.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

afs: Fix oops in afs_unlink_writeback

I'm seeing the following oops when testing afs:

  Unable to handle kernel paging request for data at address 0x00000008
  ...
  NIP [c0000000003393b0] .afs_unlink_writeback+0x38/0xc0
  LR [c00000000033987c] .afs_put_writeback+0x98/0xec
  Call Trace:
  [c00000000345f600] [c00000000033987c] .afs_put_writeback+0x98/0xec
  [c00000000345f690] [c00000000033ae80] .afs_write_begin+0x6a4/0x75c
  [c00000000345f790] [c00000000012b77c] .generic_file_buffered_write+0x148/0x320
  [c00000000345f8d0] [c00000000012e1b8] .__generic_file_aio_write+0x37c/0x3e4
  [c00000000345f9d0] [c00000000012e2a8] .generic_file_aio_write+0x88/0xfc
  [c00000000345fa90] [c0000000003390a8] .afs_file_write+0x10c/0x178
  [c00000000345fb40] [c000000000188788] .do_sync_write+0xc4/0x128
  [c00000000345fcc0] [c000000000189658] .vfs_write+0xe8/0x1d8
  [c00000000345fd70] [c000000000189884] .SyS_write+0x68/0xb0
  [c00000000345fe30] [c000000000008564] syscall_exit+0x0/0x40

afs_write_begin hits an error and calls afs_unlink_writeback. In there
we do list_del_init on an uninitialised list.

The patch below initialises ->link when creating the afs_writeback struct.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

regulator, mc13xxx: Remove pointless test for unsigned less than zero

The variable 'val' is a 'unsigned int', so it can never be less than zero.
This fact makes the "val < 0" part of the test done in BUG_ON() in
mc13xxx_regulator_get_voltage() rather pointles since it can never have
any effect.
This patch removes the pointless test.

Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Alberto Panizzo <maramaopercheseimorto@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>

regulator: Fix warning with CONFIG_BUG disabled

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>

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/i915: Fix unintended recursion in ironlake_disable_rc6
  drm/i915: fix corruptions on i8xx due to relaxed fencing
  drm/i915: skip FDI & PCH enabling for DP_A
  agp/intel: Experiment with a 855GM GWB bit
  drm/i915: don't enable FDI & transcoder interrupts after all
  drm/i915: Ignore a hung GPU when flushing the framebuffer prior to a switch

Merge branch 'drm-intel-fixes' of git://git./linux/kernel/git/ickle/drm-intel into drm-fixes

* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
  drm/i915: Fix unintended recursion in ironlake_disable_rc6

Merge branch 'kvm-updates/2.6.38' of git://git./virt/kvm/kvm

* 'kvm-updates/2.6.38' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: SVM: Advance instruction pointer in dr_intercept

MAINTAINERS: Update email address

Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86 quirk: Fix polarity for IRQ0 pin2 override on SB800 systems

On some SB800 systems polarity for IOAPIC pin2 is wrongly
specified as low active by BIOS. This caused system hangs after
resume from S3 when HPET was used in one-shot mode on such
systems because a timer interrupt was missed (HPET signal is
high active).

For more details see:

  http://marc.info/?l=linux-kernel&m=129623757413868

Tested-by: Manoj Iyer <manoj.iyer@canonical.com>
Tested-by: Andre Przywara <andre.przywara@amd.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Borislav Petkov <borislav.petkov@amd.com>
Cc: stable@kernel.org # 37.x, 32.x
LKML-Reference: <20110224145346.GD3658@alberich.amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

usb: musb: core: set has_tt flag

MUSB is a non-standard host implementation which
can handle all speeds with the same core. We need
to set has_tt flag after commit
d199c96d41d80a567493e12b8e96ea056a1350c1 (USB: prevent
buggy hubs from crashing the USB stack) in order for
MUSB HCD to continue working.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Cc: stable <stable@kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Michael Jones <michael.jones@matrix-vision.de>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

drm/i915: Fix unintended recursion in ironlake_disable_rc6

After disabling, we're meant to teardown the bo used for the contexts,
not recurse into ourselves again and preventing module unload.

Reported-and-tested-by: Ben Widawsky <bwidawsk@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

block: bd_link_disk_holder() should hold on to holder_dir

The new implementation of bd_link_disk_holder() added by 49731baa41d
(block: restore multiple bd_link_disk_holder() support) didn't get an
extra reference for the holder_dir kobject of the slave bdev; however,
bdev kills holder_dir on removal, not release, so if the slave bdev is
removed while there are holder links, the holder_dir will be destroyed
while there still are holder links, which leads to oops later when
bd_unlink_disk_order() tries to remove those links.

Make bd_link_disk_holder() grab an extra reference for the slave's
holder_dir and put it in bd_unlink_disk_holder().

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: "Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>
Tested-by: "Hawrylewicz Czarnowski, Przemyslaw" <przemyslaw.hawrylewicz.czarnowski@intel.com>
Cc: Neil Brown <neilb@suse.de>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: fix refcounting in swapon

Grab a reference to bdev before calling blkdev_get(), which expects
the refcount to be already incremented and either returns success or
decrements the refcount and returns an error.

The bug was introduced by e525fd89 (block: make blkdev_get/put()
handle exclusive access), which didn't take into account this behavior
of blkdev_get().

Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

block: fix refcounting in BLKBSZSET

Adam Kovari and others reported that disconnecting an USB drive with
an ntfs-3g filesystem would cause "kernel BUG at fs/inode.c:1421!" to
be triggered.

The BUG could be traced back to ioctl(BLKBSZSET), which would
erroneously decrement the refcount on the bdev.  This is because
blkdev_get() expects the refcount to be already incremented and either
returns success or decrements the refcount and returns an error.

The bug was introduced by e525fd89 (block: make blkdev_get/put()
handle exclusive access), which didn't take into account this behavior
of blkdev_get().

This fixes
  https://bugzilla.kernel.org/show_bug.cgi?id=29202
(and likely 29792 too)

Reported-by: Adam Kovari <kovariadam@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
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:
  Unlock vfsmount_lock in do_umount

x86/mrst: Fix apb timer rating when lapic timer is used

Need to adjust the clockevent device rating for the structure
that will be registered with clockevent system instead of the
temporary structure.

Without this fix, APB timer rating will be higher than LAPIC
timer such that it can not be released later to be used as the
broadcast timer.

Signed-off-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
LKML-Reference: <1298506046-439-1-git-send-email-jacob.jun.pan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

Unlock vfsmount_lock in do_umount

By the commit
b3e19d9 2011-01-07 fs: scale mntget/mntput
vfsmount_lock was introduced around testing mnt_count.
Fix the mis-typed 'unlock'

Signed-off-by: J. R. Okajima <hooanon05@yahoo.co.jp>
Acked-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

md: Fix - again - partition detection when array becomes active

Revert
    b821eaa572fd737faaf6928ba046e571526c36c6
and
    f3b99be19ded511a1bf05a148276239d9f13eefa

When I wrote the first of these I had a wrong idea about the
lifetime of 'struct block_device'.  It can disappear at any time that
the block device is not open if it falls out of the inode cache.

So relying on the 'size' recorded with it to detect when the
device size has changed and so we need to revalidate, is wrong.

Rather, we really do need the 'changed' attribute stored directly in
the mddev and set/tested as appropriate.

Without this patch, a sequence of:
   mknod / open / close / unlink

(which can cause a block_device to be created and then destroyed)
will result in a rescan of the partition table and consequence removal
and addition of partitions.
Several of these in a row can get udev racing to create and unlink and
other code can get confused.

With the patch, the rescan is only performed when needed and so there
are no races.

This is suitable for any stable kernel from 2.6.35.

Reported-by: "Wojcik, Krzysztof" <krzysztof.wojcik@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Cc: stable@kernel.org

Fix over-zealous flush_disk when changing device size.

There are two cases when we call flush_disk.
In one, the device has disappeared (check_disk_change) so any
data will hold becomes irrelevant.
In the oter, the device has changed size (check_disk_size_change)
so data we hold may be irrelevant.

In both cases it makes sense to discard any 'clean' buffers,
so they will be read back from the device if needed.

In the former case it makes sense to discard 'dirty' buffers
as there will never be anywhere safe to write the data.  In the
second case it *does*not* make sense to discard dirty buffers
as that will lead to file system corruption when you simply enlarge
the containing devices.

flush_disk calls __invalidate_devices.
__invalidate_device calls both invalidate_inodes and invalidate_bdev.

invalidate_inodes *does* discard I_DIRTY inodes and this does lead
to fs corruption.

invalidate_bev *does*not* discard dirty pages, but I don't really care
about that at present.

So this patch adds a flag to __invalidate_device (calling it
__invalidate_device2) to indicate whether dirty buffers should be
killed, and this is passed to invalidate_inodes which can choose to
skip dirty inodes.

flusk_disk then passes true from check_disk_change and false from
check_disk_size_change.

dm avoids tripping over this problem by calling i_size_write directly
rathher than using check_disk_size_change.

md does use check_disk_size_change and so is affected.

This regression was introduced by commit 608aeef17a which causes
check_disk_size_change to call flush_disk, so it is suitable for any
kernel since 2.6.27.

Cc: stable@kernel.org
Acked-by: Jeff Moyer <jmoyer@redhat.com>
Cc: Andrew Patterson <andrew.patterson@hp.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: NeilBrown <neilb@suse.de>

mm: fix possible cause of a page_mapped BUG

Robert Swiecki reported a BUG_ON(page_mapped) from a fuzzer, punching
a hole with madvise(,, MADV_REMOVE).  That path is under mutex, and
cannot be explained by lack of serialization in unmap_mapping_range().

Reviewing the code, I found one place where vm_truncate_count handling
should have been updated, when I switched at the last minute from one
way of managing the restart_addr to another: mremap move changes the
virtual addresses, so it ought to adjust the restart_addr.

But rather than exporting the notion of restart_addr from memory.c, or
converting to restart_pgoff throughout, simply reset vm_truncate_count
to 0 to force a rescan if mremap move races with preempted truncation.

We have no confirmation that this fixes Robert's BUG,
but it is a fix that's worth making anyway.

Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

mm: prevent concurrent unmap_mapping_range() on the same inode

Michael Leun reported that running parallel opens on a fuse filesystem
can trigger a "kernel BUG at mm/truncate.c:475"

Gurudas Pai reported the same bug on NFS.

The reason is, unmap_mapping_range() is not prepared for more than
one concurrent invocation per inode.  For example:

  thread1: going through a big range, stops in the middle of a vma and
     stores the restart address in vm_truncate_count.

  thread2: comes in with a small (e.g. single page) unmap request on
     the same vma, somewhere before restart_address, finds that the
     vma was already unmapped up to the restart address and happily
     returns without doing anything.

Another scenario would be two big unmap requests, both having to
restart the unmapping and each one setting vm_truncate_count to its
own value.  This could go on forever without any of them being able to
finish.

Truncate and hole punching already serialize with i_mutex.  Other
callers of unmap_mapping_range() do not, and it's difficult to get
i_mutex protection for all callers.  In particular ->d_revalidate(),
which calls invalidate_inode_pages2_range() in fuse, may be called
with or without i_mutex.

This patch adds a new mutex to 'struct address_space' to prevent
running multiple concurrent unmap_mapping_range() on the same mapping.

[ We'll hopefully get rid of all this with the upcoming mm
  preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
  lockbreak" patch in particular.  But that is for 2.6.39 ]

Signed-off-by: Miklos Szeredi <mszeredi@suse.cz>
Reported-by: Michael Leun <lkml20101129@newton.leun.net>
Reported-by: Gurudas Pai <gurudas.pai@oracle.com>
Tested-by: Gurudas Pai <gurudas.pai@oracle.com>
Acked-by: Hugh Dickins <hughd@google.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Revert "Bluetooth: Enable USB autosuspend by default on btusb"

This reverts commit 556ea928f78a390fe16ae584e6433dff304d3014.

Jeff Chua reports that it can cause some bluetooth devices (he mentions
an Bluetooth Intermec scanner) to just stop responding after a while
with messages like

  [ 4533.361959] btusb 8-1:1.0: no reset_resume for driver btusb?
  [ 4533.361964] btusb 8-1:1.1: no reset_resume for driver btusb?

from the kernel. See also

  https://bugzilla.kernel.org/show_bug.cgi?id=26182

for other reports.

Reported-by: Jeff Chua <jeff.chua.linux@gmail.com>
Reported-by: Andrew Meakovski <meako@bigmir.net>
Reported-by: Jim Faulkner <jfaulkne@ccs.neu.edu>
Acked-by: Greg KH <gregkh@suse.de>
Acked-by: Matthew Garrett <mjg@redhat.com>
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
Cc: stable@kernel.org (for 2.6.37)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'drm-intel-fixes' of git://git./linux/kernel/git/ickle/drm-intel into drm-fixes

* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
  drm/i915: fix corruptions on i8xx due to relaxed fencing
  drm/i915: skip FDI & PCH enabling for DP_A
  agp/intel: Experiment with a 855GM GWB bit
  drm/i915: don't enable FDI & transcoder interrupts after all
  drm/i915: Ignore a hung GPU when flushing the framebuffer prior to a switch

drm/i915: fix corruptions on i8xx due to relaxed fencing

It looks like gen2 has a peculiar interleaved 2-row inter-tile
layout. Probably inherited from i81x which had 2kb tiles (which
naturally fit an even-number-of-tile-rows scheme to fit onto 4kb
pages). There is no other mention of this in any docs (also not
in the Intel internal documention according to Chris Wilson).

Problem manifests itself in corruptions in the second half of the
last tile row (if the bo has an odd number of tiles). Which can
only happen with relaxed tiling (introduced in a00b10c360b35d6431a9).

So reject set_tiling calls that don't satisfy this constrain to
prevent broken userspace from causing havoc. While at it, also
check the size for newer chipsets.

LKML: https://lkml.org/lkml/2011/2/19/5
Reported-by: Indan Zupancic <indan@nul.nu>
Tested-by: Indan Zupancic <indan@nul.nu>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

Merge git://git./linux/kernel/git/davem/net-2.6

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (33 commits)
  Added support for usb ethernet (0x0fe6, 0x9700)
  r8169: fix RTL8168DP power off issue.
  r8169: correct settings of rtl8102e.
  r8169: fix incorrect args to oob notify.
  DM9000B: Fix PHY power for network down/up
  DM9000B: Fix reg_save after spin_lock in dm9000_timeout
  net_sched: long word align struct qdisc_skb_cb data
  sfc: lower stack usage in efx_ethtool_self_test
  bridge: Use IPv6 link-local address for multicast listener queries
  bridge: Fix MLD queries' ethernet source address
  bridge: Allow mcast snooping for transient link local addresses too
  ipv6: Add IPv6 multicast address flag defines
  bridge: Add missing ntohs()s for MLDv2 report parsing
  bridge: Fix IPv6 multicast snooping by correcting offset in MLDv2 report
  bridge: Fix IPv6 multicast snooping by storing correct protocol type
  p54pci: update receive dma buffers before and after processing
  fix cfg80211_wext_siwfreq lock ordering...
  rt2x00: Fix WPA TKIP Michael MIC failures.
  ath5k: Fix fast channel switching
  tcp: undo_retrans counter fixes
  ...

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:
  amd64-agp: fix crash at second module load
  drm/radeon: fix regression with AA resolve checking
  drm: drop commented out code and preceding comment
  drm/vblank: Enable precise vblank timestamps for interlaced and doublescan modes.
  drm/vblank: Use memory barriers optimized for atomic_t instead of generics.
  drm/vblank: Use abs64(diff_ns) for s64 diff_ns instead of abs(diff_ns)
  drm/radeon/kms: align height of fb allocation.
  Revert "drm/radeon/kms: switch back to min->max pll post divider iteration"

Merge branch 'r8169-davem' of git://git./linux/kernel/git/romieu/netdev-2.6

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: serio/gameport - use 'long' system workqueue
  Input: synaptics - document 0x0c query
  Input: tegra-kbc - add function keymap

Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfs

* 'for-linus' of git://oss.sgi.com/xfs/xfs:
  xfs: check if device support discard in xfs_ioc_trim()
  xfs: prevent leaking uninitialized stack memory in FSGEOMETRY_V1

Added support for usb ethernet (0x0fe6, 0x9700)

The device is very similar to (0x0fe6, 0x8101),
And works well with dm9601 driver.

Signed-off-by: Shahar Havivi <shaharh@redhat.com>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>

r8169: fix RTL8168DP power off issue.

- fix the RTL8111DP turn off the power when DASH is enabled.
- RTL_GIGA_MAC_VER_27 must wait for tx finish before reset.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>

r8169: correct settings of rtl8102e.

Adjust and remove certain settings of RTL8102E which are for previous chips.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Acked-off-by: Francois Romieu <romieu@fr.zoreil.com>

r8169: fix incorrect args to oob notify.

It results in the wrong point address and influences RTL8168DP.

Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>

DM9000B: Fix PHY power for network down/up

DM9000 revision B needs 1 ms delay after PHY power-on.
PHY must be powered on by writing 0 into register DM9000_GPR before
all other settings will change (see Davicom spec and example code).

Remember, that register DM9000_GPR was not changed by reset sequence.

Without this fix the FIFO is out of sync and sends wrong data after
sequence of "ifconfig ethX down ; ifconfig ethX up".

Signed-off-by: David S. Miller <davem@davemloft.net>

DM9000B: Fix reg_save after spin_lock in dm9000_timeout

The spin_lock should hold before reading register.

Signed-off-by: David S. Miller <davem@davemloft.net>

net_sched: long word align struct qdisc_skb_cb data

netem_skb_cb() does :

return (struct netem_skb_cb *)qdisc_skb_cb(skb)->data;

Unfortunatly struct qdisc_skb_cb data is not long word aligned, so
access to psched_time_t time_to_send uses a non aligned access.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Btrfs: fix fiemap bugs with delalloc

The Btrfs fiemap code wasn't properly returning delalloc extents,
so applications that trust fiemap to decide if there are holes in the
file see holes instead of delalloc.

This reworks the btrfs fiemap code, adding a get_extent helper that
searches for delalloc ranges and also adding a helper for extent_fiemap
that skips past holes in the file.

Signed-off-by: Chris Mason <chris.mason@oracle.com>

Input: serio/gameport - use 'long' system workqueue

Commit 8ee294cd9def0004887da7f44b80563493b0a097 converted serio
subsystem event handling from using a dedicated thread to using
common workqueue. Unfortunately, this regressed our boot times,
due to the fact that serio jobs take long time to execute. While
the new concurrency managed workqueue code manages long-playing
works just fine and schedules additional workers as needed, such
works wreck havoc among remaining users of flush_scheduled_work().

To solve this problem let's move serio/gameport works from system_wq
to system_long_wq which nobody tries to flush.

Reported-and-tested-by: Hernando Torque <pantherchen@versanet.de>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

Input: synaptics - document 0x0c query

Since Synaptics technical writers department is a bit slow releasing updated
Synaptics interface guide, let's add some new bits (with their blessing)
to the code so that they don't get lost.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>

Drop redundant __param section for CRISv32.

The __param section is already brought in by RODATA above.

Signed-off-by: Jesper Nilsson <jesper.nilsson@axis.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

amd64-agp: fix crash at second module load

The module forgot to sometimes unregister some resources.

This fixes Bug #22882.

[Patch updated to 2.6.38-rc3 by Randy Dunlap.]
Tested-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Florian Mickler <florian@mickler.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

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

* 'for-2639-rc4/i2c-fixes' of git://git.fluff.org/bjdooks/linux:
  i2c-omap: fixup commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac whitespace
  i2c-omap: Double clear of ARDY status in IRQ handler
  i2c-omap: fix build for !CONFIG_SUSPEND
  i2c-omap: fix static suspend vs. runtime suspend
  i2c-stu300: make sure adapter-name is terminated

USB: xhci: mark local functions as static

Functions that are not used outsde of the module they are defined
should be marked as static.

Signed-off-by: Dmitry Torokhov <dtor@vmware.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>

Merge branch 'usb-linus' of git://git./linux/kernel/git/gregkh/usb-2.6

* 'usb-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
  Revert "USB: Reset USB 3.0 devices on (re)discovery"
  USB: musb: omap2430: fix kernel panic on reboot
  sierra: add new ID for Airprime/Sierra USB IP modem
  USB: serial/usb_wwan, fix tty NULL dereference
  USB: Reset USB 3.0 devices on (re)discovery
  USB: Add quirk for Samsung Android phone modem
  USB: Add Samsung SGH-I500/Android modem ID switch to visor driver
  USB: add quirks entry for Keytouch QWERTY Panel
  usb: musb: omap2430: fix kernel panic on reboot
  usb: musb: fix build breakage

i2c-omap: fixup commit cb527ede1bf6ff2008a025606f25344b8ed7b4ac whitespace

Fixup the whitespace error noticed in cb527ede1bf6ff2008a025606f25344b8ed7b4ac

Signed-off-by: Ben Dooks <ben-linux@fluff.org>

i2c-omap: Double clear of ARDY status in IRQ handler

This errata occurs when the ARDY interrupt generation is enabled.
At the begining of every new transaction the ARDY interrupt is cleared.

On continuous i2c transactions where after clearing the ARDY bit from
I2C_STAT register (clearing the interrupt), the IRQ line is reasserted and the
I2C_STAT[ARDY] bit set again on 1. In fact, the ARDY status bit is not cleared
at the write access to I2C_STAT[ARDY] and only the IRQ line is deasserted and
then reasserted. This is not captured in the usual errata documents.

The workaround is to have a double clear of ARDY status in irq handler.

Signed-off-by: Richard woodruff <r-woodruff2@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

i2c-omap: fix build for !CONFIG_SUSPEND

fix the build break when !CONFIG_SUSPEND

drivers/i2c/busses/i2c-omap.c:1173: error: lvalue required as unary '&' operand
make[3]: *** [drivers/i2c/busses/i2c-omap.o] Error 1
make[2]: *** [drivers/i2c/busses] Error 2
make[1]: *** [drivers/i2c] Error 2
make: *** [drivers] Error 2

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

drm/radeon: fix regression with AA resolve checking

Some userspaces can emit a whole packet without disabling AA resolve
by the looks of it, so we have to deal with them.

Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Jorg Otte <jrg.otte@googlemail.com>

drm: drop commented out code and preceding comment

r100_gpu_init() was dropped in 90aca4d ("drm/radeon/kms: simplify &
improve GPU reset V2") but here it was only commented out.

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

drm/vblank: Enable precise vblank timestamps for interlaced and doublescan modes.

Testing showed the current code can already handle doublescan
video modes just fine. A trivial tweak makes it work for interlaced
scanout as well.

Tested and shown to be precise on Radeon rv530, r600 and
Intel 945-GME.

Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/vblank: Use memory barriers optimized for atomic_t instead of generics.

Documentation/atomic_ops.txt tells us that there are memory
barriers optimized for atomic_inc and other atomic_t ops.

Use these instead of smp_wmb(), and also to make the required
memory barriers around vblank counter increments more explicit.

Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/vblank: Use abs64(diff_ns) for s64 diff_ns instead of abs(diff_ns)

Use of abs() wrongly wrapped diff_ns to 32 bit, which gives a 1/4000
probability of a missed vblank increment at each vblank irq reenable
if the kms driver doesn't support high precision vblank timestamping.
Not a big deal in practice, but let's make it nice.

Signed-off-by: Mario Kleiner <mario.kleiner@tuebingen.mpg.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/radeon/kms: align height of fb allocation.

this aligns the height of the fb allocation so it doesn't trip
over the size checks later when we use this from userspace to
copy the buffer at X start.

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

Revert "drm/radeon/kms: switch back to min->max pll post divider iteration"

This reverts commit a6f9761743bf35b052180f4a8bdae4d2cc0465f6.

Remove this commit as it is no longer necessary. The relevant bugs
were fixed properly in:
drm/radeon/kms: hopefully fix pll issues for real (v3)
5b40ddf888398ce4cccbf3b9d0a18d90149ed7ff
drm/radeon/kms: add missing frac fb div flag for dce4+
9f4283f49f0a96a64c5a45fe56f0f8c942885eef

This commit also broke certain ~5 Mhz modes on old arcade monitors,
so reverting this commit fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=29502

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

i2c-omap: fix static suspend vs. runtime suspend

When runtime PM is enabled, each OMAP i2c device is suspended after
each i2c xfer.  However, there are two cases when the static suspend
methods must be used to ensure the devices are suspended:

1) runtime PM is disabled, either at compile time or dynamically
    via /sys/devices/.../power/control.
2) an i2c client driver uses i2c during it's suspend callback, thus
   leaving the i2c driver active (NOTE: runtime suspend transitions are
   disabled during system suspend, so i2c activity during system
   suspend will runtime resume the device, but not runtime (re)suspend it.)

Since the actual work to suspend the device is handled by the
subsytem, call the bus methods to take care of it.

NOTE: This takes care of a known suspend problem on OMAP3 where the
TWL RTC driver does i2c xfers during its suspend path leaving the i2c
driver in an active state (since runtime suspend transistions are
disabled.)

Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

i2c-stu300: make sure adapter-name is terminated

Use strlcpy instead of strncpy.

Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
Cc: Linus Walleij <linus.walleij@stericsson.com>
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>

xfs: check if device support discard in xfs_ioc_trim()

Right now we, are relying on the fact that when we attempt to
actually do the discard, blkdev_issue_discar() returns -EOPNOTSUPP
and the user is informed that the device does not support discard.

However, in the case where the we do not hit any suitable free
extent to trim in FITRIM code, it will finish without any error.
This is very confusing, because it seems that FITRIM was successful
even though the device does not actually supports discard.

Solution: Check for the discard support before attempt to search for
free extents.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Alex Elder <aelder@sgi.com>

xfs: prevent leaking uninitialized stack memory in FSGEOMETRY_V1

The FSGEOMETRY_V1 ioctl (and its compat equivalent) calls out to
xfs_fs_geometry() with a version number of 3.  This code path does not
fill in the logsunit member of the passed xfs_fsop_geom_t, leading to
the leaking of four bytes of uninitialized stack data to potentially
unprivileged callers.

v2 switches to memset() to avoid future issues if structure members
change, on suggestion of Dave Chinner.

Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Reviewed-by: Eugene Teo <eugeneteo@kernel.org>
Signed-off-by: Alex Elder <aelder@sgi.com>

Merge branch 'master' of git://git./linux/kernel/git/linville/wireless-2.6

sfc: lower stack usage in efx_ethtool_self_test

drivers/net/sfc/ethtool.c: In function ‘efx_ethtool_self_test’:
drivers/net/sfc/ethtool.c:613: warning: the frame size of 1200 bytes
is larger than 1024 bytes

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

bridge: Use IPv6 link-local address for multicast listener queries

Currently the bridge multicast snooping feature periodically issues
IPv6 general multicast listener queries to sense the absence of a
listener.

For this, it uses :: as its source address - however RFC 2710 requires:
"To be valid, the Query message MUST come from a link-local IPv6 Source
Address". Current Linux kernel versions seem to follow this requirement
and ignore our bogus MLD queries.

With this commit a link local address from the bridge interface is being
used to issue the MLD query, resulting in other Linux devices which are
multicast listeners in the network to respond with a MLD response (which
was not the case before).

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

bridge: Fix MLD queries' ethernet source address

Map the IPv6 header's destination multicast address to an ethernet
source address instead of the MLD queries multicast address.

For instance for a general MLD query (multicast address in the MLD query
set to ::), this would wrongly be mapped to 33:33:00:00:00:00, although
an MLD queries destination MAC should always be 33:33:00:00:00:01 which
matches the IPv6 header's multicast destination ff02::1.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

bridge: Allow mcast snooping for transient link local addresses too

Currently the multicast bridge snooping support is not active for
link local multicast. I assume this has been done to leave
important multicast data untouched, like IPv6 Neighborhood Discovery.

In larger, bridged, local networks it could however be desirable to
optimize for instance local multicast audio/video streaming too.

With the transient flag in IPv6 multicast addresses we have an easy
way to optimize such multimedia traffic without tempering with the
high priority multicast data from well-known addresses.

This patch alters the multicast bridge snooping for IPv6, to take
effect for transient multicast addresses instead of non-link-local
addresses.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

ipv6: Add IPv6 multicast address flag defines

This commit adds the missing IPv6 multicast address flag defines to
complement the already existing multicast address scope defines and to
be able to check these flags nicely in the future.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

bridge: Add missing ntohs()s for MLDv2 report parsing

The nsrcs number is 2 Byte wide, therefore we need to call ntohs()
before using it.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

bridge: Fix IPv6 multicast snooping by correcting offset in MLDv2 report

We actually want a pointer to the grec_nsrcr and not the following
field. Otherwise we can get very high values for *nsrcs as the first two
bytes of the IPv6 multicast address are being used instead, leading to
a failing pskb_may_pull() which results in MLDv2 reports not being
parsed.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

bridge: Fix IPv6 multicast snooping by storing correct protocol type

The protocol type for IPv6 entries in the hash table for multicast
bridge snooping is falsely set to ETH_P_IP, marking it as an IPv4
address, instead of setting it to ETH_P_IPV6, which results in negative
look-ups in the hash table later.

Signed-off-by: Linus Lüssing <linus.luessing@web.de>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'urgent' of git://git./linux/kernel/git/brodo/pcmcia-2.6

* 'urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6:
  pcmcia: re-enable Zoomed Video support
  cm4000_cs: Fix undefined ops warning
  pcmcia vs. MECR on pxa25x/sa1111
  drivers/char/pcmcia/ipwireless/main.c: Convert release_resource to release_region/release_mem_region

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

* 'irq-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  genirq: Disable the SHIRQ_DEBUG call in request_threaded_irq for now
  genirq: Prevent access beyond allocated_irqs bitmap

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

* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf: Fix throttle logic
  perf, x86: P4 PMU: Fix spurious NMI messages

Merge branch 'fix/asoc' of git://git./linux/kernel/git/tiwai/sound-2.6

* 'fix/asoc' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
  ASoC: Ensure supplies are maintained for force enabled widgets
  ASoC: WM8994: Improve playback robustness
  ASoC: WM8994: Improve robustness in some use cases
  ASoC: WM8903: Fix mic detection enable logic
  ASoC: WM8903: Fix mic detection register definitions
  ASoC: CX20442: fix wrong reg_cache_default content
  ASoC: Sync initial widget state with hardware

.gitignore: ignore *.xz files

Building with CONFIG_KERNEL_XZ results in the following:

 # Untracked files:
 #   (use "git add <file>..." to include in what will be committed)
 #
 #       arch/x86/boot/compressed/vmlinux.bin.xz

So ignore xz-compressed files at the top level like we already do for
other compression types.

Signed-off-by: Romain Francoise <romain@orebokech.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drm/i915: skip FDI & PCH enabling for DP_A

eDP on the CPU doesn't need the PCH set up at all, it can in fact cause
problems.  So avoid FDI training and PCH PLL enabling in that case.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

agp/intel: Experiment with a 855GM GWB bit

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=27187
Tested-by: Thorsten Vollmer <thorsten@thvo.de> (DFI-ACP G5M150-N w/852GME)
Tested-by: Moritz Brunner <2points@gmx.org> (Asus M2400N/i855GM)
Tested-by: Indan Zupancic <indan@nul.nu> (Thinkpad X40/855GM rev 02)
Tested-by: Eric Anholt <eric@anholt.net> (865G)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

drm/i915: don't enable FDI & transcoder interrupts after all

We can enable some safely, but FDI and transcoder interrupts can occur
and block other interrupts from being detected (like port hotplug
events).  So keep them disabled by default (they can be re-enabled for
debugging display bringup, but should generally be off).

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

drm/i915: Ignore a hung GPU when flushing the framebuffer prior to a switch

If the gpu is hung, then whatever was inside the render cache is lost
and there is little point waiting for it. Or complaining if we see an
EIO or EAGAIN instead. So, if the GPU is indeed in its death throes when
we need to rewrite the registers for a new framebuffer, just ignore the
error and proceed with the update.

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

KVM: SVM: Advance instruction pointer in dr_intercept

In the dr_intercept function a new cpu-feature called
decode-assists is implemented and used when available. This
code-path does not advance the guest-rip causing the guest
to dead-loop over mov-dr instructions. This is fixed by this
patch.

Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
Signed-off-by: Avi Kivity <avi@redhat.com>

Linux 2.6.38-rc6

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

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ecryptfs/ecryptfs-2.6:
  eCryptfs: Copy up lower inode attrs in getattr
  ecryptfs: read on a directory should return EISDIR if not supported
  eCryptfs: Handle NULL nameidata pointers
  eCryptfs: Revert "dont call lookup_one_len to avoid NULL nameidata"

drm/i915: Do not handle backlight combination mode specially

The current code does not follow Intel documentation: It misses some things
and does other, undocumented things. This causes wrong backlight values in
certain conditions. Instead of adding tricky code handling badly documented
and rare corner cases, don't handle combination mode specially at all. This
way PCI_LBPC is never touched and weird things shouldn't happen.

If combination mode is enabled, then the only downside is that changing the
brightness has a greater granularity (the LBPC value), but LBPC is at most
254 and the maximum is in the thousands, so this is no real functional loss.

A potential problem with not handling combined mode is that a brightness of
max * PCI_LBPC is not bright enough. However, this is very unlikely because
from the documentation LBPC seems to act as a scaling factor and doesn't look
like it's supposed to be changed after boot. The value at boot should always
result in a bright enough screen.

IMPORTANT: However, although usually the above is true, it may not be when
people ran an older (2.6.37) kernel which messed up the LBPC register, and
they are unlucky enough to have a BIOS that saves and restores the LBPC value.
Then a good kernel may seem to not work: Max brightness isn't bright enough.
If this happens people should boot back into the old kernel, set brightness
to the maximum, and then reboot. After that everything should be fine.

For more information see the below links. This fixes bugs:

  http://bugzilla.kernel.org/show_bug.cgi?id=23472
  http://bugzilla.kernel.org/show_bug.cgi?id=25072

Signed-off-by: Indan Zupancic <indan@nul.nu>
Tested-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>