pandora-kernel.git
9 years agoLinux 3.2.30 v3.2.30
Ben Hutchings [Wed, 19 Sep 2012 14:05:26 +0000 (15:05 +0100)]
Linux 3.2.30

9 years agovfs: make O_PATH file descriptors usable for 'fstat()'
Linus Torvalds [Fri, 14 Sep 2012 21:48:21 +0000 (14:48 -0700)]
vfs: make O_PATH file descriptors usable for 'fstat()'

commit 55815f70147dcfa3ead5738fd56d3574e2e3c1c2 upstream.

We already use them for openat() and friends, but fstat() also wants to
be able to use O_PATH file descriptors.  This should make it more
directly comparable to the O_SEARCH of Solaris.

Note that you could already do the same thing with "fstatat()" and an
empty path, but just doing "fstat()" directly is simpler and faster, so
there is no reason not to just allow it directly.

See also commit 332a2e1244bd, which did the same thing for fchdir, for
the same reasons.

Reported-by: ольга крыжановская <olga.kryzhanovska@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoVFS: make vfs_fstat() use f[get|put]_light()
Linus Torvalds [Sat, 28 Apr 2012 21:55:17 +0000 (14:55 -0700)]
VFS: make vfs_fstat() use f[get|put]_light()

commit e994defb7b6813ba6fa7a2a36e86d2455ad1dc35 upstream.

Use the *_light() versions that properly avoid doing the file user count
updates when they are unnecessary.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoeCryptfs: Copy up attributes of the lower target inode after rename
Tyler Hicks [Thu, 13 Sep 2012 19:00:56 +0000 (12:00 -0700)]
eCryptfs: Copy up attributes of the lower target inode after rename

commit 8335eafc2859e1a26282bef7c3d19f3d68868b8a upstream.

After calling into the lower filesystem to do a rename, the lower target
inode's attributes were not copied up to the eCryptfs target inode. This
resulted in the eCryptfs target inode staying around, rather than being
evicted, because i_nlink was not updated for the eCryptfs inode. This
also meant that eCryptfs didn't do the final iput() on the lower target
inode so it stayed around, as well. This would result in a failure to
free up space occupied by the target file in the rename() operation.
Both target inodes would eventually be evicted when the eCryptfs
filesystem was unmounted.

This patch calls fsstack_copy_attr_all() after the lower filesystem
does its ->rename() so that important inode attributes, such as i_nlink,
are updated at the eCryptfs layer. ecryptfs_evict_inode() is now called
and eCryptfs can drop its final reference on the lower inode.

http://launchpad.net/bugs/561129

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Tested-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/nouveau: fix booting with plymouth + dumb support
Dave Airlie [Fri, 14 Sep 2012 03:28:23 +0000 (13:28 +1000)]
drm/nouveau: fix booting with plymouth + dumb support

commit 610bd7da160f76f1644ecb4cd7f39511b49a22cc upstream.

We noticed a plymouth bug on Fedora 18, and I then
noticed this stupid thinko, fixing it fixed the problem
with plymouth.

Acked-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: rework pll selection (v3)
Alex Deucher [Fri, 31 Aug 2012 15:56:50 +0000 (11:56 -0400)]
drm/radeon: rework pll selection (v3)

commit 985f61f7ee647ad570c05eab0b74915da2ac8e19 upstream.

For DP we can use the same PPLL for all active DP
encoders.  Take advantage of that to prevent cases
where we may end up sharing a PPLL between DP and
non-DP which won't work.  Also clean up the code
a bit.

v2: - fix missing pll_id assignment in crtc init
v3: - fix DP PPLL check
    - document functions
    - break in main encoder search loop after matching.
      no need to keep checking additional encoders.

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

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: fix ordering in pll picking on dce4+
Alex Deucher [Mon, 6 Aug 2012 21:06:03 +0000 (17:06 -0400)]
drm/radeon: fix ordering in pll picking on dce4+

commit ecd67955fd4c8e66e4df312098989d5fa7da624c upstream.

No functional change, but re-order the cases so they
evaluate properly due to the way the DCE macros work.

Noticed by kallisti5 on IRC.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/radeon: fix up pll selection on DCE5/6
Alex Deucher [Tue, 17 Jul 2012 18:02:43 +0000 (14:02 -0400)]
drm/radeon: fix up pll selection on DCE5/6

commit 26fe45a0a76f165425f332a5aaa298f149f9db22 upstream.

Selecting ATOM_PPLL_INVALID should be equivalent as the
DCPLL or PPLL0 are already programmed for the DISPCLK, but
the preferred method is to always specify the PLL selected.
SetPixelClock will check the parameters and skip the
programming if the PLL is already set up.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
[bwh: Backported to 3.2: drop the DCE6 case]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoahci: Add alternate identifier for the 88SE9172
Alan Cox [Tue, 4 Sep 2012 15:07:18 +0000 (16:07 +0100)]
ahci: Add alternate identifier for the 88SE9172

commit 17c60c6b763cb5b83b0185e7d38d01d18e55a05a upstream.

This can also appear as 0x9192. Reported in bugzilla and confirmed with the
board documentation for these boards.

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42970
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agovmwgfx: add dumb ioctl support
Dave Airlie [Tue, 28 Aug 2012 01:53:54 +0000 (01:53 +0000)]
vmwgfx: add dumb ioctl support

commit 5e1782d224c79b26ab7d5c31e3f87657000714fb upstream.

Testing and works with the -modesetting driver,

Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoALSA: ice1724: Use linear scale for AK4396 volume control.
Matteo Frigo [Wed, 12 Sep 2012 14:12:06 +0000 (10:12 -0400)]
ALSA: ice1724: Use linear scale for AK4396 volume control.

commit 3737e2be505d872bf2b3c1cd4151b2d2b413d7b5 upstream.

The AK4396 DAC has a linear-scale attentuator, but
sound/pci/ice1712/prodigy_hifi.c used a log scale instead, which is
not quite right.  This patch restores the correct scale, borrowing
from the ak4396 code in sound/pci/oxygen/oxygen.c.

Signed-off-by: Matteo Frigo <athena@fftw.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agohwmon: (twl4030-madc-hwmon) Initialize uninitialized structure elements
Guenter Roeck [Tue, 19 Jun 2012 15:00:00 +0000 (08:00 -0700)]
hwmon: (twl4030-madc-hwmon) Initialize uninitialized structure elements

commit 73d7c119255615a26070f9d6cdb722a166a29015 upstream.

twl4030_madc_conversion uses do_avg and type structure elements of
twl4030_madc_request. Initialize structure to avoid random operation.

Fix for: Coverity CID 200794 Uninitialized scalar variable.

Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoEHCI: Update qTD next pointer in QH overlay region during unlink
Pavankumar Kondeti [Fri, 7 Sep 2012 05:53:28 +0000 (11:23 +0530)]
EHCI: Update qTD next pointer in QH overlay region during unlink

commit 3d037774b42ed677f699b1dce7d548d55f4e4c2b upstream.

There is a possibility of QH overlay region having reference to a stale
qTD pointer during unlink.

Consider an endpoint having two pending qTD before unlink process begins.
The endpoint's QH queue looks like this.

qTD1 --> qTD2 --> Dummy

To unlink qTD2, QH is removed from asynchronous list and Asynchronous
Advance Doorbell is programmed.  The qTD1's next qTD pointer is set to
qTD2'2 next qTD pointer and qTD2 is retired upon controller's doorbell
interrupt.  If QH's current qTD pointer points to qTD1, transfer overlay
region still have reference to qTD2. But qtD2 is just unlinked and freed.
This may cause EHCI system error.  Fix this by updating qTD next pointer
in QH overlay region with the qTD next pointer of the current qTD.

Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agostaging: r8712u: fix bug in r8712_recv_indicatepkt()
Eric Dumazet [Mon, 10 Sep 2012 19:22:11 +0000 (21:22 +0200)]
staging: r8712u: fix bug in r8712_recv_indicatepkt()

commit abf02cfc179bb4bd30d05f582d61b3b8f429b813 upstream.

64bit arches have a buggy r8712u driver, let's fix it.

skb->tail must be set properly or network stack behavior is undefined.

Addresses https://bugzilla.redhat.com/show_bug.cgi?id=847525
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=45071

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Dave Jones <davej@redhat.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: ftdi_sio: do not claim CDC ACM function
Bjørn Mork [Mon, 10 Sep 2012 10:01:05 +0000 (12:01 +0200)]
USB: ftdi_sio: do not claim CDC ACM function

commit f08dea734844aa42ec57c229b0b73b3d7d21f810 upstream.

The Microchip vid:pid 04d8:000a is used for their CDC ACM
demo firmware application.  This is a device with a single
function conforming to the CDC ACM specification and with
the intention of demonstrating CDC ACM class firmware and
driver interaction.  The demo is used on a number of
development boards, and may also be used unmodified by
vendors using Microchip hardware.

Some vendors have re-used this vid:pid for other types of
firmware, emulating FTDI chips. Attempting to continue to
support such devices without breaking class based
applications that by matching on interface
class/subclass/proto being ff/ff/00.  I have no information
about the actual device or interface descriptors, but this
will at least make the proper CDC ACM devices work again.
Anyone having details of the offending device's descriptors
should update this entry with the details.

Reported-by: Florian Wöhrl <fw@woehrl.biz>
Reported-by: Xiaofan Chen <xiaofanc@gmail.com>
Cc: Alan Cox <alan@linux.intel.com>
Cc: Bruno Thomsen <bruno.thomsen@gmail.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoALSA: hda - Fix Oops at codec reset/reconfig
Takashi Iwai [Mon, 10 Sep 2012 07:39:31 +0000 (09:39 +0200)]
ALSA: hda - Fix Oops at codec reset/reconfig

commit 07dc59f0988cb54fd87bd373b3b27eb2401dd811 upstream.

snd_hda_codec_reset() calls restore_pincfgs() where the codec is
powered up again, which eventually tries to resume and initialize via
the callbacks of the codec.  However, it's the place just after codec
free callback, thus no codec callbacks should be called after that.
On a codec like CS4206, it results in Oops due to the access in init
callback.

This patch fixes the issue by clearing the codec callbacks properly
after freeing codec.

