Re: [PATCH] aic7xxx: Remove redundant NULL check before kfree
On Wed, 2013-03-06 at 00:56 +0530, Syam Sidhardhan wrote: kfree on NULL pointer is a no-op. This is true, but what's the saving? kfree() has an identical check, but by the time you get to it, the result of this one is cached, so it's something like 1 instruction cycle saving (because the instruction will be pipelined). If the maintainers of particular drivers want to integrate this, that's OK, but I'd rather not do pure code churn on the older drivers. James -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Carbide Tools for Dental Industry
Dear General Manager:
Trading here, exporting dental lab carbide tool with good quality and
reasonable price.
Looking forward to hearing from you soon
--
Cynthia Dong
Sales department
Email:
cynt...@wilsonprecisiontool.comn�Р骒r��yb�X�肚�v�^�)藓{.n�+�伐�{北��{ay� �,j��f＂�h���z� �wア�
⒎�j:+v���w�j�m��赙zZ+�茛j��!�i
lsscsi and sg3_utils betas for testing 64 bit LUNs
To facilitate testing Linux 64 bit LUNs (the kernel holds only 32 bit LUNs internally at the moment), I have put up beta versions of lsscsi and the sg3_utils packages, see the top of this page: http://sg.danny.cz/sg/ lsscsi version 0.27 (beta 1) adds a --lunhex (-x) option, here is an example of its use: # lsscsi -gs [0:0:0:0]diskATA INTEL SSDSC2CW12 400i /dev/sda /dev/sg0 [7:0:0:1]diskLinuxscsi_debug 0004 /dev/sdb /dev/sg1 [7:0:0:49409]wlunLinuxscsi_debug 0004 - /dev/sg2 # lsscsi -g --lunhex [0:0:0:0x] diskATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001] diskLinuxscsi_debug 0004 /dev/sdb [7:0:0:0xc101] wlunLinuxscsi_debug 0004 - # lsscsi -xx [0:0:0:0x] diskATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001] diskLinuxscsi_debug 0004 /dev/sdb [7:0:0:0xc101] wlunLinuxscsi_debug 0004 - Additionally if sysfs offers a 64 bit (unsigned) integer in decimal for a LUN then this version will use it (previous lsscsi versions would have truncated the LUN to 32 bits). In the sg3_utils beta the sg_luns utility is expanded to better handle T10 (SAM-5) LUNs and represent them in Linux 'word flipped' form if requested. sg_luns has an additional --test=LUNHEX option that can be used for decoding arbitrary T10 LUNs, for example: # sg_luns --test=020304aa01bb00ff Decoded LUN: Peripheral device addressing: bus_id=2, target=3 Second level addressing: Peripheral device addressing: bus_id=4, target=170 Third level addressing: Peripheral device addressing: bus_id=1, target=187 Fourth level addressing: Peripheral device addressing: lun=255 # sg_luns --test=020304aa01bb00ff -H Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03 Second level addressing: Peripheral device addressing: bus_id=0x04, target=0xaa Third level addressing: Peripheral device addressing: bus_id=0x01, target=0xbb Fourth level addressing: Peripheral device addressing: lun=0xff # sg_luns --test=020304aa01bb00ffL -H Linux 'word flipped' integer LUN representation: 0xff01bb04aa0203 Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03 Second level addressing: Peripheral device addressing: bus_id=0x04, target=0xaa Third level addressing: Peripheral device addressing: bus_id=0x01, target=0xbb Fourth level addressing: Peripheral device addressing: lun=0xff Now I'm hoping Hannes Reinecke will issue a new set of the scsi: 64-bit LUN support patches that address the issues that have been brought up. Then the real testing can begin. Doug Gilbert -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: lsscsi and sg3_utils betas for testing 64 bit LUNs
On 13-03-06 10:10 AM, Douglas Gilbert wrote: To facilitate testing Linux 64 bit LUNs (the kernel holds only 32 bit LUNs internally at the moment), I have put up beta versions of lsscsi and the sg3_utils packages, see the top of this page: http://sg.danny.cz/sg/ lsscsi version 0.27 (beta 1) adds a --lunhex (-x) option, here is an example of its use: # lsscsi -gs Last second edits; the invocation line should be 'lsscsi -g' [0:0:0:0]diskATA INTEL SSDSC2CW12 400i /dev/sda /dev/sg0 [7:0:0:1]diskLinuxscsi_debug 0004 /dev/sdb /dev/sg1 [7:0:0:49409]wlunLinuxscsi_debug 0004 - /dev/sg2 # lsscsi -g --lunhex And the invocation here should be 'lsscsi --lunhex' What is happening is that redundant zeros to the right (according to the T10 LUN definition) of the LUN are dropped to lessen the clutter. When --lunhex is used twice (or -xx) then the whole 16 hex digits are output: [0:0:0:0x] diskATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001] diskLinuxscsi_debug 0004 /dev/sdb [7:0:0:0xc101] wlunLinuxscsi_debug 0004 - # lsscsi -xx [0:0:0:0x] diskATA INTEL SSDSC2CW12 400i /dev/sda [7:0:0:0x0001] diskLinuxscsi_debug 0004 /dev/sdb [7:0:0:0xc101] wlunLinuxscsi_debug 0004 - Additionally if sysfs offers a 64 bit (unsigned) integer in decimal for a LUN then this version will use it (previous lsscsi versions would have truncated the LUN to 32 bits). In the sg3_utils beta the sg_luns utility is expanded to better handle T10 (SAM-5) LUNs and represent them in Linux 'word flipped' form if requested. sg_luns has an additional --test=LUNHEX option that can be used for decoding arbitrary T10 LUNs, for example: # sg_luns --test=020304aa01bb00ff Decoded LUN: Peripheral device addressing: bus_id=2, target=3 Second level addressing: Peripheral device addressing: bus_id=4, target=170 Third level addressing: Peripheral device addressing: bus_id=1, target=187 Fourth level addressing: Peripheral device addressing: lun=255 # sg_luns --test=020304aa01bb00ff -H Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03 Second level addressing: Peripheral device addressing: bus_id=0x04, target=0xaa Third level addressing: Peripheral device addressing: bus_id=0x01, target=0xbb Fourth level addressing: Peripheral device addressing: lun=0xff The trailing L on that hex number requests the Linux LUN representation. And if -H was given twice the Linux word flipped integer would be 0x00ff01bb04aa0203 . # sg_luns --test=020304aa01bb00ffL -H Linux 'word flipped' integer LUN representation: 0xff01bb04aa0203 Decoded LUN: Peripheral device addressing: bus_id=0x02, target=0x03 Second level addressing: Peripheral device addressing: bus_id=0x04, target=0xaa Third level addressing: Peripheral device addressing: bus_id=0x01, target=0xbb Fourth level addressing: Peripheral device addressing: lun=0xff Now I'm hoping Hannes Reinecke will issue a new set of the scsi: 64-bit LUN support patches that address the issues that have been brought up. Then the real testing can begin. And finally a question, if a target had a lot of LUNs then the sorting order will help finding one in a long list. So what sorting order should 64 bit LUNs have? Doug Gilbert -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] mptfusion, mpt2sas, mpt3sas: Don't remove dead IOC PCI device
Please reject this Patch. I have made required changes which will remove PCI system's call from mptsas/mpt2sas/mpt3sas. I will be sending that patch to upstream. Currently waiting to do more testing on new patch. Thanks for constructive feedback. ` Kashyap -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Desai, Kashyap Sent: Wednesday, March 06, 2013 8:39 AM To: Bjorn Helgaas Cc: Joe Lawrence; linux-scsi@vger.kernel.org; DL-MPT Fusion Linux; Support; Reddy, Sreekanth; Nandigama, Nagalakshmi; James E.J. Bottomley; linux-...@vger.kernel.org Subject: RE: [PATCH 1/2] mptfusion, mpt2sas, mpt3sas: Don't remove dead IOC PCI device -Original Message- From: Bjorn Helgaas [mailto:bhelg...@google.com] Sent: Wednesday, March 06, 2013 7:55 AM To: Desai, Kashyap Cc: Joe Lawrence; linux-scsi@vger.kernel.org; DL-MPT Fusion Linux; Support; Reddy, Sreekanth; Nandigama, Nagalakshmi; James E.J. Bottomley; linux-...@vger.kernel.org Subject: Re: [PATCH 1/2] mptfusion, mpt2sas, mpt3sas: Don't remove dead IOC PCI device On Tue, Mar 5, 2013 at 6:46 PM, Desai, Kashyap kashyap.de...@lsi.com wrote: -Original Message- From: Bjorn Helgaas [mailto:bhelg...@google.com] Sent: Wednesday, March 06, 2013 4:43 AM To: Desai, Kashyap Cc: Joe Lawrence; linux-scsi@vger.kernel.org; DL-MPT Fusion Linux; Support; Reddy, Sreekanth; Nandigama, Nagalakshmi; James E.J. Bottomley; linux-...@vger.kernel.org Subject: Re: [PATCH 1/2] mptfusion, mpt2sas, mpt3sas: Don't remove dead IOC PCI device [+cc linux-pci] On Mon, Mar 4, 2013 at 11:02 AM, Desai, Kashyap kashyap.de...@lsi.com wrote: -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of Joe Lawrence Sent: Monday, March 04, 2013 9:26 PM To: linux-scsi@vger.kernel.org Cc: DL-MPT Fusion Linux; Support; Reddy, Sreekanth; Nandigama, Nagalakshmi; James E.J. Bottomley; Bjorn Helgaas Subject: [PATCH 1/2] mptfusion, mpt2sas, mpt3sas: Don't remove dead IOC PCI device Device removal/addition is a PCI core function, not an HBA function. Calling pci_stop_and_remove_bus_device() from a SCSI LLD may introduce device removal races with PCI hotplug. Remove these calls from mptfusion, mpt2sas, and mpt3sas, but leave remaining dead IOC code in place that flushes outstanding commands and sets IOC state. Joe: I agree that only mptsas/mpt2sas/mpt3sas is calling pci_stop_and_remove_bus_device from LLD. If through sysfs we can hot add/remove the device, It would be OK to allow similar simulation from LLD. (In case it is really require.) I agree that calling pci_stop_and_remove_bus_device is PCI subsystem's responsibility. Please consider that finding bad IOC on field is very rare. In our case, user wants BAD IOC to be detected immediately (due to performance and mission critical IOs) and it should be removed from the topology ASAP to allow other good IOC and connected topology to work well. It doesn't matter how rare bad IOCs are. But I certainly agree that when we do find a bad IOC, we want to detect it and stop using it as soon as possible. With the new proposed change you posted with this patch half of the problem still do not resolve. Driver set ioc-remove_host = 1 when bad IOC is detected, but IOs to the connected topology will still continue to flood ( if we do not detach bad IOC from topology) and Scsi Mid layer be busy sending inactive IOs to the bad IOC, and IOs will be return to the OS with DID_NO_CONNECT. So finally to release the topology from BAD IOC from OS is also equally important. This can be achieved either calling .remove entry point or what currently driver is doing remove the IOC from PCI layer which will allow better cleanup. Joe's patch remove the call to pci_stop_and_remove_bus_device(), so the IOC will remain attached to the driver. What if he *did* call the driver's . remove() method instead of calling pci_stop_and_remove_bus_device()? Would that resolve your concern? If not, why not? I initially tried using Driver's .remove call instead of pci_stop_and_remove_bus_device, but found inconsistent view from PCI layer and LLD will have its own disadvantage. With that approach, PCI layer sill observe the bad HBA, but instance of the same is not visible at LLD. What's the problem with this? It is not a problem if the PCI device exists but no driver has claimed it. That situation exists very often, when the PCI core has enumerated a device but we haven't loaded a driver for it. Finally, when someone try to remove module/Do some manual PCI bus scan through sysfs functionality etc, LLD will not be able to handle
Re: [PATCH 1/2] mptfusion, mpt2sas, mpt3sas: Don't remove dead IOC PCI device
On Wed, 6 Mar 2013 12:01:37 -0500 Desai, Kashyap kashyap.de...@lsi.com wrote: Please reject this Patch. I have made required changes which will remove PCI system's call from mptsas/mpt2sas/mpt3sas. I will be sending that patch to upstream. Currently waiting to do more testing on new patch. Thanks for constructive feedback. ` Kashyap Kashyap, I'll be glad to test your patch against mptsas/mpt2sas LSI hardware here at Stratus with respect to surprise PCI hotplug. Thanks for looking into this. Regards, -- Joe -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v1] lpfc 8.3.37: Remove redundant NULL check before kfree
From: Syam Sidhardhan s.s...@samsung.com kfree on NULL pointer is a no-op. Signed-off-by: Syam Sidhardhan s.s...@samsung.com --- v1- Corrected the from address. drivers/scsi/lpfc/lpfc_bsg.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c index 32d5683..2166097 100644 --- a/drivers/scsi/lpfc/lpfc_bsg.c +++ b/drivers/scsi/lpfc/lpfc_bsg.c @@ -1129,8 +1129,7 @@ lpfc_bsg_hba_set_event(struct fc_bsg_job *job) return 0; /* call job done later */ job_error: - if (dd_data != NULL) - kfree(dd_data); + kfree(dd_data); job-dd_data = NULL; return rc; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] lpfc 8.3.37: Remove redundant NULL check before kfree
Syam, Thank you for the patch - it is valid. However, I prefer not to merge this. I would rather force the coder to think about the pointer value explicitly rather than depending on the convenience/one line optimization. We've had errors in the past covered up by this gracious behavior. Additionally, we have coders that work on linux and vmware, and the semantics of the kfree() routine differ. For now, I'd prefer to stay as is and force good habits. -- james s On 3/6/2013 3:12 PM, syamsidha...@gmail.com wrote: From: Syam Sidhardhan s.s...@samsung.com kfree on NULL pointer is a no-op. Signed-off-by: Syam Sidhardhan s.s...@samsung.com --- v1- Corrected the from address. drivers/scsi/lpfc/lpfc_bsg.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c index 32d5683..2166097 100644 --- a/drivers/scsi/lpfc/lpfc_bsg.c +++ b/drivers/scsi/lpfc/lpfc_bsg.c @@ -1129,8 +1129,7 @@ lpfc_bsg_hba_set_event(struct fc_bsg_job *job) return 0; /* call job done later */ job_error: - if (dd_data != NULL) - kfree(dd_data); + kfree(dd_data); job-dd_data = NULL; return rc; -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND][PATCH] lpfc should check return status for task mgmt IOCBs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ping? Comments, suggestions, rejections for this patch? I understand its a little long, but it seems checking the return status from a task management routine could be considered important. Plus, it helps to bring the behavior in line with the other LLDs. Thanks, Jeremy Linton -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRN7jaAAoJEL5i86xrzcy76+sH/2u9V3GJLCgMSB2LAZDDcpAK 4t+Um2IraIJocFvylckJieoMjhfAMcsc8fJzoxvBNVb7g6NvBQZIh2IbiWhBc2Id 3/t9rA5wdbBMAbIYsoxwY1t6laxkwZxxfP3QI5UDf0e5jcd5hg+RKB6PDOD8wLZ3 tsUsDNDic0agY0WiUpied5qh4feO2e6j6Rkv/3uTFQLWIjqZMUhwZEjVivIbfG/m OWj56HuaHg0CAGq1Gos2ruuzfFuwVr8Eo4SgMlnGQNdENc6R+WbNdzCszKgRCKEt QPULdPQ2/2GCqjweHeY10OzAlAcxNRH8Z2EMbmJRmJltnwMzVHBxluIbH207MaM= =6yaT -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v1] lpfc 8.3.37: Remove redundant NULL check before kfree
If the other approach is taken, then not all kfree() calls are protected by a NULL check. One example in lpfc_els.c (from 3.7-rc5): if (!pbuflist || !pbuflist-virt) goto els_iocb_free_pbuf_exit; ... els_iocb_free_pbuf_exit: if (expectRsp) lpfc_mbuf_free(phba, prsp-virt, prsp-phys); kfree(pbuflist); -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- ow...@vger.kernel.org] On Behalf Of James Smart Sent: Wednesday, 06 March, 2013 3:10 PM To: syamsidha...@gmail.com Cc: linux-scsi@vger.kernel.org; jbottom...@parallels.com; Syam Sidhardhan; Smart, James Subject: Re: [PATCH v1] lpfc 8.3.37: Remove redundant NULL check before kfree Syam, Thank you for the patch - it is valid. However, I prefer not to merge this. I would rather force the coder to think about the pointer value explicitly rather than depending on the convenience/one line optimization. We've had errors in the past covered up by this gracious behavior. Additionally, we have coders that work on linux and vmware, and the semantics of the kfree() routine differ. For now, I'd prefer to stay as is and force good habits. -- james s On 3/6/2013 3:12 PM, syamsidha...@gmail.com wrote: From: Syam Sidhardhan s.s...@samsung.com kfree on NULL pointer is a no-op. Signed-off-by: Syam Sidhardhan s.s...@samsung.com --- v1- Corrected the from address. drivers/scsi/lpfc/lpfc_bsg.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_bsg.c b/drivers/scsi/lpfc/lpfc_bsg.c index 32d5683..2166097 100644 --- a/drivers/scsi/lpfc/lpfc_bsg.c +++ b/drivers/scsi/lpfc/lpfc_bsg.c @@ -1129,8 +1129,7 @@ lpfc_bsg_hba_set_event(struct fc_bsg_job *job) return 0; /* call job done later */ job_error: - if (dd_data != NULL) - kfree(dd_data); + kfree(dd_data); job-dd_data = NULL; return rc; -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
