]> git.karo-electronics.de Git - linux-beck.git/log
linux-beck.git
10 years agoReturn correct error on query of xattr on file with empty xattrs
Steve French [Wed, 26 Mar 2014 00:46:36 +0000 (19:46 -0500)]
Return correct error on query of xattr on file with empty xattrs

xfstest 020 detected a problem with cifs xattr handling.  When a file
had an empty xattr list, we returned success (with an empty xattr value)
on query of particular xattrs rather than returning ENODATA.
This patch fixes it so that query of an xattr returns ENODATA when the
xattr list is empty for the file.

Signed-off-by: Steve French <smfrench@gmail.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
10 years agocifs: Wait for writebacks to complete before attempting write.
Sachin Prabhu [Tue, 11 Mar 2014 16:11:47 +0000 (16:11 +0000)]
cifs: Wait for writebacks to complete before attempting write.

Problem reported in Red Hat bz 1040329 for strict writes where we cache
only when we hold oplock and write direct to the server when we don't.

When we receive an oplock break, we first change the oplock value for
the inode in cifsInodeInfo->oplock to indicate that we no longer hold
the oplock before we enqueue a task to flush changes to the backing
device. Once we have completed flushing the changes, we return the
oplock to the server.

There are 2 ways here where we can have data corruption
1) While we flush changes to the backing device as part of the oplock
break, we can have processes write to the file. These writes check for
the oplock, find none and attempt to write directly to the server.
These direct writes made while we are flushing from cache could be
overwritten by data being flushed from the cache causing data
corruption.
2) While a thread runs in cifs_strict_writev, the machine could receive
and process an oplock break after the thread has checked the oplock and
found that it allows us to cache and before we have made changes to the
cache. In that case, we end up with a dirty page in cache when we
shouldn't have any. This will be flushed later and will overwrite all
subsequent writes to the part of the file represented by this page.

Before making any writes to the server, we need to confirm that we are
not in the process of flushing data to the server and if we are, we
should wait until the process is complete before we attempt the write.
We should also wait for existing writes to complete before we process
an oplock break request which changes oplock values.

We add a version specific  downgrade_oplock() operation to allow for
differences in the oplock values set for the different smb versions.

Cc: stable@vger.kernel.org
Signed-off-by: Sachin Prabhu <sprabhu@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Pavel Shilovsky <piastry@etersoft.ru>
Signed-off-by: Steve French <smfrench@gmail.com>
10 years agostaging: r8188eu: Calling rtw_get_stainfo() with a NULL sta_addr will return NULL
Larry Finger [Wed, 9 Apr 2014 16:12:58 +0000 (11:12 -0500)]
staging: r8188eu: Calling rtw_get_stainfo() with a NULL sta_addr will return NULL

This makes the follow-on check for psta != NULL pointless and makes
the whole exercise rather pointless. This is another case of why
blindly zero-initializing variables when they are declared is bad.

Reported-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: comedi: fix circular locking dependency in comedi_mmap()
Ian Abbott [Thu, 10 Apr 2014 18:41:57 +0000 (19:41 +0100)]
staging: comedi: fix circular locking dependency in comedi_mmap()

Mmapping a comedi data buffer with lockdep checking enabled produced the
following kernel debug messages:

