From: Matthew Brost <matthew.brost@intel.com>
To: Arnd Bergmann <arnd@kernel.org>
Cc: "Lucas De Marchi" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Jonathan Cavitt" <jonathan.cavitt@intel.com>,
"Arnd Bergmann" <arnd@arndb.de>,
"John Harrison" <John.C.Harrison@intel.com>,
"José Roberto de Souza" <jose.souza@intel.com>,
"Zhanjun Dong" <zhanjun.dong@intel.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/xe: fix devcoredump chunk alignmnent calculation
Date: Tue, 29 Apr 2025 10:55:03 -0700 [thread overview]
Message-ID: <aBESdxYMh4lrdasm@lstrano-desk.jf.intel.com> (raw)
In-Reply-To: <aBERlisb42uGjZ8j@lstrano-desk.jf.intel.com>
On Tue, Apr 29, 2025 at 10:51:18AM -0700, Matthew Brost wrote:
> On Tue, Apr 29, 2025 at 09:34:00AM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann <arnd@arndb.de>
> >
> > The device core dumps are copied in 1.5GB chunks, which leads to a
> > link-time error on 32-bit builds because of the 64-bit division not
> > getting trivially turned into mask and shift operations:
> >
> > ERROR: modpost: "__moddi3" [drivers/gpu/drm/xe/xe.ko] undefined!
> >
> > On top of this, I noticed that the ALIGN_DOWN() usage here cannot
> > work because that is only defined for power-of-two alignments.
> > Change ALIGN_DOWN into an explicit div_u64_rem() that avoids the
> > link error and hopefully produces the right results.
> >
> > Doing a 1.5GB kvmalloc() does seem a bit suspicious as well, e.g.
> > this will clearly fail on any 32-bit platform and is also likely
> > to run out of memory on 64-bit systems under memory pressure, so
> > using a much smaller power-of-two chunk size might be a good idea
> > instead.
> >
> > Fixes: c4a2e5f865b7 ("drm/xe: Add devcoredump chunking")
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> Thanks for the fix, I had similar one [1] but I missed issue with
> ALIGN_DOWN.
>
> [1] https://patchwork.freedesktop.org/series/148301/
>
> > ---
> > Please test this with multi-gigabyte buffers, the original code
> > was clearly not right, but I don't trust my version either.
>
> This was tested on 64-bit only. I do see an issue with this version
> though. Inline below.
>
Oh, yea wrt the ALIGN_DOWN we'd be reading the wrong data. We have WIP
to replay hangs on the GPU and this would break the tool. Good catch.
Matt
> > ---
> > drivers/gpu/drm/xe/xe_devcoredump.c | 9 +++++----
> > 1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_devcoredump.c b/drivers/gpu/drm/xe/xe_devcoredump.c
> > index a9e618abf8ac..4eb70e2d9f68 100644
> > --- a/drivers/gpu/drm/xe/xe_devcoredump.c
> > +++ b/drivers/gpu/drm/xe/xe_devcoredump.c
> > @@ -177,6 +177,7 @@ static ssize_t xe_devcoredump_read(char *buffer, loff_t offset,
> > struct xe_devcoredump *coredump = data;
> > struct xe_devcoredump_snapshot *ss;
> > ssize_t byte_copied;
> > + u32 chunk_offset;
> >
> > if (!coredump)
> > return -ENODEV;
> > @@ -203,8 +204,9 @@ static ssize_t xe_devcoredump_read(char *buffer, loff_t offset,
> >
> > if (offset >= ss->read.chunk_position + XE_DEVCOREDUMP_CHUNK_MAX ||
> > offset < ss->read.chunk_position) {
> > - ss->read.chunk_position =
> > - ALIGN_DOWN(offset, XE_DEVCOREDUMP_CHUNK_MAX);
> > + ss->read.chunk_position = div_u64_rem(offset,
> > + XE_DEVCOREDUMP_CHUNK_MAX, &chunk_offset)
> > + * XE_DEVCOREDUMP_CHUNK_MAX;
> >
> > __xe_devcoredump_read(ss->read.buffer,
> > XE_DEVCOREDUMP_CHUNK_MAX,
> > @@ -213,8 +215,7 @@ static ssize_t xe_devcoredump_read(char *buffer, loff_t offset,
> >
> > byte_copied = count < ss->read.size - offset ? count :
> > ss->read.size - offset;
> > - memcpy(buffer, ss->read.buffer +
> > - (offset % XE_DEVCOREDUMP_CHUNK_MAX), byte_copied);
> > + memcpy(buffer, ss->read.buffer + chunk_offset, byte_copied);
>
> chunk_offset is unset unless a new devcoredump is read which is every
> 1.5 GB. You will need always call div_u64_rem outside of the above if
> statement.
>
> Matt
>
> >
> > mutex_unlock(&coredump->lock);
> >
> > --
> > 2.39.5
> >
next prev parent reply other threads:[~2025-04-29 17:54 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 7:34 [PATCH] drm/xe: fix devcoredump chunk alignmnent calculation Arnd Bergmann
2025-04-29 8:13 ` ✓ CI.Patch_applied: success for " Patchwork
2025-04-29 8:13 ` ✗ CI.checkpatch: warning " Patchwork
2025-04-29 8:14 ` ✓ CI.KUnit: success " Patchwork
2025-04-29 8:31 ` ✓ CI.Build: " Patchwork
2025-04-29 8:34 ` ✓ CI.Hooks: " Patchwork
2025-04-29 8:38 ` ✓ CI.checksparse: " Patchwork
2025-04-29 10:19 ` ✗ Xe.CI.Full: failure " Patchwork
2025-04-29 17:51 ` [PATCH] " Matthew Brost
2025-04-29 17:55 ` Matthew Brost [this message]
2025-05-06 7:14 ` ✗ Xe.CI.BAT: failure for " Patchwork
2025-05-06 7:49 ` Patchwork
2025-05-07 7:07 ` [PATCH] " kernel test robot
2025-05-07 18:10 ` kernel test robot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBESdxYMh4lrdasm@lstrano-desk.jf.intel.com \
--to=matthew.brost@intel.com \
--cc=John.C.Harrison@intel.com \
--cc=airlied@gmail.com \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jonathan.cavitt@intel.com \
--cc=jose.souza@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=zhanjun.dong@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.