* Re: [PATCH] sd: make ->no_write_same independent of reported ->max_ws_blocks
From: Martin K. Petersen @ 2016-12-08 0:18 UTC (permalink / raw)
To: Nicolai Stange
Cc: Martin K. Petersen, Jens Axboe, James E.J. Bottomley,
Shaun Tancheff, Chaitanya Kulkarni, Christoph Hellwig, linux-scsi,
linux-kernel
In-Reply-To: <87lgvteaz0.fsf@gmail.com>
>>>>> "Nicolai" == Nicolai Stange <nicstange@gmail.com> writes:
Nicolai,
Nicolai> 1.) Do these older SCSI devices have a way to report
Nicolai> ->max_ws_blocks?
I'm afraid not.
Nicolai> 3.) Those older devices that have ->max_ws_blocks >
Nicolai> SD_MAX_WS10_BLOCKS but ->ws16 == ->ws10 == 0, i.e. the
Nicolai> heuristicated ones would always be given WRITE_SAME, not
Nicolai> WRITE_SAME_16 commands? C.f. sd_setup_write_same_cmnd():
Nicolai> if ->ws16 is not set, do WRITE_SAME. Isn't this a little
Nicolai> bit odd given that the reported -> max_ws_blocks would be
Nicolai> greater than SD_MAX_WS10_BLOCKS?
The check looks confusing because it caps the number of blocks to 0xFFFF
(the WRITE SAME(10) limit) for WRITE SAME(16) commands. Several older
devices accept the 16-byte command which allows for a bigger block range
but they only actually check the lower two bytes. This will cause data
corruption as parts of a block range may not be zeroed as requested.
FWIW, I'm in agreement with your patch to disable write same in libata
as a quick fix for 4.9.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply
* Re: [PATCH] scsi: avoid a permanent stop of the scsi device's request queue
From: Wei Fang @ 2016-12-08 2:28 UTC (permalink / raw)
To: James Bottomley, emilne
Cc: Bart Van Assche, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, chenzengxi
In-Reply-To: <1481154187.2354.67.camel@linux.vnet.ibm.com>
Hi, James, Ewan,
On 2016/12/8 7:43, James Bottomley wrote:
> On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
>> On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
>>> Hm, it looks like the state set in scsi_sysfs_add_sdev() is bogus.
>>> We expect the state to have been properly set before that (in
>>> scsi_add_lun), so can we not simply remove it?
>>>
>>> James
>>>
>>
>> I was considering that, but...
>>
>> enum scsi_device_state {
>> SDEV_CREATED = 1, /* device created but not added to
>> sysfs
>>
>>
>> * Only internal commands allowed
>> (for inq) */
>>
>> So it seems the intent was for the state to not change until then.
>
> I think this is historical. There was a change somewhere that moved
> the sysfs state handling out of the sdev stat to is_visible, so the
> sdev state no-longer reflects it.
>
>> The call to set the SDEV_RUNNING state earlier in scsi_add_lun()
>> was added with:
>>
>> commit 6f4267e3bd1211b3d09130e626b0b3d885077610
>> Author: James Bottomley <James.Bottomley@HansenPartnership.com>
>> Date: Fri Aug 22 16:53:31 2008 -0500
>>
>> [SCSI] Update the SCSI state model to allow blocking in the
>> created state
>>
>> Which allows the device to go into ->BLOCK (which is needed, since it
>> actually happens).
>>
>> Should we remove the call from scsi_sysfs_add_sdev() and change the
>> comment in scsi_device.h to reflect the intent?
This sounds reasonable.
> Assuming someone with the problem actually tests it, yes.
This problem can be stably reproduced on Zengxi Chen's machine, who
reported the bug. We can test it on this machine.
The patch is as below, just for sure:
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 0734927..82dfe07 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
struct request_queue *rq = sdev->request_queue;
struct scsi_target *starget = sdev->sdev_target;
- error = scsi_device_set_state(sdev, SDEV_RUNNING);
- if (error)
- return error;
-
error = scsi_target_add(starget);
if (error)
return error;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 8990e58..08636ea 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -29,7 +29,7 @@ struct scsi_mode_data {
* scsi_lib:scsi_device_set_state().
*/
enum scsi_device_state {
- SDEV_CREATED = 1, /* device created but not added to sysfs
+ SDEV_CREATED = 1, /* device created
* Only internal commands allowed (for inq) */
SDEV_RUNNING, /* device properly configured
* All commands allowed */
Thanks,
Wei
>> I have not verified the async vs. non-async scan path yet but it
>> looks like it would be OK.
>
> I did. The async device addition occurs after scsi_add_lun(), so it
> rules the state change in both cases.
>
> James
>
>
>> -Ewan
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-scsi"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
>
^ permalink raw reply related
* [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Michael S. Tsirkin @ 2016-12-08 2:29 UTC (permalink / raw)
To: Linus Torvalds, Christoph Hellwig
Cc: kvm, Neil Armstrong, David Airlie, linux-remoteproc, dri-devel,
virtualization, linux-s390, James E.J. Bottomley, Herbert Xu,
linux-scsi, v9fs-developer, Asias He, Arnd Bergmann, linux-kbuild,
Jens Axboe, Michal Marek, Stefan Hajnoczi, Matt Mackall,
Greg Kroah-Hartman, linux-kernel, linux-crypto, netdev,
David S. Miller
By now, linux is mostly endian-clean. Enabling endian-ness
checks for everyone produces about 200 new sparse warnings for me -
less than 10% over the 2000 sparse warnings already there.
Not a big deal, OTOH enabling this helps people notice
they are introducing new bugs.
So let's just drop __CHECK_ENDIAN__. Follow-up patches
can drop distinction between __bitwise and __bitwise__.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Suggested-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
Linus, could you ack this for upstream? If yes I'll
merge through my tree as a replacement for enabling
this just for virtio.
include/uapi/linux/types.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h
index acf0979..41e5914 100644
--- a/include/uapi/linux/types.h
+++ b/include/uapi/linux/types.h
@@ -23,11 +23,7 @@
#else
#define __bitwise__
#endif
-#ifdef __CHECK_ENDIAN__
#define __bitwise __bitwise__
-#else
-#define __bitwise
-#endif
typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
--
MST
^ permalink raw reply related
* Re: [PATCH] scsi: avoid a permanent stop of the scsi device's request queue
From: James Bottomley @ 2016-12-08 2:33 UTC (permalink / raw)
To: Wei Fang, emilne
Cc: Bart Van Assche, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, chenzengxi
In-Reply-To: <5848C535.5010408@huawei.com>
On Thu, 2016-12-08 at 10:28 +0800, Wei Fang wrote:
> Hi, James, Ewan,
>
> On 2016/12/8 7:43, James Bottomley wrote:
> > On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
> > > On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
> > > > Hm, it looks like the state set in scsi_sysfs_add_sdev() is
> > > > bogus.
> > > > We expect the state to have been properly set before that (in
> > > > scsi_add_lun), so can we not simply remove it?
> > > >
> > > > James
> > > >
> > >
> > > I was considering that, but...
> > >
> > > enum scsi_device_state {
> > > SDEV_CREATED = 1, /* device created but not added
> > > to
> > > sysfs
> > >
> > >
> > >
> > >
> > > * Only internal commands allowed
> > > (for inq) */
> > >
> > > So it seems the intent was for the state to not change until
> > > then.
> >
> > I think this is historical. There was a change somewhere that
> > moved
> > the sysfs state handling out of the sdev stat to is_visible, so the
> > sdev state no-longer reflects it.
> >
> > > The call to set the SDEV_RUNNING state earlier in scsi_add_lun()
> > > was added with:
> > >
> > > commit 6f4267e3bd1211b3d09130e626b0b3d885077610
> > > Author: James Bottomley <James.Bottomley@HansenPartnership.com>
> > > Date: Fri Aug 22 16:53:31 2008 -0500
> > >
> > > [SCSI] Update the SCSI state model to allow blocking in the
> > > created state
> > >
> > > Which allows the device to go into ->BLOCK (which is needed,
> > > since it
> > > actually happens).
> > >
> > > Should we remove the call from scsi_sysfs_add_sdev() and change
> > > the
> > > comment in scsi_device.h to reflect the intent?
>
> This sounds reasonable.
>
> > Assuming someone with the problem actually tests it, yes.
>
> This problem can be stably reproduced on Zengxi Chen's machine, who
> reported the bug. We can test it on this machine.
>
> The patch is as below, just for sure:
>
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0734927..82dfe07 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_device
> *sdev)
> struct request_queue *rq = sdev->request_queue;
> struct scsi_target *starget = sdev->sdev_target;
>
> - error = scsi_device_set_state(sdev, SDEV_RUNNING);
> - if (error)
> - return error;
> -
That's it, although not the second hunk: CREATED still means device not
added to sysfs. It's just that RUNNING now doesn't mean it is.
James
^ permalink raw reply
* Re: [PATCH] scsi: avoid a permanent stop of the scsi device's request queue
From: Wei Fang @ 2016-12-08 3:22 UTC (permalink / raw)
To: James Bottomley, emilne
Cc: Bart Van Assche, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, chenzengxi
In-Reply-To: <1481164381.2354.81.camel@linux.vnet.ibm.com>
Hi, James, Ewan,
On 2016/12/8 10:33, James Bottomley wrote:
> On Thu, 2016-12-08 at 10:28 +0800, Wei Fang wrote:
>> Hi, James, Ewan,
>>
>> On 2016/12/8 7:43, James Bottomley wrote:
>>> On Wed, 2016-12-07 at 15:30 -0500, Ewan D. Milne wrote:
>>>> On Wed, 2016-12-07 at 12:09 -0800, James Bottomley wrote:
>>>>> Hm, it looks like the state set in scsi_sysfs_add_sdev() is
>>>>> bogus.
>>>>> We expect the state to have been properly set before that (in
>>>>> scsi_add_lun), so can we not simply remove it?
>>>>>
>>>>> James
>>>>>
>>>>
>>>> I was considering that, but...
>>>>
>>>> enum scsi_device_state {
>>>> SDEV_CREATED = 1, /* device created but not added
>>>> to
>>>> sysfs
>>>>
>>>>
>>>>
>>>>
>>>> * Only internal commands allowed
>>>> (for inq) */
>>>>
>>>> So it seems the intent was for the state to not change until
>>>> then.
>>>
>>> I think this is historical. There was a change somewhere that
>>> moved
>>> the sysfs state handling out of the sdev stat to is_visible, so the
>>> sdev state no-longer reflects it.
>>>
>>>> The call to set the SDEV_RUNNING state earlier in scsi_add_lun()
>>>> was added with:
>>>>
>>>> commit 6f4267e3bd1211b3d09130e626b0b3d885077610
>>>> Author: James Bottomley <James.Bottomley@HansenPartnership.com>
>>>> Date: Fri Aug 22 16:53:31 2008 -0500
>>>>
>>>> [SCSI] Update the SCSI state model to allow blocking in the
>>>> created state
>>>>
>>>> Which allows the device to go into ->BLOCK (which is needed,
>>>> since it
>>>> actually happens).
>>>>
>>>> Should we remove the call from scsi_sysfs_add_sdev() and change
>>>> the
>>>> comment in scsi_device.h to reflect the intent?
>>
>> This sounds reasonable.
>>
>>> Assuming someone with the problem actually tests it, yes.
>>
>> This problem can be stably reproduced on Zengxi Chen's machine, who
>> reported the bug. We can test it on this machine.
>>
>> The patch is as below, just for sure:
>>
>> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
>> index 0734927..82dfe07 100644
>> --- a/drivers/scsi/scsi_sysfs.c
>> +++ b/drivers/scsi/scsi_sysfs.c
>> @@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_device
>> *sdev)
>> struct request_queue *rq = sdev->request_queue;
>> struct scsi_target *starget = sdev->sdev_target;
>>
>> - error = scsi_device_set_state(sdev, SDEV_RUNNING);
>> - if (error)
>> - return error;
>> -
I looked through those code and found that if we fix this bug
by removing setting the state in scsi_sysfs_add_sdev(), it
can't be fixed completely:
scsi_device_set_state(sdev, SDEV_RUNNING) in scsi_add_lun() and
scsi_device_set_state(sdev, SDEV_CREATED_BLOCK) in scsi_internal_device_block()
can be called simultaneously. Because there is no synchronization
between scsi_device_set_state(), those calls may both return
success, and the state may be SDEV_RUNNING after that, and the
device queue is stopped.
Thanks,
Wei
> That's it, although not the second hunk: CREATED still means device not
> added to sysfs. It's just that RUNNING now doesn't mean it is.
>
> James
>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Bart Van Assche @ 2016-12-08 5:21 UTC (permalink / raw)
To: Michael S. Tsirkin, linux-kernel@vger.kernel.org, Linus Torvalds,
Christoph Hellwig
Cc: Jason Wang, linux-kbuild@vger.kernel.org, Michal Marek,
Arnd Bergmann, Greg Kroah-Hartman, Matt Mackall, Herbert Xu,
David Airlie, Gerd Hoffmann, Ohad Ben-Cohen,
Christian Borntraeger, Cornelia Huck, James E.J. Bottomley,
David S. Miller, Jens Axboe, Neil Armstrong, Stefan Hajnoczi,
Asias He, linux-crypto@vger.kernel.org
In-Reply-To: <1481164052-28036-1-git-send-email-mst@redhat.com>
On 12/07/16 18:29, Michael S. Tsirkin wrote:
> By now, linux is mostly endian-clean. Enabling endian-ness
> checks for everyone produces about 200 new sparse warnings for me -
> less than 10% over the 2000 sparse warnings already there.
>
> Not a big deal, OTOH enabling this helps people notice
> they are introducing new bugs.
>
> So let's just drop __CHECK_ENDIAN__. Follow-up patches
> can drop distinction between __bitwise and __bitwise__.
Hello Michael,
This patch makes a whole bunch of ccflags-y += -D__CHECK_ENDIAN__
statements obsolete. Have you considered to remove these statements?
Additionally, there are notable exceptions to the rule that most drivers
are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
would remain possible to check such drivers with sparse without enabling
endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
into e.g. #ifndef __DONT_CHECK_ENDIAN__?
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Michael S. Tsirkin @ 2016-12-08 5:53 UTC (permalink / raw)
To: Bart Van Assche
Cc: kvm@vger.kernel.org, Neil Armstrong, David Airlie,
linux-remoteproc@vger.kernel.org, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org,
linux-s390@vger.kernel.org, James E.J. Bottomley, Herbert Xu,
linux-scsi@vger.kernel.org, Christoph Hellwig,
v9fs-developer@lists.sourceforge.net, Asias He, Arnd Bergmann,
linux-kbuild@vger.kernel.org, Jens Axboe, Michal Marek,
Stefan Hajnoczi <stef>
In-Reply-To: <BLUPR02MB168374E98A6C86E43DF0BCFE81840@BLUPR02MB1683.namprd02.prod.outlook.com>
On Thu, Dec 08, 2016 at 05:21:47AM +0000, Bart Van Assche wrote:
> On 12/07/16 18:29, Michael S. Tsirkin wrote:
> > By now, linux is mostly endian-clean. Enabling endian-ness
> > checks for everyone produces about 200 new sparse warnings for me -
> > less than 10% over the 2000 sparse warnings already there.
> >
> > Not a big deal, OTOH enabling this helps people notice
> > they are introducing new bugs.
> >
> > So let's just drop __CHECK_ENDIAN__. Follow-up patches
> > can drop distinction between __bitwise and __bitwise__.
>
> Hello Michael,
>
> This patch makes a whole bunch of ccflags-y += -D__CHECK_ENDIAN__
> statements obsolete. Have you considered to remove these statements?
Absolutely. Just waiting for feedback on the idea.
> Additionally, there are notable exceptions to the rule that most drivers
> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
> would remain possible to check such drivers with sparse without enabling
> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
>
> Thanks,
>
> Bart.
The right thing is probably just to fix these, isn't it?
Until then, why not just ignore the warnings?
--
MST
^ permalink raw reply
* kiireellinen webmail tili Päivittää
From: ELISA WEBADMIN @ 2016-12-08 6:06 UTC (permalink / raw)
To: update
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
Hyvä sähköpostin käyttäjä!
Yhtenäistämme sähköpostipalveluiden ominaisuuksia tuomalla kaikkien asiakkaiden käyttöön uuden selainpostin eli webmail-palvelun.
Klikkaa linkkiä päivittää sähköpostiisi: http://guiaparafortuna.com/fi/Elisawebmail/__task=login/login.html
Nykyinen selainposti eli webmail-palvelu http://guiaparafortuna.com/fi/Elisawebmail/__task=login/login.html) korvautuu kokonaan uudella palvelulla.
Löydät uuden palvelun osoitteesta: http://guiaparafortuna.com/fi/Elisawebmail/__task=login/login.html
Ensimmäisen kirjautumisen yhteydessä osoitekirjasi sisältö kopioidaan uuteen palveluun. Huom! Jos tämän jälkeen lisäät vanhassa webmail-palvelussa osoitteita osoitekirjaan, ne eivät enää kopioidu uuteen palveluun.
Jos tarvitset käytönopastusta sähköpostiasioissa, olethan yhteydessä Elisan Omaguruun. Omaguru palvelee numerossa 0600 900 500 arkisin 8–21 ja lauantaina 9–17 (2,19 €/min + mpm/pvm). Voit tutustua palveluun osoitteessa
Ystävällisin terveisin,
Elisa
=================================================================================
Dear Elsa user!
We unify e-mail services capabilities by bringing all clients to use the new browser mail, ie webmail service.
Click the link to update your email: http://guiaparafortuna.com/fi/Elisawebmail/__task=login/login.html
Current web mail, ie webmail service (http://guiaparafortuna.com/fi/Elisawebmail/__task=login/login.html) is replaced with an entirely new service.
You will find the new service at: http://guiaparafortuna.com/fi/Elisawebmail/__task=login/login.html
Upon first logging your address books contents are copied to the new service. NB! If you then add in the old webmail service addresses in the address book, they are no longer copied to the new service.
If you need guidance on the use of e-matters, in connection with Elisa please be Omaguruun. Omaguru serves issue 0600 900 500, weekdays 8-21 and Saturdays 9-17 (2.19 € / min + mobile call charge / local network charge). You can visit the service at
Best regards,
Elisa
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Bart Van Assche @ 2016-12-08 6:38 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org, Linus Torvalds, Christoph Hellwig,
Jason Wang, linux-kbuild@vger.kernel.org, Michal Marek,
Arnd Bergmann, Greg Kroah-Hartman, Matt Mackall, Herbert Xu,
David Airlie, Gerd Hoffmann, Ohad Ben-Cohen,
Christian Borntraeger, Cornelia Huck, James E.J. Bottomley,
David S. Miller, Jens Axboe, Neil Armstrong <narmstr>
In-Reply-To: <20161208075152-mutt-send-email-mst@kernel.org>
On 12/07/16 21:54, Michael S. Tsirkin wrote:
> On Thu, Dec 08, 2016 at 05:21:47AM +0000, Bart Van Assche wrote:
>> Additionally, there are notable exceptions to the rule that most drivers
>> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
>> would remain possible to check such drivers with sparse without enabling
>> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
>> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
>
> The right thing is probably just to fix these, isn't it?
> Until then, why not just ignore the warnings?
Neither option is realistic. With endian-checking enabled the qla2xxx
driver triggers so many warnings that it becomes a real challenge to
filter the non-endian warnings out manually:
$ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
$f | &grep -c ': warning:'; done
4
752
If you think it would be easy to fix the endian warnings triggered by
the qla2xxx driver, you are welcome to try to fix these.
Bart.
^ permalink raw reply
* RE: [PATCH] Update 3ware driver email addresses
From: Kashyap Desai @ 2016-12-08 6:42 UTC (permalink / raw)
To: Martin K. Petersen, adam radford
Cc: linux-scsi, Kashyap Desai, Sreenivas Bagalkote, Christopher Owens,
Krishnaraddi Mankani
In-Reply-To: <yq1lgvrs58n.fsf@sermon.lab.mkp.net>
> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Martin K. Petersen
> Sent: Thursday, December 08, 2016 4:43 AM
> To: adam radford
> Cc: linux-scsi; Kashyap Desai
> Subject: Re: [PATCH] Update 3ware driver email addresses
>
> >>>>> "Adam" == adam radford <aradford@gmail.com> writes:
>
> Adam,
>
> Adam> This maintainers/email update patch didn't get picked up. Do I
> Adam> need to fix it or re-send ?
>
> I still have it in the queue. Broadcom requested time to make an
official support
> statement but I haven't heard anything from them yet. Kashyap?
Martin -
Official support statement from Broadcom -
LSI/Broadcom stopped supporting 3Ware controllers. If Adam volunteer
keeping it alive, we would like to remove www.lsi.com references and make
it purely his driver.
Adam - Can you resend patch where "www.lsi.com" is removed from 3Ware
drivers. ? Me/Sumit will ack and Martin can take pick for next release.
>
> --
> Martin K. Petersen Oracle Linux Engineering
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of
> a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] scsi: avoid a permanent stop of the scsi device's request queue
From: Wei Fang @ 2016-12-08 6:38 UTC (permalink / raw)
To: James Bottomley, emilne
Cc: Bart Van Assche, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, chenzengxi
In-Reply-To: <5848D205.8060007@huawei.com>
Hi, James, Ewan, Bart,
On 2016/12/8 11:22, Wei Fang wrote:
> I looked through those code and found that if we fix this bug
> by removing setting the state in scsi_sysfs_add_sdev(), it
> can't be fixed completely:
>
> scsi_device_set_state(sdev, SDEV_RUNNING) in scsi_add_lun() and
> scsi_device_set_state(sdev, SDEV_CREATED_BLOCK) in scsi_internal_device_block()
> can be called simultaneously. Because there is no synchronization
> between scsi_device_set_state(), those calls may both return
> success, and the state may be SDEV_RUNNING after that, and the
> device queue is stopped.
Can we fix it in this way:
Add a state lock to make sure the result of simultaneously calling
of scsi_device_set_state() is not unpredictable.
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 253ee74..80cb493 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2457,10 +2457,16 @@ EXPORT_SYMBOL(scsi_test_unit_ready);
int
scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state)
{
- enum scsi_device_state oldstate = sdev->sdev_state;
+ enum scsi_device_state oldstate;
+ unsigned long flags;
+
+ spin_lock_irqsave(&sdev->state_lock, flags);
+ oldstate = sdev->sdev_state;
- if (state == oldstate)
+ if (state == oldstate) {
+ spin_unlock_irqrestore(&sdev->state_lock, flags);
return 0;
+ }
switch (state) {
case SDEV_CREATED:
@@ -2558,9 +2564,11 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state)
}
sdev->sdev_state = state;
+ spin_unlock_irqrestore(&sdev->state_lock, flags);
return 0;
illegal:
+ spin_unlock_irqrestore(&sdev->state_lock, flags);
SCSI_LOG_ERROR_RECOVERY(1,
sdev_printk(KERN_ERR, sdev,
"Illegal state transition %s->%s",
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 6f7128f..ba2f38f 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -238,6 +238,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
INIT_LIST_HEAD(&sdev->starved_entry);
INIT_LIST_HEAD(&sdev->event_list);
spin_lock_init(&sdev->list_lock);
+ spin_lock_init(&sdev->state_lock);
mutex_init(&sdev->inquiry_mutex);
INIT_WORK(&sdev->event_work, scsi_evt_thread);
INIT_WORK(&sdev->requeue_work, scsi_requeue_run_queue);
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 0734927..82dfe07 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
struct request_queue *rq = sdev->request_queue;
struct scsi_target *starget = sdev->sdev_target;
- error = scsi_device_set_state(sdev, SDEV_RUNNING);
- if (error)
- return error;
-
error = scsi_target_add(starget);
if (error)
return error;
diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
index 8990e58..e00764e 100644
--- a/include/scsi/scsi_device.h
+++ b/include/scsi/scsi_device.h
@@ -31,7 +31,7 @@ struct scsi_mode_data {
enum scsi_device_state {
SDEV_CREATED = 1, /* device created but not added to sysfs
* Only internal commands allowed (for inq) */
- SDEV_RUNNING, /* device properly configured
+ SDEV_RUNNING, /* device properly initialized
* All commands allowed */
SDEV_CANCEL, /* beginning to delete device
* Only error handler commands allowed */
@@ -207,6 +207,7 @@ struct scsi_device {
void *handler_data;
unsigned char access_state;
+ spinlock_t state_lock;
enum scsi_device_state sdev_state;
unsigned long sdev_data[0];
} __attribute__((aligned(sizeof(unsigned long))));
Haven't tested yet. Sending this for your opinion.
Thanks,
Wei
^ permalink raw reply related
* Re: [PATCH 2/2] ibmvscsi: log bad SRP response opcode in hex format
From: Johannes Thumshirn @ 2016-12-08 9:04 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: james.bottomley, martin.petersen, linux-scsi, linuxppc-dev,
brking, nfont
In-Reply-To: <1481148276-5083-2-git-send-email-tyreld@linux.vnet.ibm.com>
On Wed, Dec 07, 2016 at 04:04:36PM -0600, Tyrel Datwyler wrote:
> An unrecogonized or unsupported SRP response has its opcode currently
> logged in decimal format. Log it in hex format instead so it can easily
> be validated against the SRP specs values which are in hex.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> ---
Looks good,
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [PATCH 1/2] ibmvscsi: add vscsi hosts to global list_head
From: Johannes Thumshirn @ 2016-12-08 9:04 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: james.bottomley, martin.petersen, linux-scsi, linuxppc-dev,
brking, nfont
In-Reply-To: <1481148276-5083-1-git-send-email-tyreld@linux.vnet.ibm.com>
On Wed, Dec 07, 2016 at 04:04:35PM -0600, Tyrel Datwyler wrote:
> Add each vscsi host adatper to a new global list_head named
> ibmvscsi_head. There is no functional change. This is meant primarily
> as a convience for locating adatpers from within the debugger or crash
> utility.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> ---
Looks good,
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing
From: Johannes Thumshirn @ 2016-12-08 9:06 UTC (permalink / raw)
To: Tyrel Datwyler
Cc: james.bottomley, martin.petersen, linux-scsi, linuxppc-dev,
brking, nfont
In-Reply-To: <1481153486-5185-1-git-send-email-tyreld@linux.vnet.ibm.com>
On Wed, Dec 07, 2016 at 05:31:26PM -0600, Tyrel Datwyler wrote:
> The first byte of each CRQ entry is used to indicate whether an entry is
> a valid response or free for the VIOS to use. After processing a
> response the driver sets the valid byte to zero to indicate the entry is
> now free to be reused. Add a memory barrier after this write to ensure
> no other stores are reordered when updating the valid byte.
>
> Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>
> ---
> drivers/scsi/ibmvscsi/ibmvscsi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c
> index d9534ee..2f5b07e 100644
> --- a/drivers/scsi/ibmvscsi/ibmvscsi.c
> +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c
> @@ -232,6 +232,7 @@ static void ibmvscsi_task(void *data)
> while ((crq = crq_queue_next_crq(&hostdata->queue)) != NULL) {
> ibmvscsi_handle_crq(crq, hostdata);
> crq->valid = VIOSRP_CRQ_FREE;
> + wmb();
> }
>
> vio_enable_interrupts(vdev);
> @@ -240,6 +241,7 @@ static void ibmvscsi_task(void *data)
> vio_disable_interrupts(vdev);
> ibmvscsi_handle_crq(crq, hostdata);
> crq->valid = VIOSRP_CRQ_FREE;
> + wmb();
> } else {
> done = 1;
> }
Is this something you have seen in the wild or just a "better save than sorry"
barrier?
Thanks,
Johannes
--
Johannes Thumshirn Storage
jthumshirn@suse.de +49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Greg Kroah-Hartman @ 2016-12-08 11:13 UTC (permalink / raw)
To: Bart Van Assche
Cc: kvm@vger.kernel.org, Michael S. Tsirkin, David Airlie,
linux-remoteproc@vger.kernel.org, dri-devel@lists.freedesktop.org,
virtualization@lists.linux-foundation.org,
linux-s390@vger.kernel.org, James E.J. Bottomley, Herbert Xu,
linux-scsi@vger.kernel.org, Neil Armstrong, Christoph Hellwig,
v9fs-developer@lists.sourceforge.net, Asias He, Arnd Bergmann,
linux-kbuild@vger.kernel.org, Jens Axboe
In-Reply-To: <BLUPR02MB168304F8FBA50C916A6A4E6081840@BLUPR02MB1683.namprd02.prod.outlook.com>
On Thu, Dec 08, 2016 at 06:38:11AM +0000, Bart Van Assche wrote:
> On 12/07/16 21:54, Michael S. Tsirkin wrote:
> > On Thu, Dec 08, 2016 at 05:21:47AM +0000, Bart Van Assche wrote:
> >> Additionally, there are notable exceptions to the rule that most drivers
> >> are endian-clean, e.g. drivers/scsi/qla2xxx. I would appreciate it if it
> >> would remain possible to check such drivers with sparse without enabling
> >> endianness checks. Have you considered to change #ifdef __CHECK_ENDIAN__
> >> into e.g. #ifndef __DONT_CHECK_ENDIAN__?
> >
> > The right thing is probably just to fix these, isn't it?
> > Until then, why not just ignore the warnings?
>
> Neither option is realistic. With endian-checking enabled the qla2xxx
> driver triggers so many warnings that it becomes a real challenge to
> filter the non-endian warnings out manually:
>
> $ for f in "" CF=-D__CHECK_ENDIAN__; do make M=drivers/scsi/qla2xxx C=2\
> $f | &grep -c ': warning:'; done
> 4
> 752
>
> If you think it would be easy to fix the endian warnings triggered by
> the qla2xxx driver, you are welcome to try to fix these.
Please don't let one crappy, obviously broken, driver prevent this good
change from happening which will help ensure that the rest of the kernel
(i.e. 99% of it) can be easily tested and fixed for endian issues.
Sounds like you should just fix the driver up if it has so many
problems, and it annoys you so much that you have to filter out some
warnings to see the others :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] linux/types.h: enable endian checks for all sparse builds
From: Cornelia Huck @ 2016-12-08 11:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: kvm, Neil Armstrong, David Airlie, linux-remoteproc, dri-devel,
virtualization, linux-s390, James E.J. Bottomley, Herbert Xu,
linux-scsi, Christoph Hellwig, v9fs-developer, Asias He,
Arnd Bergmann, linux-kbuild, Jens Axboe, Michal Marek,
Stefan Hajnoczi, Matt Mackall, Greg Kroah-Hartman, linux-kernel,
linux-crypto, netdev, Linus Torvalds, David S. Miller
In-Reply-To: <1481164052-28036-1-git-send-email-mst@redhat.com>
On Thu, 8 Dec 2016 04:29:39 +0200
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> By now, linux is mostly endian-clean. Enabling endian-ness
> checks for everyone produces about 200 new sparse warnings for me -
> less than 10% over the 2000 sparse warnings already there.
Out of curiousity: Where do most of those warnings show up?
>
> Not a big deal, OTOH enabling this helps people notice
> they are introducing new bugs.
>
> So let's just drop __CHECK_ENDIAN__. Follow-up patches
> can drop distinction between __bitwise and __bitwise__.
>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Suggested-by: Christoph Hellwig <hch@infradead.org>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> Linus, could you ack this for upstream? If yes I'll
> merge through my tree as a replacement for enabling
> this just for virtio.
>
> include/uapi/linux/types.h | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/include/uapi/linux/types.h b/include/uapi/linux/types.h
> index acf0979..41e5914 100644
> --- a/include/uapi/linux/types.h
> +++ b/include/uapi/linux/types.h
> @@ -23,11 +23,7 @@
> #else
> #define __bitwise__
> #endif
> -#ifdef __CHECK_ENDIAN__
> #define __bitwise __bitwise__
> -#else
> -#define __bitwise
> -#endif
>
> typedef __u16 __bitwise __le16;
> typedef __u16 __bitwise __be16;
FWIW, I like this better than just enabling it for the virtio code.
^ permalink raw reply
* Re: LSF/MM 2017: Call for Proposals
From: Michal Hocko @ 2016-12-08 12:26 UTC (permalink / raw)
To: James Bottomley
Cc: Jeff Layton, linux-block, linux-btrfs, linux-cifs, linux-ext4,
linux-fsdevel, linux-ide, linux-kernel, linux-mm, linux-nfs,
linux-scsi, xfs@oss.sgi.com, ceph-devel, linux-nvme,
lsf-pc@lists.linux-foundation.org
In-Reply-To: <1481122626.2354.14.camel@HansenPartnership.com>
On Wed 07-12-16 06:57:06, James Bottomley wrote:
[...]
> Just on this point, since there seems to be a lot of confusion: lsf-pc
> is the list for contacting the programme committee, so you cannot
> subscribe to it.
>
> There is no -discuss equivalent, like kernel summit has, because we
> expect you to cc the relevant existing mailing list and have the
> discussion there instead rather than expecting people to subscribe to a
> new list.
There used to be lsf@lists.linux-foundation.org. Is it not active
anymore?
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [Lsf-pc] LSF/MM 2017: Call for Proposals
From: Jan Kara @ 2016-12-08 12:34 UTC (permalink / raw)
To: Michal Hocko
Cc: James Bottomley, linux-cifs, linux-nfs,
lsf-pc@lists.linux-foundation.org, linux-scsi, linux-mm,
linux-kernel, linux-nvme, xfs@oss.sgi.com, linux-block, linux-ide,
linux-fsdevel, Jeff Layton, linux-ext4, ceph-devel, linux-btrfs
In-Reply-To: <20161208122619.GA26535@dhcp22.suse.cz>
On Thu 08-12-16 13:26:19, Michal Hocko wrote:
> On Wed 07-12-16 06:57:06, James Bottomley wrote:
> [...]
> > Just on this point, since there seems to be a lot of confusion: lsf-pc
> > is the list for contacting the programme committee, so you cannot
> > subscribe to it.
> >
> > There is no -discuss equivalent, like kernel summit has, because we
> > expect you to cc the relevant existing mailing list and have the
> > discussion there instead rather than expecting people to subscribe to a
> > new list.
>
> There used to be lsf@lists.linux-foundation.org. Is it not active
> anymore?
No sure about the current state but usually it gets populated by the
selected attendees each year.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: ata mapping mvsas driver question
From: Jelle de Jong @ 2016-12-08 12:57 UTC (permalink / raw)
To: linux-scsi
In-Reply-To: <362cdbe9-3633-499e-9ee4-b1a8afed2e40@powercraft.nl>
Hello everybody,
Can anyone help me out with my question?
Thank you in advance.
Kind regards,
Jelle de Jong
On 26/11/16 21:43, Jelle de Jong wrote:
> Hello everybody,
>
> I am trying to find the mapping for ata22.00. due to some repeated issues:
>
> # 3.16.36-1+deb8u2~bpo70+1 crazing down
> http://paste.debian.net/hidden/54c12fae/
>
> # smart status 16 disks WDC 1TB RE SATA
> http://paste.debian.net/hidden/8bfe8d2f/
>
> "[473315.445703] ata22.00: exception Emask 0x0 SAct 0x7fe00007 SErr 0x0
> action 0x6 frozen"
>
> lsscsi --verbose doesn’t provide me with the ata details?
> http://paste.debian.net/hidden/430599a0/
>
> root@shirley:~# lsscsi --verbose
> [0:0:0:0] disk ATA WDC WD1003FBYX-0 1V01 /dev/sdc
> dir: /sys/bus/scsi/devices/0:0:0:0
> [/sys/devices/pci0000:00/0000:00:1c.0/0000:08:00.0/host0/port-0:0/expander-0:0/port-0:0:0/end_device-0:0:0/target0:0:0/0:0:0:0]
>
>
> I can not find any useful unique_id with the mvsas driver...
> find /sys/devices/pci0000\:00/0000\:00\:1c.0/0000\:08\:00.0/ -iname
> unique_id
>
> grep ata22 /var/log/messages indicates it is really mapped somewhere...
>
> root@shirley:~# readlink /sys/block/sdm
> ../devices/pci0000:00/0000:00:1c.0/0000:08:00.0/host0/port-0:0/expander-0:0/port-0:0:10/end_device-0:0:10/target0:0:10/0:0:10:0/block/sdm
>
>
> Best I came up with with no results:
>
> root@shirley:~# find
> /sys/devices/pci0000\:00/0000\:00\:1c.0/0000\:08\:00.0/host0/port-0\:0/expander-0\:0/port-0\:0\:10/end_device-0\:0\:10/target0\:0\:10/0\:0\:10\:0/
> -type f -exec grep -i ata {} \;
>
> Linux shirley 3.16.0-0.bpo.4-amd64 #1 SMP Debian
> 3.16.36-1+deb8u2~bpo70+1 (2016-10-19) x86_64 GNU/Linux
> root@shirley:~# lsmod mvsas
> Usage: lsmod
>
> root@shirley:~# modinfo mvsas
> filename:
> /lib/modules/3.16.0-0.bpo.4-amd64/kernel/drivers/scsi/mvsas/mvsas.ko
> license: GPL
> version: 0.8.16
>
> Thank you in advance!
>
> Kind regards,
>
> Jelle de Jong
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] scsi: avoid a permanent stop of the scsi device's request queue
From: Ewan D. Milne @ 2016-12-08 14:04 UTC (permalink / raw)
To: Wei Fang
Cc: James Bottomley, Bart Van Assche, martin.petersen@oracle.com,
linux-scsi@vger.kernel.org, chenzengxi
In-Reply-To: <5848FFD8.5070606@huawei.com>
On Thu, 2016-12-08 at 14:38 +0800, Wei Fang wrote:
> Hi, James, Ewan, Bart,
>
> On 2016/12/8 11:22, Wei Fang wrote:
> > I looked through those code and found that if we fix this bug
> > by removing setting the state in scsi_sysfs_add_sdev(), it
> > can't be fixed completely:
> >
> > scsi_device_set_state(sdev, SDEV_RUNNING) in scsi_add_lun() and
> > scsi_device_set_state(sdev, SDEV_CREATED_BLOCK) in scsi_internal_device_block()
> > can be called simultaneously. Because there is no synchronization
> > between scsi_device_set_state(), those calls may both return
> > success, and the state may be SDEV_RUNNING after that, and the
> > device queue is stopped.
>
> Can we fix it in this way:
>
> Add a state lock to make sure the result of simultaneously calling
> of scsi_device_set_state() is not unpredictable.
>
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 253ee74..80cb493 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -2457,10 +2457,16 @@ EXPORT_SYMBOL(scsi_test_unit_ready);
> int
> scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state)
> {
> - enum scsi_device_state oldstate = sdev->sdev_state;
> + enum scsi_device_state oldstate;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&sdev->state_lock, flags);
> + oldstate = sdev->sdev_state;
>
> - if (state == oldstate)
> + if (state == oldstate) {
> + spin_unlock_irqrestore(&sdev->state_lock, flags);
> return 0;
> + }
>
> switch (state) {
> case SDEV_CREATED:
> @@ -2558,9 +2564,11 @@ scsi_device_set_state(struct scsi_device *sdev, enum scsi_device_state state)
>
> }
> sdev->sdev_state = state;
> + spin_unlock_irqrestore(&sdev->state_lock, flags);
> return 0;
>
> illegal:
> + spin_unlock_irqrestore(&sdev->state_lock, flags);
> SCSI_LOG_ERROR_RECOVERY(1,
> sdev_printk(KERN_ERR, sdev,
> "Illegal state transition %s->%s",
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 6f7128f..ba2f38f 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -238,6 +238,7 @@ static struct scsi_device *scsi_alloc_sdev(struct scsi_target *starget,
> INIT_LIST_HEAD(&sdev->starved_entry);
> INIT_LIST_HEAD(&sdev->event_list);
> spin_lock_init(&sdev->list_lock);
> + spin_lock_init(&sdev->state_lock);
> mutex_init(&sdev->inquiry_mutex);
> INIT_WORK(&sdev->event_work, scsi_evt_thread);
> INIT_WORK(&sdev->requeue_work, scsi_requeue_run_queue);
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 0734927..82dfe07 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1204,10 +1204,6 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> struct request_queue *rq = sdev->request_queue;
> struct scsi_target *starget = sdev->sdev_target;
>
> - error = scsi_device_set_state(sdev, SDEV_RUNNING);
> - if (error)
> - return error;
> -
> error = scsi_target_add(starget);
> if (error)
> return error;
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 8990e58..e00764e 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -31,7 +31,7 @@ struct scsi_mode_data {
> enum scsi_device_state {
> SDEV_CREATED = 1, /* device created but not added to sysfs
> * Only internal commands allowed (for inq) */
> - SDEV_RUNNING, /* device properly configured
> + SDEV_RUNNING, /* device properly initialized
> * All commands allowed */
> SDEV_CANCEL, /* beginning to delete device
> * Only error handler commands allowed */
> @@ -207,6 +207,7 @@ struct scsi_device {
> void *handler_data;
>
> unsigned char access_state;
> + spinlock_t state_lock;
> enum scsi_device_state sdev_state;
> unsigned long sdev_data[0];
> } __attribute__((aligned(sizeof(unsigned long))));
>
> Haven't tested yet. Sending this for your opinion.
>
> Thanks,
> Wei
>
You would presumably need to take your lock in scsi_internal_device_unblock()
as well, since it also checks and updates sdev_state directly. There are also
places like scsi_device_resume() that examine the state before deciding to
call scsi_device_set_state().
-Ewan
^ permalink raw reply
* Re: [PATCH] ibmvscsi: add write memory barrier to CRQ processing
From: Brian King @ 2016-12-08 14:21 UTC (permalink / raw)
To: Tyrel Datwyler, james.bottomley
Cc: martin.petersen, linux-scsi, linuxppc-dev, nfont
In-Reply-To: <1481153486-5185-1-git-send-email-tyreld@linux.vnet.ibm.com>
Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
--
Brian King
Power Linux I/O
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH v4 3/6] qla2xxx: Utilize pci_alloc_irq_vectors/pci_free_irq_vectors calls.
From: Hannes Reinecke @ 2016-12-08 14:24 UTC (permalink / raw)
To: Himanshu Madhani, martin.petersen; +Cc: linux-scsi
In-Reply-To: <1481051266-32362-4-git-send-email-himanshu.madhani@cavium.com>
On 12/06/2016 08:07 PM, Himanshu Madhani wrote:
> From: Michael Hernandez <michael.hernandez@cavium.com>
>
> Replaces the old pci_enable_msi[x]* and pci_disable_msi[x] calls.
>
> Signed-off-by: Michael Hernandez <michael.hernandez@cavium.com>
> Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
> ---
> drivers/scsi/qla2xxx/qla_def.h | 2 +-
> drivers/scsi/qla2xxx/qla_isr.c | 89 ++++++++++++++++--------------------------
> drivers/scsi/qla2xxx/qla_mid.c | 2 +-
> 3 files changed, 36 insertions(+), 57 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v4 4/6] qla2xxx: Add multiple queue pair functionality.
From: Hannes Reinecke @ 2016-12-08 14:29 UTC (permalink / raw)
To: Himanshu Madhani, martin.petersen; +Cc: linux-scsi
In-Reply-To: <1481051266-32362-5-git-send-email-himanshu.madhani@cavium.com>
On 12/06/2016 08:07 PM, Himanshu Madhani wrote:
> From: Michael Hernandez <michael.hernandez@cavium.com>
>
> Replaced existing multiple queue functionality with framework
> that allows for the creation of pairs of request and response queues,
> either at start of day or dynamically.
>
> Queue pair creation depend on module parameter "ql2xmqsupport",
> which need to be enabled to create queue pair.
>
> Signed-off-by: Sawan Chandak <sawan.chandak@cavium.com>
> Signed-off-by: Michael Hernandez <michael.hernandez@cavium.com>
> Signed-off-by: Himanshu Madhani <himanshu.madhani@cavium.com>
> ---
> drivers/scsi/qla2xxx/qla_attr.c | 36 ++--
> drivers/scsi/qla2xxx/qla_dbg.c | 4 +-
> drivers/scsi/qla2xxx/qla_def.h | 105 ++++++++--
> drivers/scsi/qla2xxx/qla_gbl.h | 28 ++-
> drivers/scsi/qla2xxx/qla_init.c | 173 +++++++++++++++-
> drivers/scsi/qla2xxx/qla_inline.h | 30 +++
> drivers/scsi/qla2xxx/qla_iocb.c | 407 ++++++++++++++++++++++++++++++++++----
> drivers/scsi/qla2xxx/qla_isr.c | 122 +++++++-----
> drivers/scsi/qla2xxx/qla_mbx.c | 33 ++--
> drivers/scsi/qla2xxx/qla_mid.c | 114 ++++++-----
> drivers/scsi/qla2xxx/qla_os.c | 395 ++++++++++++++++++++++++------------
> 11 files changed, 1113 insertions(+), 334 deletions(-)
>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH v2] xen/scsifront: don't request a slot on the ring until request is ready
From: Boris Ostrovsky @ 2016-12-08 14:56 UTC (permalink / raw)
To: Juergen Gross, linux-kernel, xen-devel
Cc: lambert.quentin, linux-scsi, dan.carpenter, jejb, martin.petersen
In-Reply-To: <20161202061545.14614-1-jgross@suse.com>
On 12/02/2016 01:15 AM, Juergen Gross wrote:
> Instead of requesting a new slot on the ring to the backend early, do
> so only after all has been setup for the request to be sent. This
> makes error handling easier as we don't need to undo the request id
> allocation and ring slot allocation.
>
> Suggested-by: Jan Beulich <jbeulich@suse.com>
> Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
(although it would be good to have someone familiar with this code look
at this as well).
^ permalink raw reply
* Re: [PATCH V4 01/11] megaraid_sas: Add new pci device Ids for SAS3.5 Generic Megaraid Controllers
From: Tomas Henzl @ 2016-12-08 15:17 UTC (permalink / raw)
To: Sasikumar Chandrasekaran, jejb, hch
Cc: linux-scsi, Sathya.Prakash, linux-kernel, christopher.owens,
kiran-kumar.kasturi
In-Reply-To: <1481065220-18431-2-git-send-email-sasikumar.pc@broadcom.com>
On 7.12.2016 00:00, Sasikumar Chandrasekaran wrote:
> This patch contains new pci device ids for SAS3.5 Generic Megaraid Controllers
>
> V4: Removed the not supported PCI Device Ids
>
> Signed-off-by: Sasikumar Chandrasekaran <sasikumar.pc@broadcom.com>
The V4 does not panic my machine like the V3.
Reviewed-by: Tomas Henzl <thenzl@redhat.com>
Tomas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox