Re: [PATCH v2 1/2] scsi: lpfc: Use kzalloc instead of kmalloc

Punit Vara wrote: > This patch is to the lpfc_els.c which resolves following warning > reported by coccicheck: > > WARNING: kzalloc should be used for rdp_context, instead of > kmalloc/memset > > Signed-off-by: Punit Vara > --- > drivers/scsi/lpfc/lpfc_els.c | 3 +-- > 1

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On 11/20/2015 04:28 PM, Ewan Milne wrote: On Fri, 2015-11-20 at 15:55 +0100, Hannes Reinecke wrote: Can't we have a joint effort here? I've been spending a _LOT_ of time trying to debug things here, but none of the ideas I've come up with have been able to fix anything. Yes. I'm not the one

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote: > On Sat, 21 Nov 2015 12:30:14 +0100 > Laurent Dufour wrote: > > > On 20/11/2015 13:10, Michael Ellerman wrote: > > > On Thu, 2015-11-19 at 00:23 -0800, Christoph Hellwig wrote: > > > > > > > It's pretty much

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On Mon, 2015-11-23 at 08:36 +0800, Ming Lei wrote: > On Mon, Nov 23, 2015 at 7:20 AM, Mark Salter wrote: > > On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote: > > > On Sat, 21 Nov 2015 12:30:14 +0100 > > > Laurent Dufour wrote: > > > > > > > On

Re: [PATCH v2] lpfc: replaced kmalloc + memset with kzalloc

Saurabh Sengar wrote: > replacing kmalloc and memset by a single call of kzalloc > > Signed-off-by: Saurabh Sengar > --- > v2 : I didn't got any response for my initial patch, > I am sending it again on top of latest kernel(today's) > > drivers/scsi/lpfc/lpfc_els.c | 3

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

Hi Mark, On Mon, Nov 23, 2015 at 9:50 AM, Mark Salter wrote: > On Mon, 2015-11-23 at 08:36 +0800, Ming Lei wrote: >> On Mon, Nov 23, 2015 at 7:20 AM, Mark Salter wrote: >> > On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote: >> > > On Sat, 21 Nov 2015

Re: kernel BUG at drivers/scsi/scsi_lib.c:1096!

On Mon, Nov 23, 2015 at 7:20 AM, Mark Salter wrote: > On Sun, 2015-11-22 at 00:56 +0800, Ming Lei wrote: >> On Sat, 21 Nov 2015 12:30:14 +0100 >> Laurent Dufour wrote: >> >> > On 20/11/2015 13:10, Michael Ellerman wrote: >> > > On Thu, 2015-11-19

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

On Sun, Nov 22, 2015 at 12:36:00PM +0200, Sagi Grimberg wrote: > >> Wouldn't it be a better idea to set the WQ_SYSFS interface and use >> the standard sysfs interface for specifying cpumasks or node affinity? > > I think that bart wants to allow the caller to select cpu affinity > per CQ. In this

Re: [PATCH 1/2] scsi_transport_fc: Introduce scsi_host_{get,put}()

On Fri, Nov 20, 2015 at 01:33:04PM -0800, Bart Van Assche wrote: > Use scsi_host_{get,put}() instead of open-coding these functions. > Compile-tested only. s/Introdue/use/ in the subject? Otherwise this looks fine: Reviewed-by: Christoph Hellwig -- To unsubscribe from this list:

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

I think that bart wants to allow the caller to select cpu affinity per CQ. In this case ib_alloc_cq in workqueue mode would need to accept a affinity_hint from the caller (default to wild-card WORK_CPU_UNBOUND). Hmm, true. How would be set that hint from userspace? I'd really prefer to see

Re: [PATCH] Fix a memory leak in scsi_host_dev_release()

On Fri, Nov 20, 2015 at 09:49:42AM -0800, Bart Van Assche wrote: > On 11/20/2015 03:52 AM, Christoph Hellwig wrote: > >the memory leak looks real, and your fix looks corret, but I still > >don't like it. > > > >I think it's reasonable for SCSI to assume that the final put_device > >fully frees the

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

Wouldn't it be a better idea to set the WQ_SYSFS interface and use the standard sysfs interface for specifying cpumasks or node affinity? I think that bart wants to allow the caller to select cpu affinity per CQ. In this case ib_alloc_cq in workqueue mode would need to accept a affinity_hint

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

Hello Christoph, The comment about locality in the above quote is interesting. How about modifying patch 2/9 as indicated below ? The modification below does not change the behavior of this patch if ib_cq.w.cpu is not modified. And it allows users who care about locality and who want to skip

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

On Sun, Nov 22, 2015 at 11:51:13AM +0200, Sagi Grimberg wrote: > >> Hello Christoph, >> >> The comment about locality in the above quote is interesting. How about >> modifying patch 2/9 as indicated below ? The modification below does not >> change the behavior of this patch if ib_cq.w.cpu is not

[PATCH RESEND] scsi_debug: fix prevent_allow+verify regressions

Ruediger Meier observed a regression with the PREVENT ALLOW MEDIUM REMOVAL command in lk 3.19: http://www.spinics.net/lists/util-linux-ng/msg11448.html Inspection indicated the same regression with VERIFY(10). The patch is against lk 3.19.3 and also works with lk 4.3.0 . With this patch both

Re: [PATCH 2/9] IB: add a proper completion queue abstraction

On 11/22/15 06:57, Sagi Grimberg wrote: I think that bart wants to allow the caller to select cpu affinity per CQ. In this case ib_alloc_cq in workqueue mode would need to accept a affinity_hint from the caller (default to wild-card WORK_CPU_UNBOUND). Hmm, true. How would be set that hint