<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git, branch v4.1.17</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>Linux 4.1.17</title>
<updated>2016-01-31T19:23:48+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2016-01-31T19:23:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=2d5f6b0413359df065fd02d695c08bbc7d998bbd'/>
<id>2d5f6b0413359df065fd02d695c08bbc7d998bbd</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>recordmcount: Fix endianness handling bug for nop_mcount</title>
<updated>2016-01-31T19:23:40+00:00</updated>
<author>
<name>libin</name>
<email>huawei.libin@huawei.com</email>
</author>
<published>2015-11-03T00:58:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=d17367a77457f556e7614f2e80db5d5a902e1268'/>
<id>d17367a77457f556e7614f2e80db5d5a902e1268</id>
<content type='text'>
commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.

In nop_mcount, shdr-&gt;sh_offset and welp-&gt;r_offset should handle
endianness properly, otherwise it will trigger Segmentation fault
if the recordmcount main and file.o have different endianness.

Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com

Signed-off-by: Li Bin &lt;huawei.libin@huawei.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c84da8b9ad3761eef43811181c7e896e9834b26b upstream.

In nop_mcount, shdr-&gt;sh_offset and welp-&gt;r_offset should handle
endianness properly, otherwise it will trigger Segmentation fault
if the recordmcount main and file.o have different endianness.

Link: http://lkml.kernel.org/r/563806C7.7070606@huawei.com

Signed-off-by: Li Bin &lt;huawei.libin@huawei.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>arm64: restore bogomips information in /proc/cpuinfo</title>
<updated>2016-01-31T19:23:40+00:00</updated>
<author>
<name>Yang Shi</name>
<email>yang.shi@linaro.org</email>
</author>
<published>2015-11-18T18:48:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=1f6d936d33f4b5875ca3aed0e8084e0fb56d4e0d'/>
<id>1f6d936d33f4b5875ca3aed0e8084e0fb56d4e0d</id>
<content type='text'>
commit 92e788b749862ebe9920360513a718e5dd4da7a9 upstream.

As previously reported, some userspace applications depend on bogomips
showed by /proc/cpuinfo. Although there is much less legacy impact on
aarch64 than arm, it does break libvirt.

This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
reporting bogomips in /proc/cpuinfo"), but with some tweak due to
context change and without the pr_info().

Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
Signed-off-by: Yang Shi &lt;yang.shi@linaro.org&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.12+
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 92e788b749862ebe9920360513a718e5dd4da7a9 upstream.

As previously reported, some userspace applications depend on bogomips
showed by /proc/cpuinfo. Although there is much less legacy impact on
aarch64 than arm, it does break libvirt.

