<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/scsi/scsi_lib.c, branch linux-4.4.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.4.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-07-20T14:22:36Z</updated>
<entry>
<title>scsi: core: Retry I/O for Notify (Enable Spinup) Required error</title>
<updated>2021-07-20T14:22:36Z</updated>
<author>
<name>Quat Le</name>
</author>
<published>2021-06-29T15:58:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=bbff172285ab312fbda8fab30fa5dd81e80d05f8'/>
<id>urn:sha1:bbff172285ab312fbda8fab30fa5dd81e80d05f8</id>
<content type='text'>
commit 104739aca4488909175e9e31d5cd7d75b82a2046 upstream.

If the device is power-cycled, it takes time for the initiator to transmit
the periodic NOTIFY (ENABLE SPINUP) SAS primitive, and for the device to
respond to the primitive to become ACTIVE. Retry the I/O request to allow
the device time to become ACTIVE.

Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210629155826.48441-1-quat.le@oracle.com
Reviewed-by: Bart Van Assche &lt;bvanassche@acm.org&gt;
Signed-off-by: Quat Le &lt;quat.le@oracle.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: return correct blkprep status code in case scsi_init_io() fails.</title>
<updated>2020-06-20T08:23:15Z</updated>
<author>
<name>Johannes Thumshirn</name>
</author>
<published>2017-04-12T07:21:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=9b37e23a447f1dcc654a48bbf4b23255e71a0325'/>
<id>urn:sha1:9b37e23a447f1dcc654a48bbf4b23255e71a0325</id>
<content type='text'>
commit e7661a8e5ce10b5321882d0bbaf3f81070903319 upstream.

When instrumenting the SCSI layer to run into the
!blk_rq_nr_phys_segments(rq) case the following warning emitted from the
block layer:

blk_peek_request: bad return=-22

