OSDN Git Service
Gavin Shan [Thu, 5 Jan 2017 23:39:49 +0000 (10:39 +1100)]
powerpc/eeh: Enable IO path on permanent error
[ Upstream commit
387bbc974f6adf91aa635090f73434ed10edd915 ]
We give up recovery on permanent error, simply shutdown the affected
devices and remove them. If the devices can't be put into quiet state,
they spew more traffic that is likely to cause another unexpected EEH
error. This was observed on "p8dtu2u" machine:
0002:00:00.0 PCI bridge: IBM Device 03dc
0002:01:00.0 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
0002:01:00.1 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
0002:01:00.2 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
0002:01:00.3 Ethernet controller: Intel Corporation \
Ethernet Controller X710/X557-AT 10GBASE-T (rev 02)
On P8 PowerNV platform, the IO path is frozen when shutdowning the
devices, meaning the memory registers are inaccessible. It is why
the devices can't be put into quiet state before removing them.
This fixes the issue by enabling IO path prior to putting the devices
into quiet state.
Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com>
Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Acked-by: Russell Currey <ruscur@russell.cc>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florian Fainelli [Sat, 24 Dec 2016 03:56:56 +0000 (19:56 -0800)]
net: korina: Fix NAPI versus resources freeing
commit
e6afb1ad88feddf2347ea779cfaf4d03d3cd40b6 upstream.
Commit
beb0babfb77e ("korina: disable napi on close and restart")
introduced calls to napi_disable() that were missing before,
unfortunately this leaves a small window during which NAPI has a chance
to run, yet we just freed resources since korina_free_ring() has been
called:
Fix this by disabling NAPI first then freeing resource, and make sure
that we also cancel the restart task before doing the resource freeing.
Fixes:
beb0babfb77e ("korina: disable napi on close and restart")
Reported-by: Alexandros C. Couloumbis <alex@ozo.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhou Chengming [Mon, 16 Jan 2017 03:21:11 +0000 (11:21 +0800)]
perf/x86/intel: Handle exclusive threadid correctly on CPU hotplug
[ Upstream commit
4e71de7986386d5fd3765458f27d612931f27f5e ]
The CPU hotplug function intel_pmu_cpu_starting() sets
cpu_hw_events.excl_thread_id unconditionally to 1 when the shared exclusive
counters data structure is already availabe for the sibling thread.
This works during the boot process because the first sibling gets threadid
0 assigned and the second sibling which shares the data structure gets 1.
But when the first thread of the core is offlined and onlined again it
shares the data structure with the second thread and gets exclusive thread
id 1 assigned as well.
Prevent this by checking the threadid of the already online thread.
[ tglx: Rewrote changelog ]
Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
Cc: NuoHan Qiao <qiaonuohan@huawei.com>
Cc: ak@linux.intel.com
Cc: peterz@infradead.org
Cc: kan.liang@intel.com
Cc: dave.hansen@linux.intel.com
Cc: eranian@google.com
Cc: qiaonuohan@huawei.com
Cc: davidcc@google.com
Cc: guohanjun@huawei.com
Link: http://lkml.kernel.org/r/1484536871-3131-1-git-send-email-zhouchengming1@huawei.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alvaro G. M [Tue, 17 Jan 2017 08:08:16 +0000 (09:08 +0100)]
net: phy: dp83848: add DP83620 PHY support
[ Upstream commit
93b43fd137cd8865adf9978ab9870a344365d3af ]
This PHY with fiber support is register compatible with DP83848,
so add support for it.
Signed-off-by: Alvaro Gamez Machado <alvaro.gamez@hazent.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Tue, 17 Jan 2017 20:06:58 +0000 (15:06 -0500)]
drm/amdgpu: add support for new hainan variants
[ Upstream commit
17324b6add82d6c0bf119f1d1944baef392a4e39 ]
New hainan parts require updated smc firmware.
Cc: Sonny Jiang <sonny.jiang@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rex Zhu [Tue, 10 Jan 2017 12:03:59 +0000 (20:03 +0800)]
drm/amdgpu: fix program vce instance logic error.
[ Upstream commit
50a1ebc70a2803deb7811fc73fb55d70e353bc34 ]
need to clear bit31-29 in GRBM_GFX_INDEX,
then the program can be valid.
Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quinn Tran [Sat, 24 Dec 2016 02:06:13 +0000 (18:06 -0800)]
qla2xxx: Fix erroneous invalid handle message
[ Upstream commit
4f060736f29a960aba8e781a88837464756200a8 ]
Termination of Immediate Notify IOCB was using wrong
IOCB handle. IOCB completion code was unable to find
appropriate code path due to wrong handle.
Following message is seen in the logs.
"Error entry - invalid handle/queue (ffff)."
Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
[ bvanassche: Fixed word order in patch title ]
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Quinn Tran [Sat, 24 Dec 2016 02:06:11 +0000 (18:06 -0800)]
qla2xxx: Terminate exchange if corrupted
[ Upstream commit
5f35509db179ca7ed1feaa4b14f841adb06ed220 ]
Corrupted ATIO is defined as length of fcp_header & fcp_cmd
payload is less than 0x38. It's the minimum size for a frame to
carry 8..16 bytes SCSI CDB. The exchange will be dropped or
terminated if corrupted.
Signed-off-by: Quinn Tran <quinn.tran@cavium.com>
Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
[ bvanassche: Fixed spelling in patch title ]
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Thumshirn [Tue, 10 Jan 2017 11:05:54 +0000 (12:05 +0100)]
scsi: lpfc: Set elsiocb contexts to NULL after freeing it
[ Upstream commit
8667f515952feefebb3c0f8d9a9266c91b101a46 ]
Set the elsiocb contexts to NULL after freeing as others depend on it.
Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Acked-by: Dick Kennedy <dick.kennedy@broadcom.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Julia Lawall [Tue, 17 Jan 2017 11:23:21 +0000 (12:23 +0100)]
stmmac: add missing of_node_put
[ Upstream commit
a249708bc2aa1fe3ddf15dfac22bee519d15996b ]
The function stmmac_dt_phy provides several possibilities for initializing
plat->mdio_node, all of which have the effect of increasing the reference
count of the assigned value. This field is not updated elsewhere, so the
value is live until the end of the lifetime of plat (devm_allocated), just
after the end of stmmac_remove_config_dt. Thus, add an of_node_put on
plat->mdio_node in stmmac_remove_config_dt. It is possible that the field
mdio_node is never initialized, but of_node_put is NULL-safe, so it is also
safe to call of_node_put in that case.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Acked-by: Alexandre TORGUE <alexandre.torgue@st.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Damien Le Moal [Thu, 12 Jan 2017 06:25:10 +0000 (15:25 +0900)]
scsi: sd: Fix wrong DPOFUA disable in sd_read_cache_type
[ Upstream commit
26f2819772af891dee2843e1f8662c58e5129d5f ]
Zoned block devices force the use of READ/WRITE(16) commands by setting
sdkp->use_16_for_rw and clearing sdkp->use_10_for_rw. This result in
DPOFUA always being disabled for these drives as the assumed use of
the deprecated READ/WRITE(6) commands only looks at sdkp->use_10_for_rw.
Strenghten the test by also checking that sdkp->use_16_for_rw is false.
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Vyukov [Tue, 17 Jan 2017 13:51:04 +0000 (14:51 +0100)]
KVM: x86: fix fixing of hypercalls
[ Upstream commit
ce2e852ecc9a42e4b8dabb46025cfef63209234a ]
emulator_fix_hypercall() replaces hypercall with vmcall instruction,
but it does not handle GP exception properly when writes the new instruction.
It can return X86EMUL_PROPAGATE_FAULT without setting exception information.
This leads to incorrect emulation and triggers
WARN_ON(ctxt->exception.vector > 0x1f) in x86_emulate_insn()
as discovered by syzkaller fuzzer:
WARNING: CPU: 2 PID: 18646 at arch/x86/kvm/emulate.c:5558
Call Trace:
warn_slowpath_null+0x2c/0x40 kernel/panic.c:582
x86_emulate_insn+0x16a5/0x4090 arch/x86/kvm/emulate.c:5572
x86_emulate_instruction+0x403/0x1cc0 arch/x86/kvm/x86.c:5618
emulate_instruction arch/x86/include/asm/kvm_host.h:1127 [inline]
handle_exception+0x594/0xfd0 arch/x86/kvm/vmx.c:5762
vmx_handle_exit+0x2b7/0x38b0 arch/x86/kvm/vmx.c:8625
vcpu_enter_guest arch/x86/kvm/x86.c:6888 [inline]
vcpu_run arch/x86/kvm/x86.c:6947 [inline]
Set exception information when write in emulator_fix_hypercall() fails.
Signed-off-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Wanpeng Li <wanpeng.li@hotmail.com>
Cc: kvm@vger.kernel.org
Cc: syzkaller@googlegroups.com
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Thu, 18 May 2017 15:28:48 +0000 (17:28 +0200)]
xen/blkback: don't free be structure too early
commit
71df1d7ccad1c36f7321d6b3b48f2ea42681c363 upstream.
The be structure must not be freed when freeing the blkif structure
isn't done. Otherwise a use-after-free of be when unmapping the ring
used for communicating with the frontend will occur in case of a
late call of xenblk_disconnect() (e.g. due to an I/O still active
when trying to disconnect).
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerome Brunet [Fri, 20 Jan 2017 16:20:24 +0000 (08:20 -0800)]
ARM64: dts: meson-gxbb-odroidc2: fix GbE tx link breakage
[ Upstream commit
feb3cbea0946c67060e2d5bcb7499b0a6f6700fe ]
OdroidC2 GbE link breaks under heavy tx transfer. This happens even if the
MAC does not enable Energy Efficient Ethernet (No Low Power state Idle on
the Tx path). The problem seems to come from the phy Rx path, entering the
LPI state.
Disabling EEE advertisement on the phy prevent this feature to be
negociated with the link partner and solve the issue.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 19 Dec 2016 15:05:38 +0000 (16:05 +0100)]
dt: bindings: net: use boolean dt properties for eee broken modes
[ Upstream commit
308d3165d8b2b98d3dc3d97d6662062735daea67 ]
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 19 Dec 2016 15:05:37 +0000 (16:05 +0100)]
net: phy: use boolean dt properties for eee broken modes
[ Upstream commit
57f3986231bb2c69a55ccab1d2b30a00818027ac ]
The patches regarding eee-broken-modes was merged before all people
involved could find an agreement on the best way to move forward.
While we agreed on having a DT property to mark particular modes as broken,
the value used for eee-broken-modes mapped the phy register in very direct
way. Because of this, the concern is that it could be used to implement
configuration policies instead of describing a broken HW.
In the end, having a boolean property for each mode seems to be preferred
over one bit field value mapping the register (too) directly.
Cc: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 19 Dec 2016 15:05:36 +0000 (16:05 +0100)]
net: phy: fix sign type error in genphy_config_eee_advert
[ Upstream commit
3bb9ab63276696988d8224f52db20e87194deb4b ]
In genphy_config_eee_advert, the return value of phy_read_mmd_indirect is
checked to know if the register could be accessed but the result is
assigned to a 'u32'.
Changing to 'int' to correctly get errors from phy_read_mmd_indirect.
Fixes:
d853d145ea3e ("net: phy: add an option to disable EEE advertisement")
Reported-by: Julia Lawall <julia.lawall@lip6.fr>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 28 Nov 2016 09:46:47 +0000 (10:46 +0100)]
dt-bindings: net: add EEE capability constants
[ Upstream commit
1fc31357ad194fb98691f3d122bcd47e59239e83 ]
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
jbrunet [Mon, 28 Nov 2016 09:46:46 +0000 (10:46 +0100)]
net: phy: add an option to disable EEE advertisement
[ Upstream commit
d853d145ea3e63387a2ac759aa41d5e43876e561 ]
This patch adds an option to disable EEE advertisement in the generic PHY
by providing a mask of prohibited modes corresponding to the value found in
the MDIO_AN_EEE_ADV register.
On some platforms, PHY Low power idle seems to be causing issues, even
breaking the link some cases. The patch provides a convenient way for these
platforms to disable EEE advertisement and work around the issue.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-by: Yegor Yefremov <yegorslists@googlemail.com>
Tested-by: Andreas Färber <afaerber@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Belous [Sat, 28 Jan 2017 19:53:28 +0000 (22:53 +0300)]
net: ethtool: add support for 2500BaseT and 5000BaseT link modes
[ Upstream commit
94842b4fc4d6b1691cfc86c6f5251f299d27f4ba ]
This patch introduce support for 2500BaseT and 5000BaseT link modes.
These modes are included in the new IEEE 802.3bz standard.
Signed-off-by: Pavel Belous <pavel.s.belous@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liam R. Howlett [Wed, 24 May 2017 01:54:11 +0000 (21:54 -0400)]
sparc64: Zero pages on allocation for mondo and error queues.
[ Upstream commit
7a7dc961a28b965a0d0303c2e989df17b411708b ]
Error queues use a non-zero first word to detect if the queues are full.
Using pages that have not been zeroed may result in false positive
overflow events. These queues are set up once during boot so zeroing
all mondo and error queue pages is safe.
Note that the false positive overflow does not always occur because the
page allocation for these queues is so early in the boot cycle that
higher number CPUs get fresh pages. It is only when traps are serviced
with lower number CPUs who were given already used pages that this issue
is exposed.
Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Liam R. Howlett [Wed, 24 May 2017 01:54:10 +0000 (21:54 -0400)]
sparc64: Handle PIO & MEM non-resumable errors.
[ Upstream commit
047487241ff59374fded8c477f21453681f5995c ]
User processes trying to access an invalid memory address via PIO will
receive a SIGBUS signal instead of causing a panic. Memory errors will
receive a SIGKILL since a SIGBUS may result in a coredump which may
attempt to repeat the faulting access.
Signed-off-by: Liam R. Howlett <Liam.Howlett@Oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Rutland [Fri, 16 Jun 2017 21:02:34 +0000 (14:02 -0700)]
mm: numa: avoid waiting on freed migrated pages
commit
3c226c637b69104f6b9f1c6ec5b08d7b741b3229 upstream.
In do_huge_pmd_numa_page(), we attempt to handle a migrating thp pmd by
waiting until the pmd is unlocked before we return and retry. However,
we can race with migrate_misplaced_transhuge_page():
// do_huge_pmd_numa_page // migrate_misplaced_transhuge_page()
// Holds 0 refs on page // Holds 2 refs on page
vmf->ptl = pmd_lock(vma->vm_mm, vmf->pmd);
/* ... */
if (pmd_trans_migrating(*vmf->pmd)) {
page = pmd_page(*vmf->pmd);
spin_unlock(vmf->ptl);
ptl = pmd_lock(mm, pmd);
if (page_count(page) != 2)) {
/* roll back */
}
/* ... */
mlock_migrate_page(new_page, page);
/* ... */
spin_unlock(ptl);
put_page(page);
put_page(page); // page freed here
wait_on_page_locked(page);
goto out;
}
This can result in the freed page having its waiters flag set
unexpectedly, which trips the PAGE_FLAGS_CHECK_AT_PREP checks in the
page alloc/free functions. This has been observed on arm64 KVM guests.
We can avoid this by having do_huge_pmd_numa_page() take a reference on
the page before dropping the pmd lock, mirroring what we do in
__migration_entry_wait().
When we hit the race, migrate_misplaced_transhuge_page() will see the
reference and abort the migration, as it may do today in other cases.
Fixes:
b8916634b77bffb2 ("mm: Prevent parallel splits during THP migration")
Link: http://lkml.kernel.org/r/1497349722-6731-2-git-send-email-will.deacon@arm.com
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Acked-by: Steve Capper <steve.capper@arm.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:30 +0000 (13:02 +0200)]
l2tp: take a reference on sessions used in genetlink handlers
commit
2777e2ab5a9cf2b4524486c6db1517a6ded25261 upstream.
Callers of l2tp_nl_session_find() need to hold a reference on the
returned session since there's no guarantee that it isn't going to
disappear from under them.
Relying on the fact that no l2tp netlink message may be processed
concurrently isn't enough: sessions can be deleted by other means
(e.g. by closing the PPPOL2TP socket of a ppp pseudowire).
l2tp_nl_cmd_session_delete() is a bit special: it runs a callback
function that may require a previous call to session->ref(). In
particular, for ppp pseudowires, the callback is l2tp_session_delete(),
which then calls pppol2tp_session_close() and dereferences the PPPOL2TP
socket. The socket might already be gone at the moment
l2tp_session_delete() calls session->ref(), so we need to take a
reference during the session lookup. So we need to pass the do_ref
variable down to l2tp_session_get() and l2tp_session_get_by_ifname().
Since all callers have to be updated, l2tp_session_find_by_ifname() and
l2tp_nl_session_find() are renamed to reflect their new behaviour.
Fixes:
309795f4bec2 ("l2tp: Add netlink control API for L2TP")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:29 +0000 (13:02 +0200)]
l2tp: hold session while sending creation notifications
commit
5e6a9e5a3554a5b3db09cdc22253af1849c65dff upstream.
l2tp_session_find() doesn't take any reference on the returned session.
Therefore, the session may disappear while sending the notification.
Use l2tp_session_get() instead and decrement session's refcount once
the notification is sent.
Fixes:
33f72e6f0c67 ("l2tp : multicast notification to the registered listeners")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:27 +0000 (13:02 +0200)]
l2tp: fix duplicate session creation
commit
dbdbc73b44782e22b3b4b6e8b51e7a3d245f3086 upstream.
l2tp_session_create() relies on its caller for checking for duplicate
sessions. This is racy since a session can be concurrently inserted
after the caller's verification.
Fix this by letting l2tp_session_create() verify sessions uniqueness
upon insertion. Callers need to be adapted to check for
l2tp_session_create()'s return code instead of calling
l2tp_session_find().
pppol2tp_connect() is a bit special because it has to work on existing
sessions (if they're not connected) or to create a new session if none
is found. When acting on a preexisting session, a reference must be
held or it could go away on us. So we have to use l2tp_session_get()
instead of l2tp_session_find() and drop the reference before exiting.
Fixes:
d9e31d17ceba ("l2tp: Add L2TP ethernet pseudowire support")
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:26 +0000 (13:02 +0200)]
l2tp: ensure session can't get removed during pppol2tp_session_ioctl()
commit
57377d63547861919ee634b845c7caa38de4a452 upstream.
Holding a reference on session is required before calling
pppol2tp_session_ioctl(). The session could get freed while processing the
ioctl otherwise. Since pppol2tp_session_ioctl() uses the session's socket,
we also need to take a reference on it in l2tp_session_get().
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Guillaume Nault [Fri, 31 Mar 2017 11:02:25 +0000 (13:02 +0200)]
l2tp: fix race in l2tp_recv_common()
commit
61b9a047729bb230978178bca6729689d0c50ca2 upstream.
Taking a reference on sessions in l2tp_recv_common() is racy; this
has to be done by the callers.
To this end, a new function is required (l2tp_session_get()) to
atomically lookup a session and take a reference on it. Callers then
have to manually drop this reference.
Fixes:
fd558d186df2 ("l2tp: Split pppol2tp patch into separate l2tp and ppp parts")
Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baolin Wang [Thu, 8 Dec 2016 11:55:22 +0000 (19:55 +0800)]
usb: gadget: f_fs: Fix possibe deadlock
commit
b3ce3ce02d146841af012d08506b4071db8ffde3 upstream.
When system try to close /dev/usb-ffs/adb/ep0 on one core, at the same
time another core try to attach new UDC, which will cause deadlock as
below scenario. Thus we should release ffs lock before issuing
unregister_gadget_item().
[ 52.642225] c1 ======================================================
[ 52.642228] c1 [ INFO: possible circular locking dependency detected ]
[ 52.642236] c1 4.4.6+ #1 Tainted: G W O
[ 52.642241] c1 -------------------------------------------------------
[ 52.642245] c1 usb ffs open/2808 is trying to acquire lock:
[ 52.642270] c0 (udc_lock){+.+.+.}, at: [<
ffffffc00065aeec>]
usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642272] c1 but task is already holding lock:
[ 52.642283] c0 (ffs_lock){+.+.+.}, at: [<
ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[ 52.642285] c1 which lock already depends on the new lock.
[ 52.642287] c1
the existing dependency chain (in reverse order) is:
[ 52.642295] c0
-> #1 (ffs_lock){+.+.+.}:
[ 52.642307] c0 [<
ffffffc00012340c>] __lock_acquire+0x20f0/0x2238
[ 52.642314] c0 [<
ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642322] c0 [<
ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642328] c0 [<
ffffffc00066f7bc>] ffs_func_bind+0x504/0x6e8
[ 52.642334] c0 [<
ffffffc000654004>] usb_add_function+0x84/0x184
[ 52.642340] c0 [<
ffffffc000658ca4>] configfs_composite_bind+0x264/0x39c
[ 52.642346] c0 [<
ffffffc00065b348>] udc_bind_to_driver+0x58/0x11c
[ 52.642352] c0 [<
ffffffc00065b49c>] usb_udc_attach_driver+0x90/0xc8
[ 52.642358] c0 [<
ffffffc0006598e0>] gadget_dev_desc_UDC_store+0xd4/0x128
[ 52.642369] c0 [<
ffffffc0002c14e8>] configfs_write_file+0xd0/0x13c
[ 52.642376] c0 [<
ffffffc00023c054>] vfs_write+0xb8/0x214
[ 52.642381] c0 [<
ffffffc00023cad4>] SyS_write+0x54/0xb0
[ 52.642388] c0 [<
ffffffc000085ff0>] el0_svc_naked+0x24/0x28
[ 52.642395] c0
-> #0 (udc_lock){+.+.+.}:
[ 52.642401] c0 [<
ffffffc00011e3d0>] print_circular_bug+0x84/0x2e4
[ 52.642407] c0 [<
ffffffc000123454>] __lock_acquire+0x2138/0x2238
[ 52.642412] c0 [<
ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642420] c0 [<
ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642427] c0 [<
ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642432] c0 [<
ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[ 52.642439] c0 [<
ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[ 52.642444] c0 [<
ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[ 52.642450] c0 [<
ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[ 52.642454] c0 [<
ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[ 52.642460] c0 [<
ffffffc00023dbe4>] __fput+0xb0/0x1f4
[ 52.642466] c0 [<
ffffffc00023dd9c>] ____fput+0x20/0x2c
[ 52.642473] c0 [<
ffffffc0000ee944>] task_work_run+0xb4/0xe8
[ 52.642482] c0 [<
ffffffc0000cd45c>] do_exit+0x360/0xb9c
[ 52.642487] c0 [<
ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[ 52.642494] c0 [<
ffffffc0000dd3c8>] get_signal+0x380/0x89c
[ 52.642501] c0 [<
ffffffc00008a8f0>] do_signal+0x154/0x518
[ 52.642507] c0 [<
ffffffc00008af00>] do_notify_resume+0x70/0x78
[ 52.642512] c0 [<
ffffffc000085ee8>] work_pending+0x1c/0x20
[ 52.642514] c1
other info that might help us debug this:
[ 52.642517] c1 Possible unsafe locking scenario:
[ 52.642518] c1 CPU0 CPU1
[ 52.642520] c1 ---- ----
[ 52.642525] c0 lock(ffs_lock);
[ 52.642529] c0 lock(udc_lock);
[ 52.642533] c0 lock(ffs_lock);
[ 52.642537] c0 lock(udc_lock);
[ 52.642539] c1
*** DEADLOCK ***
[ 52.642543] c1 1 lock held by usb ffs open/2808:
[ 52.642555] c0 #0: (ffs_lock){+.+.+.}, at: [<
ffffffc00066b244>]
ffs_data_clear+0x30/0x140
[ 52.642557] c1 stack backtrace:
[ 52.642563] c1 CPU: 1 PID: 2808 Comm: usb ffs open Tainted: G
[ 52.642565] c1 Hardware name: Spreadtrum SP9860g Board (DT)
[ 52.642568] c1 Call trace:
[ 52.642573] c1 [<
ffffffc00008b430>] dump_backtrace+0x0/0x170
[ 52.642577] c1 [<
ffffffc00008b5c0>] show_stack+0x20/0x28
[ 52.642583] c1 [<
ffffffc000422694>] dump_stack+0xa8/0xe0
[ 52.642587] c1 [<
ffffffc00011e548>] print_circular_bug+0x1fc/0x2e4
[ 52.642591] c1 [<
ffffffc000123454>] __lock_acquire+0x2138/0x2238
[ 52.642595] c1 [<
ffffffc000123b54>] lock_acquire+0xe4/0x298
[ 52.642599] c1 [<
ffffffc000aaf6e8>] mutex_lock_nested+0x7c/0x3cc
[ 52.642604] c1 [<
ffffffc00065aeec>] usb_gadget_unregister_driver+0x3c/0xc8
[ 52.642608] c1 [<
ffffffc00065995c>] unregister_gadget_item+0x28/0x44
[ 52.642613] c1 [<
ffffffc00066b34c>] ffs_data_clear+0x138/0x140
[ 52.642618] c1 [<
ffffffc00066b374>] ffs_data_reset+0x20/0x6c
[ 52.642621] c1 [<
ffffffc00066efd0>] ffs_data_closed+0xac/0x12c
[ 52.642625] c1 [<
ffffffc00066f070>] ffs_ep0_release+0x20/0x2c
[ 52.642629] c1 [<
ffffffc00023dbe4>] __fput+0xb0/0x1f4
[ 52.642633] c1 [<
ffffffc00023dd9c>] ____fput+0x20/0x2c
[ 52.642636] c1 [<
ffffffc0000ee944>] task_work_run+0xb4/0xe8
[ 52.642640] c1 [<
ffffffc0000cd45c>] do_exit+0x360/0xb9c
[ 52.642644] c1 [<
ffffffc0000cf228>] do_group_exit+0x4c/0xb0
[ 52.642647] c1 [<
ffffffc0000dd3c8>] get_signal+0x380/0x89c
[ 52.642651] c1 [<
ffffffc00008a8f0>] do_signal+0x154/0x518
[ 52.642656] c1 [<
ffffffc00008af00>] do_notify_resume+0x70/0x78
[ 52.642659] c1 [<
ffffffc000085ee8>] work_pending+0x1c/0x20
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Baolin Wang <baolin.wang@linaro.org>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Baoquan He [Thu, 4 May 2017 02:25:47 +0000 (10:25 +0800)]
x86/mm: Fix boot crash caused by incorrect loop count calculation in sync_global_pgds()
commit
fc5f9d5f151c9fff21d3d1d2907b888a5aec3ff7 upstream.
Jeff Moyer reported that on his system with two memory regions 0~64G and
1T~1T+192G, and kernel option "memmap=192G!1024G" added, enabling KASLR
will make the system hang intermittently during boot. While adding 'nokaslr'
won't.
The back trace is:
Oops: 0000 [#1] SMP
RIP: memcpy_erms()
[ .... ]
Call Trace:
pmem_rw_page()
bdev_read_page()
do_mpage_readpage()
mpage_readpages()
blkdev_readpages()
__do_page_cache_readahead()
force_page_cache_readahead()
page_cache_sync_readahead()
generic_file_read_iter()
blkdev_read_iter()
__vfs_read()
vfs_read()
SyS_read()
entry_SYSCALL_64_fastpath()
This crash happens because the for loop count calculation in sync_global_pgds()
is not correct. When a mapping area crosses PGD entries, we should
calculate the starting address of region which next PGD covers and assign
it to next for loop count, but not add PGDIR_SIZE directly. The old
code works right only if the mapping area is an exact multiple of PGDIR_SIZE,
otherwize the end region could be skipped so that it can't be synchronized
to all other processes from kernel PGD init_mm.pgd.
In Jeff's system, emulated pmem area [1024G, 1216G) is smaller than
PGDIR_SIZE. While 'nokaslr' works because PAGE_OFFSET is 1T aligned, it
makes this area be mapped inside one PGD entry. With KASLR enabled,
this area could cross two PGD entries, then the next PGD entry won't
be synced to all other processes. That is why we saw empty PGD.
Fix it.
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Baoquan He <bhe@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jinbum Park <jinb.park7@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.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: Yasuaki Ishimatsu <yasu.isimatu@gmail.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1493864747-8506-1-git-send-email-bhe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vallish Vaidyeshwara [Fri, 23 Jun 2017 18:53:06 +0000 (18:53 +0000)]
dm thin: do not queue freed thin mapping for next stage processing
commit
00a0ea33b495ee6149bf5a77ac5807ce87323abb upstream.
process_prepared_discard_passdown_pt1() should cleanup
dm_thin_new_mapping in cases of error.
dm_pool_inc_data_range() can fail trying to get a block reference:
metadata operation 'dm_pool_inc_data_range' failed: error = -61
When dm_pool_inc_data_range() fails, dm thin aborts current metadata
transaction and marks pool as PM_READ_ONLY. Memory for thin mapping
is released as well. However, current thin mapping will be queued
onto next stage as part of queue_passdown_pt2() or passdown_endio().
This dangling thin mapping memory when processed and accessed in
next stage will lead to device mapper crashing.
Code flow without fix:
-> process_prepared_discard_passdown_pt1(m)
-> dm_thin_remove_range()
-> discard passdown
--> passdown_endio(m) queues m onto next stage
-> dm_pool_inc_data_range() fails, frees memory m
but does not remove it from next stage queue
-> process_prepared_discard_passdown_pt2(m)
-> processes freed memory m and crashes
One such stack:
Call Trace:
[<
ffffffffa037a46f>] dm_cell_release_no_holder+0x2f/0x70 [dm_bio_prison]
[<
ffffffffa039b6dc>] cell_defer_no_holder+0x3c/0x80 [dm_thin_pool]
[<
ffffffffa039b88b>] process_prepared_discard_passdown_pt2+0x4b/0x90 [dm_thin_pool]
[<
ffffffffa0399611>] process_prepared+0x81/0xa0 [dm_thin_pool]
[<
ffffffffa039e735>] do_worker+0xc5/0x820 [dm_thin_pool]
[<
ffffffff8152bf54>] ? __schedule+0x244/0x680
[<
ffffffff81087e72>] ? pwq_activate_delayed_work+0x42/0xb0
[<
ffffffff81089f53>] process_one_work+0x153/0x3f0
[<
ffffffff8108a71b>] worker_thread+0x12b/0x4b0
[<
ffffffff8108a5f0>] ? rescuer_thread+0x350/0x350
[<
ffffffff8108fd6a>] kthread+0xca/0xe0
[<
ffffffff8108fca0>] ? kthread_park+0x60/0x60
[<
ffffffff81530b45>] ret_from_fork+0x25/0x30
The fix is to first take the block ref count for discarded block and
then do a passdown discard of this block. If block ref count fails,
then bail out aborting current metadata transaction, mark pool as
PM_READ_ONLY and also free current thin mapping memory (existing error
handling code) without queueing this thin mapping onto next stage of
processing. If block ref count succeeds, then passdown discard of this
block. Discard callback of passdown_endio() will queue this thin mapping
onto next stage of processing.
Code flow with fix:
-> process_prepared_discard_passdown_pt1(m)
-> dm_thin_remove_range()
-> dm_pool_inc_data_range()
--> if fails, free memory m and bail out
-> discard passdown
--> passdown_endio(m) queues m onto next stage
Reviewed-by: Eduardo Valentin <eduval@amazon.com>
Reviewed-by: Cristian Gafton <gafton@amazon.com>
Reviewed-by: Anchal Agarwal <anchalag@amazon.com>
Signed-off-by: Vallish Vaidyeshwara <vallish@amazon.com>
Reviewed-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Deepak Rawat [Mon, 26 Jun 2017 12:39:08 +0000 (14:39 +0200)]
drm/vmwgfx: Free hash table allocated by cmdbuf managed res mgr
commit
82fcee526ba8ca2c5d378bdf51b21b7eb058fe3a upstream.
The hash table created during vmw_cmdbuf_res_man_create was
never freed. This causes memory leak in context creation.
Added the corresponding drm_ht_remove in vmw_cmdbuf_res_man_destroy.
Tested for memory leak by running piglit overnight and kernel
memory is not inflated which earlier was.
Signed-off-by: Deepak Rawat <drawat@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bartosz Golaszewski [Fri, 23 Jun 2017 11:45:16 +0000 (13:45 +0200)]
gpiolib: fix filtering out unwanted events
commit
ad537b822577fcc143325786cd6ad50d7b9df31c upstream.
GPIOEVENT_REQUEST_BOTH_EDGES is not a single flag, but a binary OR of
GPIOEVENT_REQUEST_RISING_EDGE and GPIOEVENT_REQUEST_FALLING_EDGE.
The expression 'le->eflags & GPIOEVENT_REQUEST_BOTH_EDGES' we'll get
evaluated to true even if only one event type was requested.
Fix it by checking both RISING & FALLING flags explicitly.
Fixes:
61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Tue, 27 Jun 2017 21:33:38 +0000 (17:33 -0400)]
NFSv4.1: Fix a race in nfs4_proc_layoutget
commit
bd171930e6a3de4f5cffdafbb944e50093dfb59b upstream.
If the task calling layoutget is signalled, then it is possible for the
calls to nfs4_sequence_free_slot() and nfs4_layoutget_prepare() to race,
in which case we leak a slot.
The fix is to move the call to nfs4_sequence_free_slot() into the
nfs4_layoutget_release() so that it gets called at task teardown time.
Fixes:
2e80dbe7ac51 ("NFSv4.1: Close callback races for OPEN, LAYOUTGET...")
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hui Wang [Wed, 28 Jun 2017 00:59:16 +0000 (08:59 +0800)]
ALSA: hda - set input_path bitmap to zero after moving it to new place
commit
a8f20fd25bdce81a8e41767c39f456d346b63427 upstream.
Recently we met a problem, the codec has valid adcs and input pins,
and they can form valid input paths, but the driver does not build
valid controls for them like "Mic boost", "Capture Volume" and
"Capture Switch".
Through debugging, I found the driver needs to shrink the invalid
adcs and input paths for this machine, so it will move the whole
column bitmap value to the previous column, after moving it, the
driver forgets to set the original column bitmap value to zero, as a
result, the driver will invalidate the path whose index value is the
original colume bitmap value. After executing this function, all
valid input paths are invalidated by a mistake, there are no any
valid input paths, so the driver won't build controls for them.
Fixes:
3a65bcdc577a ("ALSA: hda - Fix inconsistent input_paths after ADC reduction")
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Wed, 28 Jun 2017 10:02:02 +0000 (12:02 +0200)]
ALSA: hda - Fix endless loop of codec configure
commit
d94815f917da770d42c377786dc428f542e38f71 upstream.
azx_codec_configure() loops over the codecs found on the given
controller via a linked list. The code used to work in the past, but
in the current version, this may lead to an endless loop when a codec
binding returns an error.
The culprit is that the snd_hda_codec_configure() unregisters the
device upon error, and this eventually deletes the given codec object
from the bus. Since the list is initialized via list_del_init(), the
next object points to the same device itself. This behavior change
was introduced at splitting the HD-audio code code, and forgotten to
adapt it here.
For fixing this bug, just use a *_safe() version of list iteration.
Fixes:
d068ebc25e6e ("ALSA: hda - Move some codes up to hdac_bus struct")
Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Burton [Fri, 3 Mar 2017 23:26:05 +0000 (15:26 -0800)]
MIPS: Fix IRQ tracing & lockdep when rescheduling
commit
d8550860d910c6b7b70f830f59003b33daaa52c9 upstream.
When the scheduler sets TIF_NEED_RESCHED & we call into the scheduler
from arch/mips/kernel/entry.S we disable interrupts. This is true
regardless of whether we reach work_resched from syscall_exit_work,
resume_userspace or by looping after calling schedule(). Although we
disable interrupts in these paths we don't call trace_hardirqs_off()
before calling into C code which may acquire locks, and we therefore
leave lockdep with an inconsistent view of whether interrupts are
disabled or not when CONFIG_PROVE_LOCKING & CONFIG_DEBUG_LOCKDEP are
both enabled.
Without tracing this interrupt state lockdep will print warnings such
as the following once a task returns from a syscall via
syscall_exit_partial with TIF_NEED_RESCHED set:
[ 49.927678] ------------[ cut here ]------------
[ 49.934445] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3687 check_flags.part.41+0x1dc/0x1e8
[ 49.946031] DEBUG_LOCKS_WARN_ON(current->hardirqs_enabled)
[ 49.946355] CPU: 0 PID: 1 Comm: init Not tainted
4.10.0-00439-gc9fd5d362289-dirty #197
[ 49.963505] Stack :
0000000000000000 ffffffff81bb5d6a 0000000000000006 ffffffff801ce9c4
[ 49.974431]
0000000000000000 0000000000000000 0000000000000000 000000000000004a
[ 49.985300]
ffffffff80b7e487 ffffffff80a24498 a8000000ff160000 ffffffff80ede8b8
[ 49.996194]
0000000000000001 0000000000000000 0000000000000000 0000000077c8030c
[ 50.007063]
000000007fd8a510 ffffffff801cd45c 0000000000000000 a8000000ff127c88
[ 50.017945]
0000000000000000 ffffffff801cf928 0000000000000001 ffffffff80a24498
[ 50.028827]
0000000000000000 0000000000000001 0000000000000000 0000000000000000
[ 50.039688]
0000000000000000 a8000000ff127bd0 0000000000000000 ffffffff805509bc
[ 50.050575]
00000000140084e0 0000000000000000 0000000000000000 0000000000040a00
[ 50.061448]
0000000000000000 ffffffff8010e1b0 0000000000000000 ffffffff805509bc
[ 50.072327] ...
[ 50.076087] Call Trace:
[ 50.079869] [<
ffffffff8010e1b0>] show_stack+0x80/0xa8
[ 50.086577] [<
ffffffff805509bc>] dump_stack+0x10c/0x190
[ 50.093498] [<
ffffffff8015dde0>] __warn+0xf0/0x108
[ 50.099889] [<
ffffffff8015de34>] warn_slowpath_fmt+0x3c/0x48
[ 50.107241] [<
ffffffff801c15b4>] check_flags.part.41+0x1dc/0x1e8
[ 50.114961] [<
ffffffff801c239c>] lock_is_held_type+0x8c/0xb0
[ 50.122291] [<
ffffffff809461b8>] __schedule+0x8c0/0x10f8
[ 50.129221] [<
ffffffff80946a60>] schedule+0x30/0x98
[ 50.135659] [<
ffffffff80106278>] work_resched+0x8/0x34
[ 50.142397] ---[ end trace
0cb4f6ef5b99fe21 ]---
[ 50.148405] possible reason: unannotated irqs-off.
[ 50.154600] irq event stamp: 400463
[ 50.159566] hardirqs last enabled at (400463): [<
ffffffff8094edc8>] _raw_spin_unlock_irqrestore+0x40/0xa8
[ 50.171981] hardirqs last disabled at (400462): [<
ffffffff8094eb98>] _raw_spin_lock_irqsave+0x30/0xb0
[ 50.183897] softirqs last enabled at (400450): [<
ffffffff8016580c>] __do_softirq+0x4ac/0x6a8
[ 50.195015] softirqs last disabled at (400425): [<
ffffffff80165e78>] irq_exit+0x110/0x128
Fix this by using the TRACE_IRQS_OFF macro to call trace_hardirqs_off()
when CONFIG_TRACE_IRQFLAGS is enabled. This is done before invoking
schedule() following the work_resched label because:
1) Interrupts are disabled regardless of the path we take to reach
work_resched() & schedule().
2) Performing the tracing here avoids the need to do it in paths which
disable interrupts but don't call out to C code before hitting a
path which uses the RESTORE_SOME macro that will call
trace_hardirqs_on() or trace_hardirqs_off() as appropriate.
We call trace_hardirqs_on() using the TRACE_IRQS_ON macro before calling
syscall_trace_leave() for similar reasons, ensuring that lockdep has a
consistent view of state after we re-enable interrupts.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15385/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paul Burton [Thu, 2 Mar 2017 22:02:40 +0000 (14:02 -0800)]
MIPS: pm-cps: Drop manual cache-line alignment of ready_count
commit
161c51ccb7a6faf45ffe09aa5cf1ad85ccdad503 upstream.
We allocate memory for a ready_count variable per-CPU, which is accessed
via a cached non-coherent TLB mapping to perform synchronisation between
threads within the core using LL/SC instructions. In order to ensure
that the variable is contained within its own data cache line we
allocate 2 lines worth of memory & align the resulting pointer to a line
boundary. This is however unnecessary, since kmalloc is guaranteed to
return memory which is at least cache-line aligned (see
ARCH_DMA_MINALIGN). Stop the redundant manual alignment.
Besides cleaning up the code & avoiding needless work, this has the side
effect of avoiding an arithmetic error found by Bryan on 64 bit systems
due to the 32 bit size of the former dlinesz. This led the ready_count
variable to have its upper 32b cleared erroneously for MIPS64 kernels,
causing problems when ready_count was later used on MIPS64 via cpuidle.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes:
3179d37ee1ed ("MIPS: pm-cps: add PM state entry code for CPS systems")
Reported-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/15383/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Hogan [Thu, 29 Jun 2017 14:05:04 +0000 (15:05 +0100)]
MIPS: Avoid accidental raw backtrace
commit
854236363370995a609a10b03e35fd3dc5e9e4a1 upstream.
Since commit
81a76d7119f6 ("MIPS: Avoid using unwind_stack() with
usermode") show_backtrace() invokes the raw backtracer when
cp0_status & ST0_KSU indicates user mode to fix issues on EVA kernels
where user and kernel address spaces overlap.
However this is used by show_stack() which creates its own pt_regs on
the stack and leaves cp0_status uninitialised in most of the code paths.
This results in the non deterministic use of the raw back tracer
depending on the previous stack content.
show_stack() deals exclusively with kernel mode stacks anyway, so
explicitly initialise regs.cp0_status to KSU_KERNEL (i.e. 0) to ensure
we get a useful backtrace.
Fixes:
81a76d7119f6 ("MIPS: Avoid using unwind_stack() with usermode")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/16656/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Karl Beldan [Tue, 27 Jun 2017 19:22:16 +0000 (19:22 +0000)]
MIPS: head: Reorder instructions missing a delay slot
commit
25d8b92e0af75d72ce8b99e63e5a449cc0888efa upstream.
In this sequence the 'move' is assumed in the delay slot of the 'beq',
but head.S is in reorder mode and the former gets pushed one 'nop'
farther by the assembler.
The corrected behavior made booting with an UHI supplied dtb erratic.
Fixes:
15f37e158892 ("MIPS: store the appended dtb address in a variable")
Signed-off-by: Karl Beldan <karl.beldan+oss@gmail.com>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Cc: Jonas Gorski <jogo@openwrt.org>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/16614/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Rientjes [Fri, 7 Apr 2017 23:05:00 +0000 (16:05 -0700)]
mm, swap_cgroup: reschedule when neeed in swap_cgroup_swapoff()
commit
460bcec84e11c75122ace5976214abbc596eb91b upstream.
We got need_resched() warnings in swap_cgroup_swapoff() because
swap_cgroup_ctrl[type].length is particularly large.
Reschedule when needed.
Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1704061315270.80559@chino.kir.corp.google.com
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell Currey [Fri, 17 Feb 2017 03:33:01 +0000 (14:33 +1100)]
drm/ast: Handle configuration without P2A bridge
commit
71f677a91046599ece96ebab21df956ce909c456 upstream.
The ast driver configures a window to enable access into BMC
memory space in order to read some configuration registers.
If this window is disabled, which it can be from the BMC side,
the ast driver can't function.
Closing this window is a necessity for security if a machine's
host side and BMC side are controlled by different parties;
i.e. a cloud provider offering machines "bare metal".
A recent patch went in to try to check if that window is open
but it does so by trying to access the registers in question
and testing if the result is 0xffffffff.
This method will trigger a PCIe error when the window is closed
which on some systems will be fatal (it will trigger an EEH
for example on POWER which will take out the device).
This patch improves this in two ways:
- First, if the firmware has put properties in the device-tree
containing the relevant configuration information, we use these.
- Otherwise, a bit in one of the SCU scratch registers (which
are readable via the VGA register space and writeable by the BMC)
will indicate if the BMC has closed the window. This bit has been
defined by Y.C Chen from Aspeed.
If the window is closed and the configuration isn't available from
the device-tree, some sane defaults are used. Those defaults are
hopefully sufficient for standard video modes used on a server.
Signed-off-by: Russell Currey <ruscur@russell.cc>
Acked-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Juergen Gross [Thu, 18 May 2017 15:28:49 +0000 (17:28 +0200)]
xen/blkback: don't use xen_blkif_get() in xen-blkback kthread
commit
a24fa22ce22ae302b3bf8f7008896d52d5d57b8d upstream.
There is no need to use xen_blkif_get()/xen_blkif_put() in the kthread
of xen-blkback. Thread stopping is synchronous and using the blkif
reference counting in the kthread will avoid to ever let the reference
count drop to zero at the end of an I/O running concurrent to
disconnecting and multiple rings.
Setting ring->xenblkd to NULL after stopping the kthread isn't needed
as the kthread does this already.
Signed-off-by: Juergen Gross <jgross@suse.com>
Tested-by: Steven Haigh <netwiz@crc.id.au>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kinglong Mee [Thu, 27 Apr 2017 03:13:38 +0000 (11:13 +0800)]
NFSv4.x/callback: Create the callback service through svc_create_pooled
commit
df807fffaabde625fa9adb82e3e5b88cdaa5709a upstream.
As the comments for svc_set_num_threads() said,
" Destroying threads relies on the service threads filling in
rqstp->rq_task, which only the nfs ones do. Assumes the serv
has been created using svc_create_pooled()."
If creating service through svc_create(), the svc_pool_map_put()
will be called in svc_destroy(), but the pool map isn't used.
So that, the reference of pool map will be drop, the next using
of pool map will get a zero npools.
[ 137.992130] divide error: 0000 [#1] SMP
[ 137.992148] Modules linked in: nfsd(E) nfsv4 nfs fscache fuse tun bridge stp llc ip_set nfnetlink vmw_vsock_vmci_transport vsock snd_seq_midi snd_seq_midi_event vmw_balloon coretemp crct10dif_pclmul crc32_pclmul ppdev ghash_clmulni_intel intel_rapl_perf joydev snd_ens1371 gameport snd_ac97_codec ac97_bus snd_seq snd_pcm snd_rawmidi snd_timer snd_seq_device snd soundcore parport_pc parport nfit acpi_cpufreq tpm_tis tpm_tis_core tpm vmw_vmci i2c_piix4 shpchp auth_rpcgss nfs_acl lockd(E) grace sunrpc(E) xfs libcrc32c vmwgfx drm_kms_helper ttm crc32c_intel drm e1000 mptspi scsi_transport_spi serio_raw mptscsih mptbase ata_generic pata_acpi [last unloaded: nfsd]
[ 137.992336] CPU: 0 PID: 4514 Comm: rpc.nfsd Tainted: G E 4.11.0-rc8+ #536
[ 137.992777] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[ 137.993757] task:
ffff955984101d00 task.stack:
ffff9873c2604000
[ 137.994231] RIP: 0010:svc_pool_for_cpu+0x2b/0x80 [sunrpc]
[ 137.994768] RSP: 0018:
ffff9873c2607c18 EFLAGS:
00010246
[ 137.995227] RAX:
0000000000000000 RBX:
ffff95598376f000 RCX:
0000000000000002
[ 137.995673] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffff9559944aec00
[ 137.996156] RBP:
ffff9873c2607c18 R08:
ffff9559944aec28 R09:
0000000000000000
[ 137.996609] R10:
0000000001080002 R11:
0000000000000000 R12:
ffff95598376f010
[ 137.997063] R13:
ffff95598376f018 R14:
ffff9559944aec28 R15:
ffff9559944aec00
[ 137.997584] FS:
00007f755529eb40(0000) GS:
ffff9559bb600000(0000) knlGS:
0000000000000000
[ 137.998048] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 137.998548] CR2:
000055f3aecd9660 CR3:
0000000084290000 CR4:
00000000001406f0
[ 137.999052] Call Trace:
[ 137.999517] svc_xprt_do_enqueue+0xef/0x260 [sunrpc]
[ 138.000028] svc_xprt_received+0x47/0x90 [sunrpc]
[ 138.000487] svc_add_new_perm_xprt+0x76/0x90 [sunrpc]
[ 138.000981] svc_addsock+0x14b/0x200 [sunrpc]
[ 138.001424] ? recalc_sigpending+0x1b/0x50
[ 138.001860] ? __getnstimeofday64+0x41/0xd0
[ 138.002346] ? do_gettimeofday+0x29/0x90
[ 138.002779] write_ports+0x255/0x2c0 [nfsd]
[ 138.003202] ? _copy_from_user+0x4e/0x80
[ 138.003676] ? write_recoverydir+0x100/0x100 [nfsd]
[ 138.004098] nfsctl_transaction_write+0x48/0x80 [nfsd]
[ 138.004544] __vfs_write+0x37/0x160
[ 138.004982] ? selinux_file_permission+0xd7/0x110
[ 138.005401] ? security_file_permission+0x3b/0xc0
[ 138.005865] vfs_write+0xb5/0x1a0
[ 138.006267] SyS_write+0x55/0xc0
[ 138.006654] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 138.007071] RIP: 0033:0x7f7554b9dc30
[ 138.007437] RSP: 002b:
00007ffc9f92c788 EFLAGS:
00000246 ORIG_RAX:
0000000000000001
[ 138.007807] RAX:
ffffffffffffffda RBX:
0000000000000002 RCX:
00007f7554b9dc30
[ 138.008168] RDX:
0000000000000002 RSI:
00005640cd536640 RDI:
0000000000000003
[ 138.008573] RBP:
00007ffc9f92c780 R08:
0000000000000001 R09:
0000000000000002
[ 138.008918] R10:
0000000000000064 R11:
0000000000000246 R12:
0000000000000004
[ 138.009254] R13:
00005640cdbf77a0 R14:
00005640cdbf7720 R15:
00007ffc9f92c238
[ 138.009610] Code: 0f 1f 44 00 00 48 8b 87 98 00 00 00 55 48 89 e5 48 83 78 08 00 74 10 8b 05 07 42 02 00 83 f8 01 74 40 83 f8 02 74 19 31 c0 31 d2 <f7> b7 88 00 00 00 5d 89 d0 48 c1 e0 07 48 03 87 90 00 00 00 c3
[ 138.010664] RIP: svc_pool_for_cpu+0x2b/0x80 [sunrpc] RSP:
ffff9873c2607c18
[ 138.011061] ---[ end trace
b3468224cafa7d11 ]---
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kinglong Mee [Mon, 6 Mar 2017 14:29:14 +0000 (22:29 +0800)]
NFSv4: fix a reference leak caused WARNING messages
commit
366a1569bff3fe14abfdf9285e31e05e091745f5 upstream.
Because nfs4_opendata_access() has close the state when access is denied,
so the state isn't leak.
Rather than revert the commit
a974deee47, I'd like clean the strange state close.
[ 1615.094218] ------------[ cut here ]------------
[ 1615.094607] WARNING: CPU: 0 PID: 23702 at lib/list_debug.c:31 __list_add_valid+0x8e/0xa0
[ 1615.094913] list_add double add: new=
ffff9d7901d9f608, prev=
ffff9d7901d9f608, next=
ffff9d7901ee8dd0.
[ 1615.095458] Modules linked in: nfsv4(E) nfs(E) nfsd(E) tun bridge stp llc fuse ip_set nfnetlink vmw_vsock_vmci_transport vsock f2fs snd_seq_midi snd_seq_midi_event fscrypto coretemp ppdev crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_rapl_perf vmw_balloon snd_ens1371 joydev gameport snd_ac97_codec ac97_bus snd_seq snd_pcm snd_rawmidi snd_timer snd_seq_device snd soundcore nfit parport_pc parport acpi_cpufreq tpm_tis tpm_tis_core tpm i2c_piix4 vmw_vmci shpchp auth_rpcgss nfs_acl lockd(E) grace sunrpc(E) xfs libcrc32c vmwgfx drm_kms_helper ttm drm crc32c_intel mptspi e1000 serio_raw scsi_transport_spi mptscsih mptbase ata_generic pata_acpi fjes [last unloaded: nfs]
[ 1615.097663] CPU: 0 PID: 23702 Comm: fstest Tainted: G W E 4.11.0-rc1+ #517
[ 1615.098015] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[ 1615.098807] Call Trace:
[ 1615.099183] dump_stack+0x63/0x86
[ 1615.099578] __warn+0xcb/0xf0
[ 1615.099967] warn_slowpath_fmt+0x5f/0x80
[ 1615.100370] __list_add_valid+0x8e/0xa0
[ 1615.100760] nfs4_put_state_owner+0x75/0xc0 [nfsv4]
[ 1615.101136] __nfs4_close+0x109/0x140 [nfsv4]
[ 1615.101524] nfs4_close_state+0x15/0x20 [nfsv4]
[ 1615.101949] nfs4_close_context+0x21/0x30 [nfsv4]
[ 1615.102691] __put_nfs_open_context+0xb8/0x110 [nfs]
[ 1615.103155] put_nfs_open_context+0x10/0x20 [nfs]
[ 1615.103586] nfs4_file_open+0x13b/0x260 [nfsv4]
[ 1615.103978] do_dentry_open+0x20a/0x2f0
[ 1615.104369] ? nfs4_copy_file_range+0x30/0x30 [nfsv4]
[ 1615.104739] vfs_open+0x4c/0x70
[ 1615.105106] ? may_open+0x5a/0x100
[ 1615.105469] path_openat+0x623/0x1420
[ 1615.105823] do_filp_open+0x91/0x100
[ 1615.106174] ? __alloc_fd+0x3f/0x170
[ 1615.106568] do_sys_open+0x130/0x220
[ 1615.106920] ? __put_cred+0x3d/0x50
[ 1615.107256] SyS_open+0x1e/0x20
[ 1615.107588] entry_SYSCALL_64_fastpath+0x1a/0xa9
[ 1615.107922] RIP: 0033:0x7fab599069b0
[ 1615.108247] RSP: 002b:
00007ffcf0600d78 EFLAGS:
00000246 ORIG_RAX:
0000000000000002
[ 1615.108575] RAX:
ffffffffffffffda RBX:
00007fab59bcfae0 RCX:
00007fab599069b0
[ 1615.108896] RDX:
0000000000000200 RSI:
0000000000000200 RDI:
00007ffcf060255e
[ 1615.109211] RBP:
0000000000040010 R08:
0000000000000000 R09:
0000000000000016
[ 1615.109515] R10:
00000000000006a1 R11:
0000000000000246 R12:
0000000000041000
[ 1615.109806] R13:
0000000000040010 R14:
0000000000001000 R15:
0000000000002710
[ 1615.110152] ---[ end trace
96ed63b1306bf2f3 ]---
Fixes:
a974deee47 ("NFSv4: Fix memory and state leak in...")
Signed-off-by: Kinglong Mee <kinglongmee@gmail.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Cc: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Leblond [Thu, 11 May 2017 16:56:38 +0000 (18:56 +0200)]
netfilter: synproxy: fix conntrackd interaction
commit
87e94dbc210a720a34be5c1174faee5c84be963e upstream.
This patch fixes the creation of connection tracking entry from
netlink when synproxy is used. It was missing the addition of
the synproxy extension.
This was causing kernel crashes when a conntrack entry created by
conntrackd was used after the switch of traffic from active node
to the passive node.
Signed-off-by: Eric Leblond <eric@regit.org>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Mon, 3 Apr 2017 17:55:11 +0000 (10:55 -0700)]
netfilter: xt_TCPMSS: add more sanity tests on tcph->doff
commit
2638fd0f92d4397884fd991d8f4925cb3f081901 upstream.
Denys provided an awesome KASAN report pointing to an use
after free in xt_TCPMSS
I have provided three patches to fix this issue, either in xt_TCPMSS or
in xt_tcpudp.c. It seems xt_TCPMSS patch has the smallest possible
impact.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Denys Fedoryshchenko <nuclearcat@nuclearcat.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Serhey Popovych [Tue, 20 Jun 2017 11:35:23 +0000 (14:35 +0300)]
rtnetlink: add IFLA_GROUP to ifla_policy
[ Upstream commit
db833d40ad3263b2ee3b59a1ba168bb3cfed8137 ]
Network interface groups support added while ago, however
there is no IFLA_GROUP attribute description in policy
and netlink message size calculations until now.
Add IFLA_GROUP attribute to the policy.
Fixes:
cbda10fa97d7 ("net_device: add support for network device groups")
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Serhey Popovych [Tue, 20 Jun 2017 10:29:25 +0000 (13:29 +0300)]
ipv6: Do not leak throw route references
[ Upstream commit
07f615574f8ac499875b21c1142f26308234a92c ]
While commit
73ba57bfae4a ("ipv6: fix backtracking for throw routes")
does good job on error propagation to the fib_rules_lookup()
in fib rules core framework that also corrects throw routes
handling, it does not solve route reference leakage problem
happened when we return -EAGAIN to the fib_rules_lookup()
and leave routing table entry referenced in arg->result.
If rule with matched throw route isn't last matched in the
list we overwrite arg->result losing reference on throw
route stored previously forever.
We also partially revert commit
ab997ad40839 ("ipv6: fix the
incorrect return value of throw route") since we never return
routing table entry with dst.error == -EAGAIN when
CONFIG_IPV6_MULTIPLE_TABLES is on. Also there is no point
to check for RTF_REJECT flag since it is always set throw
route.
Fixes:
73ba57bfae4a ("ipv6: fix backtracking for throw routes")
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bert Kenward [Fri, 16 Jun 2017 08:45:08 +0000 (09:45 +0100)]
sfc: provide dummy definitions of vswitch functions
efx_probe_all() calls efx->type->vswitching_probe during probe. For
SFC4000 (Falcon) NICs this function is not defined, leading to a BUG
with the top of the call stack similar to:
? efx_pci_probe_main+0x29a/0x830
efx_pci_probe+0x7d3/0xe70
vswitching_restore and vswitching_remove also need to be defined.
Fixed in mainline by:
commit
5a6681e22c14 ("sfc: separate out SFC4000 ("Falcon") support into new sfc-falcon driver")
Fixes:
6d8aaaf6f798 ("sfc: create VEB vswitch and vport above default firmware setup")
Signed-off-by: Bert Kenward <bkenward@solarflare.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gao Feng [Fri, 16 Jun 2017 07:00:02 +0000 (15:00 +0800)]
net: 8021q: Fix one possible panic caused by BUG_ON in free_netdev
[ Upstream commit
9745e362add89432d2c951272a99b0a5fe4348a9 ]
The register_vlan_device would invoke free_netdev directly, when
register_vlan_dev failed. It would trigger the BUG_ON in free_netdev
if the dev was already registered. In this case, the netdev would be
freed in netdev_run_todo later.
So add one condition check now. Only when dev is not registered, then
free it directly.
The following is the part coredump when netdev_upper_dev_link failed
in register_vlan_dev. I removed the lines which are too long.
[ 411.237457] ------------[ cut here ]------------
[ 411.237458] kernel BUG at net/core/dev.c:7998!
[ 411.237484] invalid opcode: 0000 [#1] SMP
[ 411.237705] [last unloaded: 8021q]
[ 411.237718] CPU: 1 PID: 12845 Comm: vconfig Tainted: G E 4.12.0-rc5+ #6
[ 411.237737] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[ 411.237764] task:
ffff9cbeb6685580 task.stack:
ffffa7d2807d8000
[ 411.237782] RIP: 0010:free_netdev+0x116/0x120
[ 411.237794] RSP: 0018:
ffffa7d2807dbdb0 EFLAGS:
00010297
[ 411.237808] RAX:
0000000000000002 RBX:
ffff9cbeb6ba8fd8 RCX:
0000000000001878
[ 411.237826] RDX:
0000000000000001 RSI:
0000000000000282 RDI:
0000000000000000
[ 411.237844] RBP:
ffffa7d2807dbdc8 R08:
0002986100029841 R09:
0002982100029801
[ 411.237861] R10:
0004000100029980 R11:
0004000100029980 R12:
ffff9cbeb6ba9000
[ 411.238761] R13:
ffff9cbeb6ba9060 R14:
ffff9cbe60f1a000 R15:
ffff9cbeb6ba9000
[ 411.239518] FS:
00007fb690d81700(0000) GS:
ffff9cbebb640000(0000) knlGS:
0000000000000000
[ 411.239949] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 411.240454] CR2:
00007f7115624000 CR3:
0000000077cdf000 CR4:
00000000003406e0
[ 411.240936] Call Trace:
[ 411.241462] vlan_ioctl_handler+0x3f1/0x400 [8021q]
[ 411.241910] sock_ioctl+0x18b/0x2c0
[ 411.242394] do_vfs_ioctl+0xa1/0x5d0
[ 411.242853] ? sock_alloc_file+0xa6/0x130
[ 411.243465] SyS_ioctl+0x79/0x90
[ 411.243900] entry_SYSCALL_64_fastpath+0x1e/0xa9
[ 411.244425] RIP: 0033:0x7fb69089a357
[ 411.244863] RSP: 002b:
00007ffcd04e0fc8 EFLAGS:
00000202 ORIG_RAX:
0000000000000010
[ 411.245445] RAX:
ffffffffffffffda RBX:
00007ffcd04e2884 RCX:
00007fb69089a357
[ 411.245903] RDX:
00007ffcd04e0fd0 RSI:
0000000000008983 RDI:
0000000000000003
[ 411.246527] RBP:
00007ffcd04e0fd0 R08:
0000000000000000 R09:
1999999999999999
[ 411.246976] R10:
000000000000053f R11:
0000000000000202 R12:
0000000000000004
[ 411.247414] R13:
00007ffcd04e1128 R14:
00007ffcd04e2888 R15:
0000000000000001
[ 411.249129] RIP: free_netdev+0x116/0x120 RSP:
ffffa7d2807dbdb0
Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei Wang [Fri, 16 Jun 2017 17:46:37 +0000 (10:46 -0700)]
decnet: always not take dst->__refcnt when inserting dst into hash table
[ Upstream commit
76371d2e3ad1f84426a30ebcd8c3b9b98f4c724f ]
In the existing dn_route.c code, dn_route_output_slow() takes
dst->__refcnt before calling dn_insert_route() while dn_route_input_slow()
does not take dst->__refcnt before calling dn_insert_route().
This makes the whole routing code very buggy.
In dn_dst_check_expire(), dnrt_free() is called when rt expires. This
makes the routes inserted by dn_route_output_slow() not able to be
freed as the refcnt is not released.
In dn_dst_gc(), dnrt_drop() is called to release rt which could
potentially cause the dst->__refcnt to be dropped to -1.
In dn_run_flush(), dst_free() is called to release all the dst. Again,
it makes the dst inserted by dn_route_output_slow() not able to be
released and also, it does not wait on the rcu and could potentially
cause crash in the path where other users still refer to this dst.
This patch makes sure both input and output path do not take
dst->__refcnt before calling dn_insert_route() and also makes sure
dnrt_free()/dst_free() is called when removing dst from the hash table.
The only difference between those 2 calls is that dnrt_free() waits on
the rcu while dst_free() does not.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Maor Dickman [Thu, 18 May 2017 12:15:08 +0000 (15:15 +0300)]
net/mlx5e: Fix timestamping capabilities reporting
[ Upstream commit
f0b381178b01b831f9907d72f467d6443afdea67 ]
Misuse of (BIT) macro caused to report wrong flags for
"Hardware Transmit Timestamp Modes" and "Hardware Receive
Filter Modes"
Fixes:
ef9814deafd0 ('net/mlx5e: Add HW timestamping (TS) support')
Signed-off-by: Maor Dickman <maord@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eli Cohen [Thu, 8 Jun 2017 16:33:16 +0000 (11:33 -0500)]
net/mlx5: Wait for FW readiness before initializing command interface
[ Upstream commit
6c780a0267b8a1075f40b39851132eeaefefcff5 ]
Before attempting to initialize the command interface we must wait till
the fw_initializing bit is clear.
If we fail to meet this condition the hardware will drop our
configuration, specifically the descriptors page address. This scenario
can happen when the firmware is still executing an FLR flow and did not
finish yet so the driver needs to wait for that to finish.
Fixes:
e3297246c2c8 ('net/mlx5_core: Wait for FW readiness on startup')
Signed-off-by: Eli Cohen <eli@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Or Gerlitz [Thu, 15 Jun 2017 17:08:32 +0000 (20:08 +0300)]
net/mlx5e: Avoid doing a cleanup call if the profile doesn't have it
[ Upstream commit
31ac93386d135a6c96de9c8bab406f5ccabf5a4d ]
The error flow of mlx5e_create_netdev calls the cleanup call
of the given profile without checking if it exists, fix that.
Currently the VF reps don't register that callback and we crash
if getting into error -- can be reproduced by the user doing ctrl^C
while attempting to change the sriov mode from legacy to switchdev.
Fixes:
26e59d8077a3 '(net/mlx5e: Implement mlx5e interface attach/detach callbacks')
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Reported-by: Sabrina Dubroca <sdubroca@redhat.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Thu, 15 Jun 2017 09:49:08 +0000 (17:49 +0800)]
sctp: return next obj by passing pos + 1 into sctp_transport_get_idx
[ Upstream commit
988c7322116970696211e902b468aefec95b6ec4 ]
In sctp_for_each_transport, pos is used to save how many objs it has
dumped. Now it gets the last obj by sctp_transport_get_idx, then gets
the next obj by sctp_transport_get_next.
The issue is that in the meanwhile if some objs in transport hashtable
are removed and the objs nums are less than pos, sctp_transport_get_idx
would return NULL and hti.walker.tbl is NULL as well. At this moment
it should stop hti, instead of continue getting the next obj. Or it
would cause a NULL pointer dereference in sctp_transport_get_next.
This patch is to pass pos + 1 into sctp_transport_get_idx to get the
next obj directly, even if pos > objs nums, it would return NULL and
stop hti.
Fixes:
626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Thu, 15 Jun 2017 08:33:58 +0000 (16:33 +0800)]
ipv6: fix calling in6_ifa_hold incorrectly for dad work
[ Upstream commit
f8a894b218138888542a5058d0e902378fd0d4ec ]
Now when starting the dad work in addrconf_mod_dad_work, if the dad work
is idle and queued, it needs to hold ifa.
The problem is there's one gap in [1], during which if the pending dad work
is removed elsewhere. It will miss to hold ifa, but the dad word is still
idea and queue.
if (!delayed_work_pending(&ifp->dad_work))
in6_ifa_hold(ifp);
<--------------[1]
mod_delayed_work(addrconf_wq, &ifp->dad_work, delay);
An use-after-free issue can be caused by this.
Chen Wei found this issue when WARN_ON(!hlist_unhashed(&ifp->addr_lst)) in
net6_ifa_finish_destroy was hit because of it.
As Hannes' suggestion, this patch is to fix it by holding ifa first in
addrconf_mod_dad_work, then calling mod_delayed_work and putting ifa if
the dad_work is already in queue.
Note that this patch did not choose to fix it with:
if (!mod_delayed_work(delay))
in6_ifa_hold(ifp);
As with it, when delay == 0, dad_work would be scheduled immediately, all
addrconf_mod_dad_work(0) callings had to be moved under ifp->lock.
Reported-by: Wei Chen <weichen@redhat.com>
Suggested-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
WANG Cong [Tue, 20 Jun 2017 17:46:27 +0000 (10:46 -0700)]
igmp: add a missing spin_lock_init()
[ Upstream commit
b4846fc3c8559649277e3e4e6b5cec5348a8d208 ]
Andrey reported a lockdep warning on non-initialized
spinlock:
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 4099 Comm: a.out Not tainted 4.12.0-rc6+ #9
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
register_lock_class+0x717/0x1aa0 kernel/locking/lockdep.c:755
? 0xffffffffa0000000
__lock_acquire+0x269/0x3690 kernel/locking/lockdep.c:3255
lock_acquire+0x22d/0x560 kernel/locking/lockdep.c:3855
__raw_spin_lock_bh ./include/linux/spinlock_api_smp.h:135
_raw_spin_lock_bh+0x36/0x50 kernel/locking/spinlock.c:175
spin_lock_bh ./include/linux/spinlock.h:304
ip_mc_clear_src+0x27/0x1e0 net/ipv4/igmp.c:2076
igmpv3_clear_delrec+0xee/0x4f0 net/ipv4/igmp.c:1194
ip_mc_destroy_dev+0x4e/0x190 net/ipv4/igmp.c:1736
We miss a spin_lock_init() in igmpv3_add_delrec(), probably
because previously we never use it on this code path. Since
we already unlink it from the global mc_tomb list, it is
probably safe not to acquire this spinlock here. It does not
harm to have it although, to avoid conditional locking.
Fixes:
c38b7d327aaf ("igmp: acquire pmc lock for ip_mc_clear_src()")
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
WANG Cong [Mon, 12 Jun 2017 16:52:26 +0000 (09:52 -0700)]
igmp: acquire pmc lock for ip_mc_clear_src()
[ Upstream commit
c38b7d327aafd1e3ad7ff53eefac990673b65667 ]
Andrey reported a use-after-free in add_grec():
for (psf = *psf_list; psf; psf = psf_next) {
...
psf_next = psf->sf_next;
where the struct ip_sf_list's were already freed by:
kfree+0xe8/0x2b0 mm/slub.c:3882
ip_mc_clear_src+0x69/0x1c0 net/ipv4/igmp.c:2078
ip_mc_dec_group+0x19a/0x470 net/ipv4/igmp.c:1618
ip_mc_drop_socket+0x145/0x230 net/ipv4/igmp.c:2609
inet_release+0x4e/0x1c0 net/ipv4/af_inet.c:411
sock_release+0x8d/0x1e0 net/socket.c:597
sock_close+0x16/0x20 net/socket.c:1072
This happens because we don't hold pmc->lock in ip_mc_clear_src()
and a parallel mr_ifc_timer timer could jump in and access them.
The RCU lock is there but it is merely for pmc itself, this
spinlock could actually ensure we don't access them in parallel.
Thanks to Eric and Long for discussion on this bug.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Reviewed-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian Perle [Mon, 12 Jun 2017 08:06:57 +0000 (10:06 +0200)]
proc: snmp6: Use correct type in memset
[ Upstream commit
3500cd73dff48f28f4ba80c171c4c80034d40f76 ]
Reading /proc/net/snmp6 yields bogus values on 32 bit kernels.
Use "u64" instead of "unsigned long" in sizeof().
Fixes:
4a4857b1c81e ("proc: Reduce cache miss in snmp6_seq_show")
Signed-off-by: Christian Perle <christian.perle@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tal Gilboa [Mon, 29 May 2017 14:02:55 +0000 (17:02 +0300)]
net/mlx5e: Fix wrong indications in DIM due to counter wraparound
[ Upstream commit
53acd76ce571e3b71f9205f2d49ab285a9f1aad8 ]
DIM (Dynamically-tuned Interrupt Moderation) is a mechanism designed for
changing the channel interrupt moderation values in order to reduce CPU
overhead for all traffic types.
Each iteration of the algorithm, DIM calculates the difference in
throughput, packet rate and interrupt rate from last iteration in order
to make a decision. DIM relies on counters for each metric. When these
counters get to their type's max value they wraparound. In this case
the delta between 'end' and 'start' samples is negative and when
translated to unsigned integers - very high. This results in a false
indication to the algorithm and might result in a wrong decision.
The fix calculates the 'distance' between 'end' and 'start' samples in a
cyclic way around the relevant type's max value. It can also be viewed as
an absolute value around the type's max value instead of around 0.
Testing show higher stability in DIM profile selection and no wraparound
issues.
Fixes:
cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tal Gilboa [Mon, 15 May 2017 11:13:16 +0000 (14:13 +0300)]
net/mlx5e: Added BW check for DIM decision mechanism
[ Upstream commit
c3164d2fc48fd4fa0477ab658b644559c3fe9073 ]
DIM (Dynamically-tuned Interrupt Moderation) is a mechanism designed for
changing the channel interrupt moderation values in order to reduce CPU
overhead for all traffic types.
Until now only interrupt and packet rate were sampled.
We found a scenario on which we get a false indication since a change in
DIM caused more aggregation and reduced packet rate while increasing BW.
We now regard a change as succesfull iff:
current_BW > (prev_BW + threshold) or
current_BW ~= prev_BW and current_PR > (prev_PR + threshold) or
current_BW ~= prev_BW and current_PR ~= prev_PR and
current_IR < (prev_IR - threshold)
Where BW = Bandwidth, PR = Packet rate and IR = Interrupt rate
Improvements (ConnectX-4Lx 25GbE, single RX queue, LRO off)
--------------------------------------------------
packet size | before[Mb/s] | after[Mb/s] | gain |
2B | 343.4 | 359.4 | 4.5% |
16B | 2739.7 | 2814.8 | 2.7% |
64B | 9739 | 10185.3 | 4.5% |
Fixes:
cb3c7fd4f839 ("net/mlx5e: Support adaptive RX coalescing")
Signed-off-by: Tal Gilboa <talgi@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jia-Ju Bai [Sat, 10 Jun 2017 09:03:35 +0000 (17:03 +0800)]
net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse
[ Upstream commit
343eba69c6968190d8654b857aea952fed9a6749 ]
The kernel may sleep under a rcu read lock in tipc_msg_reverse, and the
function call path is:
tipc_l2_rcv_msg (acquire the lock by rcu_read_lock)
tipc_rcv
tipc_sk_rcv
tipc_msg_reverse
pskb_expand_head(GFP_KERNEL) --> may sleep
tipc_node_broadcast
tipc_node_xmit_skb
tipc_node_xmit
tipc_sk_rcv
tipc_msg_reverse
pskb_expand_head(GFP_KERNEL) --> may sleep
To fix it, "GFP_KERNEL" is replaced with "GFP_ATOMIC".
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jia-Ju Bai [Sat, 10 Jun 2017 08:49:39 +0000 (16:49 +0800)]
net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx
[ Upstream commit
f146e872eb12ebbe92d8e583b2637e0741440db3 ]
The kernel may sleep under a rcu read lock in cfpkt_create_pfx, and the
function call path is:
cfcnfg_linkup_rsp (acquire the lock by rcu_read_lock)
cfctrl_linkdown_req
cfpkt_create
cfpkt_create_pfx
alloc_skb(GFP_KERNEL) --> may sleep
cfserl_receive (acquire the lock by rcu_read_lock)
cfpkt_split
cfpkt_create_pfx
alloc_skb(GFP_KERNEL) --> may sleep
There is "in_interrupt" in cfpkt_create_pfx to decide use "GFP_KERNEL" or
"GFP_ATOMIC". In this situation, "GFP_KERNEL" is used because the function
is called under a rcu read lock, instead in interrupt.
To fix it, only "GFP_ATOMIC" is used in cfpkt_create_pfx.
Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Sat, 10 Jun 2017 06:48:14 +0000 (14:48 +0800)]
sctp: disable BH in sctp_for_each_endpoint
[ Upstream commit
581409dacc9176b0de1f6c4ca8d66e13aa8e1b29 ]
Now sctp holds read_lock when foreach sctp_ep_hashtable without disabling
BH. If CPU schedules to another thread A at this moment, the thread A may
be trying to hold the write_lock with disabling BH.
As BH is disabled and CPU cannot schedule back to the thread holding the
read_lock, while the thread A keeps waiting for the read_lock. A dead
lock would be triggered by this.
This patch is to fix this dead lock by calling read_lock_bh instead to
disable BH when holding the read_lock in sctp_for_each_endpoint.
Fixes:
626d16f50f39 ("sctp: export some apis or variables for sctp_diag and reuse some for proc")
Reported-by: Xiumei Mu <xmu@redhat.com>
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Krister Johansen [Thu, 8 Jun 2017 20:12:38 +0000 (13:12 -0700)]
Fix an intermittent pr_emerg warning about lo becoming free.
[ Upstream commit
f186ce61bb8235d80068c390dc2aad7ca427a4c2 ]
It looks like this:
Message from syslogd@flamingo at Apr 26 00:45:00 ...
kernel:unregister_netdevice: waiting for lo to become free. Usage count = 4
They seem to coincide with net namespace teardown.
The message is emitted by netdev_wait_allrefs().
Forced a kdump in netdev_run_todo, but found that the refcount on the lo
device was already 0 at the time we got to the panic.
Used bcc to check the blocking in netdev_run_todo. The only places
where we're off cpu there are in the rcu_barrier() and msleep() calls.
That behavior is expected. The msleep time coincides with the amount of
time we spend waiting for the refcount to reach zero; the rcu_barrier()
wait times are not excessive.
After looking through the list of callbacks that the netdevice notifiers
invoke in this path, it appears that the dst_dev_event is the most
interesting. The dst_ifdown path places a hold on the loopback_dev as
part of releasing the dev associated with the original dst cache entry.
Most of our notifier callbacks are straight-forward, but this one a)
looks complex, and b) places a hold on the network interface in
question.
I constructed a new bcc script that watches various events in the
liftime of a dst cache entry. Note that dst_ifdown will take a hold on
the loopback device until the invalidated dst entry gets freed.
[ __dst_free] on DST:
ffff883ccabb7900 IF tap1008300eth0 invoked at
1282115677036183
__dst_free
rcu_nocb_kthread
kthread
ret_from_fork
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mateusz Jurczyk [Thu, 8 Jun 2017 09:13:36 +0000 (11:13 +0200)]
af_unix: Add sockaddr length checks before accessing sa_family in bind and connect handlers
[ Upstream commit
defbcf2decc903a28d8398aa477b6881e711e3ea ]
Verify that the caller-provided sockaddr structure is large enough to
contain the sa_family field, before accessing it in bind() and connect()
handlers of the AF_UNIX socket. Since neither syscall enforces a minimum
size of the corresponding memory region, very short sockaddrs (zero or
one byte long) result in operating on uninitialized memory while
referencing .sa_family.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Ahern [Thu, 8 Jun 2017 17:31:11 +0000 (11:31 -0600)]
net: vrf: Make add_fib_rules per network namespace flag
[ Upstream commit
097d3c9508dc58286344e4a22b300098cf0c1566 ]
Commit
1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create")
adds the l3mdev FIB rule the first time a VRF device is created. However,
it only creates the rule once and only in the namespace the first device
is created - which may not be init_net. Fix by using the net_generic
capability to make the add_fib_rules flag per network namespace.
Fixes:
1aa6c4f6b8cd8 ("net: vrf: Add l3mdev rules on first device create")
Reported-by: Petr Machata <petrm@mellanox.com>
Signed-off-by: David Ahern <dsahern@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mintz, Yuval [Wed, 7 Jun 2017 18:00:33 +0000 (21:00 +0300)]
net: Zero ifla_vf_info in rtnl_fill_vfinfo()
[ Upstream commit
0eed9cf58446b28b233388b7f224cbca268b6986 ]
Some of the structure's fields are not initialized by the
rtnetlink. If driver doesn't set those in ndo_get_vf_config(),
they'd leak memory to user.
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
CC: Michal Schmidt <mschmidt@redhat.com>
Reviewed-by: Greg Rose <gvrose8192@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mateusz Jurczyk [Wed, 7 Jun 2017 14:14:29 +0000 (16:14 +0200)]
decnet: dn_rtmsg: Improve input length sanitization in dnrmg_receive_user_skb
[ Upstream commit
dd0da17b209ed91f39872766634ca967c170ada1 ]
Verify that the length of the socket buffer is sufficient to cover the
nlmsghdr structure before accessing the nlh->nlmsg_len field for further
input sanitization. If the client only supplies 1-3 bytes of data in
sk_buff, then nlh->nlmsg_len remains partially uninitialized and
contains leftover memory from the corresponding kernel allocation.
Operating on such data may result in indeterminate evaluation of the
nlmsg_len < sizeof(*nlh) expression.
The bug was discovered by a runtime instrumentation designed to detect
use of uninitialized memory in the kernel. The patch prevents this and
other similar tools (e.g. KMSAN) from flagging this behavior in the future.
Signed-off-by: Mateusz Jurczyk <mjurczyk@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Potapenko [Tue, 6 Jun 2017 13:56:54 +0000 (15:56 +0200)]
net: don't call strlen on non-terminated string in dev_set_alias()
[ Upstream commit
c28294b941232931fbd714099798eb7aa7e865d7 ]
KMSAN reported a use of uninitialized memory in dev_set_alias(),
which was caused by calling strlcpy() (which in turn called strlen())
on the user-supplied non-terminated string.
Signed-off-by: Alexander Potapenko <glider@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Willem de Bruijn [Sun, 19 Feb 2017 00:00:45 +0000 (19:00 -0500)]
ipv6: release dst on error in ip6_dst_lookup_tail
commit
00ea1ceebe0d9f2dc1cc2b7bd575a00100c27869 upstream.
If ip6_dst_lookup_tail has acquired a dst and fails the IPv4-mapped
check, release the dst before returning an error.
Fixes:
ec5e3b0a1d41 ("ipv6: Inhibit IPv4-mapped src address on the wire.")
Signed-off-by: Willem de Bruijn <willemb@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Cc: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 29 Jun 2017 11:00:49 +0000 (13:00 +0200)]
Linux 4.9.35
Arend Van Spriel [Fri, 16 Jun 2017 08:36:35 +0000 (09:36 +0100)]
brcmfmac: fix uninitialized warning in brcmf_usb_probe_phase2()
commit
35abcd4f9f303ac4f10f99b3f7e993e5f2e6fa37 upstream.
This fixes the following warning:
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c: In function
'brcmf_usb_probe_phase2':
drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c:1198:2:
warning: 'devinfo' may be used uninitialized in this function
[-Wmaybe-uninitialized]
mutex_unlock(&devinfo->dev_init_lock);
Fixes:
6d0507a777fb ("brcmfmac: add parameter to pass error code in firmware callback")
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Reported-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gleb Fotengauer-Malinovskiy [Mon, 20 Mar 2017 17:15:53 +0000 (20:15 +0300)]
jump label: fix passing kbuild_cflags when checking for asm goto support
commit
7292ae3d5a18fb922be496e6bb687647193569b4 upstream.
The latest change of asm goto support check added passing of KBUILD_CFLAGS
to compiler. When these flags reference gcc plugins that are not built yet,
the check fails.
When one runs "make bzImage" followed by "make modules", the kernel is always
built with HAVE_JUMP_LABEL disabled, while the modules are built depending on
CONFIG_JUMP_LABEL. If HAVE_JUMP_LABEL macro happens to be different, modules
are built with undefined references, e.g.:
ERROR: "static_key_slow_inc" [net/netfilter/xt_TEE.ko] undefined!
ERROR: "static_key_slow_dec" [net/netfilter/xt_TEE.ko] undefined!
ERROR: "static_key_slow_dec" [net/netfilter/nft_meta.ko] undefined!
ERROR: "static_key_slow_inc" [net/netfilter/nft_meta.ko] undefined!
ERROR: "nf_hooks_needed" [net/netfilter/ipvs/ip_vs.ko] undefined!
ERROR: "nf_hooks_needed" [net/ipv6/ipv6.ko] undefined!
ERROR: "static_key_count" [net/ipv6/ipv6.ko] undefined!
ERROR: "static_key_slow_inc" [net/ipv6/ipv6.ko] undefined!
This change moves the check before all these references are added
to KBUILD_CFLAGS. This is correct because subsequent KBUILD_CFLAGS
modifications are not relevant to this check.
Reported-by: Anton V. Boyarshinov <boyarsh@altlinux.org>
Fixes:
35f860f9ba6a ("jump label: pass kbuild_cflags when checking for asm goto support")
Signed-off-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Acked-by: David Lin <dtwlin@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Tue, 30 May 2017 15:21:51 +0000 (16:21 +0100)]
net: phy: fix marvell phy status reading
commit
898805e0cdf7fd860ec21bf661d3a0285a3defbd upstream.
The Marvell driver incorrectly provides phydev->lp_advertising as the
logical and of the link partner's advert and our advert. This is
incorrect - this field is supposed to store the link parter's unmodified
advertisment.
This allows ethtool to report the correct link partner auto-negotiation
status.
Fixes:
be937f1f89ca ("Marvell PHY m88e1111 driver fix")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hauke Mehrtens [Sun, 16 Apr 2017 23:38:05 +0000 (01:38 +0200)]
spi: double time out tolerance
commit
833bfade96561216aa2129516a5926a0326860a2 upstream.
The generic SPI code calculates how long the issued transfer would take
and adds 100ms in addition to the timeout as tolerance. On my 500 MHz
Lantiq Mips SoC I am getting timeouts from the SPI like this when the
system boots up:
m25p80 spi32766.4: SPI transfer timed out
blk_update_request: I/O error, dev mtdblock3, sector 2
SQUASHFS error: squashfs_read_data failed to read block 0x6e
After increasing the tolerance for the timeout to 200ms I haven't seen
these SPI transfer time outs any more.
The Lantiq SPI driver in use here has an extra work queue in between,
which gets triggered when the controller send the last word and the
hardware FIFOs used for reading and writing are only 8 words long.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Matthias Reichl [Mon, 20 Feb 2017 19:01:16 +0000 (20:01 +0100)]
dmaengine: bcm2835: Fix cyclic DMA period splitting
commit
2201ac6129fa162ac24da089a034bb0971648ebb upstream.
The code responsible for splitting periods into chunks that
can be handled by the DMA controller missed to update total_len,
the number of bytes processed in the current period, when there
are more chunks to follow.
Therefore total_len was stuck at 0 and the code didn't work at all.
This resulted in a wrong control block layout and audio issues because
the cyclic DMA callback wasn't executing on period boundaries.
Fix this by adding the missing total_len update.
Signed-off-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Tested-by: Clive Messer <clive.messer@digitaldreamtime.co.uk>
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yendapally Reddy Dhananjaya Reddy [Wed, 8 Feb 2017 22:14:26 +0000 (17:14 -0500)]
net: phy: Initialize mdio clock at probe function
commit
bb1a619735b4660f21bce3e728b937640024b4ad upstream.
USB PHYs need the MDIO clock divisor enabled earlier to work.
Initialize mdio clock divisor in probe function. The ext bus
bit available in the same register will be used by mdio mux
to enable external mdio.
Signed-off-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com>
Fixes:
ddc24ae1 ("net: phy: Broadcom iProc MDIO bus driver")
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stanislaw Gruszka [Thu, 2 Feb 2017 09:57:40 +0000 (10:57 +0100)]
rt2x00: avoid introducing a USB dependency in the rt2x00lib module
commit
6232c17438ed01f43665197db5a98a4a4f77ef47 upstream.
As reported by Felix:
Though protected by an ifdef, introducing an usb symbol dependency in
the rt2x00lib module is a major inconvenience for distributions that
package kernel modules split into individual packages.
Get rid of this unnecessary dependency by calling the usb related
function from a more suitable place.
Cc: Vishal Thanki <vishalthanki@gmail.com>
Reported-by: Felix Fietkau <nbd@nbd.name>
Fixes:
8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
William Wu [Tue, 25 Apr 2017 09:45:48 +0000 (17:45 +0800)]
usb: gadget: f_fs: avoid out of bounds access on comp_desc
commit
b7f73850bb4fac1e2209a4dd5e636d39be92f42c upstream.
Companion descriptor is only used for SuperSpeed endpoints,
if the endpoints are HighSpeed or FullSpeed, the Companion
descriptor will not allocated, so we can only access it if
gadget is SuperSpeed.
I can reproduce this issue on Rockchip platform rk3368 SoC
which supports USB 2.0, and use functionfs for ADB. Kernel
build with CONFIG_KASAN=y and CONFIG_SLUB_DEBUG=y report
the following BUG:
==================================================================
BUG: KASAN: slab-out-of-bounds in ffs_func_set_alt+0x224/0x3a0 at addr
ffffffc0601f6509
Read of size 1 by task swapper/0/0
============================================================================
BUG kmalloc-256 (Not tainted): kasan: bad access detected
----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: Allocated in ffs_func_bind+0x52c/0x99c age=1275 cpu=0 pid=1
alloc_debug_processing+0x128/0x17c
___slab_alloc.constprop.58+0x50c/0x610
__slab_alloc.isra.55.constprop.57+0x24/0x34
__kmalloc+0xe0/0x250
ffs_func_bind+0x52c/0x99c
usb_add_function+0xd8/0x1d4
configfs_composite_bind+0x48c/0x570
udc_bind_to_driver+0x6c/0x170
usb_udc_attach_driver+0xa4/0xd0
gadget_dev_desc_UDC_store+0xcc/0x118
configfs_write_file+0x1a0/0x1f8
__vfs_write+0x64/0x174
vfs_write+0xe4/0x200
SyS_write+0x68/0xc8
el0_svc_naked+0x24/0x28
INFO: Freed in inode_doinit_with_dentry+0x3f0/0x7c4 age=1275 cpu=7 pid=247
...
Call trace:
[<
ffffff900808aab4>] dump_backtrace+0x0/0x230
[<
ffffff900808acf8>] show_stack+0x14/0x1c
[<
ffffff90084ad420>] dump_stack+0xa0/0xc8
[<
ffffff90082157cc>] print_trailer+0x188/0x198
[<
ffffff9008215948>] object_err+0x3c/0x4c
[<
ffffff900821b5ac>] kasan_report+0x324/0x4dc
[<
ffffff900821aa38>] __asan_load1+0x24/0x50
[<
ffffff90089eb750>] ffs_func_set_alt+0x224/0x3a0
[<
ffffff90089d3760>] composite_setup+0xdcc/0x1ac8
[<
ffffff90089d7394>] android_setup+0x124/0x1a0
[<
ffffff90089acd18>] _setup+0x54/0x74
[<
ffffff90089b6b98>] handle_ep0+0x3288/0x4390
[<
ffffff90089b9b44>] dwc_otg_pcd_handle_out_ep_intr+0x14dc/0x2ae4
[<
ffffff90089be85c>] dwc_otg_pcd_handle_intr+0x1ec/0x298
[<
ffffff90089ad680>] dwc_otg_pcd_irq+0x10/0x20
[<
ffffff9008116328>] handle_irq_event_percpu+0x124/0x3ac
[<
ffffff9008116610>] handle_irq_event+0x60/0xa0
[<
ffffff900811af30>] handle_fasteoi_irq+0x10c/0x1d4
[<
ffffff9008115568>] generic_handle_irq+0x30/0x40
[<
ffffff90081159b4>] __handle_domain_irq+0xac/0xdc
[<
ffffff9008080e9c>] gic_handle_irq+0x64/0xa4
...
Memory state around the buggy address:
ffffffc0601f6400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffffffc0601f6480: 00 00 00 00 00 00 00 00 00 00 06 fc fc fc fc fc
>
ffffffc0601f6500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
^
ffffffc0601f6580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffffffc0601f6600: fc fc fc fc fc fc fc fc 00 00 00 00 00 00 00 00
==================================================================
Signed-off-by: William Wu <william.wu@rock-chips.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Cc: Jerry Zhang <zhangjerry@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joël Esponde [Wed, 23 Nov 2016 11:47:40 +0000 (12:47 +0100)]
mtd: spi-nor: fix spansion quad enable
commit
807c16253319ee6ccf8873ae64f070f7eb532cd5 upstream.
With the S25FL127S nor flash part, each writing to the configuration
register takes hundreds of ms. During that time, no more accesses to
the flash should be done (even reads).
This commit adds a wait loop after the register writing until the flash
finishes its work.
This issue could make rootfs mounting fail when the latter was done too
much closely to this quad enable bit setting step. And in this case, a
driver as UBIFS may try to recover the filesystem and may broke it
completely.
Signed-off-by: Joël Esponde <joel.esponde@honeywell.com>
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tobias Wolf [Wed, 23 Nov 2016 09:40:07 +0000 (10:40 +0100)]
of: Add check to of_scan_flat_dt() before accessing initial_boot_params
commit
3ec754410cb3e931a6c4920b1a150f21a94a2bf4 upstream.
An empty __dtb_start to __dtb_end section might result in
initial_boot_params being null for arch/mips/ralink. This showed that the
boot process hangs indefinitely in of_scan_flat_dt().
Signed-off-by: Tobias Wolf <dev-NTEO@vplace.de>
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14605/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Howells [Wed, 14 Jun 2017 23:12:24 +0000 (00:12 +0100)]
rxrpc: Fix several cases where a padded len isn't checked in ticket decode
commit
5f2f97656ada8d811d3c1bef503ced266fcd53a0 upstream.
This fixes CVE-2017-7482.
When a kerberos 5 ticket is being decoded so that it can be loaded into an
rxrpc-type key, there are several places in which the length of a
variable-length field is checked to make sure that it's not going to
overrun the available data - but the data is padded to the nearest
four-byte boundary and the code doesn't check for this extra. This could
lead to the size-remaining variable wrapping and the data pointer going
over the end of the buffer.
Fix this by making the various variable-length data checks use the padded
length.
Reported-by: 石磊 <shilei-c@360.cn>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Marc Dionne <marc.c.dionne@auristor.com>
Reviewed-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 15 Jun 2017 15:12:28 +0000 (11:12 -0400)]
drm/amdgpu: adjust default display clock
commit
52b482b0f4fd6d5267faf29fe91398e203f3c230 upstream.
Increase the default display clock on newer asics to
accomodate some high res modes with really high refresh
rates.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=93826
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 15 Jun 2017 14:55:11 +0000 (10:55 -0400)]
drm/amdgpu/atom: fix ps allocation size for EnableDispPowerGating
commit
05b4017b37f1fce4b7185f138126dd8decdb381f upstream.
We were using the wrong structure which lead to an overflow
on some boards.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=101387
Acked-by: Chunming Zhou <david1.zhou@amd.com>
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 19 Jun 2017 19:59:58 +0000 (15:59 -0400)]
drm/radeon: add a quirk for Toshiba Satellite L20-183
commit
acfd6ee4fa7ebeee75511825fe02be3f7ac1d668 upstream.
Fixes resume from suspend.
bug: https://bugzilla.kernel.org/show_bug.cgi?id=196121
Reported-by: Przemek <soprwa@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 19 Jun 2017 16:52:47 +0000 (12:52 -0400)]
drm/radeon: add a PX quirk for another K53TK variant
commit
4eb59793cca00b0e629b6d55b5abb5acb82c5868 upstream.
Disable PX on these systems.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=101491
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Thu, 8 Jun 2017 03:29:50 +0000 (20:29 -0700)]
iscsi-target: Reject immediate data underflow larger than SCSI transfer length
commit
abb85a9b512e8ca7ad04a5a8a6db9664fe644974 upstream.
When iscsi WRITE underflow occurs there are two different scenarios
that can happen.
Normally in practice, when an EDTL vs. SCSI CDB TRANSFER LENGTH
underflow is detected, the iscsi immediate data payload is the
smaller SCSI CDB TRANSFER LENGTH.
That is, when a host fabric LLD is using a fixed size EDTL for
a specific control CDB, the SCSI CDB TRANSFER LENGTH and actual
SCSI payload ends up being smaller than EDTL. In iscsi, this
means the received iscsi immediate data payload matches the
smaller SCSI CDB TRANSFER LENGTH, because there is no more
SCSI payload to accept beyond SCSI CDB TRANSFER LENGTH.
However, it's possible for a malicous host to send a WRITE
underflow where EDTL is larger than SCSI CDB TRANSFER LENGTH,
but incoming iscsi immediate data actually matches EDTL.
In the wild, we've never had a iscsi host environment actually
try to do this.
For this special case, it's wrong to truncate part of the
control CDB payload and continue to process the command during
underflow when immediate data payload received was larger than
SCSI CDB TRANSFER LENGTH, so go ahead and reject and drop the
bogus payload as a defensive action.
Note this potential bug was originally relaxed by the following
for allowing WRITE underflow in MSFT FCP host environments:
commit
c72c5250224d475614a00c1d7e54a67f77cd3410
Author: Roland Dreier <roland@purestorage.com>
Date: Wed Jul 22 15:08:18 2015 -0700
target: allow underflow/overflow for PR OUT etc. commands
Cc: Roland Dreier <roland@purestorage.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Sat, 3 Jun 2017 12:35:47 +0000 (05:35 -0700)]
iscsi-target: Fix delayed logout processing greater than SECONDS_FOR_LOGOUT_COMP
commit
105fa2f44e504c830697b0c794822112d79808dc upstream.
This patch fixes a BUG() in iscsit_close_session() that could be
triggered when iscsit_logout_post_handler() execution from within
tx thread context was not run for more than SECONDS_FOR_LOGOUT_COMP
(15 seconds), and the TCP connection didn't already close before
then forcing tx thread context to automatically exit.
This would manifest itself during explicit logout as:
[33206.974254] 1 connection(s) still exist for iSCSI session to iqn.1993-08.org.debian:01:
3f5523242179
[33206.980184] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 2100.772 msecs
[33209.078643] ------------[ cut here ]------------
[33209.078646] kernel BUG at drivers/target/iscsi/iscsi_target.c:4346!
Normally when explicit logout attempt fails, the tx thread context
exits and iscsit_close_connection() from rx thread context does the
extra cleanup once it detects conn->conn_logout_remove has not been
cleared by the logout type specific post handlers.
To address this special case, if the logout post handler in tx thread
context detects conn->tx_thread_active has already been cleared, simply
return and exit in order for existing iscsit_close_connection()
logic from rx thread context do failed logout cleanup.
Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
Tested-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Sagi Grimberg <sagig@mellanox.com>
Tested-by: Gary Guo <ghg@datera.io>
Tested-by: Chu Yuan Lin <cyl@datera.io>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Sat, 3 Jun 2017 03:00:17 +0000 (20:00 -0700)]
target: Fix kref->refcount underflow in transport_cmd_finish_abort
commit
73d4e580ccc5c3e05cea002f18111f66c9c07034 upstream.
This patch fixes a se_cmd->cmd_kref underflow during CMD_T_ABORTED
when a fabric driver drops it's second reference from below the
target_core_tmr.c based callers of transport_cmd_finish_abort().
Recently with the conversion of kref to refcount_t, this bug was
manifesting itself as:
[705519.601034] refcount_t: underflow; use-after-free.
[705519.604034] INFO: NMI handler (kgdb_nmi_handler) took too long to run: 20116.512 msecs
[705539.719111] ------------[ cut here ]------------
[705539.719117] WARNING: CPU: 3 PID: 26510 at lib/refcount.c:184 refcount_sub_and_test+0x33/0x51
Since the original kref atomic_t based kref_put() didn't check for
underflow and only invoked the final callback when zero was reached,
this bug did not manifest in practice since all se_cmd memory is
using preallocated tags.
To address this, go ahead and propigate the existing return from
transport_put_cmd() up via transport_cmd_finish_abort(), and
change transport_cmd_finish_abort() + core_tmr_handle_tas_abort()
callers to only do their local target_put_sess_cmd() if necessary.
Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
Tested-by: Bart Van Assche <bart.vanassche@sandisk.com>
Cc: Mike Christie <mchristi@redhat.com>
Cc: Hannes Reinecke <hare@suse.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Himanshu Madhani <himanshu.madhani@qlogic.com>
Cc: Sagi Grimberg <sagig@mellanox.com>
Tested-by: Gary Guo <ghg@datera.io>
Tested-by: Chu Yuan Lin <cyl@datera.io>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Thu, 8 Jun 2017 23:44:22 +0000 (16:44 -0700)]
arm64/vdso: Fix nsec handling for CLOCK_MONOTONIC_RAW
commit
dbb236c1ceb697a559e0694ac4c9e7b9131d0b16 upstream.
Recently vDSO support for CLOCK_MONOTONIC_RAW was added in
49eea433b326 ("arm64: Add support for CLOCK_MONOTONIC_RAW in
clock_gettime() vDSO"). Noticing that the core timekeeping code
never set tkr_raw.xtime_nsec, the vDSO implementation didn't
bother exposing it via the data page and instead took the
unshifted tk->raw_time.tv_nsec value which was then immediately
shifted left in the vDSO code.
Unfortunately, by accellerating the MONOTONIC_RAW clockid, it
uncovered potential 1ns time inconsistencies caused by the
timekeeping core not handing sub-ns resolution.
Now that the core code has been fixed and is actually setting
tkr_raw.xtime_nsec, we need to take that into account in the
vDSO by adding it to the shifted raw_time value, in order to
fix the user-visible inconsistency. Rather than do that at each
use (and expand the data page in the process), instead perform
the shift/addition operation when populating the data page and
remove the shift from the vDSO code entirely.
[jstultz: minor whitespace tweak, tried to improve commit
message to make it more clear this fixes a regression]
Reported-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Daniel Mentz <danielmentz@google.com>
Acked-by: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Link: http://lkml.kernel.org/r/1496965462-20003-4-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Stultz [Thu, 8 Jun 2017 23:44:21 +0000 (16:44 -0700)]
time: Fix CLOCK_MONOTONIC_RAW sub-nanosecond accounting
commit
3d88d56c5873f6eebe23e05c3da701960146b801 upstream.
Due to how the MONOTONIC_RAW accumulation logic was handled,
there is the potential for a 1ns discontinuity when we do
accumulations. This small discontinuity has for the most part
gone un-noticed, but since ARM64 enabled CLOCK_MONOTONIC_RAW
in their vDSO clock_gettime implementation, we've seen failures
with the inconsistency-check test in kselftest.
This patch addresses the issue by using the same sub-ns
accumulation handling that CLOCK_MONOTONIC uses, which avoids
the issue for in-kernel users.
Since the ARM64 vDSO implementation has its own clock_gettime
calculation logic, this patch reduces the frequency of errors,
but failures are still seen. The ARM64 vDSO will need to be
updated to include the sub-nanosecond xtime_nsec values in its
calculation for this issue to be completely fixed.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Tested-by: Daniel Mentz <danielmentz@google.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Kevin Brodsky <kevin.brodsky@arm.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Link: http://lkml.kernel.org/r/1496965462-20003-3-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Stultz [Thu, 8 Jun 2017 23:44:20 +0000 (16:44 -0700)]
time: Fix clock->read(clock) race around clocksource changes
commit
ceea5e3771ed2378668455fa21861bead7504df5 upstream.
In tests, which excercise switching of clocksources, a NULL
pointer dereference can be observed on AMR64 platforms in the
clocksource read() function:
u64 clocksource_mmio_readl_down(struct clocksource *c)
{
return ~(u64)readl_relaxed(to_mmio_clksrc(c)->reg) & c->mask;
}
This is called from the core timekeeping code via:
cycle_now = tkr->read(tkr->clock);
tkr->read is the cached tkr->clock->read() function pointer.
When the clocksource is changed then tkr->clock and tkr->read
are updated sequentially. The code above results in a sequential
load operation of tkr->read and tkr->clock as well.
If the store to tkr->clock hits between the loads of tkr->read
and tkr->clock, then the old read() function is called with the
new clock pointer. As a consequence the read() function
dereferences a different data structure and the resulting 'reg'
pointer can point anywhere including NULL.
This problem was introduced when the timekeeping code was
switched over to use struct tk_read_base. Before that, it was
theoretically possible as well when the compiler decided to
reload clock in the code sequence:
now = tk->clock->read(tk->clock);
Add a helper function which avoids the issue by reading
tk_read_base->clock once into a local variable clk and then issue
the read function via clk->read(clk). This guarantees that the
read() function always gets the proper clocksource pointer handed
in.
Since there is now no use for the tkr.read pointer, this patch
also removes it, and to address stopping the fast timekeeper
during suspend/resume, it introduces a dummy clocksource to use
rather then just a dummy read function.
Signed-off-by: John Stultz <john.stultz@linaro.org>
Acked-by: Ingo Molnar <mingo@kernel.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Stephen Boyd <stephen.boyd@linaro.org>
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Daniel Mentz <danielmentz@google.com>
Link: http://lkml.kernel.org/r/1496965462-20003-2-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arend Van Spriel [Mon, 12 Jun 2017 11:47:34 +0000 (12:47 +0100)]
brcmfmac: unbind all devices upon failure in firmware callback
commit
7a51461fc2da82a6c565a3ee65c41c197f28225d upstream.
When request firmware fails, brcmf_ops_sdio_remove is being called and
brcmf_bus freed. In such circumstancies if you do a suspend/resume cycle
the kernel hangs on resume due a NULL pointer dereference in resume
function. So in brcmf_sdio_firmware_callback() we need to unbind the
driver from both sdio_func devices when firmware load failure is indicated.
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arend Van Spriel [Mon, 12 Jun 2017 11:47:33 +0000 (12:47 +0100)]
brcmfmac: use firmware callback upon failure to load
commit
03fb0e8393fae8ebb6710a99387853ed0becbc8e upstream.
When firmware loading failed the code used to unbind the device provided
by the calling code. However, for the sdio driver two devices are bound
and both need to be released upon failure. The callback has been extended
with parameter to pass error code so add that in this commit upon firmware
loading failure.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arend Van Spriel [Mon, 12 Jun 2017 11:47:32 +0000 (12:47 +0100)]
brcmfmac: add parameter to pass error code in firmware callback
commit
6d0507a777fbc533f7f1bf5664a81982dd50dece upstream.
Extend the parameters in the firmware callback so it can be called
upon success and failure. This allows the caller to properly clear
all resources in the failure path. Right now the error code is
always zero, ie. success.
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Drake [Tue, 20 Jun 2017 02:48:52 +0000 (19:48 -0700)]
Input: i8042 - add Fujitsu Lifebook AH544 to notimeout list
commit
817ae460c784f32cd45e60b2b1b21378c3c6a847 upstream.
Without this quirk, the touchpad is not responsive on this product, with
the following message repeated in the logs:
psmouse serio1: bad data from KBC - timeout
Add it to the notimeout list alongside other similar Fujitsu laptops.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Naveen N. Rao [Tue, 13 Jun 2017 18:42:00 +0000 (00:12 +0530)]
powerpc/64s: Handle data breakpoints in Radix mode
commit
d89ba5353f301971dd7d2f9fdf25c4432728f38e upstream.
On Power9, trying to use data breakpoints throws the splat shown
below. This is because the check for a data breakpoint in DSISR is in
do_hash_page(), which is not called when in Radix mode.
Unable to handle kernel paging request for data at address 0xc000000000e19218
Faulting instruction address: 0xc0000000001155e8
cpu 0x0: Vector: 300 (Data Access) at [
c0000000ef1e7b20]
pc:
c0000000001155e8: find_pid_ns+0x48/0xe0
lr:
c000000000116ac4: find_task_by_vpid+0x44/0x90
sp:
c0000000ef1e7da0
msr:
9000000000009033
dar:
c000000000e19218
dsisr: 400000
Move the check to handle_page_fault() so as to catch data breakpoints
in both Hash and Radix MMU modes.
We have to change the check in do_hash_page() against 0xa410 to use
0xa450, so as to include the value of (DSISR_DABRMATCH << 16).
There are two sites that call handle_page_fault() when in Radix, both
already pass DSISR in r4.
Fixes:
caca285e5ab4 ("powerpc/mm/radix: Use STD_MMU_64 to properly isolate hash related code")
Reported-by: Shriya R. Kulkarni <shriykul@in.ibm.com>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
[mpe: Fix the fall-through case on hash, we need to reload DSISR]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Naveen N. Rao [Thu, 1 Jun 2017 10:48:15 +0000 (16:18 +0530)]
powerpc/kprobes: Pause function_graph tracing during jprobes handling
commit
a9f8553e935f26cb5447f67e280946b0923cd2dc upstream.
This fixes a crash when function_graph and jprobes are used together.
This is essentially commit
237d28db036e ("ftrace/jprobes/x86: Fix
conflict between jprobes and function graph tracing"), but for powerpc.
Jprobes breaks function_graph tracing since the jprobe hook needs to use
jprobe_return(), which never returns back to the hook, but instead to
the original jprobe'd function. The solution is to momentarily pause
function_graph tracing before invoking the jprobe hook and re-enable it
when returning back to the original jprobe'd function.
Fixes:
6794c78243bf ("powerpc64: port of the function graph tracer")
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>