From: Jason Gunthorpe <jgg@nvidia.com>
To: Joao Martins <joao.m.martins@oracle.com>
Cc: Mirsad Todorovac <mirsad.todorovac@alu.unizg.hr>,
iommu@lists.linux.dev, Kevin Tian <kevin.tian@intel.com>,
Shuah Khan <shuah@kernel.org>,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] seltests/iommu: runaway ./iommufd consuming 99% CPU after a failed assert()
Date: Mon, 25 Mar 2024 10:52:07 -0300 [thread overview]
Message-ID: <20240325135207.GC6245@nvidia.com> (raw)
In-Reply-To: <cdc9c46b-1bad-41cd-8f98-38cc2171186a@oracle.com>
On Mon, Mar 25, 2024 at 12:17:28PM +0000, Joao Martins wrote:
> > However, I am not smart enough to figure out why ...
> >
> > Apparently, from the source, mmap() fails to allocate pages on the desired address:
> >
> > 1746 assert((uintptr_t)self->buffer % HUGEPAGE_SIZE == 0);
> > 1747 vrc = mmap(self->buffer, variant->buffer_size, PROT_READ |
> > PROT_WRITE,
> > 1748 mmap_flags, -1, 0);
> > → 1749 assert(vrc == self->buffer);
> > 1750
> >
> > But I am not that deep into the source to figure our what was intended and what
> > went
> > wrong :-/
>
> I can SKIP() the test rather assert() in here if it helps. Though there are
> other tests that fail if no hugetlb pages are reserved.
>
> But I am not sure if this is problem here as the initial bug email had an
> enterily different set of failures? Maybe all you need is an assert() and it
> gets into this state?
I feel like there is something wrong with the kselftest framework,
there should be some way to fail the setup/teardown operations without
triggering an infinite loop :(
Jason
next prev parent reply other threads:[~2024-03-25 13:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 6:35 [BUG] seltests/iommu: runaway ./iommufd consuming 99% CPU after a failed assert() Mirsad Todorovac
2024-03-19 13:58 ` Jason Gunthorpe
2024-03-23 20:13 ` Mirsad Todorovac
2024-03-25 12:17 ` Joao Martins
2024-03-25 13:52 ` Jason Gunthorpe [this message]
2024-03-27 10:41 ` Joao Martins
2024-03-27 11:40 ` Jason Gunthorpe
2024-03-27 15:04 ` Joao Martins
2024-03-27 16:38 ` Jason Gunthorpe
2024-03-28 0:05 ` Shuah Khan
2024-04-02 11:33 ` Jason Gunthorpe
2024-03-27 20:04 ` Mirsad Todorovac
2024-03-28 13:54 ` Joao Martins
2024-04-04 16:54 ` Shuah Khan
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=20240325135207.GC6245@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=joao.m.martins@oracle.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mirsad.todorovac@alu.unizg.hr \
--cc=shuah@kernel.org \
/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.