<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/dma/ioat/init.c, branch linux-4.9.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.9.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2019-11-25T08:53:35Z</updated>
<entry>
<title>dmaengine: ioat: fix prototype of ioat_enumerate_channels</title>
<updated>2019-11-25T08:53:35Z</updated>
<author>
<name>Rami Rosen</name>
</author>
<published>2018-10-04T21:03:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=87fc52e97f62e5219de9ab8383c864dd8aa00800'/>
<id>urn:sha1:87fc52e97f62e5219de9ab8383c864dd8aa00800</id>
<content type='text'>
[ Upstream commit f4d34aa8c887a8a2d23ef546da0efa10e3f77241 ]

Signed-off-by: Rami Rosen &lt;ramirose@gmail.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>driver/dma/ioat: Call del_timer_sync() without holding prep_lock</title>
<updated>2018-11-13T19:16:53Z</updated>
<author>
<name>Waiman Long</name>
</author>
<published>2018-09-14T18:53:32Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=479cd3e8ad91098db194dc995c7567fb480dd289'/>
<id>urn:sha1:479cd3e8ad91098db194dc995c7567fb480dd289</id>
<content type='text'>
[ Upstream commit cfb03be6c7e8a1591285849c361d67b09f5149f7 ]

The following lockdep splat was observed:

[ 1222.241750] ======================================================
[ 1222.271301] WARNING: possible circular locking dependency detected
[ 1222.301060] 4.16.0-10.el8+5.x86_64+debug #1 Not tainted
[ 1222.326659] ------------------------------------------------------
[ 1222.356565] systemd-shutdow/1 is trying to acquire lock:
[ 1222.382660]  ((&amp;ioat_chan-&gt;timer)){+.-.}, at: [&lt;00000000f71e1a28&gt;] del_timer_sync+0x5/0xf0
[ 1222.422928]
[ 1222.422928] but task is already holding lock:
[ 1222.451743]  (&amp;(&amp;ioat_chan-&gt;prep_lock)-&gt;rlock){+.-.}, at: [&lt;000000008ea98b12&gt;] ioat_shutdown+0x86/0x100 [ioatdma]
   :
[ 1223.524987] Chain exists of:
[ 1223.524987]   (&amp;ioat_chan-&gt;timer) --&gt; &amp;(&amp;ioat_chan-&gt;cleanup_lock)-&gt;rlock --&gt; &amp;(&amp;ioat_chan-&gt;prep_lock)-&gt;rlock
[ 1223.524987]
[ 1223.594082]  Possible unsafe locking scenario:
[ 1223.594082]
[ 1223.622630]        CPU0                    CPU1
[ 1223.645080]        ----                    ----
[ 1223.667404]   lock(&amp;(&amp;ioat_chan-&gt;prep_lock)-&gt;rlock);
[ 1223.691535]                                lock(&amp;(&amp;ioat_chan-&gt;cleanup_lock)-&gt;rlock);
[ 1223.728657]                                lock(&amp;(&amp;ioat_chan-&gt;prep_lock)-&gt;rlock);
[ 1223.765122]   lock((&amp;ioat_chan-&gt;timer));
[ 1223.784095]
[ 1223.784095]  *** DEADLOCK ***
[ 1223.784095]
[ 1223.813492] 4 locks held by systemd-shutdow/1:
[ 1223.834677]  #0:  (reboot_mutex){+.+.}, at: [&lt;0000000056d33456&gt;] SYSC_reboot+0x10f/0x300
[ 1223.873310]  #1:  (&amp;dev-&gt;mutex){....}, at: [&lt;00000000258dfdd7&gt;] device_shutdown+0x1c8/0x660
[ 1223.913604]  #2:  (&amp;dev-&gt;mutex){....}, at: [&lt;0000000068331147&gt;] device_shutdown+0x1d6/0x660
[ 1223.954000]  #3:  (&amp;(&amp;ioat_chan-&gt;prep_lock)-&gt;rlock){+.-.}, at: [&lt;000000008ea98b12&gt;] ioat_shutdown+0x86/0x100 [ioatdma]

