Message ID | 1547089149-20577-1-git-send-email-tyreld@linux.vnet.ibm.com (mailing list archive) |
---|---|
State | Not Applicable |
Headers | show |
Series | ibmvscsi: use GFP_KERNEL with dma_alloc_coherent in initialize_event_pool | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/apply_patch | success | next/apply_patch Successfully applied |
snowpatch_ozlabs/build-ppc64le | success | build succeeded & removed 0 sparse warning(s) |
snowpatch_ozlabs/build-ppc64be | success | build succeeded & removed 0 sparse warning(s) |
snowpatch_ozlabs/build-ppc64e | success | build succeeded & removed 0 sparse warning(s) |
snowpatch_ozlabs/build-pmac32 | success | build succeeded & removed 0 sparse warning(s) |
snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 8 lines checked |
On 01/09/2019 08:59 PM, Tyrel Datwyler wrote: > During driver probe we allocate a dma region for our event pool. > Currently, zero is passed for the gfp_flags parameter. Driver probe > callbacks run in process context and we hold no locks so we can sleep > here if necessary. > > Fix by passing GFP_KERNEL explicitly to dma_alloc_coherent(). > > Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> > --- > drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c > index cb8535e..10d5e77 100644 > --- a/drivers/scsi/ibmvscsi/ibmvscsi.c > +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c > @@ -465,7 +465,7 @@ static int initialize_event_pool(struct event_pool *pool, > pool->iu_storage = > dma_alloc_coherent(hostdata->dev, > pool->size * sizeof(*pool->iu_storage), > - &pool->iu_token, 0); > + &pool->iu_token, GFP_KERNEL); > if (!pool->iu_storage) { > kfree(pool->events); > return -ENOMEM; > Reviewed-by: Brian King <brking@linux.vnet.ibm.com>
Just stumbled upon this trivial little patch that looks to have gotten lost in the shuffle. Seems it even got a reviewed-by from Brian [1]. So, uh I guess after almost 3 years...ping? -Tyrel [1] https://yhbt.net/lore/all/fd33df0e-012b-e437-c6e9-29cd0883808d@linux.vnet.ibm.com/ On 01/09/2019 08:59 PM, Tyrel Datwyler wrote: > During driver probe we allocate a dma region for our event pool. > Currently, zero is passed for the gfp_flags parameter. Driver probe > callbacks run in process context and we hold no locks so we can sleep > here if necessary. > > Fix by passing GFP_KERNEL explicitly to dma_alloc_coherent(). > > Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> > --- > drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c > index cb8535e..10d5e77 100644 > --- a/drivers/scsi/ibmvscsi/ibmvscsi.c > +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c > @@ -465,7 +465,7 @@ static int initialize_event_pool(struct event_pool *pool, > pool->iu_storage = > dma_alloc_coherent(hostdata->dev, > pool->size * sizeof(*pool->iu_storage), > - &pool->iu_token, 0); > + &pool->iu_token, GFP_KERNEL); > if (!pool->iu_storage) { > kfree(pool->events); > return -ENOMEM; >
Tyrel Datwyler <tyreld@linux.ibm.com> writes: > Just stumbled upon this trivial little patch that looks to have gotten lost in > the shuffle. Seems it even got a reviewed-by from Brian [1]. > > So, uh I guess after almost 3 years...ping? It's marked "Changes Requested" here: https://patchwork.kernel.org/project/linux-scsi/patch/1547089149-20577-1-git-send-email-tyreld@linux.vnet.ibm.com/ If it isn't picked up in a few days you should probably do a resend so that it reappears in patchwork. cheers
On 10/14/21 9:36 PM, Michael Ellerman wrote: > Tyrel Datwyler <tyreld@linux.ibm.com> writes: >> Just stumbled upon this trivial little patch that looks to have gotten lost in >> the shuffle. Seems it even got a reviewed-by from Brian [1]. >> >> So, uh I guess after almost 3 years...ping? > > It's marked "Changes Requested" here: > > https://patchwork.kernel.org/project/linux-scsi/patch/1547089149-20577-1-git-send-email-tyreld@linux.vnet.ibm.com/ Interesting > > > If it isn't picked up in a few days you should probably do a resend so > that it reappears in patchwork. Fair enough -Tyrel > > cheers >
Michael,
> It's marked "Changes Requested" here:
Not sure why.
Applied to 5.16/scsi-staging, thanks!
On Wed, 9 Jan 2019 18:59:09 -0800, Tyrel Datwyler wrote: > During driver probe we allocate a dma region for our event pool. > Currently, zero is passed for the gfp_flags parameter. Driver probe > callbacks run in process context and we hold no locks so we can sleep > here if necessary. > > Fix by passing GFP_KERNEL explicitly to dma_alloc_coherent(). > > [...] Applied to 5.16/scsi-queue, thanks! [1/1] ibmvscsi: use GFP_KERNEL with dma_alloc_coherent in initialize_event_pool https://git.kernel.org/mkp/scsi/c/3319a8ba82b9
diff --git a/drivers/scsi/ibmvscsi/ibmvscsi.c b/drivers/scsi/ibmvscsi/ibmvscsi.c index cb8535e..10d5e77 100644 --- a/drivers/scsi/ibmvscsi/ibmvscsi.c +++ b/drivers/scsi/ibmvscsi/ibmvscsi.c @@ -465,7 +465,7 @@ static int initialize_event_pool(struct event_pool *pool, pool->iu_storage = dma_alloc_coherent(hostdata->dev, pool->size * sizeof(*pool->iu_storage), - &pool->iu_token, 0); + &pool->iu_token, GFP_KERNEL); if (!pool->iu_storage) { kfree(pool->events); return -ENOMEM;
During driver probe we allocate a dma region for our event pool. Currently, zero is passed for the gfp_flags parameter. Driver probe callbacks run in process context and we hold no locks so we can sleep here if necessary. Fix by passing GFP_KERNEL explicitly to dma_alloc_coherent(). Signed-off-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com> --- drivers/scsi/ibmvscsi/ibmvscsi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)