This patch reverts commit 326b16db9f69 ("arm64: delay: don't bother
reporting bogomips in /proc/cpuinfo"), but with some tweak due to
context change and without the pr_info().

Fixes: 326b16db9f69 ("arm64: delay: don't bother reporting bogomips in /proc/cpuinfo")
Signed-off-by: Yang Shi &lt;yang.shi@linaro.org&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 3.12+
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mn10300: Select CONFIG_HAVE_UID16 to fix build failure</title>
<updated>2016-01-31T19:23:40+00:00</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2015-11-28T16:52:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=705164dbe08ff960bce54eb2edad20f8def2b247'/>
<id>705164dbe08ff960bce54eb2edad20f8def2b247</id>
<content type='text'>
commit c86576ea114a9a881cf7328dc7181052070ca311 upstream.

mn10300 builds fail with

fs/stat.c: In function 'cp_old_stat':
fs/stat.c:163:2: error: 'old_uid_t' undeclared

ipc/util.c: In function 'ipc64_perm_to_ipc_perm':
ipc/util.c:540:2: error: 'old_uid_t' undeclared

Select CONFIG_HAVE_UID16 and remove local definition of CONFIG_UID16
to fix the problem.

Fixes: fbc416ff8618 ("arm64: fix building without CONFIG_UID16")
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c86576ea114a9a881cf7328dc7181052070ca311 upstream.

mn10300 builds fail with

fs/stat.c: In function 'cp_old_stat':
fs/stat.c:163:2: error: 'old_uid_t' undeclared

ipc/util.c: In function 'ipc64_perm_to_ipc_perm':
ipc/util.c:540:2: error: 'old_uid_t' undeclared

Select CONFIG_HAVE_UID16 and remove local definition of CONFIG_UID16
to fix the problem.

Fixes: fbc416ff8618 ("arm64: fix building without CONFIG_UID16")
Cc: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Acked-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>fix the regression from "direct-io: Fix negative return from dio read beyond eof"</title>
<updated>2016-01-31T19:23:40+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@zeniv.linux.org.uk</email>
</author>
<published>2015-12-08T17:22:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=57b7d61c2d89e3e0665b9cdcc8fb73b08d10f0c2'/>
<id>57b7d61c2d89e3e0665b9cdcc8fb73b08d10f0c2</id>
<content type='text'>
commit 2d4594acbf6d8f75a27f3578476b6a27d8b13ebb upstream.

Sure, it's better to bail out of past-the-eof read and return 0 than return
a bogus negative value on such.  Only we'd better make sure we are bailing out
with 0 and not -ENOMEM...

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2d4594acbf6d8f75a27f3578476b6a27d8b13ebb upstream.

Sure, it's better to bail out of past-the-eof read and return 0 than return
a bogus negative value on such.  Only we'd better make sure we are bailing out
with 0 and not -ENOMEM...

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>direct-io: Fix negative return from dio read beyond eof</title>
<updated>2016-01-31T19:23:40+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2015-11-30T17:15:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8885e7f3d76a9d42eb4fd97a3cfc5a8ac7f6f2ff'/>
<id>8885e7f3d76a9d42eb4fd97a3cfc5a8ac7f6f2ff</id>
<content type='text'>
commit 74cedf9b6c603f2278a05bc91b140b32b434d0b5 upstream.

Assume a filesystem with 4KB blocks. When a file has size 1000 bytes and
we issue direct IO read at offset 1024, blockdev_direct_IO() reads the
tail of the last block and the logic for handling short DIO reads in
dio_complete() results in a return value -24 (1000 - 1024) which
obviously confuses userspace.

Fix the problem by bailing out early once we sample i_size and can
reliably check that direct IO read starts beyond i_size.

Reported-by: Avi Kivity &lt;avi@scylladb.com&gt;
Fixes: 9fe55eea7e4b444bafc42fa0000cc2d1d2847275
CC: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 74cedf9b6c603f2278a05bc91b140b32b434d0b5 upstream.

Assume a filesystem with 4KB blocks. When a file has size 1000 bytes and
we issue direct IO read at offset 1024, blockdev_direct_IO() reads the
tail of the last block and the logic for handling short DIO reads in
dio_complete() results in a return value -24 (1000 - 1024) which
obviously confuses userspace.

Fix the problem by bailing out early once we sample i_size and can
reliably check that direct IO read starts beyond i_size.

Reported-by: Avi Kivity &lt;avi@scylladb.com&gt;
Fixes: 9fe55eea7e4b444bafc42fa0000cc2d1d2847275
CC: Steven Whitehouse &lt;swhiteho@redhat.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>media/vivid-osd: fix info leak in ioctl</title>
<updated>2016-01-31T19:23:40+00:00</updated>
<author>
<name>Salva Peiró</name>
<email>speirofr@gmail.com</email>
</author>
<published>2015-10-07T10:09:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b824d64b153a9683aed6730e9f093a7102c36799'/>
<id>b824d64b153a9683aed6730e9f093a7102c36799</id>
<content type='text'>
commit eda98796aff0d9bf41094b06811f5def3b4c333c upstream.

The vivid_fb_ioctl() code fails to initialize the 16 _reserved bytes of
struct fb_vblank after the -&gt;hcount member. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Salva Peiró &lt;speirofr@gmail.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit eda98796aff0d9bf41094b06811f5def3b4c333c upstream.

The vivid_fb_ioctl() code fails to initialize the 16 _reserved bytes of
struct fb_vblank after the -&gt;hcount member. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Salva Peiró &lt;speirofr@gmail.com&gt;
Signed-off-by: Hans Verkuil &lt;hans.verkuil@cisco.com&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab@osg.samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>staging: lustre: echo_copy.._lsm() dereferences userland pointers directly</title>
<updated>2016-01-31T19:23:40+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@ZenIV.linux.org.uk</email>
</author>
<published>2015-12-01T19:52:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3f0cf7dcf712ef29ca47cd2f0b20292aab6e1d59'/>
<id>3f0cf7dcf712ef29ca47cd2f0b20292aab6e1d59</id>
<content type='text'>
commit 9225c0b7b976dd9ceac2b80727a60d8fcb906a62 upstream.

missing get_user()

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9225c0b7b976dd9ceac2b80727a60d8fcb906a62 upstream.

missing get_user()

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>HID: core: Avoid uninitialized buffer access</title>
<updated>2016-01-31T19:23:39+00:00</updated>
<author>
<name>Richard Purdie</name>
<email>richard.purdie@linuxfoundation.org</email>
</author>
<published>2015-09-18T23:31:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=b50a2b556d1e487c2430e13042a98325adca0be5'/>
<id>b50a2b556d1e487c2430e13042a98325adca0be5</id>
<content type='text'>
commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

hid_connect adds various strings to the buffer but they're all
conditional. You can find circumstances where nothing would be written
to it but the kernel will still print the supposedly empty buffer with
printk. This leads to corruption on the console/in the logs.

Ensure buf is initialized to an empty string.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
Cc: Jiri Kosina &lt;jikos@kernel.org&gt;
Cc: linux-input@vger.kernel.org
Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 79b568b9d0c7c5d81932f4486d50b38efdd6da6d upstream.

hid_connect adds various strings to the buffer but they're all
conditional. You can find circumstances where nothing would be written
to it but the kernel will still print the supposedly empty buffer with
printk. This leads to corruption on the console/in the logs.

Ensure buf is initialized to an empty string.

Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;
[dvhart: Initialize string to "" rather than assign buf[0] = NULL;]
Cc: Jiri Kosina &lt;jikos@kernel.org&gt;
Cc: linux-input@vger.kernel.org
Signed-off-by: Darren Hart &lt;dvhart@linux.intel.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>parisc iommu: fix panic due to trying to allocate too large region</title>
<updated>2016-01-31T19:23:39+00:00</updated>
<author>
<name>Mikulas Patocka</name>
<email>mpatocka@redhat.com</email>
</author>
<published>2015-11-30T19:47:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c777e9ab2a44c802ca1453b820f9e3ff5dbe11a4'/>
<id>c777e9ab2a44c802ca1453b820f9e3ff5dbe11a4</id>
<content type='text'>
commit e46e31a3696ae2d66f32c207df3969613726e636 upstream.

When using the Promise TX2+ SATA controller on PA-RISC, the system often
crashes with kernel panic, for example just writing data with the dd
utility will make it crash.

Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources

CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
Backtrace:
 [&lt;000000004021497c&gt;] show_stack+0x14/0x20
 [&lt;0000000040410bf0&gt;] dump_stack+0x88/0x100
 [&lt;000000004023978c&gt;] panic+0x124/0x360
 [&lt;0000000040452c18&gt;] sba_alloc_range+0x698/0x6a0
 [&lt;0000000040453150&gt;] sba_map_sg+0x260/0x5b8
 [&lt;000000000c18dbb4&gt;] ata_qc_issue+0x264/0x4a8 [libata]
 [&lt;000000000c19535c&gt;] ata_scsi_translate+0xe4/0x220 [libata]
 [&lt;000000000c19a93c&gt;] ata_scsi_queuecmd+0xbc/0x320 [libata]
 [&lt;0000000040499bbc&gt;] scsi_dispatch_cmd+0xfc/0x130
 [&lt;000000004049da34&gt;] scsi_request_fn+0x6e4/0x970
 [&lt;00000000403e95a8&gt;] __blk_run_queue+0x40/0x60
 [&lt;00000000403e9d8c&gt;] blk_run_queue+0x3c/0x68
 [&lt;000000004049a534&gt;] scsi_run_queue+0x2a4/0x360
 [&lt;000000004049be68&gt;] scsi_end_request+0x1a8/0x238
 [&lt;000000004049de84&gt;] scsi_io_completion+0xfc/0x688
 [&lt;0000000040493c74&gt;] scsi_finish_command+0x17c/0x1d0

The cause of the crash is not exhaustion of the IOMMU space, there is
plenty of free pages. The function sba_alloc_range is called with size
0x11000, thus the pages_needed variable is 0x11. The function
sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
0x10 (because dma_get_seg_boundary(dev) returns 0xffff).

The function sba_search_bitmap attempts to allocate 17 pages that must not
cross 16-page boundary - it can't satisfy this requirement
(iommu_is_span_boundary always returns true) and fails even if there are
many free entries in the IOMMU space.

How did it happen that we try to allocate 17 pages that don't cross
16-page boundary? The cause is in the function iommu_coalesce_chunks. This
function tries to coalesce adjacent entries in the scatterlist. The
function does several checks if it may coalesce one entry with the next,
one of those checks is this:

	if (startsg-&gt;length + dma_len &gt; max_seg_size)
		break;

When it finishes coalescing adjacent entries, it allocates the mapping:

sg_dma_len(contig_sg) = dma_len;
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
sg_dma_address(contig_sg) =
	PIDE_FLAG
	| (iommu_alloc_range(ioc, dev, dma_len) &lt;&lt; IOVP_SHIFT)
	| dma_offset;

It is possible that (startsg-&gt;length + dma_len &gt; max_seg_size) is false
(we are just near the 0x10000 max_seg_size boundary), so the funcion
decides to coalesce this entry with the next entry. When the coalescing
succeeds, the function performs
	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
to allocate 17 pages for a device that must not cross 16-page boundary.

To fix the bug, we must make sure that dma_len after addition of
dma_offset and alignment doesn't cross the segment boundary. I.e. change
	if (startsg-&gt;length + dma_len &gt; max_seg_size)
		break;
to
	if (ALIGN(dma_len + dma_offset + startsg-&gt;length, IOVP_SIZE) &gt; max_seg_size)
		break;

This patch makes this change (it precalculates max_seg_boundary at the
beginning of the function iommu_coalesce_chunks). I also added a check
that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
not needed for Promise TX2+ SATA, but it may be needed for other devices
that have dma_get_seg_boundary lower than dma_get_max_seg_size).

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit e46e31a3696ae2d66f32c207df3969613726e636 upstream.