Reported-by: Daniel J Blueman <daniel@quora.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoARM: 7526/1: traps: send SIGILL if get_user fails on undef handling path
Will Deacon [Fri, 7 Sep 2012 17:21:44 +0000 (18:21 +0100)]
ARM: 7526/1: traps: send SIGILL if get_user fails on undef handling path

commit 2b2040af0b64cd93e5d4df2494c4486cf604090d upstream.

get_user may fail to load from the provided __user address due to an
unhandled fault generated by the access.

In the case of the undefined instruction trap, this results in failure
to load the faulting instruction, in which case we should send SIGILL to
the task rather than continue with potentially uninitialised data.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoARM: 7513/1: Make sure dtc is built before running it
David Brown [Tue, 4 Sep 2012 20:36:37 +0000 (21:36 +0100)]
ARM: 7513/1: Make sure dtc is built before running it

commit 70b0476a2394de4f4e32e0b67288d80ff71ca963 upstream.

'make dtbs' in a clean tree will try running the dtc before actually
building it.  Make these rules depend upon the scripts to build it.

Signed-off-by: David Brown <davidb@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoSUNRPC: Fix a UDP transport regression
Trond Myklebust [Fri, 7 Sep 2012 15:08:50 +0000 (11:08 -0400)]
SUNRPC: Fix a UDP transport regression

commit f39c1bfb5a03e2d255451bff05be0d7255298fa4 upstream.

Commit 43cedbf0e8dfb9c5610eb7985d5f21263e313802 (SUNRPC: Ensure that
we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing
hangs in the case of NFS over UDP mounts.

Since neither the UDP or the RDMA transport mechanism use dynamic slot
allocation, we can skip grabbing the socket lock for those transports.
Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA
case.

Note that the NFSv4.1 back channel assigns the slot directly
through rpc_run_bc_task, so we can ignore that case.

Reported-by: Dick Streefland <dick.streefland@altium.nl>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFS: return error from decode_getfh in decode open
Weston Andros Adamson [Thu, 6 Sep 2012 19:54:27 +0000 (15:54 -0400)]
NFS: return error from decode_getfh in decode open

commit 01913b49cf1dc6409a07dd2a4cc6af2e77f3c410 upstream.

If decode_getfh failed, nfs4_xdr_dec_open would return 0 since the last
decode_* call must have succeeded.

Signed-off-by: Weston Andros Adamson <dros@netapp.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agokobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()"
Bjørn Mork [Sun, 2 Sep 2012 13:41:34 +0000 (15:41 +0200)]
kobject: fix oops with "input0: bad kobj_uevent_env content in show_uevent()"

commit 60e233a56609fd963c59e99bd75c663d63fa91b6 upstream.

Fengguang Wu <fengguang.wu@intel.com> writes:

> After the __devinit* removal series, I can still get kernel panic in
> show_uevent(). So there are more sources of bug..
>
> Debug patch:
>
> @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
>                 goto out;
>
>         /* copy keys to file */
> -       for (i = 0; i < env->envp_idx; i++)
> +       dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen, env->envp_idx, top_kobj->name, dev->kobj.name);
> +       for (i = 0; i < env->envp_idx; i++) {
> +               printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i, env->envp[i]);
>                 count += sprintf(&buf[count], "%s\n", env->envp[i]);
> +       }
>
> Oops message, the env[] is again not properly initilized:
>
> [   44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
> [   44.069552] uevent 0 env[0]: (null)

This is a completely different CONFIG_HOTPLUG problem, only
demonstrating another reason why CONFIG_HOTPLUG should go away.  I had a
hard time trying to disable it anyway ;-)

The problem this time is lots of code assuming that a call to
add_uevent_var() will guarantee that env->buflen > 0.  This is not true
if CONFIG_HOTPLUG is unset.  So things like this end up overwriting
env->envp_idx because the array index is -1:

if (add_uevent_var(env, "MODALIAS="))
return -ENOMEM;
        len = input_print_modalias(&env->buf[env->buflen - 1],
   sizeof(env->buf) - env->buflen,
   dev, 0);

Don't know what the best action is, given that there seem to be a *lot*
of this around the kernel.  This patch "fixes" the problem for me, but I
don't know if it can be considered an appropriate fix.

[ It is the correct fix for now, for 3.7 forcing CONFIG_HOTPLUG to
always be on is the longterm fix, but it's too late for 3.6 and older
kernels to resolve this that way - gregkh ]

Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: add device quirk for Joss Optical touchboard
Alan Stern [Tue, 4 Sep 2012 14:41:02 +0000 (10:41 -0400)]
USB: add device quirk for Joss Optical touchboard

commit 92fc7a8b0f20bdb243c706daf42658e8e0cd2ef0 upstream.

This patch (as1604) adds a CONFIG_INTF_STRINGS quirk for the Joss
infrared touchboard device.  The device doesn't like to be asked for
its interface strings.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: adam ? <adam3337@wp.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: ftdi_sio: PID for NZR SEM 16+ USB
Horst Schirmeier [Thu, 30 Aug 2012 22:00:28 +0000 (00:00 +0200)]
USB: ftdi_sio: PID for NZR SEM 16+ USB

commit 26a538b9ea2a3ee10dafc0068f0560dfd7b7ba37 upstream.

This adds the USB PID for the NZR SEM 16+ USB energy monitor device
<http://www.nzr.de>.  It works perfectly with the GPL software on
<http://schou.dk/linux/sparometer/>.

Signed-off-by: Horst Schirmeier <horst@schirmeier.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: ftdi-sio: add support for more Physik Instrumente devices
Éric Piel [Tue, 4 Sep 2012 15:25:06 +0000 (17:25 +0200)]
USB: ftdi-sio: add support for more Physik Instrumente devices

commit dafc4f7be1a556ca3868d343c00127728b397068 upstream.

Commit b69cc672052540 added support for the E-861.  After acquiring a C-867, I
realised that every Physik Instrumente's device has a different PID. They are
listed in the Windows device driver's .inf file. So here are all PIDs for the
current (and probably future) USB devices from Physik Instrumente.

Compiled, but only actually tested on the E-861 and C-867.

Signed-off-by: Éric Piel <piel@delmic.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoibmveth: Fix alignment of rx queue bug
Santiago Leon [Tue, 4 Sep 2012 14:41:37 +0000 (14:41 +0000)]
ibmveth: Fix alignment of rx queue bug

commit d90c92fee89ccd75ef2646f3bde0b4c0450666c3 upstream.

This patch fixes a bug found by Nish Aravamudan
(https://lkml.org/lkml/2012/5/15/220) where the driver is not following
the spec (it is not aligning the rx buffer on a 16-byte boundary) and the
hypervisor aborts the registration, making the device unusable.

The fix follows BenH's recommendation (https://lkml.org/lkml/2012/7/20/461)
to replace the kmalloc+map for a single call to dma_alloc_coherent()
because that function always aligns to a 16-byte boundary.

The stable trees will run into this bug whenever the rx buffer kmalloc call
returns something not aligned on a 16-byte boundary.

Signed-off-by: Santiago Leon <santil@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agotty: serial: imx: don't reinit clock in imx_setup_ufcr()
Dirk Behme [Fri, 31 Aug 2012 08:02:47 +0000 (10:02 +0200)]
tty: serial: imx: don't reinit clock in imx_setup_ufcr()

commit 7be0670f7b9198382938a03ff3db7f47ef6b4780 upstream.

Remove the clock configuration from imx_setup_ufcr(). This
isn't needed here and will cause garbage output if done.

To be be sure that we only touch the bits we want (TXTL and RXTL)
we have to mask out all other bits of the UFCR register. Add
one non-existing bit macro for this, too (bit 6, DCEDTE on i.MX6).

Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
CC: Shawn Guo <shawn.guo@linaro.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Troy Kisky <troy.kisky@boundarydevices.com>
CC: Xinyu Chen <xinyu.chen@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: deleted code in imx_setup_ufcr() refers to
 sport->clk not sport->clk_per]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agotty: serial: imx: console write routing is unsafe on SMP
Xinyu Chen [Mon, 27 Aug 2012 07:36:51 +0000 (09:36 +0200)]
tty: serial: imx: console write routing is unsafe on SMP

commit 9ec1882df244c4ee1baa692676fef5e8b0f5487d upstream.

The console feature's write routing is unsafe on SMP with
the startup/shutdown call.

There could be several consumers of the console
* the kernel printk
* the init process using /dev/kmsg to call printk to show log
* shell, which open /dev/console and write with sys_write()

The shell goes into the normal uart open/write routing,
but the other two go into the console operations.
The open routing calls imx serial startup, which will write USR1/2
register without any lock and critical with imx_console_write call.

Add a spin_lock for startup/shutdown/console_write routing.

This patch is a port from Freescale's Android kernel.

Signed-off-by: Xinyu Chen <xinyu.chen@freescale.com>
Tested-by: Dirk Behme <dirk.behme@de.bosch.com>
CC: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agousb: host: xhci: fix compilation error for non-PCI based stacks
Moiz Sonasath [Wed, 5 Sep 2012 05:34:26 +0000 (08:34 +0300)]
usb: host: xhci: fix compilation error for non-PCI based stacks

commit 296365781903226a3fb8758901eaeec09d2798e4 upstream.

For non PCI-based stacks, this function call
usb_disable_xhci_ports(to_pci_dev(hcd->self.controller));
made from xhci_shutdown is not applicable.

Ideally, we wouldn't have any PCI-specific code on
a generic driver such as the xHCI stack, but it looks
like we should just stub usb_disable_xhci_ports() out
for non-PCI devices.

[ balbi@ti.com: slight improvement to commit log ]

This patch should be backported to kernels as old as 3.0, since the
commit it fixes (e95829f474f0db3a4d940cae1423783edd966027 "xhci: Switch
PPT ports to EHCI on shutdown.") was marked for stable.

Signed-off-by: Moiz Sonasath<m-sonasath@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agousb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware
Alexis R. Cortes [Fri, 3 Aug 2012 19:00:27 +0000 (14:00 -0500)]
usb: host: xhci: Fix Compliance Mode on SN65LVPE502CP Hardware

commit 71c731a296f1b08a3724bd1b514b64f1bda87a23 upstream.

This patch is intended to work around a known issue on the
SN65LVPE502CP USB3.0 re-driver that can delay the negotiation
between a device and the host past the usual handshake timeout.

If that happens on the first insertion, the host controller
port will enter in Compliance Mode and NO port status event will
be generated (as per xHCI Spec) making impossible to detect this
event by software. The port will remain in compliance mode until
a warm reset is applied to it.

As a result of this, the port will seem "dead" to the user and no
device connections or disconnections will be detected.

For solving this, the patch creates a timer which polls every 2
seconds the link state of each host controller's port (this
by reading the PORTSC register) and recovers the port by issuing a
Warm reset every time Compliance mode is detected.

