From: Halil Pasic <pasic@linux.ibm.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: Vineeth Vijayan <vneethv@linux.ibm.com>,
Peter Oberparleiter <oberpar@linux.ibm.com>,
Heiko Carstens <hca@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>,
Michael Mueller <mimu@linux.ibm.com>,
Cornelia Huck <cohuck@redhat.com>,
linux-s390@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, bfu@redhat.com,
Halil Pasic <pasic@linux.ibm.com>
Subject: Re: [RFC PATCH 1/1] s390/cio: make ccw_device_dma_* more robust
Date: Mon, 11 Oct 2021 20:42:49 +0200 [thread overview]
Message-ID: <20211011204249.3c53ce2a.pasic@linux.ibm.com> (raw)
In-Reply-To: <466de207-e88d-ea93-beec-fbfe10e63a26@linux.ibm.com>
On Mon, 11 Oct 2021 15:45:55 +0200
Pierre Morel <pmorel@linux.ibm.com> wrote:
> > + if (IS_ERR_OR_NULL(addr))
>
> I can be wrong but it seems that only dma_alloc_coherent() used in
> cio_gp_dma_zalloc() report an error but the error is ignored and used as
> a valid pointer.
https://www.kernel.org/doc/Documentation/DMA-API.txt says:
Part Ia - Using large DMA-coherent buffers
------------------------------------------
::
void *
dma_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
[..]
It returns a pointer to the allocated region (in the processor's virtual
address space) or NULL if the allocation failed.
I hope that is still true. If not we should fix cio_gp_dma_zalloc().
>
> So shouldn't we modify this function and just test for a NULL address here?
>
Isn't IS_ERR_OR_NULL() safer, in a sense that even if we decided to
eventually return an error code, this piece of code would be robust
and safe?
We may exploit the knowledge that cio_gp_dma_zalloc() either
returns NULL or a valid pointer, but doing it like this is IMHO also an
option.
> here what I mean:---------------------------------
>
> diff --git a/drivers/s390/cio/css.c b/drivers/s390/cio/css.c
> index 2bc55ccf3f23..b45fbaa7131b 100644
> --- a/drivers/s390/cio/css.c
> +++ b/drivers/s390/cio/css.c
> @@ -1176,7 +1176,7 @@ void *cio_gp_dma_zalloc(struct gen_pool *gp_dma,
> struct device *dma_dev,
> chunk_size = round_up(size, PAGE_SIZE);
> addr = (unsigned long) dma_alloc_coherent(dma_dev,
> chunk_size, &dma_addr,
> CIO_DMA_GFP);
> - if (!addr)
> + if (IS_ERR_OR_NULL(addr))
> return NULL;
> gen_pool_add_virt(gp_dma, addr, dma_addr, chunk_size, -1);
> addr = gen_pool_alloc(gp_dma, size);
>
> ---------------------------------
>
> > + put_device(&cdev->dev);
>
> addr is not null if addr is ERR.
>
Your point?
> > + return addr;
>
> may be return IS_ERR_OR_NULL(addr)? NULL : addr;
>
See above. I don't think that is necessary.
> > }
> > EXPORT_SYMBOL(ccw_device_dma_zalloc);
> >
> > void ccw_device_dma_free(struct ccw_device *cdev, void *cpu_addr, size_t size)
> > {
> > + if (!cpu_addr)
> > + return;
>
> no need, cpu_addr is already tested in cio_gp_dma_free()
>
This is added in because of the put_device(). An alternative would be
to call cio_gp_dma_free() unconditionally do the check just for the
put_device(). But I like this one better.
Thanks for your feedback!
Halil
> > cio_gp_dma_free(cdev->private->dma_pool, cpu_addr, size);
> > + put_device(&cdev->dev);
> > }
> > EXPORT_SYMBOL(ccw_device_dma_free);
> >
> >
next prev parent reply other threads:[~2021-10-11 18:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-11 11:59 [RFC PATCH 1/1] s390/cio: make ccw_device_dma_* more robust Halil Pasic
2021-10-11 13:45 ` Pierre Morel
2021-10-11 14:33 ` Cornelia Huck
2021-10-11 18:48 ` Halil Pasic
2021-10-12 13:50 ` Cornelia Huck
2021-10-12 22:37 ` Halil Pasic
2021-10-13 6:51 ` Cornelia Huck
2021-10-12 14:10 ` Pierre Morel
2021-10-11 18:42 ` Halil Pasic [this message]
2021-10-12 13:36 ` Vineeth Vijayan
2021-10-12 21:32 ` Halil Pasic
2021-10-13 7:29 ` Vineeth Vijayan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211011204249.3c53ce2a.pasic@linux.ibm.com \
--to=pasic@linux.ibm.com \
--cc=bfu@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cohuck@redhat.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=mimu@linux.ibm.com \
--cc=oberpar@linux.ibm.com \
--cc=pmorel@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=vneethv@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.