From: Greg KH <greg@kroah.com>
To: Bibek Kumar Patro <quic_bibekkum@quicinc.com>
Cc: "Isaac J. Manjarres" <isaacmanjarres@google.com>,
stable@vger.kernel.org, Joerg Roedel <joro@8bytes.org>,
Will Deacon <will@kernel.org>,
Lu Baolu <baolu.lu@linux.intel.com>, Tom Murphy <murphyt7@tcd.ie>,
Saravana Kannan <saravanak@google.com>,
Joerg Roedel <jroedel@suse.de>,
kernel-team@android.com, iommu@lists.linux-foundation.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5.15.y] iommu/dma: Trace bounce buffer usage when mapping buffers
Date: Thu, 13 Jun 2024 13:15:27 +0200 [thread overview]
Message-ID: <2024061311-washable-ranch-abc5@gregkh> (raw)
In-Reply-To: <ZmrKZYJ0+z3mRZXx@hu-bibekkum-hyd.qualcomm.com>
On Thu, Jun 13, 2024 at 04:01:01PM +0530, Bibek Kumar Patro wrote:
> On Mon, Jan 22, 2024 at 12:37:54PM -0800, Isaac J. Manjarres wrote:
> > When commit 82612d66d51d ("iommu: Allow the dma-iommu api to
> > use bounce buffers") was introduced, it did not add the logic
> > for tracing the bounce buffer usage from iommu_dma_map_page().
> >
> > All of the users of swiotlb_tbl_map_single() trace their bounce
> > buffer usage, except iommu_dma_map_page(). This makes it difficult
> > to track SWIOTLB usage from that function. Thus, trace bounce buffer
> > usage from iommu_dma_map_page().
> >
> > Fixes: 82612d66d51d ("iommu: Allow the dma-iommu api to use bounce buffers")
> > Cc: stable@vger.kernel.org # v5.15+
> > Cc: Tom Murphy <murphyt7@tcd.ie>
> > Cc: Lu Baolu <baolu.lu@linux.intel.com>
> > Cc: Saravana Kannan <saravanak@google.com>
> > Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
> > Link: https://lore.kernel.org/r/20231208234141.2356157-1-isaacmanjarres@google.com
> > Signed-off-by: Joerg Roedel <jroedel@suse.de>
> > (cherry picked from commit a63c357b9fd56ad5fe64616f5b22835252c6a76a)
> > Signed-off-by: Isaac J. Manjarres <isaacmanjarres@google.com>
> > ---
> > drivers/iommu/dma-iommu.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 48c6f7ff4aef..8cd63e6ccd2c 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -25,6 +25,7 @@
> > #include <linux/vmalloc.h>
> > #include <linux/crash_dump.h>
> > #include <linux/dma-direct.h>
> > +#include <trace/events/swiotlb.h>
> >
> > struct iommu_dma_msi_page {
> > struct list_head list;
> > @@ -817,6 +818,8 @@ static dma_addr_t iommu_dma_map_page(struct device *dev, struct page *page,
> > void *padding_start;
> > size_t padding_size, aligned_size;
> >
> > + trace_swiotlb_bounced(dev, phys, size, swiotlb_force);
> > +
>
> Hi, this backported patch trying to access swiotlb_force variable is
> causing a build conflict where CONFIG_SWIOTLB is not enabled.
>
> In file included from kernel/drivers/iommu/dma-iommu.c:28:
> kernel/include/trace/events/swiotlb.h:15:9: error: declaration of 'enum SWIOTLB_NO_FORCE' will not be visible outside of this function [-Werror,-Wvisibility]
> enum swiotlb_force swiotlb_force),
> ^
> kernel/include/linux/swiotlb.h:143:23: note: expanded from macro 'swiotlb_force'
> #define swiotlb_force SWIOTLB_NO_FORCE
> ^
> In file included from kernel/drivers/iommu/dma-iommu.c:28:
> kernel/include/trace/events/swiotlb.h:15:9: error: declaration of 'enum SWIOTLB_NO_FORCE' will not be visible outside of this function [-Werror,-Wvisibility]
> kernel/include/linux/swiotlb.h:143:23: note: expanded from macro 'swiotlb_force'
> #define swiotlb_force SWIOTLB_NO_FORCE
> ^
> In file included from kernel/drivers/iommu/dma-iommu.c:28:
> kernel/include/trace/events/swiotlb.h:15:9: error: declaration of 'enum SWIOTLB_NO_FORCE' will not be visible outside of this function [-Werror,-Wvisibility]
> kernel/include/linux/swiotlb.h:143:23: note: expanded from macro 'swiotlb_force'
> #define swiotlb_force SWIOTLB_NO_FORCE
> ^
> In file included from kernel/drivers/iommu/dma-iommu.c:28:
> kernel/include/trace/events/swiotlb.h:15:9: error: declaration of 'enum SWIOTLB_NO_FORCE' will not be visible outside of this function [-Werror,-Wvisibility]
> kernel/include/linux/swiotlb.h:143:23: note: expanded from macro 'swiotlb_force'
> #define swiotlb_force SWIOTLB_NO_FORCE
> ^
> kernel/drivers/iommu/dma-iommu.c:865:42: error: argument type 'enum SWIOTLB_NO_FORCE' is incomplete
> trace_swiotlb_bounced(dev, phys, size, swiotlb_force);
> ^~~~~~~~~~~~~
> kernel/include/linux/swiotlb.h:143:23: note: expanded from macro 'swiotlb_force'
> #define swiotlb_force SWIOTLB_NO_FORCE
> ^~~~~~~~~~~~~~~~
> kernel/include/trace/events/swiotlb.h:15:9: note: forward declaration of 'enum SWIOTLB_NO_FORCE'
> enum swiotlb_force swiotlb_force),
> ^
> kernel/include/linux/swiotlb.h:143:23: note: expanded from macro 'swiotlb_force'
> #define swiotlb_force SWIOTLB_NO_FORCE
>
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> I have a simple proposed fix which can resolve this compile time conflict when CONFIG_SWIOTLB is disabled.
>
> --- a/include/trace/events/swiotlb.h
> +++ b/include/trace/events/swiotlb.h
> @@ -7,6 +7,7 @@
>
> #include <linux/tracepoint.h>
>
> +#ifdef CONFIG_SWIOTLB
> TRACE_EVENT(swiotlb_bounced,
>
> TP_PROTO(struct device *dev,
> @@ -43,6 +44,9 @@ TRACE_EVENT(swiotlb_bounced,
> { SWIOTLB_FORCE, "FORCE" },
> { SWIOTLB_NO_FORCE, "NO_FORCE" }))
> );
> +#else
> +#define trace_swiotlb_bounced(dev, phys, size, swiotlb_force)
> +#endif /* CONFIG_SWIOTLB */
>
> #endif /* _TRACE_SWIOTLB_H */
>
>
Why not just take whatever change upstream fixes this instead of a
one-off change?
thanks
greg k-h
next prev parent reply other threads:[~2024-06-13 11:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-22 19:59 FAILED: patch "[PATCH] iommu/dma: Trace bounce buffer usage when mapping buffers" failed to apply to 5.15-stable tree gregkh
2024-01-22 20:37 ` [PATCH 5.15.y] iommu/dma: Trace bounce buffer usage when mapping buffers Isaac J. Manjarres
2024-01-22 20:44 ` Greg KH
2024-06-13 10:31 ` Bibek Kumar Patro
2024-06-13 11:15 ` Greg KH [this message]
2024-06-13 17:40 ` Bibek Kumar Patro
2024-06-14 5:18 ` Greg KH
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=2024061311-washable-ranch-abc5@gregkh \
--to=greg@kroah.com \
--cc=baolu.lu@linux.intel.com \
--cc=iommu@lists.linux-foundation.org \
--cc=iommu@lists.linux.dev \
--cc=isaacmanjarres@google.com \
--cc=joro@8bytes.org \
--cc=jroedel@suse.de \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=murphyt7@tcd.ie \
--cc=quic_bibekkum@quicinc.com \
--cc=saravanak@google.com \
--cc=stable@vger.kernel.org \
--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 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.