If a xHC USB3.0 port has previously entered to U0, the compliance
mode issue will NOT occur only until system resumes from
sleep/hibernate, therefore, the compliance mode timer is stopped
when all xHC USB 3.0 ports have entered U0. The timer is initialized
again after each system resume.

Since the issue is being caused by a piece of hardware, the timer
will be enabled ONLY on those systems that have the SN65LVPE502CP
installed (this patch uses DMI strings for detecting those systems)
therefore making this patch to act as a quirk (XHCI_COMP_MODE_QUIRK
has been added to the xhci stack).

This patch applies for these systems:
Vendor: Hewlett-Packard. System Models: Z420, Z620 and Z820.

This patch should be backported to kernels as old as 3.2, as that was
the first kernel to support warm reset.  The kernels will need to
contain both commit 10d674a82e553cb8a1f41027bb3c3e309b3f6804 "USB: When
hot reset for USB3 fails, try warm reset" and commit
8bea2bd37df08aaa599aa361a9f8b836ba98e554 "usb: Add support for root hub
port status CAS".  The first patch add warm reset support, and the
second patch modifies the USB core to issue a warm reset when the port
is in compliance mode.

Signed-off-by: Alexis R. Cortes <alexis.cortes@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxhci: Make handover code more robust
Matthew Garrett [Tue, 14 Aug 2012 20:44:49 +0000 (16:44 -0400)]
xhci: Make handover code more robust

commit e955a1cd086de4d165ae0f4c7be7289d84b63bdc upstream.

My test platform (Intel DX79SI) boots reliably under BIOS, but frequently
crashes when booting via UEFI. I finally tracked this down to the xhci
handoff code. It seems that reads from the device occasionally just return
0xff, resulting in xhci_find_next_cap_offset generating a value that's
larger than the resource region. We then oops when attempting to read the
value. Sanity checking that value lets us avoid the crash.

I've no idea what's causing the underlying problem, and xhci still doesn't
actually *work* even with this, but the machine at least boots which will
probably make further debugging easier.

This should be backported to kernels as old as 2.6.31, that contain the
commit 66d4eadd8d067269ea8fead1a50fe87c2979a80d "USB: xhci: BIOS handoff
and HW initialization."

Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxhci: Fix a logical vs bitwise AND bug
Dan Carpenter [Mon, 13 Aug 2012 16:57:03 +0000 (19:57 +0300)]
xhci: Fix a logical vs bitwise AND bug

commit 052c7f9ffb0e95843e75448d02664459253f9ff8 upstream.

The intent was to test whether the flag was set.

This patch should be backported to stable kernels as old as 3.0, since
it fixes a bug in commit e95829f474f0db3a4d940cae1423783edd966027 "xhci:
Switch PPT ports to EHCI on shutdown.", which was marked for stable.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxhci: Switch PPT ports to EHCI on shutdown.
Sarah Sharp [Mon, 23 Jul 2012 15:59:30 +0000 (18:59 +0300)]
xhci: Switch PPT ports to EHCI on shutdown.

commit e95829f474f0db3a4d940cae1423783edd966027 upstream.

The Intel desktop boards DH77EB and DH77DF have a hardware issue that
can be worked around by BIOS.  If the USB ports are switched to xHCI on
shutdown, the xHCI host will send a spurious interrupt, which will wake
the system.  Some BIOS will work around this, but not all.

The bug can be avoided if the USB ports are switched back to EHCI on
shutdown.  The Intel Windows driver switches the ports back to EHCI, so
change the Linux xHCI driver to do the same.

Unfortunately, we can't tell the two effected boards apart from other
working motherboards, because the vendors will change the DMI strings
for the DH77EB and DH77DF boards to their own custom names.  One example
is Compulab's mini-desktop, the Intense-PC.  Instead, key off the
Panther Point xHCI host PCI vendor and device ID, and switch the ports
over for all PPT xHCI hosts.

The only impact this will have on non-effected boards is to add a couple
hundred milliseconds delay on boot when the BIOS has to switch the ports
over from EHCI to xHCI.

This patch should be backported to kernels as old as 3.0, that contain
the commit 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Denis Turischev <denis@compulab.co.il>
Tested-by: Denis Turischev <denis@compulab.co.il>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agostaging: zcache: fix cleancache race condition with shrinker
Seth Jennings [Wed, 29 Aug 2012 21:58:45 +0000 (16:58 -0500)]
staging: zcache: fix cleancache race condition with shrinker

commit 6d7d9798ad5c97ee4e911dd070dc12dc5ae55bd0 upstream.

This patch fixes a race condition that results in memory
corruption when using cleancache.

The race exists between the zcache shrinker handler,
shrink_zcache_memory() and cleancache_get_page().

In most cases, the shrinker will both evict a zbpg
from its buddy list and flush it from tmem before a
cleancache_get_page() occurs on that page. A subsequent
cleancache_get_page() will fail in the tmem layer.

In the rare case that two occur together and the
cleancache_get_page() path gets through the tmem
layer before the shrinker path can flush tmem,
zbud_decompress() does a check to see if the zbpg is a
"zombie", i.e. not on a buddy list, which means the shrinker
is in the process of reclaiming it. If the zbpg is a zombie,
zbud_decompress() returns -EINVAL.

However, this return code is being ignored by the caller,
zcache_pampd_get_data_and_free(), which results in the
caller of cleancache_get_page() thinking that the page has
been properly retrieved when it has not.

This patch modifies zcache_pampd_get_data_and_free() to
convey the failure up the stack so that the caller of
cleancache_get_page() knows the page retrieval failed.

This needs to be applied to stable trees as well.
zcache-main.c was named zcache.c before v3.1, so
I'm not sure how you want to handle trees earlier
than that.

Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agort2800usb: Added rx packet length validity check
Sergei Poselenov [Sun, 2 Sep 2012 09:14:32 +0000 (13:14 +0400)]
rt2800usb: Added rx packet length validity check

commit efd5d6b03bd9c9e0df646c56fb5f4f3e25e5c1ac upstream.

On our system (ARM Cortex-M3 SOC running linux-2.6.33)
frequent crashes were observed in the rt2800usb module
because of the invalid length of the received packet (3392,
46920...). This patch adds the sanity check on the packet
legth. Also, changed WARNING to ERROR in rt2x00lib_rxdone()
so that the bad packet condition would be noticed.

The fix was tested on the latest compat-wireless-3.5.1-1-snpc.

Signed-off-by: Sergei Poselenov <sposelenov@emcraft.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agort2x00: Fix rfkill polling prior to interface start.
Gertjan van Wingerde [Fri, 31 Aug 2012 17:22:11 +0000 (19:22 +0200)]
rt2x00: Fix rfkill polling prior to interface start.

commit a396e10019eaf3809b0219c966865aaafec12630 upstream.

We need to program the rfkill switch GPIO pin direction to input at
device initialization time, not only when the interface is brought up.
Doing this only when the interface is brought up could lead to rfkill
detecting the switch is turned on erroneously and inability to create
the interface and bringing it up.

Reported-and-tested-by: Andreas Messer <andi@bastelmap.de>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agort2x00: Fix word size of rt2500usb MAC_CSR19 register.
Gertjan van Wingerde [Fri, 31 Aug 2012 17:22:10 +0000 (19:22 +0200)]
rt2x00: Fix word size of rt2500usb MAC_CSR19 register.

commit 6ced58a5dbb94dbfbea1b33ca3c56d1e929cd548 upstream.

The register is 16 bits wide, not 32.

Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agort2x00: Identify ASUS USB-N53 device.
Gertjan van Wingerde [Fri, 31 Aug 2012 17:22:09 +0000 (19:22 +0200)]
rt2x00: Identify ASUS USB-N53 device.

commit 177ef8360fabdc49ff08d2598c06e7f7a36b53e3 upstream.

This is an RT3572 based device.

Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo Van Doorn <ivdoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoIntel xhci: Only switch the switchable ports
Keng-Yu Lin [Thu, 9 Aug 2012 17:39:23 +0000 (01:39 +0800)]
Intel xhci: Only switch the switchable ports

commit a96874a2a92feaef607ddd3137277a788cb927a6 upstream.

With a previous patch to enable the EHCI/XHCI port switching, it switches
all the available ports.

The assumption is not correct because the BIOS may expect some ports
not switchable by the OS.

There are two more registers that contains the information of the switchable
and non-switchable ports.

This patch adds the checking code for the two register so that only the
switchable ports are altered.

This patch should be backported to kernels as old as 3.0, that contain
commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxhci: Recognize USB 3.0 devices as superspeed at powerup
Manoj Iyer [Wed, 22 Aug 2012 16:53:18 +0000 (11:53 -0500)]
xhci: Recognize USB 3.0 devices as superspeed at powerup

commit 29d214576f936db627ff62afb9ef438eea18bcd2 upstream.

On Intel Panther Point chipset USB 3.0 devices show up as
high-speed devices on powerup, but after an s3 cycle they are
correctly recognized as SuperSpeed. At powerup switch the port
to xHCI so that USB 3.0 devices are correctly recognized.

BugLink: http://bugs.launchpad.net/bugs/1000424
This patch should be backported to kernels as old as 3.0, that contain
commit ID 69e848c2090aebba5698a1620604c7dccb448684 "Intel xhci: Support
EHCI/xHCI port switching."

Signed-off-by: Manoj Iyer <manoj.iyer@canonical.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agostaging: vt6656: [BUG] - Failed connection, incorrect endian.
Malcolm Priestley [Wed, 29 Aug 2012 22:08:21 +0000 (23:08 +0100)]
staging: vt6656: [BUG] - Failed connection, incorrect endian.

commit aa209eef3ce8419ff2926c2fa944dfbfb5afbacb upstream.

Hi,

This patch fixes a bug with driver failing to negotiate a connection.

The bug was traced to commit
203e4615ee9d9fa8d3506b9d0ef30095e4d5bc90
staging: vt6656: removed custom definitions of Ethernet packet types

