Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-18 Thread Joerg Roedel
On Thu, Oct 17, 2019 at 10:39:13AM -0400, Qian Cai wrote:
> On Wed, 2019-10-16 at 17:44 +0200, Joerg Roedel wrote:
> > On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > > BTW, the previous x86 warning was from only reverted one patch "iommu: 
> > > Add gfp
> > > parameter to iommu_ops::map" where proved to be insufficient. Now, 
> > > pasting the
> > > correct warning.
> > 
> > Can you please test this small fix:
> 
> This works fine so far.

Thanks for testing, I queued the fix and will push it to my next branch
today.

Regards,

Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-17 Thread Qian Cai
On Wed, 2019-10-16 at 17:44 +0200, Joerg Roedel wrote:
> On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > BTW, the previous x86 warning was from only reverted one patch "iommu: Add 
> > gfp
> > parameter to iommu_ops::map" where proved to be insufficient. Now, pasting 
> > the
> > correct warning.
> 
> Can you please test this small fix:

This works fine so far.

> 
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index 78a2cca3ac5c..e7a4464e8594 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -2562,7 +2562,7 @@ static int amd_iommu_map(struct iommu_domain *dom, 
> unsigned long iova,
>   if (iommu_prot & IOMMU_WRITE)
>   prot |= IOMMU_PROT_IW;
>  
> - ret = iommu_map_page(domain, iova, paddr, page_size, prot, GFP_KERNEL);
> + ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);
>  
>   domain_flush_np_cache(domain, iova, page_size);
>  
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Julien Grall

Hi Robin,

On 16/10/2019 17:09, Robin Murphy wrote:

On 16/10/2019 17:03, Joerg Roedel wrote:

On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:

On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:



The x86 one might just be a mistake.

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index ad05484d0c80..63c4b894751d 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2542,7 +2542,7 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
 if (iommu_prot & IOMMU_WRITE)
 prot |= IOMMU_PROT_IW;
-   ret = iommu_map_page(domain, iova, paddr, page_size, prot, GFP_KERNEL);
+   ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);


Yeah, that is a bug, I spotted that too.


@@ -1185,7 +1185,7 @@ static struct iommu_dma_msi_page
*iommu_dma_get_msi_page(struct device *dev,
 if (!iova)
 goto out_free_page;
-   if (iommu_map(domain, iova, msi_addr, size, prot))
+   if (iommu_map_atomic(domain, iova, msi_addr, size, prot))
 goto out_free_iova;


Not so sure this is a bug, this code is only about setting up MSIs on
ARM. It probably doesn't need to be atomic.
Right, since the iommu_dma_prepare_msi() operation was broken out to happen at 
MSI domain setup time, I don't think the comment in there applies any more, so 
we can probably stop disabling irqs around the iommu_dma_get_msi_page() call.


Yes, I agree that it does not need to be atomic anymore.

Cheers,

--
Julien Grall


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Robin Murphy

On 16/10/2019 17:11, Qian Cai wrote:

On Wed, 2019-10-16 at 18:03 +0200, Joerg Roedel wrote:

On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:

On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
The x86 one might just be a mistake.

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index ad05484d0c80..63c4b894751d 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2542,7 +2542,7 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
 if (iommu_prot & IOMMU_WRITE)
 prot |= IOMMU_PROT_IW;
  
-   ret = iommu_map_page(domain, iova, paddr, page_size, prot, GFP_KERNEL);

+   ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);


Yeah, that is a bug, I spotted that too.