When using the Promise TX2+ SATA controller on PA-RISC, the system often
crashes with kernel panic, for example just writing data with the dd
utility will make it crash.

Kernel panic - not syncing: drivers/parisc/sba_iommu.c: I/O MMU @ 000000000000a000 is out of mapping resources

CPU: 0 PID: 18442 Comm: mkspadfs Not tainted 4.4.0-rc2 #2
Backtrace:
 [&lt;000000004021497c&gt;] show_stack+0x14/0x20
 [&lt;0000000040410bf0&gt;] dump_stack+0x88/0x100
 [&lt;000000004023978c&gt;] panic+0x124/0x360
 [&lt;0000000040452c18&gt;] sba_alloc_range+0x698/0x6a0
 [&lt;0000000040453150&gt;] sba_map_sg+0x260/0x5b8
 [&lt;000000000c18dbb4&gt;] ata_qc_issue+0x264/0x4a8 [libata]
 [&lt;000000000c19535c&gt;] ata_scsi_translate+0xe4/0x220 [libata]
 [&lt;000000000c19a93c&gt;] ata_scsi_queuecmd+0xbc/0x320 [libata]
 [&lt;0000000040499bbc&gt;] scsi_dispatch_cmd+0xfc/0x130
 [&lt;000000004049da34&gt;] scsi_request_fn+0x6e4/0x970
 [&lt;00000000403e95a8&gt;] __blk_run_queue+0x40/0x60
 [&lt;00000000403e9d8c&gt;] blk_run_queue+0x3c/0x68
 [&lt;000000004049a534&gt;] scsi_run_queue+0x2a4/0x360
 [&lt;000000004049be68&gt;] scsi_end_request+0x1a8/0x238
 [&lt;000000004049de84&gt;] scsi_io_completion+0xfc/0x688
 [&lt;0000000040493c74&gt;] scsi_finish_command+0x17c/0x1d0

