Commit Graph

649827 Commits

Author SHA1 Message Date
Eyal Itkin
647bf3d8a8 IB/rxe: Fix mem_check_range integer overflow
Update the range check to avoid integer-overflow in edge case.
Resolves CVE 2016-8636.

Signed-off-by: Eyal Itkin <eyal.itkin@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2017-02-08 12:28:30 -05:00
Eyal Itkin
628f07d33c IB/rxe: Fix resid update
Update the response's resid field when larger than MTU, instead of only
updating the local resid variable.

Fixes: 8700e3e7c4 ("Soft RoCE driver")
Signed-off-by: Eyal Itkin <eyal.itkin@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Leon Romanovsky <leonro@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
2017-02-08 12:28:30 -05:00
Marcus Huewe
a11a7f71ca ipv6: addrconf: fix generation of new temporary addresses
Under some circumstances it is possible that no new temporary addresses
will be generated.

For instance, addrconf_prefix_rcv_add_addr() indirectly calls
ipv6_create_tempaddr(), which creates a tentative temporary address and
starts dad. Next, addrconf_prefix_rcv_add_addr() indirectly calls
addrconf_verify_rtnl(). Now, assume that the previously created temporary
address has the least preferred lifetime among all existing addresses and
is still tentative (that is, dad is still running). Hence, the next run of
addrconf_verify_rtnl() is performed when the preferred lifetime of the
temporary address ends. If dad succeeds before the next run, the temporary
address becomes deprecated during the next run, but no new temporary
address is generated.

In order to fix this, schedule the next addrconf_verify_rtnl() run slightly
before the temporary address becomes deprecated, if dad succeeded.

Signed-off-by: Marcus Huewe <suse-tux@gmx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-08 11:54:40 -05:00
Jeff Mahoney
2a36224918 btrfs: fix btrfs_compat_ioctl failures on non-compat ioctls
Commit 4c63c2454e incorrectly assumed that returning -ENOIOCTLCMD would
cause the native ioctl to be called.  The ->compat_ioctl callback is
expected to handle all ioctls, not just compat variants.  As a result,
when using 32-bit userspace on 64-bit kernels, everything except those
three ioctls would return -ENOTTY.

Fixes: 4c63c2454e ("btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl")
Cc: stable@vger.kernel.org
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
2017-02-08 17:47:30 +01:00
Nicholas Bellinger
9b2792c3da target: Fix COMPARE_AND_WRITE ref leak for non GOOD status
This patch addresses a long standing bug where the commit phase
of COMPARE_AND_WRITE would result in a se_cmd->cmd_kref reference
leak if se_cmd->scsi_status returned non SAM_STAT_GOOD.

This would manifest first as a lost SCSI response, and eventual
hung task during fabric driver logout or re-login, as existing
shutdown logic waited for the COMPARE_AND_WRITE se_cmd->cmd_kref
to reach zero.

To address this bug, compare_and_write_post() has been changed
to drop the incorrect !cmd->scsi_status conditional that was
preventing *post_ret = 1 for being set during non SAM_STAT_GOOD
status.

This patch has been tested with SAM_STAT_CHECK_CONDITION status
from normal target_complete_cmd() callback path, as well as the
incoming __target_execute_cmd() submission failure path when
se_cmd->execute_cmd() returns non zero status.

Reported-by: Donald White <dew@datera.io>
Cc: Donald White <dew@datera.io>
Tested-by: Gary Guo <ghg@datera.io>
Cc: Gary Guo <ghg@datera.io>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: <stable@vger.kernel.org> # v3.12+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2017-02-08 08:25:39 -08:00
Nicholas Bellinger
01d4d67355 target: Fix multi-session dynamic se_node_acl double free OOPs
This patch addresses a long-standing bug with multi-session
(eg: iscsi-target + iser-target) se_node_acl dynamic free
withini transport_deregister_session().

This bug is caused when a storage endpoint is configured with
demo-mode (generate_node_acls = 1 + cache_dynamic_acls = 1)
initiators, and initiator login creates a new dynamic node acl
and attaches two sessions to it.

After that, demo-mode for the storage instance is disabled via
configfs (generate_node_acls = 0 + cache_dynamic_acls = 0) and
the existing dynamic acl is never converted to an explicit ACL.

The end result is dynamic acl resources are released twice when
the sessions are shutdown in transport_deregister_session().

If the storage instance is not changed to disable demo-mode,
or the dynamic acl is converted to an explict ACL, or there
is only a single session associated with the dynamic ACL,
the bug is not triggered.

To address this big, move the release of dynamic se_node_acl
memory into target_complete_nacl() so it's only freed once
when se_node_acl->acl_kref reaches zero.

(Drop unnecessary list_del_init usage - HCH)

Reported-by: Rob Millner <rlm@daterainc.com>
Tested-by: Rob Millner <rlm@daterainc.com>
Cc: Rob Millner <rlm@daterainc.com>
Cc: stable@vger.kernel.org # 4.1+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2017-02-08 08:25:23 -08:00
Nicholas Bellinger
c54eeffbe9 target: Fix early transport_generic_handle_tmr abort scenario
This patch fixes a bug where incoming task management requests
can be explicitly aborted during an active LUN_RESET, but who's
struct work_struct are canceled in-flight before execution.

This occurs when core_tmr_drain_tmr_list() invokes cancel_work_sync()
for the incoming se_tmr_req->task_cmd->work, resulting in cmd->work
for target_tmr_work() never getting invoked and the aborted TMR
waiting indefinately within transport_wait_for_tasks().

To address this case, perform a CMD_T_ABORTED check early in
transport_generic_handle_tmr(), and invoke the normal path via
transport_cmd_check_stop_to_fabric() to complete any TMR kthreads
blocked waiting for CMD_T_STOP in transport_wait_for_tasks().

Also, move the TRANSPORT_ISTATE_PROCESSING assignment earlier
into transport_generic_handle_tmr() so the existing check in
core_tmr_drain_tmr_list() avoids attempting abort the incoming
se_tmr_req->task_cmd->work if it has already been queued into
se_device->tmr_wq.

Reported-by: Rob Millner <rlm@daterainc.com>
Tested-by: Rob Millner <rlm@daterainc.com>
Cc: Rob Millner <rlm@daterainc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2017-02-08 07:47:19 -08:00
Nicholas Bellinger
0583c261e6 target: Use correct SCSI status during EXTENDED_COPY exception
This patch adds the missing target_complete_cmd() SCSI status
parameter change in target_xcopy_do_work(), that was originally
missing in commit 926317de33.

It correctly propigates up the correct SCSI status during
EXTENDED_COPY exception cases, instead of always using the
hardcoded SAM_STAT_CHECK_CONDITION from original code.

This is required for ESX host environments that expect to
hit SAM_STAT_RESERVATION_CONFLICT for certain scenarios,
and SAM_STAT_CHECK_CONDITION results in non-retriable
status for these cases.

Reported-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Tested-by: Nixon Vincent <nixon.vincent@calsoftinc.com>
Cc: Nixon Vincent <nixon.vincent@calsoftinc.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org # 3.14+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2017-02-08 07:46:54 -08:00
Nicholas Bellinger
391e2a6de9 target: Don't BUG_ON during NodeACL dynamic -> explicit conversion
After the v4.2+ RCU conversion to se_node_acl->lun_entry_hlist,
a BUG_ON() was added in core_enable_device_list_for_node() to
detect when the located orig->se_lun_acl contains an existing
se_lun_acl pointer reference.