@@ -1185,7 +1185,7 @@ static struct iommu_dma_msi_page
*iommu_dma_get_msi_page(struct device *dev,
 if (!iova)
 goto out_free_page;
  
-   if (iommu_map(domain, iova, msi_addr, size, prot))

+   if (iommu_map_atomic(domain, iova, msi_addr, size, prot))
 goto out_free_iova;


Not so sure this is a bug, this code is only about setting up MSIs on
ARM. It probably doesn't need to be atomic.


The patch "iommu: Add gfp parameter to iommu_ops::map" does this. It could be
called from an atomic context as showed in the arm64 call traces,

+int iommu_map(struct iommu_domain *domain, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot)
+{
+   might_sleep();
+   return __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+}


Also note that it's *only* the might_sleep() at issue here - none of the 
arm64 IOMMU drivers have been converted to look at the new gfp argument 
yet, so anything they actually allocate while mapping will still be 
GFP_ATOMIC anyway.


(Carrying that flag down through the whole io-pgtable stack is on my 
to-do list...)


Robin.


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Qian Cai
On Wed, 2019-10-16 at 18:03 +0200, Joerg Roedel wrote:
> On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
> > On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
> > The x86 one might just be a mistake.
> > 
> > diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> > index ad05484d0c80..63c4b894751d 100644
> > --- a/drivers/iommu/amd_iommu.c
> > +++ b/drivers/iommu/amd_iommu.c
> > @@ -2542,7 +2542,7 @@ static int amd_iommu_map(struct iommu_domain *dom,
> > unsigned long iova,
> > if (iommu_prot & IOMMU_WRITE)
> > prot |= IOMMU_PROT_IW;
> >  
> > -   ret = iommu_map_page(domain, iova, paddr, page_size, prot, 
> > GFP_KERNEL);
> > +   ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);
> 
> Yeah, that is a bug, I spotted that too.
> 
> > @@ -1185,7 +1185,7 @@ static struct iommu_dma_msi_page
> > *iommu_dma_get_msi_page(struct device *dev,
> > if (!iova)
> > goto out_free_page;
> >  
> > -   if (iommu_map(domain, iova, msi_addr, size, prot))
> > +   if (iommu_map_atomic(domain, iova, msi_addr, size, prot))
> > goto out_free_iova;
> 
> Not so sure this is a bug, this code is only about setting up MSIs on
> ARM. It probably doesn't need to be atomic.

The patch "iommu: Add gfp parameter to iommu_ops::map" does this. It could be
called from an atomic context as showed in the arm64 call traces,

+int iommu_map(struct iommu_domain *domain, unsigned long iova,
+ phys_addr_t paddr, size_t size, int prot)
+{
+   might_sleep();
+   return __iommu_map(domain, iova, paddr, size, prot, GFP_KERNEL);
+}


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Robin Murphy

On 16/10/2019 17:03, Joerg Roedel wrote:

On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:

On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:



The x86 one might just be a mistake.

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index ad05484d0c80..63c4b894751d 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2542,7 +2542,7 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
 if (iommu_prot & IOMMU_WRITE)
 prot |= IOMMU_PROT_IW;
  
-   ret = iommu_map_page(domain, iova, paddr, page_size, prot, GFP_KERNEL);

+   ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);


Yeah, that is a bug, I spotted that too.


@@ -1185,7 +1185,7 @@ static struct iommu_dma_msi_page
*iommu_dma_get_msi_page(struct device *dev,
 if (!iova)
 goto out_free_page;
  
-   if (iommu_map(domain, iova, msi_addr, size, prot))

+   if (iommu_map_atomic(domain, iova, msi_addr, size, prot))
 goto out_free_iova;


Not so sure this is a bug, this code is only about setting up MSIs on
ARM. It probably doesn't need to be atomic.
Right, since the iommu_dma_prepare_msi() operation was broken out to 
happen at MSI domain setup time, I don't think the comment in there 
applies any more, so we can probably stop disabling irqs around the 
iommu_dma_get_msi_page() call.


Robin.


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Joerg Roedel
On Wed, Oct 16, 2019 at 11:53:33AM -0400, Qian Cai wrote:
> On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:

> The x86 one might just be a mistake.
> 
> diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
> index ad05484d0c80..63c4b894751d 100644
> --- a/drivers/iommu/amd_iommu.c
> +++ b/drivers/iommu/amd_iommu.c
> @@ -2542,7 +2542,7 @@ static int amd_iommu_map(struct iommu_domain *dom,
> unsigned long iova,
> if (iommu_prot & IOMMU_WRITE)
> prot |= IOMMU_PROT_IW;
>  
> -   ret = iommu_map_page(domain, iova, paddr, page_size, prot, 
> GFP_KERNEL);
> +   ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);

Yeah, that is a bug, I spotted that too.

> @@ -1185,7 +1185,7 @@ static struct iommu_dma_msi_page
> *iommu_dma_get_msi_page(struct device *dev,
> if (!iova)
> goto out_free_page;
>  
> -   if (iommu_map(domain, iova, msi_addr, size, prot))
> +   if (iommu_map_atomic(domain, iova, msi_addr, size, prot))
> goto out_free_iova;

Not so sure this is a bug, this code is only about setting up MSIs on
ARM. It probably doesn't need to be atomic.

Regards,

Joerg


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Qian Cai
On Wed, 2019-10-16 at 17:31 +0200, Joerg Roedel wrote:
> Hi Qian,
> 
> thanks for the report!
> 
> On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> > On Wed, 2019-10-16 at 10:55 -0400, Qian Cai wrote:
> > > Today's linux-next generates a lot of warnings on multiple servers during 
> > > boot
> > > due to the series "iommu/amd: Convert the AMD iommu driver to the 
> > > dma-iommu api"
> > > [1]. Reverted the whole things fixed them.
> > > 
> > > [1] https://lore.kernel.org/lkml/20190908165642.22253-1-murph...@tcd.ie/
> > > 
> > 
> > BTW, the previous x86 warning was from only reverted one patch "iommu: Add 
> > gfp
> > parameter to iommu_ops::map" where proved to be insufficient. Now, pasting 
> > the
> > correct warning.

The x86 one might just be a mistake.

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index ad05484d0c80..63c4b894751d 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2542,7 +2542,7 @@ static int amd_iommu_map(struct iommu_domain *dom,
unsigned long iova,
if (iommu_prot & IOMMU_WRITE)
prot |= IOMMU_PROT_IW;
 
-   ret = iommu_map_page(domain, iova, paddr, page_size, prot, GFP_KERNEL);
+   ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);
 
domain_flush_np_cache(domain, iova, page_size);

The arm64 -- does it forget to do this?

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ecc08aef9b58..8dd0ef0656f4 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -1185,7 +1185,7 @@ static struct iommu_dma_msi_page
*iommu_dma_get_msi_page(struct device *dev,
if (!iova)
goto out_free_page;
 
-   if (iommu_map(domain, iova, msi_addr, size, prot))
+   if (iommu_map_atomic(domain, iova, msi_addr, size, prot))
goto out_free_iova;
 
INIT_LIST_HEAD(_page->list);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Joerg Roedel
On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> BTW, the previous x86 warning was from only reverted one patch "iommu: Add gfp
> parameter to iommu_ops::map" where proved to be insufficient. Now, pasting the
> correct warning.

Can you please test this small fix:

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 78a2cca3ac5c..e7a4464e8594 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2562,7 +2562,7 @@ static int amd_iommu_map(struct iommu_domain *dom, 
unsigned long iova,
if (iommu_prot & IOMMU_WRITE)
prot |= IOMMU_PROT_IW;
 
-   ret = iommu_map_page(domain, iova, paddr, page_size, prot, GFP_KERNEL);
+   ret = iommu_map_page(domain, iova, paddr, page_size, prot, gfp);
 
domain_flush_np_cache(domain, iova, page_size);
 

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Joerg Roedel
Hi Qian,

thanks for the report!

On Wed, Oct 16, 2019 at 10:59:42AM -0400, Qian Cai wrote:
> On Wed, 2019-10-16 at 10:55 -0400, Qian Cai wrote:
> > Today's linux-next generates a lot of warnings on multiple servers during 
> > boot
> > due to the series "iommu/amd: Convert the AMD iommu driver to the dma-iommu 
> > api"
> > [1]. Reverted the whole things fixed them.
> > 
> > [1] https://lore.kernel.org/lkml/20190908165642.22253-1-murph...@tcd.ie/
> > 
> 
> BTW, the previous x86 warning was from only reverted one patch "iommu: Add gfp
> parameter to iommu_ops::map" where proved to be insufficient. Now, pasting the
> correct warning.

I am looking into it and may send you fixes to test.

Thanks,

Joerg

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: "Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Qian Cai
On Wed, 2019-10-16 at 10:55 -0400, Qian Cai wrote:
> Today's linux-next generates a lot of warnings on multiple servers during boot
> due to the series "iommu/amd: Convert the AMD iommu driver to the dma-iommu 
> api"
> [1]. Reverted the whole things fixed them.
> 
> [1] https://lore.kernel.org/lkml/20190908165642.22253-1-murph...@tcd.ie/
> 

BTW, the previous x86 warning was from only reverted one patch "iommu: Add gfp
parameter to iommu_ops::map" where proved to be insufficient. Now, pasting the
correct warning.

[  564.365768][ T6222] BUG: sleeping function called from invalid context at
mm/page_alloc.c:4692
[  564.374447][ T6222] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid:
6222, name: git
[  564.382969][ T6222] INFO: lockdep is turned off.
[  564.387644][ T6222] CPU: 25 PID: 6222 Comm: git Tainted:
GW 5.4.0-rc3-next-20191016 #6
[  564.397011][ T6222] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 07/10/2019
[  564.406291][ T6222] Call Trace:
[  564.409470][ T6222]  dump_stack+0x86/0xca
[  564.413517][ T6222]  ___might_sleep.cold.92+0xd2/0x122
[  564.418694][ T6222]  __might_sleep+0x73/0xe0
[  564.422999][ T6222]  __alloc_pages_nodemask+0x442/0x720
[  564.428265][ T6222]  ? __alloc_pages_slowpath+0x18d0/0x18d0
[  564.433883][ T6222]  ? arch_stack_walk+0x7f/0xf0
[  564.438534][ T6222]  ? create_object+0x4a2/0x540
[  564.443188][ T6222]  alloc_pages_current+0x9c/0x110
[  564.448098][ T6222]  __get_free_pages+0x12/0x60
[  564.452659][ T6222]  get_zeroed_page+0x16/0x20
[  564.457137][ T6222]  amd_iommu_map+0x504/0x850
[  564.461612][ T6222]  ? amd_iommu_domain_direct_map+0x60/0x60
[  564.467312][ T6222]  ? lockdep_hardirqs_on+0x16/0x2a0
[  564.472400][ T6222]  ? alloc_iova+0x189/0x210
[  564.476790][ T6222]  __iommu_map+0x1c1/0x4e0
[  564.481090][ T6222]  ? iommu_get_dma_domain+0x40/0x40
[  564.486181][ T6222]  ? alloc_iova_fast+0x258/0x3d1
[  564.491009][ T6222]  ? create_object+0x4a2/0x540
[  564.495656][ T6222]  __iommu_map_sg+0xa5/0x130
[  564.500135][ T6222]  iommu_map_sg_atomic+0x14/0x20
[  564.504958][ T6222]  iommu_dma_map_sg+0x2c3/0x450
[  564.509699][ T6222]  scsi_dma_map+0xd7/0x160
[  564.514010][ T6222]  pqi_raid_submit_scsi_cmd_with_io_request+0x392/0x420
[smartpqi]
[  564.521811][ T6222]  ? pqi_alloc_io_request+0x127/0x140 [smartpqi]
[  564.528037][ T6222]  pqi_scsi_queue_command+0x8ab/0xe00 [smartpqi]
[  564.534264][ T6222]  ? pqi_eh_device_reset_handler+0x9c0/0x9c0 [smartpqi]
[  564.541100][ T6222]  ? sd_init_command+0xa25/0x1346 [sd_mod]
[  564.546802][ T6222]  scsi_queue_rq+0xd19/0x1360
[  564.551372][ T6222]  __blk_mq_try_issue_directly+0x295/0x3f0
[  564.557071][ T6222]  ? blk_mq_request_bypass_insert+0xd0/0xd0
[  564.562860][ T6222]  ? debug_lockdep_rcu_enabled+0x27/0x60
[  564.568384][ T6222]  blk_mq_try_issue_directly+0xad/0x130
[  564.573821][ T6222]  ? __blk_mq_try_issue_directly+0x3f0/0x3f0
[  564.579693][ T6222]  ? blk_add_rq_to_plug+0xcd/0x110
[  564.584693][ T6222]  blk_mq_make_request+0xcee/0x1120
[  564.589777][ T6222]  ? lock_downgrade+0x3c0/0x3c0
[  564.594517][ T6222]  ? blk_mq_try_issue_directly+0x130/0x130
[  564.600218][ T6222]  ? blk_queue_enter+0x78d/0x810
[  564.605041][ T6222]  ? generic_make_request_checks+0xf30/0xf30
[  564.610915][ T6222]  ? lock_downgrade+0x3c0/0x3c0
[  564.615655][ T6222]  ? __srcu_read_unlock+0x24/0x50
[  564.620565][ T6222]  ? generic_make_request+0x150/0x650
[  564.625833][ T6222]  generic_make_request+0x196/0x650
[  564.630921][ T6222]  ? blk_queue_enter+0x810/0x810
[  564.635747][ T6222]  submit_bio+0xaa/0x270
[  564.639873][ T6222]  ? submit_bio+0xaa/0x270
[  564.644172][ T6222]  ? generic_make_request+0x650/0x650
[  564.649437][ T6222]  ? iomap_readpage+0x260/0x260
[  564.654173][ T6222]  iomap_readpages+0x154/0x3d0
[  564.658823][ T6222]  ? iomap_zero_range_actor+0x330/0x330
[  564.664257][ T6222]  ? __might_sleep+0x73/0xe0
[  564.668836][ T6222]  xfs_vm_readpages+0xaf/0x1f0 [xfs]
[  564.674016][ T6222]  read_pages+0xe2/0x3b0
[  564.678142][ T6222]  ? read_cache_pages+0x350/0x350
[  564.683057][ T6222]  ? __page_cache_alloc+0x12c/0x230
[  564.688148][ T6222]  __do_page_cache_readahead+0x346/0x3a0
[  564.693670][ T6222]  ? read_pages+0x3b0/0x3b0
[  564.698059][ T6222]  ? lockdep_hardirqs_on+0x16/0x2a0
[  564.703247][ T6222]  ? __xfs_filemap_fault+0x167/0x4a0 [xfs]
[  564.708947][ T6222]  filemap_fault+0xa13/0xe70
[  564.713528][ T6222]  __xfs_filemap_fault+0x167/0x4a0 [xfs]
[  564.719059][ T6222]  ? kmemleak_alloc+0x57/0x90
[  564.723724][ T6222]  ? xfs_file_read_iter+0x3c0/0x3c0 [xfs]
[  564.729337][ T6222]  ? debug_check_no_locks_freed+0x2c/0xe0
[  564.734946][ T6222]  ? lockdep_init_map+0x8b/0x2b0
[  564.739872][ T6222]  xfs_filemap_fault+0x68/0x70 [xfs]
[  564.745046][ T6222]  __do_fault+0x83/0x220
[  564.749172][ T6222]  __handle_mm_fault+0xd76/0x1f40
[  564.754084][ T6222]  ? __pmd_alloc+0x280/0x280
[  564.758559][ T6222]  ? debug_lockdep_rcu_enabled+0x27/0x60

> 
> [  183.553150] 

"Convert the AMD iommu driver to the dma-iommu api" is buggy

2019-10-16 Thread Qian Cai
Today's linux-next generates a lot of warnings on multiple servers during boot
due to the series "iommu/amd: Convert the AMD iommu driver to the dma-iommu api"
[1]. Reverted the whole things fixed them.

[1] https://lore.kernel.org/lkml/20190908165642.22253-1-murph...@tcd.ie/

[  257.785749][ T6184] BUG: sleeping function called from invalid context at
mm/page_alloc.c:4692
[  257.794886][ T6184] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid:
6184, name: readelf
[  257.803574][ T6184] INFO: lockdep is turned off.
[  257.808233][ T6184] CPU: 86 PID: 6184 Comm: readelf Tainted:
GW 5.4.0-rc3-next-20191016+ #7
[  257.818035][ T6184] Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385
Gen10, BIOS A40 07/10/2019
[  257.827313][ T6184] Call Trace:
[  257.830487][ T6184]  dump_stack+0x86/0xca
[  257.834530][ T6184]  ___might_sleep.cold.92+0xd2/0x122
[  257.839708][ T6184]  __might_sleep+0x73/0xe0
[  257.844011][ T6184]  __alloc_pages_nodemask+0x442/0x720
[  257.849274][ T6184]  ? __alloc_pages_slowpath+0x18d0/0x18d0
[  257.854886][ T6184]  ? debug_lockdep_rcu_enabled+0x27/0x60
[  257.860415][ T6184]  ? lock_downgrade+0x3c0/0x3c0
[  257.865156][ T6184]  alloc_pages_current+0x9c/0x110
[  257.870071][ T6184]  __get_free_pages+0x12/0x60
[  257.874634][ T6184]  get_zeroed_page+0x16/0x20
[  257.879112][ T6184]  amd_iommu_map+0x504/0x850
[  257.883588][ T6184]  ? amd_iommu_domain_direct_map+0x60/0x60
[  257.889286][ T6184]  ? lockdep_hardirqs_on+0x16/0x2a0
[  257.894373][ T6184]  ? alloc_iova+0x189/0x210
[  257.898765][ T6184]  ? trace_hardirqs_on+0x3a/0x160
[  257.903677][ T6184]  iommu_map+0x1b3/0x4d0
[  257.907802][ T6184]  ? iommu_unmap+0xf0/0xf0
[  257.912104][ T6184]  ? alloc_iova_fast+0x258/0x3d1
[  257.916929][ T6184]  ? create_object+0x4a2/0x540
[  257.921579][ T6184]  iommu_map_sg+0x9d/0x120
[  257.925882][ T6184]  iommu_dma_map_sg+0x2c3/0x450
[  257.930627][ T6184]  scsi_dma_map+0xd7/0x160
[  257.934936][ T6184]  pqi_raid_submit_scsi_cmd_with_io_request+0x392/0x420
[smartpqi]
[  257.942735][ T6184]  ? pqi_alloc_io_request+0x127/0x140 [smartpqi]
[  257.948962][ T6184]  pqi_scsi_queue_command+0x8ab/0xe00 [smartpqi]
[  257.955192][ T6184]  ? pqi_eh_device_reset_handler+0x9c0/0x9c0 [smartpqi]
[  257.962029][ T6184]  ? sd_init_command+0xa25/0x1346 [sd_mod]
[  257.967730][ T6184]  scsi_queue_rq+0xd19/0x1360
[  257.972298][ T6184]  __blk_mq_try_issue_directly+0x295/0x3f0
[  257.977999][ T6184]  ? blk_mq_request_bypass_insert+0xd0/0xd0
[  257.983787][ T6184]  ? debug_lockdep_rcu_enabled+0x27/0x60
[  257.989312][ T6184]  blk_mq_request_issue_directly+0xb5/0x100
[  257.995098][ T6184]  ? blk_mq_flush_plug_list+0x7e0/0x7e0
[  258.000537][ T6184]  ? blk_mq_sched_insert_requests+0xd6/0x380
[  258.006409][ T6184]  ? lock_downgrade+0x3c0/0x3c0
[  258.011147][ T6184]  blk_mq_try_issue_list_directly+0xa9/0x160
[  258.017023][ T6184]  blk_mq_sched_insert_requests+0x228/0x380
[  258.022810][ T6184]  blk_mq_flush_plug_list+0x448/0x7e0
[  258.028073][ T6184]  ? blk_mq_insert_requests+0x380/0x380
[  258.033516][ T6184]  blk_flush_plug_list+0x1eb/0x230
[  258.038515][ T6184]  ? blk_insert_cloned_request+0x1b0/0x1b0
[  258.044215][ T6184]  blk_finish_plug+0x43/0x5d
[  258.048695][ T6184]  read_pages+0xf6/0x3b0
[  258.052823][ T6184]  ? read_cache_pages+0x350/0x350
[  258.057737][ T6184]  ? __page_cache_alloc+0x12c/0x230
[  258.062826][ T6184]  __do_page_cache_readahead+0x346/0x3a0
[  258.068348][ T6184]  ? read_pages+0x3b0/0x3b0
[  258.072738][ T6184]  ? lockdep_hardirqs_on+0x16/0x2a0
[  258.077928][ T6184]  ? __xfs_filemap_fault+0x167/0x4a0 [xfs]
[  258.083625][ T6184]  filemap_fault+0xa13/0xe70
[  258.088201][ T6184]  __xfs_filemap_fault+0x167/0x4a0 [xfs]
[  258.093731][ T6184]  ? kmemleak_alloc+0x57/0x90
[  258.098397][ T6184]  ? xfs_file_read_iter+0x3c0/0x3c0 [xfs]
[  258.104009][ T6184]  ? debug_check_no_locks_freed+0x2c/0xe0
[  258.109618][ T6184]  ? lockdep_init_map+0x8b/0x2b0
[  258.114543][ T6184]  xfs_filemap_fault+0x68/0x70 [xfs]
[  258.119720][ T6184]  __do_fault+0x83/0x220
[  258.123847][ T6184]  __handle_mm_fault+0xd76/0x1f40
[  258.128757][ T6184]  ? __pmd_alloc+0x280/0x280
[  258.133231][ T6184]  ? debug_lockdep_rcu_enabled+0x27/0x60
[  258.138755][ T6184]  ? handle_mm_fault+0x178/0x4c0
[  258.143581][ T6184]  ? lockdep_hardirqs_on+0x16/0x2a0
[  258.148674][ T6184]  ? __do_page_fault+0x29c/0x640
[  258.153501][ T6184]  handle_mm_fault+0x205/0x4c0
[  258.158151][ T6184]  __do_page_fault+0x29c/0x640
[  258.162800][ T6184]  do_page_fault+0x50/0x37f
[  258.167189][ T6184]  page_fault+0x34/0x40
[  258.171228][ T6184] RIP: 0010:__clear_user+0x3b/0x70

[  183.553150] BUG: sleeping function called from invalid context at
drivers/iommu/iommu.c:1950
[  183.562306] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1486,
name: kworker/0:3
[  183.571450] 5 locks held by kworker/0:3/1486:
[  183.576510]  #0: 44ff0008000ce128 ((wq_completion)events){+.+.}, at:
process_one_work+0x25c/0x948
[