Florian Fainelli [Wed, 1 Mar 2017 18:32:57 +0000 (10:32 -0800)]
pinctrl: Really force states during suspend/resume
[ Upstream commit
981ed1bfbc6c4660b2ddaa8392893e20a6255048 ]
In case a platform only defaults a "default" set of pins, but not a
"sleep" set of pins, and this particular platform suspends and resumes
in a way that the pin states are not preserved by the hardware, when we
resume, we would call pinctrl_single_resume() -> pinctrl_force_default()
-> pinctrl_select_state() and the first thing we do is check that the
pins state is the same as before, and do nothing.
In order to fix this, decouple the actual state change from
pinctrl_select_state() and move it pinctrl_commit_state(), while keeping
the p->state == state check in pinctrl_select_state() not to change the
caller assumptions. pinctrl_force_sleep() and pinctrl_force_default()
are updated to bypass the state check by calling pinctrl_commit_state().
[Linus Walleij]
The forced pin control states are currently only used in some pin
controller drivers that grab their own reference to their own pins.
This is equal to the pin control hogs: pins taken by pin control
devices since there are no corresponding device in the Linux device
hierarchy, such as memory controller lines or unused GPIO lines,
or GPIO lines that are used orthogonally from the GPIO subsystem
but pincontrol-wise managed as hogs (non-strict mode, allowing
simultaneous use by GPIO and pin control). For this case forcing
the state from the drivers' suspend()/resume() callbacks makes
sense and should semantically match the name of the function.
Fixes:
6e5e959dde0d ("pinctrl: API changes to support multiple states per device")
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robert Walker [Mon, 18 Dec 2017 18:05:44 +0000 (11:05 -0700)]
coresight: Fix disabling of CoreSight TPIU
[ Upstream commit
11595db8e17faaa05fadc25746c870e31276962f ]
The CoreSight TPIU should be disabled when tracing to other sinks to allow
them to operate at full bandwidth.
This patch fixes tpiu_disable_hw() to correctly disable the TPIU by
configuring the TPIU to stop on flush, initiating a manual flush, waiting
for the flush to complete and then waits for the TPIU to indicate it has
stopped.
Signed-off-by: Robert Walker <robert.walker@arm.com>
Tested-by: Mike Leach <mike.leach@linaro.org>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sahara [Wed, 13 Dec 2017 05:10:48 +0000 (09:10 +0400)]
pty: cancel pty slave port buf's work in tty_release
[ Upstream commit
2b022ab7542df60021ab57854b3faaaf42552eaf ]
In case that CONFIG_SLUB_DEBUG is on and pty is used, races between
release_one_tty and flush_to_ldisc work threads may happen and lead
to use-after-free condition on tty->link->port. Because SLUB_DEBUG
is turned on, freed tty->link->port is filled with POISON_FREE value.
So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc
could return without a problem by checking if tty is NULL.
CPU 0 CPU 1
----- -----
release_tty pty_write
cancel_work_sync(tty) to = tty->link
tty_kref_put(tty->link) tty_schedule_flip(to->port)
<< workqueue >> ...
release_one_tty ...
pty_cleanup ...
kfree(tty->link->port) << workqueue >>
flush_to_ldisc
tty = READ_ONCE(port->itty)
tty is 0x6b6b6b6b6b6b6b6b
!!PANIC!! access tty->ldisc
Unable to handle kernel paging request at virtual address
6b6b6b6b6b6b6b93
pgd =
ffffffc0eb1c3000
[
6b6b6b6b6b6b6b93] *pgd=
0000000000000000, *pud=
0000000000000000
------------[ cut here ]------------
Kernel BUG at
ffffff800851154c [verbose debug info unavailable]
Internal error: Oops - BUG:
96000004 [#1] PREEMPT SMP
CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G W 3.18.31-g0a58eeb #1
Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT)
Workqueue: events_unbound flush_to_ldisc
task:
ffffffc0ed610ec0 ti:
ffffffc0ed624000 task.ti:
ffffffc0ed624000
PC is at ldsem_down_read_trylock+0x0/0x4c
LR is at tty_ldisc_ref+0x24/0x4c
pc : [<
ffffff800851154c>] lr : [<
ffffff800850f6c0>] pstate:
80400145
sp :
ffffffc0ed627cd0
x29:
ffffffc0ed627cd0 x28:
0000000000000000
x27:
ffffff8009e05000 x26:
ffffffc0d382cfa0
x25:
0000000000000000 x24:
ffffff800a012f08
x23:
0000000000000000 x22:
ffffffc0703fbc88
x21:
6b6b6b6b6b6b6b6b x20:
6b6b6b6b6b6b6b93
x19:
0000000000000000 x18:
0000000000000001
x17:
00e80000f80d6f53 x16:
0000000000000001
x15:
0000007f7d826fff x14:
00000000000000a0
x13:
0000000000000000 x12:
0000000000000109
x11:
0000000000000000 x10:
0000000000000000
x9 :
ffffffc0ed624000 x8 :
ffffffc0ed611580
x7 :
0000000000000000 x6 :
ffffff800a42e000
x5 :
00000000000003fc x4 :
0000000003bd1201
x3 :
0000000000000001 x2 :
0000000000000001
x1 :
ffffff800851004c x0 :
6b6b6b6b6b6b6b93
Signed-off-by: Sahara <keun-o.park@darkmatter.ae>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Ujfalusi [Fri, 29 Sep 2017 11:49:49 +0000 (14:49 +0300)]
drm/omap: DMM: Check for DMM readiness after successful transaction commit
[ Upstream commit
b7ea6b286c4051e043f691781785e3c4672f014a ]
Check the status of the DMM engine after it is reported that the
transaction was completed as in rare cases the engine might not reached a
working state.
The wait_status() will print information in case the DMM is not reached the
expected state and the dmm_txn_commit() will return with an error code to
make sure that we are not continuing with a broken setup.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
H. Nikolaus Schaller [Tue, 28 Nov 2017 15:48:54 +0000 (16:48 +0100)]
omapdrm: panel: fix compatible vendor string for td028ttec1
[ Upstream commit
c1b9d4c75cd549e08bd0596d7f9dcc20f7f6e8fa ]
The vendor name was "toppoly" but other panels and the vendor list
have defined it as "tpo". So let's fix it in driver and bindings.
We keep the old definition in parallel to stay compatible with
potential older DTB setup.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjorn Helgaas [Fri, 1 Dec 2017 17:06:39 +0000 (11:06 -0600)]
vgacon: Set VGA struct resource types
[ Upstream commit
c82084117f79bcae085e40da526253736a247120 ]
Set the resource type when we reserve VGA-related I/O port resources.
The resource code doesn't actually look at the type, so it inserts
resources without a type in the tree correctly even without this change.
But if we ever print a resource without a type, it looks like this:
vga+ [??? 0x000003c0-0x000003df flags 0x0]
Setting the type means it will be printed correctly as:
vga+ [io 0x000003c0-0x000003df]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bharat Potnuri [Tue, 28 Nov 2017 18:28:07 +0000 (23:58 +0530)]
iser-target: avoid reinitializing rdma contexts for isert commands
[ Upstream commit
66f53e6f5400578bae58db0c06d85a8820831f40 ]
isert commands that failed during isert_rdma_rw_ctx_post() are queued to
Queue-Full(QF) queue and are scheduled to be reposted during queue-full
queue processing. During this reposting, the rdma contexts are initialised
again in isert_rdma_rw_ctx_post(), which is leaking significant memory.
unreferenced object 0xffff8830201d9640 (size 64):
comm "kworker/0:2", pid 195, jiffies
4295374851 (age 4528.436s)
hex dump (first 32 bytes):
00 60 8b cb 2e 00 00 00 00 10 00 00 00 00 00 00 .`..............
00 90 e3 cb 2e 00 00 00 00 10 00 00 00 00 00 00 ................
backtrace:
[<
ffffffff8170711e>] kmemleak_alloc+0x4e/0xb0
[<
ffffffff811f8ba5>] __kmalloc+0x125/0x2b0
[<
ffffffffa046b24f>] rdma_rw_ctx_init+0x15f/0x6f0 [ib_core]
[<
ffffffffa07ab644>] isert_rdma_rw_ctx_post+0xc4/0x3c0 [ib_isert]
[<
ffffffffa07ad972>] isert_put_datain+0x112/0x1c0 [ib_isert]
[<
ffffffffa07dddce>] lio_queue_data_in+0x2e/0x30 [iscsi_target_mod]
[<
ffffffffa076c322>] target_qf_do_work+0x2b2/0x4b0 [target_core_mod]
[<
ffffffff81080c3b>] process_one_work+0x1db/0x5d0
[<
ffffffff8108107d>] worker_thread+0x4d/0x3e0
[<
ffffffff81088667>] kthread+0x117/0x150
[<
ffffffff81713fa7>] ret_from_fork+0x27/0x40
[<
ffffffffffffffff>] 0xffffffffffffffff
Here is patch to use the older rdma contexts while reposting
the isert commands intead of reinitialising them.
Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Artemy Kovalyov [Tue, 14 Nov 2017 12:51:59 +0000 (14:51 +0200)]
IB/umem: Fix use of npages/nmap fields
[ Upstream commit
edf1a84fe37c51290e2c88154ecaf48dadff3d27 ]
In ib_umem structure npages holds original number of sg entries, while
nmap is number of DMA blocks returned by dma_map_sg.
Fixes:
c5d76f130b28 ('IB/core: Add umem function to read data from user-space')
Signed-off-by: Artemy Kovalyov <artemyko@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Parav Pandit [Tue, 14 Nov 2017 12:51:55 +0000 (14:51 +0200)]
RDMA/cma: Use correct size when writing netlink stats
[ Upstream commit
7baaa49af3716fb31877c61f59b74d029ce15b75 ]
The code was using the src size when formatting the dst. They are almost
certainly the same value but it reads wrong.
Fixes:
ce117ffac2e9 ("RDMA/cma: Export AF_IB statistics")
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Erez Shitrit [Tue, 14 Nov 2017 12:51:53 +0000 (14:51 +0200)]
IB/ipoib: Avoid memory leak if the SA returns a different DGID
[ Upstream commit
439000892ee17a9c92f1e4297818790ef8bb4ced ]
The ipoib path database is organized around DGIDs from the LLADDR, but the
SA is free to return a different GID when asked for path. This causes a
bug because the SA's modified DGID is copied into the database key, even
though it is no longer the correct lookup key, causing a memory leak and
other malfunctions.
Ensure the database key does not change after the SA query completes.
Demonstration of the bug is as follows
ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it
creates new record in the DB with that gid as a key, and issues a new
request to the SM.
Now, the SM from some reason returns path-record with other SGID (for
example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local
subnet prefix) now ipoib will overwrite the current entry with the new
one, and if new request to the original GID arrives ipoib will not find
it in the DB (was overwritten) and will create new record that in its
turn will also be overwritten by the response from the SM, and so on
till the driver eats all the device memory.
Signed-off-by: Erez Shitrit <erezsh@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Drake [Tue, 12 Dec 2017 10:49:02 +0000 (10:49 +0000)]
mmc: avoid removing non-removable hosts during suspend
[ Upstream commit
de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ]
The Weibu F3C MiniPC has an onboard AP6255 module, presenting
two SDIO functions on a single MMC host (Bluetooth/btsdio and
WiFi/brcmfmac), and the mmc layer correctly detects this as
non-removable.
After suspend/resume, the wifi and bluetooth interfaces disappear
and do not get probed again.
The conditions here are:
1. During suspend, we reach mmc_pm_notify()
2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can
suspend the SDIO host. However, mmc_sdio_pre_suspend() returns
-ENOSYS because btsdio_driver does not have a suspend method.
3. mmc_pm_notify() proceeds to remove the card
4. Upon resume, mmc_rescan() does nothing with this host, because of
the rescan_entered check which aims to only scan a non-removable
device a single time (i.e. during boot).
Fix the loss of functionality by detecting that we are unable to
suspend a non-removable host, so avoid the forced removal in that
case. The comment above this function already indicates that this
code was only intended for removable devices.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Logan Gunthorpe [Tue, 5 Dec 2017 23:30:51 +0000 (16:30 -0700)]
drm/tilcdc: ensure nonatomic iowrite64 is not used
[ Upstream commit
4e5ca2d930aa8714400aedf4bf1dc959cb04280f ]
Add a check to ensure iowrite64 is only used if it is atomic.
It was decided in [1] that the tilcdc driver should not be using an
atomic operation (so it was left out of this patchset). However, it turns
out that through the drm code, a nonatomic header is actually included:
include/linux/io-64-nonatomic-lo-hi.h
is included from include/drm/drm_os_linux.h:9:0,
from include/drm/drmP.h:74,
from include/drm/drm_modeset_helper.h:26,
from include/drm/drm_atomic_helper.h:33,
from drivers/gpu/drm/tilcdc/tilcdc_crtc.c:19:
And thus, without this change, this patchset would inadvertantly
change the behaviour of the tilcdc driver.
[1] lkml.kernel.org/r/CAK8P3a2HhO_zCnsTzq7hmWSz5La5Thu19FWZpun16iMnyyNreQ@mail.gmail.com
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kedareswara rao Appana [Thu, 7 Dec 2017 05:24:28 +0000 (10:54 +0530)]
dmaengine: zynqmp_dma: Fix race condition in the probe
[ Upstream commit
5ba080aada5e739165e0f38d5cc3b04c82b323c8 ]
Incase of interrupt property is not present,
Driver is trying to free an invalid irq,
This patch fixes it by adding a check before freeing the irq.
Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shawn Nematbakhsh [Fri, 8 Sep 2017 20:50:11 +0000 (13:50 -0700)]
platform/chrome: Use proper protocol transfer function
[ Upstream commit
d48b8c58c57f6edbe2965f0a5f62c5cf9593ca96 ]
pkt_xfer should be used for protocol v3, and cmd_xfer otherwise. We had
one instance of these functions correct, but not the second, fall-back
case. We use the fall-back only when the first command returns an
IN_PROGRESS status, which is only used on some EC firmwares where we
don't want to constantly poll the bus, but instead back off and
sleep/retry for a little while.
Fixes:
2c7589af3c4d ("mfd: cros_ec: add proto v3 skeleton")
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guenter Roeck [Mon, 25 Sep 2017 16:17:01 +0000 (09:17 -0700)]
watchdog: Fix potential kref imbalance when opening watchdog
[ Upstream commit
4bcd615fad6adddc68b058d498b30a9e0e0db77a ]
If a watchdog driver's open function sets WDOG_HW_RUNNING with the
expectation that the watchdog can not be stopped, but then stops the
watchdog anyway in its stop function, kref_get() wil not be called in
watchdog_open(). If the watchdog then stops on close, WDOG_HW_RUNNING
will be cleared and kref_put() will be called, causing a kref imbalance.
As result the character device data structure will be released, which in
turn will cause the system to crash on the next call to watchdog_open().
Fixes:
ee142889e32f5 ("watchdog: Introduce WDOG_HW_RUNNING flag")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arnd Bergmann [Mon, 4 Dec 2017 14:49:48 +0000 (15:49 +0100)]
cros_ec: fix nul-termination for firmware build info
[ Upstream commit
50a0d71a5d20e1d3eff1d974fdc8559ad6d74892 ]
As gcc-8 reports, we zero out the wrong byte:
drivers/platform/chrome/cros_ec_sysfs.c: In function 'show_ec_version':
drivers/platform/chrome/cros_ec_sysfs.c:190:12: error: array subscript
4294967295 is above array bounds of 'uint8_t[]' [-Werror=array-bounds]
This changes the code back to what it did before changing to a
zero-length array structure.
Fixes:
a841178445bb ("mfd: cros_ec: Use a zero-length array for command data")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Potyra [Wed, 6 Dec 2017 15:46:12 +0000 (16:46 +0100)]
serial: 8250_dw: Disable clock on error
[ Upstream commit
8af016aa5a27c6a2505460eb4d83f1e70c38dc43 ]
If there is no clock rate for uartclk defined, disable the previously
enabled clock again.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes:
23f5b3fdd04e serial: 8250_dw: only get the clock rate in one place
Signed-off-by: Stefan Potyra <Stefan.Potyra@elektrobit.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bjørn Mork [Thu, 14 Dec 2017 18:55:50 +0000 (19:55 +0100)]
qmi_wwan: set FLAG_SEND_ZLP to avoid network initiated disconnect
[ Upstream commit
245d21190aec547c0de64f70c0e6de871c185a24 ]
It has been reported that the dummy byte we add to avoid
ZLPs can be forwarded by the modem to the PGW/GGSN, and that
some operators will drop the connection if this happens.
In theory, QMI devices are based on CDC ECM and should as such
both support ZLPs and silently ignore the dummy byte. The latter
assumption failed. Let's test out the first.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ron Economos [Tue, 12 Dec 2017 00:51:53 +0000 (19:51 -0500)]
media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart
[ Upstream commit
380a6c86457573aa42d27ae11e025eb25941a0b7 ]
On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart.
Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem.
Signed-off-by: Ron Economos <w6rz@comcast.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Balaji Pothunoori [Thu, 7 Dec 2017 14:58:04 +0000 (16:58 +0200)]
ath10k: handling qos at STA side based on AP WMM enable/disable
[ Upstream commit
07ffb4497360ae8789f05555fec8171ee952304d ]
Data packets are not sent by STA in case of STA joined to
non QOS AP (WMM disabled AP). This is happening because of STA
is sending data packets to firmware from host with qos enabled
along with non qos queue value(TID = 16).
Due to qos enabled, firmware is discarding the packet.
This patch fixes this issue by updating the qos based on station
WME capability field if WMM is disabled in AP.
This patch is required by 10.4 family chipsets like
QCA4019/QCA9888/QCA9884/QCA99X0.
Firmware Versoin : 10.4-3.5.1-00018.
For 10.2.4 family chipsets QCA988X/QCA9887 and QCA6174 this patch
has no effect.
Signed-off-by: Balaji Pothunoori <bpothuno@qti.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Thu, 21 Sep 2017 23:23:56 +0000 (19:23 -0400)]
media: bt8xx: Fix err 'bt878_probe()'
[ Upstream commit
45392ff6881dbe56d41ef0b17c2e576065f8ffa1 ]
This is odd to call 'pci_disable_device()' in an error path before a
coresponding successful 'pci_enable_device()'.
Return directly instead.
Fixes:
77e0be12100a ("V4L/DVB (4176): Bug-fix: Fix memory overflow")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tsang-Shian Lin [Sat, 9 Dec 2017 17:37:10 +0000 (11:37 -0600)]
rtlwifi: rtl_pci: Fix the bug when inactiveps is enabled.
[ Upstream commit
b7573a0a27bfa8270dea9b145448f6884b7cacc1 ]
Reset the driver current tx read/write index to zero when inactiveps
nic out of sync with HW state. Wrong driver tx read/write index will
cause Tx fail.
Signed-off-by: Tsang-Shian Lin <thlin@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Yan-Hsuan Chuang <yhchuang@realtek.com>
Cc: Birming Chiu <birming@realtek.com>
Cc: Shaofu <shaofu@realtek.com>
Cc: Steven Ting <steventing@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Geert Uytterhoeven [Wed, 29 Nov 2017 08:47:33 +0000 (09:47 +0100)]
RDMA/iwpm: Fix uninitialized error code in iwpm_send_mapinfo()
[ Upstream commit
302d6424e4a293a5761997e6c9fc3dfb1e4c355f ]
With gcc-4.1.2:
drivers/infiniband/core/iwpm_util.c: In function ‘iwpm_send_mapinfo’:
drivers/infiniband/core/iwpm_util.c:647: warning: ‘ret’ may be used uninitialized in this function
Indeed, if nl_client is not found in any of the scanned has buckets, ret
will be used uninitialized.
Preinitialize ret to -EINVAL to fix this.
Fixes:
30dc5e63d6a5ad24 ("RDMA/core: Add support for iWARP Port Mapper user space service")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Tatyana Nikolova <tatyana.e.nikolova@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Prakash Kamliya [Mon, 4 Dec 2017 13:40:15 +0000 (19:10 +0530)]
drm/msm: fix leak in failed get_pages
[ Upstream commit
62e3a3e342af3c313ab38603811ecdb1fcc79edb ]
get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.
Signed-off-by: Prakash Kamliya <pkamliya@codeaurora.org>
Signed-off-by: Sharat Masetty <smasetty@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gustavo A. R. Silva [Mon, 20 Nov 2017 14:00:55 +0000 (09:00 -0500)]
media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt
[ Upstream commit
baed3c4bc4c13de93e0dba0a26d601411ebcb389 ]
_channel_ is being dereferenced before it is null checked, hence there is a
potential null pointer dereference. Fix this by moving the pointer dereference
after _channel_ has been null checked.
This issue was detected with the help of Coccinelle.
Fixes:
c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Acked-by: Patrice Chotard <patrice.chotard@st.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Loic Poulain [Wed, 22 Nov 2017 14:03:17 +0000 (15:03 +0100)]
Bluetooth: btqcomsmd: Fix skb double free corruption
[ Upstream commit
67b8fbead4685b36d290a0ef91c6ddffc4920ec9 ]
In case of hci send frame failure, skb is still owned
by the caller (hci_core) and then should not be freed.
This fixes crash on dragonboard-410c when sending SCO
packet. skb is freed by both btqcomsmd and hci_core.
Fixes:
1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Loic Poulain [Mon, 6 Nov 2017 11:16:56 +0000 (12:16 +0100)]
Bluetooth: hci_qca: Avoid setup failure on missing rampatch
[ Upstream commit
ba8f3597900291a93604643017fff66a14546015 ]
Assuming that the original code idea was to enable in-band sleeping
only if the setup_rome method returns succes and run in 'standard'
mode otherwise, we should not return setup_rome return value which
makes qca_setup fail if no rampatch/nvm file found.
This fixes BT issue on the dragonboard-820C p4 which includes the
following QCA controller:
hci0: Product:0x00000008
hci0: Patch :0x00000111
hci0: ROM :0x00000302
hci0: SOC :0x00000044
Since there is no rampatch for this controller revision, just make
it work as is.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Thu, 4 May 2017 13:05:26 +0000 (15:05 +0200)]
block/mq: Cure cpu hotplug lock inversion
[ Upstream commit
eabe06595d62cfa9278e2cd012df614bc68a7042 ]
By poking at /debug/sched_features I triggered the following splat:
[] ======================================================
[] WARNING: possible circular locking dependency detected
[] 4.11.0-00873-g964c8b7-dirty #694 Not tainted
[] ------------------------------------------------------
[] bash/2109 is trying to acquire lock:
[] (cpu_hotplug_lock.rw_sem){++++++}, at: [<
ffffffff8120cb8b>] static_key_slow_dec+0x1b/0x50
[]
[] but task is already holding lock:
[] (&sb->s_type->i_mutex_key#4){+++++.}, at: [<
ffffffff81140216>] sched_feat_write+0x86/0x170
[]
[] which lock already depends on the new lock.
[]
[]
[] the existing dependency chain (in reverse order) is:
[]
[] -> #2 (&sb->s_type->i_mutex_key#4){+++++.}:
[] lock_acquire+0x100/0x210
[] down_write+0x28/0x60
[] start_creating+0x5e/0xf0
[] debugfs_create_dir+0x13/0x110
[] blk_mq_debugfs_register+0x21/0x70
[] blk_mq_register_dev+0x64/0xd0
[] blk_register_queue+0x6a/0x170
[] device_add_disk+0x22d/0x440
[] loop_add+0x1f3/0x280
[] loop_init+0x104/0x142
[] do_one_initcall+0x43/0x180
[] kernel_init_freeable+0x1de/0x266
[] kernel_init+0xe/0x100
[] ret_from_fork+0x31/0x40
[]
[] -> #1 (all_q_mutex){+.+.+.}:
[] lock_acquire+0x100/0x210
[] __mutex_lock+0x6c/0x960
[] mutex_lock_nested+0x1b/0x20
[] blk_mq_init_allocated_queue+0x37c/0x4e0
[] blk_mq_init_queue+0x3a/0x60
[] loop_add+0xe5/0x280
[] loop_init+0x104/0x142
[] do_one_initcall+0x43/0x180
[] kernel_init_freeable+0x1de/0x266
[] kernel_init+0xe/0x100
[] ret_from_fork+0x31/0x40
[] *** DEADLOCK ***
[]
[] 3 locks held by bash/2109:
[] #0: (sb_writers#11){.+.+.+}, at: [<
ffffffff81292bcd>] vfs_write+0x17d/0x1a0
[] #1: (debugfs_srcu){......}, at: [<
ffffffff8155a90d>] full_proxy_write+0x5d/0xd0
[] #2: (&sb->s_type->i_mutex_key#4){+++++.}, at: [<
ffffffff81140216>] sched_feat_write+0x86/0x170
[]
[] stack backtrace:
[] CPU: 9 PID: 2109 Comm: bash Not tainted 4.11.0-00873-g964c8b7-dirty #694
[] Hardware name: Intel Corporation S2600GZ/S2600GZ, BIOS SE5C600.86B.02.02.0002.
122320131210 12/23/2013
[] Call Trace:
[] lock_acquire+0x100/0x210
[] get_online_cpus+0x2a/0x90
[] static_key_slow_dec+0x1b/0x50
[] static_key_disable+0x20/0x30
[] sched_feat_write+0x131/0x170
[] full_proxy_write+0x97/0xd0
[] __vfs_write+0x28/0x120
[] vfs_write+0xb5/0x1a0
[] SyS_write+0x49/0xa0
[] entry_SYSCALL_64_fastpath+0x23/0xc2
This is because of the cpu hotplug lock rework. Break the chain at #1
by reversing the lock acquisition order. This way i_mutex_key#4 no
longer depends on cpu_hotplug_lock and things are good.
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kim Phillips [Wed, 3 May 2017 12:14:02 +0000 (13:14 +0100)]
perf tests kmod-path: Don't fail if compressed modules aren't supported
[ Upstream commit
805b151a1afd24414706a7f6ae275fbb9649be74 ]
__kmod_path__parse() uses is_supported_compression() to determine and
parse out compressed module file extensions. On systems without zlib,
this test fails and __kmod_path__parse() continues to strcmp "ko" with
"gz". Don't do this on those systems.
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Fixes:
3c8a67f50a1e ("perf tools: Add kmod_path__parse function")
Link: http://lkml.kernel.org/r/20170503131402.c66e314460026c80cd787b34@arm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Mera [Mon, 24 Apr 2017 07:11:57 +0000 (16:11 +0900)]
ath10k: fix out of bounds access to local buffer
[ Upstream commit
a16703aaeaedec7a8bee5be5522c7c3e75478951 ]
During write to debugfs file simulate_fw_crash, fixed-size local buffer
'buf' is accessed and modified at index 'count-1', where 'count' is the
size of the write (so potentially out of bounds).
This patch fixes this problem.
Signed-off-by: Michael Mera <dev@michaelmera.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moritz Fischer [Mon, 24 Apr 2017 22:05:12 +0000 (15:05 -0700)]
rtc: ds1374: wdt: Fix stop/start ioctl always returning -EINVAL
[ Upstream commit
538c08f4c89580fc644e2bc64e0a4b86c925da4e ]
The WDIOC_SETOPTIONS case in the watchdog ioctl would alwayss falls
through to the -EINVAL case. This is wrong since thew watchdog does
actually get stopped or started correctly.
Fixes:
920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Moritz Fischer [Mon, 24 Apr 2017 22:05:11 +0000 (15:05 -0700)]
rtc: ds1374: wdt: Fix issue with timeout scaling from secs to wdt ticks
[ Upstream commit
453d0744f6c6ca3f9749b8c57c2e85b5b9f52514 ]
The issue is that the internal counter that triggers the watchdog reset
is actually running at 4096 Hz instead of 1Hz, therefore the value
given by userland (in sec) needs to be multiplied by 4096 to get the
correct behavior.
Fixes:
920f91e50c5b ("drivers/rtc/rtc-ds1374.c: add watchdog support")
Signed-off-by: Moritz Fischer <mdf@kernel.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Naoya Horiguchi [Wed, 3 May 2017 21:56:22 +0000 (14:56 -0700)]
mm: hwpoison: call shake_page() after try_to_unmap() for mlocked page
[ Upstream commit
286c469a988fbaf68e3a97ddf1e6c245c1446968 ]
Memory error handler calls try_to_unmap() for error pages in various
states. If the error page is a mlocked page, error handling could fail
with "still referenced by 1 users" message. This is because the page is
linked to and stays in lru cache after the following call chain.
try_to_unmap_one
page_remove_rmap
clear_page_mlock
putback_lru_page
lru_cache_add
memory_failure() calls shake_page() to hanlde the similar issue, but
current code doesn't cover because shake_page() is called only before
try_to_unmap(). So this patches adds shake_page().
Fixes:
23a003bfd23ea9ea0b7756b920e51f64b284b468 ("mm/madvise: pass return code of memory_failure() to userspace")
Link: http://lkml.kernel.org/r/20170417055948.GM31394@yexl-desktop
Link: http://lkml.kernel.org/r/1493197841-23986-3-git-send-email-n-horiguchi@ah.jp.nec.com
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Xiaolong Ye <xiaolong.ye@intel.com>
Cc: Chen Gong <gong.chen@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Rientjes [Wed, 3 May 2017 21:53:02 +0000 (14:53 -0700)]
mm, vmstat: suppress pcp stats for unpopulated zones in zoneinfo
[ Upstream commit
7dfb8bf3b9caef4049bee51d2c22e1c3a311d483 ]
After "mm, vmstat: print non-populated zones in zoneinfo",
/proc/zoneinfo will show unpopulated zones.
The per-cpu pageset statistics are not relevant for unpopulated zones
and can be potentially lengthy, so supress them when they are not
interesting.
Also moves lowmem reserve protection information above pcp stats since
it is relevant for all zones per vm.lowmem_reserve_ratio.
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1703061400500.46428@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Weiner [Wed, 3 May 2017 21:51:54 +0000 (14:51 -0700)]
mm: fix check for reclaimable pages in PF_MEMALLOC reclaim throttling
[ Upstream commit
d450abd81b081d45adb12f303a07dd44b15eb1bc ]
PF_MEMALLOC direct reclaimers get throttled on a node when the sum of
all free pages in each zone fall below half the min watermark. During
the summation, we want to exclude zones that don't have reclaimables.
Checking the same pgdat over and over again doesn't make sense.
Fixes:
599d0c954f91 ("mm, vmscan: move LRU lists to node")
Link: http://lkml.kernel.org/r/20170228214007.5621-3-hannes@cmpxchg.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Jia He <hejianet@gmail.com>
Cc: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Mon, 1 May 2017 18:43:43 +0000 (21:43 +0300)]
cifs: small underflow in cnvrtDosUnixTm()
[ Upstream commit
564277eceeca01e02b1ef3e141cfb939184601b4 ]
January is month 1. There is no zero-th month. If someone passes a
zero month then it means we read from one space before the start of the
total_days_of_prev_months[] array.
We may as well also be strict about days as well.
Fixes:
1bd5bbcb6531 ("[CIFS] Legacy time handling for Win9x and OS/2 part 1")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Timmy Li [Tue, 2 May 2017 02:46:52 +0000 (10:46 +0800)]
net: hns: fix ethtool_get_strings overflow in hns driver
[ Upstream commit
412b65d15a7f8a93794653968308fc100f2aa87c ]
hns_get_sset_count() returns HNS_NET_STATS_CNT and the data space allocated
is not enough for ethtool_get_strings(), which will cause random memory
corruption.
When SLAB and DEBUG_SLAB are both enabled, memory corruptions like the
the following can be observed without this patch:
[ 43.115200] Slab corruption (Not tainted): Acpi-ParseExt start=
ffff801fb0b69030, len=80
[ 43.115206] Redzone: 0x9f911029d006462/0x5f78745f31657070.
[ 43.115208] Last user: [<
5f7272655f746b70>](0x5f7272655f746b70)
[ 43.115214] 010: 70 70 65 31 5f 74 78 5f 70 6b 74 00 6b 6b 6b 6b ppe1_tx_pkt.kkkk
[ 43.115217] 030: 70 70 65 31 5f 74 78 5f 70 6b 74 5f 6f 6b 00 6b ppe1_tx_pkt_ok.k
[ 43.115218] Next obj: start=
ffff801fb0b69098, len=80
[ 43.115220] Redzone: 0x706d655f6f666966/0x9f911029d74e35b.
[ 43.115229] Last user: [<
ffff0000084b11b0>](acpi_os_release_object+0x28/0x38)
[ 43.115231] 000: 74 79 00 6b 6b 6b 6b 6b 70 70 65 31 5f 74 78 5f ty.kkkkkppe1_tx_
[ 43.115232] 010: 70 6b 74 5f 65 72 72 5f 63 73 75 6d 5f 66 61 69 pkt_err_csum_fai
Signed-off-by: Timmy Li <lixiaoping3@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Mon, 1 May 2017 21:06:56 +0000 (17:06 -0400)]
pNFS: Fix a deadlock when coalescing writes and returning the layout
[ Upstream commit
61f454e30c18a28924e96be12592c0d5e24bcc81 ]
Consider the following deadlock:
Process P1 Process P2 Process P3
========== ========== ==========
lock_page(page)
lseg = pnfs_update_layout(inode)
lo = NFS_I(inode)->layout
pnfs_error_mark_layout_for_return(lo)
lock_page(page)
lseg = pnfs_update_layout(inode)
In this scenario,
- P1 has declared the layout to be in error, but P2 holds a reference to
a layout segment on that inode, so the layoutreturn is deferred.
- P2 is waiting for a page lock held by P3.
- P3 is asking for a new layout segment, but is blocked waiting
for the layoutreturn.
The fix is to ensure that pnfs_error_mark_layout_for_return() does
not set the NFS_LAYOUT_RETURN flag, which blocks P3. Instead, we allow
the latter to call LAYOUTGET so that it can make progress and unblock
P2.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Khoroshilov [Tue, 2 May 2017 11:47:53 +0000 (13:47 +0200)]
sm501fb: don't return zero on failure path in sm501fb_start()
[ Upstream commit
dc85e9a87420613b3129d5cc5ecd79c58351c546 ]
If fbmem iomemory mapping failed, sm501fb_start() breaks off
initialization, deallocates resources, but returns zero.
As a result, double deallocation can happen in sm501fb_stop().
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maksim Salau [Tue, 2 May 2017 11:47:53 +0000 (13:47 +0200)]
video: fbdev: udlfb: Fix buffer on stack
[ Upstream commit
45f580c42e5c125d55dbd8099750a1998de3d917 ]
Allocate buffers on HEAP instead of STACK for local array
that is to be sent using usb_control_msg().
Signed-off-by: Maksim Salau <maksim.salau@gmail.com>
Cc: Bernie Thompson <bernie@plugable.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vitaly Kuznetsov [Tue, 14 Mar 2017 17:35:43 +0000 (18:35 +0100)]
x86/xen: split xen_smp_prepare_boot_cpu()
[ Upstream commit
a2d1078a35f9a38ae888aa6147e4ca32666154a1 ]
Split xen_smp_prepare_boot_cpu() into xen_pv_smp_prepare_boot_cpu() and
xen_hvm_smp_prepare_boot_cpu() to support further splitting of smp.c.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Monakhov [Fri, 31 Mar 2017 15:53:35 +0000 (19:53 +0400)]
tcm_fileio: Prevent information leak for short reads
[ Upstream commit
f11b55d13563e9428c88c873f4f03a6bef11ec0a ]
If we failed to read data from backing file (probably because some one
truncate file under us), we must zerofill cmd's data, otherwise it will
be returned as is. Most likely cmd's data are unitialized pages from
page cache. This result in information leak.
(Change BUG_ON into -EINVAL se_cmd failure - nab)
testcase: https://github.com/dmonakhov/xfstests/commit/
e11a1b7b907ca67b1be51a1594025600767366d5
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Trofimovich [Mon, 1 May 2017 18:51:55 +0000 (11:51 -0700)]
ia64: fix module loading for gcc-5.4
[ Upstream commit
a25fb8508c1b80dce742dbeaa4d75a1e9f2c5617 ]
Starting from gcc-5.4+ gcc generates MLX instructions in more cases to
refer local symbols:
https://gcc.gnu.org/PR60465
That caused ia64 module loader to choke on such instructions:
fuse: invalid slot number 1 for IMM64
The Linux kernel used to handle only case where relocation pointed to
slot=2 instruction in the bundle. That limitation was fixed in linux by
commit
9c184a073bfd ("[IA64] Fix 2.6 kernel for the new ia64 assembler")
See
http://sources.redhat.com/bugzilla/show_bug.cgi?id=1433
This change lifts the slot=2 restriction from the kernel module loader.
Tested on 'fuse' and 'btrfs' kernel modules.
Cc: Markus Elfring <elfring@users.sourceforge.net>
Cc: H J Lu <hjl.tools@gmail.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Bug: https://bugs.gentoo.org/601014
Tested-by: Émeric MASCHINO <emeric.maschino@gmail.com>
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Sun, 30 Apr 2017 20:54:16 +0000 (22:54 +0200)]
ACPI / power: Delay turning off unused power resources after suspend
[ Upstream commit
8ece1d83346bcc431090d59a2184276192189cdd ]
Commit
660b1113e0f3 (ACPI / PM: Fix consistency check for power resources
during resume) introduced a check for ACPI power resources which have
been turned on by the BIOS during suspend and turns these back off again.
This is causing problems on a Dell Venue Pro 11 7130 (i5-4300Y) it causes
the following messages to show up in dmesg:
[ 131.014605] ACPI: Waking up from system sleep state S3
[ 131.150271] acpi LNXPOWER:07: Turning OFF
[ 131.150323] acpi LNXPOWER:06: Turning OFF
[ 131.150911] acpi LNXPOWER:00: Turning OFF
[ 131.169014] ACPI : EC: interrupt unblocked
[ 131.181811] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 133.535728] pci_raw_set_power_state: 76 callbacks suppressed
[ 133.535735] iwlwifi 0000:01:00.0: Refused to change power state,
currently in D3
[ 133.597672] PM: noirq resume of devices complete after 2428.891 msecs
Followed by a bunch of iwlwifi errors later on and the pcie device
dropping from the bus (acpiphp thinks it has been unplugged).
Disabling the turning off of unused power resources fixes this. Instead
of adding a quirk for this system, this commit fixes this by moving the
disabling of unused power resources to later in the resume sequence
when the iwlwifi card has been moved out of D3 so the ref_count for
its power resource no longer is 0.
This new behavior seems to match the intend of the original commit which
commit-msg says: "(... which means that no devices are going to need them
any time soon) and we should turn them off".
This also avoids power resources which we need when bringing devices out
of D3 from getting bounced off and then back on again.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shaohua Li [Mon, 1 May 2017 19:15:07 +0000 (12:15 -0700)]
md/raid10: skip spare disk as 'first' disk
[ Upstream commit
b506335e5d2b4ec687dde392a3bdbf7601778f1d ]
Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores
a case in reshape, the first rdev could be a spare disk, which shouldn't
be accounted as the first disk since it doesn't include the offset info.
Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop)
Cc: Guoqing Jiang <gqjiang@suse.com>
Cc: NeilBrown <neilb@suse.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Thu, 6 Apr 2017 12:49:44 +0000 (14:49 +0200)]
IB/rxe: Don't clamp residual length to mtu
[ Upstream commit
d52418502e288b5c7e9e2e6cf1de5f1d3d79d2e1 ]
When reading a RDMA WRITE FIRST packet we copy the DMA length from the RDMA
header into the qp->resp.resid variable for later use. Later in check_rkey()
we clamp it to the MTU if the packet is an RDMA WRITE packet and has a
residual length bigger than the MTU. Later in write_data_in() we subtract the
payload of the packet from the residual length. If the packet happens to have a
payload of exactly the MTU size we end up with a residual length of 0 despite
the packet not being the last in the conversation. When the next packet in the
conversation arrives, we don't have any residual length left and thus set the QP
into an error state.
This broke NVMe over Fabrics functionality over rdma_rxe.ko
The patch was verified using the following test.
# echo eth0 > /sys/module/rdma_rxe/parameters/add
# nvme connect -t rdma -a 192.168.155.101 -s 1023 -n nvmf-test
# mkfs.xfs -fK /dev/nvme0n1
meta-data=/dev/nvme0n1 isize=256 agcount=4, agsize=65536 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=0 finobt=0, sparse=0
data = bsize=4096 blocks=262144, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# mount /dev/nvme0n1 /tmp/
[ 148.923263] XFS (nvme0n1): Mounting V4 Filesystem
[ 148.961196] XFS (nvme0n1): Ending clean mount
# dd if=/dev/urandom of=test.bin bs=1M count=128
128+0 records in
128+0 records out
134217728 bytes (134 MB, 128 MiB) copied, 0.437991 s, 306 MB/s
# sha256sum test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a test.bin
# cp test.bin /tmp/
sha256sum /tmp/test.bin
cde42941f045efa8c4f0f157ab6f29741753cdd8d1cff93a6b03649d83c4129a /tmp/test.bin
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagi@grimberg.me>
Cc: Max Gurtovoy <maxg@mellanox.com>
Acked-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sebastian Reichel [Fri, 28 Apr 2017 17:25:51 +0000 (10:25 -0700)]
Input: twl4030-pwrbutton - use correct device for irq request
[ Upstream commit
3071e9dd6cd3f2290d770117330f2c8b2e9a97e4 ]
The interrupt should be requested for the platform device
and not for the input device.
Fixes:
7f9ce649d267 ("Input: twl4030-pwrbutton - simplify driver using devm_*")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Trimarchi [Tue, 25 Apr 2017 13:18:05 +0000 (15:18 +0200)]
power: supply: pda_power: move from timer to delayed_work
[ Upstream commit
633e8799ddc09431be2744c4a1efdbda13af2b0b ]
This changed is needed to avoid locking problem during
boot as shown:
<5>[ 8.824096] Registering SWP/SWPB emulation handler
<6>[ 8.977294] clock: disabling unused clocks to save power
<3>[ 9.108154] BUG: sleeping function called from invalid context at kernel_albert/kernel/mutex.c:269
<3>[ 9.122894] in_atomic(): 1, irqs_disabled(): 0, pid: 1, name: swapper/0
<4>[ 9.130249] 3 locks held by swapper/0/1:
<4>[ 9.134613] #0: (&__lockdep_no_validate__){......}, at: [<
c0342430>] __driver_attach+0x58/0xa8
<4>[ 9.144500] #1: (&__lockdep_no_validate__){......}, at: [<
c0342440>] __driver_attach+0x68/0xa8
<4>[ 9.154357] #2: (&polling_timer){......}, at: [<
c0053770>] run_timer_softirq+0x108/0x3ec
<4>[ 9.163726] Backtrace:
<4>[ 9.166473] [<
c001269c>] (dump_backtrace+0x0/0x114) from [<
c067e5f0>] (dump_stack+0x20/0x24)
<4>[ 9.175811] r6:
00203230 r5:
0000010d r4:
d782e000 r3:
60000113
<4>[ 9.182250] [<
c067e5d0>] (dump_stack+0x0/0x24) from [<
c007441c>] (__might_sleep+0x10c/0x128)
<4>[ 9.191650] [<
c0074310>] (__might_sleep+0x0/0x128) from [<
c0688f60>] (mutex_lock_nested+0x34/0x36c)
<4>[ 9.201660] r5:
c02d5350 r4:
d79a0c64
<4>[ 9.205688] [<
c0688f2c>] (mutex_lock_nested+0x0/0x36c) from [<
c02d5350>] (regulator_set_current_limit+0x30/0x118)
<4>[ 9.217071] [<
c02d5320>] (regulator_set_current_limit+0x0/0x118) from [<
c0435ce0>] (update_charger+0x84/0xc4)
<4>[ 9.228027] r7:
d782fb20 r6:
00000101 r5:
c1767e94 r4:
00000000
<4>[ 9.234436] [<
c0435c5c>] (update_charger+0x0/0xc4) from [<
c0435d40>] (psy_changed+0x20/0x48)
<4>[ 9.243804] r5:
d782e000 r4:
c1767e94
<4>[ 9.247802] [<
c0435d20>] (psy_changed+0x0/0x48) from [<
c0435dec>] (polling_timer_func+0x84/0xb8)
<4>[ 9.257537] r4:
c1767e94 r3:
00000002
<4>[ 9.261566] [<
c0435d68>] (polling_timer_func+0x0/0xb8) from [<
c00537e4>] (run_timer_softirq+0x17c/0x3ec)
<4>[ 9.272033] r4:
c1767eb0 r3:
00000000
<4>[ 9.276062] [<
c0053668>] (run_timer_softirq+0x0/0x3ec) from [<
c004b000>] (__do_softirq+0xf0/0x298)
<4>[ 9.286010] [<
c004af10>] (__do_softirq+0x0/0x298) from [<
c004b650>] (irq_exit+0x98/0xa0)
<4>[ 9.295013] [<
c004b5b8>] (irq_exit+0x0/0xa0) from [<
c000edbc>] (handle_IRQ+0x60/0xc0)
<4>[ 9.303680] r4:
c1194e98 r3:
c00bc778
<4>[ 9.307708] [<
c000ed5c>] (handle_IRQ+0x0/0xc0) from [<
c0008504>] (gic_handle_irq+0x34/0x68)
<4>[ 9.316955] r8:
000ac383 r7:
d782fc3c r6:
d782fc08 r5:
c11936c4 r4:
e0802100
<4>[ 9.324310] r3:
c026ba48
<4>[ 9.327301] [<
c00084d0>] (gic_handle_irq+0x0/0x68) from [<
c068c2c0>] (__irq_svc+0x40/0x74)
<4>[ 9.336456] Exception stack(0xd782fc08 to 0xd782fc50)
<4>[ 9.342041] fc00:
d6e30e6c ac383627 00000000 ac383417 ea19c000 ea200000
<4>[ 9.351104] fc20:
beffffff 00000667 000ac383 d6e30670 d6e3066c d782fc94 d782fbe8 d782fc50
<4>[ 9.360168] fc40:
c026ba48 c001d1f0 00000113 ffffffff
Fixes:
b2998049cfae ("[BATTERY] pda_power platform driver")
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Anthony Brandon <anthony@amarulasolutions.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Mon, 24 Apr 2017 08:22:08 +0000 (16:22 +0800)]
power: supply: isp1704: Fix unchecked return value of devm_kzalloc
[ Upstream commit
8b20839988f1ed5e534b270f3776709b640dc7e0 ]
Function devm_kzalloc() will return a NULL pointer. However, in function
isp1704_charger_probe(), the return value of devm_kzalloc() is directly
used without validation. This may result in a bad memory access bug.
Fixes:
34a109610e2a ("isp1704_charger: Add DT support")
Signed-off-by: Pan Bian <bianpan2016@163.com>
Reviewed-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Fri, 14 Apr 2017 16:52:33 +0000 (18:52 +0200)]
power: supply: bq24190_charger: Add disable-reset device-property
[ Upstream commit
6cf62a3b97e78ba41d31390e59a1ddc98a9e3622 ]
Allow platform-code to disable the reset on probe and suspend/resume
by setting a "disable-reset" boolean device property on the device.
There are several reasons why the platform-code may want to disable
the reset on probe and suspend/resume:
1) Resetting the charger should never be necessary it should always have
sane values programmed. If it is running with invalid values while we
are not running (system turned off or suspended) there is a big problem
as that may lead to overcharging the battery.
2) The reset in suspend() is meant to put the charger back into default
mode, but this is not necessary and not a good idea. If the charger has
been programmed with a higher max charge_current / charge_voltage then
putting it back in default-mode will reset those to the safe power-on
defaults, leading to slower charging, or charging to a lower voltage
(and thus not using the full capacity) while suspended which is
undesirable. Reprogramming the max charge_current / charge_voltage
after the reset will not help here as that will put the charger back
in host mode and start the i2c watchdog if the host then does not do
anything for 40s (iow if we're suspended for more then 40s) the watchdog
expires resetting the device to default-mode, including resetting all
the registers to there safe power-on defaults. So the only way to keep
using custom charge settings while suspending is to keep the charger in
its normal running state with the i2c watchdog disabled. This is fine
as the charger will still automatically switch from constant current
to constant voltage and stop charging when the battery is full.
3) Besides never being necessary resetting the charger also causes
problems on systems where the charge voltage limit is set higher then the
reset value, if this is the case and the charger is reset while charging
and the battery voltage is between the 2 voltages, then about half the
time the charger gets confused and claims to be charging (REG08 contains
0x64) but in reality the charger has decoupled itself from VBUS (Q1 off)
and is drawing 0A from VBUS, leaving the system running from the battery.
This last problem is happening on a GPD-win mini PC with a bq24292i
charger chip combined with a max17047 fuel-gauge and a LiHV battery.
I've checked and TI does not list any errata for the bq24292i which
could explain this (there are no errata at all).
Cc: Liam Breck <kernel@networkimprov.net>
Cc: Tony Lindgren <tony@atomide.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Liam Breck <kernel@networkimprov.net>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Scott Wood [Sat, 29 Apr 2017 00:17:41 +0000 (19:17 -0500)]
bnx2x: Align RX buffers
[ Upstream commit
9b70de6d0266888b3743f03802502e43131043c8 ]
The bnx2x driver is not providing proper alignment on the receive buffers it
passes to build_skb(), causing skb_shared_info to be misaligned.
skb_shared_info contains an atomic, and while PPC normally supports
unaligned accesses, it does not support unaligned atomics.
Aligning the size of rx buffers will ensure that page_frag_alloc() returns
aligned addresses.
This can be reproduced on PPC by setting the network MTU to 1450 (or other
non-multiple-of-4) and then generating sufficient inbound network traffic
(one or two large "wget"s usually does it), producing the following oops:
Unable to handle kernel paging request for unaligned access at address 0xc00000ffc43af656
Faulting instruction address: 0xc00000000080ef8c
Oops: Kernel access of bad area, sig: 7 [#1]
SMP NR_CPUS=2048
NUMA
PowerNV
Modules linked in: vmx_crypto powernv_rng rng_core powernv_op_panel leds_powernv led_class nfsd ip_tables x_tables autofs4 xfs lpfc bnx2x mdio libcrc32c crc_t10dif crct10dif_generic crct10dif_common
CPU: 104 PID: 0 Comm: swapper/104 Not tainted 4.11.0-rc8-00088-g4c761da #2
task:
c00000ffd4892400 task.stack:
c00000ffd4920000
NIP:
c00000000080ef8c LR:
c00000000080eee8 CTR:
c0000000001f8320
REGS:
c00000ffffc33710 TRAP: 0600 Not tainted (4.11.0-rc8-00088-g4c761da)
MSR:
9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE>
CR:
24082042 XER:
00000000
CFAR:
c00000000080eea0 DAR:
c00000ffc43af656 DSISR:
00000000 SOFTE: 1
GPR00:
c000000000907f64 c00000ffffc33990 c000000000dd3b00 c00000ffcaf22100
GPR04:
c00000ffcaf22e00 0000000000000000 0000000000000000 0000000000000000
GPR08:
0000000000b80008 c00000ffc43af636 c00000ffc43af656 0000000000000000
GPR12:
c0000000001f6f00 c00000000fe1a000 000000000000049f 000000000000c51f
GPR16:
00000000ffffef33 0000000000000000 0000000000008a43 0000000000000001
GPR20:
c00000ffc58a90c0 0000000000000000 000000000000dd86 0000000000000000
GPR24:
c000007fd0ed10c0 00000000ffffffff 0000000000000158 000000000000014a
GPR28:
c00000ffc43af010 c00000ffc9144000 c00000ffcaf22e00 c00000ffcaf22100
NIP [
c00000000080ef8c] __skb_clone+0xdc/0x140
LR [
c00000000080eee8] __skb_clone+0x38/0x140
Call Trace:
[
c00000ffffc33990] [
c00000000080fb74] skb_clone+0x74/0x110 (unreliable)
[
c00000ffffc339c0] [
c000000000907f64] packet_rcv+0x144/0x510
[
c00000ffffc33a40] [
c000000000827b64] __netif_receive_skb_core+0x5b4/0xd80
[
c00000ffffc33b00] [
c00000000082b2bc] netif_receive_skb_internal+0x2c/0xc0
[
c00000ffffc33b40] [
c00000000082c49c] napi_gro_receive+0x11c/0x260
[
c00000ffffc33b80] [
d000000066483d68] bnx2x_poll+0xcf8/0x17b0 [bnx2x]
[
c00000ffffc33d00] [
c00000000082babc] net_rx_action+0x31c/0x480
[
c00000ffffc33e10] [
c0000000000d5a44] __do_softirq+0x164/0x3d0
[
c00000ffffc33f00] [
c0000000000d60a8] irq_exit+0x108/0x120
[
c00000ffffc33f20] [
c000000000015b98] __do_irq+0x98/0x200
[
c00000ffffc33f90] [
c000000000027f14] call_do_irq+0x14/0x24
[
c00000ffd4923a90] [
c000000000015d94] do_IRQ+0x94/0x110
[
c00000ffd4923ae0] [
c000000000008d90] hardware_interrupt_common+0x150/0x160
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 28 Apr 2017 12:56:09 +0000 (15:56 +0300)]
qed: Unlock on error in qed_vf_pf_acquire()
[ Upstream commit
66117a9d9a8ca948680d6554769ef9e88f936954 ]
My static checker complains that we're holding a mutex on this error
path. Let's goto exit instead of returning directly.
Fixes:
b0bccb69eba3 ("qed: Change locking scheme for VF channel")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiri Benc [Thu, 27 Apr 2017 19:24:35 +0000 (21:24 +0200)]
vxlan: correctly handle ipv6.disable module parameter
[ Upstream commit
d074bf9600443403aa24fbc12c1f18eadc90f5aa ]
When IPv6 is compiled but disabled at runtime, __vxlan_sock_add returns
-EAFNOSUPPORT. For metadata based tunnels, this causes failure of the whole
operation of bringing up the tunnel.
Ignore failure of IPv6 socket creation for metadata based tunnels caused by
IPv6 not being available.
Fixes:
b1be00a6c39f ("vxlan: support both IPv4 and IPv6 sockets in a single vxlan device")
Signed-off-by: Jiri Benc <jbenc@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dean Jenkins [Fri, 28 Apr 2017 12:57:26 +0000 (13:57 +0100)]
Bluetooth: hci_ldisc: Add protocol check to hci_uart_tx_wakeup()
[ Upstream commit
2d6f1da168e1d62c47f7d50135ac4cbd8411dcb1 ]
Before attempting to schedule a work-item onto hu->write_work in
hci_uart_tx_wakeup(), check that the Data Link protocol layer is
still bound to the HCI UART driver.
Failure to perform this protocol check causes a race condition between
the work queue hu->write_work running hci_uart_write_work() and the
Data Link protocol layer being unbound (closed) in hci_uart_tty_close().
Note hci_uart_tty_close() does have a "cancel_work_sync(&hu->write_work)"
but it is ineffective because it cannot prevent work-items being added
to hu->write_work after cancel_work_sync() has run.
Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_tx_wakeup()
which prevents scheduling of the work queue when HCI_UART_PROTO_READY
is in the clear state. However, note a small race condition remains
because the hci_uart_tx_wakeup() thread can run in parallel with the
hci_uart_tty_close() thread so it is possible that a schedule of
hu->write_work can occur when HCI_UART_PROTO_READY is cleared. A complete
solution needs locking of the threads which is implemented in a future
commit.
Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dean Jenkins [Fri, 28 Apr 2017 12:57:25 +0000 (13:57 +0100)]
Bluetooth: hci_ldisc: Add protocol check to hci_uart_dequeue()
[ Upstream commit
048e1bd3a27fbeb84ccdff52e165370c1339a193 ]
Before attempting to dequeue a Data Link protocol encapsulated message,
check that the Data Link protocol is still bound to the HCI UART driver.
This makes the code consistent with the usage of the other proto
function pointers.
Therefore, add a check for HCI_UART_PROTO_READY into hci_uart_dequeue()
and return NULL if the Data Link protocol is not bound.
This is needed for robustness as there is a scheduling race condition.
hci_uart_write_work() is scheduled to run via work queue hu->write_work
from hci_uart_tx_wakeup(). Therefore, there is a delay between
scheduling hci_uart_write_work() to run and hci_uart_dequeue() running
whereby the Data Link protocol layer could become unbound during the
scheduling delay. In this case, without the check, the call to the
unbound Data Link protocol layer dequeue function can crash.
It is noted that hci_uart_tty_close() has a
"cancel_work_sync(&hu->write_work)" statement but this only reduces
the window of the race condition because it is possible for a new
work-item to be added to work queue hu->write_work after the call to
cancel_work_sync(). For example, Data Link layer retransmissions can
be added to the work queue after the cancel_work_sync() has finished.
Signed-off-by: Dean Jenkins <Dean_Jenkins@mentor.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Valentin Longchamp [Fri, 17 Feb 2017 10:29:45 +0000 (11:29 +0100)]
soc/fsl/qe: round brg_freq to 1kHz granularity
[ Upstream commit
2ccf80b7566cc035d903dd0ac5d7ebd25c2c1060 ]
Because of integer computation rounding in u-boot (that sets the QE
brg-frequency DTS prop), the clk value is
99999999 Hz even though it is
100 MHz.
When setting brg clks that are exact divisors of 100 MHz, this small
differnce plays a role and can result in lower clks to be output (for
instance 20 MHz - divide by 5 - results in 16.666 MHz - divide by 6).
This patch fixes that by "forcing" the brg_clk to the nearest kHz when
the difference is below 2 integer rounding errors (i.e. 4).
Signed-off-by: Valentin Longchamp <valentin.longchamp@keymile.com>
Signed-off-by: Scott Wood <oss@buserror.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe Leroy [Tue, 7 Feb 2017 09:05:09 +0000 (10:05 +0100)]
net: ethernet: ucc_geth: fix MEM_PART_MURAM mode
[ Upstream commit
8b8642af15ed14b9a7a34d3401afbcc274533e13 ]
Since commit
5093bb965a163 ("powerpc/QE: switch to the cpm_muram
implementation"), muram area is not part of immrbar mapping anymore
so immrbar_virt_to_phys() is not usable anymore.
Fixes:
5093bb965a163 ("powerpc/QE: switch to the cpm_muram implementation")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Li Yang <pku.leo@gmail.com>
Signed-off-by: Scott Wood <oss@buserror.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emil Tantilov [Fri, 31 Mar 2017 03:49:02 +0000 (20:49 -0700)]
ixgbevf: fix size of queue stats length
[ Upstream commit
f87fc44770f54ff1b54d44ae9cec11f10efeca02 ]
IXGBEVF_QUEUE_STATS_LEN is based on ixgebvf_stats, not ixgbe_stats.
This change fixes a bug where ethtool -S displayed some empty fields.
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Kara [Sun, 30 Apr 2017 00:12:16 +0000 (20:12 -0400)]
jbd2: Fix lockdep splat with generic/270 test
[ Upstream commit
c52c47e4b4fbe4284602fc2ccbfc4a4d8dc05b49 ]
I've hit a lockdep splat with generic/270 test complaining that:
3216.fsstress.b/3533 is trying to acquire lock:
(jbd2_handle){++++..}, at: [<
ffffffff813152e0>] jbd2_log_wait_commit+0x0/0x150
but task is already holding lock:
(jbd2_handle){++++..}, at: [<
ffffffff8130bd3b>] start_this_handle+0x35b/0x850
The underlying problem is that jbd2_journal_force_commit_nested()
(called from ext4_should_retry_alloc()) may get called while a
transaction handle is started. In such case it takes care to not wait
for commit of the running transaction (which would deadlock) but only
for a commit of a transaction that is already committing (which is safe
as that doesn't wait for any filesystem locks).
In fact there are also other callers of jbd2_log_wait_commit() that take
care to pass tid of a transaction that is already committing and for
those cases, the lockdep instrumentation is too restrictive and leading
to false positive reports. Fix the problem by calling
jbd2_might_wait_for_commit() from jbd2_log_wait_commit() only if the
transaction isn't already committing.
Fixes:
1eaa566d368b214d99cbb973647c1b0b8102a9ae
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mario Kleiner [Sun, 23 Apr 2017 23:59:34 +0000 (01:59 +0200)]
drm/nouveau/kms: Increase max retries in scanout position queries.
[ Upstream commit
60b95d709525e3ce1c51e1fc93175dcd1755d345 ]
So far we only allowed for 1 retry and just failed the query
- and thereby high precision vblank timestamping - if we did
not get a reasonable result, as such a failure wasn't considered
all too horrible. There are a few NVidia gpu models out there which
may need a bit more than 1 retry to get a successful query result
under some conditions.
Since Linux 4.4 the update code for vblank counter and timestamp
in drm_update_vblank_count() changed so that the implementation
assumes that high precision vblank timestamping of a kms driver
either consistently succeeds or consistently fails for a given
video mode and encoder/connector combo. Iow. switching from success
to fail or vice versa on a modeset or connector change is ok, but
spurious temporary failure for a given setup can confuse the core
code and potentially cause bad miscounting of vblanks and confusion
or hangs in userspace clients which rely on vblank stuff, e.g.,
desktop compositors.
Therefore change the max retry count to a larger number - more than
any gpu so far is known to need to succeed, but still low enough
so that these queries which do also happen in vblank interrupt are
still fast enough to be not disastrously long if something would
go badly wrong with them.
As such sporadic retries only happen seldom even on affected gpu's,
this could mean a vblank irq could take a few dozen microseconds
longer every few hours of uptime -- better than a desktop compositor
randomly hanging every couple of hours or days of uptime in a hard
to reproduce manner.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chunming Zhou [Mon, 24 Apr 2017 09:09:15 +0000 (17:09 +0800)]
drm/amdgpu: fix gpu reset crash
[ Upstream commit
51687759be93fbc553f2727e86be25c38126ba93 ]
[ 413.687439] BUG: unable to handle kernel NULL pointer dereference at
0000000000000548
[ 413.687479] IP: [<
ffffffff8109b175>] to_live_kthread+0x5/0x60
[ 413.687507] PGD
1efd12067
[ 413.687519] PUD
1efd11067
[ 413.687531] PMD 0
[ 413.687543] Oops: 0000 [#1] SMP
[ 413.687557] Modules linked in: amdgpu(OE) ttm(OE) drm_kms_helper(E) drm(E) i2c_algo_bit(E) fb_sys_fops(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) rpcsec_gss_krb5(E) nfsv4(E) nfs(E) fscache(E) snd_hda_codec_realtek(E) snd_hda_codec_generic(E) snd_hda_codec_hdmi(E) snd_hda_intel(E) eeepc_wmi(E) snd_hda_codec(E) asus_wmi(E) snd_hda_core(E) sparse_keymap(E) snd_hwdep(E) video(E) snd_pcm(E) snd_seq_midi(E) joydev(E) snd_seq_midi_event(E) snd_rawmidi(E) snd_seq(E) snd_seq_device(E) snd_timer(E) kvm(E) irqbypass(E) crct10dif_pclmul(E) snd(E) crc32_pclmul(E) ghash_clmulni_intel(E) soundcore(E) aesni_intel(E) aes_x86_64(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) shpchp(E) serio_raw(E) i2c_piix4(E) 8250_dw(E) i2c_designware_platform(E) i2c_designware_core(E) mac_hid(E) binfmt_misc(E)
[ 413.687894] parport_pc(E) ppdev(E) lp(E) parport(E) nfsd(E) auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) autofs4(E) hid_generic(E) usbhid(E) hid(E) psmouse(E) ahci(E) r8169(E) mii(E) libahci(E) wmi(E)
[ 413.687989] CPU: 13 PID: 1134 Comm: kworker/13:2 Tainted: G OE 4.9.0-custom #4
[ 413.688019] Hardware name: System manufacturer System Product Name/PRIME B350-PLUS, BIOS 0606 04/06/2017
[ 413.688089] Workqueue: events amd_sched_job_timedout [amdgpu]
[ 413.688116] task:
ffff88020f9657c0 task.stack:
ffffc90001a88000
[ 413.688139] RIP: 0010:[<
ffffffff8109b175>] [<
ffffffff8109b175>] to_live_kthread+0x5/0x60
[ 413.688171] RSP: 0018:
ffffc90001a8bd60 EFLAGS:
00010282
[ 413.688191] RAX:
ffff88020f0073f8 RBX:
ffff88020f000000 RCX:
0000000000000000
[ 413.688217] RDX:
0000000000000001 RSI:
ffff88020f9670c0 RDI:
0000000000000000
[ 413.688243] RBP:
ffffc90001a8bd78 R08:
0000000000000000 R09:
0000000000001000
[ 413.688269] R10:
0000006051b11a82 R11:
0000000000000001 R12:
0000000000000000
[ 413.688295] R13:
ffff88020f002770 R14:
ffff88020f004838 R15:
ffff8801b23c2c60
[ 413.688321] FS:
0000000000000000(0000) GS:
ffff88021ef40000(0000) knlGS:
0000000000000000
[ 413.688352] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 413.688373] CR2:
0000000000000548 CR3:
00000001efd0f000 CR4:
00000000003406e0
[ 413.688399] Stack:
[ 413.688407]
ffffffff8109b304 ffff88020f000000 0000000000000070 ffffc90001a8bdf0
[ 413.688439]
ffffffffa05ce29d ffffffffa052feb7 ffffffffa07b5820 ffffc90001a8bda0
[ 413.688470]
ffffffff00000018 ffff8801bb88f060 0000000001a8bdb8 ffff88021ef59280
[ 413.688502] Call Trace:
[ 413.688514] [<
ffffffff8109b304>] ? kthread_park+0x14/0x60
[ 413.688555] [<
ffffffffa05ce29d>] amdgpu_gpu_reset+0x7d/0x670 [amdgpu]
[ 413.688589] [<
ffffffffa052feb7>] ? drm_printk+0x97/0xa0 [drm]
[ 413.688643] [<
ffffffffa0698136>] amdgpu_job_timedout+0x46/0x50 [amdgpu]
[ 413.688700] [<
ffffffffa06969e7>] amd_sched_job_timedout+0x17/0x20 [amdgpu]
[ 413.688727] [<
ffffffff81095493>] process_one_work+0x153/0x3f0
[ 413.688751] [<
ffffffff81095c5b>] worker_thread+0x12b/0x4b0
[ 413.688773] [<
ffffffff8100392e>] ? do_syscall_64+0x6e/0x180
[ 413.688795] [<
ffffffff81095b30>] ? rescuer_thread+0x350/0x350
[ 413.688818] [<
ffffffff8100392e>] ? do_syscall_64+0x6e/0x180
[ 413.688839] [<
ffffffff8109b423>] kthread+0xd3/0xf0
[ 413.688858] [<
ffffffff8109b350>] ? kthread_park+0x60/0x60
[ 413.688881] [<
ffffffff817e1ee5>] ret_from_fork+0x25/0x30
[ 413.688901] Code: 25 40 d3 00 00 48 8b 80 48 05 00 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 <48> 8b b7 48 05 00 00 55 48 89 e5 48 85 f6 74 31 8b 97 f8 18 00
[ 413.689045] RIP [<
ffffffff8109b175>] to_live_kthread+0x5/0x60
[ 413.689064] RSP <
ffffc90001a8bd60>
[ 413.689076] CR2:
0000000000000548
[ 413.697985] ---[ end trace
0a314a64821f84e9 ]---
The root cause is some ring doesn't have scheduler, like KIQ ring
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Chunming Zhou <David1.Zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hans de Goede [Fri, 21 Apr 2017 11:48:08 +0000 (13:48 +0200)]
ACPI / PMIC: xpower: Fix power_table addresses
[ Upstream commit
2bde7c32b1db162692f05c6be066b5bcd3d9fdbe ]
The power table addresses should be contiguous, but there was a hole
where 0x34 was missing. On most devices this is not a problem as
addresses above 0x34 are used for the BUC# convertors which are not
used in the DSDTs I've access to but after the BUC# convertors
there is a field named GPI1 in the DSTDs, which does get used in some
cases and ended up turning BUC6 on and off due to the wrong addresses,
resulting in turning the entire device off (or causing it to reboot).
Removing the hole in the addresses fixes this, fixing one of my
Bay Trail tablets turning off while booting the mainline kernel.
While at it add comments with the field names used in the DSDTs to
make it easier to compare the register and bits used at each address
with the datasheet.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robert Lippert [Thu, 20 Apr 2017 23:49:47 +0000 (16:49 -0700)]
ipmi/watchdog: fix wdog hang on panic waiting for ipmi response
[ Upstream commit
2c1175c2e8e5487233cabde358a19577562ac83e ]
Commit
c49c097610fe ("ipmi: Don't call receive handler in the
panic context") means that the panic_recv_free is not called during a
panic and the atomic count does not drop to 0.
Fix this by only expecting one decrement of the atomic variable
which comes from panic_smi_free.
Signed-off-by: Robert Lippert <rlippert@google.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleksij Rempel [Fri, 28 Apr 2017 14:19:49 +0000 (16:19 +0200)]
platform/x86: asus-wmi: try to set als by default
[ Upstream commit
e9b615186805e2c18a0ac76aca62c1543ecfdbb8 ]
some laptops, for example ASUS UX330UAK, have brocken als_get function
but working als_set funktion. In this case, ALS will stay turned off.
Method (WMNB, 3, Serialized)
{
...
If (Local0 == 0x53545344)
{
...
If (IIA0 == 0x00050001)
{
If (!ALSP)
{
Return (0x02)
}
Local0 = (GALS & 0x10) <<<---- bug,
should be: (GALS () & 0x10)
If (Local0)
{
Return (0x00050001)
}
Else
{
Return (0x00050000)
}
}
.....
If (Local0 == 0x53564544)
{
...
If (IIA0 == 0x00050001)
{
Return (ALSC (IIA1))
}
......
Method (GALS, 0, NotSerialized)
{
Local0 = Zero
Local0 |= 0x20
If (ALAE)
{
Local0 |= 0x10
}
Local1 = 0x0A
Local1 <<= 0x08
Local0 |= Local1
Return (Local0)
}
Since it works without problems on Windows I assume ASUS WMI driver for Win
never trying to get ALS state, and instead it is setting it by default to ON.
This patch will do the same. Turn ALS on by default.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tadeusz Struk [Fri, 28 Apr 2017 17:40:02 +0000 (10:40 -0700)]
IB/hfi1: Fix softlockup issue
[ Upstream commit
22546b741af8355cd2e16739b6af4a8f17081839 ]
Soft lockups can occur because the mad processing on different CPUs acquire
the spin lock dc8051_lock:
[534552.835870] [<
ffffffffa026f993>] ? read_dev_port_cntr.isra.37+0x23/0x160 [hfi1]
[534552.835880] [<
ffffffffa02775af>] read_dev_cntr+0x4f/0x60 [hfi1]
[534552.835893] [<
ffffffffa028d7cd>] pma_get_opa_portstatus+0x64d/0x8c0 [hfi1]
[534552.835904] [<
ffffffffa0290e7d>] hfi1_process_mad+0x48d/0x18c0 [hfi1]
[534552.835908] [<
ffffffff811dc1f1>] ? __slab_free+0x81/0x2f0
[534552.835936] [<
ffffffffa024c34e>] ? ib_mad_recv_done+0x21e/0xa30 [ib_core]
[534552.835939] [<
ffffffff811dd153>] ? __kmalloc+0x1f3/0x240
[534552.835947] [<
ffffffffa024c3fb>] ib_mad_recv_done+0x2cb/0xa30 [ib_core]
[534552.835955] [<
ffffffffa0237c85>] __ib_process_cq+0x55/0xd0 [ib_core]
[534552.835962] [<
ffffffffa0237d70>] ib_cq_poll_work+0x20/0x60 [ib_core]
[534552.835964] [<
ffffffff810a7f3b>] process_one_work+0x17b/0x470
[534552.835966] [<
ffffffff810a8d76>] worker_thread+0x126/0x410
[534552.835969] [<
ffffffff810a8c50>] ? rescuer_thread+0x460/0x460
[534552.835971] [<
ffffffff810b052f>] kthread+0xcf/0xe0
[534552.835974] [<
ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140
[534552.835977] [<
ffffffff81696418>] ret_from_fork+0x58/0x90
[534552.835980] [<
ffffffff810b0460>] ? kthread_create_on_node+0x140/0x140
This issue is made worse when the 8051 is busy and the reads take longer.
Fix by using a non-spinning lock procure.
Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Reviewed-by: Mike Marciszyn <mike.marciniszyn@intel.com>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Thu, 27 Apr 2017 09:14:20 +0000 (12:14 +0300)]
IB/rdmavt: restore IRQs on error path in rvt_create_ah()
[ Upstream commit
f0bb2d44ca26b7090dc7bade8877b77005f07dfc ]
We need to call spin_unlock_irqrestore() instead of vanilla
spin_unlock() on this error path.
Fixes:
119a8e708d16 ("IB/rdmavt: Add AH to rdmavt")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Acked-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kishon Vijay Abraham I [Mon, 27 Mar 2017 09:45:20 +0000 (15:15 +0530)]
ARM: DRA7: clockdomain: Change the CLKTRCTRL of CM_PCIE_CLKSTCTRL to SW_WKUP
[ Upstream commit
2c949ce38f4e81d7487f165fa3b8f77d74a2a6c4 ]
The PCIe programming sequence in TRM suggests CLKSTCTRL of PCIe should be
set to SW_WKUP. There are no issues when CLKSTCTRL is set to HW_AUTO in RC
mode. However in EP mode, the host system is not able to access the
MEMSPACE and setting the CLKSTCTRL to SW_WKUP fixes it.
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Fri, 28 Apr 2017 12:57:56 +0000 (15:57 +0300)]
netfilter: x_tables: unlock on error in xt_find_table_lock()
[ Upstream commit
7dde07e9c53617549d67dd3e1d791496d0d3868e ]
According to my static checker we should unlock here before the return.
That seems reasonable to me as well.
Fixes"
b9e69e127397 ("netfilter: xtables: don't hook tables by default")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
yangbo lu [Thu, 20 Apr 2017 06:58:29 +0000 (14:58 +0800)]
mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a
[ Upstream commit
a627f025eb0534052ff451427c16750b3530634c ]
The ls1046a datasheet specified that the max SD clock frequency
for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet
specified it's 125MHz for ls1012a. So this patch is to add the
limitation.
Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mohammed Shafi Shajakhan [Thu, 27 Apr 2017 07:15:38 +0000 (12:45 +0530)]
mac80211: Fix possible sband related NULL pointer de-reference
[ Upstream commit
21a8e9dd52b64f0170bad208293ef8c30c3c1403 ]
Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even
if the channel context configuration is NULL. This crashes for chipsets
which support 5 Ghz alone when it tries to access members of 'sband'.
Channel context configuration can be NULL in multivif case and when
channel switch is in progress (or) when it fails. Fix this by replacing
the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which
returns a NULL pointer for sband when the channel configuration is NULL.
An example scenario is as below:
In multivif mode (AP + STA) with drivers like ath10k, when we do a
channel switch in the AP vif (which has a number of clients connected)
and a STA vif which is connected to some other AP, when the channel
switch in AP vif fails, while the STA vifs tries to connect to the
other AP, there is a window where the channel context is NULL/invalid
and this results in a crash while the clients connected to the AP vif
tries to reconnect and this race is very similar to the one investigated
by Michal in https://patchwork.kernel.org/patch/3788161/ and this does
happens with hardware that supports 5Ghz alone after long hours of
testing with continuous channel switch on the AP vif
ieee80211 phy0: channel context reservation cannot be finalized because
some interfaces aren't switching
wlan0: failed to finalize CSA, disconnecting
wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice
(Reason: 3=DEAUTH_LEAVING)
WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211]
[<
bf77272c>] (sta_info_alloc [mac80211])
[<
bf78776c>] (ieee80211_add_station [mac80211]))
[<
bf73cc50>] (nl80211_new_station [cfg80211])
Unable to handle kernel NULL pointer dereference at virtual
address
00000014
pgd =
d5f4c000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
PC is at sta_info_alloc+0x380/0x3fc [mac80211]
LR is at sta_info_alloc+0x37c/0x3fc [mac80211]
[<
bf772738>] (sta_info_alloc [mac80211])
[<
bf78776c>] (ieee80211_add_station [mac80211])
[<
bf73cc50>] (nl80211_new_station [cfg80211]))
Cc: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Abeni [Thu, 20 Apr 2017 09:44:16 +0000 (11:44 +0200)]
ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled
[ Upstream commit
1442f6f7c1b77de1c508318164a527e240c24a4d ]
When creating a new ipvs service, ipv6 addresses are always accepted
if CONFIG_IP_VS_IPV6 is enabled. On dest creation the address family
is not explicitly checked.
This allows the user-space to configure ipvs services even if the
system is booted with ipv6.disable=1. On specific configuration, ipvs
can try to call ipv6 routing code at setup time, causing the kernel to
oops due to fib6_rules_ops being NULL.
This change addresses the issue adding a check for the ipv6
module being enabled while validating ipv6 service operations and
adding the same validation for dest operations.
According to git history, this issue is apparently present since
the introduction of ipv6 support, and the oops can be triggered
since commit
09571c7ae30865ad ("IPVS: Add function to determine
if IPv6 address is local")
Fixes:
09571c7ae30865ad ("IPVS: Add function to determine if IPv6 address is local")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Julian Anastasov <ja@ssi.bg>
Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Sun, 23 Apr 2017 11:53:58 +0000 (19:53 +0800)]
staging: wilc1000: fix unchecked return value
[ Upstream commit
9e96652756ad647b7bcc03cb99ffc9756d7b5f93 ]
Function dev_alloc_skb() will return a NULL pointer if there is no
enough memory. However, in function WILC_WFI_mon_xmit(), its return
value is used without validation. This may result in a bad memory access
bug. This patch fixes the bug.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sameer Wadgaonkar [Tue, 18 Apr 2017 20:55:25 +0000 (16:55 -0400)]
staging: unisys: visorhba: fix s-Par to boot with option CONFIG_VMAP_STACK set to y
[ Upstream commit
3c2bf0bd08123f3497bd3e84bd9088c937b0cb40 ]
The root issue is that we are not allowed to have items on the
stack being passed to "DMA" like operations. In this case we have
a vmcall and an inline completion of scsi command.
This patch fixes the issue by moving the variables on stack in
do_scsi_nolinuxstat() to heap memory.
Signed-off-by: Sameer Wadgaonkar <sameer.wadgaonkar@unisys.com>
Signed-off-by: David Kershner <david.kershner@unisys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kuppuswamy Sathyanarayanan [Mon, 24 Apr 2017 19:15:04 +0000 (12:15 -0700)]
gpio: gpio-wcove: fix GPIO IRQ status mask
[ Upstream commit
881ebd229f4a5ea88f269c1225245e50db9ba303 ]
According to Whiskey Cove PMIC spec, bit 7 of GPIOIRQ0_REG belongs to
battery IO. So we should skip this bit when checking for GPIO IRQ pending
status. Otherwise, wcove_gpio_irq_handler() might go into the infinite
loop until IRQ "pending" status becomes 0. This patch fixes this issue.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baoquan He [Thu, 27 Apr 2017 07:42:20 +0000 (15:42 +0800)]
x86/KASLR: Fix kexec kernel boot crash when KASLR randomization fails
[ Upstream commit
da63b6b20077469bd6bd96e07991ce145fc4fbc4 ]
Dave found that a kdump kernel with KASLR enabled will reset to the BIOS
immediately if physical randomization failed to find a new position for
the kernel. A kernel with the 'nokaslr' option works in this case.
The reason is that KASLR will install a new page table for the identity
mapping, while it missed building it for the original kernel location
if KASLR physical randomization fails.
This only happens in the kexec/kdump kernel, because the identity mapping
has been built for kexec/kdump in the 1st kernel for the whole memory by
calling init_pgtable(). Here if physical randomizaiton fails, it won't build
the identity mapping for the original area of the kernel but change to a
new page table '_pgtable'. Then the kernel will triple fault immediately
caused by no identity mappings.
The normal kernel won't see this bug, because it comes here via startup_32()
and CR3 will be set to _pgtable already. In startup_32() the identity
mapping is built for the 0~4G area. In KASLR we just append to the existing
area instead of entirely overwriting it for on-demand identity mapping
building. So the identity mapping for the original area of kernel is still
there.
To fix it we just switch to the new identity mapping page table when physical
KASLR succeeds. Otherwise we keep the old page table unchanged just like
"nokaslr" does.
Signed-off-by: Baoquan He <bhe@redhat.com>
Signed-off-by: Dave Young <dyoung@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Borislav Petkov <bp@suse.de>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Garnier <thgarnie@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1493278940-5885-1-git-send-email-bhe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Thu, 27 Apr 2017 13:45:18 +0000 (07:45 -0600)]
mtip32xx: use runtime tag to initialize command header
[ Upstream commit
a4e84aae8139aca9fbfbced1f45c51ca81b57488 ]
mtip32xx supposes that 'request_idx' passed to .init_request()
is tag of the request, and use that as request's tag to initialize
command header.
After MQ IO scheduler is in, request tag assigned isn't same with
the request index anymore, so cause strange hardware failure on
mtip32xx, even whole system panic is triggered.
This patch fixes the issue by initializing command header via
request's real tag.
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Keerthy [Thu, 10 Nov 2016 05:09:18 +0000 (10:39 +0530)]
mfd: palmas: Reset the POWERHOLD mux during power off
[ Upstream commit
85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ]
POWERHOLD signal has higher priority over the DEV_ON bit.
So power off will not happen if the POWERHOLD is held high.
Hence reset the MUX to GPIO_7 mode to release the POWERHOLD
and the DEV_ON bit to take effect to power off the PMIC.
PMIC Power off happens in dire situations like thermal shutdown
so irrespective of the POWERHOLD setting go ahead and turn off
the powerhold. Currently poweroff is broken on boards that have
powerhold enabled. This fixes poweroff on those boards.
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rask Ingemann Lambertsen [Wed, 22 Feb 2017 19:41:02 +0000 (20:41 +0100)]
dt-bindings: mfd: axp20x: Add "xpowers,master-mode" property for AXP806 PMICs
[ Upstream commit
8461cf20d17e0090e9236b73d25b31be4f7fadc5 ]
commit
b101829a029a ("mfd: axp20x: Fix AXP806 access errors on cold boot")
was intended to fix the case where a board uses an AXP806 in slave mode,
but the boot loader leaves it in master mode for lack of AXP806 support.
But now the driver breaks on boards where the PMIC is operating in master
mode. To let the device tree describe which mode of operation is needed,
this patch introduces a new property "xpowers,master-mode".
Fixes:
204ae2963e10 ("mfd: axp20x: Add bindings for AXP806 PMIC")
Signed-off-by: Rask Ingemann Lambertsen <rask@formelder.dk>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Wed, 19 Apr 2017 14:35:48 +0000 (15:35 +0100)]
iio: hid-sensor: fix return of -EINVAL on invalid values in ret or value
[ Upstream commit
c894acc7bf400d039bf740420b22f0b71b7fb504 ]
Ensure that when an invalid value in ret or value is found -EINVAL
is returned. A previous commit broke the way the return error is
being returned and instead caused the return code in ret to be
re-assigned rather than be returned.
Fixes:
5d9854eaea776 ("iio: hid-sensor: Store restore poll and hysteresis on S3")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lv Zheng [Wed, 26 Apr 2017 08:18:49 +0000 (16:18 +0800)]
ACPICA: iasl: Fix IORT SMMU GSI disassembling
[ Upstream commit
bb1e23e66e6237ff7a1824b37366540a89149c33 ]
ACPICA commit
637b88de24a78c20478728d9d66632b06fcaa5bf
If the IORT template is compiled and then iort.aml binary disassembled to
iort.dsl, SMMUv1 node lists incorrect offset for SMMU_Nsg_cfg_irpt Interrupt:
[0ECh 0236 8] SMMU_Nsg_irpt Interrupt :
0000000000000000
[0ECh 0236 8] SMMU_Nsg_cfg_irpt Interrupt :
0000000000000000
This is because iasl hasn't implemented SMMU GSI decoding yet.
This patch fixes this issue by preparing structures for decoding IORT SMMU
GSI. ACPICA BZ 1340, reported by Alexei Fedorov, fixed by Lv Zheng.
Link: https://github.com/acpica/acpica/commit/637b88de
Link: https://bugs.acpica.org/show_bug.cgi?id=1340
Reported-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emmanuel Grumbach [Wed, 26 Apr 2017 07:58:51 +0000 (10:58 +0300)]
mac80211: don't parse encrypted management frames in ieee80211_frame_acked
[ Upstream commit
cf147085fdda044622973a12e4e06f1c753ab677 ]
ieee80211_frame_acked is called when a frame is acked by
the peer. In case this is a management frame, we check
if this an SMPS frame, in which case we can update our
antenna configuration.
When we parse the management frame we look at the category
in case it is an action frame. That byte sits after the IV
in case the frame was encrypted. This means that if the
frame was encrypted, we basically look at the IV instead
of looking at the category. It is then theorically
possible that we think that an SMPS action frame was acked
where really we had another frame that was encrypted.
Since the only management frame whose ack needs to be
tracked is the SMPS action frame, and that frame is not
a robust management frame, it will never be encrypted.
The easiest way to fix this problem is then to not look
at frames that were encrypted.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martin Brandenburg [Tue, 25 Apr 2017 19:38:07 +0000 (15:38 -0400)]
orangefs: do not wait for timeout if umounting
[ Upstream commit
b5a9d61eebdd0016ccb383b25a5c3d04977a6549 ]
When the computer is turned off, all the processes are killed and then
all the filesystems are umounted. OrangeFS should not wait for the
userspace daemon to come back in that case.
This only works for plain umount(2). To actually take advantage of this
interactively, `umount -f' is needed; otherwise umount will issue a
statfs first, which will wait for the userspace daemon to come back.
Signed-off-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Filipe Manana [Mon, 3 Apr 2017 14:57:17 +0000 (15:57 +0100)]
Btrfs: fix extent map leak during fallocate error path
[ Upstream commit
be2d253cc98244765323a7c94cc1ac5cd5a17072 ]
If the call to btrfs_qgroup_reserve_data() failed, we were leaking an
extent map structure. The failure can happen either due to an -ENOMEM
condition or, when quotas are enabled, due to -EDQUOT for example.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Filipe Manana [Tue, 4 Apr 2017 19:31:00 +0000 (20:31 +0100)]
Btrfs: send, fix file hole not being preserved due to inline extent
[ Upstream commit
e1cbfd7bf6dabdac561c75d08357571f44040a45 ]
Normally we don't have inline extents followed by regular extents, but
there's currently at least one harmless case where this happens. For
example, when the page size is 4Kb and compression is enabled:
$ mkfs.btrfs -f /dev/sdb
$ mount -o compress /dev/sdb /mnt
$ xfs_io -f -c "pwrite -S 0xaa 0 4K" -c "fsync" /mnt/foobar
$ xfs_io -c "pwrite -S 0xbb 8K 4K" -c "fsync" /mnt/foobar
In this case we get a compressed inline extent, representing 4Kb of
data, followed by a hole extent and then a regular data extent. The
inline extent was not expanded/converted to a regular extent exactly
because it represents 4Kb of data. This does not cause any apparent
problem (such as the issue solved by commit
e1699d2d7bf6
("btrfs: add missing memset while reading compressed inline extents"))
except trigger an unexpected case in the incremental send code path
that makes us issue an operation to write a hole when it's not needed,
resulting in more writes at the receiver and wasting space at the
receiver.
So teach the incremental send code to deal with this particular case.
The issue can be currently triggered by running fstests btrfs/137 with
compression enabled (MOUNT_OPTIONS="-o compress" ./check btrfs/137).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Filipe Manana [Wed, 8 Mar 2017 16:43:49 +0000 (16:43 +0000)]
Btrfs: fix incorrect space accounting after failure to insert inline extent
[ Upstream commit
1c81ba237bcecad9bc885a1ddcf02d725ea38482 ]
When using compression, if we fail to insert an inline extent we
incorrectly end up attempting to free the reserved data space twice,
once through extent_clear_unlock_delalloc(), because we pass it the
flag EXTENT_DO_ACCOUNTING, and once through a direct call to
btrfs_free_reserved_data_space_noquota(). This results in a trace
like the following:
[ 834.576240] ------------[ cut here ]------------
[ 834.576825] WARNING: CPU: 2 PID: 486 at fs/btrfs/extent-tree.c:4316 btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 834.579501] Modules linked in: btrfs crc32c_generic xor raid6_pq ppdev i2c_piix4 acpi_cpufreq psmouse tpm_tis parport_pc pcspkr serio_raw tpm_tis_core sg parport evdev i2c_core tpm button loop autofs4 ext4 crc16 jbd2 mbcache sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
[ 834.592116] CPU: 2 PID: 486 Comm: kworker/u32:4 Not tainted 4.10.0-rc8-btrfs-next-37+ #2
[ 834.593316] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
[ 834.595273] Workqueue: btrfs-delalloc btrfs_delalloc_helper [btrfs]
[ 834.596103] Call Trace:
[ 834.596103] dump_stack+0x67/0x90
[ 834.596103] __warn+0xc2/0xdd
[ 834.596103] warn_slowpath_null+0x1d/0x1f
[ 834.596103] btrfs_free_reserved_data_space_noquota+0x60/0x9f [btrfs]
[ 834.596103] compress_file_range.constprop.42+0x2fa/0x3fc [btrfs]
[ 834.596103] ? submit_compressed_extents+0x3a7/0x3a7 [btrfs]
[ 834.596103] async_cow_start+0x32/0x4d [btrfs]
[ 834.596103] btrfs_scrubparity_helper+0x187/0x3e7 [btrfs]
[ 834.596103] btrfs_delalloc_helper+0xe/0x10 [btrfs]
[ 834.596103] process_one_work+0x273/0x4e4
[ 834.596103] worker_thread+0x1eb/0x2ca
[ 834.596103] ? rescuer_thread+0x2b6/0x2b6
[ 834.596103] kthread+0x100/0x108
[ 834.596103] ? __list_del_entry+0x22/0x22
[ 834.596103] ret_from_fork+0x2e/0x40
[ 834.611656] ---[ end trace
719902fe6bdef08f ]---
So fix this by not calling directly btrfs_free_reserved_data_space_noquota()
if an error happened.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Mon, 24 Apr 2017 00:40:28 +0000 (08:40 +0800)]
rndis_wlan: add return value validation
[ Upstream commit
9dc7efd3978aa67ae598129d2a3f240b390ce508 ]
Function create_singlethread_workqueue() will return a NULL pointer if
there is no enough memory, and its return value should be validated
before using. However, in function rndis_wlan_bind(), its return value
is not checked. This may cause NULL dereference bugs. This patch fixes
it.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Sun, 23 Apr 2017 13:19:38 +0000 (21:19 +0800)]
libertas: check return value of alloc_workqueue
[ Upstream commit
dc3f89c38a8406554ffeffa370aad086a9c5e9de ]
Function alloc_workqueue() will return a NULL pointer if there is no
enough memory, and its return value should be validated before using.
However, in function if_spi_probe(), its return value is not checked.
This may result in a NULL dereference bug. This patch fixes the bug.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Sun, 23 Apr 2017 07:00:23 +0000 (15:00 +0800)]
mt7601u: check return value of alloc_skb
[ Upstream commit
5fb01e91daf84ad1e50edfcf63116ecbe31e7ba7 ]
Function alloc_skb() will return a NULL pointer if there is no enough
memory. However, in function mt7601u_mcu_msg_alloc(), its return value
is not validated before it is used. This patch fixes it.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Acked-by: Jakub Kicinski <kubakici@wp.pl>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Shrirang Bagul [Wed, 19 Apr 2017 14:05:00 +0000 (22:05 +0800)]
iio: st_pressure: st_accel: Initialise sensor platform data properly
[ Upstream commit
7383d44b84c94aaca4bf695a6bd8a69f2295ef1a ]
This patch fixes the sensor platform data initialisation for st_pressure
and st_accel device drivers. Without this patch, the driver fails to
register the sensors when the user removes and re-loads the driver.
1. Unload the kernel modules for st_pressure
$ sudo rmmod st_pressure_i2c
$ sudo rmmod st_pressure
2. Re-load the driver
$ sudo insmod st_pressure
$ sudo insmod st_pressure_i2c
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Wed, 15 Mar 2017 01:40:44 +0000 (12:40 +1100)]
NFS: don't try to cross a mountpount when there isn't one there.
[ Upstream commit
99bbf6ecc694dfe0b026e15359c5aa2a60b97a93 ]
consider the sequence of commands:
mkdir -p /import/nfs /import/bind /import/etc
mount --bind / /import/bind
mount --make-private /import/bind
mount --bind /import/etc /import/bind/etc
exportfs -o rw,no_root_squash,crossmnt,async,no_subtree_check localhost:/
mount -o vers=4 localhost:/ /import/nfs
ls -l /import/nfs/etc
You would not expect this to report a stale file handle.
Yet it does.
The manipulations under /import/bind cause the dentry for
/etc to get the DCACHE_MOUNTED flag set, even though nothing
is mounted on /etc. This causes nfsd to call
nfsd_cross_mnt() even though there is no mountpoint. So an
upcall to mountd for "/etc" is performed.
The 'crossmnt' flag on the export of / causes mountd to
report that /etc is exported as it is a descendant of /. It
assumes the kernel wouldn't ask about something that wasn't
a mountpoint. The filehandle returned identifies the
filesystem and the inode number of /etc.
When this filehandle is presented to rpc.mountd, via
"nfsd.fh", the inode cannot be found associated with any
name in /etc/exports, or with any mountpoint listed by
getmntent(). So rpc.mountd says the filehandle doesn't
exist. Hence ESTALE.
This is fixed by teaching nfsd not to trust DCACHE_MOUNTED
too much. It is just a hint, not a guarantee.
Change nfsd_mountpoint() to return '1' for a certain mountpoint,
'2' for a possible mountpoint, and 0 otherwise.
Then change nfsd_crossmnt() to check if follow_down()
actually found a mountpount and, if not, to avoid performing
a lookup if the location is not known to certainly require
an export-point.
Signed-off-by: NeilBrown <neilb@suse.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chuck Lever [Tue, 11 Apr 2017 17:22:29 +0000 (13:22 -0400)]
xprtrdma: Cancel refresh worker during buffer shutdown
[ Upstream commit
9378b274e1eb6925db315e345f48850d2d5d9789 ]
Trying to create MRs while the transport is being torn down can
cause a crash.
Fixes:
e2ac236c0b65 ("xprtrdma: Allocate MRs on demand")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 25 Apr 2017 15:26:53 +0000 (11:26 -0400)]
pNFS: Fix use after free issues in pnfs_do_read()
[ Upstream commit
6aeafd05eca9bc8ab6b03d7e56d09ffd18190f44 ]
The assumption should be that if the caller returns PNFS_ATTEMPTED, then hdr
has been consumed, and so we should not be testing hdr->task.tk_status.
If the caller returns PNFS_TRY_AGAIN, then we need to recoalesce and
free hdr.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vlad Tsyrklevich [Fri, 24 Mar 2017 19:55:17 +0000 (15:55 -0400)]
infiniband/uverbs: Fix integer overflows
[ Upstream commit
4f7f4dcfff2c19debbcdbcc861c325610a15e0c5 ]
The 'num_sge' variable is verfied to be smaller than the 'sge_count'
variable; however, since both are user-controlled it's possible to cause
an integer overflow for the kmalloc multiply on 32-bit platforms
(num_sge and sge_count are both defined u32). By crafting an input that
causes a smaller-than-expected allocation it's possible to write
controlled data out-of-bounds.
Signed-off-by: Vlad Tsyrklevich <vlad@tsyrklevich.net>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Finn Thain [Sun, 2 Apr 2017 07:08:05 +0000 (17:08 +1000)]
scsi: mac_esp: Replace bogus memory barrier with spinlock
[ Upstream commit
4da2b1eb230ba4ad19b58984dc52e05b1073df5f ]
Commit
da244654c66e ("[SCSI] mac_esp: fix for quadras with two esp
chips") added mac_scsi_esp_intr() to handle the IRQ lines from a pair of
on-board ESP chips (a normal shared IRQ did not work).
Proper mutual exclusion was missing from that patch. This patch fixes
race conditions between comparison and assignment of esp_chips[]
pointers.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Reviewed-by: Michael Schmitz <schmitzmic@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maarten Maathuis [Mon, 24 Apr 2017 21:35:21 +0000 (23:35 +0200)]
platform/x86: intel-vbtn: add volume up and down
[ Upstream commit
8d9e29972836b75eb74f533594999500a4c7cc19 ]
Tested on HP Elite X2 1012 G1.
Matches event report of Lenovo Helix 2
(https://www.spinics.net/lists/ibm-acpi-devel/msg03982.html).
Signed-off-by: Maarten Maathuis <madman2003@shikahr.net>
[andy: fixed indentation of comments and massaged title of the change]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liping Zhang [Sun, 23 Apr 2017 10:29:30 +0000 (18:29 +0800)]
netfilter: nft_dynset: continue to next expr if _OP_ADD succeeded
[ Upstream commit
277a292835c196894ef895d5e1fd6170bb916f55 ]
Currently, after adding the following nft rules:
# nft add set x target1 { type ipv4_addr \; flags timeout \;}
# nft add rule x y set add ip daddr timeout 1d @target1 counter
the counters will always be zero despite of the elements are added
to the dynamic set "target1" or not, as we will break the nft expr
traversal unconditionally:
# nft list ruleset
...
set target1 {
...
elements = { 8.8.8.8 expires 23h59m53s}
}
chain output {
...
set add ip daddr timeout 1d @target1 counter packets 0 bytes 0
^ ^
...
}
Since we add the elements to the set successfully, we should continue
to the next expression.
Additionally, if elements are added to "flow table" successfully, we
will _always_ continue to the next expr, even if the operation is
_OP_ADD. So it's better to keep them to be consistent.
Fixes:
22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates")
Reported-by: Robert White <rwhite@pobox.com>
Signed-off-by: Liping Zhang <zlpnobody@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Sun, 23 Apr 2017 12:04:04 +0000 (20:04 +0800)]
qlcnic: fix unchecked return value
[ Upstream commit
91ec701a553cb3de470fd471c6fefe3ad1125455 ]
Function pci_find_ext_capability() may return 0, which is an invalid
address. In function qlcnic_sriov_virtid_fn(), its return value is used
without validation. This may result in invalid memory access bugs. This
patch fixes the bug.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Sun, 23 Apr 2017 09:38:35 +0000 (17:38 +0800)]
wan: pc300too: abort path on failure
[ Upstream commit
2a39e7aa8a98f777f0732ca7125b6c9668791760 ]
In function pc300_pci_init_one(), on the ioremap error path, function
pc300_pci_remove_one() is called to free the allocated memory. However,
the path is not terminated, and the freed memory will be used later,
resulting in use-after-free bugs. This path fixes the bug.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pan Bian [Sun, 23 Apr 2017 07:09:19 +0000 (15:09 +0800)]
tipc: check return value of nlmsg_new
[ Upstream commit
78302fd405769c9a9379e9adda119d533dce2eed ]
Function nlmsg_new() will return a NULL pointer if there is no enough
memory, and its return value should be checked before it is used.
However, in function tipc_nl_node_get_monitor(), the validation of the
return value of function nlmsg_new() is missed. This patch fixes the
bug.
Signed-off-by: Pan Bian <bianpan2016@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Mon, 10 Apr 2017 13:54:17 +0000 (16:54 +0300)]
mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()
[ Upstream commit
ec5ab8933772c87f24ad62a4a602fe8949f423c2 ]
devm_pinctrl_get() returns error pointers, it never returns NULL.
Fixes:
455e5cd6f736 ("mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>