| Age | Commit message (Collapse) | Author |
|---|
|
In the current code, the nvme is using a fixed 4k PRP entry size,
but if the kernel use a page size which is more than 4k, we should
consider the situation that the bv_offset may be larger than the
dev->ctrl.page_size. Otherwise we may miss setting the prp2 and then
cause the command can't be executed correctly.
Fixes: dff824b2aadb ("nvme-pci: optimize mapping of small single segment requests")
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Keith Busch <kbusch@kernel.org>
|
|
* acpi-tables:
ACPI: HMAT: ACPI_HMAT_MEMORY_PD_VALID is deprecated since ACPI-6.3
|
|
When enabling KASAN and DEBUG_TEST_DRIVER_REMOVE, I find this KASAN
warning:
[ 20.872057] BUG: KASAN: use-after-free in pcc_data_alloc+0x40/0xb8
[ 20.878226] Read of size 4 at addr ffff00236cdeb684 by task swapper/0/1
[ 20.884826]
[ 20.886309] CPU: 19 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc1-00009-ge7f7df3db5bf-dirty #289
[ 20.894994] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
[ 20.903505] Call trace:
[ 20.905942] dump_backtrace+0x0/0x200
[ 20.909593] show_stack+0x14/0x20
[ 20.912899] dump_stack+0xd4/0x130
[ 20.916291] print_address_description.isra.9+0x6c/0x3b8
[ 20.921592] __kasan_report+0x12c/0x23c
[ 20.925417] kasan_report+0xc/0x18
[ 20.928808] __asan_load4+0x94/0xb8
[ 20.932286] pcc_data_alloc+0x40/0xb8
[ 20.935938] acpi_cppc_processor_probe+0x4e8/0xb08
[ 20.940717] __acpi_processor_start+0x48/0xb0
[ 20.945062] acpi_processor_start+0x40/0x60
[ 20.949235] really_probe+0x118/0x548
[ 20.952887] driver_probe_device+0x7c/0x148
[ 20.957059] device_driver_attach+0x94/0xa0
[ 20.961231] __driver_attach+0xa4/0x110
[ 20.965055] bus_for_each_dev+0xe8/0x158
[ 20.968966] driver_attach+0x30/0x40
[ 20.972531] bus_add_driver+0x234/0x2f0
[ 20.976356] driver_register+0xbc/0x1d0
[ 20.980182] acpi_processor_driver_init+0x40/0xe4
[ 20.984875] do_one_initcall+0xb4/0x254
[ 20.988700] kernel_init_freeable+0x24c/0x2f8
[ 20.993047] kernel_init+0x10/0x118
[ 20.996524] ret_from_fork+0x10/0x18
[ 21.000087]
[ 21.001567] Allocated by task 1:
[ 21.004785] save_stack+0x28/0xc8
[ 21.008089] __kasan_kmalloc.isra.9+0xbc/0xd8
[ 21.012435] kasan_kmalloc+0xc/0x18
[ 21.015913] pcc_data_alloc+0x94/0xb8
[ 21.019564] acpi_cppc_processor_probe+0x4e8/0xb08
[ 21.024343] __acpi_processor_start+0x48/0xb0
[ 21.028689] acpi_processor_start+0x40/0x60
[ 21.032860] really_probe+0x118/0x548
[ 21.036512] driver_probe_device+0x7c/0x148
[ 21.040684] device_driver_attach+0x94/0xa0
[ 21.044855] __driver_attach+0xa4/0x110
[ 21.048680] bus_for_each_dev+0xe8/0x158
[ 21.052591] driver_attach+0x30/0x40
[ 21.056155] bus_add_driver+0x234/0x2f0
[ 21.059980] driver_register+0xbc/0x1d0
[ 21.063805] acpi_processor_driver_init+0x40/0xe4
[ 21.068497] do_one_initcall+0xb4/0x254
[ 21.072322] kernel_init_freeable+0x24c/0x2f8
[ 21.076667] kernel_init+0x10/0x118
[ 21.080144] ret_from_fork+0x10/0x18
[ 21.083707]
[ 21.085186] Freed by task 1:
[ 21.088056] save_stack+0x28/0xc8
[ 21.091360] __kasan_slab_free+0x118/0x180
[ 21.095445] kasan_slab_free+0x10/0x18
[ 21.099183] kfree+0x80/0x268
[ 21.102139] acpi_cppc_processor_exit+0x1a8/0x1b8
[ 21.106832] acpi_processor_stop+0x70/0x80
[ 21.110917] really_probe+0x174/0x548
[ 21.114568] driver_probe_device+0x7c/0x148
[ 21.118740] device_driver_attach+0x94/0xa0
[ 21.122912] __driver_attach+0xa4/0x110
[ 21.126736] bus_for_each_dev+0xe8/0x158
[ 21.130648] driver_attach+0x30/0x40
[ 21.134212] bus_add_driver+0x234/0x2f0
[ 21.0x10/0x18
[ 21.161764]
[ 21.163244] The buggy address belongs to the object at ffff00236cdeb600
[ 21.163244] which belongs to the cache kmalloc-256 of size 256
[ 21.175750] The buggy address is located 132 bytes inside of
[ 21.175750] 256-byte region [ffff00236cdeb600, ffff00236cdeb700)
[ 21.187473] The buggy address belongs to the page:
[ 21.192254] page:fffffe008d937a00 refcount:1 mapcount:0 mapping:ffff002370c0fa00 index:0x0 compound_mapcount: 0
[ 21.202331] flags: 0x1ffff00000010200(slab|head)
[ 21.206940] raw: 1ffff00000010200 dead000000000100 dead000000000122 ffff002370c0fa00
[ 21.214671] raw: 0000000000000000 00000000802a002a 00000001ffffffff 0000000000000000
[ 21.222400] page dumped because: kasan: bad access detected
[ 21.227959]
[ 21.229438] Memory state around the buggy address:
[ 21.234218] ffff00236cdeb580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 21.241427] ffff00236cdeb600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 21.248637] >ffff00236cdeb680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 21.255845] ^
[ 21.259062] ffff00236cdeb700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 21.266272] ffff00236cdeb780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 21.273480] ==================================================================
It seems that global pcc_data[pcc_ss_id] can be freed in
acpi_cppc_processor_exit(), but we may later reference this value, so
NULLify it when freed.
Also remove the useless setting of data "pcc_channel_acquired", which
we're about to free.
Fixes: 85b1407bf6d2 ("ACPI / CPPC: Make CPPC ACPI driver aware of PCC subspace IDs")
Signed-off-by: John Garry <john.garry@huawei.com>
Cc: 4.15+ <stable@vger.kernel.org> # 4.15+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
* pm-cpufreq:
ACPI: processor: Avoid NULL pointer dereferences at init time
cpufreq: Avoid cpufreq_suspend() deadlock on system shutdown
* pm-sleep:
PM: sleep: include <linux/pm_runtime.h> for pm_wq
ACPI: PM: Drop Dell XPS13 9360 from LPS0 Idle _DSM blacklist
|
|
Update maintainers for MediaTek ethernet driver with Mark Lee.
He is familiar with MediaTek mt762x series ethernet devices and
will keep following maintenance from the vendor side.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Mark Lee <Mark-MC.Lee@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"The main thing here is a long-awaited workaround for a CPU erratum on
ThunderX2 which we have developed in conjunction with engineers from
Cavium/Marvell.
At the moment, the workaround is unconditionally enabled for affected
CPUs at runtime but we may add a command-line option to disable it in
future if performance numbers show up indicating a significant cost
for real workloads.
Summary:
- Work around Cavium/Marvell ThunderX2 erratum #219
- Fix regression in mlock() ABI caused by sign-extension of TTBR1 addresses
- More fixes to the spurious kernel fault detection logic
- Fix pathological preemption race when enabling some CPU features at boot
- Drop broken kcore macros in favour of generic implementations
- Fix userspace view of ID_AA64ZFR0_EL1 when SVE is disabled
- Avoid NULL dereference on allocation failure during hibernation"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: tags: Preserve tags for addresses translated via TTBR1
arm64: mm: fix inverted PAR_EL1.F check
arm64: sysreg: fix incorrect definition of SYS_PAR_EL1_F
arm64: entry.S: Do not preempt from IRQ before all cpufeatures are enabled
arm64: hibernate: check pgd table allocation
arm64: cpufeature: Treat ID_AA64ZFR0_EL1 as RAZ when SVE is not enabled
arm64: Fix kcore macros after 52-bit virtual addressing fallout
arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected
arm64: Avoid Cavium TX2 erratum 219 when switching TTBR
arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT
arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set
|
|
Jesse and Ido reported the following race condition:
<CPU A, t0> - Received packet A is forwarded and cached dst entry is
taken from the nexthop ('nhc->nhc_rth_input'). Calls skb_dst_set()
<t1> - Given Jesse has busy routers ("ingesting full BGP routing tables
from multiple ISPs"), route is added / deleted and rt_cache_flush() is
called
<CPU B, t2> - Received packet B tries to use the same cached dst entry
from t0, but rt_cache_valid() is no longer true and it is replaced in
rt_cache_route() by the newer one. This calls dst_dev_put() on the
original dst entry which assigns the blackhole netdev to 'dst->dev'
<CPU A, t3> - dst_input(skb) is called on packet A and it is dropped due
to 'dst->dev' being the blackhole netdev
There are 2 issues in the v4 routing code:
1. A per-netns counter is used to do the validation of the route. That
means whenever a route is changed in the netns, users of all routes in
the netns needs to redo lookup. v6 has an implementation of only
updating fn_sernum for routes that are affected.
2. When rt_cache_valid() returns false, rt_cache_route() is called to
throw away the current cache, and create a new one. This seems
unnecessary because as long as this route does not change, the route
cache does not need to be recreated.
To fully solve the above 2 issues, it probably needs quite some code
changes and requires careful testing, and does not suite for net branch.
So this patch only tries to add the deleted cached rt into the uncached
list, so user could still be able to use it to receive packets until
it's done.
Fixes: 95c47f9cf5e0 ("ipv4: call dst_dev_put() properly")
Signed-off-by: Wei Wang <weiwan@google.com>
Reported-by: Ido Schimmel <idosch@idosch.org>
Reported-by: Jesse Hathaway <jesse@mbuki-mvuki.org>
Tested-by: Jesse Hathaway <jesse@mbuki-mvuki.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Cc: David Ahern <dsahern@gmail.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Pull Xtensa fixes from Max Filippov:
- fix {get,put}_user() for 64bit values
- fix warning about static EXPORT_SYMBOL from modpost
- fix PCI IO ports mapping for the virt board
- fix pasto in change_bit for exclusive access option
* tag 'xtensa-20191017' of git://github.com/jcmvbkbc/linux-xtensa:
xtensa: fix change_bit in exclusive access option
xtensa: virt: fix PCI IO ports mapping
xtensa: drop EXPORT_SYMBOL for outs*/ins*
xtensa: fix type conversion in __get_user_[no]check
xtensa: clean up assembly arguments in uaccess macros
xtensa: fix {get,put}_user() for 64bit values
|
|
...instead of -EINVAL. An issue was found with older kernel versions
while unplugging a NFS client with pending RPCs, and the wrong error
code here prevented it from recovering once link is back up with a
configured address.
Incidentally, this is not an issue anymore since commit 4f8943f80883
("SUNRPC: Replace direct task wakeups from softirq context"), included
in 5.2-rc7, had the effect of decoupling the forwarding of this error
by using SO_ERROR in xs_wake_error(), as pointed out by Benjamin
Coddington.
To the best of my knowledge, this isn't currently causing any further
issue, but the error code doesn't look appropriate anyway, and we
might hit this in other paths as well.
In detail, as analysed by Gonzalo Siero, once the route is deleted
because the interface is down, and can't be resolved and we return
-EINVAL here, this ends up, courtesy of inet_sk_rebuild_header(),
as the socket error seen by tcp_write_err(), called by
tcp_retransmit_timer().
In turn, tcp_write_err() indirectly calls xs_error_report(), which
wakes up the RPC pending tasks with a status of -EINVAL. This is then
seen by call_status() in the SUN RPC implementation, which aborts the
RPC call calling rpc_exit(), instead of handling this as a
potentially temporary condition, i.e. as a timeout.
Return -EINVAL only if the input parameters passed to
ip_route_output_key_hash_rcu() are actually invalid (this is the case
if the specified source address is multicast, limited broadcast or
all zeroes), but return -ENETUNREACH in all cases where, at the given
moment, the given source address doesn't allow resolving the route.
While at it, drop the initialisation of err to -ENETUNREACH, which
was added to __ip_route_output_key() back then by commit
0315e3827048 ("net: Fix behaviour of unreachable, blackhole and
prohibit routes"), but actually had no effect, as it was, and is,
overwritten by the fib_lookup() return code assignment, and anyway
ignored in all other branches, including the if (fl4->saddr) one:
I find this rather confusing, as it would look like -ENETUNREACH is
the "default" error, while that statement has no effect.
Also note that after commit fc75fc8339e7 ("ipv4: dont create routes
on down devices"), we would get -ENETUNREACH if the device is down,
but -EINVAL if the source address is specified and we can't resolve
the route, and this appears to be rather inconsistent.
Reported-by: Stefan Walter <walteste@inf.ethz.ch>
Analysed-by: Benjamin Coddington <bcodding@redhat.com>
Analysed-by: Gonzalo Siero <gsierohu@redhat.com>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The KSZ8795 PHY ID is in fact used by KSZ8794/KSZ8795/KSZ8765 switches.
Update the PHY ID and name to reflect that, as this family of switches
is commonly refered to as KSZ87xx
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The KSZ8051 PHY and the KSZ8794/KSZ8795/KSZ8765 switch share exactly the
same PHY ID. Since KSZ8051 is higher in the ksphy_driver[] list of PHYs
in the micrel PHY driver, it is used even with the KSZ87xx switch. This
is wrong, since the KSZ8051 configures registers of the PHY which are
not present on the simplified KSZ87xx switch PHYs and misconfigures
other registers of the KSZ87xx switch PHYs.
Fortunatelly, it is possible to tell apart the KSZ8051 PHY from the
KSZ87xx switch by checking the Basic Status register Bit 0, which is
read-only and indicates presence of the Extended Capability Registers.
The KSZ8051 PHY has those registers while the KSZ87xx switch does not.
This patch implements simple check for the presence of this bit for
both the KSZ8051 PHY and KSZ87xx switch, to let both use the correct
PHY driver instance.
Fixes: 9d162ed69f51 ("net: phy: micrel: add support for KSZ8795")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Sean Nyekjaer <sean.nyekjaer@prevas.dk>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
If ctx->cached_sq_head < nxt_sq_head, we should add UINT_MAX to tmp, not
tmp_nxt.
Fixes: 5da0fb1ab34c ("io_uring: consider the overflow of sequence for timeout req")
Signed-off-by: yangerkun <yangerkun@huawei.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
We've got two issues with the non-regular file handling for non-blocking
IO:
1) We don't want to re-do a short read in full for a non-regular file,
as we can't just read the data again.
2) For non-regular files that don't support non-blocking IO attempts,
we need to punt to async context even if the file is opened as
non-blocking. Otherwise the caller always gets -EAGAIN.
Add two new request flags to handle these cases. One is just a cache
of the inode S_ISREG() status, the other tells io_uring that we always
need to punt this request to async context, even if REQ_F_NOWAIT is set.
Cc: stable@vger.kernel.org
Reported-by: Hrvoje Zeba <zeba.hrvoje@gmail.com>
Tested-by: Hrvoje Zeba <zeba.hrvoje@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Pull xfs fix from Darrick Wong:
"The single fix converts the seconds field in the recently added XFS
bulkstat structure to a signed 64-bit quantity.
The structure layout doesn't change and so far there are no users of
the ioctl to break because we only publish xfs ioctl interfaces
through the XFS userspace development libraries, and we're still
working on a 5.3 release"
* tag 'xfs-5.4-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: change the seconds fields in xfs_bulkstat to signed
|
|
Pull drm fixes from Dave Airlie:
"This is this weeks fixes for drm.
The dma-resv one is probably the more important one a fair few people
have reported it, besides that it's a couple of panfrost, a few i915
and a few amdgpu fixes.
One radeon patch to fix some ppc64 related issues caused an x86
regression so is getting reverted for now.
Summary:
dma-resv:
- shared fences for lima/panfrost
ttm:
- prefault regression fix
- lifetime fix
panfrost:
- stopped job timeout fix
- missing register values
amdgpu:
- smu7 powerplay fix
- bail earlier for cik/si detection
- navi SDMA fix
radeon:
- revert a ppc64 shutdown fix that broke x86
i915:
- VBT information handling fix
- Circular locking fix
- preemption vs resubmission virtual requests fix"
* tag 'drm-fixes-2019-10-18' of git://anongit.freedesktop.org/drm/drm:
drm/i915: Fixup preempt-to-busy vs resubmission of a virtual request
drm/i915/userptr: Never allow userptr into the mappable GGTT
drm/i915: Favor last VBT child device with conflicting AUX ch/DDC pin
drm/i915/execlists: Refactor -EIO markup of hung requests
drm/panfrost: Handle resetting on timeout better
drm/panfrost: Add missing GPU feature registers
drm/ttm: fix handling in ttm_bo_add_mem_to_lru
drm/ttm: Restore ttm prefaulting
drm/ttm: fix busy reference in ttm_mem_evict_first
drm/amdgpu/sdma5: fix mask value of POLL_REGMEM packet for pipe sync
drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1
Revert "drm/radeon: Fix EEH during kexec"
drm/msm/dsi: Implement reset correctly
dma-buf/resv: fix exclusive fence get
drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50
drm/tiny: Kconfig: Remove always-y THERMAL dep. from TINYDRM_REPAPER
drm/amdgpu/powerplay: fix typo in mvdd table setup
|
|
Workaround for Cavium/Marvell ThunderX2 erratum #219.
* errata/tx2-219:
arm64: Allow CAVIUM_TX2_ERRATUM_219 to be selected
arm64: Avoid Cavium TX2 erratum 219 when switching TTBR
arm64: Enable workaround for Cavium TX2 erratum 219 when running SMT
arm64: KVM: Trap VM ops when ARM64_WORKAROUND_CAVIUM_TX2_219_TVM is set
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
-dma-resv: Change shared_count to post-increment to fix lima crash (Qiang)
-ttm: A couple fixes related to lifetime and restore prefault behavior
(Christian & Thomas)
-panfrost: Fill in missing feature reg values and fix stoppedjob timeouts
(Steven)
Cc: Qiang Yu <yuq825@gmail.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Christian König <christian.koenig@amd.com>
Cc: Steven Price <steven.price@arm.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Sean Paul <sean@poorly.run>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017203419.GA142909@art_vandelay
|
|
git://people.freedesktop.org/~agd5f/linux into drm-fixes
drm-fixes-5.4-2019-10-16:
amdgpu:
- Powerplay fix for SMU7 parts
- Bail earlier when cik/si support is not set to 1
- Fix an SDMA issue on navi
radeon:
- revert a PPC fix which broken x86
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017022443.3853-1-alexander.deucher@amd.com
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes
- Display fix on handling VBT information.
- Important circular locking fix
- Fix for preemption vs resubmission on virtual requests
- and a prep patch to make this last one to apply cleanly
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191017135444.GA12255@intel.com
|
|
The KSZ driver uses one regmap per register width (8/16/32), each with
it's own lock, but accessing the same set of registers. In theory, it
is possible to create a race condition between these regmaps, although
the underlying bus (SPI or I2C) locking should assure nothing bad will
really happen and the accesses would be correct.
To make the driver do the right thing, add one single shared mutex for
all the regmaps used by the driver instead. This assures that even if
some future hardware is on a bus which does not serialize the accesses
the same way SPI or I2C does, nothing bad will happen.
Note that the status_mutex was unused and only initied, hence it was
renamed and repurposed as the regmap mutex.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The KSZ87xx driver calls mutex_init() on mutexes already inited in
ksz_common.c ksz_switch_register(). Do not do it twice, drop the
reinitialization.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: George McCollister <george.mccollister@gmail.com>
Cc: Tristram Ha <Tristram.Ha@microchip.com>
Cc: Woojung Huh <woojung.huh@microchip.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The stmmac_pcs_ctrl_ane() expects a register address as
argument 1, but for some reason the mac_device_info is
being passed.
Fix the warning (and possible bug) from sparse:
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: warning: incorrect type in argument 1 (different address spaces)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: expected void [noderef] <asn:2> *ioaddr
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:2613:17: got struct mac_device_info *hw
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Ioana Ciornei says:
====================
dpaa2-eth: misc fixes
This patch set adds a couple of fixes around updating configuration on MAC
change. Depending on when MC connects the DPNI to a MAC, both the MAC
address and TX FQIDs should be updated everytime there is a change in
configuration.
Changes in v2:
- used reverse christmas tree ordering in patch 2/2
Changes in v3:
- add a missing new line
- go back to FQ based enqueueing after a transient error
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Depending on when MC connects the DPNI to a MAC, Tx FQIDs may
not be available during probe time.
Read the FQIDs each time the link goes up to avoid using invalid
values. In case an error occurs or an invalid value is retrieved,
fall back to QDID-based enqueueing.
Fixes: 1fa0f68c9255 ("dpaa2-eth: Use FQ-based DPIO enqueue API")
Signed-off-by: Ioana Radulescu <ruxandra.radulescu@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Add IRQ for the DPNI endpoint change event, resolving the issue
when a dynamically created DPNI gets a randomly generated hw address
when the endpoint is a DPMAC object.
Signed-off-by: Florin Chiculita <florinlaurentiu.chiculita@nxp.com>
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The serial state information must not be embedded into another
data structure, as this interferes with cache handling for DMA
on architectures without cache coherence..
That would result in data corruption on some architectures
Allocating it separately.
v2: fix syntax error
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
"The main change is that we are reverting blanket enablement of SMBus
mode for devices with Elan touchpads that report BIOS release date as
2018+ because there are older boxes with updated BIOSes that still do
not work well in SMbus mode.
We will have to establish whitelist for SMBus mode it looks like"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Revert "Input: elantech - enable SMBus on new (2018+) systems"
Input: synaptics-rmi4 - avoid processing unknown IRQs
Input: soc_button_array - partial revert of support for newer surface devices
Input: goodix - add support for 9-bytes reports
Input: da9063 - fix capability and drop KEY_SLEEP
|
|
While it is useful for new drivers to use devm_platform_ioremap_resource,
this script is currently used to spam maintainers, often updating very
old drivers. The net benefit is the removal of 2 lines of code in the
driver but the review load for the maintainers is huge. As of now, more
that 560 patches have been sent, some of them obviously broken, as in:
https://lore.kernel.org/lkml/9bbcce19c777583815c92ce3c2ff2586@www.loen.fr/
Remove the script to reduce the spam.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Przemysław Kopa reports that since commit b516ea586d71 ("PCI: Enable
NVIDIA HDA controllers"), the discrete GPU Nvidia GeForce GT 540M on his
2011 Samsung laptop refuses to runtime suspend, resulting in a power
regression and excessive heat.
Rivera Valdez witnesses the same issue with a GeForce GT 525M (GF108M)
of the same era, as does another Arch Linux user named "R0AR" with a
more recent GeForce GTX 1050 Ti (GP107M).
The commit exposes the discrete GPU's HDA controller and all four codecs
on the controller do not set the CLKSTOP and EPSS bits in the Supported
Power States Response. They also do not set the PS-ClkStopOk bit in the
Get Power State Response. hda_codec_runtime_suspend() therefore does
not call snd_hdac_codec_link_down(), which prevents each codec and the
PCI device from runtime suspending.
The same issue is present on some AMD discrete GPUs and we addressed it
by forcing runtime PM despite the bits not being set, see commit
57cb54e53bdd ("ALSA: hda - Force to link down at runtime suspend on
ATI/AMD HDMI").
Do the same for Nvidia HDMI codecs.
Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers")
Link: https://bbs.archlinux.org/viewtopic.php?pid=1865512
Link: https://bugs.freedesktop.org/show_bug.cgi?id=75985#c81
Reported-by: Przemysław Kopa <prymoo@gmail.com>
Reported-by: Rivera Valdez <riveravaldez@ysinembargo.com>
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Cc: Daniel Drake <dan@reactivated.net>
Cc: stable@vger.kernel.org # v5.3+
Link: https://lore.kernel.org/r/3086bc75135c1e3567c5bc4f3cc4ff5cbf7a56c2.1571324194.git.lukas@wunner.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
git://git.infradead.org/linux-platform-drivers-x86
Pull x86 platform driver fixes from Andy Shevchenko:
- Users of Intel P-Unit IPC driver might be surprised by harmless
warning. Thus, switch to API which doesn't issue a warning at all.
- I²C multi-instantiate driver continues to add slave devices even when
IRQ resource is not found. For devices in the market IRQ resource is
mandatory, so, fail the ->probe() of the parent driver to avoid
slaves being probed.
- Avoid compiler warning due to unused variable in Classmate laptop
driver.
* tag 'platform-drivers-x86-v5.4-3' of git://git.infradead.org/linux-platform-drivers-x86:
platform/x86: i2c-multi-instantiate: Fail the probe if no IRQ provided
platform/x86: intel_punit_ipc: Avoid error message when retrieving IRQ
platform/x86: classmate-laptop: remove unused variable
|
|
GFP_NOWAIT allocation can fail anytime - it doesn't wait for memory being
available and it fails if the mempool is exhausted and there is not enough
memory.
If we go down this path:
map_bio -> mg_start -> alloc_migration -> mempool_alloc(GFP_NOWAIT)
we can see that map_bio() doesn't check the return value of mg_start(),
and the bio is leaked.
If we go down this path:
map_bio -> mg_start -> mg_lock_writes -> alloc_prison_cell ->
dm_bio_prison_alloc_cell_v2 -> mempool_alloc(GFP_NOWAIT) ->
mg_lock_writes -> mg_complete
the bio is ended with an error - it is unacceptable because it could
cause filesystem corruption if the machine ran out of memory
temporarily.
Change GFP_NOWAIT to GFP_NOIO, so that the mempool code will properly
wait until memory becomes available. mempool_alloc with GFP_NOIO can't
fail, so remove the code paths that deal with allocation failure.
Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"The fixes pertain to a problem with initializing the Intel GPIO
irqchips when adding gpiochips.
Andy fixed it up elegantly by adding a hardware initialization
callback to the struct gpio_irq_chip so let's use this. Tested and
verified on the target hardware"
* tag 'gpio-v5.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: lynxpoint: set default handler to be handle_bad_irq()
gpio: merrifield: Move hardware initialization to callback
gpio: lynxpoint: Move hardware initialization to callback
gpio: intel-mid: Move hardware initialization to callback
gpiolib: Initialize the hardware with a callback
gpio: merrifield: Restore use of irq_base
|
|
On Asus MJ401TA (with Realtek ALC256), the headset mic is connected to
pin 0x19, with default configuration value 0x411111f0 (indicating no
physical connection).
Enable this by quirking the pin. Mic jack detection was also tested and
found to be working.
This enables use of the headset mic on this product.
Signed-off-by: Daniel Drake <drake@endlessm.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191017081501.17135-1-drake@endlessm.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
BOSS Katana amplifiers cannot be used for recording or playback if quirks
are applied
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=195223
Signed-off-by: Szabolcs Szőke <szszoke.code@gmail.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191011171937.8013-1-szszoke.code@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
disable ptp_ref_clk in suspend flow, and enable it in resume flow.
Fixes: f573c0b9c4e0 ("stmmac: move stmmac_clk, pclk, clk_ptp_ref and stmmac_rst to platform structure")
Signed-off-by: Biao Huang <biao.huang@mediatek.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Some drivers just call phy_ethtool_ksettings_set() to set the
links, for those phy drivers that use genphy_read_status(), if
autoneg is on, and the link is up, than execute "ethtool -s
ethx autoneg on" will cause "link partner" information disappear.
The call trace is phy_ethtool_ksettings_set()->phy_start_aneg()
->linkmode_zero(phydev->lp_advertising)->genphy_read_status(),
the link didn't change, so genphy_read_status() just return, and
phydev->lp_advertising is zero now.
This patch moves the clear operation of lp_advertising from
phy_start_aneg() to genphy_read_lpa()/genphy_c45_read_lpa(), and
if autoneg on and autoneg not complete, just clear what the
generic functions care about.
Fixes: 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in genphy_read_status")
Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We need to extend the rcu_read_lock() section in rxrpc_error_report()
and use rcu_dereference_sk_user_data() instead of plain access
to sk->sk_user_data to make sure all rules are respected.
The compiler wont reload sk->sk_user_data at will, and RCU rules
prevent memory beeing freed too soon.
Fixes: f0308fb07080 ("rxrpc: Fix possible NULL pointer access in ICMP handling")
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
As preempt-to-busy leaves the request on the HW as the resubmission is
processed, that request may complete in the background and even cause a
second virtual request to enter queue. This second virtual request
breaks our "single request in the virtual pipeline" assumptions.
Furthermore, as the virtual request may be completed and retired, we
lose the reference the virtual engine assumes is held. Normally, just
removing the request from the scheduler queue removes it from the
engine, but the virtual engine keeps track of its singleton request via
its ve->request. This pointer needs protecting with a reference.
v2: Drop unnecessary motion of rq->engine = owner
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190923152844.8914-1-chris@chris-wilson.co.uk
(cherry picked from commit b647c7df01b75761b4c0b1cb6f4841088c0b1121)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to
invalidate userptr objects which also happen to be pulled into GGTT
mmaps. That is when we unbind the userptr object (on mmu invalidation),
we revoke all CPU mmaps, which may then recurse into mmu invalidation.
We looked for ways of breaking the cycle, but the revocation on
invalidation is required and cannot be avoided. The only solution we
could see was to not allow such GGTT bindings of userptr objects in the
first place. In practice, no one really wants to use a GGTT mmapping of
a CPU pointer...
Just before Daniel's explosive lockdep patches land in v5.4-rc1, we got
a genuine blip from CI:
<4>[ 246.793958] ======================================================
<4>[ 246.793972] WARNING: possible circular locking dependency detected
<4>[ 246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G U
<4>[ 246.794003] ------------------------------------------------------
<4>[ 246.794017] kswapd0/145 is trying to acquire lock:
<4>[ 246.794030] 000000003f565be6 (&dev->struct_mutex/1){+.+.}, at: userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[ 246.794250]
but task is already holding lock:
<4>[ 246.794263] 000000001799cef9 (&anon_vma->rwsem){++++}, at: page_lock_anon_vma_read+0xe6/0x2a0
<4>[ 246.794291]
which lock already depends on the new lock.
<4>[ 246.794307]
the existing dependency chain (in reverse order) is:
<4>[ 246.794322]
-> #3 (&anon_vma->rwsem){++++}:
<4>[ 246.794344] down_write+0x33/0x70
<4>[ 246.794357] __vma_adjust+0x3d9/0x7b0
<4>[ 246.794370] __split_vma+0x16a/0x180
<4>[ 246.794385] mprotect_fixup+0x2a5/0x320
<4>[ 246.794399] do_mprotect_pkey+0x208/0x2e0
<4>[ 246.794413] __x64_sys_mprotect+0x16/0x20
<4>[ 246.794429] do_syscall_64+0x55/0x1c0
<4>[ 246.794443] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794456]
-> #2 (&mapping->i_mmap_rwsem){++++}:
<4>[ 246.794478] down_write+0x33/0x70
<4>[ 246.794493] unmap_mapping_pages+0x48/0x130
<4>[ 246.794519] i915_vma_revoke_mmap+0x81/0x1b0 [i915]
<4>[ 246.794519] i915_vma_unbind+0x11d/0x4a0 [i915]
<4>[ 246.794519] i915_vma_destroy+0x31/0x300 [i915]
<4>[ 246.794519] __i915_gem_free_objects+0xb8/0x4b0 [i915]
<4>[ 246.794519] drm_file_free.part.0+0x1e6/0x290
<4>[ 246.794519] drm_release+0xa6/0xe0
<4>[ 246.794519] __fput+0xc2/0x250
<4>[ 246.794519] task_work_run+0x82/0xb0
<4>[ 246.794519] do_exit+0x35b/0xdb0
<4>[ 246.794519] do_group_exit+0x34/0xb0
<4>[ 246.794519] __x64_sys_exit_group+0xf/0x10
<4>[ 246.794519] do_syscall_64+0x55/0x1c0
<4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794519]
-> #1 (&vm->mutex){+.+.}:
<4>[ 246.794519] i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915]
<4>[ 246.794519] i915_address_space_init+0x9f/0x160 [i915]
<4>[ 246.794519] i915_ggtt_init_hw+0x55/0x170 [i915]
<4>[ 246.794519] i915_driver_probe+0xc9f/0x1620 [i915]
<4>[ 246.794519] i915_pci_probe+0x43/0x1b0 [i915]
<4>[ 246.794519] pci_device_probe+0x9e/0x120
<4>[ 246.794519] really_probe+0xea/0x3d0
<4>[ 246.794519] driver_probe_device+0x10b/0x120
<4>[ 246.794519] device_driver_attach+0x4a/0x50
<4>[ 246.794519] __driver_attach+0x97/0x130
<4>[ 246.794519] bus_for_each_dev+0x74/0xc0
<4>[ 246.794519] bus_add_driver+0x13f/0x210
<4>[ 246.794519] driver_register+0x56/0xe0
<4>[ 246.794519] do_one_initcall+0x58/0x300
<4>[ 246.794519] do_init_module+0x56/0x1f6
<4>[ 246.794519] load_module+0x25bd/0x2a40
<4>[ 246.794519] __se_sys_finit_module+0xd3/0xf0
<4>[ 246.794519] do_syscall_64+0x55/0x1c0
<4>[ 246.794519] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794519]
-> #0 (&dev->struct_mutex/1){+.+.}:
<4>[ 246.794519] __lock_acquire+0x15d8/0x1e90
<4>[ 246.794519] lock_acquire+0xa6/0x1c0
<4>[ 246.794519] __mutex_lock+0x9d/0x9b0
<4>[ 246.794519] userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[ 246.794519] __mmu_notifier_invalidate_range_start+0x85/0x110
<4>[ 246.794519] try_to_unmap_one+0x76b/0x860
<4>[ 246.794519] rmap_walk_anon+0x104/0x280
<4>[ 246.794519] try_to_unmap+0xc0/0xf0
<4>[ 246.794519] shrink_page_list+0x561/0xc10
<4>[ 246.794519] shrink_inactive_list+0x220/0x440
<4>[ 246.794519] shrink_node_memcg+0x36e/0x740
<4>[ 246.794519] shrink_node+0xcb/0x490
<4>[ 246.794519] balance_pgdat+0x241/0x580
<4>[ 246.794519] kswapd+0x16c/0x530
<4>[ 246.794519] kthread+0x119/0x130
<4>[ 246.794519] ret_from_fork+0x24/0x50
<4>[ 246.794519]
other info that might help us debug this:
<4>[ 246.794519] Chain exists of:
&dev->struct_mutex/1 --> &mapping->i_mmap_rwsem --> &anon_vma->rwsem
<4>[ 246.794519] Possible unsafe locking scenario:
<4>[ 246.794519] CPU0 CPU1
<4>[ 246.794519] ---- ----
<4>[ 246.794519] lock(&anon_vma->rwsem);
<4>[ 246.794519] lock(&mapping->i_mmap_rwsem);
<4>[ 246.794519] lock(&anon_vma->rwsem);
<4>[ 246.794519] lock(&dev->struct_mutex/1);
<4>[ 246.794519]
*** DEADLOCK ***
v2: Say no to mmap_ioctl
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111744
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111870
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190928082546.3473-1-chris@chris-wilson.co.uk
(cherry picked from commit a4311745bba9763e3c965643d4531bd5765b0513)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
The first come first served apporoach to handling the VBT
child device AUX ch conflicts has backfired. We have machines
in the wild where the VBT specifies both port A eDP and
port E DP (in that order) with port E being the real one.
So let's try to flip the preference around and let the last
child device win once again.
Cc: stable@vger.kernel.org
Cc: Jani Nikula <jani.nikula@intel.com>
Tested-by: Masami Ichikawa <masami256@gmail.com>
Tested-by: Torsten <freedesktop201910@liggy.de>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Fixes: 36a0f92020dc ("drm/i915/bios: make child device order the priority order")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191011202030.8829-1-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 41e35ffb380bde1379e4030bb5b2ac824d5139cf)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Pull setting -EIO on the hung requests into its own utility function.
Having allowed ourselves to short-circuit submission of completed
requests, we can now do the mark_eio() prior to submission and avoid
some redundant operations.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190923110056.15176-4-chris@chris-wilson.co.uk
(cherry picked from commit 0d7cf7bc15e75bf79f2f65d61d19f896609f816a)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
This reverts commit b0818f80c8c1bc215bba276bd61c216014fab23b.
Started seeing weird behavior after this patch especially in
the IPv6 code path. Haven't root caused it, but since this was
applied to net branch, taking a precautionary measure to revert
it and look / analyze those failures
Revert this now and I'll send a better fix after analysing / fixing
the weirdness observed.
CC: Eric Dumazet <edumazet@google.com>
CC: Wei Wang <weiwan@google.com>
CC: David S. Miller <davem@davemloft.net>
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Sign-extending TTBR1 addresses when converting to an untagged address
breaks the documented POSIX semantics for mlock() in some obscure error
cases where we end up returning -EINVAL instead of -ENOMEM as a direct
result of rewriting the upper address bits.
Rework the untagged_addr() macro to preserve the upper address bits for
TTBR1 addresses and only clear the tag bits for user addresses. This
matches the behaviour of the 'clear_address_tag' assembly macro, so
rename that and align the implementations at the same time so that they
use the same instruction sequences for the tag manipulation.
Link: https://lore.kernel.org/stable/20191014162651.GF19200@arrakis.emea.arm.com/
Reported-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Tested-by: Vincenzo Frascino <vincenzo.frascino@arm.com>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
When detecting a spurious EL1 translation fault, we have the CPU retry
the translation using an AT S1E1R instruction, and inspect PAR_EL1 to
determine if the fault was spurious.
When PAR_EL1.F == 0, the AT instruction successfully translated the
address without a fault, which implies the original fault was spurious.
However, in this case we return false and treat the original fault as if
it was not spurious.
Invert the return value so that we treat such a case as spurious.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Fixes: 42f91093b043 ("arm64: mm: Ignore spurious translation faults taken from the kernel")
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
The 'F' field of the PAR_EL1 register lives in bit 0, not bit 1.
Fix the broken definition in 'sysreg.h'.
Fixes: e8620cff9994 ("arm64: sysreg: Add some field definitions for PAR_EL1")
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
Preempting from IRQ-return means that the task has its PSTATE saved
on the stack, which will get restored when the task is resumed and does
the actual IRQ return.
However, enabling some CPU features requires modifying the PSTATE. This
means that, if a task was scheduled out during an IRQ-return before all
CPU features are enabled, the task might restore a PSTATE that does not
include the feature enablement changes once scheduled back in.
* Task 1:
PAN == 0 ---| |---------------
| |<- return from IRQ, PSTATE.PAN = 0
| <- IRQ |
+--------+ <- preempt() +--
^
|
reschedule Task 1, PSTATE.PAN == 1
* Init:
--------------------+------------------------
^
|
enable_cpu_features
set PSTATE.PAN on all CPUs
Worse than this, since PSTATE is untouched when task switching is done,
a task missing the new bits in PSTATE might affect another task, if both
do direct calls to schedule() (outside of IRQ/exception contexts).
Fix this by preventing preemption on IRQ-return until features are
enabled on all CPUs.
This way the only PSTATE values that are saved on the stack are from
synchronous exceptions. These are expected to be fatal this early, the
exception is BRK for WARN_ON(), but as this uses do_debug_exception()
which keeps IRQs masked, it shouldn't call schedule().
Signed-off-by: Julien Thierry <julien.thierry@arm.com>
[james: Replaced a really cool hack, with an even simpler static key in C.
expanded commit message with Julien's cover-letter ascii art]
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/song/md into for-linus
Pull MD fix from Song.
* 'md-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/song/md:
md/raid0: fix warning message for parameter default_layout
|
|
The message should match the parameter, i.e. raid0.default_layout.
Fixes: c84a1372df92 ("md/raid0: avoid RAID0 data corruption due to layout confusion.")
Cc: NeilBrown <neilb@suse.de>
Reported-by: Ivan Topolsky <doktor.yak@gmail.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
|
|
The __kthread_queue_delayed_work is not exported so
make it static, to avoid the following sparse warning:
kernel/kthread.c:869:6: warning: symbol '__kthread_queue_delayed_work' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
On a machine with a 64K PAGE_SIZE, the nested for loops in
test_check_nonzero_user() can lead to soft lockups, eg:
watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [modprobe:611]
Modules linked in: test_user_copy(+) vmx_crypto gf128mul crc32c_vpmsum virtio_balloon ip_tables x_tables autofs4
CPU: 4 PID: 611 Comm: modprobe Tainted: G L 5.4.0-rc1-gcc-8.2.0-00001-gf5a1a536fa14-dirty #1151
...
NIP __might_sleep+0x20/0xc0
LR __might_fault+0x40/0x60
Call Trace:
check_zeroed_user+0x12c/0x200
test_user_copy_init+0x67c/0x1210 [test_user_copy]
do_one_initcall+0x60/0x340
do_init_module+0x7c/0x2f0
load_module+0x2d94/0x30e0
__do_sys_finit_module+0xc8/0x150
system_call+0x5c/0x68
Even with a 4K PAGE_SIZE the test takes multiple seconds. Instead
tweak it to only scan a 1024 byte region, but make it cross the
page boundary.
Fixes: f5a1a536fa14 ("lib: introduce copy_struct_from_user() helper")
Suggested-by: Aleksa Sarai <cyphar@cyphar.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Aleksa Sarai <cyphar@cyphar.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Link: https://lore.kernel.org/r/20191016122732.13467-1-mpe@ellerman.id.au
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
|
