<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers, branch v3.10.85</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.85</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.85'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2015-08-03T16:29:47Z</updated>
<entry>
<title>qla2xxx: Mark port lost when we receive an RSCN for it.</title>
<updated>2015-08-03T16:29:47Z</updated>
<author>
<name>Chad Dupuis</name>
<email>chad.dupuis@qlogic.com</email>
</author>
<published>2014-09-25T09:17:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=40ce7fb598a3e1d56e333a770bf178e32b80cd37'/>
<id>urn:sha1:40ce7fb598a3e1d56e333a770bf178e32b80cd37</id>
<content type='text'>
commit ef86cb2059a14b4024c7320999ee58e938873032 upstream.

Signed-off-by: Chad Dupuis &lt;chad.dupuis@qlogic.com&gt;
Signed-off-by: Saurav Kashyap &lt;saurav.kashyap@qlogic.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Cc: Himanshu Madhani &lt;himanshu.madhani@qlogic.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Fix firmware loader uevent buffer NULL pointer dereference</title>
<updated>2015-08-03T16:29:47Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2015-07-09T18:20:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=27dbfee9cffffa812e56f8a1a2f84f91d1d9ad63'/>
<id>urn:sha1:27dbfee9cffffa812e56f8a1a2f84f91d1d9ad63</id>
<content type='text'>
commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c upstream.

The firmware class uevent function accessed the "fw_priv-&gt;buf" buffer
without the proper locking and testing for NULL.  This is an old bug
(looks like it goes back to 2012 and commit 1244691c73b2: "firmware
loader: introduce firmware_buf"), but for some reason it's triggering
only now in 4.2-rc1.

Shuah Khan is trying to bisect what it is that causes this to trigger
more easily, but in the meantime let's just fix the bug since others are
hitting it too (at least Ingo reports having seen it as well).

Reported-and-tested-by: Shuah Khan &lt;shuahkh@osg.samsung.com&gt;
Acked-by: Ming Lei &lt;ming.lei@canonical.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>agp/intel: Fix typo in needs_ilk_vtd_wa()</title>
<updated>2015-08-03T16:29:47Z</updated>
<author>
<name>Chris Wilson</name>
<email>chris@chris-wilson.co.uk</email>
</author>
<published>2015-06-28T13:18:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f626f57b4ebd92ef9270eca4aa49a541bc66ff27'/>
<id>urn:sha1:f626f57b4ebd92ef9270eca4aa49a541bc66ff27</id>
<content type='text'>
commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.

In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
the ids for the mobile GPU and the mobile host bridge. That latter is
impossible and so likely was just a typo for the desktop GPU device id
(which is also buggy).

Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
Author: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Date:   Wed Feb 13 09:31:53 2013 +0000

    drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Reported-by: Ting-Wei Lan &lt;lantw44@gmail.com&gt;
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
Signed-off-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rbd: use GFP_NOIO in rbd_obj_request_create()</title>
<updated>2015-08-03T16:29:47Z</updated>
<author>
<name>Ilya Dryomov</name>
<email>idryomov@gmail.com</email>
</author>
<published>2015-06-24T14:24:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d8c97a8db6c42be159f05dbe02729a85a543aa01'/>
<id>urn:sha1:d8c97a8db6c42be159f05dbe02729a85a543aa01</id>
<content type='text'>
commit 5a60e87603c4c533492c515b7f62578189b03c9c upstream.

rbd_obj_request_create() is called on the main I/O path, so we need to
use GFP_NOIO to make sure allocation doesn't blow back on us.  Not all
callers need this, but I'm still hardcoding the flag inside rather than
making it a parameter because a) this is going to stable, and b) those
callers shouldn't really use rbd_obj_request_create() and will be fixed
in the future.

More memory allocation fixes will follow.

Signed-off-by: Ilya Dryomov &lt;idryomov@gmail.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>watchdog: omap: assert the counter being stopped before reprogramming</title>
<updated>2015-08-03T16:29:47Z</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2015-04-29T18:38:46Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6afa955908877c770d18eb53a00bf8113fa9dab3'/>
<id>urn:sha1:6afa955908877c770d18eb53a00bf8113fa9dab3</id>
<content type='text'>
commit 530c11d432727c697629ad5f9d00ee8e2864d453 upstream.

The omap watchdog has the annoying behaviour that writes to most
registers don't have any effect when the watchdog is already running.
Quoting the AM335x reference manual:

	To modify the timer counter value (the WDT_WCRR register),
	prescaler ratio (the WDT_WCLR[4:2] PTV bit field), delay
	configuration value (the WDT_WDLY[31:0] DLY_VALUE bit field), or
	the load value (the WDT_WLDR[31:0] TIMER_LOAD bit field), the
	watchdog timer must be disabled by using the start/stop sequence
	(the WDT_WSPR register).

Currently the timer is stopped in the .probe callback but still there
are possibilities that yield to a situation where omap_wdt_start is
entered with the timer running (e.g. when /dev/watchdog is closed
without stopping and then reopened). In such a case programming the
timeout silently fails!

To circumvent this stop the timer before reprogramming.

Assuming one of the first things the watchdog user does is setting the
timeout explicitly nothing too bad should happen because this explicit
setting works fine.