However, this scenario can happen when a dynamically generated
NodeACL is being converted to an explicit NodeACL, when the
explicit NodeACL contains a different LUN mapping than the
default provided by the WWN endpoint.

So instead of triggering BUG_ON(), go ahead and fail instead
following the original pre RCU conversion logic.

Reported-by: Benjamin ESTRABAUD <ben.estrabaud@mpstor.com>
Cc: Benjamin ESTRABAUD <ben.estrabaud@mpstor.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2017-02-08 07:46:31 -08:00
Benjamin Herrenschmidt
d7df2443cd powerpc/mm: Fix spurrious segfaults on radix with autonuma
When autonuma (Automatic NUMA balancing) marks a PTE inaccessible it
clears all the protection bits but leave the PTE valid.

With the Radix MMU, an attempt at executing from such a PTE will
take a fault with bit 35 of SRR1 set "SRR1_ISI_N_OR_G".

It is thus incorrect to treat all such faults as errors. We should
pass them to handle_mm_fault() for autonuma to deal with. The case
of pages that are really not executable is handled by the existing
test for VM_EXEC further down.

That leaves us with catching the kernel attempts at executing user
pages. We can catch that earlier, even before we do find_vma.

It is never valid on powerpc for the kernel to take an exec fault
to begin with. So fold that test with the existing test for the
kernel faulting on kernel addresses to bail out early.

Fixes: 1d18ad0268 ("powerpc/mm: Detect instruction fetch denied and report")
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Acked-by: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
2017-02-08 23:36:29 +11:00
Takashi Iwai
4842e98f26 ALSA: seq: Fix race at creating a queue
When a sequencer queue is created in snd_seq_queue_alloc(),it adds the
new queue element to the public list before referencing it.  Thus the
queue might be deleted before the call of snd_seq_queue_use(), and it
results in the use-after-free error, as spotted by syzkaller.

The fix is to reference the queue object at the right time.

Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-02-08 12:42:37 +01:00
Michał Winiarski
6e7eb1783b drm/i915: Always convert incoming exec offsets to non-canonical
We're using non-canonical addresses in drm_mm, and we're making sure that
userspace is using canonical addressing - both in case of softpin
(verifying incoming offset) and when relocating (converting to canonical
when updating offset returned to userspace).
Unfortunately when considering the need for relocations, we're comparing
offset from userspace (in canonical form) with drm_mm node (in
non-canonical form), and as a result, we end up always relocating if our
offsets are in the "problematic" range.
Let's always convert the offsets to avoid the performance impact of
relocations.

Fixes: a5f0edf63b ("drm/i915: Avoid writing relocs with addresses in non-canonical form")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Reported-by: Michał Pyrzowski <michal.pyrzowski@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170207195559.18798-1-michal.winiarski@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 038c95a313)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-02-08 13:27:28 +02:00
Chris Wilson
83bf6d55c1 drm/i915: Remove overzealous fence warn on runtime suspend
The goal of the WARN was to catch when we are still actively using the
fence as we go into the runtime suspend. However, the reg->pin_count is
too coarse as it does not distinguish between exclusive ownership of the
fence register from activity.

I've not improved on the WARN, nor have we captured this WARN in an
exact igt, but it is showing up regularly in the wild:

[ 1915.935332] WARNING: CPU: 1 PID: 10861 at drivers/gpu/drm/i915/i915_gem.c:2022 i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.935383] WARN_ON(reg->pin_count)[ 1915.935399] Modules linked in:
 snd_hda_intel i915 drm_kms_helper vgem netconsole scsi_transport_iscsi fuse vfat fat x86_pkg_temp_thermal coretemp intel_cstate intel_uncore snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm snd_timer snd mei_me mei serio_raw intel_rapl_perf intel_pch_thermal soundcore wmi acpi_pad i2c_algo_bit syscopyarea sysfillrect sysimgblt fb_sys_fops drm r8169 mii video [last unloaded: drm_kms_helper]
