Message ID | 20231108022716.15250-1-dakr@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:aa0b:0:b0:403:3b70:6f57 with SMTP id k11csp650310vqo; Tue, 7 Nov 2023 18:28:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IE4nw8gOH2nshBwBDMSHd0ZVMaZBfon1+cA5MnyYF3bCZShKyAwHQjidRiRPuFZ+baWaRrW X-Received: by 2002:a25:bc90:0:b0:d9b:4a28:f66 with SMTP id e16-20020a25bc90000000b00d9b4a280f66mr588459ybk.53.1699410507040; Tue, 07 Nov 2023 18:28:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699410507; cv=none; d=google.com; s=arc-20160816; b=adeUt0t/OATnXzDfE9FtqOgSoTC4Zyp1f6g4CCGMFKU0i+enCwanTGxSZ3KroETYDz 5BEg5ZFHnVnycb0uQWCR5qv+qntqB/PPL+x1qUBxR7ngzfW2OufwzVcQ344JCFb+293U weKPCUHWGAWnMbqTY7Drwg+L4IhBEa5k/PEVH5mUMX2XhUk83vpgGS5JggfliQ70a7QK /N9EkSa3WBCZEVdfGagdWJjC+NIgvYMfPMaDUQByiajGsD0xwBhCTtUWlW1LAwD7ntwe VXqZ7wi46LqEiSjMC1vm9ZgdduVauWkdD5NNCkqN97LRj52brNkMeqsRzBzeufH/y71b pStQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=B3DL0Vft98Gq2vq6RutJxBknUxdBNOODfG1hAxtLDfY=; fh=wV5QwnFZcdFi7pIpUHvN2Jj76p5zzE/0bbCxD9X47qw=; b=09rK80KJ7aggaihRVWtilLHC1BXC9vtLhjy+SZo283y1HznNIeS0/eXSzIDe8tbjxu gWmeTKVigF+RmGeTPZl+QjJyvvEqWi2JrGqnLfnMa/NxIJxc7yHHkflPxb7eGd6g9cnc Bn37hcxnw5dRZGVfqamlXqtMkM32yLyNpiS/7AZmKwGoCMGir22fIUEYypudDP8BdUc4 rHhczKvjfNk8ZDUhpi6ZoQCQBJO0sQsuJ29nSsOiEEJ/95gGQaHdkFMiSxQjkyMqe1Pl dqQeQDikle7s0+d9MJd9Daawg8Re0X/RckDY17slfbKCegSZeTy7LlPhoPAFEbqBcQWo bROA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BAK6VOXB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from groat.vger.email (groat.vger.email. [23.128.96.35]) by mx.google.com with ESMTPS id fc27-20020a056a002e1b00b006bf349fd067si12417434pfb.156.2023.11.07.18.28.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 18:28:26 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BAK6VOXB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by groat.vger.email (Postfix) with ESMTP id DDD0C80EE7A1; Tue, 7 Nov 2023 18:28:24 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234832AbjKHC2O (ORCPT <rfc822;jaysivo@gmail.com> + 32 others); Tue, 7 Nov 2023 21:28:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46098 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230389AbjKHC2N (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 7 Nov 2023 21:28:13 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 86ECE10F9 for <linux-kernel@vger.kernel.org>; Tue, 7 Nov 2023 18:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1699410444; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=B3DL0Vft98Gq2vq6RutJxBknUxdBNOODfG1hAxtLDfY=; b=BAK6VOXBVV30gXMwFuppfSa17AnQbIdnC1ECUQ9z+J6UIE+nU3gdF8n5g6+NG0ckIEIH37 iVKOyAlFg5nqWtUyiZxL+SABq1dw5aqIjsGRcj71dUH86I90RXZdYsIlWcrMzNzlThTRa/ 78FyGnCXWiNKBbo59PyNB8Roal5IiCs= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-641-2kOUYiDqMOmBCiKXhtJjtA-1; Tue, 07 Nov 2023 21:27:21 -0500 X-MC-Unique: 2kOUYiDqMOmBCiKXhtJjtA-1 Received: by mail-ed1-f72.google.com with SMTP id 4fb4d7f45d1cf-53df4385dccso5053577a12.0 for <linux-kernel@vger.kernel.org>; Tue, 07 Nov 2023 18:27:21 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699410440; x=1700015240; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=B3DL0Vft98Gq2vq6RutJxBknUxdBNOODfG1hAxtLDfY=; b=vyJh+MDLr/MRsrdMhmEKOFgXpR8gQUoHMmOXY3XFZ+R4Eiu5xoRELrg8XJ1T2SJJWh a2JTgIZ2hhjti595B4KbtPhC3NUOekjV9hQPrQAzxc7cDqqGIgFZMagBdajXCOekapUM 2tvnZ53wrr8eVScCu1u4JpPkt6YusTfXvhiN8qrSaY9m7Fk0S3Oj8OSgqCYf5poxr+h9 Nxhm3WCUBUmiyiH2DkiK5RM1eqwgIEfpAcy0lcLtjlb6Mn/Sl9RuygBmoz4EVye/65zm BoJVIEjg1xZuodefk8cZwT3IrTeyo5D9nDXCi/YFM/jxLqMV/9mMzEBE0agP8zpt/WzX KMpQ== X-Gm-Message-State: AOJu0YyKxTIlRhhyvXJi9l2bYhKsWmA4Ny+DVfjUpsqLkFBdWxuGOZSU s9KD6NjLezQ1vb68GAuRgKYnJocYImK4koSJ1uHf8PubHvLir97jjZopWBZbn/L9rEb3mjaukL0 hcPyglfdN+n2WAZfXfiMm2N5x X-Received: by 2002:a50:d555:0:b0:540:b0ec:bcd5 with SMTP id f21-20020a50d555000000b00540b0ecbcd5mr357602edj.15.1699410440221; Tue, 07 Nov 2023 18:27:20 -0800 (PST) X-Received: by 2002:a50:d555:0:b0:540:b0ec:bcd5 with SMTP id f21-20020a50d555000000b00540b0ecbcd5mr357590edj.15.1699410439971; Tue, 07 Nov 2023 18:27:19 -0800 (PST) Received: from cassiopeiae.. ([2a02:810d:4b3f:de9c:642:1aff:fe31:a19f]) by smtp.gmail.com with ESMTPSA id m6-20020a50ef06000000b00543525d9fddsm5922217eds.21.2023.11.07.18.27.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Nov 2023 18:27:19 -0800 (PST) From: Danilo Krummrich <dakr@redhat.com> To: airlied@gmail.com, daniel@ffwll.ch, christian.koenig@amd.com, luben.tuikov@amd.com Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, Danilo Krummrich <dakr@redhat.com> Subject: [PATCH] drm/sched: fix potential page fault in drm_sched_job_init() Date: Wed, 8 Nov 2023 03:26:07 +0100 Message-ID: <20231108022716.15250-1-dakr@redhat.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (groat.vger.email [0.0.0.0]); Tue, 07 Nov 2023 18:28:24 -0800 (PST) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on groat.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1781961071573959838 X-GMAIL-MSGID: 1781961071573959838 |
Series |
drm/sched: fix potential page fault in drm_sched_job_init()
|
|
Commit Message
Danilo Krummrich
Nov. 8, 2023, 2:26 a.m. UTC
Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable
number of run-queues") introduces drm_err() in drm_sched_job_init(), in
order to indicate that the given entity has no runq, however at this
time job->sched is not yet set, likely to be NULL initialized, and hence
shouldn't be used.
Replace the corresponding drm_err() call with pr_err() to avoid a
potential page fault.
While at it, extend the documentation of drm_sched_job_init() to
indicate that job->sched is not a valid pointer until
drm_sched_job_arm() has been called.
Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues")
Signed-off-by: Danilo Krummrich <dakr@redhat.com>
---
drivers/gpu/drm/scheduler/sched_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
base-commit: c015fb6d01adb616fb54824feb55ce5ab18e8ca1
Comments
Hi, Could you please use my gmail address, the one one I'm responding from--I don't want to miss any DRM scheduler patches. BTW, the luben.tuikov@amd.com email should bounce as undeliverable. On 2023-11-07 21:26, Danilo Krummrich wrote: > Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable > number of run-queues") introduces drm_err() in drm_sched_job_init(), in > order to indicate that the given entity has no runq, however at this > time job->sched is not yet set, likely to be NULL initialized, and hence > shouldn't be used. > > Replace the corresponding drm_err() call with pr_err() to avoid a > potential page fault. > > While at it, extend the documentation of drm_sched_job_init() to > indicate that job->sched is not a valid pointer until > drm_sched_job_arm() has been called. > > Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") > Signed-off-by: Danilo Krummrich <dakr@redhat.com> > --- > drivers/gpu/drm/scheduler/sched_main.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c > index 27843e37d9b7..dd28389f0ddd 100644 > --- a/drivers/gpu/drm/scheduler/sched_main.c > +++ b/drivers/gpu/drm/scheduler/sched_main.c > @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); > * This function returns -ENOENT in this case (which probably should be -EIO as > * a more meanigful return value). > * > + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has > + * been called. > + * Good catch! Did you actually get this to page-fault and have a kernel log? I'm asking because we see it correctly set in this kernel log coming from AMD, [ 11.886024] amdgpu 0000:0a:00.0: [drm] *ERROR* drm_sched_job_init: entity has no rq! in this email, https://lore.kernel.org/r/CADnq5_PS64jYS_Y3kGW27m-kuWP+FQFiaVcOaZiB=JLSgPnXBQ@mail.gmail.com > * Returns 0 for success, negative error code otherwise. > */ > int drm_sched_job_init(struct drm_sched_job *job, > @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, > * or worse--a blank screen--leave a trail in the > * logs, so this can be debugged easier. > */ > - drm_err(job->sched, "%s: entity has no rq!\n", __func__); > + pr_err("%s: entity has no rq!\n", __func__); Is it feasible to do something like the following? dev_err(job->sched ? job->sched->dev : NULL, "%s: entity has no rq!\n", __func__); > return -ENOENT; > } > > > base-commit: c015fb6d01adb616fb54824feb55ce5ab18e8ca1
On 2023-11-08 00:46, Luben Tuikov wrote: > Hi, > > Could you please use my gmail address, the one one I'm responding from--I don't want > to miss any DRM scheduler patches. BTW, the luben.tuikov@amd.com email should bounce > as undeliverable. > > On 2023-11-07 21:26, Danilo Krummrich wrote: >> Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable >> number of run-queues") introduces drm_err() in drm_sched_job_init(), in >> order to indicate that the given entity has no runq, however at this >> time job->sched is not yet set, likely to be NULL initialized, and hence >> shouldn't be used. >> >> Replace the corresponding drm_err() call with pr_err() to avoid a >> potential page fault. >> >> While at it, extend the documentation of drm_sched_job_init() to >> indicate that job->sched is not a valid pointer until >> drm_sched_job_arm() has been called. >> >> Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") >> Signed-off-by: Danilo Krummrich <dakr@redhat.com> >> --- >> drivers/gpu/drm/scheduler/sched_main.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >> index 27843e37d9b7..dd28389f0ddd 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); >> * This function returns -ENOENT in this case (which probably should be -EIO as >> * a more meanigful return value). >> * >> + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has >> + * been called. >> + * > > Good catch! > > Did you actually get this to page-fault and have a kernel log? > > I'm asking because we see it correctly set in this kernel log coming from AMD, > > [ 11.886024] amdgpu 0000:0a:00.0: [drm] *ERROR* drm_sched_job_init: entity has no rq! > > in this email, > https://lore.kernel.org/r/CADnq5_PS64jYS_Y3kGW27m-kuWP+FQFiaVcOaZiB=JLSgPnXBQ@mail.gmail.com > >> * Returns 0 for success, negative error code otherwise. >> */ >> int drm_sched_job_init(struct drm_sched_job *job, >> @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, >> * or worse--a blank screen--leave a trail in the >> * logs, so this can be debugged easier. >> */ >> - drm_err(job->sched, "%s: entity has no rq!\n", __func__); >> + pr_err("%s: entity has no rq!\n", __func__); > > Is it feasible to do something like the following? > > dev_err(job->sched ? job->sched->dev : NULL, "%s: entity has no rq!\n", __func__); Sorry, that was meant to be like this to make the print look just like the original, dev_err(job->sched ? job->sched->dev : NULL, "[drm] *ERROR* %s: entity has no rq!\n", __func__); > >> return -ENOENT; >> } >> >> >> base-commit: c015fb6d01adb616fb54824feb55ce5ab18e8ca1 >
On 11/8/23 06:46, Luben Tuikov wrote: > Hi, > > Could you please use my gmail address, the one one I'm responding from--I don't want > to miss any DRM scheduler patches. BTW, the luben.tuikov@amd.com email should bounce > as undeliverable. > > On 2023-11-07 21:26, Danilo Krummrich wrote: >> Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable >> number of run-queues") introduces drm_err() in drm_sched_job_init(), in >> order to indicate that the given entity has no runq, however at this >> time job->sched is not yet set, likely to be NULL initialized, and hence >> shouldn't be used. >> >> Replace the corresponding drm_err() call with pr_err() to avoid a >> potential page fault. >> >> While at it, extend the documentation of drm_sched_job_init() to >> indicate that job->sched is not a valid pointer until >> drm_sched_job_arm() has been called. >> >> Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") >> Signed-off-by: Danilo Krummrich <dakr@redhat.com> >> --- >> drivers/gpu/drm/scheduler/sched_main.c | 5 ++++- >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >> index 27843e37d9b7..dd28389f0ddd 100644 >> --- a/drivers/gpu/drm/scheduler/sched_main.c >> +++ b/drivers/gpu/drm/scheduler/sched_main.c >> @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); >> * This function returns -ENOENT in this case (which probably should be -EIO as >> * a more meanigful return value). >> * >> + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has >> + * been called. >> + * > > Good catch! > > Did you actually get this to page-fault and have a kernel log? No, I just found it because I was about to make the same mistake. > > I'm asking because we see it correctly set in this kernel log coming from AMD, I think that's because amdgpu just sets job->sched to *some* scheduler instance after job allocation [1]. [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L108 > > [ 11.886024] amdgpu 0000:0a:00.0: [drm] *ERROR* drm_sched_job_init: entity has no rq! > > in this email, > https://lore.kernel.org/r/CADnq5_PS64jYS_Y3kGW27m-kuWP+FQFiaVcOaZiB=JLSgPnXBQ@mail.gmail.com > >> * Returns 0 for success, negative error code otherwise. >> */ >> int drm_sched_job_init(struct drm_sched_job *job, >> @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, >> * or worse--a blank screen--leave a trail in the >> * logs, so this can be debugged easier. >> */ >> - drm_err(job->sched, "%s: entity has no rq!\n", __func__); >> + pr_err("%s: entity has no rq!\n", __func__); > > Is it feasible to do something like the following? > > dev_err(job->sched ? job->sched->dev : NULL, "%s: entity has no rq!\n", __func__); I don't think that's a good idea. Although I'd assume that every driver zero-initializes its job structures, I can't see a rule enforcing that. Hence, job->sched can be a random value until drm_sched_job_arm() is called. However, I notice there are quite a view more fields of struct drm_sched_job that are never initialized, hence there are either a couple more potential bugs or missing documentation that drivers *must* ensure that a job is zero-initialized. Not quite sure if we really want to rely on the latter for core infrastructure... > >> return -ENOENT; >> } >> >> >> base-commit: c015fb6d01adb616fb54824feb55ce5ab18e8ca1 >
On 2023-11-08 19:09, Danilo Krummrich wrote: > On 11/8/23 06:46, Luben Tuikov wrote: >> Hi, >> >> Could you please use my gmail address, the one one I'm responding from--I don't want >> to miss any DRM scheduler patches. BTW, the luben.tuikov@amd.com email should bounce >> as undeliverable. >> >> On 2023-11-07 21:26, Danilo Krummrich wrote: >>> Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable >>> number of run-queues") introduces drm_err() in drm_sched_job_init(), in >>> order to indicate that the given entity has no runq, however at this >>> time job->sched is not yet set, likely to be NULL initialized, and hence >>> shouldn't be used. >>> >>> Replace the corresponding drm_err() call with pr_err() to avoid a >>> potential page fault. >>> >>> While at it, extend the documentation of drm_sched_job_init() to >>> indicate that job->sched is not a valid pointer until >>> drm_sched_job_arm() has been called. >>> >>> Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") >>> Signed-off-by: Danilo Krummrich <dakr@redhat.com> >>> --- >>> drivers/gpu/drm/scheduler/sched_main.c | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >>> index 27843e37d9b7..dd28389f0ddd 100644 >>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>> @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); >>> * This function returns -ENOENT in this case (which probably should be -EIO as >>> * a more meanigful return value). >>> * >>> + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has >>> + * been called. >>> + * >> >> Good catch! >> >> Did you actually get this to page-fault and have a kernel log? > > No, I just found it because I was about to make the same mistake. > >> >> I'm asking because we see it correctly set in this kernel log coming from AMD, > > I think that's because amdgpu just sets job->sched to *some* scheduler instance after > job allocation [1]. > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L108 > >> >> [ 11.886024] amdgpu 0000:0a:00.0: [drm] *ERROR* drm_sched_job_init: entity has no rq! >> >> in this email, >> https://lore.kernel.org/r/CADnq5_PS64jYS_Y3kGW27m-kuWP+FQFiaVcOaZiB=JLSgPnXBQ@mail.gmail.com >> >>> * Returns 0 for success, negative error code otherwise. >>> */ >>> int drm_sched_job_init(struct drm_sched_job *job, >>> @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, >>> * or worse--a blank screen--leave a trail in the >>> * logs, so this can be debugged easier. >>> */ >>> - drm_err(job->sched, "%s: entity has no rq!\n", __func__); >>> + pr_err("%s: entity has no rq!\n", __func__); >> >> Is it feasible to do something like the following? >> >> dev_err(job->sched ? job->sched->dev : NULL, "%s: entity has no rq!\n", __func__); > > I don't think that's a good idea. Although I'd assume that every driver zero-initializes its job > structures, I can't see a rule enforcing that. Hence, job->sched can be a random value until > drm_sched_job_arm() is called. Okay. However, when using pr_err() we're losing "[drm] *ERROR* " prefix and we scan for that in the logs to quickly find the cause of the error. Perhaps we can define pr_fmt() and also include "*ERROR*" so that we can get the desired result as the attached patch shows?
On 11/9/23 05:23, Luben Tuikov wrote: > On 2023-11-08 19:09, Danilo Krummrich wrote: >> On 11/8/23 06:46, Luben Tuikov wrote: >>> Hi, >>> >>> Could you please use my gmail address, the one one I'm responding from--I don't want >>> to miss any DRM scheduler patches. BTW, the luben.tuikov@amd.com email should bounce >>> as undeliverable. >>> >>> On 2023-11-07 21:26, Danilo Krummrich wrote: >>>> Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable >>>> number of run-queues") introduces drm_err() in drm_sched_job_init(), in >>>> order to indicate that the given entity has no runq, however at this >>>> time job->sched is not yet set, likely to be NULL initialized, and hence >>>> shouldn't be used. >>>> >>>> Replace the corresponding drm_err() call with pr_err() to avoid a >>>> potential page fault. >>>> >>>> While at it, extend the documentation of drm_sched_job_init() to >>>> indicate that job->sched is not a valid pointer until >>>> drm_sched_job_arm() has been called. >>>> >>>> Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") >>>> Signed-off-by: Danilo Krummrich <dakr@redhat.com> >>>> --- >>>> drivers/gpu/drm/scheduler/sched_main.c | 5 ++++- >>>> 1 file changed, 4 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >>>> index 27843e37d9b7..dd28389f0ddd 100644 >>>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>>> @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); >>>> * This function returns -ENOENT in this case (which probably should be -EIO as >>>> * a more meanigful return value). >>>> * >>>> + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has >>>> + * been called. >>>> + * >>> >>> Good catch! >>> >>> Did you actually get this to page-fault and have a kernel log? >> >> No, I just found it because I was about to make the same mistake. >> >>> >>> I'm asking because we see it correctly set in this kernel log coming from AMD, >> >> I think that's because amdgpu just sets job->sched to *some* scheduler instance after >> job allocation [1]. >> >> [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L108 >> >>> >>> [ 11.886024] amdgpu 0000:0a:00.0: [drm] *ERROR* drm_sched_job_init: entity has no rq! >>> >>> in this email, >>> https://lore.kernel.org/r/CADnq5_PS64jYS_Y3kGW27m-kuWP+FQFiaVcOaZiB=JLSgPnXBQ@mail.gmail.com >>> >>>> * Returns 0 for success, negative error code otherwise. >>>> */ >>>> int drm_sched_job_init(struct drm_sched_job *job, >>>> @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, >>>> * or worse--a blank screen--leave a trail in the >>>> * logs, so this can be debugged easier. >>>> */ >>>> - drm_err(job->sched, "%s: entity has no rq!\n", __func__); >>>> + pr_err("%s: entity has no rq!\n", __func__); >>> >>> Is it feasible to do something like the following? >>> >>> dev_err(job->sched ? job->sched->dev : NULL, "%s: entity has no rq!\n", __func__); >> >> I don't think that's a good idea. Although I'd assume that every driver zero-initializes its job >> structures, I can't see a rule enforcing that. Hence, job->sched can be a random value until >> drm_sched_job_arm() is called. > > Okay. However, when using pr_err() we're losing "[drm] *ERROR* " prefix and we scan for that > in the logs to quickly find the cause of the error. > > Perhaps we can define pr_fmt() and also include "*ERROR*" so that we can get the desired result > as the attached patch shows? Sure, I'd add the pr_fmt() in a separate patch though.
On 11/9/23 01:09, Danilo Krummrich wrote: > On 11/8/23 06:46, Luben Tuikov wrote: >> Hi, >> >> Could you please use my gmail address, the one one I'm responding from--I don't want >> to miss any DRM scheduler patches. BTW, the luben.tuikov@amd.com email should bounce >> as undeliverable. >> >> On 2023-11-07 21:26, Danilo Krummrich wrote: >>> Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable >>> number of run-queues") introduces drm_err() in drm_sched_job_init(), in >>> order to indicate that the given entity has no runq, however at this >>> time job->sched is not yet set, likely to be NULL initialized, and hence >>> shouldn't be used. >>> >>> Replace the corresponding drm_err() call with pr_err() to avoid a >>> potential page fault. >>> >>> While at it, extend the documentation of drm_sched_job_init() to >>> indicate that job->sched is not a valid pointer until >>> drm_sched_job_arm() has been called. >>> >>> Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") >>> Signed-off-by: Danilo Krummrich <dakr@redhat.com> >>> --- >>> drivers/gpu/drm/scheduler/sched_main.c | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >>> index 27843e37d9b7..dd28389f0ddd 100644 >>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>> @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); >>> * This function returns -ENOENT in this case (which probably should be -EIO as >>> * a more meanigful return value). >>> * >>> + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has >>> + * been called. >>> + * >> >> Good catch! >> >> Did you actually get this to page-fault and have a kernel log? > > No, I just found it because I was about to make the same mistake. > >> >> I'm asking because we see it correctly set in this kernel log coming from AMD, > > I think that's because amdgpu just sets job->sched to *some* scheduler instance after > job allocation [1]. > > [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L108 > >> >> [ 11.886024] amdgpu 0000:0a:00.0: [drm] *ERROR* drm_sched_job_init: entity has no rq! >> >> in this email, >> https://lore.kernel.org/r/CADnq5_PS64jYS_Y3kGW27m-kuWP+FQFiaVcOaZiB=JLSgPnXBQ@mail.gmail.com >> >>> * Returns 0 for success, negative error code otherwise. >>> */ >>> int drm_sched_job_init(struct drm_sched_job *job, >>> @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, >>> * or worse--a blank screen--leave a trail in the >>> * logs, so this can be debugged easier. >>> */ >>> - drm_err(job->sched, "%s: entity has no rq!\n", __func__); >>> + pr_err("%s: entity has no rq!\n", __func__); >> >> Is it feasible to do something like the following? >> >> dev_err(job->sched ? job->sched->dev : NULL, "%s: entity has no rq!\n", __func__); > > I don't think that's a good idea. Although I'd assume that every driver zero-initializes its job > structures, I can't see a rule enforcing that. Hence, job->sched can be a random value until > drm_sched_job_arm() is called. > > However, I notice there are quite a view more fields of struct drm_sched_job that are never > initialized, hence there are either a couple more potential bugs or missing documentation that > drivers *must* ensure that a job is zero-initialized. Any opinions on that? Otherwise I'd probably go ahead and send a fix for the other bugs too. > > Not quite sure if we really want to rely on the latter for core infrastructure... > >> >>> return -ENOENT; >>> } >>> >>> base-commit: c015fb6d01adb616fb54824feb55ce5ab18e8ca1 >>
On 2023-11-09 14:55, Danilo Krummrich wrote: > On 11/9/23 01:09, Danilo Krummrich wrote: >> On 11/8/23 06:46, Luben Tuikov wrote: >>> Hi, >>> >>> Could you please use my gmail address, the one one I'm responding from--I don't want >>> to miss any DRM scheduler patches. BTW, the luben.tuikov@amd.com email should bounce >>> as undeliverable. >>> >>> On 2023-11-07 21:26, Danilo Krummrich wrote: >>>> Commit 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable >>>> number of run-queues") introduces drm_err() in drm_sched_job_init(), in >>>> order to indicate that the given entity has no runq, however at this >>>> time job->sched is not yet set, likely to be NULL initialized, and hence >>>> shouldn't be used. >>>> >>>> Replace the corresponding drm_err() call with pr_err() to avoid a >>>> potential page fault. >>>> >>>> While at it, extend the documentation of drm_sched_job_init() to >>>> indicate that job->sched is not a valid pointer until >>>> drm_sched_job_arm() has been called. >>>> >>>> Fixes: 56e449603f0a ("drm/sched: Convert the GPU scheduler to variable number of run-queues") >>>> Signed-off-by: Danilo Krummrich <dakr@redhat.com> >>>> --- >>>> drivers/gpu/drm/scheduler/sched_main.c | 5 ++++- >>>> 1 file changed, 4 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c >>>> index 27843e37d9b7..dd28389f0ddd 100644 >>>> --- a/drivers/gpu/drm/scheduler/sched_main.c >>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c >>>> @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); >>>> * This function returns -ENOENT in this case (which probably should be -EIO as >>>> * a more meanigful return value). >>>> * >>>> + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has >>>> + * been called. >>>> + * >>> >>> Good catch! >>> >>> Did you actually get this to page-fault and have a kernel log? >> >> No, I just found it because I was about to make the same mistake. >> >>> >>> I'm asking because we see it correctly set in this kernel log coming from AMD, >> >> I think that's because amdgpu just sets job->sched to *some* scheduler instance after >> job allocation [1]. >> >> [1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c#L108 >> >>> >>> [ 11.886024] amdgpu 0000:0a:00.0: [drm] *ERROR* drm_sched_job_init: entity has no rq! >>> >>> in this email, >>> https://lore.kernel.org/r/CADnq5_PS64jYS_Y3kGW27m-kuWP+FQFiaVcOaZiB=JLSgPnXBQ@mail.gmail.com >>> >>>> * Returns 0 for success, negative error code otherwise. >>>> */ >>>> int drm_sched_job_init(struct drm_sched_job *job, >>>> @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, >>>> * or worse--a blank screen--leave a trail in the >>>> * logs, so this can be debugged easier. >>>> */ >>>> - drm_err(job->sched, "%s: entity has no rq!\n", __func__); >>>> + pr_err("%s: entity has no rq!\n", __func__); >>> >>> Is it feasible to do something like the following? >>> >>> dev_err(job->sched ? job->sched->dev : NULL, "%s: entity has no rq!\n", __func__); >> >> I don't think that's a good idea. Although I'd assume that every driver zero-initializes its job >> structures, I can't see a rule enforcing that. Hence, job->sched can be a random value until >> drm_sched_job_arm() is called. >> >> However, I notice there are quite a view more fields of struct drm_sched_job that are never >> initialized, hence there are either a couple more potential bugs or missing documentation that >> drivers *must* ensure that a job is zero-initialized. > > Any opinions on that? Otherwise I'd probably go ahead and send a fix for the other bugs too. Send the patches. Will those patches also add pr_fmt() for DRM? I'm asking because you said you'll add pr_fmt() in a "separate" patch, and I thought it was okay being self-contained in your patch as per the version I sent.
diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c index 27843e37d9b7..dd28389f0ddd 100644 --- a/drivers/gpu/drm/scheduler/sched_main.c +++ b/drivers/gpu/drm/scheduler/sched_main.c @@ -680,6 +680,9 @@ EXPORT_SYMBOL(drm_sched_resubmit_jobs); * This function returns -ENOENT in this case (which probably should be -EIO as * a more meanigful return value). * + * Note that job->sched is not a valid pointer until drm_sched_job_arm() has + * been called. + * * Returns 0 for success, negative error code otherwise. */ int drm_sched_job_init(struct drm_sched_job *job, @@ -691,7 +694,7 @@ int drm_sched_job_init(struct drm_sched_job *job, * or worse--a blank screen--leave a trail in the * logs, so this can be debugged easier. */ - drm_err(job->sched, "%s: entity has no rq!\n", __func__); + pr_err("%s: entity has no rq!\n", __func__); return -ENOENT; }