UBUNTU: Start new release

Ignore: yes
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
drm/i915: Make data/link N value power of two

BugLink: http://bugs.launchpad.net/bugs/1212376

The BIOS uses power of two values for the data/link N value.

Follow suit to make the Zotac DP to dual-HDMI dongle work.

v2: Clean up the magic numbers and defines
    Change the N clamping to be a bit easier on the eye
    Rename intel_reduce_ratio to intel_reduce_m_n_ratio

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49402
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59810
Tested-by:  Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[Haitao Zhang: backport to 3.8 from commit a65851af59387146a28a928c3e7bb17dabc5db72 upstream]
Signed-off-by: Haitao Zhang <haitao.zhang@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>

(cherry picked from commit b92ae13bf2b9610bef48c1b64c0b4dcdf47a4053 ubuntu-raring)
Cc: Timo Aaltonen <timo.aaltonen@canonical.com>
Signed-off-by: Adam Lee <adam.lee@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
isofs: Refuse RW mount of the filesystem instead of making it RO

BugLink: http://bugs.launchpad.net/bugs/1228751

Refuse RW mount of isofs filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block layer won't notice
this change and thus will think device is used RW and will block eject
button of the drive. That is unexpected by users because for
non-writeable media eject button works just fine.

Userspace mount(8) command handles this just fine and retries mounting
with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
tool mounting isofs is likely confronted with the case of read-only
media where block layer already refuses to mount the filesystem without
MS_RDONLY set so our behavior shouldn't be anything new for it.

Reported-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Jan Kara <jack@suse.cz>
(cherry picked from commit 17b7f7cf58926844e1dd40f5eb5348d481deca6a)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
udf: Standardize return values in mount sequence

BugLink: http://bugs.launchpad.net/bugs/1228751

Change all function used in filesystem discovery during mount to user
standard kernel return values - -errno on error, 0 on success instead
of 1 on failure and 0 on success. This allows us to pass error number
(not just failure / success) so we can abort device scanning earlier
in case of errors like EIO or ENOMEM . Also we will be able to return
EROFS in case writeable mount is requested but writing isn't supported.

Signed-off-by: Jan Kara <jack@suse.cz>
(back ported from commit d759bfa4e7919b89357de50a2e23817079889195)

Conflicts:
	fs/udf/super.c
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
udf: Refuse RW mount of the filesystem instead of making it RO

BugLink: http://bugs.launchpad.net/bugs/1228751

Refuse RW mount of udf filesystem. So far we just silently changed it
to RO mount but when the media is writeable, block layer won't notice
this change and thus will think device is used RW and will block eject
button of the drive. That is unexpected by users because for
non-writeable media eject button works just fine.

Userspace mount(8) command handles this just fine and retries mounting
with MS_RDONLY set so userspace shouldn't see any regression.  Plus any
tool mounting udf is likely confronted with the case of read-only
media where block layer already refuses to mount the filesystem without
MS_RDONLY set so our behavior shouldn't be anything new for it.

Reported-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Jan Kara <jack@suse.cz>
(cherry picked from commit e729eac6f65e11c5f03b09adcc84bd5bcb230467)
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
cciss: fix info leak in cciss_ioctl32_passthru()

BugLink: http://bugs.launchpad.net/bugs/1188355

CVE-2013-2147

The arg64 struct has a hole after ->buf_size which isn't cleared.  Or if
any of the calls to copy_from_user() fail then that would cause an
information leak as well.

This was assigned CVE-2013-2147.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 58f09e00ae095e46ef9edfcf3a5fd9ccdfad065e)
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
cpqarray: fix info leak in ida_locked_ioctl()

BugLink: http://bugs.launchpad.net/bugs/1188355

CVE-2013-2147

The pciinfo struct has a two byte hole after ->dev_fn so stack
information could be leaked to the user.

This was assigned CVE-2013-2147.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Mike Miller <mike.miller@hp.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit 627aad1c01da6f881e7f98d71fd928ca0c316b1a)
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Andy Whitcroft <andy.whitcroft@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: Ubuntu-3.5.0-42.65

Signed-off-by: Brad Figg <brad.figg@canonical.com>
UBUNTU: Start new release

Ignore: yes
get rid of full-hash scan on detaching vfsmounts

BugLink: http://bugs.launchpad.net/bugs/1226726

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
(backported from commit 84d17192d2afd52aeba88c71ae4959a015f56a38 upstream)
Signed-off-by: Dave Chiluk <chiluk@canonical.com>
Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Smack: Fix the bug smackcipso can't set CIPSO correctly

BugLink: http://bugs.launchpad.net/bugs/1236743

Bug report: https://tizendev.org/bugs/browse/TDIS-3891

The reason is userspace libsmack only use "smackfs/cipso2" long-label interface,
but the code's logical is still for orginal fixed length label. Now update
smack_cipso_apply() to support flexible label (<=256 including tailing '\0')

There is also a bug in kernel/security/smack/smackfs.c:
When smk_set_cipso() parsing the CIPSO setting from userspace, the offset of
CIPSO level should be "strlen(label)+1" instead of "strlen(label)"

Signed-off-by: Passion,Zhao <passion.zhao@intel.com>
(cherry picked from commit 0fcfee61d63b82c1eefb5b1a914240480f17d63f)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
Revert "xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end"

BugLink: http://bugs.launchpad.net/bugs/1236041

This reverts commit fde35888f97d4ba46010eed7b9c321cd73f7bd99 which is
commit eb178619f930fa2ba2348de332a1ff1c66a31424 upstream.

