<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/block, branch v3.10.47</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/block?h=v3.10.47</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/block?h=v3.10.47'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-07-07T01:54:13Z</updated>
<entry>
<title>mtip32xx: Remove dfs_parent after pci unregister</title>
<updated>2014-07-07T01:54:13Z</updated>
<author>
<name>Asai Thambi S P</name>
<email>asamymuthupa@micron.com</email>
</author>
<published>2014-04-17T03:30:16Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e03da047fbec64d868f54e06d2c9b77c37619351'/>
<id>urn:sha1:e03da047fbec64d868f54e06d2c9b77c37619351</id>
<content type='text'>
commit af5ded8ccf21627f9614afc03b356712666ed225 upstream.

In module exit, dfs_parent and it's subtree were removed before
unregistering with pci. When debugfs entry for each device is attempted
to remove in pci_remove() context, they don't exist, as dfs_parent and
its children were already ripped apart.

Modified to first unregister with pci and then remove dfs_parent.

Signed-off-by: Asai Thambi S P &lt;asamymuthupa@micron.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtip32xx: Increase timeout for STANDBY IMMEDIATE command</title>
<updated>2014-07-07T01:54:13Z</updated>
<author>
<name>Asai Thambi S P</name>
<email>asamymuthupa@micron.com</email>
</author>
<published>2014-04-17T03:27:54Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=18c1e8433a6fefb91357264977065210695394e4'/>
<id>urn:sha1:18c1e8433a6fefb91357264977065210695394e4</id>
<content type='text'>
commit 670a641420a3d9586eebe7429dfeec4e7ed447aa upstream.

Increased timeout for STANDBY IMMEDIATE command to 2 minutes.

Signed-off-by: Selvan Mani &lt;smani@micron.com&gt;
Signed-off-by: Asai Thambi S P &lt;asamymuthupa@micron.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtip32xx: Fix ERO and NoSnoop values in PCIe upstream on AMD systems</title>
<updated>2014-07-07T01:54:13Z</updated>
<author>
<name>Asai Thambi S P</name>
<email>asamymuthupa@micron.com</email>
</author>
<published>2014-03-14T01:45:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=14cee64356c626b001739400ec30a34b0d5f6dc6'/>
<id>urn:sha1:14cee64356c626b001739400ec30a34b0d5f6dc6</id>
<content type='text'>
commit d1e714db8129a1d3670e449b87719c78e2c76f9f upstream.

A hardware quirk in P320h/P420m interfere with PCIe transactions on some
AMD chipsets, making P320h/P420m unusable. This workaround is to disable
ERO and NoSnoop bits in the parent and root complex for normal
functioning of these devices

NOTE: This workaround is specific to AMD chipset with a PCIe upstream
device with device id 0x5aXX

Signed-off-by: Asai Thambi S P &lt;asamymuthupa@micron.com&gt;
Signed-off-by: Sam Bradshaw &lt;sbradshaw@micron.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen-blkfront: restore the non-persistent data path</title>
<updated>2014-06-07T20:25:37Z</updated>
<author>
<name>Roger Pau Monne</name>
<email>roger.pau@citrix.com</email>
</author>
<published>2013-10-29T17:31:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d642daf637d02dacf216d7fd9da7532a4681cfd3'/>
<id>urn:sha1:d642daf637d02dacf216d7fd9da7532a4681cfd3</id>
<content type='text'>
commit bfe11d6de1c416cea4f3f0f35f864162063ce3fa upstream.

When persistent grants were added they were always used, even if the
backend doesn't have this feature (there's no harm in always using the
same set of pages). This restores the old data path when the backend
doesn't have persistent grants, removing the burden of doing a memcpy
when it is not actually needed.

Signed-off-by: Roger Pau Monné &lt;roger.pau@citrix.com&gt;
Reported-by: Felipe Franciosi &lt;felipe.franciosi@citrix.com&gt;
Cc: Felipe Franciosi &lt;felipe.franciosi@citrix.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Cc: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
[v2: Fix up whitespace issues]
Tested-by: Felipe Franciosi &lt;felipe@paradoxo.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xen-blkfront: revoke foreign access for grants not mapped by the backend</title>
<updated>2014-06-07T20:25:37Z</updated>
<author>
<name>Roger Pau Monne</name>
<email>roger.pau@citrix.com</email>
</author>
<published>2013-08-12T10:53:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ba4abe2e7f32f6d7fe3d92eeb4b1748c10b5f601'/>
<id>urn:sha1:ba4abe2e7f32f6d7fe3d92eeb4b1748c10b5f601</id>
<content type='text'>
commit fbe363c476afe8ec992d3baf682670a4bd1b6ce6 upstream.

There's no need to keep the foreign access in a grant if it is not
persistently mapped by the backend. This allows us to free grants that
are not mapped by the backend, thus preventing blkfront from hoarding
all grants.

The main effect of this is that blkfront will only persistently map
the same grants as the backend, and it will always try to use grants
that are already mapped by the backend. Also the number of persistent
grants in blkfront is the same as in blkback (and is controlled by the
value in blkback).

