Re: [PATCHv3 2/4] myrb: Add Mylex RAID controller (block interface)
> +#define myrb_logical_channel(shost) ((shost)->max_channel - 1)
inline function, please.
> +/*
> + * myrb_exec_cmd executes V1 Command and waits for completion.
> + */
> +
> +static void myrb_exec_cmd(myrb_hba *cb, myrb_cmdblk *cmd_blk)
> +{
> + DECLARE_COMPLETION_ONSTACK(Completion);
> + unsigned long flags;
> +
> + cmd_blk->Completion = &Completion;
> +
> + spin_lock_irqsave(&cb->queue_lock, flags);
> + cb->qcmd(cb, cmd_blk);
> + spin_unlock_irqrestore(&cb->queue_lock, flags);
> +
> + if (in_interrupt())
> + return;
> + wait_for_completion(&Completion);
> +}
This interface looks completely bogus as it silently does something
else if in_interrupt() is true. As far as I can tell from a quick
scan it never even is called from interrupt context and all callers
expect to get a status back, so it should be changed to just
a WARN_ON for the in_interrupt case.
And to avoid some boiler plate code it could just return
cmd_blk->status as the return value.
> +
> +/*
> + myrb_exec_type3 executes a DAC960 V1 Firmware Controller Type 3
> + Command and waits for completion.
> +*/
> +
> +static unsigned short myrb_exec_type3(myrb_hba *cb,
> + myrb_cmd_opcode op,
> + dma_addr_t addr)
Why the empty lines before the description and function? Also
Please use normal Linux block comment style instead of this weird
style.
> + dma_free_coherent(&cb->pdev->dev, sizeof(myrb_log_entry),
> + ev_buf, ev_addr);
> + return;
> +}
No need for an empty return statement at the end of a function.
> + if ((new_entry->parity_err != old_entry->parity_err) ||
> + (new_entry->soft_err != old_entry->soft_err) ||
> + (new_entry->hard_err != old_entry->hard_err) ||
> + (new_entry->misc_err !=
> + old_entry->misc_err))
No need for any of the inner braces.
> + mbox->Type3.addr = rbld_addr;
> + myrb_exec_cmd(cb, cmd_blk);
> + status = cmd_blk->status;
> + if (status == DAC960_V1_NormalCompletion) {
> + unsigned int ldev_num = rbld_buf->ldev_num;
> + unsigned int ldev_size = rbld_buf->ldev_size;
> + unsigned int blocks_done =
> + ldev_size - rbld_buf->blocks_left;
> + struct scsi_device *sdev;
> +
> + sdev = scsi_device_lookup(cb->host,
> + myrb_logical_channel(cb->host),
> + ldev_num, 0);
This seems to leak the scsi_device.
> + if ((new->ldev_critical > 0 ||
> + new->ldev_critical != old.ldev_critical) ||
> + (new->ldev_offline > 0 ||
> + new->ldev_offline != old.ldev_offline) ||
> + (new->ldev_count != old.ldev_count)) {
no need for the inner braces here as-is, but the logic looks broken to
me as well. Shouldn't the inner ||s be &&s?
> + if ((new->pdev_dead > 0 ||
> + new->pdev_dead != old.pdev_dead) ||
Same here.
> +static ssize_t myrb_show_dev_level(struct device *dev,
> + struct device_attribute *attr, char *buf)
Two tab indentation for prototype continuations, please.
> +myrb_hba *myrb_alloc_host(struct pci_dev *pdev,
> + const struct pci_device_id *entry)
static? Or even bettetr just merge into the caller.
> +{
> + struct Scsi_Host *shost;
> + myrb_hba *cb;
> +
> + shost = scsi_host_alloc(&myrb_template, sizeof(myrb_hba));
> + if (!shost)
> + return NULL;
> +
> + cb = (myrb_hba *)shost->hostdata;
Use shost_priv(), please.
> +bool myrb_err_status(myrb_hba *cb, unsigned char error,
> + unsigned char parm0, unsigned char parm1)
static for all functions, please.
> +static void myrb_remove(struct pci_dev *pdev)
> +{
> + myrb_hba *cb = pci_get_drvdata(pdev);
> +
> + if (cb == NULL)
> + return;
Can't happen.
> +static const struct pci_device_id myrb_id_table[] = {
> + {
> + .vendor = PCI_VENDOR_ID_DEC,
> + .device = PCI_DEVICE_ID_DEC_21285,
> + .subvendor = PCI_VENDOR_ID_MYLEX,
> + .subdevice = PCI_DEVICE_ID_MYLEX_DAC960_LA,
> + .driver_data= (unsigned long) &DAC960_LA_privdata,
> + },
> + {
> + .vendor = PCI_VENDOR_ID_MYLEX,
> + .device = PCI_DEVICE_ID_MYLEX_DAC960_PG,
> + .subvendor = PCI_ANY_ID,
> + .subdevice = PCI_ANY_ID,
> + .driver_data= (unsigned long) &DAC960_PG_privdata,
> + },
Please use the PCI_DEVICE_SUB and PCI_VDEVICE macros.
> +typedef enum
No typedefs for enums or structs, please.
> +{
Linux style is to not have the opening curly brace on a separate line.
> +}
> +__attribute__ ((pack
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: > > Kashyap, Hi Martin, > > Sorry, I didn't give you complete information — with the previous > > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > > "A Cable". > > > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: > > Do you get different sg_readcap -l output when accessing it in UAS mode? > I.e. is lbpme=1? Afraid, no :-( I was excited for a brief moment, but it's the same as earlier. The result with the SSD via 'Thunderbolt': $> sudo sg_readcap -l /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=976773167 (0x3a38602f), Number of logical blocks=976773168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB /me naively wonders if it has anything to do with accessing it via Linux. -- /kashyap
Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled
I reviewed this several days before but mistakenly replied only to the open-iscsi list. Signed-off-by: Lee Duncan -- Lee-Man Duncan Sent from my iPhone, dude > On Mar 14, 2018, at 10:11 PM, Martin K. Petersen > wrote: > > >> iscsi tcp will first send out data, then calculate and send data >> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will >> be written in spite of the on going writeback. Consequently, wrong >> digest will be got and sent to target. >> >> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled >> in iscsi_tcp .slave_configure callback. > > Lee, Chris: Please review! > > -- > Martin K. PetersenOracle Linux Engineering > > -- > You received this message because you are subscribed to a topic in the Google > Groups "open-iscsi" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/open-iscsi/owLIZAXfgoA/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > open-iscsi+unsubscr...@googlegroups.com. > To post to this group, send email to open-is...@googlegroups.com. > Visit this group at https://groups.google.com/group/open-iscsi. > For more options, visit https://groups.google.com/d/optout.
Re: [PATCH] scsi: cxgb4i: potential array overflow in t4_uld_rx_handler()
What happened to this one?
regards,
dan carpenter
On Wed, Nov 29, 2017 at 02:42:20PM +0300, Dan Carpenter wrote:
> The story is that Smatch marks skb->data as untrusted and so it
> complains about this code:
>
> drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:2111 t4_uld_rx_handler()
> error: buffer overflow 'cxgb4i_cplhandlers' 239 <= 255.
>
> I don't know the code very well, but it looks like a reasonable warning
> message. Let's address it by adding a sanity check to make sure "opc"
> is within bounds.
>
> Fixes: bbc02c7e9d34 ("cxgb4: Add register, message, and FW definitions")
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> index 266eddf17a99..94b2d5660a07 100644
> --- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> +++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
> @@ -2108,12 +2108,12 @@ static int t4_uld_rx_handler(void *handle, const
> __be64 *rsp,
> log_debug(1 << CXGBI_DBG_TOE,
> "cdev %p, opcode 0x%x(0x%x,0x%x), skb %p.\n",
>cdev, opc, rpl->ot.opcode_tid, ntohl(rpl->ot.opcode_tid), skb);
> - if (cxgb4i_cplhandlers[opc])
> - cxgb4i_cplhandlers[opc](cdev, skb);
> - else {
> + if (opc >= ARRAY_SIZE(cxgb4i_cplhandlers) || !cxgb4i_cplhandlers[opc]) {
> pr_err("No handler for opcode 0x%x.\n", opc);
> __kfree_skb(skb);
> + return 0;
> }
> + cxgb4i_cplhandlers[opc](cdev, skb);
> return 0;
> nomem:
> log_debug(1 << CXGBI_DBG_TOE, "OOM bailing out.\n");
Re: [PATCH v3] m68k/amiga - Amiga Zorro NCR53C9x boards: new zorro_esp.c
On Wed, 14 Mar 2018, Michael Schmitz wrote: > > > > Please pass "addr" and "fifo" as macro parameters, too, so it's easier > > for the reviewer to notice they are used. > > Yes, I can do that (meaning Finn would need to make the same change to > keep our versions in sync). Personally, I wouldn't want to change it. This wasn't an oversight. Maybe if you (Geert) take a look at MAC_ESP_PDMA_LOOP, etc. this style might make more sense. These are not macros in a header file that might get used in any random scope. There is exactly one scope in which the macro appears, and the variables that appear in the macro are simply the variables from that scope. If you apply the rule, "the macro's parameters should exhaustively list all the macro's symbols", then (in this case) you'd violate the rule "Don't Repeat Yourself". And if you'd adhere to the latter rule then you'd violate the former. So I chose the more readable option. The preprocessor allows us to pretend we are doing symbolic code transformation, but that's not needed here. This was meant to be a textual device. --
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote: On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: Kashyap, Hi Martin, Sorry, I didn't give you complete information — with the previous `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB "A Cable". Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: Do you get different sg_readcap -l output when accessing it in UAS mode? I.e. is lbpme=1? Afraid, no :-( I was excited for a brief moment, but it's the same as earlier. The result with the SSD via 'Thunderbolt': $> sudo sg_readcap -l /dev/sdc Read Capacity results: Protection: prot_en=0, p_type=0, p_i_exponent=0 Logical block provisioning: lbpme=0, lbprz=0 Last logical block address=976773167 (0x3a38602f), Number of logical blocks=976773168 Logical block length=512 bytes Logical blocks per physical block exponent=0 Lowest aligned logical block address=0 Hence: Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB /me naively wonders if it has anything to do with accessing it via Linux. You can also run 'sg_readcap -l' on a Windows machine to test your theory. Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then you would do something like: sg_readcap -l pd2 There is no IOS port of sg3_utils. I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe commands) that tell a storage device something like: "BTW I'm a Linux machine running Ubuntu 17.10 on hardware". It is possible that a storage device might recognize an OS by the pattern of commands it sends, especially in the device discovery mode. So basically your suggestion is a long shot. There might be a "secret" setting in a vendor specific command that another OS is aware of. For example, according to the 'net this command: sg_raw /dev/sr0 EA 00 00 00 00 00 01 allows owners of Apple USB Superdrives to use them on other OSes. Doug Gilbert *** there are transport_ids used by PERSISTENT RESERVATION commands to differentiate one machine from another. But they convey about as much information as a random number does. Also that applies to a multi-initiator, single target model which isn't the case when we are talking about USB/Thunderbolt attachment.
RE: [PATCH] bfa: remove VLA
> > - sizeof(wwn_t[iocmd->nports])) != BFA_STATUS_OK) {
> > + sizeof(wwn_t) * iocmd->nports) != BFA_STATUS_OK) {
>
> These parentheses made me blurry eyed but it's actually OK.
iocmd->nports * sizeof(wwn_t)) != BFA_STATUS_OK) {
is easier to focus on :-)
David
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 12:19:11PM +0100, Douglas Gilbert wrote: > On 2018-03-15 10:47 AM, Kashyap Chamarthy wrote: > > On Wed, Mar 14, 2018 at 11:43:55PM -0400, Martin K. Petersen wrote: > > > > > > Kashyap, > > > > Hi Martin, > > > > > > Sorry, I didn't give you complete information — with the previous > > > > `dmesg` output, I actually attached the SSD (Samsung T5) via regular USB > > > > "A Cable". > > > > > > > > Now, I re-attached the SSD via the "Thunderbolt" port on my other laptop > > > > (Lenovo T470s), it _does_ show "UAS". Refer the arrow below: > > > > > > Do you get different sg_readcap -l output when accessing it in UAS mode? > > > I.e. is lbpme=1? > > > > Afraid, no :-( I was excited for a brief moment, but it's the same as > > earlier. The result with the SSD via 'Thunderbolt': > > > > $> sudo sg_readcap -l /dev/sdc > > Read Capacity results: > > Protection: prot_en=0, p_type=0, p_i_exponent=0 > > Logical block provisioning: lbpme=0, lbprz=0 > > Last logical block address=976773167 (0x3a38602f), Number of > > logical blocks=976773168 > > Logical block length=512 bytes > > Logical blocks per physical block exponent=0 > > Lowest aligned logical block address=0 > > Hence: > > Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB > > > > > > /me naively wonders if it has anything to do with accessing it via > > Linux. > > You can also run 'sg_readcap -l' on a Windows machine to test your theory. > Do 'sg_scan.exe' first to see where (and if) the 'physical disk' is, then > you would do something like: > sg_readcap -l pd2 > > There is no IOS port of sg3_utils. > > I am not aware of any SCSI command *** (and haven't seen any ATA or NVMe > commands) that tell a storage device something like: "BTW I'm a Linux > machine running Ubuntu 17.10 on hardware". > > It is possible that a storage device might recognize an OS by the pattern > of commands it sends, especially in the device discovery mode. > > So basically your suggestion is a long shot. There might be a "secret" > setting in a vendor specific command that another OS is aware of. > For example, according to the 'net this command: >sg_raw /dev/sr0 EA 00 00 00 00 00 01 > allows owners of Apple USB Superdrives to use them on other OSes. I see, thanks for the explanation and the specific useful commands. I'll try to get hold of a friend's Windows computer, as I don't have one with me. But your "long shot" comment adjusted my expectations to not hold my breath. > *** there are transport_ids used by PERSISTENT RESERVATION commands to > differentiate one machine from another. But they convey about as > much information as a random number does. Also that applies to a > multi-initiator, single target model which isn't the case when we > are talking about USB/Thunderbolt attachment. > -- /kashyap
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
Kashyap, > /me naively wonders if it has anything to do with accessing it via > Linux. I'm guessing that the drive doesn't actually support SCSI UNMAP. I have a T3 that reports all the right things in the bl/lbpv VPD pages but also has lbpme set to 0. Interestingly enough, my T3 does appear to be a regular SATA drive behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA passthrough? -- Martin K. Petersen Oracle Linux Engineering
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On 2018-03-15 01:45 PM, Martin K. Petersen wrote: Kashyap, /me naively wonders if it has anything to do with accessing it via Linux. I'm guessing that the drive doesn't actually support SCSI UNMAP. I have a T3 that reports all the right things in the bl/lbpv VPD pages but also has lbpme set to 0. Interestingly enough, my T3 does appear to be a regular SATA drive behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA passthrough? hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS OPTION!!" in its manpage :-) Doug Gilbert
[Bug 198861] Regression causes kernel OOPS and hang in SCSI error report
https://bugzilla.kernel.org/show_bug.cgi?id=198861 --- Comment #6 from Bart Van Assche (bvanass...@acm.org) --- Kernels 4.15.10 and 4.14.27 include patch "scsi: core: Avoid that ATA error handling can trigger a kernel hang or oops". -- You are receiving this mail because: You are the assignee for the bug.
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 08:45:05AM -0400, Martin K. Petersen wrote:
>
> Kashyap,
>
> > /me naively wonders if it has anything to do with accessing it via
> > Linux.
>
> I'm guessing that the drive doesn't actually support SCSI UNMAP. I have
> a T3 that reports all the right things in the bl/lbpv VPD pages but also
> has lbpme set to 0.
>
> Interestingly enough, my T3 does appear to be a regular SATA drive
> behind a USB bridge.
I see. So I ran `hdparm` on my SSD (still attached via the
'Thunderbolt' port), and it does show TRIM support:
$> hdparm -I /dev/sdc | grep TRIM
*Data Set Management TRIM supported (limit 8 blocks)
(Full output attached to this e-mail as a text file.)
> Have you tried to issue a DSM TRIM command via ATA
> passthrough?
I'm afraid I don't know how to do that (my SCSI / (S)ATA knowledge is
less than zero). If there's a page where I can educate myself about how
to send the TRIM command via ATA passthrough I'd appreciate it. (Aside:
>From my looking up, I don't see any ATA equivalent of SCSI's
'sg3_utils'; wonder if there is any.)
Thanks for the response.
--
/kashyap
$> hdparm -I /dev/sdc
/dev/sdc:
ATA device, with non-removable media
Model Number: Samsung Portable SSD T5
Serial Number: S3UNNV0K102165T
Firmware Revision: MVT41P1Q
Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions,
SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
Used: unknown (minor revision code 0x0039)
Supported: 9 8 7 6 5
Likely used: 9
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors:16514064
LBAuser addressable sectors: 268435455
LBA48 user addressable sectors: 976773168
Logical Sector size: 512 bytes
Physical Sector size: 512 bytes
Logical Sector-0 offset: 0 bytes
device size with M = 1024*1024: 476940 MBytes
device size with M = 1000*1000: 500107 MBytes (500 GB)
cache/buffer size = unknown
Form Factor: unknown (0x0006]
Nominal Media Rotation Rate: Solid State Device
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 1 Current = 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
Enabled Supported:
*SMART feature set
*Power Management feature set
*Write cache
*Look-ahead
*WRITE_BUFFER command
*READ_BUFFER command
*NOP cmd
*DOWNLOAD_MICROCODE
SET_MAX security extension
*48-bit Address feature set
*Mandatory FLUSH_CACHE
*FLUSH_CACHE_EXT
*SMART error logging
*SMART self-test
*General Purpose Logging feature set
*WRITE_{DMA|MULTIPLE}_FUA_EXT
*64-bit World wide name
Write-Read-Verify feature set
*WRITE_UNCORRECTABLE_EXT command
*{READ,WRITE}_DMA_EXT_GPL commands
*Segmented DOWNLOAD_MICROCODE
*Gen1 signaling speed (1.5Gb/s)
*Gen2 signaling speed (3.0Gb/s)
*Gen3 signaling speed (6.0Gb/s)
*Native Command Queueing (NCQ)
*Phy event counters
*READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
DMA Setup Auto-Activate optimization
*Device-initiated interface power management
*Software settings preservation
*reserved 69[4]
*DOWNLOAD MICROCODE DMA command
*SET MAX SETPASSWORD/UNLOCK DMA commands
*WRITE BUFFER DMA command
*READ BUFFER DMA command
*Data Set Management TRIM supported (limit 8 blocks)
Logical Unit WWN Device Identifier: 5002538d
NAA : 5
IEEE OUI: 002538
Unique ID : d
Checksum: correct
Re: [PATCH] [RFC] target/file: add support of direct and async I/O
On 3/8/18 6:42 PM, Andrei Vagin wrote: > Direct I/O allows to not affect the write-back cache, this is > expected when a non-buffered mode is used. > > Async I/O allows to handle a few commands concurrently, so a target shows a > better perfomance: > > Mode: O_DSYNC Async: 1 > $ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 > --name=/dev/sda --runtime=20 --numjobs=2 > WRITE: bw=45.9MiB/s (48.1MB/s), 21.9MiB/s-23.0MiB/s (22.0MB/s-25.2MB/s), > io=919MiB (963MB), run=20002-20020msec > > Mode: O_DSYNC Async: 0 > $ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 > --name=/dev/sdb --runtime=20 --numjobs=2 > WRITE: bw=1607KiB/s (1645kB/s), 802KiB/s-805KiB/s (821kB/s-824kB/s), > io=31.8MiB (33.4MB), run=20280-20295msec > > Known issue: > > DIF (PI) emulation doesn't work when a target uses async I/O, because > DIF metadata is saved in a separate file, and it is another non-trivial > task how to synchronize writing in two files, so that a following read > operation always returns a consisten metadata for a specified block. > > Cc: "Nicholas A. Bellinger" > Signed-off-by: Andrei Vagin > --- > drivers/target/target_core_file.c | 124 > -- > drivers/target/target_core_file.h | 1 + > 2 files changed, 120 insertions(+), 5 deletions(-) > > Tested-by: Bryant G. Ly Patch looks good to me - Thanks for the performance enhancement! Btw I have been running I/O tests with HTX against this patch for 24 hrs and have no problems. -Bryant
Re: [PATCH v2 01/13] qla2xxx: Remove unneeded message and minor cleanup for FC-NVMe
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 02/13] qla2xxx: Set IIDMA and fcport state before qla_nvme_register_remote()
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 03/13] qla2xxx: Add changes for devloss timeout in driver
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 04/13] qla2xxx: Restore ZIO threshold setting
I'd really appreciate a more verbose changelog. No only on this patch, but in general. Anyways, Reviewed-by: Johannes Thumshirn -- 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 v2 06/13] qla2xxx: Fix n2n_ae flag to prevent dev_loss on PDB change
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 05/13] qla2xxx: Add FC-NVMe abort processing
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 07/13] qla2xxx: Return busy if rport going away
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 08/13] qla2xxx: Remove nvme_done_list
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 09/13] qla2xxx: Fix retry for PRLI RJT with reason of BUSY
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 10/13] qla2xxx: Fix FC-NVMe IO abort during driver reset
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 11/13] qla2xxx: Cleanup code to improve FC-NVMe error handling
Looks good, Reviewed-by: Johannes Thumshirn -- 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 v2 13/13] qla2xxx: Update driver version to 10.00.00.06-k
Looks good, Reviewed-by: Johannes Thumshirn -- 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: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
(Sorry, accidentally dropped the lists. Adding it back & re-posting my off-list response.) On Thu, Mar 15, 2018 at 04:05:53PM +0100, Kashyap Chamarthy wrote: > On Thu, Mar 15, 2018 at 03:33:46PM +0100, Douglas Gilbert wrote: > > On 2018-03-15 02:44 PM, Douglas Gilbert wrote: > > > On 2018-03-15 01:45 PM, Martin K. Petersen wrote: > > > > > > > > Kashyap, > > > > > > > > > /me naively wonders if it has anything to do with accessing it via > > > > > Linux. > > > > > > > > I'm guessing that the drive doesn't actually support SCSI UNMAP. I have > > > > a T3 that reports all the right things in the bl/lbpv VPD pages but also > > > > has lbpme set to 0. > > > > > > > > Interestingly enough, my T3 does appear to be a regular SATA drive > > > > behind a USB bridge. Have you tried to issue a DSM TRIM command via ATA > > > > passthrough? > > > > > > hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS > > > OPTION!!" in its manpage :-) > > Hehe, near as I see, that's dangerous only if you have data on the disk. > > This is an empty SSD that I haven't put any data in it, I should remind. > :-) In that case, I'll assume it is "safe" to tinker with the above. > > > IOWs, using Mark Lord's example: > >hdparm --trim-sector-ranges 1000:4 /dev/sdz > > > > That will attempt to trim lba 1000, 1001, 1002 and 1003 on /dev/sdz > > Thanks; I should first educate myself more on this before I tinker with > the above. One Ubuntu wiki page claims: "To wipe out contents of an SSD, > SATA secure erase is the way to go", and '--trim-sector-ranges' is only > "experimental and for benchmarking purpose". > > Just to recap: My goal is to clean (insofar as possible) the SSD of all > and any / all pre-loaded programs & re-claim space. > > --- > > Related: The ATA Secure Erase wiki page claims[*] if you do it (Secure > Erase) via USB interface, you might brick the SSD. I'm using the > 'Thunderbolt' interface, and the said wiki page doesn't say anything > useful about it. > > > [*] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase > > > -- > /kashyap -- /kashyap
Re: Debugging SCSI 'UNMAP' ("Logical Block Provisioning") failure on an SSD
On Thu, Mar 15, 2018 at 04:46:30PM +0100, Kashyap Chamarthy wrote: > (Sorry, accidentally dropped the lists. Adding it back & re-posting my > off-list response.) (Now add the missing linux-...@vger.kernel.org list for real. Not trimming the full e-mail intentionally as I missed to Cc 'linux-usb'.) > On Thu, Mar 15, 2018 at 04:05:53PM +0100, Kashyap Chamarthy wrote: > > On Thu, Mar 15, 2018 at 03:33:46PM +0100, Douglas Gilbert wrote: > > > On 2018-03-15 02:44 PM, Douglas Gilbert wrote: > > > > On 2018-03-15 01:45 PM, Martin K. Petersen wrote: > > > > > > > > > > Kashyap, > > > > > > > > > > > /me naively wonders if it has anything to do with accessing it via > > > > > > Linux. > > > > > > > > > > I'm guessing that the drive doesn't actually support SCSI UNMAP. I > > > > > have > > > > > a T3 that reports all the right things in the bl/lbpv VPD pages but > > > > > also > > > > > has lbpme set to 0. > > > > > > > > > > Interestingly enough, my T3 does appear to be a regular SATA drive > > > > > behind a USB bridge. Have you tried to issue a DSM TRIM command via > > > > > ATA > > > > > passthrough? > > > > > > > > hdparm can do that. Look for "EXCEPTIONALLY DANGEROUS. DO NOT USE THIS > > > > OPTION!!" in its manpage :-) > > > > Hehe, near as I see, that's dangerous only if you have data on the disk. > > > > This is an empty SSD that I haven't put any data in it, I should remind. > > :-) In that case, I'll assume it is "safe" to tinker with the above. > > > > > IOWs, using Mark Lord's example: > > >hdparm --trim-sector-ranges 1000:4 /dev/sdz > > > > > > That will attempt to trim lba 1000, 1001, 1002 and 1003 on /dev/sdz > > > > Thanks; I should first educate myself more on this before I tinker with > > the above. One Ubuntu wiki page claims: "To wipe out contents of an SSD, > > SATA secure erase is the way to go", Never mind about "secure erase", even trying to set password via `hdparm' for this T5 SSD (still connected via 'Thunderbolt'): $> hdparm --user-master u --security-set-pass $SECRET /dev/sdc Fails with the unactionable & useless error: "SECURITY_SET_PASS: Input/output error" > > and '--trim-sector-ranges' is only > > "experimental and for benchmarking purpose". > > > > Just to recap: My goal is to clean (insofar as possible) the SSD of all > > and any / all pre-loaded programs & re-claim space. > > > > --- > > > > Related: The ATA Secure Erase wiki page claims[*] if you do it (Secure > > Erase) via USB interface, you might brick the SSD. I'm using the > > 'Thunderbolt' interface, and the said wiki page doesn't say anything > > useful about it. > > > > > > [*] https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase -- /kashyap
Re: [PATCHv3 2/4] myrb: Add Mylex RAID controller (block interface)
Hi Christoph,
Thanks for the review!
I know it's a pain
On 03/15/2018 09:37 AM, Christoph Hellwig wrote:
>> +#define myrb_logical_channel(shost) ((shost)->max_channel - 1)
>
> inline function, please.
>
>> +/*
>> + * myrb_exec_cmd executes V1 Command and waits for completion.
>> + */
>> +
>> +static void myrb_exec_cmd(myrb_hba *cb, myrb_cmdblk *cmd_blk)
>> +{
>> +DECLARE_COMPLETION_ONSTACK(Completion);
>> +unsigned long flags;
>> +
>> +cmd_blk->Completion = &Completion;
>> +
>> +spin_lock_irqsave(&cb->queue_lock, flags);
>> +cb->qcmd(cb, cmd_blk);
>> +spin_unlock_irqrestore(&cb->queue_lock, flags);
>> +
>> +if (in_interrupt())
>> +return;
>> +wait_for_completion(&Completion);
>> +}
>
> This interface looks completely bogus as it silently does something
> else if in_interrupt() is true. As far as I can tell from a quick
> scan it never even is called from interrupt context and all callers
> expect to get a status back, so it should be changed to just
> a WARN_ON for the in_interrupt case.
>
I guess we can just drop this check.
> And to avoid some boiler plate code it could just return
> cmd_blk->status as the return value.
>
Ok.
>> +
>> +/*
>> + myrb_exec_type3 executes a DAC960 V1 Firmware Controller Type 3
>> + Command and waits for completion.
>> +*/
>> +
>> +static unsigned short myrb_exec_type3(myrb_hba *cb,
>> + myrb_cmd_opcode op,
>> + dma_addr_t addr)
>
> Why the empty lines before the description and function? Also
> Please use normal Linux block comment style instead of this weird
> style.
>
Copied over from the original driver.
Will be changing it.
>> +dma_free_coherent(&cb->pdev->dev, sizeof(myrb_log_entry),
>> + ev_buf, ev_addr);
>> +return;
>> +}
>
> No need for an empty return statement at the end of a function.
>
>> +if ((new_entry->parity_err != old_entry->parity_err) ||
>> +(new_entry->soft_err != old_entry->soft_err) ||
>> +(new_entry->hard_err != old_entry->hard_err) ||
>> +(new_entry->misc_err !=
>> + old_entry->misc_err))
>
> No need for any of the inner braces.
>
>> +mbox->Type3.addr = rbld_addr;
>> +myrb_exec_cmd(cb, cmd_blk);
>> +status = cmd_blk->status;
>> +if (status == DAC960_V1_NormalCompletion) {
>> +unsigned int ldev_num = rbld_buf->ldev_num;
>> +unsigned int ldev_size = rbld_buf->ldev_size;
>> +unsigned int blocks_done =
>> +ldev_size - rbld_buf->blocks_left;
>> +struct scsi_device *sdev;
>> +
>> +sdev = scsi_device_lookup(cb->host,
>> + myrb_logical_channel(cb->host),
>> + ldev_num, 0);
>
> This seems to leak the scsi_device.
>
True.
>> +if ((new->ldev_critical > 0 ||
>> + new->ldev_critical != old.ldev_critical) ||
>> +(new->ldev_offline > 0 ||
>> + new->ldev_offline != old.ldev_offline) ||
>> +(new->ldev_count != old.ldev_count)) {
>
> no need for the inner braces here as-is, but the logic looks broken to
> me as well. Shouldn't the inner ||s be &&s?
>
I tried to do some fancy computation (only display a change if the
device actually _is_ broken), but then we do want to display a change
from a broken/failed device to a working one, too.
So yeah, it should be &&s.
>> +if ((new->pdev_dead > 0 ||
>> + new->pdev_dead != old.pdev_dead) ||
>
> Same here.
>
No, here the '||' is actually okay, as we only want to update the bgi
status for dead devices.
(I think ...)
>> +static sssize_t myrb_show_dev_level(struct device *dev,
>> +struct device_attribute *attr, char *buf)
>
> Two tab indentation for prototype continuations, please.
>
>> +myrb_hba *myrb_alloc_host(struct pci_dev *pdev,
>> + const struct pci_device_id *entry)
>
> static? Or even bettetr just merge into the caller.
>
>> +{
>> +struct Scsi_Host *shost;
>> +myrb_hba *cb;
>> +
>> +shost = scsi_host_alloc(&myrb_template, sizeof(myrb_hba));
>> +if (!shost)
>> +return NULL;
>> +
>> +cb = (myrb_hba *)shost->hostdata;
>
> Use shost_priv(), please.
>
>> +bool myrb_err_status(myrb_hba *cb, unsigned char error,
>> + unsigned char parm0, unsigned char parm1)
>
> static for all functions, please.
>
>> +static void myrb_remove(struct pci_dev *pdev)
>> +{
>> +myrb_hba *cb = pci_get_drvdata(pdev);
>> +
>> +if (cb == NULL)
>> +return;
>
> Can't happen.
>
>> +static const struct pci_device_id myrb_id_table[] = {
>> +{
>> +.vendor = PCI_VENDOR_ID_DEC,
>> +.device = PCI_DEVICE_ID_DEC_21285,
>> +.subvendor = PCI_VENDOR_ID_MYLEX,
>
Re: [PATCH] [RFC] target/file: add support of direct and async I/O
On Thu, Mar 15, 2018 at 09:26:57AM -0500, Bryant G. Ly wrote: > On 3/8/18 6:42 PM, Andrei Vagin wrote: > > > Direct I/O allows to not affect the write-back cache, this is > > expected when a non-buffered mode is used. > > > > Async I/O allows to handle a few commands concurrently, so a target shows a > > better perfomance: > > > > Mode: O_DSYNC Async: 1 > > $ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 > > --name=/dev/sda --runtime=20 --numjobs=2 > > WRITE: bw=45.9MiB/s (48.1MB/s), 21.9MiB/s-23.0MiB/s (22.0MB/s-25.2MB/s), > > io=919MiB (963MB), run=20002-20020msec > > > > Mode: O_DSYNC Async: 0 > > $ ./fio --bs=4K --direct=1 --rw=randwrite --ioengine=libaio --iodepth=64 > > --name=/dev/sdb --runtime=20 --numjobs=2 > > WRITE: bw=1607KiB/s (1645kB/s), 802KiB/s-805KiB/s (821kB/s-824kB/s), > > io=31.8MiB (33.4MB), run=20280-20295msec > > > > Known issue: > > > > DIF (PI) emulation doesn't work when a target uses async I/O, because > > DIF metadata is saved in a separate file, and it is another non-trivial > > task how to synchronize writing in two files, so that a following read > > operation always returns a consisten metadata for a specified block. > > > > Cc: "Nicholas A. Bellinger" > > Signed-off-by: Andrei Vagin > > --- > > drivers/target/target_core_file.c | 124 > > -- > > drivers/target/target_core_file.h | 1 + > > 2 files changed, 120 insertions(+), 5 deletions(-) > > > > > Tested-by: Bryant G. Ly > > Patch looks good to me - Thanks for the performance enhancement! > > Btw I have been running I/O tests with HTX against this patch for 24 hrs and > have no problems. Bryant, thank you for the feedback. > > -Bryant >
[PATCH resend] scsi: devinfo: add HP DISK-SUBSYSTEM device, for HP XP arrays
"The DISK-SUBSYSTEM is a special model name returned when LUs
are not installed. For example, when LU#0 is not installed in "OPEN-"
models, LU#0 is detected as the DISK-SUBSYSTEM model":
https://marc.info/?l=linux-scsi&m=125424006417825
It's missing for HP XP rebranded arrays, "HP"/"OPEN-".
Only the HITACHI one is present:
13f7e5acc8b329080672c13f05f252ace5b79825
627511e3e67553b04f6917c03e39b797df210e04
Cc: Anthony Cheung
Cc: Takahiro Yasui
Cc: Matthias Rudolph
Cc: Martin K. Petersen
Cc: James E.J. Bottomley
Cc: SCSI ML
Signed-off-by: Xose Vazquez Perez
---
drivers/scsi/scsi_devinfo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index f3b117246d47..4a2d276c42eb 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -189,6 +189,7 @@ static struct {
{"HP", "C5713A", NULL, BLIST_NOREPORTLUN},
{"HP", "DF400", "*", BLIST_REPORTLUN2},
{"HP", "DF500", "*", BLIST_REPORTLUN2},
+ {"HP", "DISK-SUBSYSTEM", "*", BLIST_REPORTLUN2},
{"HP", "OP-C-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "3380-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "3390-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
--
2.14.3
Re: [PATCH] scsi: scsi_transport_iscsi: use put_device() instead of kfree()
On Wed, Mar 07, 2018 at 05:07:33PM +0530, Arvind Yadav wrote: > Never directly free @dev after calling device_register(), even > if it returned an error! Always use put_device() to give up the > reference initialized. > > Signed-off-by: Arvind Yadav > --- > drivers/scsi/scsi_transport_iscsi.c | 27 +-- > 1 file changed, 13 insertions(+), 14 deletions(-) > > @@ -783,7 +781,7 @@ struct iscsi_iface * > > free_iface: > put_device(iface->dev.parent); > - kfree(iface); > + put_device(&iface->dev); > return NULL; > } > EXPORT_SYMBOL_GPL(iscsi_create_iface); Am I reading the device code correctly that the parent reference is only released in the unregister path (device_unregister calls device_del) and so the manual put_device on the parent here is still correct? Just want to make sure that's still needed with the call to put_device. Other than that question, I this all looks good. Thanks. Signed-off-by: Chris Leech
CONTACT DHL OFFICE IMMEDIATELY FOR DELIVERY OF YOUR ATM MASTERCARD
Attention; Beneficiary, This is to official inform you that we have been having meetings for the past three (3) weeks which ended two days ago with MR. JIM YONG KIM the Former world bank president and other seven continent presidents on the congress we treated on solution to scam victim problems. Note: we have decided to contact you following the reports we received from anti-fraud international monitoring group your name/email has been submitted to us therefore the united nations have agreed to compensate you with the sum of (USD$1.5 Million) this compensation is also including international business that failed you in past due to government problems etc. We have arranged your payment through our ATM MasterCard and deposited it in DHL Office to deliver it to you which is the latest instruction from the Former World Bank president MR. JIM YONG KIM, For your information’s, the delivery charges already paid by U.N treasury, the only money you will send to DHL office Benin Republic is $225 dollars for security keeping fee, U.N coordinator already paid for others charges fees for delivery except the security keeping fee, the director of DHL refused to collect the security keeping fee from U.N treasury because Direct of DHL office said they don’t know exactly time you will contact them to reconfirm your details to avoid counting demurrage. Therefore be advice to contact DHL Office agent Benin. Rev:TONY harries who is in position to post your ATM MasterCard, contact DHL Office immediately with the bellow email & phone number as listed below. Contact name: Rev:Tony HARRIES Email:(post.dhlbenin.serv...@outlook.com ) Tell: +229-98787436 Make sure you reconfirmed DHL Office your details ASAP as stated below to avoid wrong delivery. Your full name.. Home address:. Your country... Your city.. Telephone.. Occupation:... Age:…….. Let us know as soon as possible you receive your ATM MasterCard for proper verifications. Regards, MR Paul Ogie. DEPUTY SECRETARY-GENERAL (U.N) Benin Republic.
[PATCH] scsi: devinfo: remove DF arrays from HP
Matthias did confirm that there are no such devices.
Cc: Matthias Rudolph
Cc: Anthony Cheung
Cc: Takahiro Yasui
Cc: Mike Christie
Cc: Martin K. Petersen
Cc: James E.J. Bottomley
Cc: SCSI ML
Cc: device-mapper development
Signed-off-by: Xose Vazquez Perez
---
drivers/scsi/scsi_devinfo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index f3b117246d47..b119b5bfb4d3 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -187,8 +187,6 @@ static struct {
{"HP", "C1557A", NULL, BLIST_FORCELUN},
{"HP", "C3323-300", "4269", BLIST_NOTQ},
{"HP", "C5713A", NULL, BLIST_NOREPORTLUN},
- {"HP", "DF400", "*", BLIST_REPORTLUN2},
- {"HP", "DF500", "*", BLIST_REPORTLUN2},
{"HP", "OP-C-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "3380-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
{"HP", "3390-", "*", BLIST_SPARSELUN | BLIST_LARGELUN},
--
2.14.3
Re: [PATCH] scsi: iscsi_tcp: set BDI_CAP_STABLE_WRITES when data digest enabled
On Wed, Mar 07, 2018 at 08:29:03PM +0800, Jianchao Wang wrote:
> iscsi tcp will first send out data, then calculate and send data
> digest. If we don't have BDI_CAP_STABLE_WRITES, the page cache will
> be written in spite of the on going writeback. Consequently, wrong
> digest will be got and sent to target.
>
> To fix this, set BDI_CAP_STABLE_WRITES when data digest is enabled
> in iscsi_tcp .slave_configure callback.
>
> Signed-off-by: Jianchao Wang
> ---
> drivers/scsi/iscsi_tcp.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index 6198559..261c686 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -37,6 +37,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -954,6 +955,12 @@ static int iscsi_sw_tcp_slave_alloc(struct scsi_device
> *sdev)
>
> static int iscsi_sw_tcp_slave_configure(struct scsi_device *sdev)
> {
> + struct iscsi_sw_tcp_host *tcp_sw_host = iscsi_host_priv(sdev->host);
> + struct iscsi_session *session = tcp_sw_host->session;
> + struct iscsi_conn *conn = session->leadconn;
> +
> + if (conn->datadgst_en)
> + sdev->request_queue->backing_dev_info->capabilities |=
> BDI_CAP_STABLE_WRITES;
> blk_queue_bounce_limit(sdev->request_queue, BLK_BOUNCE_ANY);
> blk_queue_dma_alignment(sdev->request_queue, 0);
> return 0;
> --
Thanks for fixing this issue with data digests!
Signed-off-by: Chris Leech
CONTACT DHL OFFICE IMMEDIATELY FOR DELIVERY OF YOUR ATM MASTERCARD
Attention; Beneficiary, This is to official inform you that we have been having meetings for the past three (3) weeks which ended two days ago with MR. JIM YONG KIM the Former world bank president and other seven continent presidents on the congress we treated on solution to scam victim problems. Note: we have decided to contact you following the reports we received from anti-fraud international monitoring group your name/email has been submitted to us therefore the united nations have agreed to compensate you with the sum of (USD$1.5 Million) this compensation is also including international business that failed you in past due to government problems etc. We have arranged your payment through our ATM MasterCard and deposited it in DHL Office to deliver it to you which is the latest instruction from the Former World Bank president MR. JIM YONG KIM, For your information’s, the delivery charges already paid by U.N treasury, the only money you will send to DHL office Benin Republic is $225 dollars for security keeping fee, U.N coordinator already paid for others charges fees for delivery except the security keeping fee, the director of DHL refused to collect the security keeping fee from U.N treasury because Direct of DHL office said they don’t know exactly time you will contact them to reconfirm your details to avoid counting demurrage. Therefore be advice to contact DHL Office agent Benin. Rev:Tony harries who is in position to post your ATM MasterCard, contact DHL Office immediately with the bellow email & phone number as listed below. Contact name: Rev:Tony HARRIES Email:(post.dhlbenin.serv...@outlook.com ) Tell: +229-98787436 Make sure you reconfirmed DHL Office your details ASAP as stated below to avoid wrong delivery. Your full name.. Home address:. Your country... Your city.. Telephone.. Occupation:... Age:…….. Let us know as soon as possible you receive your ATM MasterCard for proper verifications. Regards, MR Paul Ogie. DEPUTY SECRETARY-GENERAL (U.N) Benin Republic.
[PATCH] storvsc: Set up correct queue depth values for IDE devices
From: Long Li Unlike SCSI and FC, we don't use multiple channels for IDE. So set queue depth correctly for IDE. Also set the correct cmd_per_lun for all devices. Signed-off-by: Long Li --- drivers/scsi/storvsc_drv.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index 8c51d628b52e..fba170640e9c 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1722,15 +1722,19 @@ static int storvsc_probe(struct hv_device *device, max_targets = STORVSC_MAX_TARGETS; max_channels = STORVSC_MAX_CHANNELS; /* -* On Windows8 and above, we support sub-channels for storage. +* On Windows8 and above, we support sub-channels for storage +* on SCSI and FC controllers. * The number of sub-channels offerred is based on the number of * VCPUs in the guest. */ - max_sub_channels = (num_cpus / storvsc_vcpus_per_sub_channel); + if (!dev_is_ide) + max_sub_channels = + num_cpus / storvsc_vcpus_per_sub_channel; } scsi_driver.can_queue = (max_outstanding_req_per_channel * (max_sub_channels + 1)); + scsi_driver.cmd_per_lun = scsi_driver.can_queue; host = scsi_host_alloc(&scsi_driver, sizeof(struct hv_host_device)); -- 2.14.1
Re: [PATCH] storvsc: Set up correct queue depth values for IDE devices
On Thu, 15 Mar 2018 16:52:23 -0700 Long Li wrote: > From: Long Li > > Unlike SCSI and FC, we don't use multiple channels for IDE. So set queue depth > correctly for IDE. > > Also set the correct cmd_per_lun for all devices. > > Signed-off-by: Long Li Looks correct. Acked-by: Stephen Hemminger
[no subject]
Schönen Tag:Bist du in finanziellen Schwierigkeiten? Brauchen Sie einen Kredit mit einem niedrigen Zinssatz? Wenn ja, kontaktieren Sie uns jetzt mitIhr Name:Land:Darlehensbetrag:Telefonnummer:Darlehens Dauer:Staat:Sex:Beruf:Monatliches Einkommen:Alter:Privatadresse:
