Re: 4.15.14 crash with iscsi target and dvd

2018-04-06 Thread Bart Van Assche 
On Fri, 2018-04-06 at 21:03 -0400, Wakko Warner wrote:
> Bart Van Assche wrote:
> > On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote:
> > > I know now why scsi_print_command isn't doing anything.  cmd->cmnd is 
> > > null.
> > > I added a dev_printk in scsi_print_command where the 2 if statements 
> > > return.
> > > Logs:
> > > [  29.866415] sr 3:0:0:0: cmd->cmnd is NULL
> > 
> > That's something that should never happen. As one can see in
> > scsi_setup_scsi_cmnd() and scsi_setup_fs_cmnd() both functions initialize
> > that pointer. Since I have not yet been able to reproduce myself what you
> > reported, would it be possible for you to bisect this issue? You will need
> > to follow something like the following procedure (see also
> > https://git-scm.com/docs/git-bisect):
> > 
> > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > git bisect start
> > git bisect bad v4.10
> > git bisect good v4.9
> > 
> > and then build the kernel, install it, boot the kernel and test it.
> > Depending on the result, run either git bisect bad or git bisect good and
> > keep going until git bisect comes to a conclusion. This can take an hour or
> > more.
> 
> I have 1 question.  Should make clean be done between tests?  My box
> compiles the whole kernel in 2 minutes.

If you trust that the build system will figure out all dependencies then
running make clean is not necessary. Personally I always run make clean
during a bisect before rebuilding the kernel because if a header file has
changed in e.g. the block layer a huge number of files has to be rebuilt
anyway.

Bart.

Re: 4.15.14 crash with iscsi target and dvd

2018-04-06 Thread Wakko Warner 
Bart Van Assche wrote:
> On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote:
> > I know now why scsi_print_command isn't doing anything.  cmd->cmnd is null.
> > I added a dev_printk in scsi_print_command where the 2 if statements return.
> > Logs:
> > [  29.866415] sr 3:0:0:0: cmd->cmnd is NULL
> 
> That's something that should never happen. As one can see in
> scsi_setup_scsi_cmnd() and scsi_setup_fs_cmnd() both functions initialize
> that pointer. Since I have not yet been able to reproduce myself what you
> reported, would it be possible for you to bisect this issue? You will need
> to follow something like the following procedure (see also
> https://git-scm.com/docs/git-bisect):
> 
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git bisect start
> git bisect bad v4.10
> git bisect good v4.9
> 
> and then build the kernel, install it, boot the kernel and test it.
> Depending on the result, run either git bisect bad or git bisect good and
> keep going until git bisect comes to a conclusion. This can take an hour or
> more.

I have 1 question.  Should make clean be done between tests?  My box
compiles the whole kernel in 2 minutes.

-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

Re: [PATCH v6] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-06 Thread Finn Thain 
On Sat, 7 Apr 2018, Michael Schmitz wrote:

> Changes since v5:
> 
> Christoph Hellwig:
> 
> - fix comment style
> - drop initialization to zero in driver data init
> - fix alignment in struct declarations
> - drop braces around asm macros
> - change board_base type to void __iomem *
> - drop unneeded void __iomem * cast from ZTWO_VADDR() use
> - add comment to explain why ZTWO_VADDR() use is safe
> - move board specific functions to per-board esp_ops
> 

The sparse warnings have changed to this:

  CHECK   /home/fthain/src/kernel.org/linux/drivers/scsi/zorro_esp.c
drivers/scsi/zorro_esp.c:274:14: warning: cast removes address space of 
expression
drivers/scsi/zorro_esp.c:712:14: warning: cast removes address space of 
expression

Why not just call writel() and get rid of the 't' temporary pointer?

--

Re: 4.15.14 crash with iscsi target and dvd

2018-04-06 Thread Wakko Warner 
Bart Van Assche wrote:
> On Thu, 2018-04-05 at 22:06 -0400, Wakko Warner wrote:
> > I know now why scsi_print_command isn't doing anything.  cmd->cmnd is null.
> > I added a dev_printk in scsi_print_command where the 2 if statements return.
> > Logs:
> > [  29.866415] sr 3:0:0:0: cmd->cmnd is NULL
> 
> That's something that should never happen. As one can see in
> scsi_setup_scsi_cmnd() and scsi_setup_fs_cmnd() both functions initialize
> that pointer. Since I have not yet been able to reproduce myself what you
> reported, would it be possible for you to bisect this issue? You will need
> to follow something like the following procedure (see also
> https://git-scm.com/docs/git-bisect):

I don't know how relevent it is, but this machine boots nfs and exports it's
dvd drives over iscsi with the target modules.  My scsi_target.lio is at the
end.  I removed the iqn name.  The options are default except for a few. 
Non default options I tabbed over.
eth0 is the nfs/localnet nic and eth1 is the
nic that iscsi goes over.
eth0 is onboard pci 8086:1502 (subsystem 1028:05d3)
eth1 is pci 8086:107d (subsystem 8086:1084)
Both use the e1000e driver

The initiator is running 4.4.107.
When running on the initiator, /dev/sr1 is the target /dev/sr0.  Therefor
cat /dev/sr1 > /dev/null seems to work.
mount /dev/sr1 /cdrom works
find /cdrom -type f | xargs cat > /dev/null immediately crashes the target.
Burning to /dev/sr1 seems to work.

I have another nic that uses igb instead, I'll see if that makes a
difference.

> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git bisect start
> git bisect bad v4.10
> git bisect good v4.9
> 
> and then build the kernel, install it, boot the kernel and test it.
> Depending on the result, run either git bisect bad or git bisect good and
> keep going until git bisect comes to a conclusion. This can take an hour or
> more.

I'll try this.

Here's my scsi_target.lio:
storage pscsi {
disk dvd0 {
path /dev/sr0 
attribute {
emulate_3pc yes 
emulate_caw yes 
emulate_dpo no 
emulate_fua_read no 
emulate_model_alias no 
emulate_rest_reord no 
emulate_tas yes 
emulate_tpu no 
emulate_tpws no 
emulate_ua_intlck_ctrl no 
emulate_write_cache no 
enforce_pr_isids yes 
fabric_max_sectors 8192 
is_nonrot yes 
max_unmap_block_desc_count 0 
max_unmap_lba_count 0 
max_write_same_len 65535 
queue_depth 128 
unmap_granularity 0 
unmap_granularity_alignment 0 
}
}
disk dvd1 {
path /dev/sr1 
attribute {
emulate_3pc yes 
emulate_caw yes 
emulate_dpo no 
emulate_fua_read no 
emulate_model_alias no 
emulate_rest_reord no 
emulate_tas yes 
emulate_tpu no 
emulate_tpws no 
emulate_ua_intlck_ctrl no 
emulate_write_cache no 
enforce_pr_isids yes 
fabric_max_sectors 8192 
is_nonrot yes 
max_unmap_block_desc_count 0 
max_unmap_lba_count 0 
max_write_same_len 65535 
queue_depth 128 
unmap_granularity 0 
unmap_granularity_alignment 0 
}
}
disk dvd2 {
path /dev/sr2 
attribute {
emulate_3pc yes 
emulate_caw yes 
emulate_dpo no 
emulate_fua_read no 
emulate_model_alias no 
emulate_rest_reord no 
emulate_tas yes 
emulate_tpu no 
emulate_tpws no 
emulate_ua_intlck_ctrl no 
emulate_write_cache no 
enforce_pr_isids yes 
fabric_max_sectors 8192 
is_nonrot yes 
max_unmap_block_desc_count 0 
max_unmap_lba_count 0 
max_write_same_len 65535 
queue_depth 128 
unmap_granularity 0 
unmap_granularity_alignment 0 
}
}
}
fabric iscsi {
discovery_auth {
enable no 
mutual_password "" 
mutual_userid "" 
password "" 
userid "" 
}
target iqn.:dvd tpgt 1 {
enable yes 
attribute {
authentication no 
cache_dynamic_acls yes 
default_cmdsn_depth 64 
default_erl 0 
demo_mode_discovery yes 
demo_mode_write_protect no 
fabric_prot_type 0 
generate_node_acls yes 
login_timeout 15 
netif_timeout 2 
prod_mode_write_protect no 
t10_pi 0 
tpg_enabled_sendtargets 1 
}
auth {
password "" 
password_mutual "" 
userid "" 
userid_mutual "" 
}
parameter {
AuthMethod "CHAP,None" 
DataDigest "CRC32C,None" 
DataPDUInOrder yes 
DataSequenceInOrder yes 
DefaultTime2Retain 20 
DefaultTime2Wait 2 
ErrorRecoveryLevel no 
FirstBurstLength 65536 
HeaderDigest "CRC32C,None" 
IFMarkInt Reject 
IFMarker no 
ImmediateData yes 
InitialR2T yes 
MaxBurstLength 262144 
MaxConnections 1 
MaxOutstandingR2T 1 
MaxRecvDataSegmentLength 8192 
MaxXmitDataSegmentLength 262144 
OFMarkInt Reject 
OFMarker no 
TargetAlias "LIO Target" 
}
lun 0 backend pscsi:dvd0 
lun 1 backend pscsi:dvd1 
lun 2 backend pscsi:dvd2 
portal 0.0.0.0:3260 
}
}


-- 
 Microsoft has beaten Volkswagen's world record.  Volkswagen only created 22
 million bugs.

[PATCH v6] scsi: new zorro_esp.c for Amiga Zorro NCR53C9x boards

2018-04-06 Thread Michael Schmitz 
New combined SCSI driver for all ESP based Zorro SCSI boards for
m68k Amiga.

Code largely based on board specific parts of the old drivers (blz1230.c,
blz2060.c, cyberstorm.c, cyberstormII.c, fastlane.c which were removed
after the 2.6 kernel series for lack of maintenance) with contributions
by Tuomas Vainikka (TCQ bug tests and workaround) and Finn Thain (TCQ
bugfix by use of PIO in extended message in transfer).

New Kconfig option and Makefile entries for new Amiga Zorro ESP SCSI
driver included in this patch.

Use DMA transfers wherever possible, with board-specific DMA set-up
functions copied from the old driver code. Three byte reselection messages
do appear to cause DMA timeouts. So wire up a PIO transfer routine for
these instead. esp_reselect_with_tag explicitly sets esp->cmd_block_dma as
target address for the message bytes but PIO requires a virtual address.
Substiute kernel virtual address esp->cmd_block in PIO transfer call if
DMA address is esp->cmd_block_dma and phase is message in.

PIO code taken from mac_esp.c where the reselection timeout issue was
debugged and fixed first, with minor macro and function rename.

Signed-off-by: Michael Schmitz 
Reviewed-by: Finn Thain 

---

Changes since v1:

Fixed issues raised by Finn Thain in initial code review:

- use KBUILD_MODNAME for driver name string.
- use pr_fmt() for pr_* format prefix.
- clean up DMA error reporting: clear error flag before each DMA
  operation, set error flag on PIO error. Don't test phase in dma_err hook.
- change confusing comment about semantics of read flag, add comments
  indicating DMA direction to DMA setup hooks.
- drop spurious braces around switch clauses.
- lift cfreq setting out of ID switch clauses.
- fix indentation.
- fix error codes on probe fail.
- drop check for board ID when unmapping DMA regs in error handling:
  the ioaddr > 0xff test already catches all cases where the DMA
  registers were ioremapped.
- dynamically alloc zorro_private_data.
- fix use of driver_data field (don't mix host and zorro_esp_priv
  pointers). Note: require esp pointer in zorro_esp_priv to find host
  pointer!
- back out phase bits changes to pio_cmd !write branch introduced
  to cope with ESP SELAS command. We don't use that code so keep
  it in sync with Finn's version.
- use esp_ops.dma_length_limit() to limit transfer size. After review
  of old driver code, use 0xff max transfer size throughout.

Fixed issues raised by Geert Uytterhoven:

- dynamically alloc zorro_private_data, store as device drvdata.
- store ctrl_data for CyberStormI in driver private data.
- use dma_sync_single_for_device() instead of cache_push/clear.
- handle case of duplicate board identity - check whether board is
  Zorro III or Zorro II (use ROM resource data for this). Also fix
  up DMA mask for Zorro II boards to 32 bits (these are really CPU
  expansion slot boards).
- remove zorro3 field from driver_data struct (now in private data).
- add braces around ambiguous if - else construct.
- use named structs instead of array for board config data.
- use scsi_option driver data flag for boards with optional ESP.

Other improvements and bugfixes

- fix Zorro device table error (duplicate ID used, also raised
  by Kars de Jong).
- error code fixup in error handling path.
- add separate DMA setup for Blizzard 1230 II board.
- add support for Cyberstorm II board.
- add register structs and DMA setup for Zorro III Fastlane board,
  following logic from old fastlane.c driver. Wire up Fastlane DMA
  and interrupt status routines, map the necessary low 24 bit board
  address space used for DMA target address setting. Clean up DMA
  register space ioremap() branch for Zorro III boards (currently
  Fastlane only) to end confusion about what to do in error recovery.
- use esp_ops.fastlane_esp_dma_invalidate() on Fastlane (and skip
  fastlane_esp_reset_dma() in DMA setup).
- credit Tuomas Vainikka for contributing Blizzard 1230 code (and
  testing).
- clarify comment about unsupported Oktagon SCSI board.
- remove unused const definitions carried over from old driver.

Changes since v2:

- add SPDX-License-Identifier.
- remove unused ratelimit.h.
- drop phys_to_virt() in PIO transfer routine, after ensuring PIO is only
  used for message in transfers to esp->command_block. This obviates any
  need for finding the virtual address corresponding to a DMA handle.
- drop BUG_ON(!(cmd & ESP_CMD_DMA)) assertion in DMA setup. Short of changes
  to the core ESP driver, this can never trigger.
- make ioremap() of DMA address range conditional on zep->zorro3 and use
  that same condition to unmap in error handling and driver exit.
  Omit board ID test as we only support a single Zorro III board, and add
  comment on what to do when adding support for more boards.
- free driver private data in driver exit.
- various whitespace related cleanup.

Changes since v3:

Finn  Thain:
- substitute esp->command_block for

[PATCH] scsi: scsi_dh: replace too broad "TP9" string with the exact models

2018-04-06 Thread Xose Vazquez Perez 
SGI/TP9100 is not a RDAC array:
^^^
https://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=libmultipath/hwtable.c;h=88b4700beb1d8940008020fbe4c3cd97d62f4a56;hb=HEAD#l235

This reverts partially the 35204772ea034b380bc9d8942699dc03898e5c13 commit

Cc: NetApp RDAC team 
Cc: Hannes Reinecke 
Cc: James E.J. Bottomley 
Cc: Martin K. Petersen 
Cc: SCSI ML 
Cc: DM ML 
Signed-off-by: Xose Vazquez Perez 
---
 drivers/scsi/scsi_dh.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/scsi_dh.c b/drivers/scsi/scsi_dh.c
index b88b5dbbc444..d2fc6521f8ad 100644
--- a/drivers/scsi/scsi_dh.c
+++ b/drivers/scsi/scsi_dh.c
@@ -58,7 +58,10 @@ static const struct scsi_dh_blist scsi_dh_blist[] = {
{"IBM", "3526", "rdac", },
{"IBM", "3542", "rdac", },
{"IBM", "3552", "rdac", },
-   {"SGI", "TP9",  "rdac", },
+   {"SGI", "TP9300",   "rdac"},
+   {"SGI", "TP9400",   "rdac"},
+   {"SGI", "TP9500",   "rdac"},
+   {"SGI", "TP9700",   "rdac"},
{"SGI", "IS",   "rdac", },
{"STK", "OPENstorage",  "rdac", },
{"STK", "FLEXLINE 380", "rdac", },
-- 
2.14.3

[PATCH resend] scsi: devinfo: delete duplicate "Generic"/"USB Storage-SMC" device

2018-04-06 Thread Xose Vazquez Perez 
Revision is irrelevant, it's unused by the scsi infrastructure.

$ egrep "Generic.*Storage-SMC" /proc/scsi/device_info
'Generic' 'USB Storage-SMC' 0x402
'Generic' 'USB Storage-SMC' 0x402

Cc: Hannes Reinecke 
Cc: Martin K. Petersen 
Cc: James E.J. Bottomley 
Cc: SCSI ML 
Signed-off-by: Xose Vazquez Perez 
---
 drivers/scsi/scsi_devinfo.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index f3b117246d47..384bed37b13b 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -168,8 +168,7 @@ static struct {
{"easyRAID", "F8", NULL, BLIST_NOREPORTLUN},
{"FSC", "CentricStor", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"Generic", "USB SD Reader", "1.00", BLIST_FORCELUN | BLIST_INQUIRY_36},
-   {"Generic", "USB Storage-SMC", "0180", BLIST_FORCELUN | 
BLIST_INQUIRY_36},
-   {"Generic", "USB Storage-SMC", "0207", BLIST_FORCELUN | 
BLIST_INQUIRY_36},
+   {"Generic", "USB Storage-SMC", NULL, BLIST_FORCELUN | 
BLIST_INQUIRY_36}, /* FW: 0180 and 0207 */
{"HITACHI", "DF400", "*", BLIST_REPORTLUN2},
{"HITACHI", "DF500", "*", BLIST_REPORTLUN2},
{"HITACHI", "DISK-SUBSYSTEM", "*", BLIST_REPORTLUN2},
-- 
2.14.3

【全球最大轨道高铁展】关于参加9月“2018德国柏林国际轨道交通技术展”（InnoTrans 2018）的通知 ds <上P3-C50>

2018-04-06 Thread keywb2n 
关于参加“2018德国柏林国际轨道交通技术展览会”（InnoTrans 2018）的通知
　　
ds 各轨道交通与高速铁路有关单位：
　
　　
为推动我国轨道交通行业与德国及欧洲地区商界的技术交流，促进我国轨道交通企业与世界各国轨道交通生产商和采购商的合作与发展，进一步开拓、巩固欧洲国际市场，我会将组织相关企业参加2018年9月在德国柏林举办的国际轨道交通技术展览会，现将有关事项通知如下：
　
一、展会简介
　
　　
“德国柏林国际轨道交通技术展览会（InnoTrans）”创办于1996年，每两年一届，2018年度为第十二届，十余年来发展迅速，目前是“全世界轨道交通行业规模最大，发展最快，专业观众最多的国际展览盛会”。展会分为“轨道技术展区”、“基础设施展区”、“隧道建设展区”、“公共交通展区”和“车辆内饰展区”等五大展区。由德国柏林国际展览有限公司（Messe
 Berlin GmbH）主办，得到了欧洲铁路联合会、德国铁路协会等机构的大力支持和协助。中国总展团的组办方为映德国际会展集团（YOND 
EXPO）中国代表处，在北京、上海等地设有分支机构，负责该展会在中国的推广和招商工作，以及中国境内企业参展参观的组织管理事宜，InnoTrans德国柏林轨道展中国总展团报名热线：4000-680-860转、8144。主办方将室内展区和室外展区有机结合，在展会同期举办一系列论坛和峰会，该展会已成为各国轨道交通行业人士进行产品展示、技术水平和经贸合作的最佳平台。
　　
2016年展会总面积超过20平方米，吸引了来自60个国家和地区的2995家参展商和来自119个国家和地区的137391余名专业观众，其中国际参展商1465家；展会展出的展品中，铁路设备和技术占52.5%，基础设施建设占23.5%，公共交通工具占13.5%，车辆内饰占6.5%，隧道施工占4%。德国、法国、美国、日本、英国、巴西、澳大利亚、意大利、土耳其等国家组织了庞大的参观采购团到会参观采购。
　　轨道交通技术展区（railtechnology）是最大的展区，几乎环绕了整个展览馆的中庭花园；第二大展区是交通基础建设展区（railway 
infrastructure）,其参展商数量从上届的470家增加到654家；隧道建设展区（tunnelconstruction）是2006年开始增加的特色展区，随着建设技术的逐渐成熟也越来越引起关注；公共交通展区（pubilce
 
transport）的扩大则充分反映了世界各国城市轨道交通业对通讯需求的重视，展区面积在逐年快速增加，产品主要集中于轨道交通通讯系统、公共交通管理系统、旅客信息系统等领域；车辆内饰展区（interior）的面积比上届增加了51%，达到了近25000平方米。
　　展会期间还举办了各种与轨道交通相关的高层研讨会和专业活动，其内容包括铁道对话论坛、欧亚轨道交通高峰会、铁路技术设施建设特别会议等。
　　
中国共有169家企业组团参与了本届展会，展示了我国在轨道交通车辆、零部件与配件、车辆内饰、电子、通信通讯等方面的产品和技术，受到了与会者的高度关注，取得了很好的效果。
　　中国国际贸促会、映德国际会展集团（YOND 
EXPO）中国代表处已近十年组织中国企业参与该展会，为中国建筑、中国中铁、中国盾建、中国铁通、中国重汽、中国南车、中国北车、中国通号、徐工集团、中船重工、西南铝、三一重工、北京城建集团、上海城建集团、杭叉集团、湘潭电机、无锡万里、鼎汉技术、北方交通重工集团、交通大学、工业大学等众多行业巨头和业界机构提供了优质高效的境外展贸服务。
　
二、展会信息：
◆ 展会名称： 2018第十二届德国柏林国际轨道交通技术展览会（InnoTrans 2018）
◆ 展会时间： 2018年09月18—21日
◆ 展会地点： 德国柏林国际展览中心 （Germany Berlin International Exhibition Center）
◆ 展会周期： 两年一届 （2018年为第12届）
◆ 报名截止： 2018年04月18日
◆ 在线客服： 邮箱/QQ/ 82775...@qq.com； 微信/ CanZhanXiaoXi； 微博/ 
http://weibo.com/guidaojiaotong  
◆ 咨询电话： 4000-680-860（转、8144）； 139-1031-8144； 010—8699-7155、6923-6944；
◆ 支持单位： 德国铁路运输协会、 美国铁路保养工程协会、 欧洲铁路轨道工程承包商会、 欧洲铁路联合会、 欧洲铁路基础设施管理公司共同体、  
欧洲轨道基础设施管理者协会
◆ 主办单位： 德国柏林国际展览有限公司
◆ 组办单位： 中国国际贸促会、映德会展有限公司
◆ 部分展商： 中国铁路总公司、 中国建筑工程总公司、 中国中铁股份有限公司、 中国铁建股份有限公司、 中国中铁电气化局集团公司、 
中国铁建电气化局集团有限公司、 中铁物资集团有限公司、 中国铁路通信信号股份有限公司、 中国中车股份有限公司、 中国建筑股份有限公司、 
中国重型汽车集团有限公司、 中国铁路通信信号股份有限公司、 中国船舶重工集团公司、 徐州工程机械集团有限公司、 华为技术有限公司、 
西南铝业（集团）有限责任公司、 三一集团有限公司、 北京城建集团有限责任公司、 上海城建（集团）公司、 杭叉集团股份有限公司、 北京鼎汉技术股份有限公司、 
北方重工集团有限公司、 南京康尼机电股份有限公司、 广州新科佳都科技有限公司、 一机集团包头北方创业有限责任公司、 晋西车轴股份有限公司、 
晋亿实业股份有限公司、 河南辉煌科技股份有限公司、 深圳达实智能股份有限公司、 浙江众合科技股份有限公司、 株洲时代新材料科技股份有限公司、 
航空工业西安飞机工业（集团）有限责任公司、 交控科技股份有限公司、 无锡市万里实业发展有限公司••
　
三、展品范围：
　
◆ 铁道技术：
　　
轨道交通及铁路机车车辆设备及零部件和机电设备；车辆段设备；供电系统；通信、信号系统；自动售检票系统；升降系统；火灾报警系统；通风、空调与采暖系统；环境与设备监控系统；综合监控系统；清分系统；屏蔽门安全系统等；轨道交通及铁路建设施工材料、装备、安全、节能、环保技术与维护等；
◆ 基础设施：
　　铁道设施建设，车站及站场设备，轨道线路铺设、养护、维修装备与技术；铁道土木工程、桥梁道路、给排水、环境工程、风景园林、公用工程等建设；
◆ 隧道建设：
　　
隧道施工建设机械设备、配件、材料与技术，工程机械，安全装置及设备等；地下交通检测、勘探技术、建设材料与技术设备等；地下线路、信号、桥梁、隧道、供电网、站房等施工机械及配套设备；
◆ 公共交通：
 　　
智能交通管理系统、道路收费系统设备、智能交通产品及安防监控设备；视频监控设备、交通信息采集设备、交通控制设备、道路收费系统设备；地铁、汽车、巴士等轨道交通运输工具；
◆ 内部装饰：
　　铁轨车内部设计、更新、装饰服务，门、窗帘，隔断，桌椅，行李架，扶手杆，替换零件，锁柜，安全带，涂料，手推车，洗手间，厨房设备等。
　
四、展出形式：
　　以实物为主，辅以图片、模型、音像和样本等。
　　参展单位可租用标准展位展出，也可根据企业的要求对展位进行特殊装修。
　
五、联络方式：
　
　　组办单位：中国国际贸促会、 映德会展有限公司
　　参展顾问： 王先生、 杨先生、 孙小姐、 吴小姐
　　参展热线： 139-1031-8144、 131-2662-5206；  010— 8699- 7155、 6923- 6944.
　　全国统一客服热线： 4000- 580- 850.（分机: / 分机:）
　　全国统一报名专线： 4000- 680- 860.（兼传真）
　　在线客服： QQ/ 82775507；  微信/ CanZhanXiaoXi（参展消息）； 
　　邮箱号码： q...@12809395.com、 jack--w...@ccpit.org
　　网络地址： http://weibo.com/guidaojiaotong 
　　办公地址： 中国北京市西城区三里河路46号

　　
　　
　　
　　
——
（百万群发系统|为您发送|如不希望再收到此行业资讯|请回复“TD+IT2018”至邮箱1055800...@qq.com）

Re: [PATCH] target: prefer dbroot of /etc/target over /var/target

2018-04-06 Thread kbuild test robot 
Hi Lee,

I love your patch! Yet something to improve:

[auto build test ERROR on target/for-next]
[also build test ERROR on v4.16 next-20180406]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lee-Duncan/target-prefer-dbroot-of-etc-target-over-var-target/20180406-234105
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git 
for-next
config: i386-randconfig-a0-201813 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/target/target_core_configfs.c: In function 'target_init_dbroot':
>> drivers/target/target_core_configfs.c:3222:39: error: 'DB_ROOT_PREFERRED' 
>> undeclared (first use in this function)
 snprintf(db_root_stage, DB_ROOT_LEN, DB_ROOT_PREFERRED);
  ^
   drivers/target/target_core_configfs.c:3222:39: note: each undeclared 
identifier is reported only once for each function it appears in

vim +/DB_ROOT_PREFERRED +3222 drivers/target/target_core_configfs.c

  3217  
  3218  static void target_init_dbroot(void)
  3219  {
  3220  struct file *fp;
  3221  
> 3222  snprintf(db_root_stage, DB_ROOT_LEN, DB_ROOT_PREFERRED);
  3223  fp = filp_open(db_root_stage, O_RDONLY, 0);
  3224  if (IS_ERR(fp)) {
  3225  pr_err("db_root: cannot open: %s\n", db_root_stage);
  3226  return;
  3227  }
  3228  if (!S_ISDIR(file_inode(fp)->i_mode)) {
  3229  filp_close(fp, NULL);
  3230  pr_err("db_root: not a valid directory: %s\n", 
db_root_stage);
  3231  return;
  3232  }
  3233  filp_close(fp, NULL);
  3234  
  3235  strncpy(db_root, db_root_stage, DB_ROOT_LEN);
  3236  pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
  3237  }
  3238  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCHv2] target: prefer dbroot of /etc/target over /var/target

2018-04-06 Thread Lee Duncan 
The target database root directory, dbroot, has
defaulted to /var/target for a while, but its
main client, targetcli-fb, has been moving it
to /etc/target for quite some time. With the
plethora of target drivers now appearing, it has
become more difficult to initialize this attribute
before use by any child drivers.

If the directory /etc/target exists, use that as
the DB root. Otherwise, fall back to using
/var/target.

The ability to override this dbroot attribute
still exists via sysfs.

Signed-off-by: Lee Duncan 
---
 drivers/target/target_core_configfs.c | 25 +
 drivers/target/target_core_internal.h |  1 +
 2 files changed, 26 insertions(+)

diff --git a/drivers/target/target_core_configfs.c 
b/drivers/target/target_core_configfs.c
index 3f4bf126eed0..5ccef7d597fa 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -155,6 +155,8 @@ static ssize_t target_core_item_dbroot_store(struct 
config_item *item,
 
mutex_unlock(_tf_lock);
 
+   pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
+
return read_bytes;
 }
 
@@ -3213,6 +3215,27 @@ void target_setup_backend_cits(struct target_backend *tb)
target_core_setup_dev_stat_cit(tb);
 }
 
+static void target_init_dbroot(void)
+{
+   struct file *fp;
+
+   snprintf(db_root_stage, DB_ROOT_LEN, DB_ROOT_PREFERRED);
+   fp = filp_open(db_root_stage, O_RDONLY, 0);
+   if (IS_ERR(fp)) {
+   pr_err("db_root: cannot open: %s\n", db_root_stage);
+   return;
+   }
+   if (!S_ISDIR(file_inode(fp)->i_mode)) {
+   filp_close(fp, NULL);
+   pr_err("db_root: not a valid directory: %s\n", db_root_stage);
+   return;
+   }
+   filp_close(fp, NULL);
+
+   strncpy(db_root, db_root_stage, DB_ROOT_LEN);
+   pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
+}
+
 static int __init target_core_init_configfs(void)
 {
struct configfs_subsystem *subsys = _core_fabrics;
@@ -3293,6 +3316,8 @@ static int __init target_core_init_configfs(void)
if (ret < 0)
goto out;
 
+   target_init_dbroot();
+
return 0;
 
 out:
diff --git a/drivers/target/target_core_internal.h 
b/drivers/target/target_core_internal.h
index 1d5afc3ae017..dead30b1d32c 100644
--- a/drivers/target/target_core_internal.h
+++ b/drivers/target/target_core_internal.h
@@ -166,6 +166,7 @@ extern struct se_portal_group xcopy_pt_tpg;
 /* target_core_configfs.c */
 #define DB_ROOT_LEN4096
 #defineDB_ROOT_DEFAULT "/var/target"
+#defineDB_ROOT_PREFERRED   "/etc/target"
 
 extern char db_root[];
 
-- 
2.13.6

Re: [PATCH] target: prefer dbroot of /etc/target over /var/target

2018-04-06 Thread Lee Duncan 
I will be re-sending this, as this version somehow missed
a change to an include file.

On 04/06/2018 08:37 AM, Lee Duncan wrote:
> The target database root directory, dbroot, has
> defaulted to /var/target for a while, but its
> main client, targetcli-fb, has been moving it
> to /etc/target for quite some time. With the
> plethora of target drivers now appearing, it has
> become more difficult to initialize this attribute
> before use by any child drivers.
> 
> If the directory /etc/target exists, use that as
> the DB root. Otherwise, fall back to using
> /var/target.
> 
> The ability to override this dbroot attribute
> still exists via sysfs.
> 
> Signed-off-by: Lee Duncan 
> ---
>  drivers/target/target_core_configfs.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/drivers/target/target_core_configfs.c 
> b/drivers/target/target_core_configfs.c
> index 3f4bf126eed0..5ccef7d597fa 100644
> --- a/drivers/target/target_core_configfs.c
> +++ b/drivers/target/target_core_configfs.c
> @@ -155,6 +155,8 @@ static ssize_t target_core_item_dbroot_store(struct 
> config_item *item,
>  
>   mutex_unlock(_tf_lock);
>  
> + pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
> +
>   return read_bytes;
>  }
>  
> @@ -3213,6 +3215,27 @@ void target_setup_backend_cits(struct target_backend 
> *tb)
>   target_core_setup_dev_stat_cit(tb);
>  }
>  
> +static void target_init_dbroot(void)
> +{
> + struct file *fp;
> +
> + snprintf(db_root_stage, DB_ROOT_LEN, DB_ROOT_PREFERRED);
> + fp = filp_open(db_root_stage, O_RDONLY, 0);
> + if (IS_ERR(fp)) {
> + pr_err("db_root: cannot open: %s\n", db_root_stage);
> + return;
> + }
> + if (!S_ISDIR(file_inode(fp)->i_mode)) {
> + filp_close(fp, NULL);
> + pr_err("db_root: not a valid directory: %s\n", db_root_stage);
> + return;
> + }
> + filp_close(fp, NULL);
> +
> + strncpy(db_root, db_root_stage, DB_ROOT_LEN);
> + pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
> +}
> +
>  static int __init target_core_init_configfs(void)
>  {
>   struct configfs_subsystem *subsys = _core_fabrics;
> @@ -3293,6 +3316,8 @@ static int __init target_core_init_configfs(void)
>   if (ret < 0)
>   goto out;
>  
> + target_init_dbroot();
> +
>   return 0;
>  
>  out:
> 

-- 
Lee Duncan
SUSE Labs

Re: Multi-Actuator SAS HDD First Look

2018-04-06 Thread Douglas Gilbert 

On 2018-04-06 02:42 AM, Christoph Hellwig wrote:

On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:

Ah. Far better.
What about delegating FORMAT UNIT to the control LUN, and not
implementing it for the individual disk LUNs?
That would make an even stronger case for having a control LUN;
with that there wouldn't be any problem with having to synchronize
across LUNs etc.


It sounds to me like NVMe might be a much better model for this drive
than SCSI, btw :)


So you found a document that outlines NVMe's architecture! Could you
share the url (no marketing BS, please)?


And a serious question ... How would you map NVMe's (in Linux)
subsystem number, controller device minor number, CNTLID field
(Identify ctl response) and namespace id onto the SCSI subsystem's
h:c:t:l ?

Doug Gilbert

Re: [PATCH] target: prefer dbroot of /etc/target over /var/target

2018-04-06 Thread kbuild test robot 
Hi Lee,

I love your patch! Yet something to improve:

[auto build test ERROR on target/for-next]
[also build test ERROR on v4.16 next-20180406]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Lee-Duncan/target-prefer-dbroot-of-etc-target-over-var-target/20180406-234105
base:   https://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git 
for-next
config: i386-randconfig-x016-201813 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/target/target_core_configfs.c: In function 'target_init_dbroot':
>> drivers/target/target_core_configfs.c:3222:39: error: 'DB_ROOT_PREFERRED' 
>> undeclared (first use in this function); did you mean 'DB_ROOT_DEFAULT'?
 snprintf(db_root_stage, DB_ROOT_LEN, DB_ROOT_PREFERRED);
  ^
  DB_ROOT_DEFAULT
   drivers/target/target_core_configfs.c:3222:39: note: each undeclared 
identifier is reported only once for each function it appears in

vim +3222 drivers/target/target_core_configfs.c

  3217  
  3218  static void target_init_dbroot(void)
  3219  {
  3220  struct file *fp;
  3221  
> 3222  snprintf(db_root_stage, DB_ROOT_LEN, DB_ROOT_PREFERRED);
  3223  fp = filp_open(db_root_stage, O_RDONLY, 0);
  3224  if (IS_ERR(fp)) {
  3225  pr_err("db_root: cannot open: %s\n", db_root_stage);
  3226  return;
  3227  }
  3228  if (!S_ISDIR(file_inode(fp)->i_mode)) {
  3229  filp_close(fp, NULL);
  3230  pr_err("db_root: not a valid directory: %s\n", 
db_root_stage);
  3231  return;
  3232  }
  3233  filp_close(fp, NULL);
  3234  
  3235  strncpy(db_root, db_root_stage, DB_ROOT_LEN);
  3236  pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
  3237  }
  3238  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] target: prefer dbroot of /etc/target over /var/target

2018-04-06 Thread Lee Duncan 
The target database root directory, dbroot, has
defaulted to /var/target for a while, but its
main client, targetcli-fb, has been moving it
to /etc/target for quite some time. With the
plethora of target drivers now appearing, it has
become more difficult to initialize this attribute
before use by any child drivers.

If the directory /etc/target exists, use that as
the DB root. Otherwise, fall back to using
/var/target.

The ability to override this dbroot attribute
still exists via sysfs.

Signed-off-by: Lee Duncan 
---
 drivers/target/target_core_configfs.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/target/target_core_configfs.c 
b/drivers/target/target_core_configfs.c
index 3f4bf126eed0..5ccef7d597fa 100644
--- a/drivers/target/target_core_configfs.c
+++ b/drivers/target/target_core_configfs.c
@@ -155,6 +155,8 @@ static ssize_t target_core_item_dbroot_store(struct 
config_item *item,
 
mutex_unlock(_tf_lock);
 
+   pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
+
return read_bytes;
 }
 
@@ -3213,6 +3215,27 @@ void target_setup_backend_cits(struct target_backend *tb)
target_core_setup_dev_stat_cit(tb);
 }
 
+static void target_init_dbroot(void)
+{
+   struct file *fp;
+
+   snprintf(db_root_stage, DB_ROOT_LEN, DB_ROOT_PREFERRED);
+   fp = filp_open(db_root_stage, O_RDONLY, 0);
+   if (IS_ERR(fp)) {
+   pr_err("db_root: cannot open: %s\n", db_root_stage);
+   return;
+   }
+   if (!S_ISDIR(file_inode(fp)->i_mode)) {
+   filp_close(fp, NULL);
+   pr_err("db_root: not a valid directory: %s\n", db_root_stage);
+   return;
+   }
+   filp_close(fp, NULL);
+
+   strncpy(db_root, db_root_stage, DB_ROOT_LEN);
+   pr_debug("Target_Core_ConfigFS: db_root set to %s\n", db_root);
+}
+
 static int __init target_core_init_configfs(void)
 {
struct configfs_subsystem *subsys = _core_fabrics;
@@ -3293,6 +3316,8 @@ static int __init target_core_init_configfs(void)
if (ret < 0)
goto out;
 
+   target_init_dbroot();
+
return 0;
 
 out:
-- 
2.13.6

Re: [PATCH] qla2xxx: correctly shift host byte

2018-04-06 Thread Bart Van Assche 
On Fri, 2018-04-06 at 09:52 +0200, Johannes Thumshirn wrote:
> The host byte has to be shifted by 16 not 6.
> 
> Signed-off-by: Johannes Thumshirn 
> ---
>  drivers/scsi/qla2xxx/qla_isr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index 89f93ebd819d..49d67e1d571f 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -2368,7 +2368,7 @@ qla25xx_process_bidir_status_iocb(scsi_qla_host_t *vha, 
> void *pkt,
>   bsg_job->reply_len = sizeof(struct fc_bsg_reply);
>   /* Always return DID_OK, bsg will send the vendor specific response
>* in this case only */
> - sp->done(sp, DID_OK << 6);
> + sp->done(sp, DID_OK << 16);
>  
>  }

Hello Johannes,

Had you noticed the following statements? I think the "<< 1" should be removed
from these statements.

$ git grep 'SAM_STAT.*<< 1'
drivers/scsi/qla2xxx/qla_isr.c: cmd->result |= SAM_STAT_CHECK_CONDITION 
<< 1;
drivers/scsi/qla2xxx/qla_isr.c: cmd->result |= SAM_STAT_CHECK_CONDITION 
<< 1;
drivers/scsi/qla2xxx/qla_isr.c: cmd->result |= SAM_STAT_CHECK_CONDITION 
<< 1;

Thanks,

Bart.

Re: [PATCH v1 03/15] mpt3sas: Add sanity checks for scsi tracker before accessing it.

2018-04-06 Thread Bart Van Assche 
On Thu, 2018-04-05 at 11:46 -0400, Chaitra P B wrote:
> Check scsi tracker 'st' for NULL and st->smid for zero (as driver uses smid
> starting from one) before accessing it.
> These checks are added as there are possibilities for getting valid
> scsi_cmd when driver calls scsi_host_find_tag() API when it loops using
> smid(i.e tag) from one to hba queue depth but still scsi tracker st for
> this corresponding scsi_cmd is not yet initialized.
> 
> For example below are such scenario:
> Sometimes it is possible that scsi_cmd might have created at SML but it
> might not be issued to the driver (or driver might have returned the
> command with Host busy status) as the host reset operation / TMs is in
> progress.In such case where the scsi_cmd is not yet processed by driver
> then the scsi tracker 'st' of that scsi_cmd & the fields of this 'st' will
> be uninitialized.
> And hence this patch add checks for 'st' in IOCTL path for TMs issued from
> applications and also in host reset path where driver flushes all the
> outstanding commands as part of host reset operation.

What is needed is an explanation about which mechanism serializes the
execution of scsih_qcmd() and mpt3sas_base_hard_reset_handler(), at least if
such a mechanism exists. The above text does not mention anything about such
a synchronization mechanism.
 
>   scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid);
> - if (!scmd)
> + if (scmd == NULL || scmd->device == NULL ||
> + scmd->device->hostdata == NULL)

As Christoph explained before, scmd->device is never NULL. Additionally, the
scmd->device->hostdata check looks very suspicious. That check should either
be left out or the race that causes a SCSI device to be removed concurrently
with this function should be fixed.

If you are unable to motivate why this patch is correct, please repost this
series without this patch.

Thanks,

Bart.

Re: [PATCH] qla2xxx: correctly shift host byte

2018-04-06 Thread Bart Van Assche 
On Fri, 2018-04-06 at 09:52 +0200, Johannes Thumshirn wrote:
> The host byte has to be shifted by 16 not 6.
> 
> Signed-off-by: Johannes Thumshirn 
> ---
>  drivers/scsi/qla2xxx/qla_isr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
> index 89f93ebd819d..49d67e1d571f 100644
> --- a/drivers/scsi/qla2xxx/qla_isr.c
> +++ b/drivers/scsi/qla2xxx/qla_isr.c
> @@ -2368,7 +2368,7 @@ qla25xx_process_bidir_status_iocb(scsi_qla_host_t *vha, 
> void *pkt,
>   bsg_job->reply_len = sizeof(struct fc_bsg_reply);
>   /* Always return DID_OK, bsg will send the vendor specific response
>* in this case only */
> - sp->done(sp, DID_OK << 6);
> + sp->done(sp, DID_OK << 16);
>  
>  }

Please mention in the description of this patch that this patch does not
change any functionality because DID_OK == 0. Anyway:

Reviewed-by: Bart Van Assche

Re: [PATCH v3 0/3] Report all request failures again to user space

2018-04-06 Thread Bart Van Assche 
On Fri, 2018-04-06 at 09:45 +0200, Johannes Thumshirn wrote:
> On 05/04/18 19:49, Martin K. Petersen wrote:
> > Longer term I'd really like to see the command result integer
> > host/driver/msg/status stuff cleaned up. It's super arcane and the
> > associated naming schemes make it a very error-prone interface.
> > 
> 
> I did start a series [1] for this but than got distracted by more urgent
> things. I can pick it up again I think.
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=iscsi_DID_REQUEUE

Hello Johannes,

Since modifying how SCSI results are communicated from SCSI LLDs to the SCSI
core requires to touch all SCSI LLDs, please consider to include the following
changes in your patch series:
- Remove the deprecated SCSI status codes (GOOD, CHECK_CONDITION, etc.) and
  use the SAM_STAT_* symbolic names instead.
- Ensure that assigning an int to scsi_cmnd.result triggers a compiler error.
  There is code in the Linux kernel that mixes traditional error codes (-EIO)
  with the SCSI result codes (DID_ERROR << 16). I think most of that code is
  buggy and that it should be fixed. Changing the type of scsi_cmnd.result is
  one way to find such code. How about something like the following (untested)
  patch?

diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index cb85eddb47ea..27f1c347f0ea 100644
--- a/include/scsi/scsi.h
+++ b/include/scsi/scsi.h
@@ -18,6 +18,27 @@ enum scsi_timeouts {
SCSI_DEFAULT_EH_TIMEOUT = 10 * HZ,
 };
 
+/*
+ * Note: .result is signed because SCSI LLDs store a SCSI result in
+ * .result while the bsg driver stores a negative error code in .result. 
+ */
+typedef union {
+   s32 result;
+   struct {
+#if defined(__BIG_ENDIAN)
+   u8  driver_byte;
+   u8  host_byte;
+   u8  msg_byte;
+   u8  status_byte;
+#elif defined(__LITTLE_ENDIAN)
+   u8  status_byte;
+   u8  msg_byte;
+   u8  host_byte;
+   u8  driver_byte;
+#endif
+   };
+} scsi_result;
+
 /*
  * DIX-capable adapters effectively support infinite chaining for the
  * protection information scatterlist
@@ -38,8 +59,10 @@ enum scsi_timeouts {
  * This returns true for known good conditions that may be treated as
  * command completed normally
  */
-static inline int scsi_status_is_good(int status)
+static inline int scsi_status_is_good(scsi_result result)
 {
+   u8 status = result.status_byte;
+
/*
 * FIXME: bit0 is listed as reserved in SCSI-2, but is
 * significant in SCSI-3.  For now, we follow the SCSI-2
@@ -205,10 +228,10 @@ static inline int scsi_is_wlun(u64 lun)
  *  host_byte   = set by low-level driver to indicate status.
  *  driver_byte = set by mid-level.
  */
-#define status_byte(result) (((result) >> 1) & 0x7f)
-#define msg_byte(result)(((result) >> 8) & 0xff)
-#define host_byte(result)   (((result) >> 16) & 0xff)
-#define driver_byte(result) (((result) >> 24) & 0xff)
+#define status_byte(result) ((result).status_byte >> 1)
+#define msg_byte(result)((result).msg_byte)
+#define host_byte(result)   ((result).host_byte)
+#define driver_byte(result) ((result).driver_byte)
 
 #define sense_class(sense)  (((sense) >> 4) & 0x7)
 #define sense_error(sense)  ((sense) & 0xf)
diff --git a/include/scsi/scsi_cmnd.h b/include/scsi/scsi_cmnd.h
index 2280b2351739..cbc5df948dd3 100644
--- a/include/scsi/scsi_cmnd.h
+++ b/include/scsi/scsi_cmnd.h
@@ -144,7 +144,7 @@ struct scsi_cmnd {
 * obtained by scsi_malloc is guaranteed
 * to be at an address < 16Mb). */
 
-   int result; /* Status code from lower level driver */
+   scsi_result result; /* Status code from lower level driver */
int flags;  /* Command flags */
 
unsigned char tag;  /* SCSI-II queued command tag */

Bart.

Re: [PATCH 1/1] target:separate tx/rx cmd_puds

2018-04-06 Thread David Disseldorp 
On Thu, 5 Apr 2018 13:12:12 +0200, David Disseldorp wrote:

> > -CONFIGFS_ATTR_RO(target_stat_tgt_port_, in_cmds);
> > +CONFIGFS_ATTR_RO(target_stat_tgt_port_, tx_cmds);
> > +CONFIGFS_ATTR_RO(target_stat_tgt_port_, rx_cmds);  
> 
> I don't think the in_cmds metric should be deleted here. It could be
> calculated on the fly via tx_cmds + rx_cmds + nodata_cmds.

@Zhang Zhuoyu: How about something like the following?
https://git.samba.org/?p=ddiss/linux.git;a=commitdiff;h=73723ccf433424721830797d70cfb88d4596e0fc

...this keeps the in_cmds metric, and renames tx/rx_cmds read/write_cmds
respectively. read/write_cmds is still a bit ambiguous, as it refers to
the command data direction rather than SCSI READ/WRITE CDBs, but IMO
it's clearer, and more consistent with the read/write_mbytes metrics.

Cheers, David

[Bug 101201] hpsa hang when creating ext4 FS

2018-04-06 Thread bugzilla-daemon 
https://bugzilla.kernel.org/show_bug.cgi?id=101201

Hebe (skycitylove1...@gmail.com) changed:

   What|Removed |Added

 CC||skycitylove1...@gmail.com

--- Comment #1 from Hebe (skycitylove1...@gmail.com) ---
see a similar bug with kernel 4.14 on ProLiant DL120 G7 and ProLiant DL380 G6.
The installation hang all the time with loop: module loaded
I see "seq 1481 '/devices/pci:00/:00:01.0/:04:00.0' is taking a
long time" in the log,and that is a hpsa disk. 
Actually,the installer will hang there after you run "modprobe hpsa".

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[PATCH 2/3] megaraid_sas: Increase timeout by 1 sec for non-RAID fastpath IOs

2018-04-06 Thread Shivasharan S 
Problem description:
Hardware could timeout Fastpath IOs one second earlier than the timeout
provided by the host.

For non-RAID devices, driver provides timeout value based on OS provided
timeout value.
Under certain scenarios, if the OS provides a timeout value of 1 second,
due to above behavior hardware will timeout immediately.

Fix:
Increase timeout value for non-RAID fastpath IOs by 1second.

Signed-off-by: Shivasharan S 
---
 drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 57da0acae986..c2ad37d483a2 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -2998,6 +2998,9 @@ megasas_build_syspd_fusion(struct megasas_instance 
*instance,
pRAID_Context->timeout_value = cpu_to_le16(os_timeout_value);
pRAID_Context->virtual_disk_tgt_id = cpu_to_le16(device_id);
} else {
+   if (os_timeout_value)
+   os_timeout_value++;
+
/* system pd Fast Path */
io_request->Function = MPI2_FUNCTION_SCSI_IO_REQUEST;
timeout_limit = (scmd->device->type == TYPE_DISK) ?
-- 
2.16.1

[PATCH 1/3] megaraid_sas: Use zeroing memory allocator than allocator/memset

2018-04-06 Thread Shivasharan S 
From: Himanshu Jha 

Use pci_zalloc_consistent for allocating zeroed
memory and remove unnecessary memset function.

Done using Coccinelle.
Generated by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci

Suggested-by: Luis R. Rodriguez 
Signed-off-by: Himanshu Jha 
Signed-off-by: Shivasharan S 
---
 drivers/scsi/megaraid/megaraid_sas_base.c   | 25 ++---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  5 ++---
 2 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index 905ea36da646..5b48cd6c3005 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -2224,9 +2224,9 @@ static int megasas_get_ld_vf_affiliation_111(struct 
megasas_instance *instance,
   sizeof(struct MR_LD_VF_AFFILIATION_111));
else {
new_affiliation_111 =
-   pci_alloc_consistent(instance->pdev,
-sizeof(struct 
MR_LD_VF_AFFILIATION_111),
-_affiliation_111_h);
+   pci_zalloc_consistent(instance->pdev,
+ sizeof(struct 
MR_LD_VF_AFFILIATION_111),
+ _affiliation_111_h);
if (!new_affiliation_111) {
dev_printk(KERN_DEBUG, >pdev->dev, "SR-IOV: 
Couldn't allocate "
   "memory for new affiliation for scsi%d\n",
@@ -2234,8 +2234,6 @@ static int megasas_get_ld_vf_affiliation_111(struct 
megasas_instance *instance,
megasas_return_cmd(instance, cmd);
return -ENOMEM;
}
-   memset(new_affiliation_111, 0,
-  sizeof(struct MR_LD_VF_AFFILIATION_111));
}
 
memset(dcmd->mbox.b, 0, MFI_MBOX_SIZE);
@@ -2333,10 +2331,10 @@ static int megasas_get_ld_vf_affiliation_12(struct 
megasas_instance *instance,
   sizeof(struct MR_LD_VF_AFFILIATION));
else {
new_affiliation =
-   pci_alloc_consistent(instance->pdev,
-(MAX_LOGICAL_DRIVES + 1) *
-sizeof(struct 
MR_LD_VF_AFFILIATION),
-_affiliation_h);
+   pci_zalloc_consistent(instance->pdev,
+ (MAX_LOGICAL_DRIVES + 1) *
+ sizeof(struct 
MR_LD_VF_AFFILIATION),
+ _affiliation_h);
if (!new_affiliation) {
dev_printk(KERN_DEBUG, >pdev->dev, "SR-IOV: 
Couldn't allocate "
   "memory for new affiliation for scsi%d\n",
@@ -2344,8 +2342,6 @@ static int megasas_get_ld_vf_affiliation_12(struct 
megasas_instance *instance,
megasas_return_cmd(instance, cmd);
return -ENOMEM;
}
-   memset(new_affiliation, 0, (MAX_LOGICAL_DRIVES + 1) *
-  sizeof(struct MR_LD_VF_AFFILIATION));
}
 
memset(dcmd->mbox.b, 0, MFI_MBOX_SIZE);
@@ -5614,16 +5610,15 @@ megasas_get_seq_num(struct megasas_instance *instance,
}
 
dcmd = >frame->dcmd;
-   el_info = pci_alloc_consistent(instance->pdev,
-  sizeof(struct megasas_evt_log_info),
-  _info_h);
+   el_info = pci_zalloc_consistent(instance->pdev,
+   sizeof(struct megasas_evt_log_info),
+   _info_h);
 
if (!el_info) {
megasas_return_cmd(instance, cmd);
return -ENOMEM;
}
 
-   memset(el_info, 0, sizeof(*el_info));
memset(dcmd->mbox.b, 0, MFI_MBOX_SIZE);
 
dcmd->cmd = MFI_CMD_DCMD;
diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c 
b/drivers/scsi/megaraid/megaraid_sas_fusion.c
index 073ced07e662..57da0acae986 100644
--- a/drivers/scsi/megaraid/megaraid_sas_fusion.c
+++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c
@@ -690,15 +690,14 @@ megasas_alloc_rdpq_fusion(struct megasas_instance 
*instance)
array_size = sizeof(struct MPI2_IOC_INIT_RDPQ_ARRAY_ENTRY) *
 MAX_MSIX_QUEUES_FUSION;
 
-   fusion->rdpq_virt = pci_alloc_consistent(instance->pdev, array_size,
->rdpq_phys);
+   fusion->rdpq_virt = pci_zalloc_consistent(instance->pdev, array_size,
+ >rdpq_phys);
if (!fusion->rdpq_virt) {

[PATCH 3/3] megaraid_sas: driver version upgrade

2018-04-06 Thread Shivasharan S 
Signed-off-by: Shivasharan S 
---
 drivers/scsi/megaraid/megaraid_sas.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/megaraid/megaraid_sas.h 
b/drivers/scsi/megaraid/megaraid_sas.h
index ba6503f37756..cb792bbfbf8b 100644
--- a/drivers/scsi/megaraid/megaraid_sas.h
+++ b/drivers/scsi/megaraid/megaraid_sas.h
@@ -35,8 +35,8 @@
 /*
  * MegaRAID SAS Driver meta data
  */
-#define MEGASAS_VERSION"07.704.04.00-rc1"
-#define MEGASAS_RELDATE"December 7, 2017"
+#define MEGASAS_VERSION"07.705.02.00-rc1"
+#define MEGASAS_RELDATE"April 4, 2018"
 
 /*
  * Device IDs
-- 
2.16.1

[PATCH 0/2] megaraid_sas: driver fixes and updates

2018-04-06 Thread Shivasharan S 
Himanshu Jha (1):
  megaraid_sas: Use zeroing memory allocator than allocator/memset

Shivasharan S (2):
  megaraid_sas: Increase timeout by 1 sec for non-RAID fastpath IOs
  megaraid_sas: driver version upgrade

 drivers/scsi/megaraid/megaraid_sas.h|  4 ++--
 drivers/scsi/megaraid/megaraid_sas_base.c   | 25 ++---
 drivers/scsi/megaraid/megaraid_sas_fusion.c |  8 +---
 3 files changed, 17 insertions(+), 20 deletions(-)

-- 
2.16.1

Re: 答复: Re: [PATCH v2] scsi: Introduce sdev_printk_ratelimited to throttlefrequent printk

2018-04-06 Thread Petr Mladek 
On Fri 2018-04-06 10:30:16, Petr Mladek wrote:
> On Tue 2018-04-03 14:19:43, wen.yan...@zte.com.cn wrote:
> > On the other hand，queue_lock is big, looping doing something under spinlock 
> > 
> > may locked many things and taking a long time, may cause some problems.
> > 
> > So This code needs to be optimized later:
> > 
> > scsi_request_fn()
> > {
> > for (;;) {
> > int rtn;
> > /*
> >  * get next queueable request.  We do this early to make sure
> >  * that the request is fully prepared even if we cannot
> >  * accept it.
> >  */
> > 
> > req = blk_peek_request(q);
> > 
> > if (!req)
> > break;
> > 
> > if (unlikely(!scsi_device_online(sdev))) {
> > sdev_printk(KERN_ERR, sdev,
> > "rejected I/O to offline device\n");
> > scsi_kill_request(req, q);
> > continue;
> > 
> > ^ still under spinlock
> > }
> 
> I wonder if the following might be the best solution after all:
> 
>   if (unlikely(!scsi_device_online(sdev))) {
>   scsi_kill_request(req, q);
> 
>   /*
>* printk() might take a while on slow consoles.
>* Prevent solftlockups by releasing the lock.
>*/
>   spin_unlock_irq(q->queue_lock);
>   sdev_printk(KERN_ERR, sdev,
>   "rejecting I/O to offline device\n");
>   spin_lock_irq(q->queue_lock);
>   continue;
>   }
> 
> I see that the lock is released also in several other situations.
> Therefore it looks safe. Also handling too many requests without
> releasing the lock seems to be a bad idea in general. I think
> that this solution was already suggested earlier.

Just to be sure. Is it safe to kill first few requests and proceed
the others?

I wonder if the device could actually get online without releasing
the queue lock. If not, we normally killed all requests.

I wonder if a local flag might actually help to reduce the number
of messages but keep the existing behavior. I mean something like

static void scsi_request_fn(struct request_queue *q)
{
struct scsi_device *sdev = q->queuedata;
   ^
   The device is the same for each request
   in this queue.


struct request *req;
+   bool offline_reported = false;

/*
 * To start with, we keep looping until the queue is empty, or until
 * the host is no longer able to accept any more requests.
 */
shost = sdev->host;
for (;;) {
int rtn;
req = blk_peek_request(q);
if (!req)
break;

if (unlikely(!scsi_device_online(sdev))) {
+   if (!offline_reported) {
sdev_printk(KERN_ERR, sdev,
"rejecting I/O to offline device\n");
+   offline_reported = true;
+   }
scsi_kill_request(req, q);
continue;
}


Please, note that I am not familiar with the scsi code. I am involved
because this is printk related. Unfortunately, we could not make
printk() faster. The main principle is to get messages on the console
ASAP. Nobody knows when the system might die and any message might
be important.

Best Regards,
Petr

Re: 答复: Re: [PATCH v2] scsi: Introduce sdev_printk_ratelimited to throttlefrequent printk

2018-04-06 Thread Petr Mladek 
On Tue 2018-04-03 14:19:43, wen.yan...@zte.com.cn wrote:
> On the other hand，queue_lock is big, looping doing something under spinlock 
> 
> may locked many things and taking a long time, may cause some problems.
> 
> So This code needs to be optimized later:
> 
> scsi_request_fn()
> {
>   for (;;) {
>   int rtn;
>   /*
>* get next queueable request.  We do this early to make sure
>* that the request is fully prepared even if we cannot
>* accept it.
>*/
> 
>   req = blk_peek_request(q);
> 
>   if (!req)
>   break;
> 
>   if (unlikely(!scsi_device_online(sdev))) {
>   sdev_printk(KERN_ERR, sdev,
>   "rejected I/O to offline device\n");
>   scsi_kill_request(req, q);
>   continue;
> 
>   ^ still under spinlock
>   }

I wonder if the following might be the best solution after all:

if (unlikely(!scsi_device_online(sdev))) {
scsi_kill_request(req, q);

/*
 * printk() might take a while on slow consoles.
 * Prevent solftlockups by releasing the lock.
 */
spin_unlock_irq(q->queue_lock);
sdev_printk(KERN_ERR, sdev,
"rejecting I/O to offline device\n");
spin_lock_irq(q->queue_lock);
continue;
}

I see that the lock is released also in several other situations.
Therefore it looks safe. Also handling too many requests without
releasing the lock seems to be a bad idea in general. I think
that this solution was already suggested earlier.

Please, note that I moved scsi_kill_request() up. It looks natural
to remove it from the queue before we release the queue lock.

Best Regards,
Petr

BTW: Your mail had strange formatting. Please, try to avoid using
html.

[PATCH] qla2xxx: correctly shift host byte

2018-04-06 Thread Johannes Thumshirn 
The host byte has to be shifted by 16 not 6.

Signed-off-by: Johannes Thumshirn 
---
 drivers/scsi/qla2xxx/qla_isr.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/qla2xxx/qla_isr.c b/drivers/scsi/qla2xxx/qla_isr.c
index 89f93ebd819d..49d67e1d571f 100644
--- a/drivers/scsi/qla2xxx/qla_isr.c
+++ b/drivers/scsi/qla2xxx/qla_isr.c
@@ -2368,7 +2368,7 @@ qla25xx_process_bidir_status_iocb(scsi_qla_host_t *vha, 
void *pkt,
bsg_job->reply_len = sizeof(struct fc_bsg_reply);
/* Always return DID_OK, bsg will send the vendor specific response
 * in this case only */
-   sp->done(sp, DID_OK << 6);
+   sp->done(sp, DID_OK << 16);
 
 }
 
-- 
2.16.2

Re: [PATCH v3] scsi: Introduce sdev_printk_ratelimited to throttle frequent printk

2018-04-06 Thread Petr Mladek 
On Tue 2018-04-03 14:04:40, Wen Yang wrote:
> There would be so many same lines printed by frequent printk if one
> disk went wrong, like,
> [  546.185242] sd 0:1:0:0: rejecting I/O to offline device
> [  546.185258] sd 0:1:0:0: rejecting I/O to offline device
> [  546.185280] sd 0:1:0:0: rejecting I/O to offline device
> [  546.185307] sd 0:1:0:0: rejecting I/O to offline device
> [  546.185334] sd 0:1:0:0: rejecting I/O to offline device
> [  546.185364] sd 0:1:0:0: rejecting I/O to offline device
> [  546.185390] sd 0:1:0:0: rejecting I/O to offline device
> [  546.185410] sd 0:1:0:0: rejecting I/O to offline device
> For slow serial console, the frequent printk may be blocked for a
> long time, and if any spin_lock has been acquired before the printk
> like in scsi_request_fn, watchdog could be triggered.
> 
> Related disscussion can be found here,
> https://bugzilla.kernel.org/show_bug.cgi?id=199003
> And Petr brought the idea to throttle the frequent printk, it's
> useless to print the same lines frequently after all.
> 
> v2: fix some typos
> v3: limit the print only for the same device
> 
> Suggested-by: Petr Mladek 
> Suggested-by: Sergey Senozhatsky 
> Signed-off-by: Wen Yang 
> Signed-off-by: Jiang Biao 
> Signed-off-by: Tan Hu 
> Reviewed-by: Bart Van Assche 
> CC: BartVanAssche 
> CC: Petr Mladek 
> CC: Sergey Senozhatsky 
> CC: Martin K. Petersen 
> CC: "James E.J. Bottomley" 
> CC: Tejun Heo 
> CC: JasonYan 
> ---
>  drivers/scsi/scsi_lib.c| 6 +++---
>  drivers/scsi/scsi_scan.c   | 3 +++
>  include/scsi/scsi_device.h | 8 
>  3 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index c84f931..f77e801 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -1301,7 +1301,7 @@ static int scsi_setup_cmnd(struct scsi_device *sdev, 
> struct request *req)
>* commands.  The device must be brought online
>* before trying any recovery commands.
>*/
> - sdev_printk(KERN_ERR, sdev,
> + sdev_printk_ratelimited(KERN_ERR, sdev,
>   "rejecting I/O to offline device\n");
>   ret = BLKPREP_KILL;
>   break;
> @@ -1310,7 +1310,7 @@ static int scsi_setup_cmnd(struct scsi_device *sdev, 
> struct request *req)
>* If the device is fully deleted, we refuse to
>* process any commands as well.
>*/
> - sdev_printk(KERN_ERR, sdev,
> + sdev_printk_ratelimited(KERN_ERR, sdev,
>   "rejecting I/O to dead device\n");
>   ret = BLKPREP_KILL;
>   break;
> @@ -1802,7 +1802,7 @@ static void scsi_request_fn(struct request_queue *q)
>   break;
>  
>   if (unlikely(!scsi_device_online(sdev))) {
> - sdev_printk(KERN_ERR, sdev,
> + sdev_printk_ratelimited(KERN_ERR, sdev,
>   "rejecting I/O to offline device\n");
>   scsi_kill_request(req, q);
>   continue;
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 0880d97..a6da935 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -288,6 +288,9 @@ static struct scsi_device *scsi_alloc_sdev(struct 
> scsi_target *starget,
>   scsi_change_queue_depth(sdev, sdev->host->cmd_per_lun ?
>   sdev->host->cmd_per_lun : 1);
>  
> + /* Enable message ratelimiting. Default is 10 messages per 5 secs. */
> + ratelimit_state_init(>sdev_ratelimit_state,
> + DEFAULT_RATELIMIT_INTERVAL, DEFAULT_RATELIMIT_BURST);

This makes the ratelimiting device independent but it adds another
problem. Several unrelated messages share the ratelimit data now.
It means that cycling on one message might cause that people will
not see the others.

One question is if we really need to ratelimit all three messages.

Another question if we are really printing all the messages in
a single cycle without releasing the spin lock. Then I wonder what
event will cause that the cycle finishes. If the event is independent
then ratelimiting the messages need not help to avoid the softlockup.
I mean that we might cycle faster without the printk but it does
not mean the event would unblock the cycle faster.

Best Regards,
Petr

>   scsi_sysfs_device_initialize(sdev);
>  
>   if (shost->hostt->slave_alloc) {
> diff

Re: [PATCH v3 0/3] Report all request failures again to user space

2018-04-06 Thread Johannes Thumshirn 
On 05/04/18 19:49, Martin K. Petersen wrote:
> 
> Bart,
> 
>> A recent change in the SCSI core caused certain request failures no
>> longer to be reported to user space. Damien noticed this by sending a
>> write request that is not aligned to the write pointer to an SMR drive
>> from user space. Such non-aligned write requests are failed by the
>> drive and such failures should be reported to user space. This patch
>> series makes sure that all SCSI request failures are again reported to
>> user space. This patch series also makes the SCSI core recognize
>> status codes like CONDITION MET as not being an error.  Please
>> consider at least the first patch in this series for the rc stage of
>> kernel v4.17.
> 
> Looks good to me.
> 
> Longer term I'd really like to see the command result integer
> host/driver/msg/status stuff cleaned up. It's super arcane and the
> associated naming schemes make it a very error-prone interface.
> 

I did start a series [1] for this but than got distracted by more urgent
things. I can pick it up again I think.

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/jth/linux.git/log/?h=iscsi_DID_REQUEUE

Johannes
-- 
Johannes Thumshirn  Storage
jthumsh...@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

Re: [PATCH] target: change default dbroot to /etc/target

2018-04-06 Thread Christoph Hellwig 
On Thu, Apr 05, 2018 at 01:54:25PM -0700, Lee Duncan wrote:
> How about if the code looks for /etc/target, then uses /var/target if
> /etc/target is not present? Then users can use the current sysfs logic
> to set the path to any other directory, if neither of these paths are to
> their liking?
> 
> And users can always find out the current dbroot with the sysfs attribute.

Sounds fine to me.

Re: Multi-Actuator SAS HDD First Look

2018-04-06 Thread Christoph Hellwig 
On Fri, Apr 06, 2018 at 08:24:18AM +0200, Hannes Reinecke wrote:
> Ah. Far better.
> What about delegating FORMAT UNIT to the control LUN, and not
> implementing it for the individual disk LUNs?
> That would make an even stronger case for having a control LUN;
> with that there wouldn't be any problem with having to synchronize
> across LUNs etc.

It sounds to me like NVMe might be a much better model for this drive
than SCSI, btw :)

Re: [PATCH v3 2/3] Rename __scsi_error_from_host_byte() into scsi_result_to_blk_status()

2018-04-06 Thread Hannes Reinecke 
On Thu,  5 Apr 2018 10:33:00 -0700
Bart Van Assche  wrote:

> Since the next patch will modify this function such that it
> checks more than just the host byte of the SCSI result, rename
> __scsi_error_from_host_byte() into scsi_result_to_blk_status().
> This patch does not change any functionality.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Hannes Reinecke 
> Cc: Douglas Gilbert 
> Cc: Damien Le Moal 
> Cc: Christoph Hellwig 
> Cc: Lee Duncan 
> ---
>  drivers/scsi/scsi_lib.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index c0e4ae733cce..26d82f323b31 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -723,14 +723,14 @@ static bool scsi_end_request(struct request
> *req, blk_status_t error, }
>  
>  /**
> - * __scsi_error_from_host_byte - translate SCSI error code into errno
> - * @cmd: SCSI command (unused)
> + * scsi_result_to_blk_status - translate a SCSI result code into
> blk_status_t
> + * @cmd: SCSI command
>   * @result:  scsi error code
>   *
> - * Translate SCSI error code into block errors.
> + * Translate a SCSI result code into a blk_status_t value. May reset
> the host
> + * byte of @cmd->result.
>   */
> -static blk_status_t __scsi_error_from_host_byte(struct scsi_cmnd
> *cmd,
> - int result)
> +static blk_status_t scsi_result_to_blk_status(struct scsi_cmnd *cmd,
> int result) {
>   switch (host_byte(result)) {
>   case DID_TRANSPORT_FAILFAST:
> @@ -810,10 +810,10 @@ void scsi_io_completion(struct scsi_cmnd *cmd,
> unsigned int good_bytes) SCSI_SENSE_BUFFERSIZE);
>   }
>   if (!sense_deferred)
> - error =
> __scsi_error_from_host_byte(cmd, result);
> + error =
> scsi_result_to_blk_status(cmd, result); }
>   /*
> -  * __scsi_error_from_host_byte may have reset the
> host_byte
> +  * scsi_result_to_blk_status may have reset the
> host_byte */
>   scsi_req(req)->result = cmd->result;
>   scsi_req(req)->resid_len = scsi_get_resid(cmd);
> @@ -835,7 +835,7 @@ void scsi_io_completion(struct scsi_cmnd *cmd,
> unsigned int good_bytes)
>* good_bytes != blk_rq_bytes(req) as the signal for
> an error.
>* This sets the error explicitly for the problem
> case. */
> - error = __scsi_error_from_host_byte(cmd, result);
> + error = scsi_result_to_blk_status(cmd, result);
>   }
>  
>   /* no bidi support for !blk_rq_is_passthrough yet */
> @@ -905,7 +905,7 @@ void scsi_io_completion(struct scsi_cmnd *cmd,
> unsigned int good_bytes) if (result == 0)
>   goto requeue;
>  
> - error = __scsi_error_from_host_byte(cmd, result);
> + error = scsi_result_to_blk_status(cmd, result);
>  
>   if (host_byte(result) == DID_RESET) {
>   /* Third party bus reset or reset for error recovery

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes

Re: [PATCH v3 3/3] Make scsi_result_to_blk_status() recognize CONDITION MET

2018-04-06 Thread Hannes Reinecke 
On Thu,  5 Apr 2018 10:33:01 -0700
Bart Van Assche  wrote:

> Ensure that CONDITION MET and other non-zero status values that
> indicate success are translated into BLK_STS_OK.
> 
> Signed-off-by: Bart Van Assche 
> Cc: Hannes Reinecke 
> Cc: Douglas Gilbert 
> Cc: Damien Le Moal 
> Cc: Christoph Hellwig 
> Cc: Lee Duncan 
> ---
>  drivers/scsi/scsi_lib.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 26d82f323b31..3e494a476c50 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -733,6 +733,15 @@ static bool scsi_end_request(struct request
> *req, blk_status_t error, static blk_status_t
> scsi_result_to_blk_status(struct scsi_cmnd *cmd, int result) {
>   switch (host_byte(result)) {
> + case DID_OK:
> + /*
> +  * Also check the other bytes than the status byte
> in result
> +  * to handle the case when a SCSI LLD sets result to
> +  * DRIVER_SENSE << 24 without setting
> SAM_STAT_CHECK_CONDITION.
> +  */
> + if (scsi_status_is_good(result) && (result & ~0xff)
> == 0)
> + return BLK_STS_OK;
> + return BLK_STS_IOERR;
>   case DID_TRANSPORT_FAILFAST:
>   return BLK_STS_TRANSPORT;
>   case DID_TARGET_FAILURE:

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes

Re: [PATCH v3 1/3] Revert "scsi: core: return BLK_STS_OK for DID_OK in __scsi_error_from_host_byte()"

2018-04-06 Thread Hannes Reinecke 
On Thu,  5 Apr 2018 10:32:59 -0700
Bart Van Assche  wrote:

> The description of commit e39a97353e53 is wrong: it mentions that
> commit 2a842acab109 introduced a bug in __scsi_error_from_host_byte()
> although that commit did not change the behavior of that function.
> Additionally, commit e39a97353e53 introduced a bug: it causes commands
> that fail with hostbyte=DID_OK and driverbyte=DRIVER_SENSE to be
> completed with BLK_STS_OK. Hence revert that commit.
> 
> Fixes: e39a97353e53 ("scsi: core: return BLK_STS_OK for DID_OK in
> __scsi_error_from_host_byte()") Reported-by: Damien Le Moal
>  Signed-off-by: Bart Van Assche
>  Cc: Hannes Reinecke 
> Cc: Douglas Gilbert 
> Cc: Damien Le Moal 
> Cc: Christoph Hellwig 
> Cc: Lee Duncan 
> Cc: sta...@vger.kernel.org
> ---
>  drivers/scsi/scsi_lib.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
> index 1d83f29aee74..c0e4ae733cce 100644
> --- a/drivers/scsi/scsi_lib.c
> +++ b/drivers/scsi/scsi_lib.c
> @@ -733,8 +733,6 @@ static blk_status_t
> __scsi_error_from_host_byte(struct scsi_cmnd *cmd, int result)
>  {
>   switch (host_byte(result)) {
> - case DID_OK:
> - return BLK_STS_OK;
>   case DID_TRANSPORT_FAILFAST:
>   return BLK_STS_TRANSPORT;
>   case DID_TARGET_FAILURE:

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes

Re: Multi-Actuator SAS HDD First Look

2018-04-06 Thread Hannes Reinecke 
On Thu, 5 Apr 2018 17:43:46 -0600
Tim Walker  wrote:

> On Tue, Apr 3, 2018 at 1:46 AM, Christoph Hellwig 
> wrote:
> > On Sat, Mar 31, 2018 at 01:03:46PM +0200, Hannes Reinecke wrote:  
> >> Actually I would propose to have a 'management' LUN at LUN0, who
> >> could handle all the device-wide commands (eg things like START
> >> STOP UNIT, firmware update, or even SMART commands), and ignoring
> >> them for the remaining LUNs.  
> >
> > That is in fact the only workable option at all.  Everything else
> > completly breaks the scsi architecture.  
> 
> Here's an update: Seagate will eliminate the inter-LU actions from
> FORMAT UNIT and SANITIZE. Probably SANITIZE will be per-LUN, but
> FORMAT UNIT is trickier due to internal drive architecture, and how
> FORMAT UNIT initializes on-disk metadata. Likely it will require some
> sort of synchronization across LUNs, such as the command being sent to
> both LUNs sequentially or something similar. We are also considering
> not supporting FORMAT UNIT at all - would anybody object? Any other
> suggestions?
> 

Ah. Far better.
What about delegating FORMAT UNIT to the control LUN, and not
implementing it for the individual disk LUNs?
That would make an even stronger case for having a control LUN;
with that there wouldn't be any problem with having to synchronize
across LUNs etc.

Cheers,

Hannes

Re: usercopy whitelist woe in scsi_sense_cache

2018-04-06 Thread Oleksandr Natalenko 

Hi.

05.04.2018 20:52, Kees Cook wrote:

Okay. My qemu gets mad about that and wants the format=raw argument,
so I'm using:

-drive file=sda.img,format=raw \
-drive file=sdb.img,format=raw \

How are you running your smartctl? I'm doing this now:

[1]   Running while :; do
( smartctl -a /dev/sda; smartctl -a /dev/sdb ) > /dev/null;
done &


Yes, so do I.


I assume I'm missing something from your .config, but since I don't
boot with an initramfs, I had to tweak it a bit. I'll try again...


Let me, maybe, describe, what both the VM and the server have in common:

1. have 4 CPUs
2. are EFI-based
3. use blk-mq with BFQ scheduler (it is set up via udev rule during 
boot)

4. have zswap enabled
5. have 2 SATA disks with RAID10 on top of it (layout f2)
6. have LUKS on top of the RAID, and LVM on top of the LUKS

VM has machine type "q35", BTW.

Do you think something of what's mentioned above is relevant for the 
code path in question?


Thanks.

Regards,
  Oleksandr