Re: [PATCH] klist: Make it safe to use klists in atomic context
Bart, > Thanks Greg for the ack. I wasn't sure which maintainer to send this > patch to since lib/klist.c is not mentioned in the MAINTAINERS > file. Martin, are you OK with queuing this patch? Sure, no problem. -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH-next] scsi: libsas: dynamically allocate and free ata host
John, > OK, but please be aware that there may be a more serious issue fixed > here than the WARN, in that we could try to free memory embedded in a > structure. We can still get it into 4.18.x. I'm just wary of submitting stuff to Linus that has had zero -next exposure. -- Martin K. Petersen Oracle Linux Engineering
RE: mpt3sas regression...
David, I could see the same issue on sparc64 system, soon we will repost the patch addressing this. Thanks, Chaitra -Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Thursday, June 28, 2018 5:45 AM To: chaitra.basa...@broadcom.com Cc: linux-scsi@vger.kernel.org; sparcli...@vger.kernel.org Subject: Re: mpt3sas regression... From: Chaitra Basappa Date: Wed, 27 Jun 2018 19:58:34 +0530 > Please let us know what is the issue faced and if its recreating then > share the driver logs with logging_level=0x3f8. The driver cannot even probe successfully to start scanning for disks because some busy bit never clears. I think it was in one of the firmware status registers or the doorbell register.
Re: [PATCH] klist: Make it safe to use klists in atomic context
On 06/28/18 08:37, Greg Kroah-Hartman wrote:
On Fri, Jun 22, 2018 at 02:54:49PM -0700, Bart Van Assche wrote:
In the scsi_transport_srp implementation it cannot be avoided to
iterate over a klist from atomic context when using the legacy
block layer instead of blk-mq. Hence this patch that makes it safe
to use klists in atomic context. This patch avoids that lockdep
reports the following:
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock(&(>k_lock)->rlock);
local_irq_disable();
lock(&(>__queue_lock)->rlock);
lock(&(>k_lock)->rlock);
lock(&(>__queue_lock)->rlock);
stack backtrace:
Workqueue: kblockd blk_timeout_work
Call Trace:
dump_stack+0xa4/0xf5
check_usage+0x6e6/0x700
__lock_acquire+0x185d/0x1b50
lock_acquire+0xd2/0x260
_raw_spin_lock+0x32/0x50
klist_next+0x47/0x190
device_for_each_child+0x8e/0x100
srp_timed_out+0xaf/0x1d0 [scsi_transport_srp]
scsi_times_out+0xd4/0x410 [scsi_mod]
blk_rq_timed_out+0x36/0x70
blk_timeout_work+0x1b5/0x220
process_one_work+0x4fe/0xad0
worker_thread+0x63/0x5a0
kthread+0x1c1/0x1e0
ret_from_fork+0x24/0x30
See also commit c9ddf73476ff ("scsi: scsi_transport_srp: Fix shost
to rport translation").
Signed-off-by: Bart Van Assche
Cc: Martin K. Petersen
Cc: James Bottomley
---
lib/klist.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
No objection from me:
Acked-by: Greg Kroah-Hartman
This should probably go through the scsi tree, right?
Thanks Greg for the ack. I wasn't sure which maintainer to send this
patch to since lib/klist.c is not mentioned in the MAINTAINERS file.
Martin, are you OK with queuing this patch?
Thanks,
Bart.
Re: [PATCH] klist: Make it safe to use klists in atomic context
On Fri, Jun 22, 2018 at 02:54:49PM -0700, Bart Van Assche wrote:
> In the scsi_transport_srp implementation it cannot be avoided to
> iterate over a klist from atomic context when using the legacy
> block layer instead of blk-mq. Hence this patch that makes it safe
> to use klists in atomic context. This patch avoids that lockdep
> reports the following:
>
> WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
> Possible interrupt unsafe locking scenario:
>
>CPU0CPU1
>
> lock(&(>k_lock)->rlock);
>local_irq_disable();
>lock(&(>__queue_lock)->rlock);
>lock(&(>k_lock)->rlock);
>
> lock(&(>__queue_lock)->rlock);
>
> stack backtrace:
> Workqueue: kblockd blk_timeout_work
> Call Trace:
> dump_stack+0xa4/0xf5
> check_usage+0x6e6/0x700
> __lock_acquire+0x185d/0x1b50
> lock_acquire+0xd2/0x260
> _raw_spin_lock+0x32/0x50
> klist_next+0x47/0x190
> device_for_each_child+0x8e/0x100
> srp_timed_out+0xaf/0x1d0 [scsi_transport_srp]
> scsi_times_out+0xd4/0x410 [scsi_mod]
> blk_rq_timed_out+0x36/0x70
> blk_timeout_work+0x1b5/0x220
> process_one_work+0x4fe/0xad0
> worker_thread+0x63/0x5a0
> kthread+0x1c1/0x1e0
> ret_from_fork+0x24/0x30
>
> See also commit c9ddf73476ff ("scsi: scsi_transport_srp: Fix shost
> to rport translation").
>
> Signed-off-by: Bart Van Assche
> Cc: Martin K. Petersen
> Cc: James Bottomley
> ---
> lib/klist.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
No objection from me:
Acked-by: Greg Kroah-Hartman
This should probably go through the scsi tree, right?
thanks,
greg k-h
[PATCH] sd_zbc: Remove an assignment from sd_zbc_setup_report_cmnd()
Since nr_bytes == blk_rq_bytes(rq) == rq->__data_len, the rq->__data_len = nr_bytes assignment does not modify the value of rq->__data_len. Hence remove that assignment. Note: the code in sd_done() that sets the residual to zero for zone report requests is not affected by this patch. Signed-off-by: Bart Van Assche Reviewed-by: Damien Le Moal Cc: Hannes Reinecke Cc: Johannes Thumshirn --- drivers/scsi/sd_zbc.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/scsi/sd_zbc.c b/drivers/scsi/sd_zbc.c index a14fef11776e..160b79619d30 100644 --- a/drivers/scsi/sd_zbc.c +++ b/drivers/scsi/sd_zbc.c @@ -148,12 +148,6 @@ int sd_zbc_setup_report_cmnd(struct scsi_cmnd *cmd) cmd->transfersize = sdkp->device->sector_size; cmd->allowed = 0; - /* -* Report may return less bytes than requested. Make sure -* to report completion on the entire initial request. -*/ - rq->__data_len = nr_bytes; - return BLKPREP_OK; } -- 2.17.1
RE: [PATCH] scsi: qedi: tidy up a size caculation
> -Original Message- > From: Dan Carpenter > Sent: Thursday, June 28, 2018 2:53 PM > To: Dept-Eng QLogic Storage Upstream upstr...@cavium.com>; Rangankar, Manish > > Cc: James E.J. Bottomley ; Martin K. Petersen > ; linux-scsi@vger.kernel.org; kernel- > janit...@vger.kernel.org > Subject: [PATCH] scsi: qedi: tidy up a size caculation > > External Email > > The id_tbl->table pointer points to unsigned long so static checkers complain > that instead of 4 we should be allocating sizeof(long) bytes. > > We're trying to allocate enough bits for the bitmap. The size variable is > always > 1024. (1024 / 32 * 4) is the same as (1024 / 64 * 8) so this doesn't change > runtime, but this is the more idiomatic way to do it and makes the static > checker > happy. > > Signed-off-by: Dan Carpenter > > diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c > index > cf274a79e77a..682f3ce31014 100644 > --- a/drivers/scsi/qedi/qedi_main.c > +++ b/drivers/scsi/qedi/qedi_main.c > @@ -524,7 +524,7 @@ static int qedi_init_id_tbl(struct qedi_portid_tbl > *id_tbl, > u16 size, > id_tbl->max = size; > id_tbl->next = next; > spin_lock_init(_tbl->lock); > - id_tbl->table = kcalloc(DIV_ROUND_UP(size, 32), 4, GFP_KERNEL); > + id_tbl->table = kcalloc(BITS_TO_LONGS(size), sizeof(long), > + GFP_KERNEL); > if (!id_tbl->table) > return -ENOMEM; Thanks, Acked-by: Manish Rangankar
Re: aacraid driver, kernel 4.14 and up, ASR8xxx controller : doesn't work
Le Wed, 27 Jun 2018 18:48:56 + Dave Carroll écrivait: > Sorry, that comment was incorrect, but I would like to see if the > size is consistent between the kernels. > Yes it is. The only difference is the driver version going from 50834 to 50877. The problem occurs on different setups, using different RAID controllers, etc. As I mentioned it works with an ASR7xx5 up to 4.14, but with 4.16 both 8xx5 and 7xx5 controllers don't work. [5.762727] Adaptec aacraid driver 1.2.1[50834]-custom [5.768147] aacraid: Comm Interface type2 enabled [5.775262] AAC0: kernel 7.13-0[33263] Mar 16 2018 [5.775264] AAC0: monitor 7.13-0[33263] [5.775265] AAC0: bios 7.13-0[33263] [5.775267] AAC0: serial 6A476396945 [5.775268] AAC0: Non-DASD support enabled. [7.782209] scsi host6: aacraid [7.782629] scsi 6:0:2:0: Direct-Access ASR8885 raid3V1.0 PQ: 0 ANSI: 2 [7.782735] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.782743] sd 6:0:2:0: [sdb] 632763166720 512-byte logical blocks: (324 TB/295 TiB) [7.782751] sd 6:0:2:0: [sdb] Write Protect is off [7.782752] sd 6:0:2:0: [sdb] Mode Sense: 12 00 10 08 [7.782764] sd 6:0:2:0: [sdb] Write cache: disabled, read cache: enabled, supports DPO and FUA [7.782832] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.808366] scsi 6:1:105:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.809387] scsi 6:1:106:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.810895] scsi 6:1:107:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.811889] scsi 6:1:108:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.812131] sd 6:0:2:0: [sdb] Very big device. Trying to use READ CAPACITY(16). [7.812156] sd 6:0:2:0: [sdb] Attached SCSI removable disk [7.812884] scsi 6:1:109:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.813886] scsi 6:1:110:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.814861] scsi 6:1:111:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.815994] scsi 6:1:112:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.817001] scsi 6:1:113:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.818019] scsi 6:1:114:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.819004] scsi 6:1:115:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.820103] scsi 6:1:116:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.821087] scsi 6:1:117:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.822065] scsi 6:1:118:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.824714] scsi 6:1:119:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.825785] scsi 6:1:120:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.826830] scsi 6:1:121:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.829031] scsi 6:1:122:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.830013] scsi 6:1:123:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.831022] scsi 6:1:124:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.832033] scsi 6:1:125:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.833098] scsi 6:1:126:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.834078] scsi 6:1:127:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.835077] scsi 6:1:128:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.836046] scsi 6:1:129:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.837025] scsi 6:1:130:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.838002] scsi 6:1:131:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.838984] scsi 6:1:132:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.839965] scsi 6:1:133:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 [7.840939] scsi 6:1:134:0: Direct-Access HGST HUH721212AL5200 A3D0 PQ: 1 ANSI: 6 -- Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 pgpEXUp9KUvpv.pgp Description: Signature digitale OpenPGP
[PATCH] scsi: qedi: tidy up a size caculation
The id_tbl->table pointer points to unsigned long so static checkers complain that instead of 4 we should be allocating sizeof(long) bytes. We're trying to allocate enough bits for the bitmap. The size variable is always 1024. (1024 / 32 * 4) is the same as (1024 / 64 * 8) so this doesn't change runtime, but this is the more idiomatic way to do it and makes the static checker happy. Signed-off-by: Dan Carpenter diff --git a/drivers/scsi/qedi/qedi_main.c b/drivers/scsi/qedi/qedi_main.c index cf274a79e77a..682f3ce31014 100644 --- a/drivers/scsi/qedi/qedi_main.c +++ b/drivers/scsi/qedi/qedi_main.c @@ -524,7 +524,7 @@ static int qedi_init_id_tbl(struct qedi_portid_tbl *id_tbl, u16 size, id_tbl->max = size; id_tbl->next = next; spin_lock_init(_tbl->lock); - id_tbl->table = kcalloc(DIV_ROUND_UP(size, 32), 4, GFP_KERNEL); + id_tbl->table = kcalloc(BITS_TO_LONGS(size), sizeof(long), GFP_KERNEL); if (!id_tbl->table) return -ENOMEM;
