aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-30drm/amdgpu: fix the issue of reserving bad pages failedDennis Li4-119/+156
In amdgpu_ras_reset_gpu, because bad pages may not be freed, it has high probability to reserve bad pages failed. Change to reserve bad pages when freeing VRAM. v2: 1. avoid allocating the drm_mm node outside of amdgpu_vram_mgr.c 2. move bad page reserving into amdgpu_ras_add_bad_pages, if vram mgr reserve bad page failed, it will put it into pending list, otherwise put it into processed list; 3. remove amdgpu_ras_release_bad_pages, because retired page's info has been moved into amdgpu_vram_mgr v3: 1. formate code style; 2. rename amdgpu_vram_reserve_scope as amdgpu_vram_reservation; 3. rename scope_pending as reservations_pending; 4. rename scope_processed as reserved_pages; 5. change to iterate over all the pending ones and try to insert them with drm_mm_reserve_node(); v4: 1. rename amdgpu_vram_mgr_reserve_scope as amdgpu_vram_mgr_reserve_range; 2. remove unused include "amdgpu_ras.h"; 3. rename amdgpu_vram_mgr_check_and_reserve as amdgpu_vram_mgr_do_reserve; 4. refine amdgpu_vram_mgr_reserve_range to call amdgpu_vram_mgr_do_reserve. Reviewed-by: Christian König <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Dennis Li <[email protected]> Signed-off-by: Wenhui Sheng <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-30drm/amdgpu: remove redundant GPU resetDennis Li2-25/+1
Because bad pages saving has been moved to UMC error interrupt callback, which will trigger a new GPU reset after saving. Signed-off-by: Dennis Li <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-30drm/amdgpu: change to save bad pages in UMC error interrupt callbackDennis Li3-7/+6
Instead of saving bad pages in amdgpu_ras_reset_gpu, it will reduce the unnecessary calling of amdgpu_ras_save_bad_pages. Signed-off-by: Dennis Li <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-30drm/amdgpu: rename nv_is_headless_sku()Flora Cui1-3/+3
for headless NAVI ASICs Signed-off-by: Flora Cui <[email protected]> Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-30drm/amdgpu: disable DCN and VCN for Navi14 0x7340/C9 SKUFlora Cui1-2/+3
Navi14 0x7340/C9 SKU has no display and video support, remove them. Signed-off-by: Flora Cui <[email protected]> Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-30drm/amdgpu/display: fix indentation in defer_delay_converter_wa()Alex Deucher1-7/+7
Fixes this warning: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_ddc.c: In function ‘defer_delay_converter_wa’: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_ddc.c:285:2: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] 285 | if (link->dpcd_caps.branch_dev_id == DP_BRANCH_DEVICE_ID_0080E1 && | ^~ drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_ddc.c:291:3: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the ‘if’ 291 | if (link->dpcd_caps.branch_dev_id == DP_BRANCH_DEVICE_ID_006037 && | ^~ Reviewed-by: Evan Quan <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2020-10-30drm/i915/gvt: Fix mmio handler break on BXT/APL.Colin Xu1-1/+11
- Remove dup mmio handler for BXT/APL. Otherwise mmio handler will fail to init. - Add engine GPR with F_CMD_ACCESS since BXT/APL will load them via LRI. Otherwise, guest will enter failsafe mode. V2: Use RCS/BCS GPR macros instead of offset. Revise commit message. V3: Use GEN8_RING_CS_GPR macros on ring base. Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Colin Xu <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-30Merge tag 'drm-intel-fixes-2020-10-29' into gvt-fixesZhenyu Wang13652-269977/+558679
Backmerge for 5.10-rc1 to apply one extra APL fix. Signed-off-by: Zhenyu Wang <[email protected]>
2020-10-30drm/i915/gvt: Only pin/unpin intel_context along with workloadColin Xu1-7/+8
One issue exposed after below commit with which the system will freeze at suspend after vGPU is created (no need to activate the vGPU). commit e6ba76480299 ("drm/i915: Remove i915->kernel_context") Old implementation pin the intel_context at setup_submission and unpin it at clean_submission. So after some vGPU is created, the intel_context is always pinned there although no workload using it. It will then block i915 enter suspend state. There is no need to pin it all the time. Pin/unpin it around workload lifecycle is more reasonable. After GVT enabled suspend/resume, the pinned intel_context will also get unpined when userspace put VM process into suspend state since all workloads are retired, then it's safe to unpin all intel_context for workloads created. So move the pin/unpin to create_workload and destroy_workload, while still keep the create/destroy in old place. V2: Rebase. Fixes: e6ba76480299 ("drm/i915: Remove i915->kernel_context") Reviewed-by: Zhenyu Wang <[email protected]> Signed-off-by: Colin Xu <[email protected]> Signed-off-by: Zhenyu Wang <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-30usb: cdns3: gadget: own the lock wrongly at the suspend routinePeter Chen1-4/+7
When the system goes to suspend, if the controller is at device mode with cable connecting to host, the call stack is: cdns3_suspend-> cdns3_gadget_suspend -> cdns3_disconnect_gadget, after cdns3_disconnect_gadget is called, it owns lock wrongly, it causes the system being deadlock after resume due to at cdns3_device_thread_irq_handler, it tries to get the lock, but can't get it forever. To fix it, we delete the unlock-lock operations at cdns3_disconnect_gadget, and do it at the caller. Fixes: b1234e3b3b26 ("usb: cdns3: add runtime PM support") Acked-by: Pawel Laszczak <[email protected]> Signed-off-by: Peter Chen <[email protected]>
2020-10-30usb: cdns3: Fix on-chip memory overflow issuePawel Laszczak3-76/+94
Patch fixes issue caused setting On-chip memory overflow bit in usb_sts register. The issue occurred because EP_CFG register was set twice before USB_STS.CFGSTS was set. Every write operation on EP_CFG.BUFFERING causes that controller increases internal counter holding the number of reserved on-chip buffers. First time this register was updated in function cdns3_ep_config before delegating SET_CONFIGURATION request to class driver and again it was updated when class wanted to enable endpoint. This patch fixes this issue by configuring endpoints enabled by class driver in cdns3_gadget_ep_enable and others just before status stage. Cc: [email protected]#v5.8+ Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Reported-and-tested-by: Peter Chen <[email protected]> Signed-off-by: Pawel Laszczak <[email protected]> Signed-off-by: Peter Chen <[email protected]>
2020-10-29scsi: hpsa: Fix memory leak in hpsa_init_one()Keita Suzuki1-1/+3
When hpsa_scsi_add_host() fails, h->lastlogicals is leaked since it is missing a free() in the error handler. Fix this by adding free() when hpsa_scsi_add_host() fails. Link: https://lore.kernel.org/r/[email protected] Tested-by: Don Brace <[email protected]> Acked-by: Don Brace <[email protected]> Signed-off-by: Keita Suzuki <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2020-10-30Merge tag 'drm-intel-fixes-2020-10-29' of ↵Dave Airlie5-2/+84
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes - Fix max memory region size calculation (Matt) - Restore ILK-M RPS support, restoring performance (Ville) - Reject 90/270 degreerotated initial fbs (Ville) Signed-off-by: Dave Airlie <[email protected]> From: Rodrigo Vivi <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-30Merge branch 'linux-5.10' of git://github.com/skeggsb/linux into drm-fixesDave Airlie11-68/+145
Fixes an endian regression on older GPUs, a refcount overflow, a migration fix and 3 display fixes. Signed-off-by: Dave Airlie <[email protected]> From: Ben Skeggs <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv6MOjtgzKchpis1XrZYmu7-6CaxnHVzJKOXPH62_em7tw@mail.gmail.com
2020-10-30Merge tag 'drm-misc-fixes-2020-10-29' of ↵Dave Airlie16-64/+82
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes First round of drm-misc-fixes with a couple of leftovers from drm-misc-fixes next. Some reset fixes for the mantix panel, some fixes for a scaler issue on sun4i, many kernel-doc fixes and various fixes for vc4 (mostly HDMI audio related) Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-30drm/nouveau/kms/nv50-: Fix clock checking algorithm in nv50_dp_mode_valid()Lyude Paul1-10/+11
While I thought I had this correct (since it actually did reject modes like I expected during testing), Ville Syrjala from Intel pointed out that the logic here isn't correct. max_clock refers to the max data rate supported by the DP encoder. So, limiting it to the output of ds_clock (which refers to the maximum dotclock of the downstream DP device) doesn't make any sense. Additionally, since we're using the connector's bpc as the canonical BPC we should use this in mode_valid until we support dynamically setting the bpp based on bandwidth constraints. https://lists.freedesktop.org/archives/dri-devel/2020-September/280276.html For more info. So, let's rewrite this using Ville's advice. v2: * Ville pointed out I mixed up the dotclock and the link rate. So fix that... * ...and also rename all the variables in this function to be more appropriately labeled so I stop mixing them up. * Reuse the bpp from the connector for now until we have dynamic bpp selection. * Use use DIV_ROUND_UP for calculating the mode rate like i915 does, which we should also have been doing from the start Signed-off-by: Lyude Paul <[email protected]> Fixes: 409d38139b42 ("drm/nouveau/kms/nv50-: Use downstream DP clock limits for mode validation") Cc: Ville Syrjälä <[email protected]> Cc: Lyude Paul <[email protected]> Cc: Ben Skeggs <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-10-30drm/nouveau/kms/nv50-: Get rid of bogus nouveau_conn_mode_valid()Lyude Paul2-31/+21
Ville also pointed out that I got a lot of the logic here wrong as well, whoops. While I don't think anyone's likely using 3D output with nouveau, the next patch will make nouveau_conn_mode_valid() make a lot less sense. So, let's just get rid of it and open-code it like before, while taking care to move the 3D frame packing calculations on the dot clock into the right place. Signed-off-by: Lyude Paul <[email protected]> Fixes: d6a9efece724 ("drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST") Cc: Ville Syrjälä <[email protected]> Cc: <[email protected]> # v5.8+ Signed-off-by: Ben Skeggs <[email protected]>
2020-10-30drm/nouveau/device: fix changing endianess code to work on older GPUsKarol Herbst1-13/+26
With this we try to detect if the endianess switch works and assume LE if not. Suggested by Ben. Fixes: 51c05340e407 ("drm/nouveau/device: detect if changing endianness failed") Signed-off-by: Karol Herbst <[email protected]> Cc: <[email protected]> # v5.8+ Signed-off-by: Ben Skeggs <[email protected]>
2020-10-30drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"Karol Herbst1-1/+2
we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-10-30drm/nouveau/kms/nv50-: Program notifier offset before requesting disp capsLyude Paul6-5/+85
Not entirely sure why this never came up when I originally tested this (maybe some BIOSes already have this setup?) but the ->caps_init vfunc appears to cause the display engine to throw an exception on driver init, at least on my ThinkPad P72: nouveau 0000:01:00.0: disp: chid 0 mthd 008c data 00000000 0000508c 0000102b This is magic nvidia speak for "You need to have the DMA notifier offset programmed before you can call NV507D_GET_CAPABILITIES." So, let's fix this by doing that, and also perform an update afterwards to prevent racing with the GPU when reading capabilities. v2: * Don't just program the DMA notifier offset, make sure to actually perform an update v3: * Don't call UPDATE() * Actually read the correct notifier fields, as apparently the CAPABILITIES_DONE field lives in a different location than the main NV_DISP_CORE_NOTIFIER_1 field. As well, 907d+ use a different CAPABILITIES_DONE field then pre-907d cards. v4: * Don't forget to check the return value of core507d_read_caps() v5: * Get rid of NV50_DISP_CAPS_NTFY[14], use NV50_DISP_CORE_NTFY * Disable notifier after calling GetCapabilities() Signed-off-by: Lyude Paul <[email protected]> Fixes: 4a2cb4181b07 ("drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support") Cc: <[email protected]> # v5.8+ Signed-off-by: Ben Skeggs <[email protected]>
2020-10-30drm/nouveau/nouveau: fix the start/end range for migrationRalph Campbell1-11/+3
The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2020-10-30Merge tag 'amd-drm-fixes-5.10-2020-10-29' of ↵Dave Airlie13-76/+69
git://people.freedesktop.org/~agd5f/linux into drm-fixes amd-drm-fixes-5.10-2020-10-29: amdgpu: - Add new navi1x PCI ID - GPUVM reserved area fixes - Misc display fixes - Fix bad interactions between display code and CONFIG_KGDB - Fixes for SMU manual fan control and i2c Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-29scsi: target: tcmu: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29ima: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29enetc: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29fs: Replace zero-length array with flexible-array memberGustavo A. R. Silva6-10/+10
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29Bluetooth: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29params: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29tracepoint: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29platform/chrome: cros_ec_proto: Replace zero-length array with ↵Gustavo A. R. Silva1-1/+1
flexible-array member There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29platform/chrome: cros_ec_commands: Replace zero-length array with ↵Gustavo A. R. Silva1-7/+7
flexible-array member There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29mailbox: zynqmp-ipi-message: Replace zero-length array with flexible-array ↵Gustavo A. R. Silva1-1/+1
member There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29dmaengine: ti-cppi5: Replace zero-length array with flexible-array memberGustavo A. R. Silva1-2/+2
There is a regular need in the kernel to provide a way to declare having a dynamically sized set of trailing elements in a structure. Kernel code should always use “flexible array members”[1] for these cases. The older style of one-element or zero-length arrays should no longer be used[2]. [1] https://en.wikipedia.org/wiki/Flexible_array_member [2] https://www.kernel.org/doc/html/v5.9-rc1/process/deprecated.html#zero-length-and-one-element-arrays Signed-off-by: Gustavo A. R. Silva <[email protected]>
2020-10-29drm: Quieten [zero] EDID carpingChris Wilson1-2/+2
We have a few displays in CI that always report their EDID as a bunch of zeroes. This is consistent behaviour, so one assumes intentional indication of an "absent" EDID. Flagging these consistent warnings detracts from CI. One option would be to ignore the zero EDIDs as intentional behaviour, but Ville would like to keep the information available for debugging. The simple alternative then is to reduce the loglevel for all the EDID dumping from WARN to DEBUG so the information is present but not annoy CI. Note that the bad EDID dumping is already only shown if drm.debug=KMS, it's just the loglevel chosen was set to be caught by CI if it ever occurred as it was expected to be an internal error not external. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2203 Signed-off-by: Chris Wilson <[email protected]> Cc: Ville Syrjälä <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-10-29gfs2: check for live vs. read-only file system in gfs2_fitrimBob Peterson1-0/+3
Before this patch, gfs2_fitrim was not properly checking for a "live" file system. If the file system had something to trim and the file system was read-only (or spectator) it would start the trim, but when it starts the transaction, gfs2_trans_begin returns -EROFS (read-only file system) and it errors out. However, if the file system was already trimmed so there's no work to do, it never called gfs2_trans_begin. That code is bypassed so it never returns the error. Instead, it returns a good return code with 0 work. All this makes for inconsistent behavior: The same fstrim command can return -EROFS in one case and 0 in another. This tripped up xfstests generic/537 which reports the error as: +fstrim with unrecovered metadata just ate your filesystem This patch adds a check for a "live" (iow, active journal, iow, RW) file system, and if not, returns the error properly. Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-10-29gfs2: don't initialize statfs_change inodes in spectator modeBob Peterson1-4/+8
Before commit 97fd734ba17e, the local statfs_changeX inode was never initialized for spectator mounts. However, it still checks for spectator mounts when unmounting everything. There's no good reason to lookup the statfs_changeX files because spectators cannot perform recovery. It still, however, needs the master statfs file for statfs calls. This patch adds the check for spectator mounts to init_statfs. Fixes: 97fd734ba17e ("gfs2: lookup local statfs inodes prior to journal recovery") Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-10-29gfs2: Split up gfs2_meta_sync into inode and rgrp versionsBob Peterson5-40/+52
Before this patch, function gfs2_meta_sync called filemap_fdatawrite to write the address space for the metadata being synced. That's great for inodes, but resource groups all point to the same superblock-address space, sdp->sd_aspace. Each rgrp has its own range of blocks on which it should operate. That meant every time an rgrp's metadata was synced, it would write all of them instead of just the range. This patch eliminates function gfs2_meta_sync and tailors specific metasync functions for inodes and rgrps. Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-10-29gfs2: init_journal's undo directive should also undo the statfs inodesBob Peterson1-1/+1
Hi, Before this patch, function init_journal's "undo" directive jumped to label fail_jinode_gh. But now that it does statfs initialization, it needs to jump to fail_statfs instead. Failure to do so means that mount failures after init_journal is successful will neglect to let go of the proper statfs information, stranding the statfs_changeX inodes. This makes it impossible to free its glocks, and results in: gfs2: fsid=sda.s: G: s:EX n:2/805f f:Dqob t:EX d:UN/603701000 a:0 v:0 r:4 m:200 p:1 gfs2: fsid=sda.s: H: s:EX f:H e:0 p:1397947 [(ended)] init_journal+0x548/0x890 [gfs2] gfs2: fsid=sda.s: I: n:6/32863 t:8 f:0x00 d:0x00000201 s:24 p:0 gfs2: fsid=sda.s: G: s:SH n:5/805f f:Dqob t:SH d:UN/603712000 a:0 v:0 r:3 m:200 p:0 gfs2: fsid=sda.s: H: s:SH f:EH e:0 p:1397947 [(ended)] gfs2_inode_lookup+0x1fb/0x410 [gfs2] VFS: Busy inodes after unmount of sda. Self-destruct in 5 seconds. Have a nice day... The next time the file system is mounted, it then reuses the same glocks, which ends in a kernel NULL pointer dereference when trying to dump the reused glock. This patch makes the "undo" function of init_journal jump to fail_statfs so the statfs files are properly deconstructed upon failure. Fixes: 97fd734ba17e ("gfs2: lookup local statfs inodes prior to journal recovery") Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-10-29gfs2: Add missing truncate_inode_pages_final for sd_aspaceBob Peterson1-0/+1
Gfs2 creates an address space for its rgrps called sd_aspace, but it never called truncate_inode_pages_final on it. This confused vfs greatly which tried to reference the address space after gfs2 had freed the superblock that contained it. This patch adds a call to truncate_inode_pages_final for sd_aspace, thus avoiding the use-after-free. Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-10-29gfs2: Free rd_bits later in gfs2_clear_rgrpd to fix use-after-freeBob Peterson1-1/+1
Function gfs2_clear_rgrpd calls kfree(rgd->rd_bits) before calling return_all_reservations, but return_all_reservations still dereferences rgd->rd_bits in __rs_deltree. Fix that by moving the call to kfree below the call to return_all_reservations. Signed-off-by: Bob Peterson <[email protected]> Signed-off-by: Andreas Gruenbacher <[email protected]>
2020-10-29soc: ti: ti_sci_pm_domains: check for proper args count in xlateTero Kristo1-1/+1
K2G devices still only use single parameter for power-domains property, so check for this properly in the driver. Without this, every peripheral fails to probe resulting in boot failure. Link: https://lore.kernel.org/r/[email protected] Fixes: efa5c01cd7ee ("soc: ti: ti_sci_pm_domains: switch to use multiple genpds instead of one") Reported-by: Nishanth Menon <[email protected]> Signed-off-by: Tero Kristo <[email protected]> Acked-by: Nishanth Menon <[email protected]> Acked-by: Santosh Shilimkar <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2020-10-29KVM: arm64: Force PTE mapping on fault resulting in a device mappingSantosh Shukla1-0/+1
VFIO allows a device driver to resolve a fault by mapping a MMIO range. This can be subsequently result in user_mem_abort() to try and compute a huge mapping based on the MMIO pfn, which is a sure recipe for things to go wrong. Instead, force a PTE mapping when the pfn faulted in has a device mapping. Fixes: 6d674e28f642 ("KVM: arm/arm64: Properly handle faulting of device mappings") Suggested-by: Marc Zyngier <[email protected]> Signed-off-by: Santosh Shukla <[email protected]> [maz: rewritten commit message] Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Use fallback mapping sizes for contiguous huge page sizesGavin Shan1-7/+19
Although huge pages can be created out of multiple contiguous PMDs or PTEs, the corresponding sizes are not supported at Stage-2 yet. Instead of failing the mapping, fall back to the nearer supported mapping size (CONT_PMD to PMD and CONT_PTE to PTE respectively). Suggested-by: Marc Zyngier <[email protected]> Signed-off-by: Gavin Shan <[email protected]> [maz: rewritten commit message] Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29Merge tag 'fallthrough-fixes-clang-5.10-rc2' of ↵Linus Torvalds2-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux Pull fallthrough fix from Gustavo A. R. Silva: "This fixes a ton of fall-through warnings when building with Clang 12.0.0 and -Wimplicit-fallthrough" * tag 'fallthrough-fixes-clang-5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gustavoars/linux: include: jhash/signal: Fix fall-through warnings for Clang
2020-10-29Merge tag 'net-5.10-rc2' of ↵Linus Torvalds39-178/+261
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net Pull networking fixes from Jakub Kicinski: "Current release regressions: - r8169: fix forced threading conflicting with other shared interrupts; we tried to fix the use of raise_softirq_irqoff from an IRQ handler on RT by forcing hard irqs, but this driver shares legacy PCI IRQs so drop the _irqoff() instead - tipc: fix memory leak caused by a recent syzbot report fix to tipc_buf_append() Current release - bugs in new features: - devlink: Unlock on error in dumpit() and fix some error codes - net/smc: fix null pointer dereference in smc_listen_decline() Previous release - regressions: - tcp: Prevent low rmem stalls with SO_RCVLOWAT. - net: protect tcf_block_unbind with block lock - ibmveth: Fix use of ibmveth in a bridge; the self-imposed filtering to only send legal frames to the hypervisor was too strict - net: hns3: Clear the CMDQ registers before unmapping BAR region; incorrect cleanup order was leading to a crash - bnxt_en - handful of fixes to fixes: - Send HWRM_FUNC_RESET fw command unconditionally, even if there are PCIe errors being reported - Check abort error state in bnxt_open_nic(). - Invoke cancel_delayed_work_sync() for PFs also. - Fix regression in workqueue cleanup logic in bnxt_remove_one(). - mlxsw: Only advertise link modes supported by both driver and device, after removal of 56G support from the driver 56G was not cleared from advertised modes - net/smc: fix suppressed return code Previous release - always broken: - netem: fix zero division in tabledist, caused by integer overflow - bnxt_en: Re-write PCI BARs after PCI fatal error. - cxgb4: set up filter action after rewrites - net: ipa: command payloads already mapped Misc: - s390/ism: fix incorrect system EID, it's okay to change since it was added in current release - vsock: use ns_capable_noaudit() on socket create to suppress false positive audit messages" * tag 'net-5.10-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (36 commits) r8169: fix issue with forced threading in combination with shared interrupts netem: fix zero division in tabledist ibmvnic: fix ibmvnic_set_mac mptcp: add missing memory scheduling in the rx path tipc: fix memory leak caused by tipc_buf_append() gtp: fix an use-before-init in gtp_newlink() net: protect tcf_block_unbind with block lock ibmveth: Fix use of ibmveth in a bridge. net/sched: act_mpls: Add softdep on mpls_gso.ko ravb: Fix bit fields checking in ravb_hwtstamp_get() devlink: Unlock on error in dumpit() devlink: Fix some error codes chelsio/chtls: fix memory leaks in CPL handlers chelsio/chtls: fix deadlock issue net: hns3: Clear the CMDQ registers before unmapping BAR region bnxt_en: Send HWRM_FUNC_RESET fw command unconditionally. bnxt_en: Check abort error state in bnxt_open_nic(). bnxt_en: Re-write PCI BARs after PCI fatal error. bnxt_en: Invoke cancel_delayed_work_sync() for PFs also. bnxt_en: Fix regression in workqueue cleanup logic in bnxt_remove_one(). ...
2020-10-29KVM: arm64: Fix masks in stage2_pte_cacheable()Will Deacon1-1/+1
stage2_pte_cacheable() tries to figure out whether the mapping installed in its 'pte' parameter is cacheable or not. Unfortunately, it fails miserably because it extracts the memory attributes from the entry using FIELD_GET(), which returns the attributes shifted down to bit 0, but then compares this with the unshifted value generated by the PAGE_S2_MEMATTR() macro. A direct consequence of this bug is that cache maintenance is silently skipped, which in turn causes 32-bit guests to crash early on when their set/way maintenance is trapped but not emulated correctly. Fix the broken masks by avoiding the use of FIELD_GET() altogether. Fixes: 6d9d2115c480 ("KVM: arm64: Add support for stage-2 map()/unmap() in generic page-table") Reported-by: Marc Zyngier <[email protected]> Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Cc: Quentin Perret <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Fix AArch32 handling of DBGD{CCINT,SCRext} and DBGVCRMarc Zyngier2-3/+4
The DBGD{CCINT,SCRext} and DBGVCR register entries in the cp14 array are missing their target register, resulting in all accesses being targetted at the guard sysreg (indexed by __INVALID_SYSREG__). Point the emulation code at the actual register entries. Fixes: bdfb4b389c8d ("arm64: KVM: add trap handlers for AArch32 debug registers") Signed-off-by: Marc Zyngier <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Allocate stage-2 pgd pages with GFP_KERNEL_ACCOUNTWill Deacon1-1/+1
For consistency with the rest of the stage-2 page-table page allocations (performing using a kvm_mmu_memory_cache), ensure that __GFP_ACCOUNT is included in the GFP flags for the PGD pages. Signed-off-by: Will Deacon <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Gavin Shan <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Quentin Perret <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Drop useless PAN setting on host EL1 to EL2 transitionMarc Zyngier1-2/+0
Setting PSTATE.PAN when entering EL2 on nVHE doesn't make much sense as this bit only means something for translation regimes that include EL0. This obviously isn't the case in the nVHE case, so let's drop this setting. Signed-off-by: Marc Zyngier <[email protected]> Reviewed-by: Vladimir Murzin <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-10-29KVM: arm64: Remove leftover kern_hyp_va() in nVHE TLB invalidationMarc Zyngier1-1/+0
The new calling convention says that pointers coming from the SMCCC interface are turned into their HYP version in the host HVC handler. However, there is still a stray kern_hyp_va() in the TLB invalidation code, which could result in a corrupted pointer. Drop the spurious conversion. Fixes: a071261d9318 ("KVM: arm64: nVHE: Fix pointers during SMCCC convertion") Signed-off-by: Marc Zyngier <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.