In the ioat_shutdown() function:

	spin_lock_bh(&amp;ioat_chan-&gt;prep_lock);
	set_bit(IOAT_CHAN_DOWN, &amp;ioat_chan-&gt;state);
	del_timer_sync(&amp;ioat_chan-&gt;timer);
	spin_unlock_bh(&amp;ioat_chan-&gt;prep_lock);

According to the synchronization rule for the del_timer_sync() function,
the caller must not hold locks which would prevent completion of the
timer's handler.

The timer structure has its own lock that manages its synchronization.
Setting the IOAT_CHAN_DOWN bit should prevent other CPUs from
trying to use that device anyway, there is probably no need to call
del_timer_sync() while holding the prep_lock. So the del_timer_sync()
call is now moved outside of the prep_lock critical section to prevent
the circular lock dependency.

Signed-off-by: Waiman Long &lt;longman@redhat.com&gt;
Reviewed-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ioat: Fix error handling path</title>
<updated>2018-02-25T10:05:48Z</updated>
<author>
<name>Christophe JAILLET</name>
</author>
<published>2017-11-17T21:37:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b3df69b4abe6cfd8efc8c3c187cff7f02aeff642'/>
<id>urn:sha1:b3df69b4abe6cfd8efc8c3c187cff7f02aeff642</id>
<content type='text'>
[ Upstream commit 5c9afbda911ce20b3f2181d1e440a0222e1027dd ]

If the last test in 'ioat_dma_self_test()' fails, we must release all
the allocated resources and not just part of them.

Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Acked-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ioatdma: workaround SKX ioatdma version</title>
<updated>2017-08-07T01:59:46Z</updated>
<author>
<name>Dave Jiang</name>
</author>
<published>2016-12-13T18:15:27Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c2804b21f2e7f46f76500aa58850127b31054c84'/>
<id>urn:sha1:c2804b21f2e7f46f76500aa58850127b31054c84</id>
<content type='text'>
[ Upstream commit 34a31f0af84158955a9747fb5c6712da5bbb5331 ]

The Skylake ioatdma is technically CBDMA 3.2+ and contains the same hardware
bits with some additional 3.3 features, but it's not really 3.3 where the
driver is concerned.

Signed-off-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ioatdma: Add Skylake PCI Dev ID</title>
<updated>2017-08-07T01:59:46Z</updated>
<author>
<name>Dave Jiang</name>
</author>
<published>2016-12-13T18:15:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2987ce159fb9b0894d9bf000b8317e07cfed3fa8'/>
<id>urn:sha1:2987ce159fb9b0894d9bf000b8317e07cfed3fa8</id>
<content type='text'>
[ Upstream commit 1594c18fd297a8edcc72bc4b161f3f52603ebb92 ]

Adding Skylake Xeon PCI device ids for ioatdma and related bits.

Signed-off-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: iota: ioat_alloc_chan_resources should not perform sleeping allocations.</title>
<updated>2017-03-22T11:43:35Z</updated>
<author>
<name>Krister Johansen</name>
</author>
<published>2017-01-04T09:22:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2382c1486c62a21d162f0d457c61cd87a2498ffd'/>
<id>urn:sha1:2382c1486c62a21d162f0d457c61cd87a2498ffd</id>
<content type='text'>
commit 21d25f6a4217e755906cb548b55ddab39d0e88b9 upstream.

On a kernel with DEBUG_LOCKS, ioat_free_chan_resources triggers an
in_interrupt() warning.  With PROVE_LOCKING, it reports detecting a
SOFTIRQ-safe to SOFTIRQ-unsafe lock ordering in the same code path.