Signed-off-by: Roger Pau Monné &lt;roger.pau@citrix.com&gt;
Reviewed-by: David Vrabel &lt;david.vrabel@citrix.com&gt;
Acked-by: Matt Wilson &lt;msw@amazon.com&gt;
Cc: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Cc: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>rbd: fix error paths in rbd_img_request_fill()</title>
<updated>2014-05-31T04:52:12Z</updated>
<author>
<name>Ilya Dryomov</name>
<email>ilya.dryomov@inktank.com</email>
</author>
<published>2014-03-04T09:57:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=04168b98a30d5257d20a7213f58ff0b27174e489'/>
<id>urn:sha1:04168b98a30d5257d20a7213f58ff0b27174e489</id>
<content type='text'>
commit 42dd037c08c7cd6e3e9af7824b0c1d063f838885 upstream.

Doing rbd_obj_request_put() in rbd_img_request_fill() error paths is
not only insufficient, but also triggers an rbd_assert() in
rbd_obj_request_destroy():

    Assertion failure in rbd_obj_request_destroy() at line 1867:

    rbd_assert(obj_request-&gt;img_request == NULL);

rbd_img_obj_request_add() adds obj_requests to the img_request, the
opposite is rbd_img_obj_request_del().  Use it.

Fixes: http://tracker.ceph.com/issues/7327

Signed-off-by: Ilya Dryomov &lt;ilya.dryomov@inktank.com&gt;
Reviewed-by: Alex Elder &lt;elder@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>floppy: don't write kernel-only members to FDRAWCMD ioctl output</title>
<updated>2014-05-13T11:59:40Z</updated>
<author>
<name>Matthew Daley</name>
<email>mattd@bugfuzz.com</email>
</author>
<published>2014-04-28T07:05:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=50c648e394a0968f19d448b70bec82da88219963'/>
<id>urn:sha1:50c648e394a0968f19d448b70bec82da88219963</id>
<content type='text'>
commit 2145e15e0557a01b9195d1c7199a1b92cb9be81f upstream.

Do not leak kernel-only floppy_raw_cmd structure members to userspace.
This includes the linked-list pointer and the pointer to the allocated
DMA space.

Signed-off-by: Matthew Daley &lt;mattd@bugfuzz.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>floppy: ignore kernel-only members in FDRAWCMD ioctl input</title>
<updated>2014-05-13T11:59:40Z</updated>
<author>
<name>Matthew Daley</name>
<email>mattd@bugfuzz.com</email>
</author>
<published>2014-04-28T07:05:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=21506304588afab20b2d52aaa56b70e85aca6386'/>
<id>urn:sha1:21506304588afab20b2d52aaa56b70e85aca6386</id>
<content type='text'>
commit ef87dbe7614341c2e7bfe8d32fcb7028cc97442c upstream.

Always clear out these floppy_raw_cmd struct members after copying the
entire structure from userspace so that the in-kernel version is always
valid and never left in an interdeterminate state.

Signed-off-by: Matthew Daley &lt;mattd@bugfuzz.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mtip32xx: Set queue bounce limit</title>
<updated>2014-05-06T14:55:32Z</updated>
<author>
<name>Felipe Franciosi</name>
<email>felipe@paradoxo.org</email>
</author>
<published>2014-03-13T14:34:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=981752df71cfdab8096cb44a76a9b597cdde8796'/>
<id>urn:sha1:981752df71cfdab8096cb44a76a9b597cdde8796</id>
<content type='text'>
commit 1044b1bb9278f2e656a1a7b63dc24a59506540aa upstream.

We need to set the queue bounce limit during the device initialization to
prevent excessive bouncing on 32 bit architectures.

Signed-off-by: Felipe Franciosi &lt;felipe@paradoxo.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm: close PageTail race</title>
<updated>2014-04-03T19:01:05Z</updated>
<author>
<name>David Rientjes</name>
<email>rientjes@google.com</email>
</author>
<published>2014-03-03T23:38:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=def52acc90faab583b124f3177d55c15d125e2d1'/>
<id>urn:sha1:def52acc90faab583b124f3177d55c15d125e2d1</id>
<content type='text'>
commit 668f9abbd4334e6c29fa8acd71635c4f9101caa7 upstream.

Commit bf6bddf1924e ("mm: introduce compaction and migration for
ballooned pages") introduces page_count(page) into memory compaction
which dereferences page-&gt;first_page if PageTail(page).

This results in a very rare NULL pointer dereference on the
aforementioned page_count(page).  Indeed, anything that does
compound_head(), including page_count() is susceptible to racing with
prep_compound_page() and seeing a NULL or dangling page-&gt;first_page
pointer.

This patch uses Andrea's implementation of compound_trans_head() that
deals with such a race and makes it the default compound_head()
implementation.  This includes a read memory barrier that ensures that
if PageTail(head) is true that we return a head page that is neither
NULL nor dangling.  The patch then adds a store memory barrier to
prep_compound_page() to ensure page-&gt;first_page is set.

This is the safest way to ensure we see the head page that we are
expecting, PageTail(page) is already in the unlikely() path and the
memory barriers are unfortunately required.

Hugetlbfs is the exception, we don't enforce a store memory barrier
during init since no race is possible.

Signed-off-by: David Rientjes &lt;rientjes@google.com&gt;
Cc: Holger Kiehl &lt;Holger.Kiehl@dwd.de&gt;
Cc: Christoph Lameter &lt;cl@linux.com&gt;
Cc: Rafael Aquini &lt;aquini@redhat.com&gt;
Cc: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Cc: Michal Hocko &lt;mhocko@suse.cz&gt;
Cc: Mel Gorman &lt;mgorman@suse.de&gt;
Cc: Andrea Arcangeli &lt;aarcange@redhat.com&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Cc: "Kirill A. Shutemov" &lt;kirill.shutemov@linux.intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;



</content>
</entry>
</feed>
