Age | Commit message (Collapse) | Author | Files | Lines |
|
The afs filesystem driver allows unstarted operations to be cancelled by
signal, but most of these can easily be restarted (mkdir for example). The
primary culprits for reproducing this are those applications that use
SIGALRM to display a progress counter.
File lock-extension operation is marked uninterruptible as we have a
limited time in which to do it, and the release op is marked
uninterruptible also as if we fail to unlock a file, we'll have to wait 20
mins before anyone can lock it again.
The store operation logs a warning if it gets interruption, e.g.:
kAFS: Unexpected error from FS.StoreData -4
because it's run from the background - but it can also be run from
fdatasync()-type things. However, store options aren't marked
interruptible at the moment.
Fix this in the following ways:
(1) Mark store operations as uninterruptible. It might make sense to
relax this for certain situations, but I'm not sure how to make sure
that background store ops aren't affected by signals to foreground
processes that happen to trigger them.
(2) In afs_get_io_locks(), where we're getting the serialisation lock for
talking to the fileserver, return ERESTARTSYS rather than EINTR
because a lot of the operations (e.g. mkdir) are restartable if we
haven't yet started sending the op to the server.
Fixes: e49c7b2f6de7 ("afs: Build an abstraction around an "operation" concept")
Signed-off-by: David Howells <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Without upperdir mount option, there is no index dir and the dependency
checks nfs_export => index for mount options parsing are incorrect.
Allow the combination nfs_export=on,index=off with no upperdir and move
the check for dependency redirect_dir=nofollow for non-upper mount case
to mount options parsing.
Signed-off-by: Amir Goldstein <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
With index feature enabled, on failure to create index dir, overlay is
being mounted read-only. However, we do not forbid user to remount overlay
read-write. Fix that by setting ofs->workdir to NULL, which prevents
remount read-write.
Signed-off-by: Amir Goldstein <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
Commit 9df085f3c9a2 ("ovl: relax requirement for non null uuid of lower
fs") relaxed the requirement for non null uuid with single lower layer to
allow enabling index and nfs_export features with single lower squashfs.
Fabian reported a regression in a setup when overlay re-uses an existing
upper layer and re-formats the lower squashfs image. Because squashfs
has no uuid, the origin xattr in upper layer are decoded from the new
lower layer where they may resolve to a wrong origin file and user may
get an ESTALE or EIO error on lookup.
To avoid the reported regression while still allowing the new features
with single lower squashfs, do not allow decoding origin with lower null
uuid unless user opted-in to one of the new features that require
following the lower inode of non-dir upper (index, xino, metacopy).
Reported-by: Fabian <[email protected]>
Link: https://lore.kernel.org/linux-unionfs/32532923.JtPX5UtSzP@fgdesktop/
Fixes: 9df085f3c9a2 ("ovl: relax requirement for non null uuid of lower fs")
Cc: [email protected] # v4.20+
Signed-off-by: Amir Goldstein <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
Mounting with nfs_export=on, xfstests overlay/031 triggers a kernel panic
since v5.8-rc1 overlayfs updates.
overlayfs: orphan index entry (index/00fb1..., ftype=4000, nlink=2)
BUG: kernel NULL pointer dereference, address: 0000000000000030
RIP: 0010:ovl_cleanup_and_whiteout+0x28/0x220 [overlay]
Bisect point at commit c21c839b8448 ("ovl: whiteout inode sharing")
Minimal reproducer:
--------------------------------------------------
rm -rf l u w m
mkdir -p l u w m
mkdir -p l/testdir
touch l/testdir/testfile
mount -t overlay -o lowerdir=l,upperdir=u,workdir=w,nfs_export=on overlay m
echo 1 > m/testdir/testfile
umount m
rm -rf u/testdir
mount -t overlay -o lowerdir=l,upperdir=u,workdir=w,nfs_export=on overlay m
umount m
--------------------------------------------------
When mount with nfs_export=on, and fail to verify an orphan index, we're
cleaning this index from indexdir by calling ovl_cleanup_and_whiteout().
This dereferences ofs->workdir, that was earlier set to NULL.
The design was that ovl->workdir will point at ovl->indexdir, but we are
assigning ofs->indexdir to ofs->workdir only after ovl_indexdir_cleanup().
There is no reason not to do it sooner, because once we get success from
ofs->indexdir = ovl_workdir_create(... there is no turning back.
Reported-and-tested-by: Murphy Zhou <[email protected]>
Fixes: c21c839b8448 ("ovl: whiteout inode sharing")
Signed-off-by: Amir Goldstein <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
Decoding a lower directory file handle to overlay path with cold
inode/dentry cache may go as follows:
1. Decode real lower file handle to lower dir path
2. Check if lower dir is indexed (was copied up)
3. If indexed, get the upper dir path from index
4. Lookup upper dir path in overlay
5. If overlay path found, verify that overlay lower is the lower dir
from step 1
On failure to verify step 5 above, user will get an ESTALE error and a
WARN_ON will be printed.
A mismatch in step 5 could be a result of lower directory that was renamed
while overlay was offline, after that lower directory has been copied up
and indexed.
This is a scripted reproducer based on xfstest overlay/052:
# Create lower subdir
create_dirs
create_test_files $lower/lowertestdir/subdir
mount_dirs
# Copy up lower dir and encode lower subdir file handle
touch $SCRATCH_MNT/lowertestdir
test_file_handles $SCRATCH_MNT/lowertestdir/subdir -p -o $tmp.fhandle
# Rename lower dir offline
unmount_dirs
mv $lower/lowertestdir $lower/lowertestdir.new/
mount_dirs
# Attempt to decode lower subdir file handle
test_file_handles $SCRATCH_MNT -p -i $tmp.fhandle
Since this WARN_ON() can be triggered by user we need to relax it.
Fixes: 4b91c30a5a19 ("ovl: lookup connected ancestor of dir in inode cache")
Cc: <[email protected]> # v4.16+
Signed-off-by: Amir Goldstein <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
ovl_check_origin outparam 'ctrp' argument not used by caller. So remove
this argument.
Signed-off-by: youngjun <[email protected]>
Reviewed-by: Amir Goldstein <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
"ovl_copy_up_flags" is used in copy_up.c.
so, change it static.
Signed-off-by: youngjun <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
When "ovl_is_inuse" true case, trap inode reference not put. plus adding
the comment explaining sequence of ovl_is_inuse after ovl_setup_trap.
Fixes: 0be0bfd2de9d ("ovl: fix regression caused by overlapping layers detection")
Cc: <[email protected]> # v4.19+
Reviewed-by: Amir Goldstein <[email protected]>
Signed-off-by: youngjun <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
As the ENABLE_IRQ_POLL macro is undefined, the check for ENABLE_IRQ_POLL
macro in ISR will always be false. This leads to irq polling being
non-functional.
Remove ENABLE_IRQ_POLL check from ISR.
Link: https://lore.kernel.org/r/[email protected]
Fixes: a6ffd5bf6819 ("scsi: megaraid_sas: Call disable_irq from process IRQ")
Cc: <[email protected]> # v5.3+
Signed-off-by: Chandrakanth Patil <[email protected]>
Signed-off-by: Kashyap Desai <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
io_recvmsg() doesn't free memory allocated for struct io_buffer. This can
causes a leak when used with automatic buffer selection.
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
Fix dtschema validator warnings like:
intc@fffc1000: $nodename:0:
'intc@fffc1000' does not match '^interrupt-controller(@[0-9a-f,]+)*$'
Fixes: 78cd6a9d8e15 ("arm64: dts: Add base stratix 10 dtsi")
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Dinh Nguyen <[email protected]>
|
|
Fix dtschema validator warnings like:
l2-cache@fffff000: $nodename:0:
'l2-cache@fffff000' does not match '^(cache-controller|cpu)(@[0-9a-f,]+)*$'
Fixes: 475dc86d08de ("arm: dts: socfpga: Add a base DTSI for Altera's Arria10 SOC")
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Dinh Nguyen <[email protected]>
|
|
Match the QSPI reg address in the socfpga_stratix10_socdk.dts file.
Fixes: 80f132d73709 ("arm64: dts: increase the QSPI reg address for Stratix10 and Agilex")
Cc: linux-stable <[email protected]> # >= v5.6
Signed-off-by: Dinh Nguyen <[email protected]>
|
|
Add status = "okay" to QSPI node.
Fixes: 0cb140d07fc75 ("arm64: dts: stratix10: Add QSPI support for Stratix10")
Cc: linux-stable <[email protected]> # >= v5.6
Signed-off-by: Dinh Nguyen <[email protected]>
|
|
Add status = "okay" to QSPI node.
Fixes: c4c8757b2d895 ("arm64: dts: agilex: add QSPI support for Intel Agilex")
Cc: linux-stable <[email protected]> # >= v5.5
Signed-off-by: Dinh Nguyen <[email protected]>
|
|
Currently the header size calculations are using an assignment
operator instead of a += operator when accumulating the header
size leading to incorrect sizes. Fix this by using the correct
operator.
Addresses-Coverity: ("Unused value")
Fixes: 302d3deb2068 ("xprtrdma: Prevent inline overflow")
Signed-off-by: Colin Ian King <[email protected]>
Reviewed-by: Chuck Lever <[email protected]>
Signed-off-by: Anna Schumaker <[email protected]>
|
|
SMATCH detected a potential buffer overflow in the manipulation of
hwmon_attributes array inside the scmi_hwmon_probe function:
drivers/hwmon/scmi-hwmon.c:226
scmi_hwmon_probe() error: buffer overflow 'hwmon_attributes' 6 <= 9
Fix it by statically declaring the size of the array as the maximum
possible as defined by hwmon_max define.
Signed-off-by: Cristian Marussi <[email protected]>
Reviewed-by: Sudeep Holla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Guenter Roeck <[email protected]>
|
|
ERR_NX_TRANSLATION(CSB.CC=5) is for internal to VAS for fault handling
and should not used by OS. ERR_NX_AT_FAULT(CSB.CC=250) is the proper
error code should be reported by OS when NX encounters address
translation failure.
This patch uses CC=250 to determine the fault address when the request
is not successful.
Signed-off-by: Haren Myneni <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
P9 DD2 NX workbook (Table 4-36) says DMA controller uses CC=5
internally for translation fault handling. NX reserves CC=250 for
OS to notify user space when NX encounters address translation
failure on the request buffer. Not an issue in earlier releases
as NX does not get faults on kernel addresses.
This patch defines CSB_CC_FAULT_ADDRESS(250) and updates CSB.CC with
this proper error code for user space.
Fixes: c96c4436aba4 ("powerpc/vas: Update CSB and notify process for fault CRBs")
Signed-off-by: Haren Myneni <[email protected]>
[mpe: Added Fixes tag and fix typo in comment]
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The ioctl encoding for this parameter is a long but the documentation says
it should be an int and the kernel drivers expect it to be an int. If the
fuse driver treats this as a long it might end up scribbling over the stack
of a userspace process that only allocated enough space for an int.
This was previously discussed in [1] and a patch for fuse was proposed in
[2]. From what I can tell the patch in [2] was nacked in favor of adding
new, "fixed" ioctls and using those from userspace. However there is still
no "fixed" version of these ioctls and the fact is that it's sometimes
infeasible to change all userspace to use the new one.
Handling the ioctls specially in the fuse driver seems like the most
pragmatic way for fuse servers to support them without causing crashes in
userspace applications that call them.
[1]: https://lore.kernel.org/linux-fsdevel/[email protected]/T/
[2]: https://sourceforge.net/p/fuse/mailman/message/31771759/
Signed-off-by: Chirantan Ekbote <[email protected]>
Fixes: 59efec7b9039 ("fuse: implement ioctl support")
Cc: <[email protected]>
Signed-off-by: Miklos Szeredi <[email protected]>
|
|
The battery on my laptop ASUS TUF Gaming FX706II is named BAT1.
This patch allows battery extension to load.
Signed-off-by: Vasiliy Kupriakov <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
Added new PCI device ids for supporting mailbox and MMIO interface for
Sapphire Rapids.
Signed-off-by: Srinivas Pandruvada <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
dispatch_proc_write()"
This reverts commit 35d13c7a05126a5a54a1ef40aff4c6984474e604.
This broke procfs interface due to neglecting the fact that
the strings are not coming NULL terminated.
Revert the change till we will have a better clean up.
Fixes: 35d13c7a0512 ("platform/x86: thinkpad_acpi: Use strndup_user() in dispatch_proc_write()")
Reported-by: Hans de Goede <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
|
|
This reverts commit eb9aecd90d1a39601e91cd08b90d5fee51d321a6
The above patch is supposed to fix a register index error on mt2701. It
is not clear if the problem solved is a hang or just an invalid value
returned, my guess is the second. The patch introduces, though, a new
hang on MT8173 device making them unusable. So, seems reasonable, revert
the patch because introduces a worst issue.
The reason I send a revert instead of trying to fix the issue for MT8173
is because the information needed to fix the issue is in the datasheet
and is not public. So I am not really able to fix it.
Fixes the following bug when CONFIG_MTK_THERMAL is set on MT8173
devices.
[ 2.222488] Unable to handle kernel paging request at virtual address ffff8000125f5001
[ 2.230421] Mem abort info:
[ 2.233207] ESR = 0x96000021
[ 2.236261] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2.241571] SET = 0, FnV = 0
[ 2.244623] EA = 0, S1PTW = 0
[ 2.247762] Data abort info:
[ 2.250640] ISV = 0, ISS = 0x00000021
[ 2.254473] CM = 0, WnR = 0
[ 2.257544] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000041850000
[ 2.264251] [ffff8000125f5001] pgd=000000013ffff003, pud=000000013fffe003, pmd=000000013fff9003, pte=006800001100b707
[ 2.274867] Internal error: Oops: 96000021 [#1] PREEMPT SMP
[ 2.280432] Modules linked in:
[ 2.283483] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc6+ #162
[ 2.289914] Hardware name: Google Elm (DT)
[ 2.294003] pstate: 20000005 (nzCv daif -PAN -UAO)
[ 2.298792] pc : mtk_read_temp+0xb8/0x1c8
[ 2.302793] lr : mtk_read_temp+0x7c/0x1c8
[ 2.306794] sp : ffff80001003b930
[ 2.310100] x29: ffff80001003b930 x28: 0000000000000000
[ 2.315404] x27: 0000000000000002 x26: ffff0000f9550b10
[ 2.320709] x25: ffff0000f9550a80 x24: 0000000000000090
[ 2.326014] x23: ffff80001003ba24 x22: 00000000610344c0
[ 2.331318] x21: 0000000000002710 x20: 00000000000001f4
[ 2.336622] x19: 0000000000030d40 x18: ffff800011742ec0
[ 2.341926] x17: 0000000000000001 x16: 0000000000000001
[ 2.347230] x15: ffffffffffffffff x14: ffffff0000000000
[ 2.352535] x13: ffffffffffffffff x12: 0000000000000028
[ 2.357839] x11: 0000000000000003 x10: ffff800011295ec8
[ 2.363143] x9 : 000000000000291b x8 : 0000000000000002
[ 2.368447] x7 : 00000000000000a8 x6 : 0000000000000004
[ 2.373751] x5 : 0000000000000000 x4 : ffff800011295cb0
[ 2.379055] x3 : 0000000000000002 x2 : ffff8000125f5001
[ 2.384359] x1 : 0000000000000001 x0 : ffff0000f9550a80
[ 2.389665] Call trace:
[ 2.392105] mtk_read_temp+0xb8/0x1c8
[ 2.395760] of_thermal_get_temp+0x2c/0x40
[ 2.399849] thermal_zone_get_temp+0x78/0x160
[ 2.404198] thermal_zone_device_update.part.0+0x3c/0x1f8
[ 2.409589] thermal_zone_device_update+0x34/0x48
[ 2.414286] of_thermal_set_mode+0x58/0x88
[ 2.418375] thermal_zone_of_sensor_register+0x1a8/0x1d8
[ 2.423679] devm_thermal_zone_of_sensor_register+0x64/0xb0
[ 2.429242] mtk_thermal_probe+0x690/0x7d0
[ 2.433333] platform_drv_probe+0x5c/0xb0
[ 2.437335] really_probe+0xe4/0x448
[ 2.440901] driver_probe_device+0xe8/0x140
[ 2.445077] device_driver_attach+0x7c/0x88
[ 2.449252] __driver_attach+0xac/0x178
[ 2.453082] bus_for_each_dev+0x78/0xc8
[ 2.456909] driver_attach+0x2c/0x38
[ 2.460476] bus_add_driver+0x14c/0x230
[ 2.464304] driver_register+0x6c/0x128
[ 2.468131] __platform_driver_register+0x50/0x60
[ 2.472831] mtk_thermal_driver_init+0x24/0x30
[ 2.477268] do_one_initcall+0x50/0x298
[ 2.481098] kernel_init_freeable+0x1ec/0x264
[ 2.485450] kernel_init+0x1c/0x110
[ 2.488931] ret_from_fork+0x10/0x1c
[ 2.492502] Code: f9401081 f9400402 b8a67821 8b010042 (b9400042)
[ 2.498599] ---[ end trace e43e3105ed27dc99 ]---
[ 2.503367] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 2.511020] SMP: stopping secondary CPUs
[ 2.514941] Kernel Offset: disabled
[ 2.518421] CPU features: 0x090002,25006005
[ 2.522595] Memory Limit: none
[ 2.525644] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]--
Cc: Michael Kao <[email protected]>
Fixes: eb9aecd90d1a ("thermal: mediatek: fix register index error")
Signed-off-by: Enric Balletbo i Serra <[email protected]>
Reviewed-by: Matthias Brugger <[email protected]>
Signed-off-by: Daniel Lezcano <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Downgrade "Unsupported event" message from dev_err to dev_dbg to avoid
flooding with this message on some platforms.
Cc: [email protected] # v5.4+
Suggested-by: Zhang Rui <[email protected]>
Signed-off-by: Alex Hung <[email protected]>
[ rzhang: fix typo in changelog ]
Signed-off-by: Zhang Rui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Stefan Dietrich reports invalid temperature source messages on Asus Formula
XII Z490.
nct6775 nct6775.656: Invalid temperature source 28 at index 0,
source register 0x100, temp register 0x73
Debugging suggests that temperature source 28 reports the CPU temperature.
Let's assume that temperature sources 28 and 29 reflect "PECI Agent {0,1}
Calibration", similar to other chips of the series.
Reported-by: Stefan Dietrich <[email protected]>
Cc: Stefan Dietrich <[email protected]>
Signed-off-by: Guenter Roeck <[email protected]>
|
|
With the current 8KB stack size there are frequent overflows in a 64-bit
configuration. We may split IRQ stacks off in the future, but this fixes a
number of issues right now.
Signed-off-by: Andreas Schwab <[email protected]>
Reviewed-by: Anup Patel <[email protected]>
[Palmer: mention irqstack in the commit text]
Fixes: 7db91e57a0ac ("RISC-V: Task implementation")
Cc: [email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>
|
|
"u64 *wptr" points to the the wptr value in write back buffer and
"*wptr = (*wptr) >> 2;" results in the value being overwritten each time
when ->get_wptr() is called.
umr uses /sys/kernel/debug/dri/0/amdgpu_ring_sdma0 to get rptr/wptr and
decode ring content and it is affected by this issue.
fix and simplify the logic similar as sdma_v4_0_ring_get_wptr().
v2: fix for sdma5.2 as well
v3: drop sdma 5.2 changes for 5.8 and stable
Suggested-by: Le Ma <[email protected]>
Signed-off-by: Xiaojie Yuan <[email protected]>
Reviewed-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
I consulted Cai Land([email protected]), he told me corresponding smc
message name to fSMC_MSG_SetWorkloadMask() is
"PPSMC_MSG_ActiveProcessNotify" in firmware code of Renoir.
Strange though it may seem, but it's a fact.
Signed-off-by: chen gong <[email protected]>
Reviewed-by: Evan Quan <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected]
|
|
[Why]
Failing to allocate a transfer function during stream construction leads
to a null pointer dereference
[How]
Handle the failed allocation by failing the stream construction
Cc: [email protected]
Signed-off-by: Josip Pavic <[email protected]>
Reviewed-by: Aric Cyr <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
connected
[Why]
amdgpu_dm->backlight_caps is for single eDP only. the caps are upddated
for very connector. Real eDP caps will be overwritten by other external
display. For OLED panel, caps->aux_support is set to 1 for OLED pnael.
after external connected, caps+.aux_support is set to 0. This causes
OLED backlight adjustment not work.
[How]
within update_conector_ext_caps, backlight caps will be updated only for
eDP connector.
Cc: [email protected]
Signed-off-by: hersen wu <[email protected]>
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Acked-by: Rodrigo Siqueira <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Prevents a warning in the MST create connector case.
v2: create global fake encoders rather per connector fake encoders
to avoid running out of encoder indices.
v3: use the actual number of crtcs on the asic rather than the max
to conserve encoders.
v4: v3 plus missing hunk I forgot to git add.
Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1108
Fixes: c6385e503aeaf9 ("drm/amdgpu: drop legacy drm load and unload callbacks")
Reviewed-by: Nicholas Kazlauskas <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
Cc: [email protected] # 5.7.x
|
|
Remove signaled jobs from job list and ensure the
job was indeed preempted.
Signed-off-by: Jack Xiao <[email protected]>
Reviewed-by: Hawking Zhang <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
During preemption test for gfx10, it uses kiq to trigger
gfx preemption, which would result in race condition
with flushing TLB for kiq.
Signed-off-by: Jack Xiao <[email protected]>
Reviewed-by: Hawking Zhang <[email protected]>
Acked-by: Christian König <[email protected]>
Signed-off-by: Alex Deucher <[email protected]>
|
|
Currently we're failing to recalculate the gen9 FBC w/a stride
unless something more drastic than just the modifier itself has
changed. This often leaves us with FBC enabled with the linear
fbdev framebuffer without the w/a stride enabled. That will cause
an immediate underrun and FBC will get promptly disabled.
Fix the problem by checking if the w/a stride is about to change,
and go through the full dance if so. This part of the FBC code
is still pretty much a disaster and will need lots more work.
But this should at least fix the immediate issue.
v2: Deactivate FBC when the modifier changes since that will
likely require resetting the w/a CFB stride
Cc: [email protected]
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: José Roberto de Souza <[email protected]>
(cherry picked from commit 0428ab013fdd39dbfb8f4cd8ad2b60af3776c6b9)
Signed-off-by: Jani Nikula <[email protected]>
|
|
This fixes the following KASAN splash on module reload:
[ 145.136327] ==================================================================
[ 145.136502] BUG: KASAN: use-after-free in intel_hdmi_destroy+0x74/0x80 [i915]
[ 145.136514] Read of size 8 at addr ffff888216641830 by task kworker/1:1/134
[ 145.136535] CPU: 1 PID: 134 Comm: kworker/1:1 Tainted: G U T 5.5.0-rc7-valkyria+ #5783
[ 145.136539] Hardware name: GIGABYTE GB-BKi3A-7100/MFLP3AP-00, BIOS F1 07/27/2016
[ 145.136546] Workqueue: events drm_connector_free_work_fn
[ 145.136551] Call Trace:
[ 145.136560] dump_stack+0xa1/0xe0
[ 145.136571] print_address_description.constprop.0+0x1e/0x210
[ 145.136639] ? intel_hdmi_destroy+0x74/0x80 [i915]
[ 145.136703] ? intel_hdmi_destroy+0x74/0x80 [i915]
[ 145.136710] __kasan_report.cold+0x1b/0x37
[ 145.136790] ? intel_hdmi_destroy+0x74/0x80 [i915]
[ 145.136863] ? intel_hdmi_destroy+0x74/0x80 [i915]
[ 145.136870] kasan_report+0x27/0x30
[ 145.136881] __asan_report_load8_noabort+0x1c/0x20
[ 145.136946] intel_hdmi_destroy+0x74/0x80 [i915]
[ 145.136954] drm_connector_free_work_fn+0xd1/0x100
[ 145.136967] process_one_work+0x86e/0x1610
[ 145.136987] ? pwq_dec_nr_in_flight+0x2f0/0x2f0
[ 145.137004] ? move_linked_works+0x128/0x2c0
[ 145.137021] worker_thread+0x63e/0xc90
[ 145.137048] kthread+0x2f6/0x3f0
[ 145.137054] ? calculate_sigpending+0x81/0xa0
[ 145.137059] ? process_one_work+0x1610/0x1610
[ 145.137064] ? kthread_bind+0x40/0x40
[ 145.137075] ret_from_fork+0x24/0x30
[ 145.137111] Allocated by task 0:
[ 145.137119] (stack is not available)
[ 145.137137] Freed by task 5053:
[ 145.137147] save_stack+0x28/0x90
[ 145.137152] __kasan_slab_free+0x136/0x180
[ 145.137157] kasan_slab_free+0x26/0x30
[ 145.137161] kfree+0xe6/0x350
[ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915]
[ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0
[ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915]
[ 145.137403] i915_driver_remove+0xc4/0x130 [i915]
[ 145.137482] i915_pci_remove+0x3e/0x90 [i915]
[ 145.137489] pci_device_remove+0x108/0x2d0
[ 145.137494] device_release_driver_internal+0x1e6/0x4a0
[ 145.137499] driver_detach+0xcb/0x198
[ 145.137503] bus_remove_driver+0xde/0x204
[ 145.137508] driver_unregister+0x6d/0xa0
[ 145.137513] pci_unregister_driver+0x2e/0x230
[ 145.137576] i915_exit+0x1f/0x26 [i915]
[ 145.137157] kasan_slab_free+0x26/0x30
[ 145.137161] kfree+0xe6/0x350
[ 145.137242] intel_ddi_encoder_destroy+0x60/0x80 [i915]
[ 145.137252] drm_mode_config_cleanup+0x11d/0x8f0
[ 145.137329] intel_modeset_driver_remove+0x1f5/0x350 [i915]
[ 145.137403] i915_driver_remove+0xc4/0x130 [i915]
[ 145.137482] i915_pci_remove+0x3e/0x90 [i915]
[ 145.137489] pci_device_remove+0x108/0x2d0
[ 145.137494] device_release_driver_internal+0x1e6/0x4a0
[ 145.137499] driver_detach+0xcb/0x198
[ 145.137503] bus_remove_driver+0xde/0x204
[ 145.137508] driver_unregister+0x6d/0xa0
[ 145.137513] pci_unregister_driver+0x2e/0x230
[ 145.137576] i915_exit+0x1f/0x26 [i915]
[ 145.137581] __x64_sys_delete_module+0x35b/0x470
[ 145.137586] do_syscall_64+0x99/0x4e0
[ 145.137591] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 145.137606] The buggy address belongs to the object at ffff888216640000
which belongs to the cache kmalloc-8k of size 8192
[ 145.137618] The buggy address is located 6192 bytes inside of
8192-byte region [ffff888216640000, ffff888216642000)
[ 145.137630] The buggy address belongs to the page:
[ 145.137640] page:ffffea0008599000 refcount:1 mapcount:0 mapping:ffff888107c02a80 index:0xffff888216644000 compound_mapcount: 0
[ 145.137647] raw: 0200000000010200 0000000000000000 0000000100000001 ffff888107c02a80
[ 145.137652] raw: ffff888216644000 0000000080020001 00000001ffffffff 0000000000000000
[ 145.137656] page dumped because: kasan: bad access detected
[ 145.137668] Memory state around the buggy address:
[ 145.137678] ffff888216641700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 145.137687] ffff888216641780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 145.137697] >ffff888216641800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 145.137706] ^
[ 145.137715] ffff888216641880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 145.137724] ffff888216641900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 145.137733] ==================================================================
[ 145.137742] Disabling lock debugging due to kernel taint
Changes since v1:
- Add fixes tags.
- Use early unregister.
Signed-off-by: Maarten Lankhorst <[email protected]>
Fixes: 9c229127aee2 ("drm/i915: hdmi: add CEC notifier to intel_hdmi")
Cc: <[email protected]> # v4.19+
Reviewed-by: Daniel Vetter <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit a581483b1e5466d28fc50ff623fba31cea2cccb6)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The danger in switching at random upon intel_context_pin is that the
context may still actually be inflight, as it will not be scheduled out
until a context switch after it is complete -- that may be a long time
after we do a final intel_context_unpin.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2118
Fixes: 6d06779e8672 ("drm/i915: Load balancing across a virtual engine")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: <[email protected]> # v5.3+
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 90a987205c6cf74116a102ed446d22d92cdaf915)
Signed-off-by: Jani Nikula <[email protected]>
|
|
We do not use the virtual engines for interrupts (they have physical
components), but we do use them to decouple the fence signaling during
submission. Currently, when we submit a completed request, we try to
enable the interrupt handler for the virtual engine, but we never disarm
it. A quick fix is then to mark the irq as enabled, and it will then
remain enabled -- and this prevents us from waking the device and never
letting it sleep again.
Fixes: f8db4d051b5e ("drm/i915: Initialise breadcrumb lists on the virtual engine")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: <[email protected]> # v5.5+
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 4fe6abb8f51355224808ab02a9febf65d184c40b)
Signed-off-by: Jani Nikula <[email protected]>
|
|
MI_STORE_REGISTER_MEM and MI_LOAD_REGISTER_MEM need to know which
translation to use when saving restoring the engine general purpose
registers to and from the GT scratch. Since GT scratch is mapped to
ggtt, we need to set an additional bit in the command to use GTT.
Fixes: daed3e44396d17 ("drm/i915/perf: implement active wait for noa configurations")
Suggested-by: Prathap Kumar Valsan <[email protected]>
Signed-off-by: Umesh Nerlige Ramappa <[email protected]>
Reviewed-by: Lionel Landwerlin <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Signed-off-by: Chris Wilson <[email protected]>
(cherry picked from commit e43ff99c8deda85234e6233e0f4af6cb09566a37)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Both cmp_u32 and cmp_u64 are comparing the pointers instead of the value
at those pointers. This will result in incorrect/unsorted list. Fix it
by deferencing the pointers before comparison.
Fixes: 4ba74e53ada3 ("drm/i915/selftests: Verify frequency scaling with RPS")
Fixes: 8757797ff9c9 ("drm/i915/selftests: Repeat the rps clock frequency measurement")
Cc: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 2196dfea896f7027b43bae848890ce4aec5c8724)
Signed-off-by: Jani Nikula <[email protected]>
|
|
Quite some non OF/ACPI users of irqdomains allocate firmware nodes of type
IRQCHIP_FWNODE_NAMED or IRQCHIP_FWNODE_NAMED_ID and free them right after
creating the irqdomain. The only purpose of these FW nodes is to convey
name information. When this was introduced the core code did not store the
pointer to the node in the irqdomain. A recent change stored the firmware
node pointer in irqdomain for other reasons and missed to notice that the
usage sites which do the alloc_fwnode/create_domain/free_fwnode sequence
are broken by this. Storing a dangling pointer is dangerous itself, but in
case that the domain is destroyed later on this leads to a double free.
Remove the freeing of the firmware node after creating the irqdomain from
all affected call sites to cure this.
Fixes: 711419e504eb ("irqdomain: Add the missing assignment of domain->fwnode for named fwnode")
Reported-by: Andy Shevchenko <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]>
Acked-by: Marc Zyngier <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
|
|
Got following d_can probe errors with kernel 5.8-rc1 on am437x
[ 10.730822] CAN device driver interface
Starting Wait for Network to be Configured...
[ OK ] Reached target Network.
[ 10.787363] c_can_platform 481cc000.can: probe failed
[ 10.792484] c_can_platform: probe of 481cc000.can failed with error -2
[ 10.799457] c_can_platform 481d0000.can: probe failed
[ 10.804617] c_can_platform: probe of 481d0000.can failed with error -2
actually, Tony has fixed this issue on am335x with the patch [3]
Since am437x has the same clock structure with am335x
[1][2], so reuse the code from Tony Lindgren's patch [3] to fix it.
[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on
am335x")
Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to read revision")
Signed-off-by: dillon min <[email protected]>
[[email protected]: aligned commit message a bit for readability]
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Fix memory leak in omap_hwmod_allocate_module not freeing in
handling error path.
Fixes: 8c87970543b17("ARM: OMAP2+: Add functions to allocate module data from device tree")
Signed-off-by: Chen Tao <[email protected]>
Reviewed-by: Paul Walmsley <[email protected]>
[[email protected]: fix call iounmap for missing regs]
Signed-off-by: Tony Lindgren <[email protected]>
|
|
Starting from commit "thermal/int340x_thermal: Don't require IDSP to
exist", priv->current_uuid_index is initialized to -1. This value may
be passed to int3400_thermal_run_osc() from int3400_thermal_set_mode,
contributing to page fault when accessing int3400_thermal_uuids array
at index -1.
This commit adds a check on uuid value to int3400_thermal_run_osc.
Fixes: 8d485da0ddee ("thermal/int340x_thermal: Don't require IDSP to exist")
Signed-off-by: Bartosz Szczepanek <[email protected]>
Reviewed-by: Pandruvada, Srinivas <[email protected]>
[ rzhang: Add Fixes tag ]
Signed-off-by: Zhang Rui <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
There is no guarantee to CMA's placement, so allocating a zone specific
atomic pool from CMA might return memory from a completely different
memory zone. So stop using it.
Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp mask")
Reported-by: Jeremy Linton <[email protected]>
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Tested-by: Jeremy Linton <[email protected]>
Acked-by: David Rientjes <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
When allocating DMA memory from a pool, the core can only guess which
atomic pool will fit a device's constraints. If it doesn't, get a safer
atomic pool and try again.
Fixes: c84dc6e68a1d ("dma-pool: add additional coherent pools to map to gfp mask")
Reported-by: Jeremy Linton <[email protected]>
Suggested-by: Robin Murphy <[email protected]>
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
dma-pool's dev_to_pool() creates the false impression that there is a
way to grantee a mapping between a device's DMA constraints and an
atomic pool. It tuns out it's just a guess, and the device might need to
use an atomic pool containing memory from a 'safer' (or lower) memory
zone.
To help mitigate this, introduce dma_guess_pool() which can be fed a
device's DMA constraints and atomic pools already known to be faulty, in
order for it to provide an better guess on which pool to use.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
The function is only used once and can be simplified to a one-liner.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|
|
dma_coherent_ok() checks if a physical memory area fits a device's DMA
constraints.
Signed-off-by: Nicolas Saenz Julienne <[email protected]>
Signed-off-by: Christoph Hellwig <[email protected]>
|