dri-devel March 2022

dri-devel@lists.freedesktop.org

370 participants
780 discussions

[PATCH] drm/panel-edp: Fix AUO B133UAN01 panel id
by Matthias Kaehlcke 30 Mar '22

30 Mar '22

Two digits are swapped in the AUO B133UAN01 panel id (0x8495 instead of 0x8594). This went initially unnoticed because the panel is still detected, though it is set up with a conservative default timing. Fix the digit swap. Fixes: ec57376fba5a ("drm/panel-edp: Add AUO B133UAN01") Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> --- drivers/gpu/drm/panel/panel-edp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/panel-edp.c index db4eea1d7f67..1732b4f56e38 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -1847,7 +1847,7 @@ static const struct panel_delay delay_100_500_e200 = { static const struct edp_panel_entry edp_panels[] = { EDP_PANEL_ENTRY('A', 'U', 'O', 0x405c, &auo_b116xak01.delay, "B116XAK01"), EDP_PANEL_ENTRY('A', 'U', 'O', 0x615c, &delay_200_500_e50, "B116XAN06.1"), - EDP_PANEL_ENTRY('A', 'U', 'O', 0x8495, &delay_200_500_e50, "B133UAN01.0"), + EDP_PANEL_ENTRY('A', 'U', 'O', 0x8594, &delay_200_500_e50, "B133UAN01.0"), EDP_PANEL_ENTRY('B', 'O', 'E', 0x0786, &delay_200_500_p2e80, "NV116WHM-T01"), EDP_PANEL_ENTRY('B', 'O', 'E', 0x07d1, &boe_nv133fhm_n61.delay, "NV133FHM-N61"), -- 2.35.1.1094.g7c7d902a7c-goog

2 1

[PATCH] drm: round_up the size to the alignment value
by Arunpravin Paneer Selvam 30 Mar '22

30 Mar '22

Round up the size value to the min_page_size and trim the last block to the required size. This solves a bug detected when size is not aligned with the min_page_size. Unigine Heaven has allocation requests for example required pages are 257 and alignment request is 256. To allocate the left over 1 page, continues the iteration to find the order value which is 0 and when it compares with min_order = 8, triggers the BUG_ON(order < min_order). To avoid this issue we round_up the size value to the min_page_size and trim the last block to the computed required size value. Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam(a)amd.com> --- drivers/gpu/drm/drm_buddy.c | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/drivers/gpu/drm/drm_buddy.c b/drivers/gpu/drm/drm_buddy.c index 72f52f293249..98d7ec359b08 100644 --- a/drivers/gpu/drm/drm_buddy.c +++ b/drivers/gpu/drm/drm_buddy.c @@ -641,6 +641,7 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm, unsigned int min_order, order; unsigned long pages; LIST_HEAD(allocated); + u64 cur_size; int err; if (size < mm->chunk_size) @@ -665,6 +666,11 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm, if (start + size == end) return __drm_buddy_alloc_range(mm, start, size, blocks); + cur_size = size; + + if (!IS_ALIGNED(size, min_page_size)) + size = round_up(size, min_page_size); + pages = size >> ilog2(mm->chunk_size); order = fls(pages) - 1; min_order = ilog2(min_page_size) - ilog2(mm->chunk_size); @@ -702,6 +708,31 @@ int drm_buddy_alloc_blocks(struct drm_buddy *mm, break; } while (1); + + /* + * If size value rounded up to min_page_size, trim the last block + * to the required size + */ + if (cur_size != size) { + struct drm_buddy_block *trim_block; + LIST_HEAD(trim_list); + u64 required_size; + + trim_block = list_last_entry(&allocated, typeof(*trim_block), link); + list_move_tail(&trim_block->link, &trim_list); + /* + * Compute the required_size value by subtracting the last block size + * with (aligned size - original size) + */ + required_size = drm_buddy_block_size(mm, trim_block) - (size - cur_size); + + drm_buddy_block_trim(mm, + required_size, + &trim_list); + + list_splice_tail(&trim_list, &allocated); + } + list_splice_tail(&allocated, blocks); return 0; base-commit: ec57376fba5abc0e571617ff88e2ade7970c2e4b -- 2.25.1

3 4

[PATCH] drm/i915/guc: Use iosys_map interface to update lrc_desc
by Balasubramani Vivekanandan 30 Mar '22

30 Mar '22

This patch is continuation of the effort to move all pointers in i915, which at any point may be pointing to device memory or system memory, to iosys_map interface. More details about the need of this change is explained in the patch series which initiated this task https://patchwork.freedesktop.org/series/99711/ This patch converts all access to the lrc_desc through iosys_map interfaces. Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: John Harrison <John.C.Harrison(a)Intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa(a)intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan(a)intel.com> --- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 68 ++++++++++++------- 2 files changed, 43 insertions(+), 27 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h b/drivers/gpu/drm/i915/gt/uc/intel_guc.h index e439e6c1ac8b..cbbc24dbaf0f 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h @@ -168,7 +168,7 @@ struct intel_guc { /** @lrc_desc_pool: object allocated to hold the GuC LRC descriptor pool */ struct i915_vma *lrc_desc_pool; /** @lrc_desc_pool_vaddr: contents of the GuC LRC descriptor pool */ - void *lrc_desc_pool_vaddr; + struct iosys_map lrc_desc_pool_vaddr; /** * @context_lookup: used to resolve intel_context from guc_id, if a diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c index 9ec03234d2c2..84b17ded886a 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c @@ -467,13 +467,14 @@ static u32 *get_wq_pointer(struct guc_process_desc *desc, return &__get_parent_scratch(ce)->wq[ce->parallel.guc.wqi_tail / sizeof(u32)]; } -static struct guc_lrc_desc *__get_lrc_desc(struct intel_guc *guc, u32 index) +static void __write_lrc_desc(struct intel_guc *guc, u32 index, + struct guc_lrc_desc *desc) { - struct guc_lrc_desc *base = guc->lrc_desc_pool_vaddr; + unsigned int size = sizeof(struct guc_lrc_desc); GEM_BUG_ON(index >= GUC_MAX_CONTEXT_ID); - return &base[index]; + iosys_map_memcpy_to(&guc->lrc_desc_pool_vaddr, index * size, desc, size); } static inline struct intel_context *__get_context(struct intel_guc *guc, u32 id) @@ -489,20 +490,28 @@ static int guc_lrc_desc_pool_create(struct intel_guc *guc) { u32 size; int ret; + void *addr; size = PAGE_ALIGN(sizeof(struct guc_lrc_desc) * GUC_MAX_CONTEXT_ID); ret = intel_guc_allocate_and_map_vma(guc, size, &guc->lrc_desc_pool, - (void **)&guc->lrc_desc_pool_vaddr); + &addr); + if (ret) return ret; + if (i915_gem_object_is_lmem(guc->lrc_desc_pool->obj)) + iosys_map_set_vaddr_iomem(&guc->lrc_desc_pool_vaddr, + (void __iomem *)addr); + else + iosys_map_set_vaddr(&guc->lrc_desc_pool_vaddr, addr); + return 0; } static void guc_lrc_desc_pool_destroy(struct intel_guc *guc) { - guc->lrc_desc_pool_vaddr = NULL; + iosys_map_clear(&guc->lrc_desc_pool_vaddr); i915_vma_unpin_and_release(&guc->lrc_desc_pool, I915_VMA_RELEASE_MAP); } @@ -513,9 +522,11 @@ static inline bool guc_submission_initialized(struct intel_guc *guc) static inline void _reset_lrc_desc(struct intel_guc *guc, u32 id) { - struct guc_lrc_desc *desc = __get_lrc_desc(guc, id); + unsigned int size = sizeof(struct guc_lrc_desc); - memset(desc, 0, sizeof(*desc)); + GEM_BUG_ON(id >= GUC_MAX_CONTEXT_ID); + + iosys_map_memset(&guc->lrc_desc_pool_vaddr, id * size, 0, size); } static inline bool ctx_id_mapped(struct intel_guc *guc, u32 id) @@ -2233,7 +2244,7 @@ static void prepare_context_registration_info(struct intel_context *ce) struct intel_engine_cs *engine = ce->engine; struct intel_guc *guc = &engine->gt->uc.guc; u32 ctx_id = ce->guc_id.id; - struct guc_lrc_desc *desc; + struct guc_lrc_desc desc; struct intel_context *child; GEM_BUG_ON(!engine->mask); @@ -2245,13 +2256,13 @@ static void prepare_context_registration_info(struct intel_context *ce) GEM_BUG_ON(i915_gem_object_is_lmem(guc->ct.vma->obj) != i915_gem_object_is_lmem(ce->ring->vma->obj)); - desc = __get_lrc_desc(guc, ctx_id); - desc->engine_class = engine_class_to_guc_class(engine->class); - desc->engine_submit_mask = engine->logical_mask; - desc->hw_context_desc = ce->lrc.lrca; - desc->priority = ce->guc_state.prio; - desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD; - guc_context_policy_init(engine, desc); + memset(&desc, 0, sizeof(desc)); + desc.engine_class = engine_class_to_guc_class(engine->class); + desc.engine_submit_mask = engine->logical_mask; + desc.hw_context_desc = ce->lrc.lrca; + desc.priority = ce->guc_state.prio; + desc.context_flags = CONTEXT_REGISTRATION_FLAG_KMD; + guc_context_policy_init(engine, &desc); /* * If context is a parent, we need to register a process descriptor @@ -2259,36 +2270,41 @@ static void prepare_context_registration_info(struct intel_context *ce) */ if (intel_context_is_parent(ce)) { struct guc_process_desc *pdesc; + struct guc_lrc_desc child_desc; ce->parallel.guc.wqi_tail = 0; ce->parallel.guc.wqi_head = 0; - desc->process_desc = i915_ggtt_offset(ce->state) + + desc.process_desc = i915_ggtt_offset(ce->state) + __get_parent_scratch_offset(ce); - desc->wq_addr = i915_ggtt_offset(ce->state) + + desc.wq_addr = i915_ggtt_offset(ce->state) + __get_wq_offset(ce); - desc->wq_size = WQ_SIZE; + desc.wq_size = WQ_SIZE; pdesc = __get_process_desc(ce); memset(pdesc, 0, sizeof(*(pdesc))); pdesc->stage_id = ce->guc_id.id; - pdesc->wq_base_addr = desc->wq_addr; - pdesc->wq_size_bytes = desc->wq_size; + pdesc->wq_base_addr = desc.wq_addr; + pdesc->wq_size_bytes = desc.wq_size; pdesc->wq_status = WQ_STATUS_ACTIVE; for_each_child(ce, child) { - desc = __get_lrc_desc(guc, child->guc_id.id); + memset(&child_desc, 0, sizeof(child_desc)); - desc->engine_class = + child_desc.engine_class = engine_class_to_guc_class(engine->class); - desc->hw_context_desc = child->lrc.lrca; - desc->priority = ce->guc_state.prio; - desc->context_flags = CONTEXT_REGISTRATION_FLAG_KMD; - guc_context_policy_init(engine, desc); + child_desc.hw_context_desc = child->lrc.lrca; + child_desc.priority = ce->guc_state.prio; + child_desc.context_flags = CONTEXT_REGISTRATION_FLAG_KMD; + guc_context_policy_init(engine, &child_desc); + + __write_lrc_desc(guc, child->guc_id.id, &child_desc); } clear_children_join_go_memory(ce); } + + __write_lrc_desc(guc, ctx_id, &desc); } static int try_context_registration(struct intel_context *ce, bool loop) -- 2.25.1

4 5

[PATCH 0/2] chrontel-ch7033: Add byteswap order option
by Chris Morgan 30 Mar '22

30 Mar '22

From: Chris Morgan <macromorgan(a)hotmail.com> This series adds the ability to set the byteswap order in the chrontel ch7033 driver via an optional devicetree node. This is necessary because the HDMI DIP of the NTC CHIP requires a byteswap order that differs from the default value of the driver. Signed-off-by: Chris Morgan <macromorgan(a)hotmail.com> Chris Morgan (2): dt-bindings: Add byteswap order to chrontel ch7033 drm/bridge: chrontel-ch7033: Add option for setting byteswap order .../bindings/display/bridge/chrontel,ch7033.yaml | 8 ++++++++ drivers/gpu/drm/bridge/chrontel-ch7033.c | 15 +++++++++++++-- 2 files changed, 21 insertions(+), 2 deletions(-) -- 2.25.1

1 2

[PATCH 1/1] drm/amdkfd: Create file descriptor after client is added to smi_clients list
by Lee Jones 30 Mar '22

30 Mar '22

This ensures userspace cannot prematurely clean-up the client before it is fully initialised which has been proven to cause issues in the past. Cc: Felix Kuehling <Felix.Kuehling(a)amd.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan(a)amd.com> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: amd-gfx(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Lee Jones <lee.jones(a)linaro.org> --- drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c index e4beebb1c80a2..c5d5398d45cbf 100644 --- a/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c +++ b/drivers/gpu/drm/amd/amdkfd/kfd_smi_events.c @@ -247,15 +247,6 @@ int kfd_smi_event_open(struct kfd_dev *dev, uint32_t *fd) return ret; } - ret = anon_inode_getfd(kfd_smi_name, &kfd_smi_ev_fops, (void *)client, - O_RDWR); - if (ret < 0) { - kfifo_free(&client->fifo); - kfree(client); - return ret; - } - *fd = ret; - init_waitqueue_head(&client->wait_queue); spin_lock_init(&client->lock); client->events = 0; @@ -265,5 +256,14 @@ int kfd_smi_event_open(struct kfd_dev *dev, uint32_t *fd) list_add_rcu(&client->list, &dev->smi_clients); spin_unlock(&dev->smi_lock); + ret = anon_inode_getfd(kfd_smi_name, &kfd_smi_ev_fops, (void *)client, + O_RDWR); + if (ret < 0) { + kfifo_free(&client->fifo); + kfree(client); + return ret; + } + *fd = ret; + return 0; } -- 2.35.1.1021.g381101b075-goog

2 2

[PATCH 0/9] drm/msm: Userspace allocated GPU addresses
by Rob Clark 30 Mar '22

30 Mar '22

From: Rob Clark <robdclark(a)chromium.org> The first five paches are various cleanups and simplifications. The next two get rid of redundant vma lookups in the submit and retire paths. Following that, fenced vma lets us indicate a fence value following which the vma is no longer used, which is needed because otherwise userspace could observe the signaled fence prior to retire_submits() finishing. (With userspace allocated GPU addresses userspace is tracking when a buffer is no longer used and it's vma can be deleted.) And finally the last patch adds the new uabi for user- space allocated iova. Rob Clark (9): drm/msm/gem: Move prototypes drm/msm/gpu: Drop duplicate fence counter drm/msm/gem: Split out inuse helper drm/msm/gem: Drop PAGE_SHIFT for address space mm drm/msm: Drop msm_gem_iova() drm/msm/gem: Rework vma lookup and pin drm/msm/gem: Split vma lookup and pin drm/msm/gem: Add fenced vma unpin drm/msm: Add a way for userspace to allocate GPU iova drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 14 ++- drivers/gpu/drm/msm/msm_drv.c | 21 ++++ drivers/gpu/drm/msm/msm_drv.h | 23 ---- drivers/gpu/drm/msm/msm_fb.c | 16 ++- drivers/gpu/drm/msm/msm_fence.c | 6 +- drivers/gpu/drm/msm/msm_fence.h | 3 + drivers/gpu/drm/msm/msm_gem.c | 151 ++++++++++++++---------- drivers/gpu/drm/msm/msm_gem.h | 47 +++++++- drivers/gpu/drm/msm/msm_gem_submit.c | 17 ++- drivers/gpu/drm/msm/msm_gem_vma.c | 59 ++++++--- drivers/gpu/drm/msm/msm_gpu.c | 8 +- drivers/gpu/drm/msm/msm_gpu.h | 2 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 12 +- drivers/gpu/drm/msm/msm_ringbuffer.h | 1 - include/uapi/drm/msm_drm.h | 3 + 18 files changed, 258 insertions(+), 131 deletions(-) -- 2.35.1

3 17

[PATCH 0/2] remove DC_FP_* wrappers in dml files
by Melissa Wen 30 Mar '22

30 Mar '22

>From FPU documentation, developers must not use DC_FP_START/END in dml files, but invoke it when calling FPU-associated functions (isolated in dml folder). Therefore, the first patch renames dcn10_validate_bandwidth in dml/calcs to dcn_ for generalization, declares dcn10_validate_bandwidth in dcn10 - that calls dcn_validate_bandwidth and wraps with DC_FP_* accordingly. The second patch removes invocations of DC_FP_* from dml files and properly wraps FPU functions in dc code outside dml folder. Melissa Wen (2): drm/amd/display: detach fpu operations from dcn10_validate_bandwidth in calcs drm/amd/display: remove DC_FP_* wrapper from dml folder .../amd/display/dc/dcn10/dcn10_hw_sequencer.c | 10 ++++++++-- .../drm/amd/display/dc/dcn10/dcn10_resource.c | 16 ++++++++++++++++ .../drm/amd/display/dc/dml/calcs/dcn_calcs.c | 19 +------------------ .../drm/amd/display/dc/dml/dcn20/dcn20_fpu.c | 2 -- .../gpu/drm/amd/display/dc/inc/dcn_calcs.h | 2 +- 5 files changed, 26 insertions(+), 23 deletions(-) -- 2.35.1

4 7

Re: regression: NULL pointer dereference due to 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")
by Thorsten Leemhuis 30 Mar '22

30 Mar '22

[TLDR: I'm adding the regression report below to regzbot, the Linux kernel regression tracking bot; all text you find below is compiled from a few templates paragraphs you might have encountered already already from similar mails.] [adding fbdev and dri-devel lists, and the egression mailing list, as it should be in the loop for all regressions] Hi, this is your Linux kernel regression tracker. Top-posting for once, to make this easily accessible to everyone. Thanks for the report. Thomas, Zack, do you know what's up here? Note to everyone: the culprit of this regression is marked for backporting. Anyway: To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced 27599aacbaef #regzbot title drm: fbdev: NULL pointer dereference due to 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal") #regzbot ignore-activity If it turns out this isn't a regression, free free to remove it from the tracking by sending a reply to this thread containing a paragraph like "#regzbot invalid: reason why this is invalid" (without the quotes). Reminder for developers: when fixing the issue, please add a 'Link:' tags pointing to the report (the mail quoted above) using lore.kernel.org/r/, as explained in 'Documentation/process/submitting-patches.rst' and 'Documentation/process/5.Posting.rst'. Regzbot needs them to automatically connect reports with fixes, but they are useful in general, too. I'm sending this to everyone that got the initial report, to make everyone aware of the tracking. I also hope that messages like this motivate people to directly get at least the regression mailing list and ideally even regzbot involved when dealing with regressions, as messages like this wouldn't be needed then. And don't worry, if I need to send other mails regarding this regression only relevant for regzbot I'll send them to the regressions lists only (with a tag in the subject so people can filter them away). With a bit of luck no such messages will be needed anyway. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I'm getting a lot of reports on my table. I can only look briefly into most of them and lack knowledge about most of the areas they concern. I thus unfortunately will sometimes get things wrong or miss something important. I hope that's not the case here; if you think it is, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. On 28.03.22 17:41, Sudip Mukherjee wrote: > Hi Thomas, > > We usually run boot tests with linux mainline HEAD commit almost every > night on ppc64 qemu. And my tests had been failing for last few days. > Testing locally gave me: > > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.038791] BUG: Kernel NULL pointer dereference on read at 0x00000060 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.038995] Faulting instruction address: 0xc00000000080dfa4 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.039572] Oops: Kernel access of bad area, sig: 11 [#1] > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.039723] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.040012] Modules linked in: bochs(+) drm_vram_helper xhci_pci drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm_ttm_helper sr_mod ttm cdrom xhci_hcd virtio_net virtio_console net_failover virtio_blk virtio_scsi failover ibmvscsi scsi_transport_srp virtio_pci virtio virtio_pci_legacy_dev virtio_pci_modern_dev usbcore drm drm_panel_orientation_quirks virtio_ring usb_common > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.040918] CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.041245] NIP: c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.041376] REGS: c000000004132fe0 TRAP: 0300 Not tainted (5.17.0-ae085d7f9365) > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.041528] MSR: 8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE> CR: 28228282 XER: 20000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.042017] GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.043184] NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.043748] LR [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.043982] Call Trace: > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.044108] [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable) > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.044335] [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.044468] [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.044588] [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm] > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.045443] [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs] > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.045624] [c000000004133570] [c0000000007ca518] local_pci_probe+0x68/0x110 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.045730] [c0000000041335f0] [c0000000007cb438] pci_call_probe+0x88/0x1a0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.045830] [c000000004133750] [c0000000007cc6ac] pci_device_probe+0xbc/0x1a0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.045928] [c000000004133790] [c0000000008969e0] really_probe+0x100/0x5e0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046025] [c000000004133810] [c00000000089704c] __driver_probe_device+0x18c/0x250 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046125] [c000000004133890] [c00000000089716c] driver_probe_device+0x5c/0x140 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046225] [c0000000041338d0] [c000000000897cf8] __driver_attach+0x118/0x290 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046322] [c000000004133950] [c000000000892d38] bus_for_each_dev+0xa8/0x130 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046425] [c0000000041339b0] [c000000000895c24] driver_attach+0x34/0x50 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046521] [c0000000041339d0] [c000000000895308] bus_add_driver+0x1b8/0x2e0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046618] [c000000004133a60] [c000000000898ea4] driver_register+0xb4/0x1c0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046714] [c000000004133ad0] [c0000000007c9d28] __pci_register_driver+0x68/0x80 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046815] [c000000004133af0] [c008000000da174c] bochs_pci_driver_init+0x70/0x98 [bochs] > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.046931] [c000000004133b20] [c000000000011fd0] do_one_initcall+0x60/0x2d0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.047033] [c000000004133c00] [c000000000229d38] do_init_module+0x68/0x360 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.047136] [c000000004133c90] [c00000000022dc3c] __do_sys_finit_module+0xdc/0x180 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.047239] [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.050839] [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.053127] --- interrupt: c00 at 0x7fffa43100c4 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.055616] NIP: 00007fffa43100c4 LR: 00007fffa457fe2c CTR: 0000000000000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.058073] REGS: c000000004133e80 TRAP: 0c00 Not tainted (5.17.0-ae085d7f9365) > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.060563] MSR: 800000000000f033 <SF,EE,PR,FP,ME,IR,DR,RI,LE> CR: 24222824 XER: 00000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] IRQMASK: 0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR00: 0000000000000161 00007fffe8930710 00007fffa43f7100 0000000000000015 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR04: 00007fffa458b448 0000000000000000 0000000000000000 0000000000000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR12: 0000000000000000 00007fffa465ddd0 0000000020000000 0000000000000000 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR20: 000001000f7283b0 0000000000000000 0000000113fcfb68 000001000f729570 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR24: 0000000000000000 000001000f7283b0 0000000000020000 000001000f7282f0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.063048] GPR28: 00007fffa458b448 0000000000020000 0000000000000000 000001000f7283b0 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.086658] NIP [00007fffa43100c4] 0x7fffa43100c4 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.091853] LR [00007fffa457fe2c] 0x7fffa457fe2c > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.097294] --- interrupt: c00 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.103124] Instruction dump: > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.112912] 7d710120 7d708120 4e800020 e8df0000 7fc407b4 7f45d378 7ec3b378 f8810068 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.119165] 38c600f0 4b9b9c7d 60000000 3d22fff3 <e9550060> 392979e8 e8810068 7c2a4800 > Mar 28 13:16:36 debian-ppc64 kernel: [ 11.123573] ---[ end trace 0000000000000000 ]--- > > My last good test was with 5.17.0-3bf03b9a0839 and can be seen at: > https://openqa.qa.codethink.co.uk/tests/932 > > A failure test with 5.17.0-52d543b5497c can be seen at: https://openqa.qa.codethink.co.uk/tests/937 > > After reverting 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on > forced removal") on top of latest Linux mainline HEAD fixes the problem > and I can see qemu booting again. > > I will be happy to test any patch fixing the problem. -- Additional information about regzbot: If you want to know more about regzbot, check out its web-interface, the getting start guide, and the references documentation: https://linux-regtracking.leemhuis.info/regzbot/ https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md The last two documents will explain how you can interact with regzbot yourself if your want to. Hint for reporters: when reporting a regression it's in your interest to CC the regression list and tell regzbot about the issue, as that ensures the regression makes it onto the radar of the Linux kernel's regression tracker -- that's in your interest, as it ensures your report won't fall through the cracks unnoticed. Hint for developers: you normally don't need to care about regzbot once it's involved. Fix the issue as you normally would, just remember to include 'Link:' tag in the patch descriptions pointing to all reports about the issue. This has been expected from developers even before regzbot showed up for reasons explained in 'Documentation/process/submitting-patches.rst' and 'Documentation/process/5.Posting.rst'.

1 0

[PATCH AUTOSEL 4.9 01/17] video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow
by Sasha Levin 30 Mar '22

30 Mar '22

From: Tim Gardner <tim.gardner(a)canonical.com> [ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ] Coverity complains of a possible buffer overflow. However, given the 'static' scope of nvidia_setup_i2c_bus() it looks like that can't happen after examiniing the call sites. CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW) 1. fixed_size_dest: You might overrun the 48-character fixed-size string chan->adapter.name by copying name without checking the length. 2. parameter_as_source: Note: This defect has an elevated risk because the source argument is a parameter of the current function. 89 strcpy(chan->adapter.name, name); Fix this warning by using strscpy() which will silence the warning and prevent any future buffer overflows should the names used to identify the channel become much longer. Cc: Antonino Daplas <adaplas(a)gmail.com> Cc: linux-fbdev(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Tim Gardner <tim.gardner(a)canonical.com> Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/video/fbdev/nvidia/nv_i2c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c b/drivers/video/fbdev/nvidia/nv_i2c.c index d7994a173245..0b48965a6420 100644 --- a/drivers/video/fbdev/nvidia/nv_i2c.c +++ b/drivers/video/fbdev/nvidia/nv_i2c.c @@ -86,7 +86,7 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, const char *name, { int rc; - strcpy(chan->adapter.name, name); + strscpy(chan->adapter.name, name, sizeof(chan->adapter.name)); chan->adapter.owner = THIS_MODULE; chan->adapter.class = i2c_class; chan->adapter.algo_data = &chan->algo; -- 2.34.1

1 0

[PATCH AUTOSEL 4.14 01/20] video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow
by Sasha Levin 30 Mar '22

30 Mar '22

1 0

← Newer
1
...
16
17
18
19
20
21
22
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2022