======================================================
[ INFO: possible circular locking dependency detected ]
3.5.0-rc3-ija1+ #9 Tainted: G         C
-------------------------------------------------------
comedi_test/4160 is trying to acquire lock:
 (&dev->mutex#2){+.+.+.}, at: [<ffffffffa00313f4>] comedi_mmap+0x57/0x1d9 [comedi]

but task is already holding lock:
 (&mm->mmap_sem){++++++}, at: [<ffffffff810c96fe>] vm_mmap_pgoff+0x41/0x76

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (&mm->mmap_sem){++++++}:
       [<ffffffff8106d0e8>] lock_acquire+0x97/0x105
       [<ffffffff810ce3bc>] might_fault+0x6d/0x90
       [<ffffffffa0031ffb>] do_devinfo_ioctl.isra.7+0x11e/0x14c [comedi]
       [<ffffffffa003227f>] comedi_unlocked_ioctl+0x256/0xe48 [comedi]
       [<ffffffff810f7fcd>] vfs_ioctl+0x18/0x34
       [<ffffffff810f87fd>] do_vfs_ioctl+0x382/0x43c
       [<ffffffff810f88f9>] sys_ioctl+0x42/0x65
       [<ffffffff81415c62>] system_call_fastpath+0x16/0x1b

-> #0 (&dev->mutex#2){+.+.+.}:
       [<ffffffff8106c528>] __lock_acquire+0x101d/0x1591
       [<ffffffff8106d0e8>] lock_acquire+0x97/0x105
       [<ffffffff8140c894>] mutex_lock_nested+0x46/0x2a4
       [<ffffffffa00313f4>] comedi_mmap+0x57/0x1d9 [comedi]
       [<ffffffff810d5816>] mmap_region+0x281/0x492
       [<ffffffff810d5c92>] do_mmap_pgoff+0x26b/0x2a7
       [<ffffffff810c971a>] vm_mmap_pgoff+0x5d/0x76
       [<ffffffff810d493f>] sys_mmap_pgoff+0xc7/0x10d
       [<ffffffff81004d36>] sys_mmap+0x16/0x20
       [<ffffffff81415c62>] system_call_fastpath+0x16/0x1b

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(&mm->mmap_sem);
                               lock(&dev->mutex#2);
                               lock(&mm->mmap_sem);
  lock(&dev->mutex#2);

 *** DEADLOCK ***

To avoid the circular dependency, just try to get the lock in
`comedi_mmap()` instead of blocking.  Since the comedi device's main mutex
is heavily used, do a down-read of its `attach_lock` rwsemaphore
instead.  Trying to down-read `attach_lock` should only fail if
some task has down-write locked it, and that is only done while the
comedi device is being attached to or detached from a low-level hardware
device.

Unfortunately, acquiring the `attach_lock` doesn't prevent another
task replacing the comedi data buffer we are trying to mmap.  The
details of the buffer are held in a `struct comedi_buf_map` and pointed
to by `s->async->buf_map` where `s` is the comedi subdevice whose buffer
we are trying to map.  The `struct comedi_buf_map` is already reference
counted with a `struct kref`, so we can stop it being freed prematurely.

Modify `comedi_mmap()` to call new function
`comedi_buf_map_from_subdev_get()` to read the subdevice's current
buffer map pointer and increment its reference instead of accessing
`async->buf_map` directly.  Call `comedi_buf_map_put()` to decrement the
reference once the buffer map structure has been dealt with.  (Note that
`comedi_buf_map_put()` does nothing if passed a NULL pointer.)

`comedi_buf_map_from_subdev_get()` checks the subdevice's buffer map
pointer has been set and the buffer map has been initialized enough for
`comedi_mmap()` to deal with it (specifically, check the `n_pages`
member has been set to a non-zero value).  If all is well, the buffer
map's reference is incremented and a pointer to it is returned.  The
comedi subdevice's spin-lock is used to protect the checks.  Also use
the spin-lock in `__comedi_buf_alloc()` and `__comedi_buf_free()` to
protect changes to the subdevice's buffer map structure pointer and the
buffer map structure's `n_pages` member.  (This checking of `n_pages` is
a bit clunky and I [Ian Abbott] plan to deal with it in the future.)

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: <stable@vger.kernel.org> # 3.14.x, 3.15.x
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: r8723au: Add missing initialization of change_inx in sort algorithm
Geert Uytterhoeven [Thu, 10 Apr 2014 17:46:56 +0000 (19:46 +0200)]
staging: r8723au: Add missing initialization of change_inx in sort algorithm

drivers/staging/rtl8723au/core/rtw_wlan_util.c: In function ‘WMMOnAssocRsp23a’:
drivers/staging/rtl8723au/core/rtw_wlan_util.c:684: warning: ‘change_inx’ may be used uninitialized in this function

Depending on the uninitialized data on the stack, the array may not be
sorted correctly.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agoStaging: unisys: use after free in list_for_each()
Dan Carpenter [Thu, 10 Apr 2014 09:45:45 +0000 (12:45 +0300)]
Staging: unisys: use after free in list_for_each()

These should be using the _safe version of list_for_each() because we
free the current element and it leads to a use after free bug.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: unisys: use after free in error messages
Dan Carpenter [Thu, 10 Apr 2014 09:36:13 +0000 (12:36 +0300)]
staging: unisys: use after free in error messages

We dereference "bus" when we report the error so we have to move the
kfree() down a couple lines.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: speakup: fix misuse of kstrtol() in handle_goto()
Daeseok Youn [Wed, 9 Apr 2014 10:45:46 +0000 (19:45 +0900)]
staging: speakup: fix misuse of kstrtol() in handle_goto()

A string of goto_buf has a number followed by x or y.
e.g. "3x" means move 3 lines down.
The kstrtol() returns an error(-EINVAL) with this string so
go_pos has unsigned a value of that error.
And also "*cp" has not expected value.

And fix sparse warnings:
 drivers/staging/speakup/main.c:1901 handle_goto() warn: unsigned '(speakup_console[vc->vc_num]->go_pos)' is never less than zero.
 drivers/staging/speakup/main.c:1911 handle_goto() warn: unsigned '(speakup_console[vc->vc_num]->go_pos)' is never less than zero.

Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: goldfish: Call free_irq in error path
Tuomas Tynkkynen [Tue, 8 Apr 2014 06:15:22 +0000 (09:15 +0300)]
staging: goldfish: Call free_irq in error path

If misc_register failed in goldfish_audio_probe, the already requested
IRQ wouldn't get freed. Add a call to free_irq() like there is in
goldfish_audio_remove().

Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Acked-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agoMerge branch 'mvneta_qsgmii'
David S. Miller [Wed, 16 Apr 2014 18:37:13 +0000 (14:37 -0400)]
Merge branch 'mvneta_qsgmii'

Thomas Petazzoni says:

====================
net: mvneta: fix usage as a module, and support QSGMII properly

This set of patches is a new attempt at fixing the operation of the
mvneta driver when built as a module. For the record, the previous
attempt, merged in commit e3a8786c10e75903f1269474e21fe8cb49c3a670
('net: mvneta: fix usage as a module on RGMII configurations') caused
problems for all RGMII configurations.

In fact, it turned out that the MAC to PHY connection on the Armada XP
GP, which was described as using RGMII-ID according to its Device
Tree, is in fact a QSGMII connection. And the RGMII and QSGMII
configurations have to be handled in a different way in the driver,
because the SERDES configuration is different in those two cases.

So, this patch series fixes that by:

 * Adding minimal handling of a "qsgmii" connection type in the PHY
   layer. Mainly to make sure that a "qsgmii" phy-mode in the Device
   Tree is recognized, and handed over to the driver as
   PHY_INTERFACE_QSGMII.

 * Changing the mvneta driver to properly configure the RGMIIEn and
   PCSEn bits in the GMAC_CTRL_2 register, and configure the SERDES
   register, in the three possible cases: RGMII, SGMII and QSGMII.

 * Updating the Device Tree of the Armada XP GP board to reflect the
   fact that it uses a QSGMII MAC/PHY connection.

PATCH 1 and 2 would be merged by David Miller, through the net tree,
while PATCH 3 would be merged by the mach-mvebu maintainers, through
their tree and arm-soc.

This set of patches has been tested on:

 * Armada XP GP (four QSGMII interfaces)
 * Armada XP DB (two RGMII interfaces and two SGMII interfaces)
 * Armada 370 Mirabox (two RGMII interfaces)

I've tested both the driver built-in, and compiled as a module.

Since the last attempt at fixing this was quite a fiasco, I'd like
this new attempt to be tested more widely before being applied. I'll
try to do some testing on other Armada boards I have, but independent
testing from other persons would also be appreciated.

Note that these patches apply after reverting the previous attempt,
obviously.
====================

Tested-by: Arnaud Ebalard <arno@natisbad.org>
Tested-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agonet: mvneta: properly configure the MAC <-> PHY connection in all situations
Thomas Petazzoni [Tue, 15 Apr 2014 13:50:20 +0000 (15:50 +0200)]
net: mvneta: properly configure the MAC <-> PHY connection in all situations

Commit 5445eaf309ff ('mvneta: Try to fix mvneta when compiled as
module') fixed the mvneta driver to make it work properly when loaded
as a module in SGMII configuration, which was tested successful by the
author on the Armada XP OpenBlocks AX3, which uses SGMII.

However, some other platforms, namely the Armada XP GP don't use
SGMII, but a QSGMII connection between the MAC and the PHY, and this
case was not supported by the mvneta driver, which was relying on
configuration put in place by the bootloader. While this works when
the mvneta driver is built-in (because clocks are not gated), it
breaks when mvneta is built as a module, because the clock is gated
(all configuration is lost) and then re-enabled when the mvneta driver
is loaded.

In order to support all of RGMII, SGMII and QSGMII, this commit
reworks how the PHY interface configuration is done, and simplifies
it: it removes the mvneta_port_sgmii_config() and
mvneta_gmac_rgmii_set() functions, which were strange because
mvneta_gmac_rgmii_set() was called in all cases, even for SGMII
configurations. Also, the mvneta_gmac_rgmii_set() function was taking
a boolean as argument, which was always true.

Instead, all the PHY interface configuration logic is moved into the
mvneta_port_power_up() function, in a much simpler 'switch' construct,
with four cases:

 - QSGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured in QSGMII. Technically speaking,
   configuring the SERDES of the first port would be sufficient, but
   it is simpler to do it on all ports.

 - SGMII: the RGMIIEn bit, the PCSEn bit in GMAC_CTRL_2 are set, and
   the SERDES is configured as SGMII.

 - RGMII: the RGMIIEn bit in GMAC_CTRL_2 is set. The PCSEn bit is kept
   cleared, and no SERDES configuration is done, because RGMII is not
   using SERDES lanes.

 - other: an error is returned. For this reason, the
   mvneta_port_power_up() now returns an int instead of nothing, and
   the return value is checked by mvneta_probe().

This has been successfully tested on:

 * Armada XP DB, which has two RGMII and two SGMII connections
 * Armada XP GP, which uses QSGMII for its four interfaces
 * Armada 370 Mirabox, which has two RGMII connections

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agonet: phy: add minimal support for QSGMII PHY
Thomas Petazzoni [Tue, 15 Apr 2014 13:50:19 +0000 (15:50 +0200)]
net: phy: add minimal support for QSGMII PHY

This commit adds the necessary definitions for the PHY layer to
recognize "qsgmii" as a valid PHY interface. A QSMII interface, as
defined at
http://en.wikipedia.org/wiki/Media_Independent_Interface#Quad_Serial_Gigabit_Media_Independent_Interface,
is "is a method of combining four SGMII lines into a 5Gbit/s
interface. QSGMII, like SGMII, uses LVDS signalling for the TX and RX
data and a single LVDS clock signal. QSGMII uses significantly fewer
signal lines than four SGMII busses."

This type of MAC <-> PHY connection might require special handling on
the MAC driver side, so it should be possible to express this type of
MAC <-> PHY connection, for example in the Device Tree.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: devicetree@vger.kernel.org
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agostaging: delete rtl8187se wireless driver
Greg Kroah-Hartman [Wed, 16 Apr 2014 18:35:54 +0000 (11:35 -0700)]
staging: delete rtl8187se wireless driver

There is a "real" driver for this hardware now in drivers/net/ so remove
the staging version as it's not needed anymore.

Reported-by: Xose Vazquez Perez <xose.vazquez@gmail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: John W. Linville" <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agosfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)
Edward Cree [Wed, 16 Apr 2014 18:27:48 +0000 (19:27 +0100)]
sfc:On MCDI timeout, issue an FLR (and mark MCDI to fail-fast)

When an MCDI command times out (whether or not we find it
completed when we poll), call efx_mcdi_abandon(), which tells
all subsequent MCDI calls to fail-fast, and queues up an FLR.

Because an FLR doesn't lead to receiving any reboot even from
the MC (unlike most other types of reset), we have to call
efx_ef10_reset_mc_allocations.
In efx_start_all(), if a reset (of any kind) is pending, we
bail out.
Without this, attempts to reconfigure (e.g. change mtu) can
cause driver/mc state inconsistency if the first MCDI call
triggers an FLR.

For similar reasons, on EF10, in
efx_reset_down(method=RESET_TYPE_MCDI_TIMEOUT), set the number
of active queues to zero before calling efx_stop_all().
And, on farch, in efx_reset_up(method=RESET_TYPE_MCDI_TIMEOUT),
set active_queues and flushes pending & outstanding to zero.

efx_mcdi_mode_{poll,event}() should not take us out of fail-fast
 mode. Instead, this is done by efx_mcdi_reset() after the FLR
completes.

The new FLR reset_type RESET_TYPE_MCDI_TIMEOUT doesn't really
fit into the hierarchy of reset 'scopes' whereby efx_reset()
decides some resets subsume others.  Thus, it uses separate logic.

Also, fixed up some inconsistency around RESET_TYPE_MC_BIST,
which was in the wrong place in that hierarchy.

Signed-off-by: Shradha Shah <sshah@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoMerge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux
Linus Torvalds [Wed, 16 Apr 2014 18:28:25 +0000 (11:28 -0700)]
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull s390 patches from Martin Schwidefsky:
 "An update to the oops output with additional information about the
  crash.  The renameat2 system call is enabled.  Two patches in regard
  to the PTR_ERR_OR_ZERO cleanup.  And a bunch of bug fixes"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/sclp_cmd: replace PTR_RET with PTR_ERR_OR_ZERO
  s390/sclp: replace PTR_RET with PTR_ERR_OR_ZERO
  s390/sclp_vt220: Fix kernel panic due to early terminal input
  s390/compat: fix typo
  s390/uaccess: fix possible register corruption in strnlen_user_srst()
  s390: add 31 bit warning message
  s390: wire up sys_renameat2
  s390: show_registers() should not map user space addresses to kernel symbols
  s390/mm: print control registers and page table walk on crash
  s390/smp: fix smp_stop_cpu() for !CONFIG_SMP
  s390: fix control register update

10 years agoMerge tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel...
Linus Torvalds [Wed, 16 Apr 2014 18:22:45 +0000 (11:22 -0700)]
Merge tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux

Pull itanium erratum fix from Tony Luck:
 "Small workaround for a rare, but annoying, erratum #237"

* tag 'please-pull-ia64-erratum' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
  [IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)

10 years ago[IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)
Tony Luck [Fri, 28 Mar 2014 21:42:07 +0000 (14:42 -0700)]
[IA64] Change default PSR.ac from '1' to '0' (Fix erratum #237)

April 2014 Itanium processor specification update:

http://www.intel.com/content/www/us/en/processors/itanium/itanium-specification-update.html

describes this erratum:

=========================================================================
237. Under a complex set of conditions, store to load forwarding for a
sub 8-byte load may complete incorrectly

Problem: A load instruction may complete incorrectly when a code sequence
using 4-byte or smaller load and store operations to the same address
is executed in combination with specific timing of all the following
concurrent conditions: store to load forwarding, alignment checking
enabled, a mis-predicted branch, and complex cache utilization activity.

Implication: The affected sub 8-byte instruction may complete
incorrectly resulting in unpredictable system behavior. There is an
extremely low probability of exposure due to the significant number of
complex microarchitectural concurrent conditions required to encounter
the erratum.

Workaround: Set PSR.ac = 0 to completely avoid the erratum. Disabling
Hyper-Threading will significantly reduce exposure to the conditions
that contribute to encountering the erratum.

Status: See the Summary Table of Changes for the affected steppings.
=========================================================================

[Table of changes essentially lists all models from McKinley to Tukwila]

The PSR.ac bit controls whether the processor will always generate
an unaligned reference trap (0x5a00) for a misaligned data access
(when PSR.ac=1) or if it will let the access succeed when running
on a cpu that implements logic to handle some unaligned accesses.

Way back in 2008 in commit b704882e70d87d7f56db5ff17e2253f3fa90e4f3
  [IA64] Rationalize kernel mode alignment checking
we made the decision to always enable strict checking. We were
already doing so in trap/interrupt context because the common
preamble code set this bit - but the rest of supervisor code
(and by inheritance user code) ran with PSR.ac=0.

We now reverse that decision and set PSR.ac=0 everywhere in the
kernel (also inherited by user processes). This will avoid the
erratum using the method described in the Itanium specification
update.  Net effect for users is that the processor will handle
unaligned access when it can (typically with a tiny performance
bubble in the pipeline ... but much less invasive than taking a
trap and having the OS perform the access).

Signed-off-by: Tony Luck <tony.luck@intel.com>
10 years agoPCI: tegra: Use new OF interrupt mapping when possible
Lucas Stach [Wed, 16 Apr 2014 16:24:32 +0000 (10:24 -0600)]
PCI: tegra: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This allows interrupts to be remapped across bridges.

Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
10 years agoPCI: rcar: Use new OF interrupt mapping when possible
Lucas Stach [Wed, 16 Apr 2014 16:24:09 +0000 (10:24 -0600)]
PCI: rcar: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This allows interrupts to be remapped across bridges.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
10 years agoPCI: designware: Use new OF interrupt mapping when possible
Lucas Stach [Wed, 16 Apr 2014 16:23:46 +0000 (10:23 -0600)]
PCI: designware: Use new OF interrupt mapping when possible

Use new OF interrupt mapping (of_irq_parse_and_map_pci()) when possible.
This is the recommended method of doing the IRQ mapping.  For old
devicetrees we fall back to the previous practice.

This makes INTB, INTC, and INTD work on i.MX.

Tested-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Jingoo Han <jg1.han@samsung.com>
10 years agoPCI: designware: Fix iATU programming for cfg1, io and mem viewport
Mohit Kumar [Wed, 16 Apr 2014 16:23:34 +0000 (10:23 -0600)]
PCI: designware: Fix iATU programming for cfg1, io and mem viewport

This patch corrects iATU programming for cfg1, io and mem viewport.  Enable
ATU only after configuring it.

Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Ajay Khandelwal <ajay.khandelwal@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Cc: stable@vger.kernel.org
10 years agoPCI: designware: Fix comment for setting number of lanes
Mohit Kumar [Wed, 16 Apr 2014 16:23:28 +0000 (10:23 -0600)]
PCI: designware: Fix comment for setting number of lanes

Corrects comment for setting number of lanes.

Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
10 years agodrm/tegra: Remove gratuitous pad field
Thierry Reding [Wed, 9 Apr 2014 12:26:59 +0000 (14:26 +0200)]
drm/tegra: Remove gratuitous pad field

The version of the drm_tegra_submit structure that was merged all the
way back in 3.10 contains a pad field that was originally intended to
properly pad the following __u64 field. Unfortunately it seems like a
different field was dropped during review that caused this padding to
become unnecessary, but the pad field wasn't removed at that time.

One possible side-effect of this is that since the __u64 following the
pad is now no longer properly aligned, the compiler may (or may not)
introduce padding itself, which results in no predictable ABI.

Rectify this by removing the pad field so that all fields are again
naturally aligned. Technically this is breaking existing userspace ABI,
but given that there aren't any (released) userspace drivers that make
use of this yet, the fallout should be minimal.

Fixes: d43f81cbaf43 ("drm/tegra: Add gr2d device")
Cc: <stable@vger.kernel.org> # 3.10
Signed-off-by: Thierry Reding <treding@nvidia.com>
10 years agogpu: host1x: handle the correct # of syncpt regs
Stephen Warren [Fri, 4 Apr 2014 22:31:05 +0000 (16:31 -0600)]
gpu: host1x: handle the correct # of syncpt regs

BIT_WORD() truncates rather than rounds, so the loops in
syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <=
rather than < in an attempt to process the correct number of registers
when rounding of the conversion of count of bits to count of words is
necessary. However, when rounding isn't necessary because the value is
already a multiple of the divisor (as is the case for all values of
nb_pts the code actually sees), this causes one too many registers to
be processed.

Solve this by using and explicit DIV_ROUND_UP() call, rather than
BIT_WORD(), and comparing with < rather than <=.

Fixes: 7ede0b0bf3e2 ("gpu: host1x: Add syncpoint wait and interrupts")
Cc: <stable@vger.kernel.org> # 3.10
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-By: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
10 years agoMerge git://git.infradead.org/iommu-2.6 into iommu/fixes
Joerg Roedel [Wed, 16 Apr 2014 14:09:40 +0000 (16:09 +0200)]
Merge git://git.infradead.org/iommu-2.6 into iommu/fixes

10 years agoALSA: hda/realtek - Add headset Mic support for Dell machine
Kailang Yang [Wed, 16 Apr 2014 07:53:12 +0000 (15:53 +0800)]
ALSA: hda/realtek - Add headset Mic support for Dell machine

Signed-off-by: Kailang Yang <kailang@realtek.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
10 years agox86: Remove the PCI reboot method from the default chain
Ingo Molnar [Fri, 4 Apr 2014 06:41:26 +0000 (08:41 +0200)]
x86: Remove the PCI reboot method from the default chain

Steve reported a reboot hang and bisected it back to this commit:

  a4f1987e4c54 x86, reboot: Add EFI and CF9 reboot methods into the default list

He heroically tested all reboot methods and found the following:

  reboot=t       # triple fault                  ok
  reboot=k       # keyboard ctrl                 FAIL
  reboot=b       # BIOS                          ok
  reboot=a       # ACPI                          FAIL
  reboot=e       # EFI                           FAIL   [system has no EFI]
  reboot=p       # PCI 0xcf9                     FAIL

And I think it's pretty obvious that we should only try PCI 0xcf9 as a
last resort - if at all.

The other observation is that (on this box) we should never try
the PCI reboot method, but close with either the 'triple fault'
or the 'BIOS' (terminal!) reboot methods.

Thirdly, CF9_COND is a total misnomer - it should be something like
CF9_SAFE or CF9_CAREFUL, and 'CF9' should be 'CF9_FORCE' ...

So this patch fixes the worst problems:

 - it orders the actual reboot logic to follow the reboot ordering
   pattern - it was in a pretty random order before for no good
   reason.

 - it fixes the CF9 misnomers and uses BOOT_CF9_FORCE and
   BOOT_CF9_SAFE flags to make the code more obvious.

 - it tries the BIOS reboot method before the PCI reboot method.
   (Since 'BIOS' is a terminal reboot method resulting in a hang
    if it does not work, this is essentially equivalent to removing
    the PCI reboot method from the default reboot chain.)

 - just for the miraculous possibility of terminal (resulting
   in hang) reboot methods of triple fault or BIOS returning
   without having done their job, there's an ordering between
   them as well.

Reported-and-bisected-and-tested-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Li Aubrey <aubrey.li@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Link: http://lkml.kernel.org/r/20140404064120.GB11877@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
10 years agodma: fix eDMA driver as a subsys_initcall
Yuan Yao [Fri, 4 Apr 2014 04:27:55 +0000 (12:27 +0800)]
dma: fix eDMA driver as a subsys_initcall

Because of some driver base on DMA, changed the initcall order as subsys_initcall.

Signed-off-by: Yuan Yao <yao.yuan@freescale.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
10 years agodmaengine: sirf: off by one in of_dma_sirfsoc_xlate()
Dan Carpenter [Thu, 3 Apr 2014 07:29:33 +0000 (10:29 +0300)]
dmaengine: sirf: off by one in of_dma_sirfsoc_xlate()

The ">" here should be ">=" or we are one step beyond the end of the
sdma->channels[] array.

Fixes: 2e041c94628c ('dmaengine: sirf: enable generic dt binding for dma channels')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
10 years agoplatform: Fix timberdale dependencies
Jean Delvare [Thu, 3 Apr 2014 09:32:06 +0000 (11:32 +0200)]
platform: Fix timberdale dependencies

VIDEO_TIMBERDALE selects TIMB_DMA which itself depends on
MFD_TIMBERDALE, so VIDEO_TIMBERDALE should either select or depend on
MFD_TIMBERDALE as well. I chose to make it depend on it because I
think it makes more sense and it is consistent with what other options
are doing.

Adding a "|| HAS_IOMEM" to the TIMB_DMA dependencies silenced the
kconfig warning about unmet direct dependencies but it was wrong:
without MFD_TIMBERDALE, TIMB_DMA is useless as the driver has no
device to bind to.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
10 years agoALSA: hda - add headset mic detect quirk for a Dell laptop
Hui Wang [Wed, 16 Apr 2014 02:09:08 +0000 (10:09 +0800)]
ALSA: hda - add headset mic detect quirk for a Dell laptop

When we plug a 3-ring headset on the Dell machine (VID: 0x10ec0255,
SID: 0x1028067f), the headset mic can't be detected, after apply this
patch, the headset mic can work well.

BugLink: https://bugs.launchpad.net/bugs/1297581
Cc: David Henningsson <david.henningsson@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
10 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Linus Torvalds [Wed, 16 Apr 2014 03:30:30 +0000 (20:30 -0700)]
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net

Pull networking fixes from David Miller:

 1) Fix BPF filter validation of netlink attribute accesses, from
    Mathias Kruase.

 2) Netfilter conntrack generation seqcount not initialized properly,
    from Andrey Vagin.

 3) Fix comparison mask computation on big-endian in nft_cmp_fast(),
    from Patrick McHardy.

 4) Properly limit MTU over ipv6, from Eric Dumazet.

 5) Fix seccomp system call argument population on 32-bit, from Daniel
    Borkmann.

 6) skb_network_protocol() should not use hard-coded ETH_HLEN, instead
    skb->mac_len needs to be used.  From Vlad Yasevich.

 7) We have several cases of using socket based communications to
    implement a tunnel.  For example, some tunnels are encapsulations
    over UDP so we use an internal kernel UDP socket to do the
    transmits.

    These tunnels should behave just like other software devices and
    pass the packets on down to the next layer.

    Most importantly we want the top-level socket (eg TCP) that created
    the traffic to be charged for the SKB memory.

    However, once you get into the IP output path, we have code that
    assumed that whatever was attached to skb->sk is an IP socket.

    To keep the top-level socket being charged for the SKB memory,
    whilst satisfying the needs of the IP output path, we now pass in an
    explicit 'sk' argument.

    From Eric Dumazet.

 8) ping_init_sock() leaks group info, from Xiaoming Wang.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (33 commits)
  cxgb4: use the correct max size for firmware flash
  qlcnic: Fix MSI-X initialization code
  ip6_gre: don't allow to remove the fb_tunnel_dev
  ipv4: add a sock pointer to dst->output() path.
  ipv4: add a sock pointer to ip_queue_xmit()
  driver/net: cosa driver uses udelay incorrectly
  at86rf230: fix __at86rf230_read_subreg function
  at86rf230: remove check if AVDD settled
  net: cadence: Add architecture dependencies
  net: Start with correct mac_len in skb_network_protocol
  Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
  cxgb4: Save the correct mac addr for hw-loopback connections in the L2T
  net: filter: seccomp: fix wrong decoding of BPF_S_ANC_SECCOMP_LD_W
  seccomp: fix populating a0-a5 syscall args in 32-bit x86 BPF
  qlcnic: Do not disable SR-IOV when VFs are assigned to VMs
  qlcnic: Fix QLogic application/driver interface for virtual NIC configuration
  qlcnic: Fix PVID configuration on eSwitch port.
  qlcnic: Fix max ring count calculation
  qlcnic: Fix to send INIT_NIC_FUNC as first mailbox.
  qlcnic: Fix panic due to uninitialzed delayed_work struct in use.
  ...

