From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: "Daniel W. S. Almeida" <dwlsalmeida@gmail.com>
Cc: sean@mess.org, kstewart@linuxfoundation.org, allison@lohutok.net,
tglx@linutronix.de, linux-media@vger.kernel.org,
skhan@linuxfoundation.org,
linux-kernel-mentees@lists.linuxfoundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC, WIP, v4 06/11] media: vidtv: add wrappers for memcpy and memset
Date: Sun, 3 May 2020 09:06:34 +0200 [thread overview]
Message-ID: <20200503090634.1b7ae548@coco.lan> (raw)
In-Reply-To: <20200502084038.07c38c4b@coco.lan>
Em Sat, 2 May 2020 08:40:38 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> escreveu:
> Em Sat, 2 May 2020 00:22:11 -0300
> "Daniel W. S. Almeida" <dwlsalmeida@gmail.com> escreveu:
>
> > +u32 vidtv_memcpy(void *to,
> > + const void *from,
> > + size_t len,
> > + u32 offset,
> > + u32 buf_sz)
> > +{
> > + if (buf_sz && offset + len > buf_sz) {
> > + pr_err("%s: overflow detected, skipping. Try increasing the buffer size",
> > + __func__);
> > + return 0;
>
> shouldn't it return an error?
>
> > + }
> > +
> > + memcpy(to, from, len);
> > + return len;
> > +}
When trying to use your memset wrapper, I noticed a few issues there.
The first one is that you should not use __func__ directly at pr_* macros.
Instead, just ensure that you have a pr_fmt() macro that ill be adding
the driver's name and the function, e. g.:
#define pr_fmt(fmt) KBUILD_MODNAME ":%s: " fmt, __func__
Besides that, the parameter order sounded weird:
> > +u32 vidtv_memcpy(void *to,
> > + const void *from,
> > + size_t len,
> > + u32 offset,
> > + u32 buf_sz)
The "to", "offset" and "buf_sz" arguments refer to the "to" buffer,
while "from" and "len" refers to what will be copied from the "from"
into the "to" buffer. Please re-order it, placing first the "to"
args, then "from" arg, and finally the argument that applies to both,
e. g.:
size_t vidtv_memcpy(void *to, size_t to_offset, size_t to_size,
const void *from, size_t len)
(you should notice that I'm using size_t for all args there).
The same is also valid for the memset.
Finally, the places where this function is used require to pass twice
the offset (from patch 08/11):
> + nbytes += vidtv_memcpy(args.dest_buf +
> + args.dest_offset +
> + nbytes,
> + &ts_header,
> + sizeof(ts_header),
> + args.dest_offset + nbytes,
> + args.dest_buf_sz);
That doesn't make much sense. I mean, if the arguments are "buf + offset",
one would expect that the "buf" would be the head of a buffer, and the
function would be adding the offset internally.
So, the best would be to re-define it like:
/**
* vidtv_memcpy() - wrapper routine to be used by MPEG-TS
* generator, in order to avoid going past the
* output buffer.
* @to: Starting element to where a MPEG-TS packet will
* be copied.
* @to_offset: Starting position of the @to buffer to be filled.
* @to_size: Size of the @to buffer.
* @from: Starting element of the buffer to be copied.
* @ten: Number of elements to be copy from @from buffer
* into @to+ @to_offset buffer.
*
* Note:
* Real digital TV demod drivers should not have memcpy
* wrappers. We use it here just because emulating a MPEG-TS
* generation at kernelspace require some extra care.
*
* Return:
* Returns the number of bytes
*/
size_t vidtv_memcpy(void *to, size_t to_offset, size_t to_size,
const void *from, size_t len)
{
if unlikely(to_offset + len > to_size) {
pr_err_ratelimited("overflow detected, skipping. Try increasing the buffer size\n");
return 0;
}
memcpy(to + to_offset, from, len);
return len;
}
Thanks,
Mauro
next prev parent reply other threads:[~2020-05-03 7:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-02 3:22 [RFC, WIP, v4 00/11] media: vidtv: implement a virtual DVB driver Daniel W. S. Almeida
2020-05-02 3:22 ` [RFC, WIP, v4 01/11] media: vidtv: add Kconfig entry Daniel W. S. Almeida
2020-05-02 4:58 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 02/11] media: vidtv: implement a tuner driver Daniel W. S. Almeida
2020-05-02 5:27 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 03/11] media: vidtv: implement a demodulator driver Daniel W. S. Almeida
2020-05-02 5:58 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 04/11] media: vidtv: move config structs into a separate header Daniel W. S. Almeida
2020-05-02 6:02 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 05/11] media: vidtv: add a bridge driver Daniel W. S. Almeida
2020-05-02 6:30 ` Mauro Carvalho Chehab
2020-05-02 21:12 ` Daniel W. S. Almeida
2020-05-02 3:22 ` [RFC, WIP, v4 06/11] media: vidtv: add wrappers for memcpy and memset Daniel W. S. Almeida
2020-05-02 6:40 ` Mauro Carvalho Chehab
2020-05-03 7:06 ` Mauro Carvalho Chehab [this message]
2020-05-02 3:22 ` [RFC, WIP, v4 07/11] media: vidtv: add MPEG TS common code Daniel W. S. Almeida
2020-05-02 7:09 ` Mauro Carvalho Chehab
2020-05-02 22:22 ` Daniel W. S. Almeida
2020-05-03 9:50 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 08/11] media: vidtv: implement a PSI generator Daniel W. S. Almeida
2020-05-03 7:51 ` Mauro Carvalho Chehab
2020-05-06 6:28 ` Daniel W. S. Almeida
2020-05-06 8:36 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 09/11] media: vidtv: implement a PES packetizer Daniel W. S. Almeida
2020-05-03 8:16 ` Mauro Carvalho Chehab
2020-05-06 6:55 ` Daniel W. S. Almeida
2020-05-06 8:59 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 10/11] media: vidtv: Implement a SMPTE 302M encoder Daniel W. S. Almeida
2020-05-03 8:57 ` Mauro Carvalho Chehab
2020-05-02 3:22 ` [RFC, WIP, v4 11/11] media: vidtv: Add a MPEG Transport Stream Multiplexer Daniel W. S. Almeida
2020-05-03 9:13 ` Mauro Carvalho Chehab
2020-05-06 7:05 ` Daniel W. S. Almeida
2020-05-06 9:01 ` Mauro Carvalho Chehab
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=20200503090634.1b7ae548@coco.lan \
--to=mchehab+huawei@kernel.org \
--cc=allison@lohutok.net \
--cc=dwlsalmeida@gmail.com \
--cc=kstewart@linuxfoundation.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=sean@mess.org \
--cc=skhan@linuxfoundation.org \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).