In that patch, definitions in include/linux/if_ether.h replaced ones
in tether.h which had both big and little endian definitions.

include/linux/if_ether.h only refers to big endian values, cpu_to_be16
should be used for the correct endian architectures.

Signed-off-by: Malcolm Priestley <tvboxspy@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agostaging: comedi: das08: Correct AO output for das08jr-16-ao
Ian Abbott [Fri, 31 Aug 2012 19:41:30 +0000 (20:41 +0100)]
staging: comedi: das08: Correct AO output for das08jr-16-ao

commit 61ed59ed09e6ad2b8395178ea5ad5f653bba08e3 upstream.

Don't zero out bits 15..12 of the data value in `das08jr_ao_winsn()` as
that knobbles the upper three-quarters of the output range for the
'das08jr-16-ao' board.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agostaging: comedi: das08: Correct AI encoding for das08jr-16-ao
Ian Abbott [Fri, 31 Aug 2012 19:41:29 +0000 (20:41 +0100)]
staging: comedi: das08: Correct AI encoding for das08jr-16-ao

commit e6391a182865efc896cb2a8d79e07b7ac2f45b48 upstream.

The element of `das08_boards[]` for the 'das08jr-16-ao' board has the
`ai_encoding` member set to `das08_encode12`.  It should be set to
`das08_encode16` same as the 'das08jr/16' board.  After all, this board
has 16-bit AI resolution.

The description of the A/D LSB register at offset 0 seems incorrect in
the user manual "cio-das08jr-16-ao.pdf" as it implies that the AI
resolution is only 12 bits.  The diagrams of the A/D LSB and MSB
registers show 15 data bits and a sign bit, which matches what the
software expects for the `das08_encode16` AI encoding method.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[bwh: Backported to 3.2: adjust indentation]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFS: Fix a problem with the legacy binary mount code
Trond Myklebust [Tue, 4 Sep 2012 15:05:07 +0000 (11:05 -0400)]
NFS: Fix a problem with the legacy binary mount code

commit 872ece86ea5c367aa92f44689c2d01a1c767aeb3 upstream.

Apparently, am-utils is still using the legacy binary mountdata interface,
and is having trouble parsing /proc/mounts due to the 'port=' field being
incorrectly set.

The following patch should fix up the regression.

Reported-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoNFS: Fix the initialisation of the readdir 'cookieverf' array
Trond Myklebust [Mon, 3 Sep 2012 18:56:02 +0000 (14:56 -0400)]
NFS: Fix the initialisation of the readdir 'cookieverf' array

commit c3f52af3e03013db5237e339c817beaae5ec9e3a upstream.

When the NFS_COOKIEVERF helper macro was converted into a static
inline function in commit 99fadcd764 (nfs: convert NFS_*(inode)
helpers to static inline), we broke the initialisation of the
readdir cookies, since that depended on doing a memset with an
argument of 'sizeof(NFS_COOKIEVERF(inode))' which therefore
changed from sizeof(be32 cookieverf[2]) to sizeof(be32 *).

At this point, NFS_COOKIEVERF seems to be more of an obfuscation
than a helper, so the best thing would be to just get rid of it.

Also see: https://bugzilla.kernel.org/show_bug.cgi?id=46881

Reported-by: Andi Kleen <andi@firstfloor.org>
Reported-by: David Binderman <dcb314@hotmail.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoperf_event: Switch to internal refcount, fix race with close()
Al Viro [Mon, 20 Aug 2012 13:59:25 +0000 (14:59 +0100)]
perf_event: Switch to internal refcount, fix race with close()

commit a6fa941d94b411bbd2b6421ffbde6db3c93e65ab upstream.

Don't mess with file refcounts (or keep a reference to file, for
that matter) in perf_event.  Use explicit refcount of its own
instead.  Deal with the race between the final reference to event
going away and new children getting created for it by use of
atomic_long_inc_not_zero() in inherit_event(); just have the
latter free what it had allocated and return NULL, that works
out just fine (children of siblings of something doomed are
created as singletons, same as if the child of leader had been
created and immediately killed).

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20120820135925.GG23464@ZenIV.linux.org.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agocan: mcp251x: avoid repeated frame bug
Benoît Locher [Mon, 27 Aug 2012 13:02:45 +0000 (15:02 +0200)]
can: mcp251x: avoid repeated frame bug

commit cab32f39dcc5b35db96497dc0a026b5dea76e4e7 upstream.

The MCP2515 has a silicon bug causing repeated frame transmission, see section
5 of MCP2515 Rev. B Silicon Errata Revision G (March 2007).

Basically, setting TXBnCTRL.TXREQ in either SPI mode (00 or 11) will eventually
cause the bug. The workaround proposed by Microchip is to use mode 00 and send
a RTS command on the SPI bus to initiate the transmission.

Signed-off-by: Benoît Locher <Benoit.Locher@skf.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/i915: only enable sdvo hotplug irq if needed
Jani Nikula [Wed, 29 Aug 2012 11:08:42 +0000 (14:08 +0300)]
drm/i915: only enable sdvo hotplug irq if needed

commit fcbc50da7753b210b4442ca9abc4efbd4e481f6e upstream.

Avoid constant wakeups caused by noisy irq lines when we don't even care
about the irq. This should be particularly useful for i945g/gm where the
hotplug has been disabled:

commit 768b107e4b3be0acf6f58e914afe4f337c00932b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri May 4 11:29:56 2012 +0200

    drm/i915: disable sdvo hotplug on i945g/gm

v2: While at it, remove the bogus hotplug_active read, and do not mask
hotplug_active[0] before checking whether the irq is needed, per discussion
with Daniel on IRC.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=38442
Tested-by: Dominik Köppl <dominik@devwork.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x
Chris Wilson [Fri, 11 May 2012 17:01:33 +0000 (18:01 +0100)]
drm/i915: SDVO hotplug have different interrupt status bits for i915/i965/g4x

commit 084b612ecf8e59973576b2f644e6949609c79375 upstream.

