All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: kernel-janitors@vger.kernel.org
Subject: Re: [patch] exofs: add a cap on the memcpy() size
Date: Mon, 30 Jan 2012 13:37:29 +0000	[thread overview]
Message-ID: <4F269D19.5030200@panasas.com> (raw)
In-Reply-To: <20120130075949.GA22364@elgon.mountain>

On 01/30/2012 09:59 AM, Dan Carpenter wrote:
> This data comes from the device, so probably it's fairly trustworthy but
> it makes the static checkers happy if we check it.
> 
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> 
> diff --git a/fs/exofs/super.c b/fs/exofs/super.c
> index d22cd16..755812a 100644
> --- a/fs/exofs/super.c
> +++ b/fs/exofs/super.c
> @@ -529,6 +529,8 @@ static int exofs_devs_2_odi(struct exofs_dt_device_info *dt_dev,
>  			     struct osd_dev_info *odi)
>  {
>  	odi->systemid_len = le32_to_cpu(dt_dev->systemid_len);
> +	if (odi->systemid_len > OSD_SYSTEMID_LEN)
> +		return -EINVAL;
>  	memcpy(odi->systemid, dt_dev->systemid, odi->systemid_len);
>  
>  	odi->osdname_len = le32_to_cpu(dt_dev->osdname_len);

Hi Dan

I was going over this code and for the life of me I can't remember
why I have dt_dev->systemid_len at all. The ->systemid field
is just a constant 20 bytes buffer that is always there. at all
ends of the spectrum. (Including user-mode mkfs.exofs)

I think my thought was that dt_dev->systemid_len could be
either 20 or zero, for ignoring it.

I think I'd like something like:
-  	memcpy(odi->systemid, dt_dev->systemid, odi->systemid_len);
+	if (likely(odi->systemid_len))
+ 		memcpy(odi->systemid, dt_dev->systemid, OSD_SYSTEMID_LEN);

Which should also make the static checkers happy. What do you think?

Thanks
Boaz

  reply	other threads:[~2012-01-30 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30  7:59 [patch] exofs: add a cap on the memcpy() size Dan Carpenter
2012-01-30 13:37 ` Boaz Harrosh [this message]
2012-01-30 13:44 ` Dan Carpenter
2012-01-30 13:50 ` Boaz Harrosh
2012-01-30 14:01 ` Dan Carpenter
2012-01-30 16:20 ` Boaz Harrosh

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=4F269D19.5030200@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=kernel-janitors@vger.kernel.org \
    /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.