On Fri, Mar 09, 2018 at 12:26:57PM +0530, Kashyap Desai wrote:
> > -Original Message-
> > From: Ming Lei [mailto:ming@redhat.com]
> > Sent: Thursday, March 8, 2018 4:54 PM
> > To: Kashyap Desai
> > Cc: Jens Axboe; linux-bl...@vger.kernel.org; Christoph Hellwig; Mike
> Snitzer;
> > linux
>> static int sd_try_rc16_first(struct scsi_device *sdp)
>> {
>> if (sdp->host->max_cmd_len < 16)
>> return 0;
>
>
> option
>
>> if (sdp->try_rc_10_first)
>> return 0;
>
>
> option
>
>> if (sdp->scsi_level > SCSI_SPC_2)
>> retu
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
On Tue, Mar 06, 2018 at 10:21:33PM -0500, Douglas Gilbert wrote:
> ChangeLog:
> - add likely() and unlikely() hints to conditionals on or near the
> fastpath
> - fix a comment in scsi_io_completion_action()
Do you have any numbers what this patch buys us performance wise?
Thanks,
> -Original Message-
> From: Ming Lei [mailto:ming@redhat.com]
> Sent: Friday, March 9, 2018 9:02 AM
> To: James Bottomley; Jens Axboe; Martin K . Petersen
> Cc: Christoph Hellwig; linux-scsi@vger.kernel.org; linux-
> bl...@vger.kernel.org; Meelis Roos; Don Brace; Kashyap Desai; Laurenc
On Wed, Mar 07, 2018 at 05:56:41PM +1100, Finn Thain wrote:
> In jazz_esp and sun3x_esp, the esp_driver_ops methods pass esp->dev
> in dma api calls as if it was a pointer to a struct device. But
> it actually points to a struct platform_device. Fix this.
>
> Cc: Thomas Bogendoerfer
> Signed-off-
On Fri, Mar 09, 2018 at 04:37:56PM +0530, Kashyap Desai wrote:
> > -Original Message-
> > From: Ming Lei [mailto:ming@redhat.com]
> > Sent: Friday, March 9, 2018 9:02 AM
> > To: James Bottomley; Jens Axboe; Martin K . Petersen
> > Cc: Christoph Hellwig; linux-scsi@vger.kernel.org; linux
when mounting an ISO filesystem sometimes (very rarely)
the system hangs because of a race condition between two tasks.
PID: 6766 TASK: 88007b2a6dd0 CPU: 0 COMMAND: "mount"
#0 [880078447ae0] __schedule at 8168d605
#1 [880078447b48] schedule_preempt_disabled at 81
> V4:
> - splitted from previous patchset
> - handle virtio-scsi by force_blk_mq
>
> Ming Lei (4):
> scsi: hpsa: fix selection of reply queue
> scsi: megaraid_sas: fix selection of reply queue
> scsi: introduce force_blk_mq
> scsi: virtio_scsi: fix IO hang caused by irq vector
> -Original Message-
> From: Ming Lei [mailto:ming@redhat.com]
> Sent: Friday, March 9, 2018 5:33 PM
> To: Kashyap Desai
> Cc: James Bottomley; Jens Axboe; Martin K . Petersen; Christoph Hellwig;
> linux-scsi@vger.kernel.org; linux-bl...@vger.kernel.org; Meelis Roos;
Don
> Brace; Lauren
On 3/9/18 5:59 AM, Maurizio Lombardi wrote:
> when mounting an ISO filesystem sometimes (very rarely)
> the system hangs because of a race condition between two tasks.
>
> PID: 6766 TASK: 88007b2a6dd0 CPU: 0 COMMAND: "mount"
> #0 [880078447ae0] __schedule at 8168d605
> #1 [f
On Fri, 2018-03-09 at 13:59 +0100, Maurizio Lombardi wrote:
> diff --git a/drivers/block/paride/pcd.c b/drivers/block/paride/pcd.c
> index 7b8c636..a026211 100644
> --- a/drivers/block/paride/pcd.c
> +++ b/drivers/block/paride/pcd.c
> @@ -230,6 +230,8 @@ static int pcd_block_open(struct block_devic
https://bugzilla.kernel.org/show_bug.cgi?id=198861
--- Comment #5 from Bart Van Assche (bvanass...@acm.org) ---
Commit 3be8828fc507 is now upstream but is not yet in any of the stable trees.
--
You are receiving this mail because:
You are the assignee for the bug.
I think I've found some suboptimal behaviour in the iSCSI target code, but I'd
like another opinion.
Just as a caveat, this behaviour was first seen on a CentOS 7 kernel, but
looking at the code I think it'll behave the same in master.
Basically, the issue is that the iSCSI target code crea
From: Ming Lei
Sent: Thursday, March 8, 2018 7:32 PM
To: James Bottomley; Jens Axboe; Martin K . Petersen
Cc: Christoph Hellwig; linux-scsi@vger.kernel.org; linux-bl...@vger.kernel.org;
Meelis Roos; Don Brace; Kashyap Desai; Laurence Oberman; Mike Snitzer
In preparation to enabling -Wvla, remove VLAs and replace them with
fixed-length arrays instead.
scsi_dh_{alua,emc,rdac} use variable-length array declarations to
store command blocks, with the appropriate size as determined by
COMMAND_SIZE. This patch replaces these with fixed-sized arrays using
COMMAND_SIZE currently uses an array of values in block/scsi_ioctl.c.
A number of device_handler functions use this to initialise arrays,
and this is flagged by -Wvla.
This patch replaces COMMAND_SIZE with a variant using a formula which
can be resolved at compile time in cases where the opcode is
Hi Finn, Geert,
> + /* We are passed DMA addresses i.e. physical addresses, but must
> use
> +* kernel virtual addresses here, so remap to virtual. This is
> easy
> +* enough for the case of residual bytes of an extended message in
> +* trans
On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote:
> +/*
> + * SCSI command sizes are as follows, in bytes, for fixed size commands, per
> + * group: 6, 10, 10, 12, 16, 12, 10, 10. The top three bits of an opcode
> + * determine its group.
> + * The size table is encoded into a 32-bit value by
On Fri, 2018-03-09 at 23:32 +0100, Stephen Kitt wrote:
> In preparation to enabling -Wvla, remove VLAs and replace them with
> fixed-length arrays instead.
>
> scsi_dh_{alua,emc,rdac} use variable-length array declarations to
> store command blocks, with the appropriate size as determined by
> COM
Hi,
I sent this to the wrong maintainers, sorry — you’ll find the original patch
on https://patchwork.kernel.org/patch/10269257/
Regards,
Stephen
On Thu, 8 Mar 2018 13:43:07 -0800, Kees Cook wrote:
> On Thu, Mar 8, 2018 at 1:38 PM, Stephen Kitt wrote:
> > In preparation to enabling -Wvla, re
Hi,
I’ve been looking into removing some VLAs from device_handler drivers,
prompted by https://lkml.org/lkml/2018/3/7/621
The uses in question here are quite straightforward, e.g. in
drivers/scsi/device_handler/scsi_dh_alua.c:
u8 cdb[COMMAND_SIZE(MAINTENANCE_IN)];
There’s no trivial way
Commit 6e8e1c14c61e ("scsi: lpfc: Add WQ Full Logic for NVME Target")
fails the static checker. Driver is missing an unlock on an return
path.
Add the unlock.
Fixes: 6e8e1c14c61e ("scsi: lpfc: Add WQ Full Logic for NVME Target")
Signed-off-by: Dick Kennedy
Signed-off-by: James Smart
---
driver
Really, the commit message has to be descriptive. This makes me think
this is about some annoying policy of making everything static rather
than a critical bug.
What's wrong with
lpfc: add missing unlock on defer WQFULL path
? You can then expand on the static checker discovery in the main
mes
24 matches
Mail list logo
