From: Pranjal Shrivastava <praan@google.com>
To: Lin Ruifeng <linruifeng4@huawei.com>
Cc: joro@8bytes.org, will@kernel.org, robin.murphy@arm.com,
jroedel@suse.de, iommu@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] iommu: Use dev_dbg for group handling code
Date: Tue, 7 Apr 2026 15:31:14 +0000 [thread overview]
Message-ID: <adUjQpF4okGX4n92@google.com> (raw)
In-Reply-To: <20260407130638.1920205-1-linruifeng4@huawei.com>
On Tue, Apr 07, 2026 at 09:06:38PM +0800, Lin Ruifeng wrote:
> When devices are frequently registered/unregistered, there will be a large
> number of iommu group adding/remove messages, which will flood the dmesg buffer
> and flush out other logs. For iommu group handling messages, we can use dev_dbg
> to output logs only when needed.
>
> Signed-off-by: Lin Ruifeng <linruifeng4@huawei.com>
> ---
> drivers/iommu/iommu.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index 50718ab810a4..18ceaba6cf0a 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1283,7 +1283,7 @@ static struct group_device *iommu_group_alloc_device(struct iommu_group *group,
>
> trace_add_device_to_group(group->id, dev);
>
> - dev_info(dev, "Adding to iommu group %d\n", group->id);
> + dev_dbg(dev, "Adding to iommu group %d\n", group->id);
>
> return device;
>
> @@ -1337,7 +1337,7 @@ void iommu_group_remove_device(struct device *dev)
> if (!group)
> return;
>
> - dev_info(dev, "Removing from iommu group %d\n", group->id);
> + dev_dbg(dev, "Removing from iommu group %d\n", group->id);
>
> __iommu_group_remove_device(dev);
> }
I believe this was discussed roughly an year ago as well:
https://lore.kernel.org/linux-iommu/84cb9155-4793-45f9-bb67-6926e103dc84@arm.com/
And 5 years ago as well:
https://lore.kernel.org/linux-iommu/20200302154426.GC6540@8bytes.org/
The general consensus is that the maintainers and the community would
like to keep this log in place as it helps us debug issues just based on
dmesg logs shared over an email.
I understand that losing dmesg logs in such situations could be
frustrating but I guess you could try increasing the log buffer size..
Thanks,
Praan
prev parent reply other threads:[~2026-04-07 15:31 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-07 13:06 [PATCH] iommu: Use dev_dbg for group handling code Lin Ruifeng
2026-04-07 15:31 ` Pranjal Shrivastava [this message]
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=adUjQpF4okGX4n92@google.com \
--to=praan@google.com \
--cc=iommu@lists.linux.dev \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=linruifeng4@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox