[RFI] WARNING: CPU: 0 PID: 14493 at drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()

[RFI] WARNING: CPU: 0 PID: 14493 at drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()

[Jinpu Wang]

Hi experts,

We hit warning below during test:

[13560.541562] ERROR: DMA PTE for vPFN 0xc3a00 already set (to
42834a003 not 114600083)
[13560.541696] ------------[ cut here ]------------
[13560.541701] WARNING: CPU: 0 PID: 22427 at
drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()
[13560.541702] Modules linked in: dm_snapshot dm_bufio ibnbd_server(O)
ibtrs_server(O) rdma_cm iw_cm ib_uverbs ipmi_dev
intf ib_ipoib ib_cm ib_umad loop mlx4_ib ib_sa ib_mad ib_core ib_addr
ipv6 hid_generic usbhid mlx4_core i2c_i801 ioatdm
a ehci_pci sb_edac i2c_core ehci_hcd edac_core dca ipmi_si
ipmi_msghandler button dm_mod sg e1000e
[13560.541726] CPU: 0 PID: 22427 Comm: kworker/0:0 Tainted: G
 O   3.18.21-1-storage #1
[13560.541727] Hardware name: Supermicro X9SRL-F/X9SRL-F, BIOS 3.00 07/04/2013
[13560.541730] Workqueue: ib_cm ib_destroy_cm_id [ib_cm]
[13560.541731]  0000000000000009 ffff880109213968 ffffffff815bac45
0000000000000000
[13560.541733]  0000000000000000 ffff8801092139a8 ffffffff81050d3c
ffff8801092139c8
[13560.541734]  0000000114600083 ffff88007992f0e8 0000000000000200
00000000000c3a00
[13560.541736] Call Trace:
[13560.541740]  [<ffffffff815bac45>] dump_stack+0x46/0x58
[13560.541743]  [<ffffffff81050d3c>] warn_slowpath_common+0x8c/0xc0
[13560.541744]  [<ffffffff81050d8a>] warn_slowpath_null+0x1a/0x20
[13560.541746]  [<ffffffff814fc0ad>] __domain_mapping+0x37d/0x390
[13560.541748]  [<ffffffff814fdced>] __intel_map_single+0x10d/0x1d0
[13560.541749]  [<ffffffff814fdde9>] intel_map_page+0x39/0x40

and during search I found a patch from Christian:
http://permalink.gmane.org/gmane.linux.kernel.iommu/9993

Seems we have similar error message at least, and we also map 4M
memory each time, after several map, it triggered warning above, apply
the patch seems fix the warning for us, but checking with lastest
linus tree 4.3-rc4, it's not there yet, could you guys give some
comment on the patch,  is it the right fix or we need to fix it
another way, or it's simply imply driver bug?

Please share your comments!

-- 
Mit freundlichen Grüßen,
Best Regards,

Jack Wang

Linux Kernel Developer Storage
ProfitBricks GmbH  The IaaS-Company.

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin
Tel: +49 30 5770083-42
Fax: +49 30 5770085-98
Email: jinpu.wang@profitbricks.com
URL: http://www.profitbricks.de

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506 B.
Geschäftsführer: Andreas Gauger, Achim Weiss.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFI] WARNING: CPU: 0 PID: 14493 at drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()

[Jinpu Wang]

On Mon, Oct 12, 2015 at 3:29 PM, Jinpu Wang <jinpu.wang-EIkl63zCoXaH+58JC4qpiA@public.gmane.org> wrote:
> Hi experts,
>
> We hit warning below during test:
>
> [13560.541562] ERROR: DMA PTE for vPFN 0xc3a00 already set (to
> 42834a003 not 114600083)
> [13560.541696] ------------[ cut here ]------------
> [13560.541701] WARNING: CPU: 0 PID: 22427 at
> drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()
> [13560.541702] Modules linked in: dm_snapshot dm_bufio ibnbd_server(O)
> ibtrs_server(O) rdma_cm iw_cm ib_uverbs ipmi_dev
> intf ib_ipoib ib_cm ib_umad loop mlx4_ib ib_sa ib_mad ib_core ib_addr
> ipv6 hid_generic usbhid mlx4_core i2c_i801 ioatdm
> a ehci_pci sb_edac i2c_core ehci_hcd edac_core dca ipmi_si
> ipmi_msghandler button dm_mod sg e1000e
> [13560.541726] CPU: 0 PID: 22427 Comm: kworker/0:0 Tainted: G
>  O   3.18.21-1-storage #1
> [13560.541727] Hardware name: Supermicro X9SRL-F/X9SRL-F, BIOS 3.00 07/04/2013
> [13560.541730] Workqueue: ib_cm ib_destroy_cm_id [ib_cm]
> [13560.541731]  0000000000000009 ffff880109213968 ffffffff815bac45
> 0000000000000000
> [13560.541733]  0000000000000000 ffff8801092139a8 ffffffff81050d3c
> ffff8801092139c8
> [13560.541734]  0000000114600083 ffff88007992f0e8 0000000000000200
> 00000000000c3a00
> [13560.541736] Call Trace:
> [13560.541740]  [<ffffffff815bac45>] dump_stack+0x46/0x58
> [13560.541743]  [<ffffffff81050d3c>] warn_slowpath_common+0x8c/0xc0
> [13560.541744]  [<ffffffff81050d8a>] warn_slowpath_null+0x1a/0x20
> [13560.541746]  [<ffffffff814fc0ad>] __domain_mapping+0x37d/0x390
> [13560.541748]  [<ffffffff814fdced>] __intel_map_single+0x10d/0x1d0
> [13560.541749]  [<ffffffff814fdde9>] intel_map_page+0x39/0x40
>
> and during search I found a patch from Christian:
> http://permalink.gmane.org/gmane.linux.kernel.iommu/9993
>
> Seems we have similar error message at least, and we also map 4M
> memory each time, after several map, it triggered warning above, apply
> the patch seems fix the warning for us, but checking with lastest
> linus tree 4.3-rc4, it's not there yet, could you guys give some
> comment on the patch,  is it the right fix or we need to fix it
> another way, or it's simply imply driver bug?
>
> Please share your comments!
>
Ping,

Can you shed any light on this?


Regards,

Jack

Re: [RFI] WARNING: CPU: 0 PID: 14493 at drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()

[Joerg Roedel]

On Tue, Oct 13, 2015 at 05:18:29PM +0200, Jinpu Wang wrote:
> > and during search I found a patch from Christian:
> > http://permalink.gmane.org/gmane.linux.kernel.iommu/9993

I think David alreadt applied this patch.

Re: [RFI] WARNING: CPU: 0 PID: 14493 at drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()

[Jinpu Wang]

On Wed, Oct 14, 2015 at 1:19 PM, Joerg Roedel <joro@8bytes.org> wrote:
> On Tue, Oct 13, 2015 at 05:18:29PM +0200, Jinpu Wang wrote:
>> > and during search I found a patch from Christian:
>> > http://permalink.gmane.org/gmane.linux.kernel.iommu/9993
>
> I think David alreadt applied this patch.
>

Yes, thanks Joerg.

-- 
Mit freundlichen Grüßen,
Best Regards,

Jack Wang

Linux Kernel Developer Storage
ProfitBricks GmbH  The IaaS-Company.

URL: http://www.profitbricks.de
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFI] WARNING: CPU: 0 PID: 14493 at drivers/iommu/intel-iommu.c:2048 __domain_mapping+0x37d/0x390()

[David Woodhouse]

[-- Attachment #1.1: Type: text/plain, Size: 1577 bytes --]

On Wed, 2015-10-14 at 13:19 +0200, Joerg Roedel wrote:
> On Tue, Oct 13, 2015 at 05:18:29PM +0200, Jinpu Wang wrote:
> > > and during search I found a patch from Christian:
> > > http://permalink.gmane.org/gmane.linux.kernel.iommu/9993
> 
> I think David alreadt applied this patch.

However, in doing so I've noticed another problem.

Note how we carefully avoid *freeing* the old page table pages, in
__domain_unmap(). We keep them on a list and don't free them until
*after* the IOTLB has been flushed.

That's because the hardware can still be accessing them.

However, that call to dma_pte_free_pagetable() from within
__domain_mapping() doesn't do that.

It's irrelevant in the DMA API case, since we'll never be overwriting
the existing mappings in an IOVA range anyway. That would be a bug.

But for the IOMMU API when we're changing an existing mapping, we
really need to do that properly.

I think we want something like an additional (struct page **) argument
to __domain_mapping(), for it to put any such freed pages into.

Callers *other* than intel_iommu_map() can just pass NULL, and if it
has to free any page table pages when it's NULL, it can BUG().

Then intel_iommu_map() can free the pages when it's done the IOTLB
flush.... and IOTLB flush which I note is currently completely absent
from intel_iommu_map(). Which is another bug.

-- 
-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org                              Intel Corporation


[-- Attachment #1.2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5691 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]