10 years agoMerge tag 'drm-intel-fixes-2014-04-11' of git://anongit.freedesktop.org/drm-intel...
Dave Airlie [Wed, 16 Apr 2014 00:35:01 +0000 (10:35 +1000)]
Merge tag 'drm-intel-fixes-2014-04-11' of git://anongit.freedesktop.org/drm-intel into drm-next

Some fixes from Intel.

* tag 'drm-intel-fixes-2014-04-11' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Always use kref tracking for all contexts.
  drm/i915: do not setup backlight if not available according to VBT
  drm/i915: check VBT for supported backlight type
  drm/i915: Disable self-refresh for untiled fbs on i915gm
  drm/mm: Don't WARN if drm_mm_reserve_node

10 years agostaging: rtl8723au: Fix buffer overflow in rtw_get_wfd_ie()
Jes Sorensen [Tue, 15 Apr 2014 17:43:20 +0000 (19:43 +0200)]
staging: rtl8723au: Fix buffer overflow in rtw_get_wfd_ie()

Add bounds checking to not allow WFD Information Elements larger than
128, and make sure we use the correct buffer size MAX_WFD_IE_LEN
instea of hardcoding the size.

This also simplifies rtw_get_wfd_ie() by using the cfg80211
infrastructure.

Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: gs_fpgaboot: remove __TIMESTAMP__ macro
Arnd Bergmann [Tue, 25 Mar 2014 15:48:35 +0000 (16:48 +0100)]
staging: gs_fpgaboot: remove __TIMESTAMP__ macro

