[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100420173552.GA15669@8bytes.org>
Date: Tue, 20 Apr 2010 19:35:59 +0200
From: Joerg Roedel <joro@...tes.org>
To: Greg KH <greg@...ah.com>
Cc: Joerg Roedel <joerg.roedel@....com>,
Jesse Barnes <jbarnes@...tuousgeek.org>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: pci_get_dev_by_id() from interrupt handlers
On Tue, Apr 20, 2010 at 09:32:15AM -0700, Greg KH wrote:
> On Tue, Apr 20, 2010 at 06:04:24PM +0200, Joerg Roedel wrote:
> > Hi Jesse,
> >
> > I have a question regarding the warning in the pci_get_dev_by_id()
> > [search.c] function which triggers when called from interrupt context.
> > As far as I have seen this function should be save to be called in
> > atomic mode.
>
> Are you sure?
Not anymore. You proved me wrong ;-)
> > Is there any other reason it should not be called in interrupt
> > handlers?
>
> klist traversal is not safe to be done in interrupt context as the
> spinlock is not told to be interrupt safe. Now you could go and change
> the klist core to be interrupt safe, but you should probably rethink
> your need here first.
The idea was to capture IO page faults in the IOMMU and propagate them
to KVM instead of just printk into dmesg. KVM could do something better
then like killing the guest. Currently a malicious guest could flood
host dmesg by causing IO page faults.
For the AMD IOMMU the page faults are reported in an event log and the
cpu is informed by an interrupt about it. The event log entry contains
the bus/dev/function of the device. To get the necessary information to
propagate this to KVM I need to get the 'struct device' for it.
I could certainly do this in a tasklet instead but doing that only for
the task of converting bus/device/function into 'struct device' sounds
a bit complicated to me.
Regards,
Joerg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists