From: Halil Pasic <pasic@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: Pierre Morel <pmorel@linux.ibm.com>,
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>,
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:48:37 +0200 [thread overview]
Message-ID: <20211011204837.7617301b.pasic@linux.ibm.com> (raw)
In-Reply-To: <874k9ny6k6.fsf@redhat.com>
On Mon, 11 Oct 2021 16:33:45 +0200
Cornelia Huck <cohuck@redhat.com> wrote:
> On Mon, Oct 11 2021, Pierre Morel <pmorel@linux.ibm.com> wrote:
>
> > On 10/11/21 1:59 PM, Halil Pasic wrote:
> >> diff --git a/drivers/s390/cio/device_ops.c b/drivers/s390/cio/device_ops.c
> >> index 0fe7b2f2e7f5..c533d1dadc6b 100644
> >> --- a/drivers/s390/cio/device_ops.c
> >> +++ b/drivers/s390/cio/device_ops.c
> >> @@ -825,13 +825,23 @@ EXPORT_SYMBOL_GPL(ccw_device_get_chid);
> >> */
> >> void *ccw_device_dma_zalloc(struct ccw_device *cdev, size_t size)
> >> {
> >> - return cio_gp_dma_zalloc(cdev->private->dma_pool, &cdev->dev, size);
> >> + void *addr;
> >> +
> >> + if (!get_device(&cdev->dev))
> >> + return NULL;
> >> + addr = cio_gp_dma_zalloc(cdev->private->dma_pool, &cdev->dev, size);
> >> + 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.
>
> Hm, I thought dma_alloc_coherent() returned either NULL or a valid
> address?
Yes, that is what is documented.
>
> >
> > So shouldn't we modify this function and just test for a NULL address here?
>
> If I read cio_gp_dma_zalloc() correctly, we either get NULL or a valid
> address, so yes.
>
I don't think the extra care will hurt us too badly. I prefer to keep
the IS_ERR_OR_NULL() check because it needs less domain specific
knowledge to be understood, and because it is more robust.
Regards,
Halil
next prev parent reply other threads:[~2021-10-11 18:49 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 [this message]
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
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=20211011204837.7617301b.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.