Re: [PATCH 2/2] dm: Avoid use-after-free of a mapped device
Hello Bart,
On 02/22/13 19:47, Bart Van Assche wrote:
As the comment above rq_completed() explains, md members must
not be touched after the dm_put() at the end of that function
has been invoked. Avoid that the md-queue can be run
asynchronously after the last md reference has been dropped by
running that queue synchronously. This patch fixes the
following kernel oops:
Calling blk_run_queue_async() there should be ok.
After dm_put(), the dm device may be removed. But free_dev() in dm.c
calls blk_queue_cleanup() and it should solve the race vs. delayed work.
And I could reproduce very similar oops without removing dm device
by following procedure:
(please replace mpathX with your dm-multipath map name)
# t=`dmsetup table mpathX`
# while sleep 1; do \
echo $t | dmsetup load mpathX; dmsetup resume mpathX; done
Looking at the following back trace:
general protection fault: [#1] SMP
RIP: 0010:[810fe754] [810fe754] mempool_free+0x24/0xb0
Call Trace:
IRQ
[81187417] bio_put+0x97/0xc0
[a02247a5] end_clone_bio+0x35/0x90 [dm_mod]
[81185efd] bio_endio+0x1d/0x30
[811f03a3] req_bio_endio.isra.51+0xa3/0xe0
[811f2f68] blk_update_request+0x118/0x520
[811f3397] blk_update_bidi_request+0x27/0xa0
[811f343c] blk_end_bidi_request+0x2c/0x80
[811f34d0] blk_end_request+0x10/0x20
[a000b32b] scsi_io_completion+0xfb/0x6c0 [scsi_mod]
[a000107d] scsi_finish_command+0xbd/0x120 [scsi_mod]
[a000b12f] scsi_softirq_done+0x13f/0x160 [scsi_mod]
[811f9fd0] blk_done_softirq+0x80/0xa0
[81044551] __do_softirq+0xf1/0x250
[8142ee8c] call_softirq+0x1c/0x30
[8100420d] do_softirq+0x8d/0xc0
[81044885] irq_exit+0xd5/0xe0
[8142f3e3] do_IRQ+0x63/0xe0
[814257af] common_interrupt+0x6f/0x6f
EOI
[a021737c] srp_queuecommand+0x8c/0xcb0 [ib_srp]
[a0002f18] scsi_dispatch_cmd+0x148/0x310 [scsi_mod]
[a000a38e] scsi_request_fn+0x31e/0x520 [scsi_mod]
[811f1e57] __blk_run_queue+0x37/0x50
[811f1f69] blk_delay_work+0x29/0x40
[81059003] process_one_work+0x1c3/0x5c0
[8105b22e] worker_thread+0x15e/0x440
[8106164b] kthread+0xdb/0xe0
[8142db9c] ret_from_fork+0x7c/0xb0
it seems that the bioset was removed while being referenced.
c0820cf5 dm: introduce per_bio_data started to replace dm bioset
during table replacement because the size of bioset front_pad might
change for bio-based dm.
However, for request-based dm, it is not necessary because the size
of front_pad is static. Also we can't simply replace bioset because
prep-ed requests in queue have reference to the old bioset.
The patch below changes it not to replace bioset for request-based dm.
(Brings back to the same behavior with v3.7)
With this patch, I could not reproduce the problem.
Could you try this?
--
Jun'ichi Nomura, NEC Corporation
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 314a0e2..51fefb5 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1973,15 +1973,27 @@ static void __bind_mempools(struct mapped_device *md,
struct dm_table *t)
{
struct dm_md_mempools *p = dm_table_get_md_mempools(t);
- if (md-io_pool (md-tio_pool || dm_table_get_type(t) ==
DM_TYPE_BIO_BASED) md-bs) {
- /*
-* The md already has necessary mempools. Reload just the
-* bioset because front_pad may have changed because
-* a different table was loaded.
-*/
- bioset_free(md-bs);
- md-bs = p-bs;
- p-bs = NULL;
+ if (md-io_pool md-bs) {
+ /* The md already has necessary mempools. */
+ if (dm_table_get_type(t) == DM_TYPE_BIO_BASED) {
+ /*
+* Reload bioset because front_pad may have changed
+* because a different table was loaded.
+*/
+ bioset_free(md-bs);
+ md-bs = p-bs;
+ p-bs = NULL;
+ } else if (dm_table_get_type(t) == DM_TYPE_REQUEST_BASED) {
+ BUG_ON(!md-tio_pool);
+ /*
+* No need to reload in case of request-based dm
+* because of fixed size front_pad.
+* Note for future: if you are to reload bioset,
+* prep-ed requests in queue may have reference
+* to bio from the old bioset.
+* So you must walk through the queue to unprep.
+*/
+ }
goto out;
}
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info
[PATCH -next] [SCSI] fnic: convert to use simple_open()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
This removes an open coded simple_open() function and
replaces file operations references to the function
with simple_open() instead.
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
drivers/scsi/fnic/fnic_debugfs.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/scsi/fnic/fnic_debugfs.c b/drivers/scsi/fnic/fnic_debugfs.c
index bc06f9b..26db5b5 100644
--- a/drivers/scsi/fnic/fnic_debugfs.c
+++ b/drivers/scsi/fnic/fnic_debugfs.c
@@ -25,23 +25,6 @@ static struct dentry *fnic_trace_debugfs_file;
static struct dentry *fnic_trace_enable;
/*
- * fnic_trace_ctrl_open - Open the trace_enable file
- * @inode: The inode pointer.
- * @file: The file pointer to attach the trace enable/disable flag.
- *
- * Description:
- * This routine opens a debugsfs file trace_enable.
- *
- * Returns:
- * This function returns zero if successful.
- */
-static int fnic_trace_ctrl_open(struct inode *inode, struct file *filp)
-{
- filp-private_data = inode-i_private;
- return 0;
-}
-
-/*
* fnic_trace_ctrl_read - Read a trace_enable debugfs file
* @filp: The file pointer to read from.
* @ubuf: The buffer to copy the data to.
@@ -232,7 +215,7 @@ static int fnic_trace_debugfs_release(struct inode *inode,
static const struct file_operations fnic_trace_ctrl_fops = {
.owner = THIS_MODULE,
- .open = fnic_trace_ctrl_open,
+ .open = simple_open,
.read = fnic_trace_ctrl_read,
.write = fnic_trace_ctrl_write,
};
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RESEND3 PATCH] libiscsi: avoid unnecessary multiple NULL assignments
In iscsi_free_task, NULL is assigned to task-sc twice: before and
after kfifo_in invocatoin. Allocating and freeing iscsi_task are guarded
with session-lock, so multiple NULL assignments cause no trouble. But
people reading the source code may be confused.
The second NULL assignment comes from commit:
3e5c28ad0391389959ccae81c938c7533efb3490
It seems that the line after kfifo_in invocation was introduced
accidentally.
Signed-off-by: Masatake YAMATO yam...@redhat.com
Reviewed-by: Mike Christie micha...@cs.wisc.edu
---
drivers/scsi/libiscsi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 82c3fd4..7aacf3a 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -507,7 +507,6 @@ static void iscsi_free_task(struct iscsi_task *task)
kfifo_in(session-cmdpool.queue, (void*)task, sizeof(void*));
if (sc) {
- task-sc = NULL;
/* SCSI eh reuses commands to verify us */
sc-SCp.ptr = NULL;
/*
--
1.7.11.7
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dm: Avoid use-after-free of a mapped device
On 02/25/13 10:49, Jun'ichi Nomura wrote:
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 314a0e2..51fefb5 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1973,15 +1973,27 @@ static void __bind_mempools(struct mapped_device *md,
struct dm_table *t)
{
struct dm_md_mempools *p = dm_table_get_md_mempools(t);
- if (md-io_pool (md-tio_pool || dm_table_get_type(t) == DM_TYPE_BIO_BASED)
md-bs) {
- /*
-* The md already has necessary mempools. Reload just the
-* bioset because front_pad may have changed because
-* a different table was loaded.
-*/
- bioset_free(md-bs);
- md-bs = p-bs;
- p-bs = NULL;
+ if (md-io_pool md-bs) {
+ /* The md already has necessary mempools. */
+ if (dm_table_get_type(t) == DM_TYPE_BIO_BASED) {
+ /*
+* Reload bioset because front_pad may have changed
+* because a different table was loaded.
+*/
+ bioset_free(md-bs);
+ md-bs = p-bs;
+ p-bs = NULL;
+ } else if (dm_table_get_type(t) == DM_TYPE_REQUEST_BASED) {
+ BUG_ON(!md-tio_pool);
+ /*
+* No need to reload in case of request-based dm
+* because of fixed size front_pad.
+* Note for future: if you are to reload bioset,
+* prep-ed requests in queue may have reference
+* to bio from the old bioset.
+* So you must walk through the queue to unprep.
+*/
+ }
goto out;
}
Without your patch my test failed after two or three iterations. With
your patch my test is still running after 53 iterations. So if you want
you can add Tested-by: Bart Van Assche bvanass...@acm.org.
Your e-mail and the above patch are also interesting because these
explain why reverting to the v3.7 of drivers/md made my test succeed.
Note: even if this patch gets accepted I think it's still useful to
modify blk_run_queue() such that it converts recursion into iteration.
Bart.
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] scsi: use 64-bit LUNs
Hi Hannes,
I like the idea and most of the patch set, so I only have a few questions left
and some review comments below.
Just curious: Do you also plan to adapt systemd/udev, especially path_id for fc
transport with its open coded copy of int_to_scsilun()?
Since I don't see zfcp touched in this patch set, assuming this set will get
merged, I plan to adapt a few spots in zfcp that might not work with 64 bit
luns out of the box although most of it already works with 64 bit luns inside.
Speaking of opaque handling of scsi luns: Lately I noticed that some sg3_utils
tools decode the lun format and only report parts of the entire 64 bit fcp lun,
e.g. sg_scan or sg_luns -d. I don't have enough historical scsi experience to
know why that is, maybe because of some SPI background. By itself this is not a
problem, however, rescan-scsi-bus.sh makes use of those scsi lun parts and then
fails when matching those with the full scsi lun exposed by the midlayer to
user space. E.g. with flat space addresses of IBM DS8000 this does not seem to
work:
# sg_luns -v -s2 -d /dev/sg2 | head
report luns cdb: a0 00 02 00 00 00 00 00 20 00 00 00
report luns: requested 8192 bytes but got 4112 bytes
Lun list length = 4104 which imples 513 lun entries
Report luns [select_report=2]:
c101
REPORT LUNS well known logical unit
40204000
Flat space addressing: lun=32
40204001
Flat space addressing: lun=32
40204002
Flat space addressing: lun=32
^^=== 0x20 of the lun's 1st short
Did I overlook something or are rescan-scsi-bus.sh and maybe other tools really
broken with some modern scsi targets?
On 02/19/2013 09:18 AM, Hannes Reinecke wrote:
The SCSI standard uses a 64-bit value for LUNs, and large arrays
employing large LUN numbers become more and more common.
So move the linux SCSI stack to use 64-bit LUN numbers.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/scsi_proc.c|2 +-
drivers/scsi/scsi_sysfs.c | 14
drivers/scsi/scsi_transport_fc.c|4 +-
drivers/scsi/scsi_transport_iscsi.c |4 +-
drivers/scsi/scsi_transport_sas.c |2 +-
drivers/scsi/sg.c |4 +-
include/scsi/scsi.h |2 +-
include/scsi/scsi_device.h | 22 ++--
include/scsi/scsi_transport.h |2 +-
50 files changed, 239 insertions(+), 247 deletions(-)
--- a/drivers/scsi/scsi_proc.c
+++ b/drivers/scsi/scsi_proc.c
@@ -196,7 +196,7 @@ static int proc_print_scsidevice(struct device *dev, void
*data)
sdev = to_scsi_device(dev);
seq_printf(s,
- Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n Vendor: ,
+ Host: scsi%d Channel: %02d Id: %02d Lun: %02llu\n Vendor: ,
sdev-host-host_no, sdev-channel, sdev-id, sdev-lun);
for (i = 0; i 8; i++) {
if (sdev-vendor[i] = 0x20)
Is it intentional that you did not adapt scsi_add_single_device(),
scsi_remove_single_device(), proc_scsi_write() to cope with 64 bit luns?
(in the admittedly old and probably somewhat deprecated procfs interface; but
then again, proc_print_scsidevice can output 64 bit luns now)
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 931a7d9..6e98f05 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -80,7 +80,7 @@ const char *scsi_host_state_name(enum scsi_host_state state)
return name;
}
-static int check_set(unsigned int *val, char *src)
+static int check_set(unsigned long long *val, char *src)
{
char *last;
@@ -90,7 +90,7 @@ static int check_set(unsigned int *val, char *src)
/*
* Doesn't check for int overflow
*/
- *val = simple_strtoul(src, last, 0);
+ *val = simple_strtoull(src, last, 0);
if (*last != '\0')
return 1;
}
@@ -99,11 +99,11 @@ static int check_set(unsigned int *val, char *src)
static int scsi_scan(struct Scsi_Host *shost, const char *str)
{
- char s1[15], s2[15], s3[15], junk;
- unsigned int channel, id, lun;
+ char s1[15], s2[15], s3[17], junk;
Since we use automatic base detection with the 3rd argument of
simple_strtoull() being 0 in check_set() above, I think the user is free to
specify the lun to scan for in decimal/octal/hex base for s3.
With 64 bits, couldn't this need a maximum of 20 decimal digits (plus '\0'
termination) which is more than 16? I think this is a legitimate use case as
long as the scsi lun is represented in decimal in sysfs so users might just
have it from the h:c:t:l device name there.
While I don't think anyone would specify the lun in octal, it could even need
22 digits.
[Maximum number of digits is ceil(ln(2**64-1)/ln(base)) if I'm not
Re: [PATCH 2/4] scsi: use 64-bit LUNs
On 02/25/2013 04:33 PM, Steffen Maier wrote:
Hi Hannes,
I like the idea and most of the patch set, so I only have a few questions left
and some review comments below.
Just curious: Do you also plan to adapt systemd/udev, especially path_id for
fc transport with its open coded copy of int_to_scsilun()?
Yes.
Since I don't see zfcp touched in this patch set, assuming this set will get
merged, I plan to adapt a few spots in zfcp that might not work
with 64 bit
luns out of the box although most of it already works with 64 bit
luns inside.
Ah. Yes, this might be a good idea. I've already got a patch from
QLogic regarding qla4xxx, so maybe we should be adding them as
separate patches on top of the original patchset.
Speaking of opaque handling of scsi luns: Lately I noticed that some sg3_utils
tools decode the lun format and only report parts of the entire
64 bit fcp lun,
e.g. sg_scan or sg_luns -d. I don't have enough historical scsi
experience to
know why that is, maybe because of some SPI background. By itself
this is not a
problem, however, rescan-scsi-bus.sh makes use of those scsi lun
parts and then
fails when matching those with the full scsi lun exposed by the
midlayer to user
space. E.g. with flat space addresses of IBM DS8000 this does not
seem to work:
# sg_luns -v -s2 -d /dev/sg2 | head
report luns cdb: a0 00 02 00 00 00 00 00 20 00 00 00
report luns: requested 8192 bytes but got 4112 bytes
Lun list length = 4104 which imples 513 lun entries
Report luns [select_report=2]:
c101
REPORT LUNS well known logical unit
40204000
Flat space addressing: lun=32
40204001
Flat space addressing: lun=32
40204002
Flat space addressing: lun=32
^^=== 0x20 of the lun's 1st short
Did I overlook something or are rescan-scsi-bus.sh and maybe other tools really
broken with some modern scsi targets?
Should've been fixed by now.
There was a bug in rescan-scsi-bus.sh which indeed tried to decode
LUNs, but that has been fixed.
On 02/19/2013 09:18 AM, Hannes Reinecke wrote:
The SCSI standard uses a 64-bit value for LUNs, and large arrays
employing large LUN numbers become more and more common.
So move the linux SCSI stack to use 64-bit LUN numbers.
Signed-off-by: Hannes Reinecke h...@suse.de
---
drivers/scsi/scsi_proc.c|2 +-
drivers/scsi/scsi_sysfs.c | 14
drivers/scsi/scsi_transport_fc.c|4 +-
drivers/scsi/scsi_transport_iscsi.c |4 +-
drivers/scsi/scsi_transport_sas.c |2 +-
drivers/scsi/sg.c |4 +-
include/scsi/scsi.h |2 +-
include/scsi/scsi_device.h | 22 ++--
include/scsi/scsi_transport.h |2 +-
50 files changed, 239 insertions(+), 247 deletions(-)
--- a/drivers/scsi/scsi_proc.c
+++ b/drivers/scsi/scsi_proc.c
@@ -196,7 +196,7 @@ static int proc_print_scsidevice(struct device *dev, void
*data)
sdev = to_scsi_device(dev);
seq_printf(s,
- Host: scsi%d Channel: %02d Id: %02d Lun: %02d\n Vendor: ,
+ Host: scsi%d Channel: %02d Id: %02d Lun: %02llu\n Vendor: ,
sdev-host-host_no, sdev-channel, sdev-id, sdev-lun);
for (i = 0; i 8; i++) {
if (sdev-vendor[i] = 0x20)
Is it intentional that you did not adapt scsi_add_single_device(),
scsi_remove_single_device(), proc_scsi_write() to cope with 64
bit luns?
(in the admittedly old and probably somewhat deprecated procfs interface;
but then again, proc_print_scsidevice can output 64 bit luns now)
I deliberately did _not_ touch procfs (apart from the necessary
bits). Precisely because it's being marked as deprecated.
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 931a7d9..6e98f05 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -80,7 +80,7 @@ const char *scsi_host_state_name(enum scsi_host_state state)
return name;
}
-static int check_set(unsigned int *val, char *src)
+static int check_set(unsigned long long *val, char *src)
{
char *last;
@@ -90,7 +90,7 @@ static int check_set(unsigned int *val, char *src)
/*
* Doesn't check for int overflow
*/
- *val = simple_strtoul(src, last, 0);
+ *val = simple_strtoull(src, last, 0);
if (*last != '\0')
return 1;
}
@@ -99,11 +99,11 @@ static int check_set(unsigned int *val, char *src)
static int scsi_scan(struct Scsi_Host *shost, const char *str)
{
- char s1[15], s2[15], s3[15], junk;
- unsigned int channel, id, lun;
+ char s1[15], s2[15], s3[17], junk;
Since we use automatic base detection with the 3rd argument of simple_strtoull()
being 0 in check_set()
Re: [PATCH 0/4] scsi: 64-bit LUN support
On 13-02-21 11:32 AM, James Bottomley wrote:
On Thu, 2013-02-21 at 16:15 +, Elliott, Robert (Server Storage)
wrote:
Regarding changes like this:
- printk(MYIOC_s_NOTE_FMT [%d:%d:%d:%d]
+ printk(MYIOC_s_NOTE_FMT [%d:%d:%d:%llu]
FCP_ResponseInfo=%08xh\n, ioc-name,
sc-device-host-host_no, sc-device-channel,
sc-device-id, sc-device-lun,
It might be preferable to print the LUN values in hex rather than
decimal, particularly if they are large values. SAM-5 includes some
guidance for displaying LUNs, shown below.
We can't really change from decimal to hex without causing confusion and
possibly breaking ABIs. All the existing SCSI references look like
h:c:t:l and all expect l to be a simple decimal. It's not just in the
logs, we have active use of this form in all the /sys/class/scsi_*/
directories and some tools may parse this value.
One important goal is to match the format, if any, that the user must
use in a configuration file or command line argument, so
cutting-and-pasting the LUN value works. So, the answer might differ
for prints from different drivers. If a driver expects decimal input
values, then print decimal.
SAM-5 excerpt:
4.7.2 Logical unit representation format
[...]
We're a bit bound by kernel convention here as well. To retain
compatibility with SPI and flat addressing schemes, we really need to
show the 8 and 16 bit flat addresses as simple decimal numerics.
However, we *might* be free to move to a more hierarchical scheme with
the multi-level luns, since I don't think there's to many people who've
got arrays that output them (yet).
For those of you that don't remember, back when the Linux
OS was born, a SCSI READ(6) command looked like this:
==
Bit| 7| 6| 5| 4| 3| 2| 1| 0|
Byte |||||||||
==
0 | Operation Code (08h)|
-|---|
1 | Logical Unit Number | (MSB) |
-|-- ---|
2 | Logical Block Address |
-|--- ---|
3 | (LSB) |
-|---|
4 | Transfer Length |
-|---|
5 | Control |
==
Notice that 3 bit LUN field tucked into byte 1 of the cdb.
There may be still remnants of code in the Linux SCSI
subsystem to support that. Since then LUNs have grown to 16,
32 and now 64 bits. Will they keep expanding?
My point is that a T10 sanctioned LUN representation
can be a hard act for an OS to follow.
Fixing Linux's broken 32 bit word-flipped LUN
should be done as a matter of urgency, IMO. Here I am
referring to Hannes Reinecke patch:
[PATCH 1/4] scsi_scan: Fixup scsilun_to_int()
Extending Linux's 32 bit word-flipped LUN to a 64 bit
word-flipped LUN seems like the least disruptive change
for the Linux user space. Existing small LUN formats
would continue to yield the same sysfs and bsg
file/directory names. And my lsscsi utility would
continue to work.
lsscsi will still need some work to support 64 bit
word-flipped LUNs. The simple one is to expand the LUN
decoding (currently expecting a 32 bit signed integer)
to accept uint64_t . Also I would like to add a
--lunhex option ('-x' as the more obvious short option
letters are already used) to show the LUN in hex along
the lines of what Robert Elliott (and SAM-5) propose.
As an example showing the REPORT LUNS well known LUNS
as a non-trivial LUN:
# lsscsi
[0:0:0:0]diskATA INTEL SSDSC2CW12 400i /dev/sda
[6:0:0:1]diskLinuxscsi_debug 0004 /dev/sdb
[6:0:0:49409]wlunLinuxscsi_debug 0004 -
# lsscsi -x
[0:0:0:0x] diskATA INTEL SSDSC2CW12 400i /dev/sda
[6:0:0:0x0001] diskLinuxscsi_debug 0004 /dev/sdb
[6:0:0:0xc101] wlunLinuxscsi_debug 0004 -
# lsscsi -xx
[0:0:0:0x] diskATA INTEL SSDSC2CW12 400i /dev/sda
[6:0:0:0x0001] diskLinuxscsi_debug 0004 /dev/sdb
[6:0:0:0xc101] wlunLinuxscsi_debug 0004 -
Also, given an
[PATCH V6 Resend 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
This patch set adds following features - Seggregate PCI specific code in ufshcd.c and corrected copyright - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module - Adds Platform glue driver ufshcd-pltfrm.c - Update correct transfer size in Command UPIU Vinayak Holikatti (4): [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver [SCSI] ufs: Add Platform glue driver for ufshcd [SCSI] ufs: Correct the expected data transfersize drivers/scsi/ufs/Kconfig | 87 +--- drivers/scsi/ufs/Makefile|2 + drivers/scsi/ufs/ufs.h | 44 ++--- drivers/scsi/ufs/ufshcd-pci.c| 211 +++ drivers/scsi/ufs/ufshcd-pltfrm.c | 217 +++ drivers/scsi/ufs/ufshcd.c| 425 -- drivers/scsi/ufs/ufshcd.h| 202 ++ drivers/scsi/ufs/ufshci.h| 44 ++--- 8 files changed, 811 insertions(+), 421 deletions(-) create mode 100644 drivers/scsi/ufs/ufshcd-pci.c create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c create mode 100644 drivers/scsi/ufs/ufshcd.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V6 Resend 1/4] [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code
This patch seggregates the PCI specific code in ufshcd.c to make it ready for splitting into core ufs driver and PCI glue driver. Also copyright header modification to remove extra warranty disclaim. Reviewed-by: Arnd Bergmann a...@arndb.de Reviewed-by: Namjae Jeon linkinj...@gmail.com Reviewed-by: Subhash Jadavani subha...@codeaurora.org Tested-by: Maya Erez me...@codeaurora.org Signed-off-by: Vinayak Holikatti vinholika...@gmail.com Signed-off-by: Santosh Yaraganavi santos...@gmail.com --- drivers/scsi/ufs/Kconfig | 50 +++ drivers/scsi/ufs/ufs.h| 44 +++ drivers/scsi/ufs/ufshcd.c | 348 +++- drivers/scsi/ufs/ufshci.h | 44 +++ 4 files changed, 267 insertions(+), 219 deletions(-) diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig index 8f27f9d..8ee40df 100644 --- a/drivers/scsi/ufs/Kconfig +++ b/drivers/scsi/ufs/Kconfig @@ -2,45 +2,35 @@ # Kernel configuration file for the UFS Host Controller # # This code is based on drivers/scsi/ufs/Kconfig -# Copyright (C) 2011 Samsung Samsung India Software Operations +# Copyright (C) 2011-2013 Samsung India Software Operations +# +# Authors: +# Santosh Yaraganavi santosh...@samsung.com +# Vinayak Holikatti h.vina...@samsung.com # -# Santosh Yaraganavi santosh...@samsung.com -# Vinayak Holikatti h.vina...@samsung.com - # This program is free software; you can redistribute it and/or # modify it under the terms of the GNU General Public License # as published by the Free Software Foundation; either version 2 # of the License, or (at your option) any later version. - +# See the COPYING file in the top-level directory or visit +# http://www.gnu.org/licenses/gpl-2.0.html +# # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. - -# NO WARRANTY -# THE PROGRAM IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR -# CONDITIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED INCLUDING, WITHOUT -# LIMITATION, ANY WARRANTIES OR CONDITIONS OF TITLE, NON-INFRINGEMENT, -# MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Each Recipient is -# solely responsible for determining the appropriateness of using and -# distributing the Program and assumes all risks associated with its -# exercise of rights under this Agreement, including but not limited to -# the risks and costs of program errors, damage to or loss of data, -# programs or equipment, and unavailability or interruption of operations. - -# DISCLAIMER OF LIABILITY -# NEITHER RECIPIENT NOR ANY CONTRIBUTORS SHALL HAVE ANY LIABILITY FOR ANY -# DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL -# DAMAGES (INCLUDING WITHOUT LIMITATION LOST PROFITS), HOWEVER CAUSED AND -# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR -# TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE -# USE OR DISTRIBUTION OF THE PROGRAM OR THE EXERCISE OF ANY RIGHTS GRANTED -# HEREUNDER, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES - -# You should have received a copy of the GNU General Public License -# along with this program; if not, write to the Free Software -# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, -# USA. +# +# This program is provided AS IS and WITH ALL FAULTS and +# without warranty of any kind. You are solely responsible for +# determining the appropriateness of using and distributing +# the program and assume all risks associated with your exercise +# of rights with respect to the program, including but not limited +# to infringement of third party rights, the risks and costs of +# program errors, damage to or loss of data, programs or equipment, +# and unavailability or interruption of operations. Under no +# circumstances will the contributor of this Program be liable for +# any damages of any kind arising from your use or distribution of +# this program. config SCSI_UFSHCD tristate Universal Flash Storage host controller driver diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h index b207529..139bc06 100644 --- a/drivers/scsi/ufs/ufs.h +++ b/drivers/scsi/ufs/ufs.h @@ -2,45 +2,35 @@ * Universal Flash Storage Host controller driver * * This code is based on drivers/scsi/ufs/ufs.h - * Copyright (C) 2011-2012 Samsung India Software Operations + * Copyright (C) 2011-2013 Samsung India Software Operations * - * Santosh Yaraganavi santosh...@samsung.com - * Vinayak Holikatti h.vina...@samsung.com + * Authors: + * Santosh Yaraganavi santosh...@samsung.com + * Vinayak Holikatti h.vina...@samsung.com * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; either version 2 * of the License, or (at your option)
[PATCH V6 Resend 3/4] [SCSI] ufs: Add Platform glue driver for ufshcd
This patch adds Platform glue driver for ufshcd.
Reviewed-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Namjae Jeon linkinj...@gmail.com
Reviewed-by: Subhash Jadavani subha...@codeaurora.org
Reviewed-by: Sujit Reddy Thumma sthu...@codeaurora.org
Tested-by: Maya Erez me...@codeaurora.org
Signed-off-by: Vinayak Holikatti vinholika...@gmail.com
Signed-off-by: Santosh Yaraganavi santos...@gmail.com
---
drivers/scsi/ufs/Kconfig | 11 ++
drivers/scsi/ufs/Makefile|1 +
drivers/scsi/ufs/ufshcd-pltfrm.c | 217 ++
3 files changed, 229 insertions(+), 0 deletions(-)
create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 0371047..35faf24 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -57,3 +57,14 @@ config SCSI_UFSHCD_PCI
If you have a controller with this interface, say Y or M here.
If unsure, say N.
+
+config SCSI_UFSHCD_PLATFORM
+ tristate Platform bus based UFS Controller support
+ depends on SCSI_UFSHCD
+ ---help---
+ This selects the UFS host controller support. Select this if
+ you have an UFS controller on Platform bus.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
diff --git a/drivers/scsi/ufs/Makefile b/drivers/scsi/ufs/Makefile
index 9eda0df..1e5bd48 100644
--- a/drivers/scsi/ufs/Makefile
+++ b/drivers/scsi/ufs/Makefile
@@ -1,3 +1,4 @@
# UFSHCD makefile
obj-$(CONFIG_SCSI_UFSHCD) += ufshcd.o
obj-$(CONFIG_SCSI_UFSHCD_PCI) += ufshcd-pci.o
+obj-$(CONFIG_SCSI_UFSHCD_PLATFORM) += ufshcd-pltfrm.o
diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
new file mode 100644
index 000..a661b31
--- /dev/null
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -0,0 +1,217 @@
+/*
+ * Universal Flash Storage Host controller Platform bus based glue driver
+ *
+ * This code is based on drivers/scsi/ufs/ufshcd-pltfrm.c
+ * Copyright (C) 2011-2013 Samsung India Software Operations
+ *
+ * Authors:
+ * Santosh Yaraganavi santosh...@samsung.com
+ * Vinayak Holikatti h.vina...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * See the COPYING file in the top-level directory or visit
+ * http://www.gnu.org/licenses/gpl-2.0.html
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This program is provided AS IS and WITH ALL FAULTS and
+ * without warranty of any kind. You are solely responsible for
+ * determining the appropriateness of using and distributing
+ * the program and assume all risks associated with your exercise
+ * of rights with respect to the program, including but not limited
+ * to infringement of third party rights, the risks and costs of
+ * program errors, damage to or loss of data, programs or equipment,
+ * and unavailability or interruption of operations. Under no
+ * circumstances will the contributor of this Program be liable for
+ * any damages of any kind arising from your use or distribution of
+ * this program.
+ */
+
+#include ufshcd.h
+#include linux/platform_device.h
+
+#ifdef CONFIG_PM
+/**
+ * ufshcd_pltfrm_suspend - suspend power management function
+ * @pdev: pointer to Platform device handle
+ * @mesg: power state
+ *
+ * Returns 0
+ */
+static int ufshcd_pltfrm_suspend(struct platform_device *pdev,
+pm_message_t mesg)
+{
+ struct ufs_hba *hba = platform_get_drvdata(pdev);
+
+ /*
+* TODO:
+* 1. Call ufshcd_suspend
+* 2. Do bus specific power management
+*/
+
+ disable_irq(hba-irq);
+
+ return 0;
+}
+
+/**
+ * ufshcd_pltfrm_resume - resume power management function
+ * @pdev: pointer to Platform device handle
+ *
+ * Returns 0
+ */
+static int ufshcd_pltfrm_resume(struct platform_device *pdev)
+{
+ struct ufs_hba *hba = platform_get_drvdata(pdev);
+
+ /*
+* TODO:
+* 1. Call ufshcd_resume.
+* 2. Do bus specific wake up
+*/
+
+ enable_irq(hba-irq);
+
+ return 0;
+}
+#else
+#define ufshcd_pltfrm_suspend NULL
+#define ufshcd_pltfrm_resume NULL
+#endif
+
+/**
+ * ufshcd_pltfrm_probe - probe routine of the driver
+ * @pdev: pointer to Platform device handle
+ *
+ * Returns 0 on success, non-zero value on failure
+ */
+static int __devinit
+ufshcd_pltfrm_probe(struct platform_device *pdev)
+{
+ struct ufs_hba *hba;
+ void __iomem *mmio_base;
+ struct resource *mem_res;
+ struct resource *irq_res;
+
[PATCH V6 Resend 4/4] [SCSI] ufs: Correct the expected data transfersize
This patch corrects the expected data transfer size of the command UPIU. The current implementation of cmd-transfersize is wrong as it probably equal to sector size. With this implementation the transfer size is updated correctly Reported-by: KOBAYASHI Yoshitake yoshitake.kobaya...@toshiba.co.jp Reviewed-by: Arnd Bergmann a...@arndb.de Reviewed-by: Namjae Jeon linkinj...@gmail.com Reviewed-by: Subhash Jadavani subha...@codeaurora.org Tested-by: Maya Erez me...@codeaurora.org Signed-off-by: Santosh Yaraganavi santos...@gmail.com Signed-off-by: Vinayak Holikatti vinholika...@gmail.com --- drivers/scsi/ufs/ufshcd.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index 60fd40c..c32a478 100644 --- a/drivers/scsi/ufs/ufshcd.c +++ b/drivers/scsi/ufs/ufshcd.c @@ -478,7 +478,7 @@ static void ufshcd_compose_upiu(struct ufshcd_lrb *lrbp) ucd_cmd_ptr-header.dword_2 = 0; ucd_cmd_ptr-exp_data_transfer_len = - cpu_to_be32(lrbp-cmd-transfersize); + cpu_to_be32(lrbp-cmd-sdb.length); memcpy(ucd_cmd_ptr-cdb, lrbp-cmd-cmnd, -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 Resend 0/4] [SCSI] ufs: Adds glue drivers to ufshcd
James, I have rebased these patches with top scsi-misc tree. On Mon, Feb 25, 2013 at 9:44 PM, Vinayak Holikatti vinholika...@gmail.com wrote: This patch set adds following features - Seggregate PCI specific code in ufshcd.c and corrected copyright - Adds PCI glue driver ufshcd-pci.c and ufshcd.c become core module - Adds Platform glue driver ufshcd-pltfrm.c - Update correct transfer size in Command UPIU Vinayak Holikatti (4): [SCSI] drivers/scsi/ufs: Seggregate PCI Specific Code [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver [SCSI] ufs: Add Platform glue driver for ufshcd [SCSI] ufs: Correct the expected data transfersize drivers/scsi/ufs/Kconfig | 87 +--- drivers/scsi/ufs/Makefile|2 + drivers/scsi/ufs/ufs.h | 44 ++--- drivers/scsi/ufs/ufshcd-pci.c| 211 +++ drivers/scsi/ufs/ufshcd-pltfrm.c | 217 +++ drivers/scsi/ufs/ufshcd.c| 425 -- drivers/scsi/ufs/ufshcd.h| 202 ++ drivers/scsi/ufs/ufshci.h| 44 ++--- 8 files changed, 811 insertions(+), 421 deletions(-) create mode 100644 drivers/scsi/ufs/ufshcd-pci.c create mode 100644 drivers/scsi/ufs/ufshcd-pltfrm.c create mode 100644 drivers/scsi/ufs/ufshcd.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 Resend 2/4] [SCSI] drivers/scsi/ufs: Separate PCI code into glue driver
On Mon, 2013-02-25 at 21:44 +0530, Vinayak Holikatti wrote: This patch separates PCI code from ufshcd.c and makes it as a core driver module and adds a new file ufshcd-pci.c as PCI glue driver. You rebased this, but didn't compile it: CC [M] drivers/scsi/ufs/ufshcd-pci.o drivers/scsi/ufs/ufshcd-pci.c:131:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘ufshcd_pci_probe’ drivers/scsi/ufs/ufshcd-pci.c:196:11: error: ‘ufshcd_pci_probe’ undeclared here (not in a function) drivers/scsi/ufs/ufshcd-pci.c:197:2: error: implicit declaration of function ‘__devexit_p’ [-Werror=implicit-function-declaration] drivers/scsi/ufs/ufshcd-pci.c:197:2: error: initializer element is not constant drivers/scsi/ufs/ufshcd-pci.c:197:2: error: (near initialization for ‘ufshcd_pci_driver.remove’) drivers/scsi/ufs/ufshcd-pci.c:110:12: warning: ‘ufshcd_set_dma_mask’ defined but not used [-Wunused-function] cc1: some warnings being treated as errors make[3]: *** [drivers/scsi/ufs/ufshcd-pci.o] Error 1 That's because of a stray __devinit and devexit_p() which no-longer exist in the kernel. I've fixed this up. James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 Resend 3/4] [SCSI] ufs: Add Platform glue driver for ufshcd
On Mon, 2013-02-25 at 21:44 +0530, Vinayak Holikatti wrote: This patch adds Platform glue driver for ufshcd. Even after fixing the __devXX issues, I still get this: rivers/scsi/ufs/ufshcd-pltfrm.c:196:2: warning: initialization from incompatible pointer type [enabled by default] drivers/scsi/ufs/ufshcd-pltfrm.c:196:2: warning: (near initialization for ‘ufshcd_dev_pm_ops.suspend’) [enabled by default] drivers/scsi/ufs/ufshcd-pltfrm.c:197:2: warning: initialization from incompatible pointer type [enabled by default] drivers/scsi/ufs/ufshcd-pltfrm.c:197:2: warning: (near initialization for ‘ufshcd_dev_pm_ops.resume’) [enabled by default] That's apparently because the function protoypes are wrong. I'm not sure why this is, but I stopped applying here, please fix. Thanks, James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] scsi: use 64-bit LUNs
On 13-02-25 10:33 AM, Steffen Maier wrote: Hi Hannes, I like the idea and most of the patch set, so I only have a few questions left and some review comments below. Just curious: Do you also plan to adapt systemd/udev, especially path_id for fc transport with its open coded copy of int_to_scsilun()? Since I don't see zfcp touched in this patch set, assuming this set will get merged, I plan to adapt a few spots in zfcp that might not work with 64 bit luns out of the box although most of it already works with 64 bit luns inside. Speaking of opaque handling of scsi luns: Lately I noticed that some sg3_utils tools decode the lun format and only report parts of the entire 64 bit fcp lun, e.g. sg_scan or sg_luns -d. I don't have enough historical scsi experience to know why that is, maybe because of some SPI background. By itself this is not a problem, however, rescan-scsi-bus.sh makes use of those scsi lun parts and then fails when matching those with the full scsi lun exposed by the midlayer to user space. E.g. with flat space addresses of IBM DS8000 this does not seem to work: # sg_luns -v -s2 -d /dev/sg2 | head report luns cdb: a0 00 02 00 00 00 00 00 20 00 00 00 report luns: requested 8192 bytes but got 4112 bytes Lun list length = 4104 which imples 513 lun entries Report luns [select_report=2]: c101 REPORT LUNS well known logical unit 40204000 Flat space addressing: lun=32 40204001 Flat space addressing: lun=32 40204002 Flat space addressing: lun=32 ^^=== 0x20 of the lun's 1st short According to sam5r13.pdf ** section 4.7.7.3 you owe me a beer :-) Flat space addressing is only 16 bits long. Extended Flat space and Long Extended Flat space addressing would have the top bit set in byte 0 (and no part of the actual lun is in byte 0). # sg_luns --test=40204002 -H Decoded LUN: Flat space addressing: lun=0x0020 A vendor specific LUN or am I misreading SAM-5? sg_luns --test=d2204002 -H Decoded LUN: Extended flat space addressing: lun=0x204002 snip I guess we cannot adapt sg_ioctl SG_GET_SCSI_ID that easily without breaking the user space interface. But how does a user of this interface know that there are 64 bit luns in the kernel but the ioctl cannot handle the new kernel functionality (and may be affected by aliasing)? I think that would involve adding a new ioctl (e.g. SG_GET_SCSI_ID64) and last time I proposed that L. Torvalds said something like: over his dead body. Doug Gilbert ** now we have conglomerate LUNs! -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[LSF/MM TOPIC] Making sure soft SCSI Targets are Valid
Hi, This is my attend request to to co-present a paper with Lee Duncan. regards ronnie sahlberg On Tue, Jan 29, 2013 at 11:13 AM, Lee Duncan ldun...@suse.com wrote: Hi: I'm not sure if there is much interest in this, but I've recently realized that there is no good free software to validate iSCSI targets, not to mention FCOE targets, IB soft targets, etc. There's just no way to know if any change you make is legal short of learning to speak SCSI geek spec (or waiting to see what fails when you make a subtle change). So I have been working with the (user-space) libiscsi creator and maintainer, Ronnie Sahlberg, to enhance his test suite. But this only addresses iSCSI targets. Some of his tests have already shown problems like kernel panics when an incorrect bit is injected, showing the need for such testing. It occurs to me it would be most valuable if we had more generic SCSI tests, not even limited to soft targets, available to developers and manufacturers. How best to support such tests with our SCSI layer, and what tests are needed now and in the future may be a good topic for discussion. -- Lee Duncan SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [SCSI] Wake blockdev queue in scsi_internal_device_unblock() for SDEV_RUNNING
From: Roland Dreier rol...@purestorage.com If a SCSI device's old state is already SDEV_RUNNING and we're moving to the same SDEV_RUNNING state, still wake the blockdev queue in scsi_internal_device_unblock(). This fixes a case where we silently hang SCSI commands forever during device discovery. One way this can happen is when mpt2sas is discovering a reasonably big SAS topology, and the sd driver has queued up a bunch of sd_probe_async() instances that are queueing SCSI commands to various devices. If at the same time a SAS fabric event goes to the HBA, what can happen is the following: - mpt2sas calls _scsih_block_io_all_device() - scsi_internal_device_block(sdev) (In response to some HBA firmware event like MPI2_EVENT_SAS_BROADCAST_PRIMITIVE) Now sdev state is SDEV_BLOCK and blockdev queue has QUEUE_FLAG_STOPPED set. - Someone like scsi_add_lun() calls scsi_device_set_state(sdev, SDEV_RUNNING) (SCSI bus scanning runs asynchronously to firmware event handling) Now sdev state is SDEV_RUNNING but blockdev queue still has QUEUE_FLAG_STOPPED set - mpt2sas calls _scsih_ublock_io_all_device() - scsi_internal_device_unblock(sdev, SDEV_RUNNING) (Finishes handling the firmware event) With the old scsi_lib code, scsi_internal_device_unblock() will return an error at this point because the sdev state is already SDEV_RUNNING. This means we skip the call to blk_start_queue() and never actually start executing commands again. Fix this by still going ahead and finishing scsi_internal_device_unblock() even if the sdev state is already SDEV_RUNNING. Signed-off-by: Roland Dreier rol...@purestorage.com --- drivers/scsi/scsi_lib.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 765398c..75108ea 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -2495,7 +2495,9 @@ scsi_internal_device_unblock(struct scsi_device *sdev, else sdev-sdev_state = SDEV_CREATED; } else if (sdev-sdev_state != SDEV_CANCEL -sdev-sdev_state != SDEV_OFFLINE) + sdev-sdev_state != SDEV_OFFLINE + (sdev-sdev_state != SDEV_RUNNING || + new_state != SDEV_RUNNING)) return -EINVAL; spin_lock_irqsave(q-queue_lock, flags); -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] fnic: Kernel panic due to FIP mode misconfiguration
If switch configured in FIP and adapter configured in non-fip mode, driver
panics while queueing FIP frame in non-existing fip_frame_queue. Added config
check before queueing FIP frame in misconfiguration case to avoid kernel panic.
Signed-off-by: Hiral Patel hiral...@cisco.com
---
drivers/scsi/fnic/fnic_fcs.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/scsi/fnic/fnic_fcs.c b/drivers/scsi/fnic/fnic_fcs.c
index 41faca4..a0092e8 100644
--- a/drivers/scsi/fnic/fnic_fcs.c
+++ b/drivers/scsi/fnic/fnic_fcs.c
@@ -603,6 +603,12 @@ static inline int fnic_import_rq_eth_pkt(struct fnic
*fnic, struct sk_buff *skb)
skb_reset_mac_header(skb);
}
if (eh-h_proto == htons(ETH_P_FIP)) {
+ if (!(fnic-config.flags VFCF_FIP_CAPABLE)) {
+ printk(KERN_ERR Dropped FIP frame, as firmware
+ uses non-FIP mode, Enable FIP
+ using UCSM\n);
+ goto drop;
+ }
skb_queue_tail(fnic-fip_frame_queue, skb);
queue_work(fnic_fip_queue, fnic-fip_frame_work);
return 1; /* let caller know packet was used */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] fnic: Incremented driver version
Incrementing driver versio after bug fixes and new feature commits. Signed-off-by: Brian Uchino buch...@cisco.com Signed-off-by: Hiral Patel hiral...@cisco.com --- drivers/scsi/fnic/fnic.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h index acec42a..b6d1f92 100644 --- a/drivers/scsi/fnic/fnic.h +++ b/drivers/scsi/fnic/fnic.h @@ -38,7 +38,7 @@ #define DRV_NAME fnic #define DRV_DESCRIPTIONCisco FCoE HBA Driver -#define DRV_VERSION1.5.0.2 +#define DRV_VERSION1.5.0.22 #define PFXDRV_NAME : #define DFX DRV_NAME %d: -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] fnic: FIP VLAN Discovery Feature Support
FIP VLAN discovery discovers the FCoE VLAN that will be used by all other FIP
protocols as well as by the FCoE encapsulation for Fibre Channel payloads on
the established virtual link. One of the goals of FC-BB-5 was to be as
nonintrusive as possible on initiators and targets, and therefore FIP VLAN
discovery occurs in the native VLAN used by the initiator or target to
exchange Ethernet traffic. The FIP VLAN discovery protocol is the only FIP
protocol running on the native VLAN; all other FIP protocols run on the
discovered FCoE VLANs.
If an administrator has manually configured FCoE VLANs on ENodes and FCFs,
there is no need to use this protocol. FIP and FCoE will run over the
configured VLANs.
An ENode without FCoE VLANs configuration would use this automated discovery
protocol to discover over which VLANs FCoE is running.
The ENode sends a FIP VLAN discovery request to a multicast MAC address called
All-FCF-MACs, which is a multicast MAC address to which all FCFs listen.
All FCFs that can be reached in the native VLAN of the ENode are expected to
respond on the same VLAN with a response that lists one or more FCoE VLANs
that are available for the ENode's VN_Port login. This protocol has the sole
purpose of allowing the ENode to discover all the available FCoE VLANs.
Now the ENode may enable a subset of these VLANs for FCoE Running the FIP
protocol in these VLANs on a per VLAN basis. And FCoE data transactions also
would occur on this VLAN. Hence, Except for FIP VLAN discovery, all other FIP
and FCoE traffic runs on the selected FCoE VLAN. Its only the FIP VLAN
Discovery protocol that is permitted to run on the Default native VLAN of the
system.
[ NOTE ]
We are working on moving this feature definitions and functionality to libfcoe
module. We need this patch to be approved, as Suse is looking forward to merge
this feature in SLES 11 SP3 release. Once this patch is approved, we will
submit patch which should move vlan discovery feature to libfoce.
Signed-off-by: Anantha Prakash T atung...@cisco.com
Signed-off-by: Hiral Patel hiral...@cisco.com
---
drivers/scsi/fnic/fnic.h| 32 +++
drivers/scsi/fnic/fnic_fcs.c| 558 ++-
drivers/scsi/fnic/fnic_fip.h| 68 +
drivers/scsi/fnic/fnic_main.c | 51 +++-
drivers/scsi/fnic/vnic_dev.c| 10 +
drivers/scsi/fnic/vnic_dev.h|2 +
drivers/scsi/fnic/vnic_devcmd.h | 67 +
7 files changed, 784 insertions(+), 4 deletions(-)
create mode 100644 drivers/scsi/fnic/fnic_fip.h
diff --git a/drivers/scsi/fnic/fnic.h b/drivers/scsi/fnic/fnic.h
index 98436c3..acec42a 100644
--- a/drivers/scsi/fnic/fnic.h
+++ b/drivers/scsi/fnic/fnic.h
@@ -192,6 +192,18 @@ enum fnic_state {
struct mempool;
+enum fnic_evt {
+ FNIC_EVT_START_VLAN_DISC = 1,
+ FNIC_EVT_START_FCF_DISC = 2,
+ FNIC_EVT_MAX,
+};
+
+struct fnic_event {
+ struct list_head list;
+ struct fnic *fnic;
+ enum fnic_evt event;
+};
+
/* Per-instance private data structure */
struct fnic {
struct fc_lport *lport;
@@ -254,6 +266,18 @@ struct fnic {
struct sk_buff_head frame_queue;
struct sk_buff_head tx_queue;
+ /*** FIP related data members -- start ***/
+ void (*set_vlan)(struct fnic *, u16 vlan);
+ struct work_struct fip_frame_work;
+ struct sk_buff_head fip_frame_queue;
+ struct timer_list fip_timer;
+ struct list_headvlans;
+ spinlock_t vlans_lock;
+
+ struct work_struct event_work;
+ struct list_headevlist;
+ /*** FIP related data members -- end ***/
+
/* copy work queue cache line section */
cacheline_aligned struct vnic_wq_copy wq_copy[FNIC_WQ_COPY_MAX];
/* completion queue cache line section */
@@ -278,6 +302,7 @@ static inline struct fnic *fnic_from_ctlr(struct fcoe_ctlr
*fip)
}
extern struct workqueue_struct *fnic_event_queue;
+extern struct workqueue_struct *fnic_fip_queue;
extern struct device_attribute *fnic_attrs[];
void fnic_clear_intr_mode(struct fnic *fnic);
@@ -289,6 +314,7 @@ int fnic_send(struct fc_lport *, struct fc_frame *);
void fnic_free_wq_buf(struct vnic_wq *wq, struct vnic_wq_buf *buf);
void fnic_handle_frame(struct work_struct *work);
void fnic_handle_link(struct work_struct *work);
+void fnic_handle_event(struct work_struct *work);
int fnic_rq_cmpl_handler(struct fnic *fnic, int);
int fnic_alloc_rq_frame(struct vnic_rq *rq);
void fnic_free_rq_buf(struct vnic_rq *rq, struct vnic_rq_buf *buf);
@@ -321,6 +347,12 @@ void fnic_handle_link_event(struct fnic *fnic);
int fnic_is_abts_pending(struct fnic *, struct scsi_cmnd *);
+void fnic_handle_fip_frame(struct work_struct *work);
+void fnic_handle_fip_event(struct fnic *fnic);
+void fnic_fcoe_reset_vlans(struct fnic *fnic);
+void fnic_fcoe_evlist_free(struct fnic *fnic);
+extern void fnic_handle_fip_timer(struct fnic *fnic);
+
static
Re: [scsi:misc 102/104] drivers/scsi/fnic/fnic_fcs.c:381:31: sparse: cast to restricted __be16
Hey James,
I have fixed FIP Vlan discovery patch for sparse warnings and resubmitted
3 pending patches.
The patches 1-7 got committed to misc branch already has the fix for
sparse and other problems.
Thanks,
Hiral
On 2/24/13 12:18 AM, James Bottomley jbottom...@parallels.com wrote:
On Sat, 2013-02-23 at 03:07 +0800, kbuild test robot wrote:
tree: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git misc
head: c2983bd66114a8047bb74e4d347db8ffde381f71
commit: 5f0d0de727c055e15c2602e4905c6b75509ce9d7 [102/104] [SCSI] fnic:
FIP VLAN Discovery Feature Support
sparse warnings: (new ones prefixed by )
drivers/scsi/fnic/fnic_fcs.c:381:31: sparse: cast to restricted
__be16
drivers/scsi/fnic/fnic_fcs.c:381:31: sparse: cast to restricted
__be16
drivers/scsi/fnic/fnic_fcs.c:381:31: sparse: cast to restricted
__be16
drivers/scsi/fnic/fnic_fcs.c:381:31: sparse: cast to restricted
__be16
drivers/scsi/fnic/cq_enet_desc.h:142:39: sparse: restricted __le16
degrades to integer
include/scsi/fc/fc_fcoe.h:101:36: sparse: cast truncates bits from
constant value (efc becomes fc)
include/scsi/fc/fc_fcoe.h:102:23: sparse: cast truncates bits from
constant value (efc00 becomes 0)
drivers/scsi/fnic/fnic_fcs.c:1198:6: sparse: context imbalance in
'fnic_handle_fip_timer' - different lock contexts for basic block
vim +381 drivers/scsi/fnic/fnic_fcs.c
365 Received VLAN response...\n);
366
367 fiph = (struct fip_header *) skb-data;
368
369 FNIC_FCS_DBG(KERN_INFO, fnic-lport-host,
370 Received VLAN response... OP 0x%x SUB_OP
0x%x\n,
371 ntohs(fiph-fip_op), fiph-fip_subcode);
372
373 rlen = ntohs(fiph-fip_dl_len) * 4;
374 fnic_fcoe_reset_vlans(fnic);
375 spin_lock_irqsave(fnic-vlans_lock, flags);
376 desc = (struct fip_desc *)(fiph + 1);
377 while (rlen 0) {
378 dlen = desc-fip_dlen * FIP_BPW;
379 switch (desc-fip_dtype) {
380 case FIP_DT_VLAN:
381 vid = ntohs(((struct fip_vlan_desc
*)desc)-fd_vlan);
382 shost_printk(KERN_INFO,
fnic-lport-host,
383 process_vlan_resp: FIP VLAN
%d\n, vid);
384 vlan = (struct fcoe_vlan *)
kmalloc(sizeof(*vlan),
385
GFP_ATOMIC);
386 if (!vlan) {
387 /* retry from timer */
388
spin_unlock_irqrestore(fnic-vlans_lock,
389 flags);
OK, I'll drop the series from this patch on. I take it the sparse and
other problems in the patches before this are all fixed?
James
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] dm: Avoid use-after-free of a mapped device
On 02/26/13 00:09, Bart Van Assche wrote: Without your patch my test failed after two or three iterations. With your patch my test is still running after 53 iterations. So if you want you can add Tested-by: Bart Van Assche bvanass...@acm.org. Great. Thanks for testing. I'll submit a patch with your Reported-by and Tested-by. Your e-mail and the above patch are also interesting because these explain why reverting to the v3.7 of drivers/md made my test succeed. Note: even if this patch gets accepted I think it's still useful to modify blk_run_queue() such that it converts recursion into iteration. Yes. That's a separate discussion. Though I'm not sure if it's ok in general to implicitly convert sync run-queue to async one. -- Jun'ichi Nomura, NEC Corporation -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] target updates for v3.9-rc1
Hi Linus, Here are the target pending updates for v3.9-rc1 code. Please go ahead and pull from: git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next The highlights in this series include: - Improve sg_table lookup scalability in RAMDISK_MCP (martin) - Add device attribute to expose config name for INQUIRY model (tregaron) - Convert tcm_vhost to use lock-less list for cmd completion (asias) - Add tcm_vhost support for multiple target's per endpoint (asias) - Add tcm_vhost support for multiple queues per vhost (asias) - Add missing mapped_lun bounds checking during make_mappedlun setup in generic fabric configfs code (jan engelhardt + nab) - Enforce individual iscsi-target network portal export once per TargetName endpoint (grover + nab) - Add WRITE_SAME w/ UNMAP=0 emulation to FILEIO backend (nab) Things have been mostly quiet this round, with majority of the work being done on the iser-target WIP driver + associated iscsi-target refactoring patches currently in flight for v3.10 code. At this point there is one patch series left outstanding from Asias to add support for UNMAP + WRITE_SAME w/ UNMAP=1 to FILEIO awaiting feedback from hch Co, that will likely be included in a post v3.9-rc1 PULL request if there are no objections. Also, there is a regression bug recently reported off-list that seems to be effecting v3.5 and v3.6 kernels with MSFT iSCSI initiators that is still being tracked down. No word if this effects = v3.7 just yet, but if so there will likely another PULL request coming your way.. Thank you, --nab Asias He (6): tcm_vhost: Use llist for cmd completion list tcm_vhost: Introduce iov_num_pages tcm_vhost: Use iov_num_pages to calculate sgl_count tcm_vhost: Optimize gup in vhost_scsi_map_to_sgl tcm_vhost: Multi-target support tcm_vhost: Multi-queue support Dan Carpenter (4): target: change sprintf to snprintf in transport_dump_vpd_ident iscsi-target: make some temporary buffers larger target: don't always say ipv6 as address type target: don't truncate the fail intr address Hannes Reinecke (2): target: Export SPC inquiry emulation target_core_rd: break out unterminated loop during copy Martin Svec (1): target/rd: improve sg_table lookup scalability Nicholas Bellinger (6): target/iblock: Use backend REQ_FLUSH hint for WriteCacheEnabled status target: Fix lookup of dynamic NodeACLs during cached demo-mode operation target: Add missing mapped_lun bounds checking during make_mappedlun setup iscsi-target: Refactor iscsit_get_np sockaddr matching into iscsit_check_np_match iscsi-target: Enforce individual network portal export once per TargetName target/file: Add WRITE_SAME w/ UNMAP=0 emulation support Roland Dreier (6): target: Remove useless if statement target: Remove never-used TMR_FABRIC_TMR enum value target: Fix sense data for out-of-bounds IO operations target: Fix error checking for UNMAP commands target: Fix parameter list length checking in MODE SELECT target: Rename spc_get_write_same_sectors - sbc_get_write_same_sectors Tregaron Bayly (1): target: Add device attribute to expose config_item_name for INQUIRY model drivers/target/iscsi/iscsi_target.c| 65 --- drivers/target/iscsi/iscsi_target.h|2 + drivers/target/iscsi/iscsi_target_parameters.c |8 +- drivers/target/iscsi/iscsi_target_stat.c | 25 ++- drivers/target/iscsi/iscsi_target_tpg.c| 39 drivers/target/target_core_configfs.c |4 + drivers/target/target_core_device.c| 58 - drivers/target/target_core_fabric_configfs.c | 12 +- drivers/target/target_core_file.c | 114 ++ drivers/target/target_core_iblock.c| 46 +++- drivers/target/target_core_internal.h |3 +- drivers/target/target_core_rd.c| 18 ++- drivers/target/target_core_sbc.c |8 +- drivers/target/target_core_spc.c | 42 +++- drivers/target/target_core_tmr.c | 12 - drivers/target/target_core_tpg.c | 10 +- drivers/target/target_core_transport.c | 19 ++- drivers/vhost/tcm_vhost.c | 287 +--- drivers/vhost/tcm_vhost.h |8 +- include/target/target_core_backend.h |5 +- include/target/target_core_base.h |7 +- 21 files changed, 563 insertions(+), 229 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] dm: do not replace bioset for request-based dm
This patch fixes a regression introduced in v3.8, which causes oops
like this when dm-multipath is used:
general protection fault: [#1] SMP
RIP: 0010:[810fe754] [810fe754] mempool_free+0x24/0xb0
Call Trace:
IRQ
[81187417] bio_put+0x97/0xc0
[a02247a5] end_clone_bio+0x35/0x90 [dm_mod]
[81185efd] bio_endio+0x1d/0x30
[811f03a3] req_bio_endio.isra.51+0xa3/0xe0
[811f2f68] blk_update_request+0x118/0x520
[811f3397] blk_update_bidi_request+0x27/0xa0
[811f343c] blk_end_bidi_request+0x2c/0x80
[811f34d0] blk_end_request+0x10/0x20
[a000b32b] scsi_io_completion+0xfb/0x6c0 [scsi_mod]
[a000107d] scsi_finish_command+0xbd/0x120 [scsi_mod]
[a000b12f] scsi_softirq_done+0x13f/0x160 [scsi_mod]
[811f9fd0] blk_done_softirq+0x80/0xa0
[81044551] __do_softirq+0xf1/0x250
[8142ee8c] call_softirq+0x1c/0x30
[8100420d] do_softirq+0x8d/0xc0
[81044885] irq_exit+0xd5/0xe0
[8142f3e3] do_IRQ+0x63/0xe0
[814257af] common_interrupt+0x6f/0x6f
EOI
[a021737c] srp_queuecommand+0x8c/0xcb0 [ib_srp]
[a0002f18] scsi_dispatch_cmd+0x148/0x310 [scsi_mod]
[a000a38e] scsi_request_fn+0x31e/0x520 [scsi_mod]
[811f1e57] __blk_run_queue+0x37/0x50
[811f1f69] blk_delay_work+0x29/0x40
[81059003] process_one_work+0x1c3/0x5c0
[8105b22e] worker_thread+0x15e/0x440
[8106164b] kthread+0xdb/0xe0
[8142db9c] ret_from_fork+0x7c/0xb0
The regression was introduced by the change
c0820cf5 dm: introduce per_bio_data, where dm started to replace
bioset during table replacement.
For bio-based dm, it is good because clone bios do not exist during the
table replacement.
For request-based dm, however, (not-yet-mapped) clone bios may stay in
request queue and survive during the table replacement.
So freeing the old bioset could cause the oops in bio_put().
Since the size of front_pad may change only with bio-based dm,
it is not necessary to replace bioset for request-based dm.
Reported-by: Bart Van Assche bvanass...@acm.org
Tested-by: Bart Van Assche bvanass...@acm.org
Signed-off-by: Jun'ichi Nomura j-nom...@ce.jp.nec.com
Cc: Alasdair G Kergon a...@redhat.com
Cc: Mikulas Patocka mpato...@redhat.com
Cc: Mike Snitzer snit...@redhat.com
Cc: sta...@vger.kernel.org
---
drivers/md/dm.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 314a0e2..51fefb5 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1973,15 +1973,27 @@ static void __bind_mempools(struct mapped_device *md,
struct dm_table *t)
{
struct dm_md_mempools *p = dm_table_get_md_mempools(t);
- if (md-io_pool (md-tio_pool || dm_table_get_type(t) ==
DM_TYPE_BIO_BASED) md-bs) {
- /*
-* The md already has necessary mempools. Reload just the
-* bioset because front_pad may have changed because
-* a different table was loaded.
-*/
- bioset_free(md-bs);
- md-bs = p-bs;
- p-bs = NULL;
+ if (md-io_pool md-bs) {
+ /* The md already has necessary mempools. */
+ if (dm_table_get_type(t) == DM_TYPE_BIO_BASED) {
+ /*
+* Reload bioset because front_pad may have changed
+* because a different table was loaded.
+*/
+ bioset_free(md-bs);
+ md-bs = p-bs;
+ p-bs = NULL;
+ } else if (dm_table_get_type(t) == DM_TYPE_REQUEST_BASED) {
+ BUG_ON(!md-tio_pool);
+ /*
+* No need to reload in case of request-based dm
+* because of fixed size front_pad.
+* Note for future: if you are to reload bioset,
+* prep-ed requests in queue may have reference
+* to bio from the old bioset.
+* So you must walk through the queue to unprep.
+*/
+ }
goto out;
}
--
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
