[PATCH 1/1] scsi: bump SCSI_DEFAULT_MAX_SECTORS to SD_DEF_XFER_BLOCKS

From: Tom Yan As of commit ca369d51b3e1649be4a72addd6d6a168cfb3f537, max_sectors (rw_max) of a scsi disk can be as high as SD_DEF_XFER_BLOCKS. Therefore, bump SCSI_DEFAULT_MAX_SECTORS to 65535 to make hosts that do not have max_sectors set in their templates benefit from the

UBSAN whinge in scsi_devinfo.c

.936392] UBSAN: Undefined behaviour in drivers/scsi/scsi_devinfo.c:457:21 [2.936396] index 8 is out of range for type 'char [8]' [2.936401] CPU: 0 PID: 98 Comm: kworker/u8:1 Not tainted 4.6.0-next-20160517-1-gede618fce89c-dirty #279 [2.936412] Hardware name: Dell Inc. Latitude E653

Re: [PATCH 2/2] target: fix max discard sectors calculation

On 05/17/2016 01:16 PM, Bart Van Assche wrote: > On 05/16/2016 12:02 PM, Martin K. Petersen wrote: >>> "Bart" == Bart Van Assche writes: >> >> Bart> That's a good catch. But seeing this patch makes me wonder whether >> Bart> this patch introduces a 64-bit division?

Re: [PATCH 2/2] target: fix max discard sectors calculation

On 05/16/2016 12:02 PM, Martin K. Petersen wrote: "Bart" == Bart Van Assche writes: Bart> That's a good catch. But seeing this patch makes me wonder whether Bart> this patch introduces a 64-bit division? If so, I'm afraid this Bart> patch will make 32-bit users

Re: [PATCH] libfc: replace 'rp_mutex' with 'rp_lock'

On 05/16/2016 11:46 PM, Hannes Reinecke wrote: On 05/11/2016 04:44 PM, Bart Van Assche wrote: On 05/10/16 23:07, Hannes Reinecke wrote: On 05/11/2016 07:49 AM, Hannes Reinecke wrote: RIP: 0010:[] [] fc_rport_lookup+0x4b/0x70 [libfc] Call Trace: [] fc_rport_create+0x17/0x1b0 [libfc] []

Re: [PATCH] sd: get disk reference in sd_check_events()

On 04/25/2016 11:06 PM, Hannes Reinecke wrote: sd_check_events() is called asynchronously, and might race with device removal. So always take a disk reference when processing the event to avoid the device being removed while the event is processed. Reviewed-by: Bart Van Assche

UBSAN: Undefined behaviour in drivers/scsi/scsi_devinfo.c:457:21

Found another UBSAN warning on 32-bit powerpc, during pata_macio driver initialization. I hope it is not a false positive :) [2.540935] [2.547807] UBSAN: Undefined behaviour in

Re: [PATCH 0/7] fix typo

Julia Lawall writes: > On Tue, 17 May 2016, Kalle Valo wrote: > >> Julia Lawall writes: >> >> > firmare -> firmware >> > >> > --- >> > >> > drivers/media/dvb-frontends/mn88473.c |2 +- >> > drivers/net/wireless/ath/ath6kl/core.h |2

Re: [PATCH 0/7] fix typo

Julia Lawall writes: > firmare -> firmware > > --- > > drivers/media/dvb-frontends/mn88473.c |2 +- > drivers/net/wireless/ath/ath6kl/core.h |2 +- > drivers/net/wireless/marvell/mwifiex/pcie.c |2 +- It would be good to know in advance what tree you

Re: [PATCH 0/7] fix typo

On Tue, 17 May 2016, Kalle Valo wrote: > Julia Lawall writes: > > > firmare -> firmware > > > > --- > > > > drivers/media/dvb-frontends/mn88473.c |2 +- > > drivers/net/wireless/ath/ath6kl/core.h |2 +- > > drivers/net/wireless/marvell/mwifiex/pcie.c |

[PATCH 5/7] pm8001: fix typo

firmare -> firmware Signed-off-by: Julia Lawall --- drivers/scsi/pm8001/pm8001_init.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c index 6bd7bf4..fdbee8b4 100644 ---

[PATCH 1/7] snic: fix typo

firmare -> firmware Signed-off-by: Julia Lawall --- drivers/scsi/snic/snic_fwint.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/snic/snic_fwint.h b/drivers/scsi/snic/snic_fwint.h index c5f9e19..2a045a5 100644 ---

[PATCH 0/7] fix typo

firmare -> firmware --- drivers/media/dvb-frontends/mn88473.c |2 +- drivers/net/wireless/ath/ath6kl/core.h |2 +- drivers/net/wireless/marvell/mwifiex/pcie.c |2 +- drivers/scsi/pm8001/pm8001_init.c |2 +- drivers/scsi/snic/snic_fwint.h |2

Re: [PATCH 5/7] pm8001: fix typo

On Tue, May 17, 2016 at 4:38 PM, Julia Lawall wrote: > firmare -> firmware > > Signed-off-by: Julia Lawall > > --- > drivers/scsi/pm8001/pm8001_init.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Another UBSAN warning from aic7xxx

Despite the first one being a false positive, her I am reporting another one, from a older dual P2 server with Adaptec aic7896/97 Ultra2 SCSI adapter and QUANTUM VIKING II 4.5WSE HDD-s. [1.730498] [

Re: [PATCH] sd: get disk reference in sd_check_events()

On Tue, 2016-04-26 at 08:06 +0200, Hannes Reinecke wrote: > sd_check_events() is called asynchronously, and might race > with device removal. So always take a disk reference when > processing the event to avoid the device being removed while > the event is processed. > > Signed-off-by: Hannes

Re: [PATCH] storvsc: use small sg_tablesize on x86

On Mon, May 16, Joseph Salisbury wrote: > > CONFIG_64BIT=y > It doesn't appear this patch ever landed in Mainline. Olaf, do you have > plans to submit this patch? Yes, will do. Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to

Re: [PATCH] scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands

On Tue, May 17, 2016 at 11:28 AM, Johannes Thumshirn wrote: > On Fri, May 13, 2016 at 12:04:06PM -0700, James Bottomley wrote: >> When SCSI was written, all commands coming from the filesystem >> (REQ_TYPE_FS commands) had data. This meant that our signal for >> needing to

Re: [PATCH] scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands

On Fri, May 13, 2016 at 9:04 PM, James Bottomley wrote: > When SCSI was written, all commands coming from the filesystem > (REQ_TYPE_FS commands) had data. This meant that our signal for > needing to complete the command was the number of bytes completed

Re: [PATCH] scsi_lib: correctly retry failed zero length REQ_TYPE_FS commands

On Fri, May 13, 2016 at 12:04:06PM -0700, James Bottomley wrote: > When SCSI was written, all commands coming from the filesystem > (REQ_TYPE_FS commands) had data. This meant that our signal for > needing to complete the command was the number of bytes completed being > equal to the number of

Re: [PATCH] libfc: replace 'rp_mutex' with 'rp_lock'

On 05/11/2016 04:44 PM, Bart Van Assche wrote: On 05/10/16 23:07, Hannes Reinecke wrote: On 05/11/2016 07:49 AM, Hannes Reinecke wrote: RIP: 0010:[] [] fc_rport_lookup+0x4b/0x70 [libfc] Call Trace: [] fc_rport_create+0x17/0x1b0 [libfc] [] fc_disc_recv_req+0x261/0x480 [libfc] []