Fixes: 7768a13c252a ("[PATCH] OMAP: Add Watchdog driver support")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Reviewed-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Wim Van Sebroeck &lt;wim@iguana.be&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: usbfs: allow URBs to be reaped after disconnection</title>
<updated>2015-08-03T16:29:47Z</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2015-01-29T16:29:13Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e17805417b3b213935a597e64592bae2a5daa2c4'/>
<id>urn:sha1:e17805417b3b213935a597e64592bae2a5daa2c4</id>
<content type='text'>
commit 3f2cee73b650921b2e214bf487b2061a1c266504 upstream.

The usbfs API has a peculiar hole: Users are not allowed to reap their
URBs after the device has been disconnected.  There doesn't seem to be
any good reason for this; it is an ad-hoc inconsistency.

The patch allows users to issue the USBDEVFS_REAPURB and
USBDEVFS_REAPURBNDELAY ioctls (together with their 32-bit counterparts
on 64-bit systems) even after the device is gone.  If no URBs are
pending for a disconnected device then the ioctls will return -ENODEV
rather than -EAGAIN, because obviously no new URBs will ever be able
to complete.

The patch also adds a new capability flag for
USBDEVFS_GET_CAPABILITIES to indicate that the reap-after-disconnect
feature is supported.

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Tested-by: Chris Dickens &lt;christopher.a.dickens@gmail.com&gt;
Acked-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mmc: card: Fixup request missing in mmc_blk_issue_rw_rq</title>
<updated>2015-08-03T16:29:46Z</updated>
<author>
<name>Ding Wang</name>
<email>justin.wang@spreadtrum.com</email>
</author>
<published>2015-05-18T12:14:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=21dd5b3d73c3964a0bdcebcc0f5227f38d2d85b2'/>
<id>urn:sha1:21dd5b3d73c3964a0bdcebcc0f5227f38d2d85b2</id>
<content type='text'>
commit 29535f7b797df35cc9b6b3bca635591cdd3dd2a8 upstream.

The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
may cause new coming request permanent missing when the ongoing
request (previoulsy started) complete end.

The problem scenario is as follows:
(1) Request A is ongoing;
(2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
(3) Request A encounters the MMC_BLK_CMD_ERR error;
(4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
    end request A completed and return zero. Continue the error handling,
    suppose mmc_blk_reset() reset device success;
(5) Continue the execution, while loop completed because variable ret
    is zero now;
(6) Finally, mmc_blk_issue_rw_rq() return without processing request B.

The process related to the missing request may wait that IO request
complete forever, possibly crashing the application or hanging the system.

Fix this issue by starting new request when reset success.

Signed-off-by: Ding Wang &lt;justin.wang@spreadtrum.com&gt;
Fixes: 67716327eec7 ("mmc: block: add eMMC hardware reset support")
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iser-target: release stale iser connections</title>
<updated>2015-08-03T16:29:46Z</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2015-06-04T16:49:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=45f29355a34aa73db8c3419168e57d5b185bf0fa'/>
<id>urn:sha1:45f29355a34aa73db8c3419168e57d5b185bf0fa</id>
<content type='text'>
commit 2f1b6b7d9a815f341b18dfd26a363f37d4d3c96a upstream.

When receiving a new iser connect request we serialize
the pending requests by adding the newly created iser connection
to the np accept list and let the login thread process the connect
request one by one (np_accept_wait).

In case we received a disconnect request before the iser_conn
has begun processing (still linked in np_accept_list) we should
detach it from the list and clean it up and not have the login
thread process a stale connection. We do it only when the connection
state is not already terminating (initiator driven disconnect) as
this might lead us to access np_accept_mutex after the np was released
in live shutdown scenarios.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Jenny Falkovich &lt;jennyf@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>iser-target: Fix possible deadlock in RDMA_CM connection error</title>
<updated>2015-08-03T16:29:46Z</updated>
<author>
<name>Sagi Grimberg</name>
<email>sagig@mellanox.com</email>
</author>
<published>2015-03-29T12:52:04Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=394adc1d4905b143a3f4f6a859a2253becc1101e'/>
<id>urn:sha1:394adc1d4905b143a3f4f6a859a2253becc1101e</id>
<content type='text'>
commit 4a579da2586bd3b79b025947ea24ede2bbfede62 upstream.

Before we reach to connection established we may get an
error event. In this case the core won't teardown this
connection (never established it), so we take care of freeing
it ourselves.

Signed-off-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>iscsi-target: Convert iscsi_thread_set usage to kthread.h</title>
<updated>2015-08-03T16:29:46Z</updated>
<author>
<name>Nicholas Bellinger</name>
<email>nab@linux-iscsi.org</email>
</author>
<published>2015-02-27T06:19:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=49b028d31aedc00f179c883e87f1b4f2cf55923b'/>
<id>urn:sha1:49b028d31aedc00f179c883e87f1b4f2cf55923b</id>
<content type='text'>
commit 88dcd2dab5c23b1c9cfc396246d8f476c872f0ca upstream.

This patch converts iscsi-target code to use modern kthread.h API
callers for creating RX/TX threads for each new iscsi_conn descriptor,
and releasing associated RX/TX threads during connection shutdown.

This is done using iscsit_start_kthreads() -&gt; kthread_run() to start
new kthreads from within iscsi_post_login_handler(), and invoking
kthread_stop() from existing iscsit_close_connection() code.

Also, convert iscsit_logout_post_handler_closesession() code to use
cmpxchg when determing when iscsit_cause_connection_reinstatement()
needs to sleep waiting for completion.

Reported-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Tested-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Cc: Slava Shwartsman &lt;valyushash@gmail.com&gt;
Signed-off-by: Nicholas Bellinger &lt;nab@linux-iscsi.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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