Note that gen3 is the only platform where we've got the bit
definitions right, hence the workaround of disabling sdvo hotplug
support on i945g/gm is not due to misdiagnosis of broken hotplug irq
handling ...

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: add some blurb about sdvo hotplug fail on i945g/gm I've
wondered about while reviewing.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[bwh: Backported to 3.2:
 - Adjust context
 - Handle all three cases in i915_driver_irq_postinstall() as there
   are not separate functions for gen3 and gen4+
 - Carry on using IS_SDVOB() in intel_sdvo_init()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access type
Will Deacon [Thu, 16 Aug 2012 17:55:44 +0000 (18:55 +0100)]
ARM: 7496/1: hw_breakpoint: don't rely on dfsr to show watchpoint access type

commit bf8801145c01ab600f8df66e8c879ac642fa5846 upstream.

From ARM debug architecture v7.1 onwards, a watchpoint exception causes
the DFAR to be updated with the faulting data address. However, DFSR.WnR
takes an UNKNOWN value and therefore cannot be used in general to
determine the access type that triggered the watchpoint.

This patch forbids watchpoints without an overflow handler from
specifying a specific access type (load/store). Those with overflow
handlers must be able to handle false positives potentially triggered by
a watchpoint of a different access type on the same address. For
SIGTRAP-based handlers (i.e. ptrace), this should have no impact.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: option: replace ZTE K5006-Z entry with vendor class rule
Bjørn Mork [Tue, 11 Sep 2012 07:40:31 +0000 (09:40 +0200)]
USB: option: replace ZTE K5006-Z entry with vendor class rule

commit ba9edaa468869a8cea242a411066b0f490751798 upstream.

Fix the ZTE K5006-Z entry so that it actually matches anything

  commit f1b5c997 USB: option: add ZTE K5006-Z

added a device specific entry assuming that the device would use
class/subclass/proto == ff/ff/ff like other ZTE devices. It
turns out that ZTE has started using vendor specific subclass
and protocol codes:

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480  MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=19d2 ProdID=1018 Rev= 0.00
S:  Manufacturer=ZTE,Incorporated
S:  Product=ZTE LTE Technologies MSM
S:  SerialNumber=MF821Vxxxxxxx
C:* #Ifs= 5 Cfg#= 1 Atr=c0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=86 Prot=10 Driver=(none)
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=05 Driver=(none)
E:  Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=02 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=06 Prot=00 Driver=qmi_wwan
E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=2ms
E:  Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
E:  Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

We do not have any information on how ZTE intend to use these
codes, but let us assume for now that the 3 sets matching
serial functions in the K5006-Z always will identify a serial
function in a ZTE device.

Cc: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoUSB: option: add ZTE K5006-Z
Bjørn Mork [Wed, 15 Aug 2012 13:43:33 +0000 (15:43 +0200)]
USB: option: add ZTE K5006-Z

commit f1b5c997e68533df1f96dcd3068a231bca495603 upstream.

The ZTE (Vodafone) K5006-Z use the following
interface layout:

00 DIAG
01 secondary
02 modem
03 networkcard
04 storage

Ignoring interface #3 which is handled by the qmi_wwan
driver.

Cc: Thomas Schäfer <tschaefer@t-online.de>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoi2c-i801: Add Device IDs for Intel Lynx Point-LP PCH
James Ralston [Mon, 10 Sep 2012 08:14:02 +0000 (10:14 +0200)]
i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH

commit 4a8f1ddde942e232387e6129ce4f4c412e43802f upstream.

Add the SMBus Device IDs for the Intel Lynx Point-LP PCH.

Signed-off-by: James Ralston <james.d.ralston@intel.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoi2c-i801: Add device IDs for Intel Lynx Point
Seth Heasley [Mon, 26 Mar 2012 19:47:19 +0000 (21:47 +0200)]
i2c-i801: Add device IDs for Intel Lynx Point

commit 062737fb6d90c632439b1f77ad6a4965cfc84a20 upstream.

Add the SMBus controller device IDs for the Intel Lynx Point PCH.

Signed-off-by: Seth Heasley <seth.heasley@intel.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present
Will Deacon [Fri, 10 Aug 2012 16:51:18 +0000 (17:51 +0100)]
ARM: 7487/1: mm: avoid setting nG bit for user mappings that aren't present

commit 47f1204329237a0f8655f5a9f14a38ac81946ca1 upstream.

Swap entries are encoding in ptes such that !pte_present(pte) and
pte_file(pte). The remaining bits of the descriptor are used to identify
the swapfile and offset within it to the swap entry.

When writing such a pte for a user virtual address, set_pte_at
unconditionally sets the nG bit, which (in the case of LPAE) will
corrupt the swapfile offset and lead to a BUG:

[  140.494067] swap_free: Unused swap offset entry 000763b4
[  140.509989] BUG: Bad page map in process rs:main Q:Reg  pte:0ec76800 pmd:8f92e003

This patch fixes the problem by only setting the nG bit for user
mappings that are actually present.

Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxhci: Fix bug after deq ptr set to link TRB.
Sarah Sharp [Thu, 26 Jul 2012 19:03:59 +0000 (12:03 -0700)]
xhci: Fix bug after deq ptr set to link TRB.

This patch fixes a particularly nasty bug that was revealed by the ring
expansion patches.  The bug has been present since the very beginning of
the xHCI driver history, and could have caused general protection faults
from bad memory accesses.

The first thing to note is that a Set TR Dequeue Pointer command can
move the dequeue pointer to a link TRB, if the canceled or stalled
transfer TD ended just before a link TRB.  The function to increment the
dequeue pointer, inc_deq, was written before cancellation and stall
support was added.  It assumed that the dequeue pointer could never
point to a link TRB.  It would unconditionally increment the dequeue
pointer at the start of the function, check if the pointer was now on a
link TRB, and move it to the top of the next segment if so.

This means that if a Set TR Dequeue Point command moved the dequeue
pointer to a link TRB, a subsequent call to inc_deq() would move the
pointer off the segment and into la-la-land.  It would then read from
that memory to determine if it was a link TRB.  Other functions would
often call inc_deq() until the dequeue pointer matched some other
pointer, which means this function would quite happily read all of
system memory before wrapping around to the right pointer value.

Often, there would be another endpoint segment from a different ring
allocated from the same DMA pool, which would be contiguous to the
segment inc_deq just stepped off of.  inc_deq would eventually find the
link TRB in that segment, and blindly move the dequeue pointer back to
the top of the correct ring segment.

The only reason the original code worked at all is because there was
only one ring segment.  With the ring expansion patches, the dequeue
pointer would eventually wrap into place, but the dequeue segment would
be out-of-sync.  On the second TD after the dequeue pointer was moved to
a link TRB, trb_in_td() would fail (because the dequeue pointer and
dequeue segment were out-of-sync), and this message would appear:

ERROR Transfer event TRB DMA ptr not part of current TD

This fixes bugzilla entry 4333 (option-based modem unhappy on USB 3.0
port: "Transfer event TRB DMA ptr not part of current TD", "rejecting
I/O to offline device"),

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

and possibly other general protection fault bugs as well.

This patch should be backported to kernels as old as 2.6.31.  The
original upstream commit is 50d0206fcaea3e736f912fd5b00ec6233fb4ce44,
but it does not apply to kernels older than 3.4, because inc_deq was
changed in 3.3 and 3.4.  This patch should apply to the 3.2 kernel and
older.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
9 years agodrm/i915: Wait for all pending operations to the fb before disabling the pipe
Chris Wilson [Tue, 17 Apr 2012 09:05:38 +0000 (10:05 +0100)]
drm/i915: Wait for all pending operations to the fb before disabling the pipe

During modeset we have to disable the pipe to reconfigure its timings
and maybe its size. Userspace may have queued up command buffers that
depend upon the pipe running in a certain configuration and so the
commands may become confused across the modeset. At the moment, we use a
less than satisfactory kick-scanline-waits should the GPU hang during
the modeset. It should be more reliable to wait for the pending
operations to complete first, even though we still have a window for
userspace to submit a broken command buffer during the modeset.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 0f91128d88bbb8b0a8e7bb93df2c40680871d45a)

Signed-off-by: Timo Aaltonen <timo.aaltonen@canonical.com>
9 years agotime: Move ktime_t overflow checking into timespec_valid_strict
John Stultz [Fri, 31 Aug 2012 17:30:06 +0000 (13:30 -0400)]
time: Move ktime_t overflow checking into timespec_valid_strict

This is a -stable backport of cee58483cf56e0ba355fdd97ff5e8925329aa936

Andreas Bombe reported that the added ktime_t overflow checking added to
timespec_valid in commit 4e8b14526ca7 ("time: Improve sanity checking of
timekeeping inputs") was causing problems with X.org because it caused
timeouts larger then KTIME_T to be invalid.

Previously, these large timeouts would be clamped to KTIME_MAX and would
never expire, which is valid.

This patch splits the ktime_t overflow checking into a new
timespec_valid_strict function, and converts the timekeeping codes
internal checking to use this more strict function.

Reported-and-tested-by: Andreas Bombe <aeb@debian.org>
Cc: Zhouping Liu <zliu@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
9 years agotime: Avoid making adjustments if we haven't accumulated anything
John Stultz [Wed, 22 Aug 2012 00:30:49 +0000 (20:30 -0400)]
time: Avoid making adjustments if we haven't accumulated anything

This is a -stable backport of bf2ac312195155511a0f79325515cbb61929898a

If update_wall_time() is called and the current offset isn't large
enough to accumulate, avoid re-calling timekeeping_adjust which may
change the clock freq and can cause 1ns inconsistencies with
CLOCK_REALTIME_COARSE/CLOCK_MONOTONIC_COARSE.

Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1345595449-34965-5-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
9 years agotime: Improve sanity checking of timekeeping inputs
John Stultz [Wed, 8 Aug 2012 19:36:20 +0000 (15:36 -0400)]
time: Improve sanity checking of timekeeping inputs

This is a -stable backport of 4e8b14526ca7fb046a81c94002c1c43b6fdf0e9b

Unexpected behavior could occur if the time is set to a value large
enough to overflow a 64bit ktime_t (which is something larger then the
year 2262).

Also unexpected behavior could occur if large negative offsets are
injected via adjtimex.

So this patch improves the sanity check timekeeping inputs by
improving the timespec_valid() check, and then makes better use of
timespec_valid() to make sure we don't set the time to an invalid
negative value or one that overflows ktime_t.

Note: This does not protect from setting the time close to overflowing
ktime_t and then letting natural accumulation cause the overflow.

Reported-by: CAI Qian <caiqian@redhat.com>
Reported-by: Sasha Levin <levinsasha928@gmail.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Zhouping Liu <zliu@redhat.com>
Cc: Ingo Molnar <mingo@kernel.org>
Link: http://lkml.kernel.org/r/1344454580-17031-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Signed-off-by: John Stultz <john.stultz@linaro.org>
9 years agofixing dmi match for hp t5745 and hp st5747 thin client
Marc Gariepy [Tue, 1 May 2012 17:37:57 +0000 (13:37 -0400)]
fixing dmi match for hp t5745 and hp st5747 thin client

commit 62004978df3898649e152751eb6ac264a323ec36 upstream.

Match the correct information which is DMI_PRODUCT_NAME instead of DMI_BOARD_NAME
See dmidecode information on launchpad for both thin client:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916

Signed-off-by: Marc Gariepy <mgariepy@ubuntu.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoworkqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic
Lai Jiangshan [Sat, 1 Sep 2012 16:28:19 +0000 (00:28 +0800)]
workqueue: UNBOUND -> REBIND morphing in rebind_workers() should be atomic

commit 96e65306b81351b656835c15931d1d237b252f27 upstream.

The compiler may compile the following code into TWO write/modify
instructions.

worker->flags &= ~WORKER_UNBOUND;
worker->flags |= WORKER_REBIND;

so the other CPU may temporarily see worker->flags which doesn't have
either WORKER_UNBOUND or WORKER_REBIND set and perform local wakeup
prematurely.

Fix it by using single explicit assignment via ACCESS_ONCE().

Because idle workers have another WORKER_NOT_RUNNING flag, this bug
doesn't exist for them; however, update it to use the same pattern for
consistency.

tj: Applied the change to idle workers too and updated comments and
    patch description a bit.

stable: Idle worker rebinding doesn't apply for -stable and
        WORKER_UNBOUND used to be WORKER_ROGUE.  Updated accordingly.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
9 years agobnx2x: fix 57840_MF pci id
Yuval Mintz [Sun, 26 Aug 2012 00:35:45 +0000 (00:35 +0000)]
bnx2x: fix 57840_MF pci id

[ Upstream commit 5c879d2094946081af934739850c7260e8b25d3c ]

Commit c3def943c7117d42caaed3478731ea7c3c87190e have added support for
new pci ids of the 57840 board, while failing to change the obsolete value
in 'pci_ids.h'.
This patch does so, allowing the probe of such devices.

Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonet: ipv4: ipmr_expire_timer causes crash when removing net namespace
Francesco Ruggeri [Fri, 24 Aug 2012 07:38:35 +0000 (07:38 +0000)]
net: ipv4: ipmr_expire_timer causes crash when removing net namespace

[ Upstream commit acbb219d5f53821b2d0080d047800410c0420ea1 ]

When tearing down a net namespace, ipv4 mr_table structures are freed
without first deactivating their timers. This can result in a crash in
run_timer_softirq.
This patch mimics the corresponding behaviour in ipv6.
Locking and synchronization seem to be adequate.
We are about to kfree mrt, so existing code should already make sure that
no other references to mrt are pending or can be created by incoming traffic.
The functions invoked here do not cause new references to mrt or other
race conditions to be created.
Invoking del_timer_sync guarantees that ipmr_expire_timer is inactive.
Both ipmr_expire_process (whose completion we may have to wait in
del_timer_sync) and mroute_clean_tables internally use mfc_unres_lock
or other synchronizations when needed, and they both only modify mrt.

Tested in Linux 3.4.8.

Signed-off-by: Francesco Ruggeri <fruggeri@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agol2tp: avoid to use synchronize_rcu in tunnel free function
xeb@mail.ru [Fri, 24 Aug 2012 01:07:38 +0000 (01:07 +0000)]
l2tp: avoid to use synchronize_rcu in tunnel free function

[ Upstream commit 99469c32f79a32d8481f87be0d3c66dad286f4ec ]

Avoid to use synchronize_rcu in l2tp_tunnel_free because context may be
atomic.

Signed-off-by: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agogianfar: fix default tx vlan offload feature flag
Claudiu Manoil [Thu, 23 Aug 2012 21:46:25 +0000 (21:46 +0000)]
gianfar: fix default tx vlan offload feature flag

[ Upstream commit e2c53be223aca36cf93eb6a0f6bafa079e78f52b ]

Commit -
"b852b72 gianfar: fix bug caused by
87c288c6e9aa31720b72e2bc2d665e24e1653c3e"
disables by default (on mac init) the hw vlan tag insertion.
The "features" flags were not updated to reflect this, and
"ethtool -K" shows tx-vlan-offload to be "on" by default.

Cc: Sebastian Poehn <sebastian.poehn@belden.com>
Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonetlink: fix possible spoofing from non-root processes
Pablo Neira Ayuso [Thu, 23 Aug 2012 02:09:11 +0000 (02:09 +0000)]
netlink: fix possible spoofing from non-root processes

[ Upstream commit 20e1db19db5d6b9e4e83021595eab0dc8f107bef ]

Non-root user-space processes can send Netlink messages to other
processes that are well-known for being subscribed to Netlink
asynchronous notifications. This allows ilegitimate non-root
process to send forged messages to Netlink subscribers.

The userspace process usually verifies the legitimate origin in
two ways:

a) Socket credentials. If UID != 0, then the message comes from
   some ilegitimate process and the message needs to be dropped.

b) Netlink portID. In general, portID == 0 means that the origin
   of the messages comes from the kernel. Thus, discarding any
   message not coming from the kernel.

