Re: [RFC PATCH V3 06/17] ppc/pnv: allocate pe->iommu_table dynamically

On Wed, Jun 25, 2014 at 05:50:08PM +1000, Alexey Kardashevskiy wrote:

On 06/25/2014 03:27 PM, Wei Yang wrote:

quoted

On Wed, Jun 25, 2014 at 02:12:34PM +1000, Alexey Kardashevskiy wrote:

quoted

On 06/25/2014 11:12 AM, Wei Yang wrote:

quoted

On Tue, Jun 24, 2014 at 08:06:32PM +1000, Alexey Kardashevskiy wrote:

quoted

On 06/10/2014 11:56 AM, Wei Yang wrote:

quoted

Current iommu_table of a PE is a static field. This will have a problem when
iommu_free_table is called.

What kind of problem? This table is per PE and PE is not going anywhere.

Yes, for Bus PE, they will always sit in the system. When VF PE introduced,
they could be released on the fly. When they are released, so do the iommu
table for the PE.

iommu_table is a part of PE struct. When PE is released, iommu_table will
go with it as well. Why to make is a pointer? I would understand it if you
added reference counting there but no - iommu_table's lifetime is equal to
PE lifetime.

Yes, iommu_talbe's life time equals to PE lifetime, so when releasing a PE we
need to release the iommu table. Currently, there is one function to release
the iommu table, iommu_free_table() which takes a pointer of the iommu_table
and release it.

If the iommu table in PE is just a part of PE, it will have some problem to
release it with iommu_free_table(). That's why I make it a pointer in PE
structure.

So you are saying that you want to release PE by one kfree() and release
iommu_table by another kfree (embedded into iommu_free_table()). For me
that means that PE and iommu_table have different lifetime.

Hmm... it is right, the lifetime of these two may have some difference.

And I cannot find the exact place in this patchset where you call
iommu_free_table(), what do I miss?

This is called in pnv_pci_release_dev_dma(), which is introduced in the commit
cd740988: powerpc/powernv: allocate VF PE

-- 
Alexey

-- 
Richard Yang
Help you, Help me