[ 1915.935785] CPU: 1 PID: 10861 Comm: kworker/1:0 Tainted: G     U  W       4.9.0-rc5+ #170
[ 1915.935799] Hardware name: LENOVO 80MX/Lenovo E31-80, BIOS DCCN34WW(V2.03) 12/01/2015
[ 1915.935822] Workqueue: pm pm_runtime_work
[ 1915.935845]  ffffc900044fbbf0 ffffffffac3220bc ffffc900044fbc40 0000000000000000
[ 1915.935890]  ffffc900044fbc30 ffffffffac059bcb 000007e6044fbc60 ffff8801626e3198
[ 1915.935937]  ffff8801626e0000 0000000000000002 ffffffffc05e5d4e 0000000000000000
[ 1915.935985] Call Trace:
[ 1915.936013]  [<ffffffffac3220bc>] dump_stack+0x4f/0x73
[ 1915.936038]  [<ffffffffac059bcb>] __warn+0xcb/0xf0
[ 1915.936060]  [<ffffffffac059c4f>] warn_slowpath_fmt+0x5f/0x80
[ 1915.936158]  [<ffffffffc052d916>] i915_gem_runtime_suspend+0x116/0x130 [i915]
[ 1915.936251]  [<ffffffffc04f1c74>] intel_runtime_suspend+0x64/0x280 [i915]
[ 1915.936277]  [<ffffffffac0926f1>] ? dequeue_entity+0x241/0xbc0
[ 1915.936298]  [<ffffffffac36bb85>] pci_pm_runtime_suspend+0x55/0x180
[ 1915.936317]  [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936339]  [<ffffffffac4514e2>] __rpm_callback+0x32/0x70
[ 1915.936356]  [<ffffffffac451544>] rpm_callback+0x24/0x80
[ 1915.936375]  [<ffffffffac36bb30>] ? pci_pm_runtime_resume+0xa0/0xa0
[ 1915.936392]  [<ffffffffac45222d>] rpm_suspend+0x12d/0x680
[ 1915.936415]  [<ffffffffac69f6d7>] ? _raw_spin_unlock_irq+0x17/0x30
[ 1915.936435]  [<ffffffffac0810b8>] ? finish_task_switch+0x88/0x220
[ 1915.936455]  [<ffffffffac4534bf>] pm_runtime_work+0x6f/0xb0
[ 1915.936477]  [<ffffffffac074353>] process_one_work+0x1f3/0x4d0
[ 1915.936501]  [<ffffffffac074678>] worker_thread+0x48/0x4e0
[ 1915.936523]  [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0
[ 1915.936542]  [<ffffffffac074630>] ? process_one_work+0x4d0/0x4d0
[ 1915.936559]  [<ffffffffac07a2c9>] kthread+0xd9/0xf0
[ 1915.936580]  [<ffffffffac07a1f0>] ? kthread_park+0x60/0x60
[ 1915.936600]  [<ffffffffac69fe62>] ret_from_fork+0x22/0x30

In the case the register is pinned, it should be present and we will
need to invalidate them to be restored upon resume as we cannot expect
the owner of the pin to call get_fence prior to use after resume.

Fixes: 7c108fd8fe ("drm/i915: Move fence cancellation to runtime suspend")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98804
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Imre Deak <imre.deak@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170203125717.8431-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
(cherry picked from commit e0ec3ec698)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-02-08 13:27:27 +02:00
Lee, Shawn C
789ea12500 drm/i915/bxt: Add MST support when do DPLL calculation
Add the missing INTEL_OUTPUT_DP_MST case in bxt_get_dpll()
to correctly initialize the crtc_state and port plls when
link training a DP MST monitor on BXT/APL devices.

Fixes: a277ca7dc0 ("drm/i915: Split bxt_ddi_pll_select()")
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99572
Reviewed-by: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Gary C Wang <gary.c.wang@intel.com>
Reviewed-by: Ciobanu, Nathan D <nathan.d.ciobanu@intel.com>
Reviewed-by: Herbert, Marc <marc.herbert@intel.com>
Reviewed-by: Bride, Jim <jim.bride@intel.com>
Reviewed-by: Navare, Manasi D <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: <stable@vger.kernel.org> # v4.9+
Signed-off-by: Lee, Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1486096329-6255-1-git-send-email-shawn.c.lee@intel.com
(cherry picked from commit 0aab2c721d)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-02-08 13:27:27 +02:00
Jean-Nicolas Graux
5cad24d835 mmc: mmci: avoid clearing ST Micro busy end interrupt mistakenly
This fixes a race condition that may occur whenever ST micro busy end
interrupt is raised just after being unmasked but before leaving mmci
interrupt context.

A dead-lock has been found if connecting mmci ST Micro variant whose amba
id is 0x10480180 to some new eMMC that supports internal caches.  Whenever
mmci driver enables cache control by programming eMMC's EXT_CSD register,
block driver may request to flush the eMMC internal caches causing mmci
driver to send a MMC_SWITCH command to the card with FLUSH_CACHE operation.
And because busy end interrupt may be mistakenly cleared while not yet
processed, this mmc request may never complete.  As a result, mmcqd task
may be stuck forever.

Here is an instance caught by lockup detector which shows that mmcqd task
was hung while waiting for mmc_flush_cache command to complete:

..
[  240.251595] INFO: task mmcqd/1:52 blocked for more than 120 seconds.
[  240.257973]       Not tainted 4.1.13-00510-g9d91424 #2
[  240.263109] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.270955] mmcqd/1         D c047504c     0    52      2 0x00000000
[  240.277359] [<c047504c>] (__schedule) from [<c04754a0>] (schedule+0x40/0x98)
[  240.284418] [<c04754a0>] (schedule) from [<c0477d40>] (schedule_timeout+0x148/0x188)
[  240.292191] [<c0477d40>] (schedule_timeout) from [<c0476040>] (wait_for_common+0xa4/0x170)
[  240.300491] [<c0476040>] (wait_for_common) from [<c02efc1c>] (mmc_wait_for_req_done+0x4c/0x13c)
[  240.309224] [<c02efc1c>] (mmc_wait_for_req_done) from [<c02efd90>] (mmc_wait_for_cmd+0x64/0x84)
[  240.317953] [<c02efd90>] (mmc_wait_for_cmd) from [<c02f5b14>] (__mmc_switch+0xa4/0x2a8)
[  240.325964] [<c02f5b14>] (__mmc_switch) from [<c02f5d40>] (mmc_switch+0x28/0x30)
[  240.333389] [<c02f5d40>] (mmc_switch) from [<c02f0984>] (mmc_flush_cache+0x54/0x80)
[  240.341073] [<c02f0984>] (mmc_flush_cache) from [<c02ff0c4>] (mmc_blk_issue_rq+0x114/0x4e8)
[  240.349459] [<c02ff0c4>] (mmc_blk_issue_rq) from [<c03008d4>] (mmc_queue_thread+0xc0/0x180)
[  240.357844] [<c03008d4>] (mmc_queue_thread) from [<c003cf90>] (kthread+0xdc/0xf4)
[  240.365339] [<c003cf90>] (kthread) from [<c0010068>] (ret_from_fork+0x14/0x2c)
..
..
[  240.664311] INFO: task partprobe:564 blocked for more than 120 seconds.
[  240.670943]       Not tainted 4.1.13-00510-g9d91424 #2
[  240.676078] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  240.683922] partprobe       D c047504c     0   564    486 0x00000000
[  240.690318] [<c047504c>] (__schedule) from [<c04754a0>] (schedule+0x40/0x98)
[  240.697396] [<c04754a0>] (schedule) from [<c0477d40>] (schedule_timeout+0x148/0x188)
[  240.705149] [<c0477d40>] (schedule_timeout) from [<c0476040>] (wait_for_common+0xa4/0x170)
[  240.713446] [<c0476040>] (wait_for_common) from [<c01f3300>] (submit_bio_wait+0x58/0x64)
[  240.721571] [<c01f3300>] (submit_bio_wait) from [<c01fbbd8>] (blkdev_issue_flush+0x60/0x88)
[  240.729957] [<c01fbbd8>] (blkdev_issue_flush) from [<c010ff84>] (blkdev_fsync+0x34/0x44)
[  240.738083] [<c010ff84>] (blkdev_fsync) from [<c0109594>] (do_fsync+0x3c/0x64)
[  240.745319] [<c0109594>] (do_fsync) from [<c000ffc0>] (ret_fast_syscall+0x0/0x3c)
..

Here is the detailed sequence showing when this issue may happen:

1) At probe time, mmci device is initialized and card busy detection based
on DAT[0] monitoring is enabled.

2) Later during run time, since card reported to support internal caches, a
MMCI_SWITCH command is sent to eMMC device with FLUSH_CACHE operation. On
receiving this command, eMMC may enter busy state (for a relatively short
time in the case of the dead-lock).

3) Then mmci interrupt is raised and mmci_irq() is called:

MMCISTATUS register is read and is equal to 0x01000440. So the following
status bits are set:
- MCI_CMDRESPEND (= 6)
- MCI_DATABLOCKEND (= 10)
- MCI_ST_CARDBUSY (= 24)

Since MMCIMASK0 register is 0x3FF, status variable is set to 0x00000040 and
BIT MCI_CMDRESPEND is cleared by writing MMCICLEAR register.

Then mmci_cmd_irq() is called. Considering the following conditions:
- host->busy_status is 0,
- this is a "busy response",
- reading again MMCISTATUS register gives 0x1000400,
MMCIMASK0 is updated to unmask MCI_ST_BUSYEND bit.

Thus, MMCIMASK0 is set to 0x010003FF and host->busy_status is set to wait
for busy end completion.

Back again in status loop of mmci_irq(), we quickly go through
mmci_data_irq() as there are no data in that case.  And we finally go
through following test at the end of while(status) loop:

/*
 * Don't poll for busy completion in irq context.
 */
if (host->variant->busy_detect && host->busy_status)
	status &= ~host->variant->busy_detect_flag;

Because status variable is not yet null (is equal to 0x40), we do not leave
interrupt context yet but we loop again into while(status) loop. So we run
across following steps:

a) MMCISTATUS register is read again and this time is equal to 0x01000400.
So that following bits are set:
- MCI_DATABLOCKEND (= 10)
- MCI_ST_CARDBUSY (= 24)

Since MMCIMASK0 register is equal to 0x010003FF:

b) status variable is set to 0x01000000.
c) MCI_ST_CARDBUSY bit is cleared by writing MMCICLEAR register.

