All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: "Daniel W. S. Almeida" <dwlsalmeida@gmail.com>
Cc: kstewart@linuxfoundation.org, sean@mess.org,
	linux-kernel@vger.kernel.org, tglx@linutronix.de,
	linux-kernel-mentees@lists.linuxfoundation.org,
	allison@lohutok.net, linux-media@vger.kernel.org
Subject: Re: [Linux-kernel-mentees] [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
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2020-05-03  7:06 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-02  3:22 [Linux-kernel-mentees] [RFC, WIP, v4 00/11] media: vidtv: implement a virtual DVB driver Daniel W. S. Almeida
2020-05-02  3:22 ` Daniel W. S. Almeida
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 01/11] media: vidtv: add Kconfig entry Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  4:58   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-02  4:58     ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 02/11] media: vidtv: implement a tuner driver Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  5:27   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-02  5:27     ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 03/11] media: vidtv: implement a demodulator driver Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  5:58   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-02  5:58     ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 04/11] media: vidtv: move config structs into a separate header Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  6:02   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-02  6:02     ` Mauro Carvalho Chehab
2020-05-02  9:28   ` kbuild test robot
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 05/11] media: vidtv: add a bridge driver Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  6:30   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-02  6:30     ` Mauro Carvalho Chehab
2020-05-02 21:12     ` [Linux-kernel-mentees] " Daniel W. S. Almeida
2020-05-02 21:12       ` Daniel W. S. Almeida
2020-05-02 10:05   ` kbuild test robot
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 06/11] media: vidtv: add wrappers for memcpy and memset Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  6:40   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-02  6:40     ` Mauro Carvalho Chehab
2020-05-03  7:06     ` Mauro Carvalho Chehab [this message]
2020-05-03  7:06       ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 07/11] media: vidtv: add MPEG TS common code Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  7:09   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-02  7:09     ` Mauro Carvalho Chehab
2020-05-02 22:22     ` [Linux-kernel-mentees] " Daniel W. S. Almeida
2020-05-02 22:22       ` Daniel W. S. Almeida
2020-05-03  9:50       ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-03  9:50         ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 08/11] media: vidtv: implement a PSI generator Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-03  7:51   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-03  7:51     ` Mauro Carvalho Chehab
2020-05-06  6:28     ` [Linux-kernel-mentees] " Daniel W. S. Almeida
2020-05-06  6:28       ` Daniel W. S. Almeida
2020-05-06  8:36       ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-06  8:36         ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 09/11] media: vidtv: implement a PES packetizer Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-03  8:16   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-03  8:16     ` Mauro Carvalho Chehab
2020-05-06  6:55     ` [Linux-kernel-mentees] " Daniel W. S. Almeida
2020-05-06  6:55       ` Daniel W. S. Almeida
2020-05-06  8:59       ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-06  8:59         ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 10/11] media: vidtv: Implement a SMPTE 302M encoder Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-03  8:57   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-03  8:57     ` Mauro Carvalho Chehab
2020-05-02  3:22 ` [Linux-kernel-mentees] [RFC, WIP, v4 11/11] media: vidtv: Add a MPEG Transport Stream Multiplexer Daniel W. S. Almeida
2020-05-02  3:22   ` Daniel W. S. Almeida
2020-05-02  9:41   ` kbuild test robot
2020-05-03  9:13   ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
2020-05-03  9:13     ` Mauro Carvalho Chehab
2020-05-06  7:05     ` [Linux-kernel-mentees] " Daniel W. S. Almeida
2020-05-06  7:05       ` Daniel W. S. Almeida
2020-05-06  9:01       ` [Linux-kernel-mentees] " Mauro Carvalho Chehab
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=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 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.