diff for duplicates of <1364953950.8690.4@snotra> diff --git a/a/1.txt b/N1/1.txt index 1c3f6a8..c34d4c4 100644 --- a/a/1.txt +++ b/N1/1.txt @@ -1,33 +1,33 @@ On 04/02/2013 08:35:54 PM, Timur Tabi wrote: -> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote: -> +> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro@8bytes.org> wrote: +>=20 > > > + panic("\n"); > > > > A kernel panic seems like an over-reaction to an access violation. -> +>=20 > We have no way to determining what code caused the violation, so we > can't just kill the process. I agree it seems like overkill, but what > else should we do? Does the IOMMU layer have a way for the IOMMU > driver to stop the device that caused the problem? -At a minimum, log a message and continue. Probably turn off the LIODN, -at least if it continues to be noisy (otherwise we could get stuck in -an interrupt storm as you note). Possibly let the user know somehow, +At a minimum, log a message and continue. Probably turn off the LIODN, =20 +at least if it continues to be noisy (otherwise we could get stuck in =20 +an interrupt storm as you note). Possibly let the user know somehow, =20 especially if it's a VFIO domain. -Don't take down the whole kernel. It's not just overkill; it +Don't take down the whole kernel. It's not just overkill; it =20 undermines VFIO's efforts to make it safe for users to control devices. > > Besides the device that caused the violation the system should still > > work, no? -> +>=20 > Not really. The PAMU was designed to add IOMMU support to legacy > devices, which have no concept of an MMU. If the PAMU detects an > access violation, there's no way for the device to recover, because it > has no idea that a violation has occurred. It's going to keep on > writing to bad data. -I think that's only the case for posted writes (or devices which fail +I think that's only the case for posted writes (or devices which fail =20 to take a hint and stop even after they see an I/O error). --Scott +-Scott= diff --git a/a/content_digest b/N1/content_digest index e707e3c..ce9bf51 100644 --- a/a/content_digest +++ b/N1/content_digest @@ -1,50 +1,48 @@ "ref\0CAOZdJXWS50mpgMYu8o8K11yQFU6y-vNwxd9zPkqSd7euGt7XQg@mail.gmail.com\0" - "ref\0CAOZdJXWS50mpgMYu8o8K11yQFU6y-vNwxd9zPkqSd7euGt7XQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org\0" - "From\0Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>\0" + "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.\0" "Date\0Tue, 2 Apr 2013 20:52:30 -0500\0" - "To\0Timur Tabi <timur-N01EOCouUvQ@public.gmane.org>\0" - "Cc\0Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>" - Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> - stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org - lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org - Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> - " linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>\0" + "To\0Timur Tabi <timur@tabi.org>\0" + "Cc\0Joerg Roedel <joro@8bytes.org>" + stuart.yoder@freescale.com + lkml <linux-kernel@vger.kernel.org> + iommu@lists.linux-foundation.org + Varun Sethi <Varun.Sethi@freescale.com> + " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 04/02/2013 08:35:54 PM, Timur Tabi wrote:\n" - "> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:\n" - "> \n" + "> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro@8bytes.org> wrote:\n" + ">=20\n" "> > > + panic(\"\\n\");\n" "> >\n" "> > A kernel panic seems like an over-reaction to an access violation.\n" - "> \n" + ">=20\n" "> We have no way to determining what code caused the violation, so we\n" "> can't just kill the process. I agree it seems like overkill, but what\n" "> else should we do? Does the IOMMU layer have a way for the IOMMU\n" "> driver to stop the device that caused the problem?\n" "\n" - "At a minimum, log a message and continue. Probably turn off the LIODN, \n" - "at least if it continues to be noisy (otherwise we could get stuck in \n" - "an interrupt storm as you note). Possibly let the user know somehow, \n" + "At a minimum, log a message and continue. Probably turn off the LIODN, =20\n" + "at least if it continues to be noisy (otherwise we could get stuck in =20\n" + "an interrupt storm as you note). Possibly let the user know somehow, =20\n" "especially if it's a VFIO domain.\n" "\n" - "Don't take down the whole kernel. It's not just overkill; it \n" + "Don't take down the whole kernel. It's not just overkill; it =20\n" "undermines VFIO's efforts to make it safe for users to control devices.\n" "\n" "> > Besides the device that caused the violation the system should still\n" "> > work, no?\n" - "> \n" + ">=20\n" "> Not really. The PAMU was designed to add IOMMU support to legacy\n" "> devices, which have no concept of an MMU. If the PAMU detects an\n" "> access violation, there's no way for the device to recover, because it\n" "> has no idea that a violation has occurred. It's going to keep on\n" "> writing to bad data.\n" "\n" - "I think that's only the case for posted writes (or devices which fail \n" + "I think that's only the case for posted writes (or devices which fail =20\n" "to take a hint and stop even after they see an I/O error).\n" "\n" - -Scott + -Scott= -77bc1fade953105283ff8228cc213586eab54f1c65963c27ea06d1bd6dca40fe +bee0238f799f97be31ac4d1c12e7ef2c892d4563e1d6bd677c76af0e70b219d7
diff --git a/a/1.txt b/N2/1.txt index 1c3f6a8..57d3514 100644 --- a/a/1.txt +++ b/N2/1.txt @@ -1,5 +1,5 @@ On 04/02/2013 08:35:54 PM, Timur Tabi wrote: -> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote: +> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro@8bytes.org> wrote: > > > > + panic("\n"); > > diff --git a/a/content_digest b/N2/content_digest index e707e3c..f186300 100644 --- a/a/content_digest +++ b/N2/content_digest @@ -1,20 +1,20 @@ "ref\0CAOZdJXWS50mpgMYu8o8K11yQFU6y-vNwxd9zPkqSd7euGt7XQg@mail.gmail.com\0" - "ref\0CAOZdJXWS50mpgMYu8o8K11yQFU6y-vNwxd9zPkqSd7euGt7XQg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org\0" - "From\0Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>\0" + "From\0Scott Wood <scottwood@freescale.com>\0" "Subject\0Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu implementation.\0" "Date\0Tue, 2 Apr 2013 20:52:30 -0500\0" - "To\0Timur Tabi <timur-N01EOCouUvQ@public.gmane.org>\0" - "Cc\0Kumar Gala <galak-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>" - Benjamin Herrenschmidt <benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> - stuart.yoder-KZfg59tc24xl57MIdRCFDg@public.gmane.org - lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> - iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org - Varun Sethi <Varun.Sethi-KZfg59tc24xl57MIdRCFDg@public.gmane.org> - " linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org <linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org>\0" + "To\0Timur Tabi <timur@tabi.org>\0" + "Cc\0Joerg Roedel <joro@8bytes.org>" + Varun Sethi <Varun.Sethi@freescale.com> + lkml <linux-kernel@vger.kernel.org> + Kumar Gala <galak@kernel.crashing.org> + <stuart.yoder@freescale.com> + <iommu@lists.linux-foundation.org> + Benjamin Herrenschmidt <benh@kernel.crashing.org> + " linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>\0" "\00:1\0" "b\0" "On 04/02/2013 08:35:54 PM, Timur Tabi wrote:\n" - "> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:\n" + "> On Tue, Apr 2, 2013 at 11:18 AM, Joerg Roedel <joro@8bytes.org> wrote:\n" "> \n" "> > > + panic(\"\\n\");\n" "> >\n" @@ -47,4 +47,4 @@ "\n" -Scott -77bc1fade953105283ff8228cc213586eab54f1c65963c27ea06d1bd6dca40fe +cd12a4cc3641e6b6d315d61b6748ac3f80299c6b54e956de5f64234e498d590c
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.