Then, mmci_cmd_irq() is called one more time. Since host->busy_status is
set and that MCI_ST_CARDBUSY is set in status variable, we just return from
this function.

Back again in mmci_irq(), status variable is set to 0 and we finally leave
the while(status) loop. As a result we leave interrupt context, waiting for
busy end interrupt event.

Now, consider that busy end completion is raised IN BETWEEN steps 3.a) and
3.c). In such a case, we may mistakenly clear busy end interrupt at step
3.c) while it has not yet been processed. This will result in mmc command
to wait forever for a busy end completion that will never happen.

To fix the problem, this patch implements the following changes:

Considering that the mmci seems to be triggering the IRQ on both edges
while monitoring DAT0 for busy completion and that same status bit is used
to monitor start and end of busy detection, special care must be taken to
make sure that both start and end interrupts are always cleared one after
the other.

1) Clearing of card busy bit is moved in mmc_cmd_irq() function where
unmasking of busy end bit is effectively handled.
2) Just before unmasking busy end event, busy start event is cleared by
writing card busy bit in MMCICLEAR register.
3) Finally, once we are no more busy with a command, busy end event is
cleared writing again card busy bit in MMCICLEAR register.

This patch has been tested with the ST Accordo5 machine, not yet supported
upstream but relies on the mmci driver.

Signed-off-by: Sarang Mairal <sarang.mairal@garmin.com>
Signed-off-by: Jean-Nicolas Graux <jean-nicolas.graux@st.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-08 12:22:27 +01:00
Jani Nikula
8532774811 drm/i915: don't warn about Skylake CPU - KabyPoint PCH combo
Apparently there are machines out there with Skylake CPU and KabyPoint
PCH. Judging from our driver code, there doesn't seem to be any code
paths that would do anything different between SunrisePoint and
KabyPoint PCHs, so it would seem okay to accept the combo without
warnings.

Fixes: 22dea0be50 ("drm/i915: Introduce Kabypoint PCH for Kabylake H/DT.")
References: https://lists.freedesktop.org/archives/intel-gfx/2017-February/118611.html
Reported-by: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Cc: Rainer Koenig <Rainer.Koenig@ts.fujitsu.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v4.8+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1485956769-26015-1-git-send-email-jani.nikula@intel.com
(cherry picked from commit 3aac4acb89)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-02-08 13:10:36 +02:00
Juergen Gross
7152187159 drm/i915: fix i915 running as dom0 under Xen
Commit 920cf41949 ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.

Reason seems to be a missing adaption similar to that done in
commit 7453c549f5 ("swiotlb: Export swiotlb_max_segment to users")
to i915_gem_object_get_pages_internal().

So limit the maximum page order to be used according to the maximum
swiotlb segment size instead to the complete swiotlb size.

Fixes: 920cf41949 ("drm/i915: Introduce an internal allocator for disposable private objects")
Signed-off-by: Juergen Gross <jgross@suse.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170202094711.939-1-jgross@suse.com
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(cherry picked from commit 5584f1b1d7)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-02-08 13:10:30 +02:00
Chris Wilson
e3818697e1 drm/i915: Flush untouched framebuffers before display on !llc
On a non-llc system, the objects are created with .cache_level =
CACHE_NONE and so the transition to uncached for scanout is a no-op.
However, if the object was never written to, it will still be in the CPU
domain (having been zeroed out by shmemfs). Those cachelines need to be
flushed prior to display.

Reported-and-tested-by: Vito Caputo
Fixes: a6a7cc4b7d ("drm/i915: Always flush the dirty CPU cache when pinning the scanout")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.10-rc1+
Link: http://patchwork.freedesktop.org/patch/msgid/20170109111932.6342-1-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 69aeafeae9)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-02-08 13:10:24 +02:00
Andrey Ryabinin
5351fbb1bf drm/i915: fix use-after-free in page_flip_completed()
page_flip_completed() dereferences 'work' variable after executing
queue_work(). This is not safe as the 'work' item might be already freed
by queued work:

    BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr ffff8803dc010f90
    Call Trace:
     __asan_report_load8_noabort+0x59/0x80
     page_flip_completed+0x3ff/0x490
     intel_finish_page_flip_mmio+0xe3/0x130
     intel_pipe_handle_vblank+0x2d/0x40
     gen8_irq_handler+0x4a7/0xed0
     __handle_irq_event_percpu+0xf6/0x860
     handle_irq_event_percpu+0x6b/0x160
     handle_irq_event+0xc7/0x1b0
     handle_edge_irq+0x1f4/0xa50
     handle_irq+0x41/0x70
     do_IRQ+0x9a/0x200
     common_interrupt+0x89/0x89

    Freed:
     kfree+0x113/0x4d0
     intel_unpin_work_fn+0x29a/0x3b0
     process_one_work+0x79e/0x1b70
     worker_thread+0x611/0x1460
     kthread+0x241/0x3a0
     ret_from_fork+0x27/0x40

Move queue_work() after	trace_i915_flip_complete() to fix this.