The cause of the crash is not exhaustion of the IOMMU space, there is
plenty of free pages. The function sba_alloc_range is called with size
0x11000, thus the pages_needed variable is 0x11. The function
sba_search_bitmap is called with bits_wanted 0x11 and boundary size is
0x10 (because dma_get_seg_boundary(dev) returns 0xffff).

The function sba_search_bitmap attempts to allocate 17 pages that must not
cross 16-page boundary - it can't satisfy this requirement
(iommu_is_span_boundary always returns true) and fails even if there are
many free entries in the IOMMU space.

How did it happen that we try to allocate 17 pages that don't cross
16-page boundary? The cause is in the function iommu_coalesce_chunks. This
function tries to coalesce adjacent entries in the scatterlist. The
function does several checks if it may coalesce one entry with the next,
one of those checks is this:

	if (startsg-&gt;length + dma_len &gt; max_seg_size)
		break;

When it finishes coalescing adjacent entries, it allocates the mapping:

sg_dma_len(contig_sg) = dma_len;
dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
sg_dma_address(contig_sg) =
	PIDE_FLAG
	| (iommu_alloc_range(ioc, dev, dma_len) &lt;&lt; IOVP_SHIFT)
	| dma_offset;

It is possible that (startsg-&gt;length + dma_len &gt; max_seg_size) is false
(we are just near the 0x10000 max_seg_size boundary), so the funcion
decides to coalesce this entry with the next entry. When the coalescing
succeeds, the function performs
	dma_len = ALIGN(dma_len + dma_offset, IOVP_SIZE);
And now, because of non-zero dma_offset, dma_len is greater than 0x10000.
iommu_alloc_range (a pointer to sba_alloc_range) is called and it attempts
to allocate 17 pages for a device that must not cross 16-page boundary.

To fix the bug, we must make sure that dma_len after addition of
dma_offset and alignment doesn't cross the segment boundary. I.e. change
	if (startsg-&gt;length + dma_len &gt; max_seg_size)
		break;
to
	if (ALIGN(dma_len + dma_offset + startsg-&gt;length, IOVP_SIZE) &gt; max_seg_size)
		break;

This patch makes this change (it precalculates max_seg_boundary at the
beginning of the function iommu_coalesce_chunks). I also added a check
that the mapping length doesn't exceed dma_get_seg_boundary(dev) (it is
not needed for Promise TX2+ SATA, but it may be needed for other devices
that have dma_get_seg_boundary lower than dma_get_max_seg_size).

Signed-off-by: Mikulas Patocka &lt;mpatocka@redhat.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