This is because dma_generic_alloc_coherent() checks if the GFP flags
permit blocking.  It allocates from different subsystems if blocking is
permitted.  The free path knows how to return the memory to the correct
allocator.  If GFP_KERNEL is specified then the alloc and free end up
going through cma_alloc(), which uses mutexes.

Given that ioat_free_chan_resources() can be called in interrupt
context, ioat_alloc_chan_resources() must specify GFP_NOWAIT so that the
allocations do not block and instead use an allocator that uses
spinlocks.

Signed-off-by: Krister Johansen &lt;kjlx@templeofstupid.com&gt;
Acked-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>dmaengine: ioatdma: fix uninitialized array usage</title>
<updated>2016-08-08T02:32:00Z</updated>
<author>
<name>Dave Jiang</name>
</author>
<published>2016-07-21T19:40:52Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2eab9b1a3006b4f7bf49c55ce23943170a0068db'/>
<id>urn:sha1:2eab9b1a3006b4f7bf49c55ce23943170a0068db</id>
<content type='text'>
Static analysis showed that unitialized array is being used for compare.
At line 850 when a dma_mapping_error() occurs, it jumps to dma_unmap. At
this point, dma_srcs has not been initialized. However, the code after
dma_unmap label checks dma_srcs for a comparison and thus is comparing
to random garbage in the array. Given that when dest_dma is being mapped
this is the first instance of mapping DMA memory and failed, there is
really nothing to be cleaned up and thus should jump to free_resources
label instead.

Signed-off-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
</content>
</entry>
<entry>
<title>dmaengine: ioat: statify symbol</title>
<updated>2016-07-23T10:37:29Z</updated>
<author>
<name>Vinod Koul</name>
</author>
<published>2016-07-16T14:26:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=184ff2aa3c0ba7f1cd44ed7e8d766e12e43694e2'/>
<id>urn:sha1:184ff2aa3c0ba7f1cd44ed7e8d766e12e43694e2</id>
<content type='text'>
Sparse warns:
drivers/dma/ioat/init.c:1215:6: warning: symbol 'ioat_resume' was not declared. Should it be static?

Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
Acked-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
</content>
</entry>
<entry>
<title>dmaengine: ioatdma: disable relaxed ordering for ioatdma</title>
<updated>2016-05-14T08:06:52Z</updated>
<author>
<name>Dave Jiang</name>
</author>
<published>2016-05-11T21:32:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=511deae0261c839461948f2d4d1c13b8c8a59cd8'/>
<id>urn:sha1:511deae0261c839461948f2d4d1c13b8c8a59cd8</id>
<content type='text'>
ioatdma by default is in snoop mode. Relaxed ordering according to spec
does not do anything in snoop mode. However, it causes hang or significant
performance degrade when tested with NTB. Disabling in the driver due to
some BIOS do not configure it correctly.

Signed-off-by: Dave Jiang &lt;dave.jiang@intel.com&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
</content>
</entry>
<entry>
<title>dmaengine: ioatdma: Use dma_pool_zalloc</title>
<updated>2016-05-03T06:53:12Z</updated>
<author>
<name>Julia Lawall</name>
</author>
<published>2016-04-29T20:09:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=305697facd1b6d1ce41eaffb1fbe2bf5950334eb'/>
<id>urn:sha1:305697facd1b6d1ce41eaffb1fbe2bf5950334eb</id>
<content type='text'>
Dma_pool_zalloc combines dma_pool_alloc and memset 0.  The semantic patch
that makes this transformation is as follows: (http://coccinelle.lip6.fr/)

// &lt;smpl&gt;
@@
expression d,e;
statement S;
@@

        d =
-            dma_pool_alloc
+            dma_pool_zalloc
             (...);
        if (!d) S
-       memset(d, 0, sizeof(*d));
// &lt;/smpl&gt;

Signed-off-by: Julia Lawall &lt;Julia.Lawall@lip6.fr&gt;
Signed-off-by: Vinod Koul &lt;vinod.koul@intel.com&gt;
</content>
</entry>
</feed>