We specifically build the kernel with -Werror=date-time to detect
such macros, which gives us this error:

gs_fpgaboot/gs_fpgaboot.c:376:44: error: macro "__TIMESTAMP__" might prevent reproducible builds [-Werror=date-time]
  pr_info("built at %s UTC\n", __TIMESTAMP__);

The obvious fix is to remove the printk output line.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Insop Song <insop.song@gainspeed.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: vme: fix memory leak in vme_user_probe()
Daeseok Youn [Wed, 26 Mar 2014 03:01:48 +0000 (12:01 +0900)]
staging: vme: fix memory leak in vme_user_probe()

If vme_master_request() returns NULL when it failed,
it need to free buffers for master.

And also removes unreachable code in vme_user_probe().

Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: fpgaboot: clean up Makefile
Paul Bolle [Thu, 3 Apr 2014 08:32:17 +0000 (10:32 +0200)]
staging: fpgaboot: clean up Makefile

This Makefile tries to set the DEBUG macro but it uses an unknown
Kconfig macro to do so. Since no code appears to even care about the
DEBUG macro this line can safely be removed.

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Reviewed-by: Insop Song <insop.song@gainspeed.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging/usbip: fix store_attach() sscanf return value check
Shuah Khan [Tue, 25 Mar 2014 12:47:13 +0000 (06:47 -0600)]
staging/usbip: fix store_attach() sscanf return value check

sscanf() parses the input buffer for four input items. However,
the return value check is incorrect, as it checks for one input
item instead of four which is what it is expecting in the input
buffer. As a result, sscanf() will always fail even when the input
buffer is correct.

Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging/usbip: userspace - fix usbipd SIGSEGV from refresh_exported_devices()
Shuah Khan [Mon, 24 Mar 2014 19:45:13 +0000 (13:45 -0600)]
staging/usbip: userspace - fix usbipd SIGSEGV from refresh_exported_devices()

refresh_exported_devices() doesn't check udev_device_new_from_syspath()
return value and passed in null dev to udev_device_get_driver() resulting
in a segmentation fault. Change it to check for null return value from
both udev_device_new_from_syspath() and udev_device_get_driver().

Signed-off-by: Shuah Khan <shuah.kh@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agostaging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls
Wilfried Klaebe [Tue, 25 Mar 2014 17:59:39 +0000 (17:59 +0000)]
staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls

staging: rtl8188eu: remove spaces, correct counts to unbreak P2P ioctls

It looks like someone did a search-and-replace on that driver, putting
spaces before "=" characters, without checking this is OK everywhere.
Also, in some places, there's memcpm()s/strncmp()s checking for some
different length than the fixed string argument.

These things result in code not working as intended. Fix that.

Signed-off-by: Wilfried Klaebe <w-lkml@lebenslange-mailadresse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agoof: Clean up of_update_property
Guenter Roeck [Tue, 15 Apr 2014 15:38:17 +0000 (08:38 -0700)]
of: Clean up of_update_property

After searching for the old property, bail out with -ENODEV
if it was not found.

It is unnecessary to check if oldprop is NULL before removing
its binary file; the check was already done before.

Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Rob Herring <robh@kernel.org>
10 years agocxgb4: use the correct max size for firmware flash
Steve Wise [Tue, 15 Apr 2014 19:22:34 +0000 (14:22 -0500)]
cxgb4: use the correct max size for firmware flash

The wrong max fw size was being used and causing false
"too big" errors running ethtool -f.

Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoqlcnic: Fix MSI-X initialization code
Alexander Gordeev [Tue, 15 Apr 2014 09:37:14 +0000 (11:37 +0200)]
qlcnic: Fix MSI-X initialization code

Function qlcnic_setup_tss_rss_intr() might enter endless
loop in case pci_enable_msix() contiguously returns a
positive number of MSI-Xs that could have been allocated.
Besides, the function contains 'err = -EIO;' assignment
that never could be reached. This update fixes the
aforementioned issues.

Cc: Shahed Shaikh <shahed.shaikh@qlogic.com>
Cc: Dept-HSGLinuxNICDev@qlogic.com
Cc: netdev@vger.kernel.org
Cc: linux-pci@vger.kernel.org
Signed-off-by: Alexander Gordeev <agordeev@redhat.com>
Acked-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoip6_gre: don't allow to remove the fb_tunnel_dev
Nicolas Dichtel [Mon, 14 Apr 2014 15:11:38 +0000 (17:11 +0200)]
ip6_gre: don't allow to remove the fb_tunnel_dev

It's possible to remove the FB tunnel with the command 'ip link del ip6gre0' but
this is unsafe, the module always supposes that this device exists. For example,
ip6gre_tunnel_lookup() may use it unconditionally.

Let's add a rtnl handler for dellink, which will never remove the FB tunnel (we
let ip6gre_destroy_tunnels() do the job).

Introduced by commit c12b395a4664 ("gre: Support GRE over IPv6").

CC: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agostaging/rtl8821ae: Fix OOM handling in _rtl_init_deferred_work()
Richard Weinberger [Thu, 20 Mar 2014 23:42:54 +0000 (00:42 +0100)]
staging/rtl8821ae: Fix OOM handling in _rtl_init_deferred_work()

alloc_workqueue() can fail, handle this case.

Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
10 years agotick-sched: Check tick_nohz_enabled in tick_nohz_switch_to_nohz()
Viresh Kumar [Tue, 15 Apr 2014 05:24:41 +0000 (10:54 +0530)]
tick-sched: Check tick_nohz_enabled in tick_nohz_switch_to_nohz()

Since commit d689fe222 (NOHZ: Check for nohz active instead of nohz
enabled) the tick_nohz_switch_to_nohz() function returns because it
checks for the tick_nohz_active flag. This can't be set, because the
function itself sets it.

Undo the change in tick_nohz_switch_to_nohz().

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linaro-kernel@lists.linaro.org
Cc: fweisbec@gmail.com
Cc: Arvind.Chauhan@arm.com
Cc: linaro-networking@linaro.org
Cc: <stable@vger.kernel.org> # 3.13+
Link: http://lkml.kernel.org/r/40939c05f2d65d781b92b20302b02243d0654224.1397537987.git.viresh.kumar@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
10 years agotick-sched: Don't call update_wall_time() when delta is lesser than tick_period
Viresh Kumar [Tue, 15 Apr 2014 05:24:40 +0000 (10:54 +0530)]
tick-sched: Don't call update_wall_time() when delta is lesser than tick_period

In tick_do_update_jiffies64() we are processing ticks only if delta is
greater than tick_period. This is what we are supposed to do here and
it broke a bit with this patch:

commit 47a1b796 (tick/timekeeping: Call update_wall_time outside the
jiffies lock)

