Assalamualaikum..
I am Mr.Saeed Bin Salem Executive Director and Chief Financial Officer
of the National Commercial Bank Libya.I have a secured business
suggestion for you reply me on my email: saeedbi...@gmail.com
Looks good except for the subject, which will need a little update:
Reviewed-by: Christoph Hellwig
Looks fine,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
On Wed, Aug 30, 2017 at 03:15:11PM +0900, Sergey Senozhatsky wrote:
> Hi,
>
> On (08/30/17 14:43), Byungchul Park wrote:
> [..]
> > > notably slower than earlier 4.13 linux-next. (e.g. scrolling in vim
> > > is irritatingly slow)
> >
> > To Ingo,
> >
> > I cannot decide if we have to roll back C
On Wed, Aug 30, 2017 at 10:42:07AM +0200, Peter Zijlstra wrote:
>
> So the overhead looks to be spread out over all sorts, which makes it
> harder to find and fix.
>
> stack unwinding is done lots and is fairly expensive, I've not yet
> checked if crossrelease does too much of that.
Aah, we do a
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Wednesday, August 30, 2017 5:48 PM
> To: Sergey Senozhatsky
> Cc: Byungchul Park; Bart Van Assche; linux-ker...@vger.kernel.org; linux-
> bl...@vger.kernel.org; martin.peter...@oracle.com; ax...@kernel.dk; lin
Make this const as it is never modified.
Signed-off-by: Bhumika Goyal
---
drivers/scsi/esas2r/esas2r_flash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/esas2r/esas2r_flash.c
b/drivers/scsi/esas2r/esas2r_flash.c
index 7bd376d..f8414b5 100644
--- a/drivers/sc
On 08/29/2017 06:02 PM, Bart Van Assche wrote:
> On Tue, 2017-08-29 at 10:49 +0200, Hannes Reinecke wrote:
>> [ ... ]
>> +$(obj)/scsi_sysfs.o: $(obj)/scsi_devinfo_tbl.c
>> +
>> +quiet_cmd_bflags = GEN $@
>> +cmd_bflags = $(PERL) -s $(src)/mktbl.pl BLIST $< > $@
>
> Hello Hannes,
>
> Is it
The value of "size" comes from the user. When we add "start + size"
it could lead to an integer overflow bug.
It means we vmalloc() a lot more memory than we had intended. I believe
that on 64 bit systems vmalloc() can succeed even if we ask it to
allocate huge 4GB buffers. So we would get memo
Hello Peter,
On (08/30/17 10:47), Peter Zijlstra wrote:
[..]
> On Wed, Aug 30, 2017 at 10:42:07AM +0200, Peter Zijlstra wrote:
> >
> > So the overhead looks to be spread out over all sorts, which makes it
> > harder to find and fix.
> >
> > stack unwinding is done lots and is fairly expensive, I
Hi Martin,
Replied in line.
- I don't understand why you go through all these hoops to decide
whether to use PRPs or IEEE scatterlists. If the firmware translation
is slow, why even bother with the SG format in the first place? Set
the max I/O size to match MDTS and you're done.
=> We wil
On Wed, Aug 30, 2017 at 08:28:52PM +0800, shqking wrote:
> Hi,
>
> Glad to see it is fixed.
>
> Can I apply for a CVE ID for this bug?
>
We don't handle that on this list. You'd need to ask on
oss-secur...@lists.openwall.com.
regards,
dan carpenter
On Wed, Aug 30, 2017 at 03:21:07PM +0300, Dan Carpenter wrote:
> The value of "size" comes from the user. When we add "start + size"
> it could lead to an integer overflow bug.
>
> It means we vmalloc() a lot more memory than we had intended. I believe
> that on 64 bit systems vmalloc() can succ
Since commit 7401bc18d1ee ("scsi: qla2xxx: Add FC-NVMe command handling")
we make use of 'struct nvmefc_fcp_req' in qla24xx_nvme_iocb_entry() without
including linux/nvme-fc-driver.h where it is defined.
Add linux/nvme-fc-driver.h (and scsi/fc/fc_fs.h as nvme-fc-driver.h needs
the definition of 's
On Wed, Aug 30, 2017 at 6:12 AM, Greg KH wrote:
> On Wed, Aug 30, 2017 at 03:21:07PM +0300, Dan Carpenter wrote:
>> The value of "size" comes from the user. When we add "start + size"
>> it could lead to an integer overflow bug.
>>
>> It means we vmalloc() a lot more memory than we had intended.
Three minor fixes: a NULL deref in qedf, an off by one in sg and a fix
to IPR to prevent an error on initialisation.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Brian King (1):
scsi: ipr: Set no_report_opcodes
The value of "size" comes from the user. When we add "start + size"
it could lead to an integer overflow bug.
It means we vmalloc() a lot more memory than we had intended. I believe
that on 64 bit systems vmalloc() can succeed even if we ask it to
allocate huge 4GB buffers. So we would get memo
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Zang Leigang
> Sent: Thursday, August 24, 2017 5:57 AM
> To: vinholika...@gmail.com; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: linux-scsi@vger.kernel.o
Make these const as they are not modified anywhere.
Signed-off-by: Bhumika Goyal
---
To compile-test hpsa.h, I test-compiled scsi/hpsa.c which
includes this file.
drivers/scsi/hpsa.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/hpsa.h b/drivers/scsi/h
Ventura Series controller are Tri-mode. The controller and
firmware are capable of supporting NVMe devices and
PCIe switches to be connected with the controller. This
patch set adds driver level support for NVMe devices and
PCIe switches.
mpt3sas v5 patset:
1) Removed the check to find data transf
1) Added support for probing pcie device and adding NVMe drives to
SML and driver's internal list pcie_device_list.
2) Added support for determing NVMe as boot device.
3) Added nvme device support for call back functions scan_finished
target_alloc,slave_alloc,target destroy and slave destroy.
a
* The controller firmware sends separate events for NVMe devices and
PCIe switches similar to existing SAS events.
* NVMe device detection, addition and removal are reported by the
firmware through PCIe Topology Change list events.
* The PCIe device state change events are sent when the firmware
1) Used variable __le64/__le32 whichever required in
building NVME PRP, which is passed to LE Controller.
2) Remove unused function, Declared functions which are used only
in mpt3sas_scsih.c as static
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_ba
Updated mpt3sas driver version to 15.101.00.00
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
Reviewed-by: Hannes Reinecke
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.h
b/drivers/
Check for NVMe drives before enabling or checking tlr.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
Reviewed-by: Hannes Reinecke
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/mpt3s
* Added debug prints for pcie devices in ioctl debug path. Which
will be helpful for debugging.
* Added PCIe device support for ioctl BTDHMAPPING ioctl.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
Reviewed-by: Hannes Reinecke
---
drivers/scsi/mpt3sas/mpt3sas_ctl.c | 88 +
Added debug information for NVMe/PCIe drives in target rest path.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
Reviewed-by: Hannes Reinecke
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 83 ++--
1 file changed, 70 insertions(+), 13 deletions(-)
diff
After Controller reset, Scan and add nvme device back to the topology.
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
Reviewed-by: Hannes Reinecke
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 194 ++-
1 file changed, 190 insertions(+), 4 deletions(-)
Sets nvme device queue depth, name and displays device capabilities
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpt3sas_base.h | 2 +-
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 50
2 files changed, 51 insertions(+), 1 d
Below API's are included in nvme drive remove path.
_scsih_pcie_device_remove_by_handle
_scsih_pcie_device_remove_from_sml
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
Reviewed-by: Hannes Reinecke
---
drivers/scsi/mpt3sas/mpt3sas_scsih.c | 148 ++-
* Mpt3sas driver uses the NVMe Encapsulated Request message to
send an NVMe command to an NVMe device attached to the IOC.
* Normal I/O commands like reads and writes are passed to the
controller as SCSI commands and the controller has the ability
to translate the commands to NVMe equivalent.
* T
Below Functions are added in various paths to support NVMe
drive addition.
_scsih_pcie_add_device
_scsih_pcie_device_add
_scsih_pcie_device_init_add
_scsih_check_pcie_access_status
_scsih_pcie_check_device
mpt3sas_get_pdev_by_handle
mpt3sas_config_get_pcie_device_pg0
mpt3sas_config_get_pcie_devi
* Added support for translating the SGLs associated with incoming
commands either to IEE SGL or NVMe PRPs for NVMe devices.
* The hardware translation of IEEE SGL to NVMe PRPs has limitation
and if a command cannot be translated by hardware then it will go
to firmware and the firmware needs to tra
Update MPI Files for NVMe support
Signed-off-by: Chaitra P B
Signed-off-by: Suganath Prabu S
---
drivers/scsi/mpt3sas/mpi/mpi2.h | 43 ++-
drivers/scsi/mpt3sas/mpi/mpi2_cnfg.h | 564 +--
drivers/scsi/mpt3sas/mpi/mpi2_init.h | 11 +-
drivers/scsi/mpt3sas/mp
On Tue, 29 Aug 2017 21:31:11 -0400
"Martin K. Petersen" wrote:
> Long,
>
> > When storvsc is sending I/O to Hyper-v, it may allocate a bigger
> > buffer descriptor for large data payload that can't fit into a
> > pre-allocated buffer descriptor. This bigger buffer is freed on return
> > path.
>
On Wed, 2017-08-30 at 12:50 +0200, Hannes Reinecke wrote:
> On 08/29/2017 06:02 PM, Bart Van Assche wrote:
> > On Tue, 2017-08-29 at 10:49 +0200, Hannes Reinecke wrote:
> > > +} sdev_bflags[] = {
> > > +#include "scsi_devinfo_tbl.c"
> > > +};
> > > +
> > > +static const char *sdev_bflags_name(unsig
Hi Jack,
The firmware expectation is that there is no 4 byte CRC. This causes the IOMB
to be generated incorrectly for PHY_START. Local structure for SAS Identify
included in the driver so that it matches the Programmer's Manual and Firmware
expectations.
The sas_identify struct from the kerne
Thanks Jack. We will split this patch as you suggested and send V2.
Regards,
Viswas G
> -Original Message-
> From: Jack Wang [mailto:xjtu...@gmail.com]
> Sent: Tuesday, August 29, 2017 5:16 PM
> To: Viswas G
> Cc: linux-scsi@vger.kernel.org; Vasanthalakshmi Tharmarajan
>
> Subject: Re:
2017-08-30 17:41 GMT+02:00 Viswas G :
> Hi Jack,
>
> The firmware expectation is that there is no 4 byte CRC. This causes the IOMB
> to be generated incorrectly for PHY_START. Local structure for SAS Identify
> included in the driver so that it matches the Programmer's Manual and
> Firmware expe
Thanks. We will move that to pm80xx_hwi.h.
Regards,
Viswas G
> -Original Message-
> From: Jack Wang [mailto:xjtu...@gmail.com]
> Sent: Wednesday, August 30, 2017 9:34 PM
> To: Viswas G
> Cc: linux-scsi@vger.kernel.org; Vasanthalakshmi Tharmarajan
>
> Subject: Re: [PATCH 1/6] pm80xx : re
Hi Jack,
This is a customer requirement. Since the SAS addresses of all the phys were
same , when the attached SAS addresses are different, it was forming only one
domain. If we assign different SAS addresses, this will cause duplicate domain
unless we set the strict_wide_port to 1.
Regards,
good catch, thanks; I'll propagate this to our various OOB drivers.
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Wednesday, August 30, 2017 6:31 AM
To: Dept-Eng QLA2xxx Upstream ; shqking
; Carnuccio, Joe
Cc: James E.J. Bottomley ; Martin K. Petersen
> On Aug 30, 2017, at 6:12 AM, Johannes Thumshirn wrote:
>
> Since commit 7401bc18d1ee ("scsi: qla2xxx: Add FC-NVMe command handling")
> we make use of 'struct nvmefc_fcp_req' in qla24xx_nvme_iocb_entry() without
> including linux/nvme-fc-driver.h where it is defined.
>
> Add linux/nvme-fc-driv
From: Darren Trap
Signed-off-by: Darren Trap
Signed-off-by: Himanshu Madhani
---
drivers/scsi/qla2xxx/qla_init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/qla2xxx/qla_init.c b/drivers/scsi/qla2xxx/qla_init.c
index 30b3acacbfca..73a6c3abb115 100644
--- a/drivers/scsi/qla2
From: Quinn Tran
Call Trace:
[] dump_stack+0x6b/0xa4
[] ? print_irqtrace_events+0xd0/0xe0
[] ___might_sleep+0x183/0x240
[] __might_sleep+0x52/0x90
[] kmem_cache_alloc_trace+0x5b/0x300
[] ? __lock_acquired+0x30b/0x420
[] qla2x00_alloc_fcport+0x38/0x2a0 [qla2xxx]
[] ? qla2x00_do_work+0x34/0
Hi Martin,
These patches are small fixes for the driver. Please apply
to 4.14/scsi-queue at your earliest convenience.
Thanks,
Himanshu
Darren Trap (1):
qla2xxx: Clear fc4f_nvme flag
Quinn Tran (2):
qla2xxx: Fix slow mem alloc behind lock
qla2xxx: Reset the logo flag, after target re-log
From: Quinn Tran
After relogin is sucessful, "send_els_logo" flag
needs to be reinitialized. This will allow next
re-login to happen successfully.
In target mode, this flag was not reset correctly,
causing IO's failure during reset recovery and port
ON/OFF test cases from initiator.
Signed-off-
On Wed, 2017-08-30 at 10:29 +0200, Christoph Hellwig wrote:
> Looks good except for the subject, which will need a little update:
Hello Christoph,
Thanks for the review. Sorry but I don't see what's wrong with the subject.
Can you clarify your comment?
Bart.
On 08/29/2017 07:07 PM, Bart Van Assche wrote:
> If a pass-through request is submitted then blk_get_request()
> initializes that request by calling scsi_initialize_rq(). Also
> call this function for filesystem requests. Introduce
> CMD_INITIALIZED to keep track of whether or not a request has
> a
On Wed, 2017-08-30 at 17:14 -0500, Brian King wrote:
> On 08/29/2017 07:07 PM, Bart Van Assche wrote:
> > If a pass-through request is submitted then blk_get_request()
> > initializes that request by calling scsi_initialize_rq(). Also
> > call this function for filesystem requests. Introduce
> > CM
Hello Martin,
The conclusion of a recent discussion is that .jiffies_at_alloc and .retries
should be set once at the start of a lifetime of a SCSI request instead of
every time a request is requeued. This patch series realizes that and also
ensures that a request is unprepared and reprepared when
If a pass-through request is submitted then blk_get_request()
initializes that request by calling scsi_initialize_rq(). Also
call this function for filesystem requests. Introduce
CMD_INITIALIZED to keep track of whether or not a request has
already been initialized.
Signed-off-by: Bart Van Assche
One of the two scsi-mq functions that requeue a request unprepares a
request before requeueing (scsi_io_completion()) but the other function
not (__scsi_queue_insert()). Make sure that a request is unprepared
before requeuing it.
Fixes: commit d285203cf647 ("scsi: add support for a blk-mq based I/
Make these two member variables available in debugfs such that
their value can be verified by kernel developers. An example of
the new output:
8804a513d480 {.op=READ, .cmd_flags=META|PRIO,
.rq_flags=MQ_INFLIGHT|DONTPREP|IO_STAT|STATS, .atomic_flags=STARTED, .tag=17,
.internal_tag=-1, .cmd=Re
Requests are unprepared and reprepared when being requeued.
Avoid that requeuing resets .jiffies_at_alloc and .retries by
initializing these two member variables from inside
scsi_initialize_rq() and by preserving both member variables
when preparing a request. This patch affects the requeuing
behav
Long,
>> Which kernel version is this patch aimed at?
>
> Martin, thanks for pointing this out. This should also go to stable
> trees.
The reason I asked is that it didn't apply to neither fixes, nor
for-next.
I applied it to 4.13/scsi-fixes by hand and added a stable tag.
--
Martin K. Peters
Nikola,
> aac_convert_sgraw2() kmalloc memory and return -1 on error, which
> should be -ENOMEM. However, nobody is checking return value, so with
> this change, -ENOMEM is propagated to upper layer.
Applied to 4.14/scsi-queue.
--
Martin K. Petersen Oracle Linux Engineering
Dan,
> The value of "size" comes from the user. When we add "start + size"
> it could lead to an integer overflow bug.
>
> It means we vmalloc() a lot more memory than we had intended. I
> believe that on 64 bit systems vmalloc() can succeed even if we ask it
> to allocate huge 4GB buffers. So
Johannes,
> Since commit 7401bc18d1ee ("scsi: qla2xxx: Add FC-NVMe command handling")
> we make use of 'struct nvmefc_fcp_req' in qla24xx_nvme_iocb_entry() without
> including linux/nvme-fc-driver.h where it is defined.
Applied to 4.14/scsi-queue. Thank you!
--
Martin K. Petersen Oracle L
Himanshu,
> These patches are small fixes for the driver. Please apply to
> 4.14/scsi-queue at your earliest convenience.
Done, thanks!
--
Martin K. Petersen Oracle Linux Engineering
> Long,
>
> >> Which kernel version is this patch aimed at?
> >
> > Martin, thanks for pointing this out. This should also go to stable
> > trees.
>
> The reason I asked is that it didn't apply to neither fixes, nor for-next.
>
> I applied it to 4.13/scsi-fixes by hand and added a stable tag.
T
Hi Suganath,
> Theoretically we want to use h/w capability (to translate IEEE to PRP)
> for smaller IO size to leverage h/w capability.
Nobody says we have to use the capability just because the hardware has
it.
Unlike some other operating systems, Linux will only submit I/Os to the
driver that
Hi Martin,
Replied inline.
Thanks,
Suganath Prabu S
On Thu, Aug 31, 2017 at 8:35 AM, Martin K. Petersen
wrote:
>
> Hi Suganath,
>
>> Theoretically we want to use h/w capability (to translate IEEE to PRP)
>> for smaller IO size to leverage h/w capability.
>
> Nobody says we have to use the capabi
64 matches
Mail list logo
