linux-stable.git/include, branch v3.12.28

drm/radeon: add additional SI pci ids

2014-09-03T19:31:30+00:00

commit 37dbeab788a8f23fd946c0be083e5484d6f929a1 upstream.

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/radeon: add new bonaire pci ids

2014-09-03T19:31:29+00:00

commit 5fc540edc8ea1297c76685f74bc82a2107fe6731 upstream.

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

drm/radeon: add new KV pci id

2014-09-03T19:31:28+00:00

commit 6dc14baf4ced769017c7a7045019c7a19f373865 upstream.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=82912

Signed-off-by: Alex Deucher 
Signed-off-by: Jiri Slaby

PCI: Add pci_upstream_bridge()

2014-09-03T08:54:30+00:00

commit c6bde215acfd637708142ae671843b6f0eadbc6d upstream.

This adds a pci_upstream_bridge() interface to find the PCI-to-PCI bridge
upstream from a device.  This is typically just "dev->bus->self", but in
the case of a VF on a virtual bus, we have to start from the corresponding
PF.  Returns NULL if there is no upstream PCI bridge, i.e., if the device
is on a root bus.

Signed-off-by: Bjorn Helgaas 
Acked-by: Yinghai Lu 

Signed-off-by: Jiri Slaby

bio-integrity: add "bip_max_vcnt" into struct bio_integrity_payload

2014-09-02T09:41:56+00:00

commit cbcd1054a1fd2aa980fc11ff28e436fc4aaa2d54 upstream.

Commit 08778795 ("block: Fix nr_vecs for inline integrity vectors") from
Martin introduces the function bip_integrity_vecs(get the useful vectors)
to fix the issue about nr_vecs for inline integrity vectors that reported
by David Milburn.

But it seems that bip_integrity_vecs() will return the wrong number if the
bio is not based on any bio_set for some reason(bio->bi_pool == NULL),
because in that case, the bip_inline_vecs[0] is malloced directly.  So
here we add the bip_max_vcnt to record the count of vector slots, and
cleanup the function bip_integrity_vecs().

Signed-off-by: Gu Zheng 
Cc: Martin K. Petersen 
Cc: Kent Overstreet 
Signed-off-by: Jens Axboe

usb-core bInterval quirk

2014-09-02T09:37:54+00:00

commit cd83ce9e6195aa3ea15ab4db92892802c20df5d0 upstream.

This patch adds a usb quirk to support devices with interupt endpoints
and bInterval values expressed as microframes. The quirk causes the
parse endpoint function to modify the reported bInterval to a standards
conforming value.

There is currently code in the endpoint parser that checks for
bIntervals that are outside of the valid range (1-16 for USB 2+ high
speed and super speed interupt endpoints). In this case, the code assumes
the bInterval is being reported in 1ms frames. As well, the correction
is only applied if the original bInterval value is out of the 1-16 range.

With this quirk applied to the device, the bInterval will be
accurately adjusted from microframes to an exponent.

Signed-off-by: James P Michels III 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Jiri Slaby

DMA-API: provide a helper to set both DMA and coherent DMA masks

2014-08-26T12:12:07+00:00

commit 4aa806b771d16b810771d86ce23c4c3160888db3 upstream.

Provide a helper to set both the DMA and coherent DMA masks to the
same value - this avoids duplicated code in a number of drivers,
sometimes with buggy error handling, and also allows us identify
which drivers do things differently.

Signed-off-by: Russell King 
Signed-off-by: Jiri Slaby

mnt: Correct permission checks in do_remount

2014-08-26T12:12:05+00:00

commit 9566d6742852c527bf5af38af5cbb878dad75705 upstream.

While invesgiating the issue where in "mount --bind -oremount,ro ..."
would result in later "mount --bind -oremount,rw" succeeding even if
the mount started off locked I realized that there are several
additional mount flags that should be locked and are not.

In particular MNT_NOSUID, MNT_NODEV, MNT_NOEXEC, and the atime
flags in addition to MNT_READONLY should all be locked.  These
flags are all per superblock, can all be changed with MS_BIND,
and should not be changable if set by a more privileged user.

The following additions to the current logic are added in this patch.
- nosuid may not be clearable by a less privileged user.
- nodev  may not be clearable by a less privielged user.
- noexec may not be clearable by a less privileged user.
- atime flags may not be changeable by a less privileged user.

The logic with atime is that always setting atime on access is a
global policy and backup software and auditing software could break if
atime bits are not updated (when they are configured to be updated),
and serious performance degradation could result (DOS attack) if atime
updates happen when they have been explicitly disabled.  Therefore an
unprivileged user should not be able to mess with the atime bits set
by a more privileged user.

The additional restrictions are implemented with the addition of
MNT_LOCK_NOSUID, MNT_LOCK_NODEV, MNT_LOCK_NOEXEC, and MNT_LOCK_ATIME
mnt flags.

Taken together these changes and the fixes for MNT_LOCK_READONLY
should make it safe for an unprivileged user to create a user
namespace and to call "mount --bind -o remount,... ..." without
the danger of mount flags being changed maliciously.

Cc: stable@vger.kernel.org
Acked-by: Serge E. Hallyn 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Jiri Slaby

mnt: Only change user settable mount flags in remount

2014-08-26T12:12:04+00:00

commit a6138db815df5ee542d848318e5dae681590fccd upstream.

Kenton Varda  discovered that by remounting a
read-only bind mount read-only in a user namespace the
MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user
to the remount a read-only mount read-write.

Correct this by replacing the mask of mount flags to preserve
with a mask of mount flags that may be changed, and preserve
all others.   This ensures that any future bugs with this mask and
remount will fail in an easy to detect way where new mount flags
simply won't change.

Cc: stable@vger.kernel.org
Acked-by: Serge E. Hallyn 
Signed-off-by: "Eric W. Biederman" 
Signed-off-by: Jiri Slaby

mac80211: reset probe_send_count also in HW_CONNECTION_MONITOR case

2014-08-26T12:12:02+00:00

commit 448cd2e248732326632957e52ea9c44729affcb2 upstream.

In case of beacon_loss with IEEE80211_HW_CONNECTION_MONITOR
device, mac80211 probes the ap (and disconnects on timeout)
but ignores the ack.

If we already got an ack, there's no reason to continue
disconnecting. this can help devices that supports
IEEE80211_HW_CONNECTION_MONITOR only partially (e.g. take
care of keep alives, but does not probe the ap.

In case the device wants to disconnect without probing,
it can just call ieee80211_connection_loss.

Signed-off-by: Eliad Peller 
Signed-off-by: Johannes Berg 
Signed-off-by: Jiri Slaby