With above patch, we might end up calling update_wall_time() even if
delta is found to be smaller that tick_period. Fix this by returning
when the delta is less than tick period.

[ tglx: Made it a 3 liner and massaged changelog ]

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: linaro-kernel@lists.linaro.org
Cc: fweisbec@gmail.com
Cc: Arvind.Chauhan@arm.com
Cc: linaro-networking@linaro.org
Cc: John Stultz <john.stultz@linaro.org>
Cc: <stable@vger.kernel.org> # v3.14+
Link: http://lkml.kernel.org/r/80afb18a494b0bd9710975bcc4de134ae323c74f.1397537987.git.viresh.kumar@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
10 years agotick-common: Fix wrong check in tick_check_replacement()
Viresh Kumar [Tue, 15 Apr 2014 05:24:37 +0000 (10:54 +0530)]
tick-common: Fix wrong check in tick_check_replacement()

tick_check_replacement() returns if a replacement of clock_event_device is
possible or not. It does this as the first check:

if (tick_check_percpu(curdev, newdev, smp_processor_id()))
return false;

Thats wrong. tick_check_percpu() returns true when the device is
useable. Check for false instead.

[ tglx: Massaged changelog ]

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: <stable@vger.kernel.org> # v3.11+
Cc: linaro-kernel@lists.linaro.org
Cc: fweisbec@gmail.com
Cc: Arvind.Chauhan@arm.com
Cc: linaro-networking@linaro.org
Link: http://lkml.kernel.org/r/486a02efe0246635aaba786e24b42d316438bf3b.1397537987.git.viresh.kumar@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
10 years agoipv4: add a sock pointer to dst->output() path.
Eric Dumazet [Tue, 15 Apr 2014 17:47:15 +0000 (13:47 -0400)]
ipv4: add a sock pointer to dst->output() path.

In the dst->output() path for ipv4, the code assumes the skb it has to
transmit is attached to an inet socket, specifically via
ip_mc_output() : The sk_mc_loop() test triggers a WARN_ON() when the
provider of the packet is an AF_PACKET socket.

The dst->output() method gets an additional 'struct sock *sk'
parameter. This needs a cascade of changes so that this parameter can
be propagated from vxlan to final consumer.

Fixes: 8f646c922d55 ("vxlan: keep original skb ownership")
Reported-by: lucien xin <lucien.xin@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agomwifiex: fix hung task on command timeout
Amitkumar Karwar [Mon, 14 Apr 2014 22:31:06 +0000 (15:31 -0700)]
mwifiex: fix hung task on command timeout

Sometimes when command timeout occurs due to a firmware or
hardware bug, there may be some synchronous commands in command
queue. These commands are never downloaded to firmware causing
hung task warnings. This patch replaces wait_event_interruptible
call with wait_event_interruptible_timeout to fix the issue.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
10 years agomwifiex: process event before command response
Amitkumar Karwar [Mon, 14 Apr 2014 22:31:05 +0000 (15:31 -0700)]
mwifiex: process event before command response

During extended scan, SCAN report event is always followed by
command response. Sometimes It is observed that command response
is processed before SCAN report which leads to a crash, because
current command node is cleared while handling the response.
This patch makes sure that driver's main thread gives priority
to events over command responses.

Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
10 years agoMerge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git...
Ingo Molnar [Tue, 15 Apr 2014 17:25:07 +0000 (19:25 +0200)]
Merge tag 'perf-urgent-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf into perf/urgent

Pull perf/urgent fixes from Jiri Olsa:

  * Instead of redirecting flex output, use -o (Cody P Schafer)

  * Fix double free in perf test 21 (Adrian Hunter)

Signed-off-by: Jiri Olsa <jolsa@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
10 years agoipv4: add a sock pointer to ip_queue_xmit()
Eric Dumazet [Tue, 15 Apr 2014 16:58:34 +0000 (12:58 -0400)]
ipv4: add a sock pointer to ip_queue_xmit()

ip_queue_xmit() assumes the skb it has to transmit is attached to an
inet socket. Commit 31c70d5956fc ("l2tp: keep original skb ownership")
changed l2tp to not change skb ownership and thus broke this assumption.

One fix is to add a new 'struct sock *sk' parameter to ip_queue_xmit(),
so that we do not assume skb->sk points to the socket used by l2tp
tunnel.

Fixes: 31c70d5956fc ("l2tp: keep original skb ownership")
Reported-by: Zhan Jianyu <nasa4836@gmail.com>
Tested-by: Zhan Jianyu <nasa4836@gmail.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoxen/manage: Poweroff forcefully if user-space is not yet up.
Konrad Rzeszutek Wilk [Fri, 4 Apr 2014 18:53:41 +0000 (14:53 -0400)]
xen/manage: Poweroff forcefully if user-space is not yet up.

The user can launch the guest in this sequence:

xl create -p /vm.cfg [launch, but pause it]
xl shutdown latest [sets control/shutdown=poweroff]
xl unpause latest
xl console latest [and see that the guest has completely
ignored the shutdown request]

In reality the guest hasn't ignored it. It registers a watch
and gets a notification that there is value. It then calls
the shutdown_handler which ends up calling orderly_shutdown.

Unfortunately that is so early in the bootup that there
are no user-space. Which means that the orderly_shutdown fails.
But since the force flag was set to false it continues on without
reporting.

What we really want to is to use the force when we are in the
SYSTEM_BOOTING state and not use the 'force' when SYSTEM_RUNNING.

However, if we are in the running state - and the shutdown command
has been given before the user-space has been setup, there is nothing
we can do. Worst yet, we stop ignoring the 'xl shutdown' requests!

As such, the other part of this patch is to only stop ignoring
the 'xl shutdown' when we are truly in the power off sequence.

That means the user can do multiple 'xl shutdown' and we will try
to act on them instead of ignoring them.

Fixes-Bug: http://bugs.xenproject.org/xen/bug/6
Reported-by: Alex Bligh <alex@alex.org.uk>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
10 years agoxen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.
Konrad Rzeszutek Wilk [Fri, 4 Apr 2014 18:53:40 +0000 (14:53 -0400)]
xen/xenbus: Avoid synchronous wait on XenBus stalling shutdown/restart.

The 'read_reply' works with 'process_msg' to read of a reply in XenBus.
'process_msg' is running from within the 'xenbus' thread. Whenever
a message shows up in XenBus it is put on a xs_state.reply_list list
and 'read_reply' picks it up.

The problem is if the backend domain or the xenstored process is killed.
In which case 'xenbus' is still awaiting - and 'read_reply' if called -
stuck forever waiting for the reply_list to have some contents.

This is normally not a problem - as the backend domain can come back
or the xenstored process can be restarted. However if the domain
is in process of being powered off/restarted/halted - there is no
point of waiting on it coming back - as we are effectively being
terminated and should not impede the progress.

This patch solves this problem by checking whether the guest is the
right domain. If it is an initial domain and hurtling towards death -
there is no point of continuing the wait. All other type of guests
continue with their behavior (as Xenstore is expected to still be
running in another domain).

Fixes-Bug: http://bugs.xenproject.org/xen/bug/8
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
10 years agoxen/spinlock: Don't enable them unconditionally.
Konrad Rzeszutek Wilk [Fri, 4 Apr 2014 18:48:04 +0000 (14:48 -0400)]
xen/spinlock: Don't enable them unconditionally.

The git commit a945928ea2709bc0e8e8165d33aed855a0110279
('xen: Do not enable spinlocks before jump_label_init() has executed')
was added to deal with the jump machinery. Earlier the code
that turned on the jump label was only called by Xen specific
functions. But now that it had been moved to the initcall machinery
it gets called on Xen, KVM, and baremetal - ouch!. And the detection
machinery to only call it on Xen wasn't remembered in the heat
of merge window excitement.

This means that the slowpath is enabled on baremetal while it should
not be.

Reported-by: Waiman Long <waiman.long@hp.com>
Acked-by: Steven Rostedt <rostedt@goodmis.org>
CC: stable@vger.kernel.org
CC: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
10 years agoxen-pciback: silence an unwanted debug printk
Dan Carpenter [Fri, 28 Mar 2014 08:24:59 +0000 (11:24 +0300)]
xen-pciback: silence an unwanted debug printk

There is a missing curly brace here so we might print some extra debug
information.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
10 years agoxen: fix memory leak in __xen_pcibk_add_pci_dev()
Daeseok Youn [Tue, 1 Apr 2014 10:15:59 +0000 (19:15 +0900)]
xen: fix memory leak in __xen_pcibk_add_pci_dev()

It need to free dev_entry when it failed to assign to a new
slot on the virtual PCI bus.

smatch says:
 drivers/xen/xen-pciback/vpci.c:142 __xen_pcibk_add_pci_dev() warn:
possible memory leak of 'dev_entry'

Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
10 years agoirqchip: vic: Properly chain the cascaded IRQs
Linus Walleij [Tue, 15 Apr 2014 08:28:04 +0000 (10:28 +0200)]
irqchip: vic: Properly chain the cascaded IRQs

We are flagging the parent IRQ as chained, then we must also
make sure to call the chained_irq_[enter|exit] functions for
things to work smoothly.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: http://lkml.kernel.org/r/1397550484-7119-1-git-send-email-linus.walleij@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
10 years agox86/xen: Fix 32-bit PV guests's usage of kernel_stack
Boris Ostrovsky [Thu, 10 Apr 2014 16:17:09 +0000 (12:17 -0400)]
x86/xen: Fix 32-bit PV guests's usage of kernel_stack

