From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Grant Grundler <grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Linux Samsung SOC
<linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Prathyush <prathyush.k-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Sachin Kamat
<sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Tomasz Figa <t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Subash Patel
<supash.ramaswamy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Linux Kernel
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux IOMMU
<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
Kukjin Kim <kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
Antonios Motakis
<a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org>,
Cho KyongHo <pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>,
kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org,
Linux ARM Kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
Rahul Sharma
<rahul.sharma-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH v9 03/16] iommu/exynos: fix page table maintenance
Date: Wed, 14 Aug 2013 12:49:38 +0200 [thread overview]
Message-ID: <20130814104938.GF4491@8bytes.org> (raw)
In-Reply-To: <CANEJEGu1ponghpfvyUsQX16+TZWUV+0KXJ7AehjXpju2N_H+Ew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Aug 08, 2013 at 11:28:44AM -0700, Grant Grundler wrote:
> I can't speak to the previous BUG_ON(). I believe the EADDRESSINUSE
> failures could be either WARN_ON or BUG_ON. This condition is
> clearly a bug in the generic IOMMU allocator and I think that's why
> KyongHo Cho used BUG_ON.
>
> Handing out duplicate addresses will generally lead to some sort of
> data corruption or other fault depending on how robust the underlying
> device drivers are written. So my preference is a BUG_ON to
> immediately flag this condition instead of hoping a device driver will
> correctly handling the dma mapping failure (Some do, most currently
> don't).
>
> WARN_ON() + return -EADDRESSINUSE would be a good alternative.
Even if it is a real BUG condition, I don't think it is worth to stop
execution at this point. It makes debugging harder and the system less
reliable. I prefer to go with the WARN_ON and an error return value.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: joro@8bytes.org (Joerg Roedel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 03/16] iommu/exynos: fix page table maintenance
Date: Wed, 14 Aug 2013 12:49:38 +0200 [thread overview]
Message-ID: <20130814104938.GF4491@8bytes.org> (raw)
In-Reply-To: <CANEJEGu1ponghpfvyUsQX16+TZWUV+0KXJ7AehjXpju2N_H+Ew@mail.gmail.com>
On Thu, Aug 08, 2013 at 11:28:44AM -0700, Grant Grundler wrote:
> I can't speak to the previous BUG_ON(). I believe the EADDRESSINUSE
> failures could be either WARN_ON or BUG_ON. This condition is
> clearly a bug in the generic IOMMU allocator and I think that's why
> KyongHo Cho used BUG_ON.
>
> Handing out duplicate addresses will generally lead to some sort of
> data corruption or other fault depending on how robust the underlying
> device drivers are written. So my preference is a BUG_ON to
> immediately flag this condition instead of hoping a device driver will
> correctly handling the dma mapping failure (Some do, most currently
> don't).
>
> WARN_ON() + return -EADDRESSINUSE would be a good alternative.
Even if it is a real BUG condition, I don't think it is worth to stop
execution at this point. It makes debugging harder and the system less
reliable. I prefer to go with the WARN_ON and an error return value.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Grant Grundler <grundler@chromium.org>
Cc: Tomasz Figa <t.figa@samsung.com>,
Cho KyongHo <pullip.cho@samsung.com>,
Linux ARM Kernel <linux-arm-kernel@lists.infradead.org>,
Linux IOMMU <iommu@lists.linux-foundation.org>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Linux Samsung SOC <linux-samsung-soc@vger.kernel.org>,
devicetree@vger.kernel.org, Kukjin Kim <kgene.kim@samsung.com>,
Prathyush <prathyush.k@samsung.com>,
Rahul Sharma <rahul.sharma@samsung.com>,
Subash Patel <supash.ramaswamy@linaro.org>,
Antonios Motakis <a.motakis@virtualopensystems.com>,
kvmarm@lists.cs.columbia.edu,
Sachin Kamat <sachin.kamat@linaro.org>
Subject: Re: [PATCH v9 03/16] iommu/exynos: fix page table maintenance
Date: Wed, 14 Aug 2013 12:49:38 +0200 [thread overview]
Message-ID: <20130814104938.GF4491@8bytes.org> (raw)
In-Reply-To: <CANEJEGu1ponghpfvyUsQX16+TZWUV+0KXJ7AehjXpju2N_H+Ew@mail.gmail.com>
On Thu, Aug 08, 2013 at 11:28:44AM -0700, Grant Grundler wrote:
> I can't speak to the previous BUG_ON(). I believe the EADDRESSINUSE
> failures could be either WARN_ON or BUG_ON. This condition is
> clearly a bug in the generic IOMMU allocator and I think that's why
> KyongHo Cho used BUG_ON.
>
> Handing out duplicate addresses will generally lead to some sort of
> data corruption or other fault depending on how robust the underlying
> device drivers are written. So my preference is a BUG_ON to
> immediately flag this condition instead of hoping a device driver will
> correctly handling the dma mapping failure (Some do, most currently
> don't).
>
> WARN_ON() + return -EADDRESSINUSE would be a good alternative.
Even if it is a real BUG condition, I don't think it is worth to stop
execution at this point. It makes debugging harder and the system less
reliable. I prefer to go with the WARN_ON and an error return value.
Joerg
next prev parent reply other threads:[~2013-08-14 10:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-08 9:37 [PATCH v9 03/16] iommu/exynos: fix page table maintenance Cho KyongHo
2013-08-08 9:37 ` Cho KyongHo
2013-08-08 9:37 ` Cho KyongHo
2013-08-08 13:54 ` Tomasz Figa
2013-08-08 13:54 ` Tomasz Figa
2013-08-08 18:28 ` Grant Grundler
2013-08-08 18:28 ` Grant Grundler
[not found] ` <CANEJEGu1ponghpfvyUsQX16+TZWUV+0KXJ7AehjXpju2N_H+Ew-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-14 10:49 ` Joerg Roedel [this message]
2013-08-14 10:49 ` Joerg Roedel
2013-08-14 10:49 ` Joerg Roedel
2013-08-14 20:54 ` Grant Grundler
2013-08-14 20:54 ` Grant Grundler
[not found] ` <CANEJEGveOtGs8XEYFnnXoZ575bqKRkc3AMikr_1x02cNikwTng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-08-16 11:17 ` Cho KyongHo
2013-08-16 11:17 ` Cho KyongHo
2013-08-16 11:17 ` Cho KyongHo
2013-08-09 4:15 ` Cho KyongHo
2013-08-09 4:15 ` Cho KyongHo
2013-08-09 4:15 ` Cho KyongHo
2013-08-09 7:47 ` Tomasz Figa
2013-08-09 7:47 ` Tomasz Figa
2013-08-09 8:33 ` Cho KyongHo
2013-08-09 8:33 ` Cho KyongHo
2013-08-09 8:33 ` Cho KyongHo
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=20130814104938.GF4491@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=a.motakis-lrHrjnjw1UfHK3s98zE1ajGjJy/sRE9J@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grundler-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=kgene.kim-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=kvmarm-FPEHb7Xf0XXUo1n7N8X6UoWGPAHP3yOg@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=prathyush.k-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=pullip.cho-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=rahul.sharma-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org \
--cc=sachin.kamat-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=supash.ramaswamy-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=t.figa-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.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.