However, ctnetlink sets the portID in event messages that has
been triggered by some user-space process, eg. conntrack utility.
So other processes subscribed to ctnetlink events, eg. conntrackd,
know that the event was triggered by some user-space action.

Neither of the two ways to discard ilegitimate messages coming
from non-root processes can help for ctnetlink.

This patch adds capability validation in case that dst_pid is set
in netlink_sendmsg(). This approach is aggressive since existing
applications using any Netlink bus to deliver messages between
two user-space processes will break. Note that the exception is
NETLINK_USERSOCK, since it is reserved for netlink-to-netlink
userspace communication.

Still, if anyone wants that his Netlink bus allows netlink-to-netlink
userspace, then they can set NL_NONROOT_SEND. However, by default,
I don't think it makes sense to allow to use NETLINK_ROUTE to
communicate two processes that are sending no matter what information
that is not related to link/neighbouring/routing. They should be using
NETLINK_USERSOCK instead for that.

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoaf_netlink: force credentials passing [CVE-2012-3520]
Eric Dumazet [Tue, 21 Aug 2012 06:21:17 +0000 (06:21 +0000)]
af_netlink: force credentials passing [CVE-2012-3520]

[ Upstream commit e0e3cea46d31d23dc40df0a49a7a2c04fe8edfea ]

Pablo Neira Ayuso discovered that avahi and
potentially NetworkManager accept spoofed Netlink messages because of a
kernel bug.  The kernel passes all-zero SCM_CREDENTIALS ancillary data
to the receiver if the sender did not provide such data, instead of not
including any such data at all or including the correct data from the
peer (as it is the case with AF_UNIX).

This bug was introduced in commit 16e572626961
(af_unix: dont send SCM_CREDENTIALS by default)

This patch forces passing credentials for netlink, as
before the regression.

Another fix would be to not add SCM_CREDENTIALS in
netlink messages if not provided by the sender, but it
might break some programs.

With help from Florian Weimer & Petr Matousek

This issue is designated as CVE-2012-3520

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoaf_packet: don't emit packet on orig fanout group
Eric Leblond [Thu, 16 Aug 2012 22:02:58 +0000 (22:02 +0000)]
af_packet: don't emit packet on orig fanout group

[ Upstream commit c0de08d04215031d68fa13af36f347a6cfa252ca ]

If a packet is emitted on one socket in one group of fanout sockets,
it is transmitted again. It is thus read again on one of the sockets
of the fanout group. This result in a loop for software which
generate packets when receiving one.
This retransmission is not the intended behavior: a fanout group
must behave like a single socket. The packet should not be
transmitted on a socket if it originates from a socket belonging
to the same fanout group.

This patch fixes the issue by changing the transmission check to
take fanout group info account.

Reported-by: Aleksandr Kotov <a1k@mail.ru>
Signed-off-by: Eric Leblond <eric@regit.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonet: fix info leak in compat dev_ifconf()
Mathias Krause [Wed, 15 Aug 2012 11:31:57 +0000 (11:31 +0000)]
net: fix info leak in compat dev_ifconf()

[ Upstream commit 43da5f2e0d0c69ded3d51907d9552310a6b545e8 ]

The implementation of dev_ifconf() for the compat ioctl interface uses
an intermediate ifc structure allocated in userland for the duration of
the syscall. Though, it fails to initialize the padding bytes inserted
for alignment and that for leaks four bytes of kernel stack. Add an
explicit memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)
Mathias Krause [Wed, 15 Aug 2012 11:31:56 +0000 (11:31 +0000)]
ipvs: fix info leak in getsockopt(IP_VS_SO_GET_TIMEOUT)

[ Upstream commit 2d8a041b7bfe1097af21441cb77d6af95f4f4680 ]

If at least one of CONFIG_IP_VS_PROTO_TCP or CONFIG_IP_VS_PROTO_UDP is
not set, __ip_vs_get_timeouts() does not fully initialize the structure
that gets copied to userland and that for leaks up to 12 bytes of kernel
stack. Add an explicit memset(0) before passing the structure to
__ip_vs_get_timeouts() to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Wensong Zhang <wensong@linux-vs.org>
Cc: Simon Horman <horms@verge.net.au>
Cc: Julian Anastasov <ja@ssi.bg>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)
Mathias Krause [Wed, 15 Aug 2012 11:31:55 +0000 (11:31 +0000)]
dccp: fix info leak via getsockopt(DCCP_SOCKOPT_CCID_TX_INFO)

[ Upstream commit 7b07f8eb75aa3097cdfd4f6eac3da49db787381d ]

The CCID3 code fails to initialize the trailing padding bytes of struct
tfrc_tx_info added for alignment on 64 bit architectures. It that for
potentially leaks four bytes kernel stack via the getsockopt() syscall.
Add an explicit memset(0) before filling the structure to avoid the
info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agollc: fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:53 +0000 (11:31 +0000)]
llc: fix info leak via getsockname()

[ Upstream commit 3592aaeb80290bda0f2cf0b5456c97bfc638b192 ]

The LLC code wrongly returns 0, i.e. "success", when the socket is
zapped. Together with the uninitialized uaddrlen pointer argument from
sys_getsockname this leads to an arbitrary memory leak of up to 128
bytes kernel stack via the getsockname() syscall.

Return an error instead when the socket is zapped to prevent the info
leak. Also remove the unnecessary memset(0). We don't directly write to
the memory pointed by uaddr but memcpy() a local structure at the end of
the function that is properly initialized.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: L2CAP - Fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:51 +0000 (11:31 +0000)]
Bluetooth: L2CAP - Fix info leak via getsockname()

[ Upstream commit 792039c73cf176c8e39a6e8beef2c94ff46522ed ]

The L2CAP code fails to initialize the l2_bdaddr_type member of struct
sockaddr_l2 and the padding byte added for alignment. It that for leaks
two bytes kernel stack via the getsockname() syscall. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: RFCOMM - Fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:50 +0000 (11:31 +0000)]
Bluetooth: RFCOMM - Fix info leak via getsockname()

[ Upstream commit 9344a972961d1a6d2c04d9008b13617bcb6ec2ef ]

The RFCOMM code fails to initialize the trailing padding byte of struct
sockaddr_rc added for alignment. It that for leaks one byte kernel stack
via the getsockname() syscall. Add an explicit memset(0) before filling
the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)
Mathias Krause [Wed, 15 Aug 2012 11:31:49 +0000 (11:31 +0000)]
Bluetooth: RFCOMM - Fix info leak in ioctl(RFCOMMGETDEVLIST)

[ Upstream commit f9432c5ec8b1e9a09b9b0e5569e3c73db8de432a ]

The RFCOMM code fails to initialize the two padding bytes of struct
rfcomm_dev_list_req inserted for alignment before copying it to
userland. Additionally there are two padding bytes in each instance of
struct rfcomm_dev_info. The ioctl() that for disclosures two bytes plus
dev_num times two bytes uninitialized kernel heap memory.

Allocate the memory using kzalloc() to fix this issue.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)
Mathias Krause [Wed, 15 Aug 2012 11:31:48 +0000 (11:31 +0000)]
Bluetooth: RFCOMM - Fix info leak in getsockopt(BT_SECURITY)

[ Upstream commit 9ad2de43f1aee7e7274a4e0d41465489299e344b ]

The RFCOMM code fails to initialize the key_size member of struct
bt_security before copying it to userland -- that for leaking one
byte kernel stack. Initialize key_size with 0 to avoid the info
leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: HCI - Fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:47 +0000 (11:31 +0000)]
Bluetooth: HCI - Fix info leak via getsockname()

[ Upstream commit 3f68ba07b1da811bf383b4b701b129bfcb2e4988 ]

The HCI code fails to initialize the hci_channel member of struct
sockaddr_hci and that for leaks two bytes kernel stack via the
getsockname() syscall. Initialize hci_channel with 0 to avoid the
info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoBluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)
Mathias Krause [Wed, 15 Aug 2012 11:31:46 +0000 (11:31 +0000)]
Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)

[ Upstream commit e15ca9a0ef9a86f0477530b0f44a725d67f889ee ]

The HCI code fails to initialize the two padding bytes of struct
hci_ufilter before copying it to userland -- that for leaking two
bytes kernel stack. Add an explicit memset(0) before filling the
structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Cc: Marcel Holtmann <marcel@holtmann.org>
Cc: Gustavo Padovan <gustavo@padovan.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoatm: fix info leak via getsockname()
Mathias Krause [Wed, 15 Aug 2012 11:31:45 +0000 (11:31 +0000)]
atm: fix info leak via getsockname()

[ Upstream commit 3c0c5cfdcd4d69ffc4b9c0907cec99039f30a50a ]

The ATM code fails to initialize the two padding bytes of struct
sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoatm: fix info leak in getsockopt(SO_ATMPVC)
Mathias Krause [Wed, 15 Aug 2012 11:31:44 +0000 (11:31 +0000)]
atm: fix info leak in getsockopt(SO_ATMPVC)

[ Upstream commit e862f1a9b7df4e8196ebec45ac62295138aa3fc2 ]

