From: Emil Velikov <emil.l.velikov@gmail.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: emil.l.velikov@gmail.com,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 2/3] nouveau: sanitise NOUVEAU_LIBDRM_*_LIMIT_PERCENT input
Date: Thu, 13 Mar 2014 01:11:25 +0000 [thread overview]
Message-ID: <532105BD.7040704@gmail.com> (raw)
In-Reply-To: <CAKb7UvgC=9OpBRAc5NFWF-iRJHVJeO8=4MB=mxB4fxdVYTwSEw@mail.gmail.com>
On 13/03/14 00:49, Ilia Mirkin wrote:
> On Wed, Mar 12, 2014 at 4:45 PM, Emil Velikov <emil.l.velikov@gmail.com> wrote:
>> Current handling relies on atoi which does not detect errors
>> additionally, any integer value will be considered as a valid
>> percent.
>>
>> Resolve that by using strtol and limiting the value within
>> the 5-100 (percent) range.
>>
>> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
>> ---
>> nouveau/nouveau.c | 24 +++++++++++++++---------
>> 1 file changed, 15 insertions(+), 9 deletions(-)
>>
>> diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c
>> index d6013db..06cd804 100644
>> --- a/nouveau/nouveau.c
>> +++ b/nouveau/nouveau.c
>> @@ -76,7 +76,7 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev)
>> struct nouveau_device *dev = &nvdev->base;
>> uint64_t chipset, vram, gart, bousage;
>> drmVersionPtr ver;
>> - int ret;
>> + int ret, limit;
>> char *tmp;
>>
>> #ifdef DEBUG
>> @@ -121,16 +121,22 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev)
>>
>> nvdev->close = close;
>>
>> + nvdev->vram_limit_percent = 80;
>> tmp = getenv("NOUVEAU_LIBDRM_VRAM_LIMIT_PERCENT");
>> - if (tmp)
>> - nvdev->vram_limit_percent = atoi(tmp);
>> - else
>> - nvdev->vram_limit_percent = 80;
>> + if (tmp) {
>> + limit = strtol(tmp, NULL, 10);
>> + if (limit >= 5 && limit <= 100)
>> + nvdev->vram_limit_percent = limit;
>> + }
>
> Wouldn't it be easier to just clamp the value no matter what? i.e.
> leave the current code alone, and add a clamp helper function + use
> it? These are pretty rare env vars to set... presumably the person
> setting them knows what they're doing. And if not, they get what they
> deserve.
>
> On a related topic, I'd personally rather not throw in arbitrary
> restrictions to code like this -- it makes debugging harder later on.
> (e.g. what's wrong with 0 percent? let's say i want to disable
> gart/vram entirely?)
>
Valid arguments, thanks.
-Emil
>> +
>> + nvdev->gart_limit_percent = 80;
>> tmp = getenv("NOUVEAU_LIBDRM_GART_LIMIT_PERCENT");
>> - if (tmp)
>> - nvdev->gart_limit_percent = atoi(tmp);
>> - else
>> - nvdev->gart_limit_percent = 80;
>> + if (tmp) {
>> + limit = strtol(tmp, NULL, 10);
>> + if (limit >= 5 && limit <= 100)
>> + nvdev->gart_limit_percent = limit;
>> + }
>> +
>> DRMINITLISTHEAD(&nvdev->bo_list);
>> nvdev->base.object.oclass = NOUVEAU_DEVICE_CLASS;
>> nvdev->base.lib_version = 0x01000000;
>> --
>> 1.9.0
>>
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-03-13 1:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-12 20:45 [PATCH 1/3] nouveau: cleanup error handling during nouveau_device_wrap Emil Velikov
2014-03-12 20:45 ` [PATCH 2/3] nouveau: sanitise NOUVEAU_LIBDRM_*_LIMIT_PERCENT input Emil Velikov
2014-03-13 0:49 ` Ilia Mirkin
2014-03-13 1:11 ` Emil Velikov [this message]
2014-03-12 20:45 ` [PATCH 3/3] freedreno: do not leak drmVersion Emil Velikov
2014-03-13 1:01 ` Rob Clark
2014-03-13 0:45 ` [PATCH 1/3] nouveau: cleanup error handling during nouveau_device_wrap Ilia Mirkin
2014-03-13 1:04 ` Emil Velikov
2014-03-13 1:05 ` Ilia Mirkin
2014-03-13 1:24 ` Emil Velikov
2014-03-13 1:27 ` Ilia Mirkin
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=532105BD.7040704@gmail.com \
--to=emil.l.velikov@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=imirkin@alum.mit.edu \
/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.