This happens because since commit fd3fc0b4d730 ("scsi: don't BUG_ON()
empty DMA transfers") we return the wrong error value from
scsi_prep_fn() back to the block layer.

[mkp: silenced checkpatch]

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Fixes: fd3fc0b4d730 scsi: don't BUG_ON() empty DMA transfers
Cc: &lt;stable@vger.kernel.org&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
[iwamatsu: - backport for 4.4.y and 4.9.y
    - Use rq-&gt;nr_phys_segments instead of blk_rq_nr_phys_segments]
Signed-off-by: Nobuhiro Iwamatsu &lt;nobuhiro1.iwamatsu@toshiba.co.jp&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>scsi: use 'scsi_device_from_queue()' for scsi_dh</title>
<updated>2017-03-12T05:37:26Z</updated>
<author>
<name>Hannes Reinecke</name>
</author>
<published>2017-02-17T08:02:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=33950b56d2c20d10e85a0ab339e5368e8d029a2b'/>
<id>urn:sha1:33950b56d2c20d10e85a0ab339e5368e8d029a2b</id>
<content type='text'>
commit 857de6e00778738dc3d61f75acbac35bdc48e533 upstream.

The device handler needs to check if a given queue belongs to a scsi
device; only then does it make sense to attach a device handler.

[mkp: dropped flags]

Signed-off-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>scsi: don't BUG_ON() empty DMA transfers</title>
<updated>2017-02-23T16:43:09Z</updated>
<author>
<name>Johannes Thumshirn</name>
</author>
<published>2017-01-31T09:16:00Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8107096d243d8c0429513582da8919bfed5cd03d'/>
<id>urn:sha1:8107096d243d8c0429513582da8919bfed5cd03d</id>
<content type='text'>
commit fd3fc0b4d7305fa7246622dcc0dec69c42443f45 upstream.

Don't crash the machine just because of an empty transfer. Use WARN_ON()
combined with returning an error.

Found by Dmitry Vyukov and syzkaller.

[ Changed to "WARN_ON_ONCE()". Al has a patch that should fix the root
  cause, but a BUG_ON() is not acceptable in any case, and a WARN_ON()
  might still be a cause of excessive log spamming.

  NOTE! If this warning ever triggers, we may end up leaking resources,
  since this doesn't bother to try to clean the command up. So this
  WARN_ON_ONCE() triggering does imply real problems. But BUG_ON() is
  much worse.

  People really need to stop using BUG_ON() for "this shouldn't ever
  happen". It makes pretty much any bug worse.     - Linus ]

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reported-by: Dmitry Vyukov &lt;dvyukov@google.com&gt;
Cc: James Bottomley &lt;jejb@linux.vnet.ibm.com&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&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>scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands</title>
<updated>2016-06-24T17:18:16Z</updated>
<author>
<name>James Bottomley</name>
</author>
<published>2016-05-13T19:04:06Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0dec8c0d67c64401d97122e4eba347ccc5850622'/>
<id>urn:sha1:0dec8c0d67c64401d97122e4eba347ccc5850622</id>
<content type='text'>
commit a621bac3044ed6f7ec5fa0326491b2d4838bfa93 upstream.

When SCSI was written, all commands coming from the filesystem
(REQ_TYPE_FS commands) had data.  This meant that our signal for needing
to complete the command was the number of bytes completed being equal to
the number of bytes in the request.  Unfortunately, with the advent of
flush barriers, we can now get zero length REQ_TYPE_FS commands, which
confuse this logic because they satisfy the condition every time.  This
means they never get retried even for retryable conditions, like UNIT
ATTENTION because we complete them early assuming they're done.  Fix
this by special casing the early completion condition to recognise zero
length commands with errors and let them drop through to the retry code.

Reported-by: Sebastian Parschauer &lt;s.parschauer@gmx.de&gt;
Signed-off-by: James E.J. Bottomley &lt;jejb@linux.vnet.ibm.com&gt;
Tested-by: Jack Wang &lt;jinpu.wang@profitbricks.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mm, page_alloc: rename __GFP_WAIT to __GFP_RECLAIM</title>
<updated>2015-11-07T01:50:42Z</updated>
<author>
<name>Mel Gorman</name>
</author>
<published>2015-11-07T00:28:28Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=71baba4b92dc1fa1bc461742c6ab1942ec6034e9'/>
<id>urn:sha1:71baba4b92dc1fa1bc461742c6ab1942ec6034e9</id>
<content type='text'>
__GFP_WAIT was used to signal that the caller was in atomic context and
could not sleep.  Now it is possible to distinguish between true atomic
context and callers that are not willing to sleep.  The latter should
clear __GFP_DIRECT_RECLAIM so kswapd will still wake.  As clearing
__GFP_WAIT behaves differently, there is a risk that people will clear the
wrong flags.  This patch renames __GFP_WAIT to __GFP_RECLAIM to clearly
indicate what it does -- setting it allows all reclaim activity, clearing
them prevents it.

[akpm@linux-foundation.org: fix build]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Mel Gorman &lt;mgorman@techsingularity.net&gt;
Acked-by: Michal Hocko &lt;mhocko@suse.com&gt;
Acked-by: Vlastimil Babka &lt;vbabka@suse.cz&gt;
Acked-by: Johannes Weiner &lt;hannes@cmpxchg.org&gt;
Cc: Christoph Lameter &lt;cl@linux.com&gt;
Acked-by: David Rientjes &lt;rientjes@google.com&gt;
Cc: Vitaly Wool &lt;vitalywool@gmail.com&gt;
Cc: Rik van Riel &lt;riel@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>blk-mq: fix racy updates of rq-&gt;errors</title>
<updated>2015-10-01T08:10:55Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2015-09-27T19:01:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f4829a9b7a61e159367350008a608b062c4f6840'/>
<id>urn:sha1:f4829a9b7a61e159367350008a608b062c4f6840</id>
<content type='text'>
blk_mq_complete_request may be a no-op if the request has already
been completed by others means (e.g. a timeout or cancellation), but
currently drivers have to set rq-&gt;errors before calling
blk_mq_complete_request, which might leave us with the wrong error value.

Add an error parameter to blk_mq_complete_request so that we can
defer setting rq-&gt;errors until we known we won the race to complete the
request.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Sagi Grimberg &lt;sagig@mellanox.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
</content>
</entry>
<entry>
<title>scsi_dh: kill struct scsi_dh_data</title>
<updated>2015-08-28T20:14:57Z</updated>
<author>
<name>Christoph Hellwig</name>
</author>
<published>2015-08-27T12:16:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ee14c674e8fc57251223054fb52dc0ecfe711028'/>
<id>urn:sha1:ee14c674e8fc57251223054fb52dc0ecfe711028</id>
<content type='text'>
Add a -&gt;handler and a -&gt;handler_data field to struct scsi_device and kill
this indirection.  Also move struct scsi_device_handler to scsi_dh.h so that
changes to it don't require rebuilding every SCSI LLDD.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
</content>
</entry>
<entry>
<title>scsi: Add ALUA state change UA handling</title>
<updated>2015-08-26T14:19:57Z</updated>
<author>
<name>Hannes Reinecke</name>
</author>
<published>2015-07-06T11:41:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=14c3e677df9fa2e4bf87b9de683452fc140934b2'/>
<id>urn:sha1:14c3e677df9fa2e4bf87b9de683452fc140934b2</id>
<content type='text'>
Log the ALUA state change unit attention correctly with
the message log and emit an event to allow user-space
tools to react to it.

Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
</content>
</entry>
<entry>
<title>scsi: retry MODE SENSE on unit attention</title>
<updated>2015-07-30T19:37:20Z</updated>
<author>
<name>Hannes Reinecke</name>
</author>
<published>2015-06-12T14:12:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0ae80ba91f57726f31b5b5890cb7c5173e624ca4'/>
<id>urn:sha1:0ae80ba91f57726f31b5b5890cb7c5173e624ca4</id>
<content type='text'>
The 'sd' driver is calling scsi_mode_sense() to figure out
internal details. But scsi_mode_sense() never checks for
any pending unit attentions, so we're getting annoying error
messages like:

MODE SENSE: unimplemented page/subpage: 0x00/0x00

and a possible wrong decision for device cache handling.

Reviewed-by: Ewan Milne &lt;emilne@redhat.com&gt;
Signed-off-by: Hannes Reinecke &lt;hare@suse.de&gt;
Signed-off-by: James Bottomley &lt;JBottomley@Odin.com&gt;
</content>
</entry>
</feed>