The ATM code fails to initialize the two padding bytes of struct
sockaddr_atmpvc inserted for alignment. Add an explicit memset(0)
before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock
Ben Hutchings [Tue, 14 Aug 2012 08:54:51 +0000 (08:54 +0000)]
ipv6: addrconf: Avoid calling netdevice notifiers with RCU read-side lock

[ Upstream commit 4acd4945cd1e1f92b20d14e349c6c6a52acbd42d ]

Cong Wang reports that lockdep detected suspicious RCU usage while
enabling IPV6 forwarding:

 [ 1123.310275] ===============================
 [ 1123.442202] [ INFO: suspicious RCU usage. ]
 [ 1123.558207] 3.6.0-rc1+ #109 Not tainted
 [ 1123.665204] -------------------------------
 [ 1123.768254] include/linux/rcupdate.h:430 Illegal context switch in RCU read-side critical section!
 [ 1123.992320]
 [ 1123.992320] other info that might help us debug this:
 [ 1123.992320]
 [ 1124.307382]
 [ 1124.307382] rcu_scheduler_active = 1, debug_locks = 0
 [ 1124.522220] 2 locks held by sysctl/5710:
 [ 1124.648364]  #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81768498>] rtnl_trylock+0x15/0x17
 [ 1124.882211]  #1:  (rcu_read_lock){.+.+.+}, at: [<ffffffff81871df8>] rcu_lock_acquire+0x0/0x29
 [ 1125.085209]
 [ 1125.085209] stack backtrace:
 [ 1125.332213] Pid: 5710, comm: sysctl Not tainted 3.6.0-rc1+ #109
 [ 1125.441291] Call Trace:
 [ 1125.545281]  [<ffffffff8109d915>] lockdep_rcu_suspicious+0x109/0x112
 [ 1125.667212]  [<ffffffff8107c240>] rcu_preempt_sleep_check+0x45/0x47
 [ 1125.781838]  [<ffffffff8107c260>] __might_sleep+0x1e/0x19b
[...]
 [ 1127.445223]  [<ffffffff81757ac5>] call_netdevice_notifiers+0x4a/0x4f
[...]
 [ 1127.772188]  [<ffffffff8175e125>] dev_disable_lro+0x32/0x6b
 [ 1127.885174]  [<ffffffff81872d26>] dev_forward_change+0x30/0xcb
 [ 1128.013214]  [<ffffffff818738c4>] addrconf_forward_change+0x85/0xc5
[...]

addrconf_forward_change() uses RCU iteration over the netdev list,
which is unnecessary since it already holds the RTNL lock.  We also
cannot reasonably require netdevice notifier functions not to sleep.

Reported-by: Cong Wang <amwang@redhat.com>
Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoaf_packet: remove BUG statement in tpacket_destruct_skb
danborkmann@iogearbox.net [Fri, 10 Aug 2012 22:48:54 +0000 (22:48 +0000)]
af_packet: remove BUG statement in tpacket_destruct_skb

[ Upstream commit 7f5c3e3a80e6654cf48dfba7cf94f88c6b505467 ]

Here's a quote of the comment about the BUG macro from asm-generic/bug.h:

 Don't use BUG() or BUG_ON() unless there's really no way out; one
 example might be detecting data structure corruption in the middle
 of an operation that can't be backed out of.  If the (sub)system
 can somehow continue operating, perhaps with reduced functionality,
 it's probably not BUG-worthy.

 If you're tempted to BUG(), think again:  is completely giving up
 really the *only* solution?  There are usually better options, where
 users don't need to reboot ASAP and can mostly shut down cleanly.

In our case, the status flag of a ring buffer slot is managed from both sides,
the kernel space and the user space. This means that even though the kernel
side might work as expected, the user space screws up and changes this flag
right between the send(2) is triggered when the flag is changed to
TP_STATUS_SENDING and a given skb is destructed after some time. Then, this
will hit the BUG macro. As David suggested, the best solution is to simply
remove this statement since it cannot be used for kernel side internal
consistency checks. I've tested it and the system still behaves /stable/ in
this case, so in accordance with the above comment, we should rather remove it.

Signed-off-by: Daniel Borkmann <daniel.borkmann@tik.ee.ethz.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonet/core: Fix potential memory leak in dev_set_alias()
Alexey Khoroshilov [Wed, 8 Aug 2012 00:33:25 +0000 (00:33 +0000)]
net/core: Fix potential memory leak in dev_set_alias()

[ Upstream commit 7364e445f62825758fa61195d237a5b8ecdd06ec ]

Do not leak memory by updating pointer with potentially NULL realloc return value.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopptp: lookup route with the proper net namespace
Gao feng [Tue, 7 Aug 2012 00:23:11 +0000 (00:23 +0000)]
pptp: lookup route with the proper net namespace

[ Upstream commit 08252b32311c3fa84219ad794d640af7399b5485 ]

pptp always use init_net as the net namespace to lookup
route, this will cause route lookup failed in container.

because we already set the correct net namespace to struct
sock in pptp_create,so fix this by using sock_net(sk) to
replace &init_net.

Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoisdnloop: fix and simplify isdnloop_init()
Wu Fengguang [Thu, 2 Aug 2012 23:10:01 +0000 (23:10 +0000)]
isdnloop: fix and simplify isdnloop_init()

[ Upstream commit 77f00f6324cb97cf1df6f9c4aaeea6ada23abdb2 ]

Fix a buffer overflow bug by removing the revision and printk.

[   22.016214] isdnloop-ISDN-driver Rev 1.11.6.7
[   22.097508] isdnloop: (loop0) virtual card added
[   22.174400] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff83244972
[   22.174400]
[   22.436157] Pid: 1, comm: swapper Not tainted 3.5.0-bisect-00018-gfa8bbb1-dirty #129
[   22.624071] Call Trace:
[   22.720558]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[   22.815248]  [<ffffffff8222b623>] panic+0x110/0x329
[   22.914330]  [<ffffffff83244972>] ? isdnloop_init+0xaf/0xb1
[   23.014800]  [<ffffffff832448c3>] ? CallcNew+0x56/0x56
[   23.090763]  [<ffffffff8108e24b>] __stack_chk_fail+0x2b/0x30
[   23.185748]  [<ffffffff83244972>] isdnloop_init+0xaf/0xb1

Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonet_sched: gact: Fix potential panic in tcf_gact().
Hiroaki SHIMODA [Fri, 3 Aug 2012 10:57:52 +0000 (19:57 +0900)]
net_sched: gact: Fix potential panic in tcf_gact().

[ Upstream commit 696ecdc10622d86541f2e35cc16e15b6b3b1b67e ]

gact_rand array is accessed by gact->tcfg_ptype whose value
is assumed to less than MAX_RAND, but any range checks are
not performed.

So add a check in tcf_gact_init(). And in tcf_gact(), we can
reduce a branch.

Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agotcp: Apply device TSO segment limit earlier
Ben Hutchings [Mon, 30 Jul 2012 16:11:42 +0000 (16:11 +0000)]
tcp: Apply device TSO segment limit earlier

[ Upstream commit 1485348d2424e1131ea42efc033cbd9366462b01 ]

Cache the device gso_max_segs in sock::sk_gso_max_segs and use it to
limit the size of TSO skbs.  This avoids the need to fall back to
software GSO for local TCP senders.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agosfc: Fix maximum number of TSO segments and minimum TX queue size
Ben Hutchings [Mon, 30 Jul 2012 15:57:44 +0000 (15:57 +0000)]
sfc: Fix maximum number of TSO segments and minimum TX queue size

[ Upstream commit 7e6d06f0de3f74ca929441add094518ae332257c ]

Currently an skb requiring TSO may not fit within a minimum-size TX
queue.  The TX queue selected for the skb may stall and trigger the TX
watchdog repeatedly (since the problem skb will be retried after the
TX reset).  This issue is designated as CVE-2012-3412.

Set the maximum number of TSO segments for our devices to 100.  This
should make no difference to behaviour unless the actual MSS is less
than about 700.  Increase the minimum TX queue size accordingly to
allow for 2 worst-case skbs, so that there will definitely be space
to add an skb after we wake a queue.

To avoid invalidating existing configurations, change
efx_ethtool_set_ringparam() to fix up values that are too small rather
than returning -EINVAL.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agonet: Allow driver to limit number of GSO segments per skb
Ben Hutchings [Mon, 30 Jul 2012 15:57:00 +0000 (15:57 +0000)]
net: Allow driver to limit number of GSO segments per skb

[ Upstream commit 30b678d844af3305cda5953467005cebb5d7b687 ]

A peer (or local user) may cause TCP to use a nominal MSS of as little
as 88 (actual MSS of 76 with timestamps).  Given that we have a
sufficiently prodigious local sender and the peer ACKs quickly enough,
it is nevertheless possible to grow the window for such a connection
to the point that we will try to send just under 64K at once.  This
results in a single skb that expands to 861 segments.

In some drivers with TSO support, such an skb will require hundreds of
DMA descriptors; a substantial fraction of a TX ring or even more than
a full ring.  The TX queue selected for the skb may stall and trigger
the TX watchdog repeatedly (since the problem skb will be retried
after the TX reset).  This particularly affects sfc, for which the
issue is designated as CVE-2012-3412.

Therefore:
1. Add the field net_device::gso_max_segs holding the device-specific
   limit.
2. In netif_skb_features(), if the number of segments is too high then
   mask out GSO features to force fall back to software GSO.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoi2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DES...
Axel Lin [Mon, 10 Sep 2012 08:14:02 +0000 (10:14 +0200)]
i2c-designware: Fix build error if CONFIG_I2C_DESIGNWARE_PLATFORM=y && CONFIG_I2C_DESIGNWARE_PCI=y

commit e68bb91baa0bb9817567bd45d560919e8e26373b upstream.

This patch adds config I2C_DESIGNWARE_CORE in Kconfig, and let
I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI select I2C_DESIGNWARE_CORE.

Because both I2C_DESIGNWARE_PLATFORM and I2C_DESIGNWARE_PCI can be built as
built-in or module, we also need to export the functions in i2c-designware-core.

