If we detect a corrupted x18 and SCS is enabled, restore the register
before jumping back to instrumented code. This is safe, because the
wrapper is called with preemption disabled and a separate shadow stack
is used for interrupt handling.
Bug: 145210207
Change-Id: Idb75117e38c895231a14f5573261861e722c1264
(am from https://lore.kernel.org/patchwork/patch/1149060/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Don't lose the current task's shadow stack when the CPU is suspended.
Bug: 145210207
Change-Id: I8db58daadcc15a00a6f585580a3c97905c678eb3
(am from https://lore.kernel.org/patchwork/patch/1149059/)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reserve the x18 register from general allocation when SCS is enabled,
because the compiler uses the register to store the current task's
shadow stack pointer. Note that all external kernel modules must also be
compiled with -ffixed-x18 if the kernel has SCS enabled.
Bug: 145210207
Change-Id: I0407d38a0a5ecb6852b3f281d52f6601c565157e
(am from https://lore.kernel.org/patchwork/patch/1149058/)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
The graph tracer hooks returns by modifying frame records on the
(regular) stack, but with SCS the return address is taken from the
shadow stack, and the value in the frame record has no effect. As we
don't currently have a mechanism to determine the corresponding slot
on the shadow stack (and to pass this through the ftrace
infrastructure), for now let's disable the graph tracer when SCS is
enabled.
Bug: 145210207
Change-Id: I65dd098be827121ecf0c08538b11e3b98f5eacde
(am from https://lore.kernel.org/patchwork/patch/1149057/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Implements CONFIG_DEBUG_STACK_USAGE for shadow stacks. When enabled,
also prints out the highest shadow stack usage per process.
Bug: 145210207
Change-Id: I2b2fea68760ca8d94d6f887cfe5828883d233b88
(am from https://lore.kernel.org/patchwork/patch/1149056/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This change adds accounting for the memory allocated for shadow stacks.
Bug: 145210207
Change-Id: Iee94c22abefcabb63a3bcd4db8ba952130f30a82
(am from https://lore.kernel.org/patchwork/patch/1149055/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
This change adds generic support for Clang's Shadow Call Stack,
which uses a shadow stack to protect return addresses from being
overwritten by an attacker. Details are available here:
https://clang.llvm.org/docs/ShadowCallStack.html
Note that security guarantees in the kernel differ from the
ones documented for user space. The kernel must store addresses
of shadow stacks used by other tasks and interrupt handlers in
memory, which means an attacker capable reading and writing
arbitrary memory may be able to locate them and hijack control
flow by modifying shadow stacks that are not currently in use.
Bug: 145210207
Change-Id: I2a8ba6a3decac50c169731c3121c9dcab96621d2
(am from https://lore.kernel.org/patchwork/patch/1149054/)
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
The code in __cpu_soft_restart() uses x18 as an arbitrary temp register,
which will shortly be disallowed. So use x8 instead.
Bug: 145210207
Change-Id: Iad10392005b66e6bf3a0f00c40024448e9798b89
(am from https://lore.kernel.org/patchwork/patch/1149053/)
Link: https://patchwork.kernel.org/patch/9836877/
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
[Sami: updated commit message]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
In preparation of reserving x18, stop treating it as caller save in
the KVM guest entry/exit code. Currently, the code assumes there is
no need to preserve it for the host, given that it would have been
assumed clobbered anyway by the function call to __guest_enter().
Instead, preserve its value and restore it upon return.
Bug: 145210207
Change-Id: I341bcb10b615999a59a8413a6b98cb2ce1c62e02
(am from https://lore.kernel.org/patchwork/patch/1149065/)
Link: https://patchwork.kernel.org/patch/9836891/
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
[Sami: updated commit message, switched from x18 to x29 for the guest context]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Register x18 will no longer be used as a caller save register in the
future, so stop using it in the copy_page() code.
Bug: 145210207
Change-Id: Iffd77db101d6e83ec8c5e12b11d9f0fef09a630b
(am from https://lore.kernel.org/patchwork/patch/1149064/)
Link: https://patchwork.kernel.org/patch/9836869/
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
[Sami: changed the offset and bias to be explicit]
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
idmap_kpti_install_ng_mappings uses x18 as a temporary register, which
will result in a conflict when x18 is reserved. Use x16 and x17 instead
where needed.
Bug: 145210207
Change-Id: I9fbf40769c5c241422fff8558c7a9bade8ebadb6
(am from https://lore.kernel.org/patchwork/patch/1149052/)
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Because period and duty cycle are defined as ints with units of
nanoseconds, the maximum time duration that can be set is limited to
~2.147 seconds. Change their definitions to u64 in the structs of the
PWM framework so that higher durations may be set.
Also make the relevant fixes to those drivers that use the period and
duty_cycle struct members in division operations, viz. replacing the
division operations with 64-bit division macros as appropriate.
Bug: 140290586
Change-Id: Ibb8c7f007f4c11ebf8cf01e7a468cc9c29aa8b23
Link: https://www.spinics.net/lists/linux-pwm/msg11133.html
Signed-off-by: Guru Das Srinagesh <gurus@codeaurora.org>
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Todd Kjos <tkjos@google.com>
Set the default for FW_CACHE to n to match Android expectations.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 32180327
Bug: 137566496
Change-Id: I86a28040be07fb2f30125d28f7f379798727785c
Because firmware caching generates uevent messages that are sent over
a netlink socket, it can prevent suspend on many platforms. It's
also not always useful, so make it a configurable option.
Signed-off-by: Mark Salyzyn <salyzyn@android.com>
Cc: Tim Murray <timmurray@google.com>
Cc: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org>
Cc: Luis Chamberlain <mcgrof@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: linux-kernel@vger.kernel.org
Cc: kernel-team@android.com
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20191113225429.118495-1-salyzyn@android.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c74f805662 git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-testing)
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 32180327
Bug: 137566496
Change-Id: I1250512b27edb56caa78d536e5ccf1fb669476ad
I no longer work for Arm, so update the stale reference to my old email
address.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-15-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I7676e5f736fcb31376444bbfee419bc49ef17287
By conditionally dropping support for the legacy binding and exporting
the newly introduced 'arm_smmu_impl_init()' function we can allow the
ARM SMMU driver to be built as a module.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-14-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Id42da5829cb180966a0d051ec636be0c9f90efed
When removing the SMMU driver, we need to clear any state that we
registered during probe. This includes our bus ops, sysfs entries and
the IOMMU device registered for early firmware probing of masters.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-13-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I5dd6e68a609ac60bc704f9f916acc0f31dc1bd67
By removing the redundant call to 'pci_request_acs()' we can allow the
ARM SMMUv3 driver to be built as a module.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-12-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I1d8fbe26ab7114af6409ea13a68fff8afed49703
When removing the SMMUv3 driver, we need to clear any state that we
registered during probe. This includes our bus ops, sysfs entries and
the IOMMU device registered for early firmware probing of masters.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-11-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I54372d917c871231ced86250498fe2e45cf39246
Forcefully unbinding the Arm SMMU drivers is a pretty dangerous operation,
since it will likely lead to catastrophic failure for any DMA devices
mastering through the SMMU being unbound. When the driver then attempts
to "handle" the fatal faults, it's very easy to trip over dead data
structures, leading to use-after-free.
On John's machine, he reports that the machine was "unusable" due to
loss of the storage controller following a forced unbind of the SMMUv3
driver:
| # cd ./bus/platform/drivers/arm-smmu-v3
| # echo arm-smmu-v3.0.auto > unbind
| hisi_sas_v2_hw HISI0162:01: CQE_AXI_W_ERR (0x800) found!
| platform arm-smmu-v3.0.auto: CMD_SYNC timeout at 0x00000146
| [hwprod 0x00000146, hwcons 0x00000000]
Prevent this forced unbinding of the drivers by setting "suppress_bind_attrs"
to true.
Link: https://lore.kernel.org/lkml/06dfd385-1af0-3106-4cc5-6a5b8e864759@huawei.com
Reported-by: John Garry <john.garry@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-10-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I8b1c439f7ba11d6fc38cdf686948ef5909871dfb
This reverts commit addb672f20.
Let's get the SMMU driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-9-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I9779ffa7befa8535a0d7196ef5f728e40ae7d7f7
This reverts commit c07b6426df.
Let's get the SMMUv3 driver building as a module, which means putting
back some dead code that we used to carry.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-8-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ifde3c5dc81a0db600532b305906c67aa065d2f47
'bus_set_iommu()' allows IOMMU drivers to register their ops for a given
bus type. Unfortunately, it then doesn't allow them to be removed, which
is necessary for modular drivers to shutdown cleanly so that they can be
reloaded later on.
Allow 'bus_set_iommu()' to take a NULL 'ops' argument, which clear the
ops pointer for the selected bus_type.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-7-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ia89fa2df61d2a9ad04901d4c2e71e293c4c6171d
Ensure that we hold a reference to the IOMMU driver module while calling
the '->of_xlate()' callback during early device probing.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-6-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ica9ef2d5ed172c2451c0a19538dc28852c2270d5
To avoid accidental removal of an active IOMMU driver module, take a
reference to the driver module in 'iommu_probe_device()' immediately
prior to invoking the '->add_device()' callback and hold it until the
after the device has been removed by '->remove_device()'.
Suggested-by: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-5-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I8f6a8aad8c41faa51df9c3a440c8b80c74e3ce8a
Building drivers for ATS-aware IOMMUs as modules requires access to
pci_ats_disabled(). Export it as a GPL symbol to get things working.
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-4-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ia5457fd6c4593565799b97f40c0def3558a97696
To avoid having to export 'pci_request_acs()' to modular IOMMU drivers,
move the call into the 'of_dma_configure()' path in a similar manner to
the way in which ACS is configured when probing via ACPI/IORT.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-3-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: I3c689845ca493fbe037a2def2050a089036fb7d3
Building IOMMU drivers as modules requires that the core IOMMU API
symbols are exported as GPL symbols.
Signed-off-by: Will Deacon <will@kernel.org>
Bug: 140290589
Link: https://lore.kernel.org/lkml/20191121114918.2293-2-will@kernel.org/
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ic1b3b5e6e92c5852af1e3473dd230c506b8d7865
Commit 8e12257dea ("of: property: Add device link support for iommus,
mboxes and io-channels") added device link support for IOMMU linkages
described using the "iommus" property. For PCI devices, this property
is not present and instead the "iommu-map" property is used on the host
bridge node to map the endpoint RequesterIDs to their corresponding
IOMMU instance.
Add support for "iommu-map" to the device link supplier bindings so that
probing of PCI devices can be deferred until after the IOMMU is
available.
Cc: Rob Herring <robh@kernel.org>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Acked-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20191120190028.4722-1-will@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry-picked from commit e149573b2fhttps://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git driver-core-next)
Signed-off-by: Will Deacon <willdeacon@google.com>
Change-Id: Ife0cf1ed0256af47ed0cae7156f3184de355c42c
Pull cramfs fix from Al Viro:
"Regression fix, fallen through the cracks"
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
cramfs: fix usage on non-MTD device
When both CONFIG_CRAMFS_MTD and CONFIG_CRAMFS_BLOCKDEV are enabled, if
we fail to mount on MTD, we don't try on block device.
Note: this relies upon cramfs_mtd_fill_super() leaving no side
effects on fc state in case of failure; in general, failing
get_tree_...() does *not* mean "fine to try again"; e.g. parsed
options might've been consumed by fill_super callback and freed
on failure.
Fixes: 74f78fc5ef ("vfs: Convert cramfs to use the new mount API")
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Minor bugfixes all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAl3U6E4PHG1zdEByZWRo
YXQuY29tAAoJECgfDbjSjVRpi/oIAJwjsmGhheWTRa+vL/otHu1PjOQ4hziYwu/A
n80gp3pmPMa4yV5CDZt72qL4jH8llXPpH4gErvXvSyKfrvmelkJBILB53mAa04pq
BZWhkbcqldhMo35y3Ac+WcRk9zlkGq0NPuUcCb959h+pRXuZWtKWxQ2miwi413e1
1ecBRO64SvXSphflFfMMCB730aIXC/dsZAtBXqs8v+i4cIz9g8Z4fZS6c38nUA23
wBleNWylaxHn6UDRZAGRY12JFxFe3QxCP0RKTjwo0eF3HG7IZIGQKHnztjlqD4ko
ZOQmxPYW2+96XnS8n7y+gA517u10OIVZBocD9FX10c3wvS+Lpxg=
=KAuZ
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull last minute virtio bugfixes from Michael Tsirkin:
"Minor bugfixes all over the place"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio_balloon: fix shrinker count
virtio_balloon: fix shrinker scan number of pages
virtio_console: allocate inbufs in add_port() only if it is needed
virtio_ring: fix return code on DMA mapping fails
Pull input fix from Dmitry Torokhov:
"Just a single revert as RMI mode should not have been enabled for this
model [yet?]"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Revert "Input: synaptics - enable RMI mode for X1 Extreme 2nd Generation"
This reverts commit 68b9c5066e39af41d3448abfc887c77ce22dd64d.
Ugh, I really dropped the ball on this one :\. So as it turns out RMI4
works perfectly fine on the X1 Extreme Gen 2 except for one thing I
didn't notice because I usually use the trackpoint: clicking with the
touchpad. Somehow this is broken, in fact we don't even seem to indicate
BTN_LEFT as a valid event type for the RMI4 touchpad. And, I don't even
see any RMI4 events coming from the touchpad when I press down on it.
This only seems to work for PS/2 mode.
Since that means we have a regression, and PS/2 mode seems to work fine
for the time being - revert this for now. We'll have to do a more
thorough investigation on this.
Signed-off-by: Lyude Paul <lyude@redhat.com>
Link: https://lore.kernel.org/r/20191119234534.10725-1-lyude@redhat.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Pull networking fixes from David Miller:
1) Validate tunnel options length in act_tunnel_key, from Xin Long.
2) Fix DMA sync bug in gve driver, from Adi Suresh.
3) TSO kills performance on some r8169 chips due to HW issues, disable
by default in that case, from Corinna Vinschen.
4) Fix clock disable mismatch in fec driver, from Chubong Yuan.
5) Fix interrupt status bits define in hns3 driver, from Huazhong Tan.
6) Fix workqueue deadlocks in qeth driver, from Julian Wiedmann.
7) Don't napi_disable() twice in r8152 driver, from Hayes Wang.
8) Fix SKB extension memory leak, from Florian Westphal.
* git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (54 commits)
r8152: avoid to call napi_disable twice
MAINTAINERS: Add myself as maintainer of virtio-vsock
udp: drop skb extensions before marking skb stateless
net: rtnetlink: prevent underflows in do_setvfinfo()
can: m_can_platform: remove unnecessary m_can_class_resume() call
can: m_can_platform: set net_device structure as driver data
hv_netvsc: Fix send_table offset in case of a host bug
hv_netvsc: Fix offset usage in netvsc_send_table()
net-ipv6: IPV6_TRANSPARENT - check NET_RAW prior to NET_ADMIN
sfc: Only cancel the PPS workqueue if it exists
nfc: port100: handle command failure cleanly
net-sysfs: fix netdev_queue_add_kobject() breakage
r8152: Re-order napi_disable in rtl8152_close
net: qca_spi: Move reset_count to struct qcaspi
net: qca_spi: fix receive buffer size check
net/ibmvnic: Ignore H_FUNCTION return from H_EOI to tolerate XIVE mode
Revert "net/ibmvnic: Fix EOI when running in XIVE mode"
net/mlxfw: Verify FSM error code translation doesn't exceed array size
net/mlx5: Update the list of the PCI supported devices
net/mlx5: Fix auto group size calculation
...
By default s_maxbytes is set to MAX_NON_LFS, which limits the usable
file size to 2GB, enforced by the vfs.
Commit b9b1f8d593 ("AFS: write support fixes") added support for the
64-bit fetch and store server operations, but did not change this value.
As a result, attempts to write past the 2G mark result in EFBIG errors:
$ dd if=/dev/zero of=foo bs=1M count=1 seek=2048
dd: error writing 'foo': File too large
Set s_maxbytes to MAX_LFS_FILESIZE.
Fixes: b9b1f8d593 ("AFS: write support fixes")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Servers sending callback breaks to the YFS_CM_SERVICE service may
send up to YFSCBMAX (1024) fids in a single RPC. Anything over
AFSCBMAX (50) will cause the assert in afs_break_callbacks to trigger.
Remove the assert, as the count has already been checked against
the appropriate max values in afs_deliver_cb_callback and
afs_deliver_yfs_cb_callback.
Fixes: 35dbfba311 ("afs: Implement the YFS cache manager service")
Signed-off-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Call napi_disable() twice would cause dead lock. There are three situations
may result in the issue.
1. rtl8152_pre_reset() and set_carrier() are run at the same time.
2. Call rtl8152_set_tunable() after rtl8152_close().
3. Call rtl8152_set_ringparam() after rtl8152_close().
For #1, use the same solution as commit 8481141246 ("r8152: Re-order
napi_disable in rtl8152_close"). For #2 and #3, add checking the flag
of IFF_UP and using napi_disable/napi_enable during mutex.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Merge misc fixes from Andrew Morton:
"Three fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm/ksm.c: don't WARN if page is still mapped in remove_stable_node()
mm/memory_hotplug: don't access uninitialized memmaps in shrink_zone_span()
Revert "fs: ocfs2: fix possible null-pointer dereferences in ocfs2_xa_prepare_entry()"