Commit 198d208df4371734ac4728f69cb585c284d20a15 ("x86: Keep
thread_info on thread stack in x86_32") made 32-bit kernels use
kernel_stack to point to thread_info. That change missed a couple of
updates needed by Xen's 32-bit PV guests:

1. kernel_stack needs to be initialized for secondary CPUs

2. GET_THREAD_INFO() now uses %fs register which may not be the
   kernel's version when executing xen_iret().

With respect to the second issue, we don't need GET_THREAD_INFO()
anymore: we used it as an intermediate step to get to per_cpu xen_vcpu
and avoid referencing %fs. Now that we are going to use %fs anyway we
may as well go directly to xen_vcpu.

Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
10 years agodrm/omap: fix the handling of fb ref counts
Tomi Valkeinen [Tue, 15 Apr 2014 13:26:01 +0000 (16:26 +0300)]
drm/omap: fix the handling of fb ref counts

With the recent primary-plane changes for drm, the primary plane's
framebuffer needs to be ref counted the same way as for
non-primary-planes. This was not done by the omapdrm driver, which
caused the ref count to drop to 0 too early, causing problems.

This patch moves the fb unref and ref from omap_plane_update to
omap_plane_mode_set. This way the fb refs are updated for both primary
and non-primary cases, as omap_plane_update calls omap_plane_mode_set.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agoperf tools: Instead of redirecting flex output, use -o
Cody P Schafer [Mon, 14 Apr 2014 10:47:01 +0000 (12:47 +0200)]
perf tools: Instead of redirecting flex output, use -o

This gives us a real filename instead of having '<stdout>' show up all
over the place when debugging.

Signed-off-by: Cody P Schafer <cody@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/r/1396652539-2416-1-git-send-email-cody@linux.vnet.ibm.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
10 years agoperf tools: Fix double free in perf test 21 (code-reading.c)
Adrian Hunter [Thu, 10 Apr 2014 09:02:54 +0000 (12:02 +0300)]
perf tools: Fix double free in perf test 21 (code-reading.c)

perf_evlist__delete() deletes attached cpu and thread maps
but the test is still using them, so remove them from the
evlist before deleting it.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Link: http://lkml.kernel.org/r/53465E3E.8070201@intel.com
Signed-off-by: Jiri Olsa <jolsa@redhat.com>
10 years agoiommu/arm-smmu: fix panic in arm_smmu_alloc_init_pte
Bin Wang [Fri, 21 Mar 2014 10:06:07 +0000 (10:06 +0000)]
iommu/arm-smmu: fix panic in arm_smmu_alloc_init_pte

kernel panic happened when iommu_unmap a buffer larger than 2MB,
more than expected pmd entries got “invalidated”, due to a wrong range
passed to arm_smmu_alloc_init_pte. it was likely a typo, now we fix
it, passing the correct "end" address to arm_smmu_alloc_init_pte.

Signed-off-by: Bin Wang <binw@marvell.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
10 years agoiommu/arm-smmu: Return 0 on unmap failure
Laurent Pinchart [Fri, 28 Feb 2014 15:37:10 +0000 (15:37 +0000)]
iommu/arm-smmu: Return 0 on unmap failure

The IOMMU core expects the unmap operation to return the number of bytes
that have been unmapped or 0 on failure, a negative return value being
treated like a number of bytes.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
10 years agodrm/omap: protect omap_crtc's event with event_lock spinlock
Archit Taneja [Fri, 11 Apr 2014 07:23:35 +0000 (12:53 +0530)]
drm/omap: protect omap_crtc's event with event_lock spinlock

The vblank_cb callback and the page_flip ioctl can occur together in different
CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when
sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb.

Use the same spinlock in page_flip, to make sure the above omap_crtc parameters
are configured sequentially.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agodrm/omap: Use old_fb to synchronize between successive page flips
Archit Taneja [Fri, 11 Apr 2014 07:23:34 +0000 (12:53 +0530)]
drm/omap: Use old_fb to synchronize between successive page flips

omap_crtc->old_fb is used to check whether the previous page flip has completed
or not. However, it's never initialized to anything, so it's always NULL. This
results in the check to always succeed, and the page_flip to proceed.

Initialize old_fb to the fb that we intend to flip to through page_flip, and
therefore prevent a future page flip to proceed if the last one didn't
complete.

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agodrm/omap: Fix crash when using LCD3 overlay manager
Archit Taneja [Fri, 11 Apr 2014 07:23:32 +0000 (12:53 +0530)]
drm/omap: Fix crash when using LCD3 overlay manager

The channel_names list didn't have a string populated for LCD3 manager, this
results in a crash when the display's output is connected to LCD3. Add an entry
for LCD3.

Reported-by: Somnath Mukherjee <somnath@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agodrm/omap: gem sync: wait on correct events
Archit Taneja [Fri, 11 Apr 2014 07:23:31 +0000 (12:53 +0530)]
drm/omap: gem sync: wait on correct events

A waiter of the type OMAP_GEM_READ should wait for a buffer to be completely
written, and only then proceed with reading it. A similar logic applies for
waiters with OMAP_GEM_WRITE flag.

Currently the function is_waiting() waits on the read_complete/read_target
counts in the sync object.

This should be the other way round, as a reader should wait for users who are
'writing' to this buffer, and vice versa.

Make readers of the buffer(OMAP_GEM_READ) wait on the write counters, and
writers to the buffer(OMAP_GEM_WRITE) wait on the read counters in is_waiting()

Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agodrm/omap: Fix memory leak in omap_gem_op_async
Subhajit Paul [Fri, 11 Apr 2014 07:23:30 +0000 (12:53 +0530)]
drm/omap: Fix memory leak in omap_gem_op_async

In omap_gem_op_async(), if a waiter is not added to the wait list, it needs to
be free'd in the function itself.

Make sure we free the waiter for this case.

Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agodrm/omap: remove warn from debugfs
Tomi Valkeinen [Thu, 10 Apr 2014 05:57:55 +0000 (08:57 +0300)]
drm/omap: remove warn from debugfs

Patch dfe96ddcfa22b44100814b9435770f6ff1309d37 (omapdrm: simplify locking in
the fb debugfs file) removed taking locks when using omapdrm's debugfs
to dump fb objects.

However, in omap_gem_describe we give a WARN is the lock has not been
taken, so that WARN is now seen every time omapdrm debugfs is used.

So, presuming the removal of locks is ok, we can also remove the WARN.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agodrm/omap: remove extra plane->destroy from crtc destroy
Tomi Valkeinen [Wed, 9 Apr 2014 11:51:01 +0000 (14:51 +0300)]
drm/omap: remove extra plane->destroy from crtc destroy

All the planes, including primary planes, are now destroyed by the drm
framework. Thus we no longer need the explicit call to plane->destroy
from the crtc's destroy function.

This patch removes the call, thus fixing the crash caused by double
freeing the plane.

remove omap_crtc->plane->funcs->destroy(omap_crtc->plane)

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agodrm/omap: print warning when rotating non-TILER fb
Tomi Valkeinen [Tue, 8 Apr 2014 13:18:41 +0000 (16:18 +0300)]
drm/omap: print warning when rotating non-TILER fb

Print a warning when the user tries to rotate a non-TILER framebuffer.

Also set the rotation to 0, to avoid constant flood of the warnings in
case of page flipping.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agovideo: bf54x-lq043fb: fix build error
Steven Miao [Tue, 15 Apr 2014 07:17:19 +0000 (15:17 +0800)]
video: bf54x-lq043fb: fix build error

Fix build error by including linux/gpio.h. Also drop asm/gpio.h which is
not needed.

Signed-off-by: Steven Miao <realmz6@gmail.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
10 years agoiommu/vt-d: fix bug in matching PCI devices with DRHD/RMRR descriptors
Jiang Liu [Tue, 15 Apr 2014 02:35:35 +0000 (10:35 +0800)]
iommu/vt-d: fix bug in matching PCI devices with DRHD/RMRR descriptors

Commit "59ce0515cdaf iommu/vt-d: Update DRHD/RMRR/ATSR device scope
caches when PCI hotplug happens" introduces a bug, which fails to
match PCI devices with DMAR device scope entries if PCI path array
in the entry has more than one level.

For example, it fails to handle
[1D2h 0466   1]      Device Scope Entry Type : 01
[1D3h 0467   1]                 Entry Length : 0A
[1D4h 0468   2]                     Reserved : 0000
[1D6h 0470   1]               Enumeration ID : 00
[1D7h 0471   1]               PCI Bus Number : 00
[1D8h 0472   2]                     PCI Path : 1C,04
[1DAh 0474   2]                     PCI Path : 00,02

And cause DMA failure on HP DL980 as:
DMAR:[fault reason 02] Present bit in context entry is clear
dmar: DRHD: handling fault status reg 602
dmar: DMAR:[DMA Read] Request device [02:00.2] fault addr 7f61e000

Reported-and-tested-by: Davidlohr Bueso <davidlohr@hp.com>
Signed-off-by: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
10 years agoiommu/vt-d: Fix get_domain_for_dev() handling of upstream PCIe bridges
David Woodhouse [Tue, 15 Apr 2014 05:01:30 +0000 (22:01 -0700)]
iommu/vt-d: Fix get_domain_for_dev() handling of upstream PCIe bridges

Commit 146922ec79 ("iommu/vt-d: Make get_domain_for_dev() take struct
device") introduced new variables bridge_bus and bridge_devfn to
identify the upstream PCIe to PCI bridge responsible for the given
target device. Leaving the original bus/devfn variables to identify
the target device itself, now that it is no longer assumed to be PCI
and we can no longer trivially find that information.

However, the patch failed to correctly use the new variables in all
cases; instead using the as-yet-uninitialised 'bus' and 'devfn'
variables.

Reported-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
10 years agodriver/net: cosa driver uses udelay incorrectly
Li, Zhen-Hua [Tue, 15 Apr 2014 01:53:11 +0000 (09:53 +0800)]
driver/net: cosa driver uses udelay incorrectly

In cosa driver, udelay with more than 20000 may cause __bad_udelay.
Use msleep for instead.

Signed-off-by: Li, Zhen-Hua <zhen-hual@hp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoat86rf230: fix __at86rf230_read_subreg function
Alexander Aring [Mon, 14 Apr 2014 16:48:02 +0000 (18:48 +0200)]
at86rf230: fix __at86rf230_read_subreg function

The __at86rf230_read_subreg function don't mask and shift register
contents which it should do. This patch adds the necessary masks and
shift operations in this function.

Since we have csma support this can make some trouble on state changes.
Since CSMA support turned on some bits in the TRX_STATUS register that
used to be zero, not masking broke checking of the TRX_STATUS field
after commanding a state change.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Reviewed-by: Werner Almesberger <werner@almesberger.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoat86rf230: remove check if AVDD settled
Alexander Aring [Mon, 14 Apr 2014 16:48:01 +0000 (18:48 +0200)]
at86rf230: remove check if AVDD settled

The AVDD regulator is only enabled when the RF section is active TX_ON
(PLL_ON) state. Since commit 7dcbd22a97eb0689e6c583ad630ae0e7341e34c1
("ieee802154: ensure that first RF212 state comes from TRX_OFF").
We are in TRX_OFF state at the time at86rf230_hw_init is run.

Note that this test would only fail in case of a severe hardware
malfunction (faulty/shorted power supply, etc.) so it wasn't all that
useful in the first place.

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Reviewed-by: Werner Almesberger <werner@almesberger.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agonet: cadence: Add architecture dependencies
Jean Delvare [Mon, 14 Apr 2014 13:38:49 +0000 (15:38 +0200)]
net: cadence: Add architecture dependencies

The Cadence ethernet chipsets are only used on specific ARM
architectures. Add Kconfig dependencies so that drivers for these
chipsets are only buildable on the relevant architectures.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoMerge git://git.kernel.org/pub/scm/virt/kvm/kvm
Linus Torvalds [Mon, 14 Apr 2014 23:21:28 +0000 (16:21 -0700)]
Merge git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull KVM fixes from Marcelo Tosatti:
 - Fix for guest triggerable BUG_ON (CVE-2014-0155)
 - CR4.SMAP support
 - Spurious WARN_ON() fix

* git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: remove WARN_ON from get_kernel_ns()
  KVM: Rename variable smep to cr4_smep
  KVM: expose SMAP feature to guest
  KVM: Disable SMAP for guests in EPT realmode and EPT unpaging mode
  KVM: Add SMAP support when setting CR4
  KVM: Remove SMAP bit from CR4_RESERVED_BITS
  KVM: ioapic: try to recover if pending_eoi goes out of range
  KVM: ioapic: fix assignment of ioapic->rtc_status.pending_eoi (CVE-2014-0155)

10 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Linus Torvalds [Mon, 14 Apr 2014 23:04:14 +0000 (16:04 -0700)]
Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

Pull bmc2835 crypto fix from Herbert Xu:
 "This fixes a potential boot crash on bcm2835 due to the recent change
  that now causes hardware RNGs to be accessed on registration"

* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  hwrng: bcm2835 - fix oops when rng h/w is accessed during registration

10 years agouser namespace: fix incorrect memory barriers
Mikulas Patocka [Mon, 14 Apr 2014 20:58:55 +0000 (16:58 -0400)]
user namespace: fix incorrect memory barriers

smp_read_barrier_depends() can be used if there is data dependency between
the readers - i.e. if the read operation after the barrier uses address
that was obtained from the read operation before the barrier.

In this file, there is only control dependency, no data dependecy, so the
use of smp_read_barrier_depends() is incorrect. The code could fail in the
following way:
* the cpu predicts that idx < entries is true and starts executing the
  body of the for loop
* the cpu fetches map->extent[0].first and map->extent[0].count
* the cpu fetches map->nr_extents
* the cpu verifies that idx < extents is true, so it commits the
  instructions in the body of the for loop

The problem is that in this scenario, the cpu read map->extent[0].first
and map->nr_extents in the wrong order. We need a full read memory barrier
to prevent it.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
10 years agoMerge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf
David S. Miller [Mon, 14 Apr 2014 23:00:10 +0000 (19:00 -0400)]
Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf

Pablo Neira Ayuso says:

====================
Netfilter fixes for net

The following patchset contains three Netfilter fixes for your net tree,
they are:

* Fix missing generation sequence initialization which results in a splat
  if lockdep is enabled, it was introduced in the recent works to improve
  nf_conntrack scalability, from Andrey Vagin.

* Don't flush the GRE keymap list in nf_conntrack when the pptp helper is
  disabled otherwise this crashes due to a double release, from Andrey
  Vagin.

* Fix nf_tables cmp fast in big endian, from Patrick McHardy.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agonet: Start with correct mac_len in skb_network_protocol
Vlad Yasevich [Mon, 14 Apr 2014 21:37:26 +0000 (17:37 -0400)]
net: Start with correct mac_len in skb_network_protocol

Sometimes, when the packet arrives at skb_mac_gso_segment()
its skb->mac_len already accounts for some of the mac lenght
headers in the packet.  This seems to happen when forwarding
through and OpenSSL tunnel.

When we start looking for any vlan headers in skb_network_protocol()
we seem to ignore any of the already known mac headers and start
with an ETH_HLEN.  This results in an incorrect offset, dropped
TSO frames and general slowness of the connection.

We can start counting from the known skb->mac_len
and return at least that much if all mac level headers
are known and accounted for.

Fixes: 53d6471cef17262d3ad1c7ce8982a234244f68ec (net: Account for all vlan headers in skb_mac_gso_segment)
CC: Eric Dumazet <eric.dumazet@gmail.com>
CC: Daniel Borkman <dborkman@redhat.com>
Tested-by: Martin Filip <nexus+kernel@smoula.net>
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agopowerpc/PCI: Fix NULL dereference in sys_pciconfig_iobase() list traversal
Mike Qiu [Mon, 14 Apr 2014 22:12:35 +0000 (16:12 -0600)]
powerpc/PCI: Fix NULL dereference in sys_pciconfig_iobase() list traversal

3bc955987fb3 ("powerpc/PCI: Use list_for_each_entry() for bus traversal")
caused a NULL pointer dereference because the loop body set the iterator to
NULL:

  Unable to handle kernel paging request for data at address 0x00000000
  Faulting instruction address: 0xc000000000041d78
  Oops: Kernel access of bad area, sig: 11 [#1]
  ...
  NIP [c000000000041d78] .sys_pciconfig_iobase+0x68/0x1f0
  LR [c000000000041e0c] .sys_pciconfig_iobase+0xfc/0x1f0
  Call Trace:
  [c0000003b4787db0] [c000000000041e0c] .sys_pciconfig_iobase+0xfc/0x1f0 (unreliable)
  [c0000003b4787e30] [c000000000009ed8] syscall_exit+0x0/0x98

Fix it by using a temporary variable for the iterator.

[bhelgaas: changelog, drop tmp_bus initialization]
Fixes: 3bc955987fb3 powerpc/PCI: Use list_for_each_entry() for bus traversal
Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
10 years agoKVM: x86: remove WARN_ON from get_kernel_ns()
Marcelo Tosatti [Thu, 10 Apr 2014 21:19:12 +0000 (18:19 -0300)]
KVM: x86: remove WARN_ON from get_kernel_ns()

Function and callers can be preempted.

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

Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
10 years agoKVM: Rename variable smep to cr4_smep
Feng Wu [Tue, 1 Apr 2014 09:56:48 +0000 (17:56 +0800)]
KVM: Rename variable smep to cr4_smep

Rename variable smep to cr4_smep, which can better reflect the
meaning of the variable.

Signed-off-by: Feng Wu <feng.wu@intel.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
10 years agoKVM: expose SMAP feature to guest
Feng Wu [Tue, 1 Apr 2014 09:46:36 +0000 (17:46 +0800)]
KVM: expose SMAP feature to guest

This patch exposes SMAP feature to guest

Signed-off-by: Feng Wu <feng.wu@intel.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
10 years agoKVM: Disable SMAP for guests in EPT realmode and EPT unpaging mode
Feng Wu [Tue, 1 Apr 2014 09:46:35 +0000 (17:46 +0800)]
KVM: Disable SMAP for guests in EPT realmode and EPT unpaging mode

SMAP is disabled if CPU is in non-paging mode in hardware.
However KVM always uses paging mode to emulate guest non-paging
mode with TDP. To emulate this behavior, SMAP needs to be
manually disabled when guest switches to non-paging mode.

Signed-off-by: Feng Wu <feng.wu@intel.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
10 years agoKVM: Add SMAP support when setting CR4
Feng Wu [Tue, 1 Apr 2014 09:46:34 +0000 (17:46 +0800)]
KVM: Add SMAP support when setting CR4

This patch adds SMAP handling logic when setting CR4 for guests

Thanks a lot to Paolo Bonzini for his suggestion to use the branchless
way to detect SMAP violation.

Signed-off-by: Feng Wu <feng.wu@intel.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
10 years agoKVM: Remove SMAP bit from CR4_RESERVED_BITS
Feng Wu [Tue, 1 Apr 2014 09:46:33 +0000 (17:46 +0800)]
KVM: Remove SMAP bit from CR4_RESERVED_BITS

This patch removes SMAP bit from CR4_RESERVED_BITS.

Signed-off-by: Feng Wu <feng.wu@intel.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
10 years agoRevert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver...
Daniel Borkmann [Mon, 14 Apr 2014 19:45:17 +0000 (21:45 +0200)]
Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"

This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management
to reflect real state of the receiver's buffer") as it introduced a
serious performance regression on SCTP over IPv4 and IPv6, though a not
as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs.

Current state:

[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.241.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 17:56:21 GMT
Connecting to host 192.168.241.3, port 5201
      Cookie: Lab200slot2.1397238981.812898.548918
[  4] local 192.168.241.2 port 38616 connected to 192.168.241.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.09   sec  20.8 MBytes   161 Mbits/sec
[  4]   1.09-2.13   sec  10.8 MBytes  86.8 Mbits/sec
[  4]   2.13-3.15   sec  3.57 MBytes  29.5 Mbits/sec
[  4]   3.15-4.16   sec  4.33 MBytes  35.7 Mbits/sec
[  4]   4.16-6.21   sec  10.4 MBytes  42.7 Mbits/sec
[  4]   6.21-6.21   sec  0.00 Bytes    0.00 bits/sec
[  4]   6.21-7.35   sec  34.6 MBytes   253 Mbits/sec
[  4]   7.35-11.45  sec  22.0 MBytes  45.0 Mbits/sec
[  4]  11.45-11.45  sec  0.00 Bytes    0.00 bits/sec
[  4]  11.45-11.45  sec  0.00 Bytes    0.00 bits/sec
[  4]  11.45-11.45  sec  0.00 Bytes    0.00 bits/sec
[  4]  11.45-12.51  sec  16.0 MBytes   126 Mbits/sec
[  4]  12.51-13.59  sec  20.3 MBytes   158 Mbits/sec
[  4]  13.59-14.65  sec  13.4 MBytes   107 Mbits/sec
[  4]  14.65-16.79  sec  33.3 MBytes   130 Mbits/sec
[  4]  16.79-16.79  sec  0.00 Bytes    0.00 bits/sec
[  4]  16.79-17.82  sec  5.94 MBytes  48.7 Mbits/sec
(etc)

[root@Lab200slot2 ~]#  iperf3 --sctp -6 -c 2001:db8:0:f101::1 -V -l 1400 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 19:08:41 GMT
Connecting to host 2001:db8:0:f101::1, port 5201
      Cookie: Lab200slot2.1397243321.714295.2b3f7c
[  4] local 2001:db8:0:f101::2 port 55804 connected to 2001:db8:0:f101::1 port 5201
Starting Test: protocol: SCTP, 1 streams, 1400 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   169 MBytes  1.42 Gbits/sec
[  4]   1.00-2.00   sec   201 MBytes  1.69 Gbits/sec
[  4]   2.00-3.00   sec   188 MBytes  1.58 Gbits/sec
[  4]   3.00-4.00   sec   174 MBytes  1.46 Gbits/sec
[  4]   4.00-5.00   sec   165 MBytes  1.39 Gbits/sec
[  4]   5.00-6.00   sec   199 MBytes  1.67 Gbits/sec
[  4]   6.00-7.00   sec   163 MBytes  1.36 Gbits/sec
[  4]   7.00-8.00   sec   174 MBytes  1.46 Gbits/sec
[  4]   8.00-9.00   sec   193 MBytes  1.62 Gbits/sec
[  4]   9.00-10.00  sec   196 MBytes  1.65 Gbits/sec
[  4]  10.00-11.00  sec   157 MBytes  1.31 Gbits/sec
[  4]  11.00-12.00  sec   175 MBytes  1.47 Gbits/sec
[  4]  12.00-13.00  sec   192 MBytes  1.61 Gbits/sec
[  4]  13.00-14.00  sec   199 MBytes  1.67 Gbits/sec
(etc)

After patch:

[root@Lab200slot2 ~]#  iperf3 --sctp -4 -c 192.168.240.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0+ #1 SMP Mon Apr 14 12:06:40 EDT 2014 x86_64
Time: Mon, 14 Apr 2014 16:40:48 GMT
Connecting to host 192.168.240.3, port 5201
      Cookie: Lab200slot2.1397493648.413274.65e131
[  4] local 192.168.240.2 port 50548 connected to 192.168.240.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   240 MBytes  2.02 Gbits/sec
[  4]   1.00-2.00   sec   239 MBytes  2.01 Gbits/sec
[  4]   2.00-3.00   sec   240 MBytes  2.01 Gbits/sec
[  4]   3.00-4.00   sec   239 MBytes  2.00 Gbits/sec
[  4]   4.00-5.00   sec   245 MBytes  2.05 Gbits/sec
[  4]   5.00-6.00   sec   240 MBytes  2.01 Gbits/sec
[  4]   6.00-7.00   sec   240 MBytes  2.02 Gbits/sec
[  4]   7.00-8.00   sec   239 MBytes  2.01 Gbits/sec

With the reverted patch applied, the SCTP/IPv4 performance is back
to normal on latest upstream for IPv4 and IPv6 and has same throughput
as 3.4.2 test kernel, steady and interval reports are smooth again.

Fixes: ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer")
Reported-by: Peter Butler <pbutler@sonusnet.com>
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Peter Butler <pbutler@sonusnet.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agocxgb4: Save the correct mac addr for hw-loopback connections in the L2T
Steve Wise [Mon, 14 Apr 2014 19:22:43 +0000 (14:22 -0500)]
cxgb4: Save the correct mac addr for hw-loopback connections in the L2T

Hardware needs the local device mac address to support hw loopback for
rdma loopback connections.

Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agonet: filter: seccomp: fix wrong decoding of BPF_S_ANC_SECCOMP_LD_W
Daniel Borkmann [Mon, 14 Apr 2014 19:20:12 +0000 (21:20 +0200)]
net: filter: seccomp: fix wrong decoding of BPF_S_ANC_SECCOMP_LD_W

While reviewing seccomp code, we found that BPF_S_ANC_SECCOMP_LD_W has
been wrongly decoded by commit a8fc927780 ("sk-filter: Add ability to
get socket filter program (v2)") into the opcode BPF_LD|BPF_B|BPF_ABS
although it should have been decoded as BPF_LD|BPF_W|BPF_ABS.

In practice, this should not have much side-effect though, as such
conversion is/was being done through prctl(2) PR_SET_SECCOMP. Reverse
operation PR_GET_SECCOMP will only return the current seccomp mode, but
not the filter itself. Since the transition to the new BPF infrastructure,
it's also not used anymore, so we can simply remove this as it's
unreachable.

Fixes: a8fc927780 ("sk-filter: Add ability to get socket filter program (v2)")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agoseccomp: fix populating a0-a5 syscall args in 32-bit x86 BPF
Daniel Borkmann [Mon, 14 Apr 2014 19:02:59 +0000 (21:02 +0200)]
seccomp: fix populating a0-a5 syscall args in 32-bit x86 BPF

Linus reports that on 32-bit x86 Chromium throws the following seccomp
resp. audit log messages:

  audit: type=1326 audit(1397359304.356:28108): auid=500 uid=500
gid=500 ses=2 subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023
pid=3677 comm="chrome" exe="/opt/google/chrome/chrome" sig=0
syscall=172 compat=0 ip=0xb2dd9852 code=0x30000

  audit: type=1326 audit(1397359304.356:28109): auid=500 uid=500
gid=500 ses=2 subj=unconfined_u:unconfined_r:chrome_sandbox_t:s0-s0:c0.c1023
pid=3677 comm="chrome" exe="/opt/google/chrome/chrome" sig=0 syscall=5
compat=0 ip=0xb2dd9852 code=0x50000

These audit messages are being triggered via audit_seccomp() through
__secure_computing() in seccomp mode (BPF) filter with seccomp return
codes 0x30000 (== SECCOMP_RET_TRAP) and 0x50000 (== SECCOMP_RET_ERRNO)
during filter runtime. Moreover, Linus reports that x86_64 Chromium
seems fine.

The underlying issue that explains this is that the implementation of
populate_seccomp_data() is wrong. Our seccomp data structure sd that
is being shared with user ABI is:

  struct seccomp_data {
    int nr;
    __u32 arch;
    __u64 instruction_pointer;
    __u64 args[6];
  };

Therefore, a simple cast to 'unsigned long *' for storing the value of
the syscall argument via syscall_get_arguments() is just wrong as on
32-bit x86 (or any other 32bit arch), it would result in storing a0-a5
at wrong offsets in args[] member, and thus i) could leak stack memory
to user space and ii) tampers with the logic of seccomp BPF programs
that read out and check for syscall arguments:

  syscall_get_arguments(task, regs, 0, 1, (unsigned long *) &sd->args[0]);

Tested on 32-bit x86 with Google Chrome, unfortunately only via remote
test machine through slow ssh X forwarding, but it fixes the issue on
my side. So fix it up by storing args in type correct variables, gcc
is clever and optimizes the copy away in other cases, e.g. x86_64.

Fixes: bd4cf0ed331a ("net: filter: rework/optimize internal BPF interpreter's instruction set")
Reported-and-bisected-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Paris <eparis@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
10 years agowl18xx: align event mailbox with current fw
Eliad Peller [Sun, 13 Apr 2014 13:33:51 +0000 (16:33 +0300)]
wl18xx: align event mailbox with current fw

Some fields are missing from the event mailbox
struct definitions, which cause issues when
trying to handle some events.

Add the missing fields in order to align the
struct size (without adding actual support
for the new fields).

Reported-and-tested-by: Imre Kaloz <kaloz@openwrt.org>
Cc: stable@vger.kernel.org # 3.14+
Fixes: 028e724 ("wl18xx: move to new firmware (wl18xx-fw-3.bin)")
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
10 years agorsi: Fix a potential memory leak in rsi_send_auto_rate_request()
Christian Engelmayer [Thu, 10 Apr 2014 18:37:53 +0000 (20:37 +0200)]
rsi: Fix a potential memory leak in rsi_send_auto_rate_request()

Fix a potential memory leak in the error path of function
rsi_send_auto_rate_request(). In case memory allocation for array
'selected_rates' fails, the error path exits and leaves the previously
allocated skb in place. Detected by Coverity: CID 1195575.

Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
10 years agocw1200: Fix cw1200_debug_link_id
Frederic Danis [Thu, 10 Apr 2014 09:36:38 +0000 (11:36 +0200)]
cw1200: Fix cw1200_debug_link_id

This array is used in debug string to display cw1200_link_status
defined in drivers/net/wireless/cw1200/cw1200.h.

Add missing strings for CW1200_LINK_RESET and CW1200_LINK_RESET_REMAP.

Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
10 years agowlcore: ignore dummy packet events in PLT mode
Luciano Coelho [Thu, 10 Apr 2014 07:01:37 +0000 (10:01 +0300)]
wlcore: ignore dummy packet events in PLT mode

Sometimes the firmware sends a dummy packet event while we are in PLT
mode.  This doesn't make sense, it's a firmware bug.  Fix this by
ignoring dummy packet events when we're PLT mode.

Reported-by: Yegor Yefremov <yegorslists@googlemail.com>
Reported-by: Arik Nemtsov <arik@wizery.com>
Signed-off-by: Luciano Coelho <luca@coelho.fi>
Signed-off-by: John W. Linville <linville@tuxdriver.com>