From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Alex Williamson
<alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] amd_iommu: Fix leak in free_pagetable()
Date: Thu, 20 Jun 2013 22:04:06 +0200 [thread overview]
Message-ID: <20130620200406.GE11309@8bytes.org> (raw)
In-Reply-To: <1371757608.30572.18.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
On Thu, Jun 20, 2013 at 01:46:48PM -0600, Alex Williamson wrote:
> But that's true of a bug in any kernel code. I think the only danger
> unique to recursion is using too much stack space, but I doubt that's
> really an issue for a tiny function with a fixed depth like this. In
> case you didn't notice, I did send a recursive version along with the
> flat version, but I stupidly used the same subject for both. It's a
> little less code and a tiny bit easier to understand than the macro
> version. Up to you though.
Well, the limited kernel stack is exactly the problem for an
unterminating recursion. The size of the stack-footprint does also not
really matter in this situation, the code will overwrite random kernel
memory when the stack overflows. And that memory could potentially
contain data that is about to be written to disk and destroy file
systems.
Joerg
WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: iommu@lists.linux-foundation.org, ddutile@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] amd_iommu: Fix leak in free_pagetable()
Date: Thu, 20 Jun 2013 22:04:06 +0200 [thread overview]
Message-ID: <20130620200406.GE11309@8bytes.org> (raw)
In-Reply-To: <1371757608.30572.18.camel@ul30vt.home>
On Thu, Jun 20, 2013 at 01:46:48PM -0600, Alex Williamson wrote:
> But that's true of a bug in any kernel code. I think the only danger
> unique to recursion is using too much stack space, but I doubt that's
> really an issue for a tiny function with a fixed depth like this. In
> case you didn't notice, I did send a recursive version along with the
> flat version, but I stupidly used the same subject for both. It's a
> little less code and a tiny bit easier to understand than the macro
> version. Up to you though.
Well, the limited kernel stack is exactly the problem for an
unterminating recursion. The size of the stack-footprint does also not
really matter in this situation, the code will overwrite random kernel
memory when the stack overflows. And that memory could potentially
contain data that is about to be written to disk and destroy file
systems.
Joerg
next prev parent reply other threads:[~2013-06-20 20:04 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-18 1:48 [PATCH] amd_iommu: Fix leak in free_pagetable() Alex Williamson
2013-06-18 1:48 ` Alex Williamson
[not found] ` <20130618014459.20440.73844.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-06-18 1:52 ` Alex Williamson
2013-06-18 1:52 ` Alex Williamson
[not found] ` <20130618015116.20711.90269.stgit-xdHQ/5r00wBBDLzU/O5InQ@public.gmane.org>
2013-06-20 18:28 ` Joerg Roedel
2013-06-20 18:28 ` Joerg Roedel
[not found] ` <20130620182808.GC11309-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2013-06-20 19:08 ` Alex Williamson
2013-06-20 19:08 ` Alex Williamson
[not found] ` <1371755280.30572.4.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2013-06-20 19:26 ` Joerg Roedel
2013-06-20 19:26 ` Joerg Roedel
[not found] ` <20130620192638.GD11309-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2013-06-20 19:46 ` Alex Williamson
2013-06-20 19:46 ` Alex Williamson
[not found] ` <1371757608.30572.18.camel-85EaTFmN5p//9pzu0YdTqQ@public.gmane.org>
2013-06-20 20:04 ` Joerg Roedel [this message]
2013-06-20 20:04 ` Joerg Roedel
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=20130620200406.GE11309@8bytes.org \
--to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
--cc=alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@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.