This fixes below build error when CONFIG_I2C_DESIGNWARE_PLATFORM=y &&
CONFIG_I2C_DESIGNWARE_PCI=y:

  LD      drivers/i2c/busses/built-in.o
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_clear_int':
i2c-designware-core.c:(.text+0xa10): multiple definition of `i2c_dw_clear_int'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x928): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_init':
i2c-designware-core.c:(.text+0x178): multiple definition of `i2c_dw_init'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x90): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `dw_readl':
i2c-designware-core.c:(.text+0xe8): multiple definition of `dw_readl'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x0): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_isr':
i2c-designware-core.c:(.text+0x724): multiple definition of `i2c_dw_isr'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x63c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer':
i2c-designware-core.c:(.text+0x4b0): multiple definition of `i2c_dw_xfer'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c8): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_is_enabled':
i2c-designware-core.c:(.text+0x9d4): multiple definition of `i2c_dw_is_enabled'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8ec): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `dw_writel':
i2c-designware-core.c:(.text+0x124): multiple definition of `dw_writel'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x3c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_xfer_msg':
i2c-designware-core.c:(.text+0x2e8): multiple definition of `i2c_dw_xfer_msg'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x200): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_enable':
i2c-designware-core.c:(.text+0x9c8): multiple definition of `i2c_dw_enable'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8e0): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_read_comp_param':
i2c-designware-core.c:(.text+0xa24): multiple definition of `i2c_dw_read_comp_param'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x93c): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable':
i2c-designware-core.c:(.text+0x9dc): multiple definition of `i2c_dw_disable'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x8f4): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_func':
i2c-designware-core.c:(.text+0x710): multiple definition of `i2c_dw_func'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x628): first defined here
drivers/i2c/busses/i2c-designware-pci.o: In function `i2c_dw_disable_int':
i2c-designware-core.c:(.text+0xa18): multiple definition of `i2c_dw_disable_int'
drivers/i2c/busses/i2c-designware-platform.o:i2c-designware-platdrv.c:(.text+0x930): first defined here
make[3]: *** [drivers/i2c/busses/built-in.o] Error 1
make[2]: *** [drivers/i2c/busses] Error 2
make[1]: *** [drivers/i2c] Error 2
make: *** [drivers] Error 2

Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Tested-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agodrm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot
Dave Airlie [Wed, 29 Aug 2012 01:40:51 +0000 (21:40 -0400)]
drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot

commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.

This will cause udev to load vmwgfx instead of waiting for X
to do it.

Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoCIFS: Fix error handling in cifs_push_mandatory_locks
Pavel Shilovsky [Wed, 29 Aug 2012 17:13:38 +0000 (21:13 +0400)]
CIFS: Fix error handling in cifs_push_mandatory_locks

commit e2f2886a824ff0a56da1eaa13019fde86aa89fa6 upstream.

Signed-off-by: Pavel Shilovsky <pshilovsky@etersoft.ru>
Signed-off-by: Steve French <smfrench@gmail.com>
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoRemove user-triggerable BUG from mpol_to_str
Dave Jones [Thu, 6 Sep 2012 16:01:00 +0000 (12:01 -0400)]
Remove user-triggerable BUG from mpol_to_str

commit 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a upstream.

Trivially triggerable, found by trinity:

  kernel BUG at mm/mempolicy.c:2546!
  Process trinity-child2 (pid: 23988, threadinfo ffff88010197e000, task ffff88007821a670)
  Call Trace:
    show_numa_map+0xd5/0x450
    show_pid_numa_map+0x13/0x20
    traverse+0xf2/0x230
    seq_read+0x34b/0x3e0
    vfs_read+0xac/0x180
    sys_pread64+0xa2/0xc0
    system_call_fastpath+0x1a/0x1f
  RIP: mpol_to_str+0x156/0x360

Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoxen: Use correct masking in xen_swiotlb_alloc_coherent.
Ronny Hegewald [Fri, 31 Aug 2012 09:57:52 +0000 (09:57 +0000)]
xen: Use correct masking in xen_swiotlb_alloc_coherent.

commit b5031ed1be0aa419250557123633453753181643 upstream.

When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.

The underlaying reason is that if the supplied driver passes in a
DMA_BIT_MASK(64) ( hwdev->coherent_dma_mask is set to 0xffffffffffffffff)
our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
By using the dma_alloc_coherent_mask function - it does the proper casting
and we get 0xfffffffff.

This caused not working sound on a system with 4 GB and a 64-bit
compatible sound-card with sets the DMA-mask to 64bit.

On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
DMA-memory is always allocated inside the 32-bit address-range by calling
dma_alloc_coherent_mask.

This patch adds the same functionality to xen swiotlb and is a rebase of the
original patch from Ronny Hegewald which never got upstream b/c the
underlaying reason was not understood until now.

The original email with the original patch is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html
the original thread from where the discussion started is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html

Signed-off-by: Ronny Hegewald <ronny.hegewald@online.de>
Signed-off-by: Stefano Panella <stefano.panella@citrix.com>
Acked-By: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agoudf: Fix data corruption for files in ICB
Jan Kara [Wed, 5 Sep 2012 13:48:23 +0000 (15:48 +0200)]
udf: Fix data corruption for files in ICB

commit 9c2fc0de1a6e638fe58c354a463f544f42a90a09 upstream.

When a file is stored in ICB (inode), we overwrite part of the file, and
the page containing file's data is not in page cache, we end up corrupting
file's data by overwriting them with zeros. The problem is we use
simple_write_begin() which simply zeroes parts of the page which are not
written to. The problem has been introduced by be021ee4 (udf: convert to
new aops).

Fix the problem by providing a ->write_begin function which makes the page
properly uptodate.

Reported-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopowerpc: Make sure IPI handlers see data written by IPI senders
Paul Mackerras [Tue, 4 Sep 2012 18:33:08 +0000 (18:33 +0000)]
powerpc: Make sure IPI handlers see data written by IPI senders

commit 9fb1b36ca1234e64a5d1cc573175303395e3354d upstream.

We have been observing hangs, both of KVM guest vcpu tasks and more
generally, where a process that is woken doesn't properly wake up and
continue to run, but instead sticks in TASK_WAKING state.  This
happens because the update of rq->wake_list in ttwu_queue_remote()
is not ordered with the update of ipi_message in
smp_muxed_ipi_message_pass(), and the reading of rq->wake_list in
scheduler_ipi() is not ordered with the reading of ipi_message in
smp_ipi_demux().  Thus it is possible for the IPI receiver not to see
the updated rq->wake_list and therefore conclude that there is nothing
for it to do.

In order to make sure that anything done before smp_send_reschedule()
is ordered before anything done in the resulting call to scheduler_ipi(),
this adds barriers in smp_muxed_message_pass() and smp_ipi_demux().
The barrier in smp_muxed_message_pass() is a full barrier to ensure that
there is a full ordering between the smp_send_reschedule() caller and
scheduler_ipi().  In smp_ipi_demux(), we use xchg() rather than
xchg_local() because xchg() includes release and acquire barriers.
Using xchg() rather than xchg_local() makes sense given that
ipi_message is not just accessed locally.

This moves the barrier between setting the message and calling the
cause_ipi() function into the individual cause_ipi implementations.
Most of them -- those that used outb, out_8 or similar -- already had
a full barrier because out_8 etc. include a sync before the MMIO
store.  This adds an explicit barrier in the two remaining cases.

These changes made no measurable difference to the speed of IPIs as
measured using a simple ping-pong latency test across two CPUs on
different cores of a POWER7 machine.

The analysis of the reason why processes were not waking up properly
is due to Milton Miller.

Reported-by: Milton Miller <miltonm@bga.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopowerpc/xics: Harden xics hypervisor backend
Anton Blanchard [Thu, 24 Nov 2011 19:39:36 +0000 (19:39 +0000)]
powerpc/xics: Harden xics hypervisor backend

commit 3ce21cdfe93efffa4ffba9cf3ca2576d3d60d6dc upstream.

During kdump stress testing I sometimes see the kdump kernel panic
with:

  Interrupt 0x306 (real) is invalid, disabling it.
  Kernel panic - not syncing: bad return code EOI - rc = -4, value=ff000306

Instead of panicing print the error message, dump the stack the first
time it happens and continue on. Add some more information to the
debug messages as well.

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopowerpc: Restore correct DSCR in context switch
Anton Blanchard [Mon, 3 Sep 2012 16:51:10 +0000 (16:51 +0000)]
powerpc: Restore correct DSCR in context switch

commit 714332858bfd40dcf8f741498336d93875c23aa7 upstream.

During a context switch we always restore the per thread DSCR value.
If we aren't doing explicit DSCR management
(ie thread.dscr_inherit == 0) and the default DSCR changed while
the process has been sleeping we end up with the wrong value.

Check thread.dscr_inherit and select the default DSCR or per thread
DSCR as required.

This was found with the following test case, when running with
more threads than CPUs (ie forcing context switching):

http://ozlabs.org/~anton/junkcode/dscr_default_test.c

With the four patches applied I can run a combination of all
test cases successfully at the same time:

http://ozlabs.org/~anton/junkcode/dscr_default_test.c
http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopowerpc: Fix DSCR inheritance in copy_thread()
Anton Blanchard [Mon, 3 Sep 2012 16:49:47 +0000 (16:49 +0000)]
powerpc: Fix DSCR inheritance in copy_thread()

commit 1021cb268b3025573c4811f1dee4a11260c4507b upstream.

If the default DSCR is non zero we set thread.dscr_inherit in
copy_thread() meaning the new thread and all its children will ignore
future updates to the default DSCR. This is not intended and is
a change in behaviour that a number of our users have hit.

We just need to inherit thread.dscr and thread.dscr_inherit from
the parent which ends up being much simpler.

This was found with the following test case:

http://ozlabs.org/~anton/junkcode/dscr_default_test.c

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
9 years agopowerpc: Keep thread.dscr and thread.dscr_inherit in sync
Anton Blanchard [Mon, 3 Sep 2012 16:48:46 +0000 (16:48 +0000)]
powerpc: Keep thread.dscr and thread.dscr_inherit in sync

commit 00ca0de02f80924dfff6b4f630e1dff3db005e35 upstream.

When we update the DSCR either via emulation of mtspr(DSCR) or via
a change to dscr_default in sysfs we don't update thread.dscr.
We will eventually update it at context switch time but there is
a period where thread.dscr is incorrect.

If we fork at this point we will copy the old value of thread.dscr
into the child. To avoid this, always keep thread.dscr in sync with
reality.

This issue was found with the following testcase:

http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c

Signed-off-by: Anton Blanchard <anton@samba.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>