Several people have reported issues using xfs_growfs after applying the
CVE-2013-1819 fix backport:

[  133.574503] XFS (loop0): _xfs_buf_find: Block out of range: block 0x500001, EOFS 0x400000
[  133.575554] XFS (loop0): _xfs_buf_find: Block out of range: block 0x500001, EOFS 0x400000

Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
SAUCE: (no-up) Only let characters through when there are active readers.

upstreamed

BugLink: http://bugs.launchpad.net/bugs/1208740

If there is an active reader, previous behavior is in place. When there is no
active reader, input is blocked until the next read call unblocks it.

This fixes a long standing issue with readline when pasting more than 4096
bytes.

Signed-off-by: Chris J Arges <chris.j.arges@canonical.com>
Acked-by: Steve Conklin <sconklin@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
usb: xhci: define port register names and use them instead of magic numbers

BugLink: http://bugs.launchpad.net/bugs/1229576

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
(cherry picked from commit b6e76371c888f5cb677f190a28444ac8875359ad)
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
usb: xhci: add USB2 Link power management BESL support

BugLink: https://bugs.launchpad.net/bugs/1229576

usb 2.0 devices with link power managment (LPM) can describe their idle link
timeouts either in BESL or HIRD format, so far xHCI has only supported HIRD but
later xHCI errata add BESL support as well

BESL timeouts need to inform exit latency changes with an evaluate
context command the same way USB 3.0 link PM code does.
The same xhci_change_max_exit_latency() function is used as with USB3
but code is pulled out from #ifdef CONFIG_PM as USB2.0 BESL LPM
funcionality does not depend on CONFIG_PM.

Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
(backported from commit a558ccdcc71c7770c5e80c926a31cfe8a3892a09)

Signed-off-by: Shawn Wang <shawn.wang@canonical.com>
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>

Conflicts:
	drivers/usb/host/xhci.c
Acked-by: Brad Figg <brad.figg@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
UBUNTU: SAUCE: ubuntu/i915: silence unclaimed register poking debug messages

BugLink: https://bugs.launchpad.net/bugs/1138787

These harmless messages need not be visible by default.

Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Stefan Bader <stefan.bader@canonical.com>
Acked-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Andy Whitcroft <apw@canonical.com>
iwl4965: fix rfkill set state regression

BugLink: http://bugs.launchpad.net/bugs/1241093

commit b2fcc0aee58a3435566dd6d8501a0b355552f28b upstream.

My current 3.11 fix:

commit 788f7a56fce1bcb2067b62b851a086fca48a0056
Author: Stanislaw Gruszka <sgruszka@redhat.com>
Date:   Thu Aug 1 12:07:55 2013 +0200

    iwl4965: reset firmware after rfkill off

broke rfkill notification to user-space . I missed that bug, because
I compiled without CONFIG_RFKILL, sorry about that.

Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
ath9k_htc: Restore skb headroom when returning skb to mac80211

BugLink: http://bugs.launchpad.net/bugs/1241093

commit d2e9fc141e2aa21f4b35ee27072d84e9aa6e2ba0 upstream.

ath9k_htc adds padding between the 802.11 header and the payload during
TX by moving the header. When handing the frame back to mac80211 for TX
status handling the header is not moved back into its original position.
This can result in a too small skb headroom when entering ath9k_htc
again (due to a soft retransmission for example) causing an
skb_under_panic oops.

Fix this by moving the 802.11 header back into its original position
before returning the frame to mac80211 as other drivers like rt2x00
or ath5k do.

Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
ALSA: opti9xx: Fix conflicting driver object name

BugLink: http://bugs.launchpad.net/bugs/1241093

commit fb615499f0ad28ed74201c1cdfddf9e64e205424 upstream.

The recent commit to delay the release of kobject triggered NULL
dereferences of opti9xx drivers.  The cause is that all
snd-opti92x-ad1848, snd-opti92x-cs4231 and snd-opti93x drivers
register the PnP card driver with the very same name, and also
snd-opti92x-ad1848 and -cs4231 drivers register the ISA driver with
the same name, too.  When these drivers are built in, quick
"register-release-and-re-register" actions occur, and this results in
Oops because of the same name is assigned to the kobject.

The fix is simply to assign individual names.  As a bonus, by using
KBUILD_MODNAME, the patch reduces more lines than it adds.

The fix is based on the suggestion by Russell King.

Reported-and-tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>
SUNRPC: Fix memory corruption issue on 32-bit highmem systems

BugLink: http://bugs.launchpad.net/bugs/1241093

commit 347e2233b7667e336d9f671f1a52dfa3f0416e2c upstream.

Some architectures, such as ARM-32 do not return the same base address
when you call kmap_atomic() twice on the same page.
This causes problems for the memmove() call in the XDR helper routine
"_shift_data_right_pages()", since it defeats the detection of
overlapping memory ranges, and has been seen to corrupt memory.

The fix is to distinguish between the case where we're doing an
inter-page copy or not. In the former case of we know that the memory
ranges cannot possibly overlap, so we can additionally micro-optimise
by replacing memmove() with memcpy().

Reported-by: Mark Young <MYoung@nvidia.com>
Reported-by: Matt Craighead <mcraighead@nvidia.com>
Cc: Bruce Fields <bfields@fieldses.org>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Tested-by: Matt Craighead <mcraighead@nvidia.com>
Signed-off-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Brad Figg <brad.figg@canonical.com>