Fixes: e5510fac98 ("drm/i915: add tracepoints for flip requests & completions")
Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: <stable@vger.kernel.org> # v2.6.36+
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170126143211.24013-1-aryabinin@virtuozzo.com
(cherry picked from commit 05c41f926f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-02-08 13:09:24 +02:00
Stephen Smalley
0c461cb727 selinux: fix off-by-one in setprocattr
SELinux tries to support setting/clearing of /proc/pid/attr attributes
from the shell by ignoring terminating newlines and treating an
attribute value that begins with a NUL or newline as an attempt to
clear the attribute.  However, the test for clearing attributes has
always been wrong; it has an off-by-one error, and this could further
lead to reading past the end of the allocated buffer since commit
bb646cdb12 ("proc_pid_attr_write():
switch to memdup_user()").  Fix the off-by-one error.

Even with this fix, setting and clearing /proc/pid/attr attributes
from the shell is not straightforward since the interface does not
support multiple write() calls (so shells that write the value and
newline separately will set and then immediately clear the attribute,
requiring use of echo -n to set the attribute), whereas trying to use
echo -n "" to clear the attribute causes the shell to skip the
write() call altogether since POSIX says that a zero-length write
causes no side effects. Thus, one must use echo -n to set and echo
without -n to clear, as in the following example:
$ echo -n unconfined_u:object_r:user_home_t:s0 > /proc/$$/attr/fscreate
$ cat /proc/$$/attr/fscreate
unconfined_u:object_r:user_home_t:s0
$ echo "" > /proc/$$/attr/fscreate
$ cat /proc/$$/attr/fscreate

Note the use of /proc/$$ rather than /proc/self, as otherwise
the cat command will read its own attribute value, not that of the shell.

There are no users of this facility to my knowledge; possibly we
should just get rid of it.

UPDATE: Upon further investigation it appears that a local process
with the process:setfscreate permission can cause a kernel panic as a
result of this bug.  This patch fixes CVE-2017-2618.

Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
[PM: added the update about CVE-2017-2618 to the commit description]
Cc: stable@vger.kernel.org # 3.5: d6ea83ec68
Signed-off-by: Paul Moore <paul@paul-moore.com>

Signed-off-by: James Morris <james.l.morris@oracle.com>
2017-02-08 19:09:53 +11:00
Omar Sandoval
bfeda41d06 stacktrace, lockdep: Fix address, newline ugliness
Since KERN_CONT became meaningful again, lockdep stack traces have had
annoying extra newlines, like this:

[    5.561122] -> #1 (B){+.+...}:
[    5.561528]
[    5.561532] [<ffffffff810d8873>] lock_acquire+0xc3/0x210
[    5.562178]
[    5.562181] [<ffffffff816f6414>] mutex_lock_nested+0x74/0x6d0
[    5.562861]
[    5.562880] [<ffffffffa01aa3c3>] init_btrfs_fs+0x21/0x196 [btrfs]
[    5.563717]
[    5.563721] [<ffffffff81000472>] do_one_initcall+0x52/0x1b0
[    5.564554]
[    5.564559] [<ffffffff811a3af6>] do_init_module+0x5f/0x209
[    5.565357]
[    5.565361] [<ffffffff81122f4d>] load_module+0x218d/0x2b80
[    5.566020]
[    5.566021] [<ffffffff81123beb>] SyS_finit_module+0xeb/0x120
[    5.566694]
[    5.566696] [<ffffffff816fd241>] entry_SYSCALL_64_fastpath+0x1f/0xc2

That's happening because each printk() call now gets printed on its own
line, and we do a separate call to print the spaces before the symbol.
Fix it by doing the printk() directly instead of using the
print_ip_sym() helper.

Additionally, the symbol address isn't very helpful, so let's get rid of
that, too. The final result looks like this:

[    5.194518] -> #1 (B){+.+...}:
[    5.195002]        lock_acquire+0xc3/0x210
[    5.195439]        mutex_lock_nested+0x74/0x6d0
[    5.196491]        do_one_initcall+0x52/0x1b0
[    5.196939]        do_init_module+0x5f/0x209
[    5.197355]        load_module+0x218d/0x2b80
[    5.197792]        SyS_finit_module+0xeb/0x120
[    5.198251]        entry_SYSCALL_64_fastpath+0x1f/0xc2

Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: kernel-team@fb.com
Fixes: 4bcc595ccd ("printk: reinstate KERN_CONT for printing continuation lines")
Link: http://lkml.kernel.org/r/43b4e114724b2bdb0308fa86cb33aa07d3d67fad.1486510315.git.osandov@fb.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-02-08 08:21:31 +01:00
Dave Airlie
5d18a61997 Merge branch 'drm-vmwgfx-fixes-4_10' of git://people.freedesktop.org/~syeh/repos_linux into drm-fixes
Single vmwgfx boot crasher fix.

* 'drm-vmwgfx-fixes-4_10' of git://people.freedesktop.org/~syeh/repos_linux:
  drm/vmwgfx: Fix depth input into drm_mode_legacy_fb_format
2017-02-08 12:05:02 +10:00
Arnd Bergmann
413d373267 Input: synaptics-rmi4 - select 'SERIO' when needed
With CONFIG_SERIO=m, we get a build error for the rmi4-f03 driver,
added in linux-4.10:

warning: (HID_RMI) selects RMI4_F03 which has unmet direct dependencies (!UML && INPUT && RMI4_CORE && (SERIO=y || RMI4_CORE=SERIO))
drivers/input/built-in.o: In function `rmi_f03_attention':
rmi_f03.c:(.text+0xcfe0): undefined reference to `serio_interrupt'
rmi_f03.c:(.text+0xd055): undefined reference to `serio_interrupt'
drivers/input/built-in.o: In function `rmi_f03_remove':
rmi_f03.c:(.text+0xd115): undefined reference to `serio_unregister_port'
drivers/input/built-in.o: In function `rmi_f03_probe':
rmi_f03.c:(.text+0xd209): undefined reference to `__serio_register_port'

An earlier patch tried to fix this, but missed the HID_RMI driver that
does a 'select' on the F03 backend.

This adds a hidden Kconfig symbol that enforces 'serio' to be enabled
when RMI4-F03 is, which covers all cases.

Fixes: d7ddad0acc ("Input: synaptics-rmi4 - fix F03 build error when serio is module")
Fixes: c5e8848fc9 ("Input: synaptics-rmi4 - add support for F03")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
2017-02-07 14:31:45 -08:00
Linus Torvalds
926af6273f Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
Pull networking fixes from David Miller:

 1) Load correct firmware in rtl8192ce wireless driver, from Jurij
    Smakov.

 2) Fix leak of tx_ring and tx_cq due to overwriting in mlx4 driver,
    from Martin KaFai Lau.

 3) Need to reference count PHY driver module when it is attached, from
    Mao Wenan.

 4) Don't do zero length vzalloc() in ethtool register dump, from
    Stanislaw Gruszka.

 5) Defer net_disable_timestamp() to a workqueue to get out of locking
    issues, from Eric Dumazet.

 6) We cannot drop the SKB dst when IP options refer to them, fix also
    from Eric Dumazet.

 7) Incorrect packet header offset calculations in ip6_gre, again from
    Eric Dumazet.

 8) Missing tcp_v6_restore_cb() causes use-after-free, from Eric too.

 9) tcp_splice_read() can get into an infinite loop with URG, and hey
    it's from Eric once more.

10) vnet_hdr_sz can change asynchronously, so read it once during
    decision making in macvtap and tun, from Willem de Bruijn.

11) Can't use kernel stack for DMA transfers in USB networking drivers,
    from Ben Hutchings.

12) Handle csum errors properly in UDP by calling the proper destructor,
    from Eric Dumazet.

13) For non-deterministic softirq run when scheduling NAPI from a
    workqueue in mlx4, from Benjamin Poirier.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (28 commits)
  sctp: check af before verify address in sctp_addr_id2transport
  sctp: avoid BUG_ON on sctp_wait_for_sndbuf
  mlx4: Invoke softirqs after napi_reschedule
  udp: properly cope with csum errors
  catc: Use heap buffer for memory size test
  catc: Combine failure cleanup code in catc_probe()
  rtl8150: Use heap buffers for all register access
  pegasus: Use heap buffers for all register access
  macvtap: read vnet_hdr_size once
  tun: read vnet_hdr_sz once
  tcp: avoid infinite loop in tcp_splice_read()
  hns: avoid stack overflow with CONFIG_KASAN
  ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches
  ipv6: tcp: add a missing tcp_v6_restore_cb()
  nl80211: Fix mesh HT operation check
  mac80211: Fix adding of mesh vendor IEs
  mac80211: Allocate a sync skcipher explicitly for FILS AEAD
  mac80211: Fix FILS AEAD protection in Association Request frame
  ip6_gre: fix ip6gre_err() invalid reads
  netlabel: out of bound access in cipso_v4_validate()
  ...
2017-02-07 12:10:57 -08:00
Hugh Dickins
b6789123bc mm: fix KPF_SWAPCACHE in /proc/kpageflags
Commit 6326fec112 ("mm: Use owner_priv bit for PageSwapCache, valid
when PageSwapBacked") aliased PG_swapcache to PG_owner_priv_1 (and
depending on PageSwapBacked being true).

As a result, the KPF_SWAPCACHE bit in '/proc/kpageflags' should now be
synthesized, instead of being shown on unrelated pages which just happen
to have PG_owner_priv_1 set.

Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-07 12:08:32 -08:00
Xin Long
912964eacb sctp: check af before verify address in sctp_addr_id2transport
Commit 6f29a13061 ("sctp: sctp_addr_id2transport should verify the
addr before looking up assoc") invoked sctp_verify_addr to verify the
addr.

But it didn't check af variable beforehand, once users pass an address
with family = 0 through sockopt, sctp_get_af_specific will return NULL
and NULL pointer dereference will be caused by af->sockaddr_len.

This patch is to fix it by returning NULL if af variable is NULL.

Fixes: 6f29a13061 ("sctp: sctp_addr_id2transport should verify the addr before looking up assoc")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 14:07:23 -05:00
Alexey Kardashevskiy
930a42ded3 vfio/spapr_tce: Set window when adding additional groups to container
If a container already has a group attached, attaching a new group
should just program already created IOMMU tables to the hardware via
the iommu_table_group_ops::set_window() callback.

However commit 6f01cc692a ("vfio/spapr: Add a helper to create
default DMA window") did not just simplify the code but also removed
the set_window() calls in the case of attaching groups to a container
which already has tables so it broke VFIO PCI hotplug.

This reverts set_window() bits in tce_iommu_take_ownership_ddw().

Fixes: 6f01cc692a ("vfio/spapr: Add a helper to create default DMA window")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-02-07 11:48:16 -07:00
Vineet Gupta
a524c218bc ARC: [arcompact] brown paper bag bug in unaligned access delay slot fixup
Reported-by: Jo-Philipp Wich <jo@mein.io>
Fixes: 9aed02feae ("ARC: [arcompact] handle unaligned access delay slot")
Cc: linux-kernel@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2017-02-07 10:02:01 -08:00
Marcelo Ricardo Leitner
2dcab59848 sctp: avoid BUG_ON on sctp_wait_for_sndbuf
Alexander Popov reported that an application may trigger a BUG_ON in
sctp_wait_for_sndbuf if the socket tx buffer is full, a thread is
waiting on it to queue more data and meanwhile another thread peels off
the association being used by the first thread.

This patch replaces the BUG_ON call with a proper error handling. It
will return -EPIPE to the original sendmsg call, similarly to what would
have been done if the association wasn't found in the first place.

Acked-by: Alexander Popov <alex.popov@linux.com>
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 12:54:59 -05:00
Benjamin Poirier
bd4ce941c8 mlx4: Invoke softirqs after napi_reschedule
mlx4 may schedule napi from a workqueue. Afterwards, softirqs are not run
in a deterministic time frame and the following message may be logged:
NOHZ: local_softirq_pending 08

The problem is the same as what was described in commit ec13ee8014
("virtio_net: invoke softirqs after __napi_schedule") and this patch
applies the same fix to mlx4.

Fixes: 07841f9d94 ("net/mlx4_en: Schedule napi when RX buffers allocation fails")
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Benjamin Poirier <bpoirier@suse.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 12:50:43 -05:00
Eric Dumazet
69629464e0 udp: properly cope with csum errors
Dmitry reported that UDP sockets being destroyed would trigger the
WARN_ON(atomic_read(&sk->sk_rmem_alloc)); in inet_sock_destruct()

It turns out we do not properly destroy skb(s) that have wrong UDP
checksum.

Thanks again to syzkaller team.

Fixes : 7c13f97ffd ("udp: do fwd memory scheduling on dequeue")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 11:19:00 -05:00
David S. Miller
6a413e269b Merge branch 'net-Fix-on-stack-USB-buffers'
Ben Hutchings says:

====================
net: Fix on-stack USB buffers

Allocating USB buffers on the stack is not portable, and no longer
works on x86_64 (with VMAP_STACK enabled as per default).  This
series fixes all the instances I could find where USB networking
drivers do that.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 10:07:03 -05:00
Ben Hutchings
2d6a0e9de0 catc: Use heap buffer for memory size test
Allocating USB buffers on the stack is not portable, and no longer
works on x86_64 (with VMAP_STACK enabled as per default).

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 10:07:02 -05:00
Ben Hutchings
d41149145f catc: Combine failure cleanup code in catc_probe()
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 10:07:02 -05:00
Ben Hutchings
7926aff5c5 rtl8150: Use heap buffers for all register access
Allocating USB buffers on the stack is not portable, and no longer
works on x86_64 (with VMAP_STACK enabled as per default).

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 10:07:02 -05:00
Ben Hutchings
5593523f96 pegasus: Use heap buffers for all register access
Allocating USB buffers on the stack is not portable, and no longer
works on x86_64 (with VMAP_STACK enabled as per default).

Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
References: https://bugs.debian.org/852556
Reported-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Tested-by: Lisandro Damián Nicanor Pérez Meyer <lisandro@debian.org>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-07 10:07:01 -05:00
Takashi Iwai
f3d83317a6 Revert "ALSA: line6: Only determine control port properties if needed"
This reverts commit f6a0dd107a.

The commit caused a regression on LINE6 Transport that has no control
caps.  Although reverting the commit may result back in a spurious
error message for some device again, it's the simplest regression fix,
hence it's taken as is at first.  The further code fix will follow
later.

Fixes: f6a0dd107a ("ALSA: line6: Only determine control port properties if needed")
Reported-by: Igor Zinovev <zinigor@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
2017-02-07 09:37:11 +01:00
David S. Miller
432d4f8ab0 Merge branch 'read-vnet_hdr_sz-once'
Willem de Bruijn says:

====================
read vnet_hdr_sz once

Tuntap devices allow concurrent use and update of field vnet_hdr_sz.
Read the field once to avoid TOCTOU.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-06 22:41:27 -05:00
Willem de Bruijn
837585a537 macvtap: read vnet_hdr_size once
When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
Data length is verified to be greater than or equal to expected header
length tun->vnet_hdr_sz before copying.

Macvtap functions read the value once, but unless READ_ONCE is used,
the compiler may ignore this and read multiple times. Enforce a single
read and locally cached value to avoid updates between test and use.

Signed-off-by: Willem de Bruijn <willemb@google.com>
Suggested-by: Eric Dumazet <edumazet@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-06 22:41:27 -05:00
Willem de Bruijn
e1edab87fa tun: read vnet_hdr_sz once
When IFF_VNET_HDR is enabled, a virtio_net header must precede data.
Data length is verified to be greater than or equal to expected header
length tun->vnet_hdr_sz before copying.

Read this value once and cache locally, as it can be updated between
the test and use (TOCTOU).

Signed-off-by: Willem de Bruijn <willemb@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
CC: Eric Dumazet <edumazet@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-06 22:41:27 -05:00
Eric Dumazet
ccf7abb93a tcp: avoid infinite loop in tcp_splice_read()
Splicing from TCP socket is vulnerable when a packet with URG flag is
received and stored into receive queue.

__tcp_splice_read() returns 0, and sk_wait_data() immediately
returns since there is the problematic skb in queue.

This is a nice way to burn cpu (aka infinite loop) and trigger
soft lockups.

Again, this gem was found by syzkaller tool.

Fixes: 9c55e01c0c ("[TCP]: Splice receive support.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Dmitry Vyukov  <dvyukov@google.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-06 22:38:55 -05:00
Linus Torvalds
8b1b41ee74 Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm
Pull libnvdimm fixes from Dan Williams:
 "None of these are showstoppers for 4.10 and could wait for 4.11 merge
  window, but they are low enough risk for this late in the cycle and
  the fixes have waiting users . They have received a build success
  notification from the 0day robot, pass the latest ndctl unit tests,
  and appeared in next:

   - Fix a crash that can result when SIGINT is sent to a process that
     is awaiting completion of an address range scrub command. We were
     not properly cleaning up the workqueue after
     wait_event_interruptible().

   - Fix a memory hotplug failure condition that results from not
     reserving enough space out of persistent memory for the memmap. By
     default we align to 2M allocations that the memory hotplug code
     assumes, but if the administrator specifies a non-default
     4K-alignment then we can fail to correctly size the reservation.

   - A one line fix to improve the predictability of libnvdimm block
     device names. A common operation is to reconfigure /dev/pmem0 into
     a different mode. For example, a reconfiguration might set a new
     mode that reserves some of the capacity for a struct page memmap
     array. It surprises users if the device name changes to
     "/dev/pmem0.1" after the mode change and then back to /dev/pmem0
     after a reboot.

   - Add 'const' to some function pointer tables"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
  libnvdimm, pfn: fix memmap reservation size versus 4K alignment
  acpi, nfit: fix acpi_nfit_flush_probe() crash
  libnvdimm, namespace: do not delete namespace-id 0
  nvdimm: constify device_type structures
2017-02-06 19:36:04 -08:00
Linus Torvalds
f7d6040aa4 Power management fixes for v4.10-rc8
- Add an intel_pstate driver quirk to work around a firmware setting
    that leads to frequency scaling issues on desktop Intel Kaby Lake
    processors in some configurations if the hardware-managed P-states
    (HWP) feature is in use (Srinivas Pandruvada).
 
  - Fix up the recently added brcmstb-avs cpufreq driver: fix a bug
    related to system suspend and change the sysfs interface to match
    the user space expectations (Markus Mayer).
 
  - Modify the runtime PM framework to avoid false-positive warnings
    from the might_sleep_if() assertions in it (Rafael Wysocki).
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2
 
 iQIcBAABCAAGBQJYmIOoAAoJEILEb/54YlRx2XgP/AjkxDOBep8mnY3xHNMvx887
 BjWWGkuO3qZiX/xFhkhlBuxx8zLfg3ie7NJiSpn1Lj0192M9ggwn4RrM61V1SBX6
 QTOeP68uueIIA/SCt2dw9DdEpepzyvwSJpUTqRmZubZAAYjcVHN+FLgNa5QzUdMb
 X73zORAXsOu4SAguS4MP3yvPvFfdsOwSexllfsK9IAd+eb5RSZYnNyHuwW+S8EK5
 zVCE+cwJOYU4SFh0speGpvUh7wXtWdYM3CV6mzrkiQqfvS6q29xillrxKWaEIk7Z
 5Y6sReFl6i/zIuFQnx0nKPNM5DUhiOY80ha5uaZzde+vRRR7EM7n6LaIQVp672A7
 mq6d0YxsJD8Z9Gx9r66oID/pfEkviRvRc4ejm0Xb187QN9jZvBhY85WD22X5p3KR
 B0B/mhN1zN8ruaLvitqKwXtTntq4ahLtjfxtsyYoH56kh8J6C5KNlJ985/q2hhLD
 8W1ZAaXPy+vyfODsnxdzfnYvkOgeY/XIg9NQ++QGdhXNwDBb1QZP34zdNsIF/YXR
 8A+usM8BAq4r2dDROFfxtCkIVH6JsMkqWVbrUPkM9hdIL2jF3IpRS9bXKBvDICMc
 ZsbDm4ihz+XtjVG4GxmrB5SZ2C3qPYwbmLBiu1CwfY7L6lN8azF0RmRJ0s2fpvAG
 d4nxEZa5ysPKEZfU6PyE
 =2NdR
 -----END PGP SIGNATURE-----

Merge tag 'pm-4.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

Pull power management fixes from Rafael Wysocki:
 "These add a quirk to intel_pstate to work around a firmware setting
  that leads to frequency scaling issues (discovered recently) on some
  Intel Kaby Lake processors, fix up the recently added brcmstb-avs
  cpufreq driver and avoid false-positive warnings from the runtime PM
  framework triggered by recent changes in i915.

  Specifics:

   - Add an intel_pstate driver quirk to work around a firmware setting
     that leads to frequency scaling issues on desktop Intel Kaby Lake
     processors in some configurations if the hardware-managed P-states
     (HWP) feature is in use (Srinivas Pandruvada)

   - Fix up the recently added brcmstb-avs cpufreq driver: fix a bug
     related to system suspend and change the sysfs interface to match
     the user space expectations (Markus Mayer)

   - Modify the runtime PM framework to avoid false-positive warnings
     from the might_sleep_if() assertions in it (Rafael Wysocki)"

* tag 'pm-4.10-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  PM / runtime: Avoid false-positive warnings from might_sleep_if()
  cpufreq: intel_pstate: Disable energy efficiency optimization
  cpufreq: brcmstb-avs-cpufreq: properly retrieve P-state upon suspend
  cpufreq: brcmstb-avs-cpufreq: extend sysfs entry brcm_avs_pmap
2017-02-06 15:11:04 -08:00
Linus Torvalds
50dcb6cdb7 - A fix for a race in .request_fn request-based DM request handling vs
DM device destruction
 
 - An RCU fix for dm-crypt's kernel keyring support that was included in
   4.10-rc1
 
 - A -Wbool-operation warning fix for DM multipath
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJYlKLnAAoJEMUj8QotnQNaUOcH/3OgBjsRuFpNmrW3bzzcpLUQ
 XH6R2YAc1/14BU6rUYY7vLA905n7Jw3VyyJGgl2cJUqaDqA/Qj6uBmwfOve019Fl
 xTzi8rMAas05zqs9b5SrRAtSt2z6eZnbpm8df+QjrFQZjsDzsl2+PLxR+emp9YIQ
 wXLAU4Re35v/jPUccoNB0Be0LARIh0dSPQYWCYPomYqFHBoioHinGBOJpeq8HXFp
 U+JRXPcjrFxs4zjKq8aRE1XhN7lqLt7uZ4gi43sRCgieWXApoOfmo634IINyZtCf
 WIjS92qbFeyZfMk65q+GzfUYM9ZdAvzwXMlHnECYSd+jfbz89DhKv7YOuyCf1CU=
 =RSQc
 -----END PGP SIGNATURE-----

Merge tag 'dm-4.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm

Pull device mapper fixes from Mike Snitzer:

 - a fix for a race in .request_fn request-based DM request handling vs
   DM device destruction

 - an RCU fix for dm-crypt's kernel keyring support that was included in
   4.10-rc1

 - a -Wbool-operation warning fix for DM multipath

* tag 'dm-4.10-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm crypt: replace RCU read-side section with rwsem
  dm rq: cope with DM device destruction while in dm_old_request_fn()
  dm mpath: cleanup -Wbool-operation warning in choose_pgpath()
2017-02-06 14:42:34 -08:00
Linus Torvalds
72df5eba70 media fixes for v4.10-rc8
-----BEGIN PGP SIGNATURE-----
 
 iQIcBAABAgAGBQJYmJDxAAoJEAhfPr2O5OEVFtkQAJHHkcc4H139Fdp0ThGLLLf/
 1VWAwQqWb/WmXMqIrE2fIQdEty8za8GvX6gQMsgeDS06GTlxtprnBeH/ZKlwrNR3
 akq/mwQPtJhOUe5uuAmgcGUOrIUIRfO0kmY6hZY+92MyxHbUbmSvpV6YHe81eWV1
 Emkwc4cMrir3RaCAsn2FgRnFRRpB58oi9TCe89LtLI4zzCMuTzEvEfG7O9u5WCcO
 SrhMv05M5XWIvEywoZsKcUW+vBZxZ6QvbG970MY5czW2WRs5GIoOnwskNYpo/bxy
 ttKmcgDXD63Wa2JPuEImLm8imyHhquJMKXCFrCRDvSWVw5p+xKDx5lX56cMhJYmr
 ZHG32Z7dsG2bfVLY5+L/B+4QhnBYqEehhgh/8oDhrR8POw+71L40aWCq5gC9cHp4
 fjNBRxII11i6AEqyMA2Dv+aSyeW3LSYBxV11h5F/Zef5fpa+WMgtHLjKKxRMOnzF
 lt81OC5yg3XWBRb4s/4xXghOOmMPFMPCo8LUbo3wB5wGNBtguBBXssZ2HIolrSCA
 /NAD01Eb29dRhtRXEqQYAhEuSiuob6ETdn+FktbtUeZl5ZUg7JfZ+A5MqTmH1l1u
 Ezl8I42BnkMuSc2gdkWh1eBJfrzNEytiW7EOZO4TMfi00PzlshwusQkXtRTUC5aC
 DG5W41QC2PolZnV8XcXs
 =nEM8
 -----END PGP SIGNATURE-----

Merge tag 'media/v4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

Pull media fixes from Mauro Carvalho Chehab:
 "A few documentation fixes at CEC (with got promoted from staging for
  4.10), and one fix on its core."

* tag 'media/v4.10-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] cec: fix wrong last_la determination
  [media] cec-intro.rst: mention the v4l-utils package and CEC utilities
  [media] cec rst: remove "This API is not yet finalized" notice
2017-02-06 14:37:55 -08:00
Linus Torvalds
396bf4cd83 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
Pull crypto fixes from Herbert Xu:

 - use-after-free in algif_aead

 - modular aesni regression when pcbc is modular but absent

 - bug causing IO page faults in ccp

 - double list add in ccp

 - NULL pointer dereference in qat (two patches)

 - panic in chcr

 - NULL pointer dereference in chcr

 - out-of-bound access in chcr

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  crypto: chcr - Fix key length for RFC4106
  crypto: algif_aead - Fix kernel panic on list_del
  crypto: aesni - Fix failure when pcbc module is absent
  crypto: ccp - Fix double add when creating new DMA command
  crypto: ccp - Fix DMA operations when IOMMU is enabled
  crypto: chcr - Check device is allocated before use
  crypto: chcr - Fix panic on dma_unmap_sg
  crypto: qat - zero esram only for DH85x devices
  crypto: qat - fix bar discovery for c62x
2017-02-06 14:16:23 -08:00
Arnd Bergmann
b3f2d07f46 hns: avoid stack overflow with CONFIG_KASAN
The use of ACCESS_ONCE() looks like a micro-optimization to force gcc to use
an indexed load for the register address, but it has an absolutely detrimental
effect on builds with gcc-5 and CONFIG_KASAN=y, leading to a very likely
kernel stack overflow aside from very complex object code:

hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_update_stats':
hisilicon/hns/hns_dsaf_gmac.c:419:1: error: the frame size of 2912 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_reset_common':
hisilicon/hns/hns_dsaf_ppe.c:390:1: error: the frame size of 1184 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_ppe.c: In function 'hns_ppe_get_regs':
hisilicon/hns/hns_dsaf_ppe.c:621:1: error: the frame size of 3632 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_common_regs':
hisilicon/hns/hns_dsaf_rcb.c:970:1: error: the frame size of 2784 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_gmac.c: In function 'hns_gmac_get_regs':
hisilicon/hns/hns_dsaf_gmac.c:641:1: error: the frame size of 5728 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_rcb.c: In function 'hns_rcb_get_ring_regs':
hisilicon/hns/hns_dsaf_rcb.c:1021:1: error: the frame size of 2208 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_comm_init':
hisilicon/hns/hns_dsaf_main.c:1209:1: error: the frame size of 1904 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_xgmac.c: In function 'hns_xgmac_get_regs':
hisilicon/hns/hns_dsaf_xgmac.c:748:1: error: the frame size of 4704 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_update_stats':
hisilicon/hns/hns_dsaf_main.c:2420:1: error: the frame size of 1088 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_get_regs':
hisilicon/hns/hns_dsaf_main.c:2753:1: error: the frame size of 10768 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]

This does not seem to happen any more with gcc-7, but removing the ACCESS_ONCE
seems safe anyway and it avoids a serious issue for some people. I have verified
that with gcc-5.3.1, the object code we get is better in the new version
both with and without CONFIG_KASAN, as we no longer allocate a 1344 byte
stack frame for hns_dsaf_get_regs() but otherwise have practically identical
object code.

With gcc-7.0.0, removing ACCESS_ONCE has no effect, the object code is already
good either way.

This patch is probably not urgent to get into 4.11 as only KASAN=y builds
with certain compilers are affected, but I still think it makes sense to
backport into older kernels.

Cc: stable@vger.kernel.org
Fixes: 511e6bc ("net: add Hisilicon Network Subsystem DSAF support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-06 12:02:32 -05:00
Linus Lüssing
a088d1d73a ipv6: Fix IPv6 packet loss in scenarios involving roaming + snooping switches
When for instance a mobile Linux device roams from one access point to
another with both APs sharing the same broadcast domain and a
multicast snooping switch in between:

1)    (c) <~~~> (AP1) <--[SSW]--> (AP2)

2)              (AP1) <--[SSW]--> (AP2) <~~~> (c)

Then currently IPv6 multicast packets will get lost for (c) until an
MLD Querier sends its next query message. The packet loss occurs
because upon roaming the Linux host so far stayed silent regarding
MLD and the snooping switch will therefore be unaware of the
multicast topology change for a while.

This patch fixes this by always resending MLD reports when an interface
change happens, for instance from NO-CARRIER to CARRIER state.

Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-02-06 11:43:01 -05:00
Arnd Bergmann
5aff1d245e ARM: defconfigs: make NF_CT_PROTO_SCTP and NF_CT_PROTO_UDPLITE built-in
The symbols can no longer be used as loadable modules, leading to a harmless Kconfig
warning:

arch/arm/configs/imote2_defconfig:60:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
arch/arm/configs/imote2_defconfig:59:warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP
arch/arm/configs/ezx_defconfig:68:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
arch/arm/configs/ezx_defconfig:67:warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP

Let's make them built-in.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2017-02-06 17:37:42 +01:00
Christoph Hellwig
eeeefd4184 block: don't try Write Same from __blkdev_issue_zeroout
Write Same can return an error asynchronously if it turns out the
underlying SCSI device does not support Write Same, which makes a
proper fallback to other methods in __blkdev_issue_zeroout impossible.
Thus only issue a Write Same from blkdev_issue_zeroout an don't try it
at all from __blkdev_issue_zeroout as a non-invasive workaround.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Junichi Nomura <j-nomura@ce.jp.nec.com>
Fixes: e73c23ff ("block: add async variant of blkdev_issue_zeroout")
Tested-by: Junichi Nomura <j-nomura@ce.jp.nec.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
2017-02-06 09:34:46 -07:00