[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Help to fix a bug on the arbiter
From: |
Joan Lledó |
Subject: |
Help to fix a bug on the arbiter |
Date: |
Fri, 10 Apr 2020 16:47:21 +0200 (CEST) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
Hello,
I'm blocked trying to solve a bug I found in the option parsing of the
arbiter, at:
http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/pci-arbiter/options.c#n135
strtol() returns 0 if it wasn't able to convert the input, for instance,
-d jj will set h->curset->domain to 0, which means giving the permission
over the domain 0 and all it's devices. It's worst on system with no PCI
express, since the domain 0 is the only domain and therefore permission
over all devices on the system is granted.
I wrote a patch to solve it, something like:
static long int
parse_number (const char *s)
{
long int val;
char *endptr;
errno = 0;
val = strtol (s, &endptr, 16);
if (*endptr != '\0' || errno)
errno = EINVAL;
return val;
}
...
case 'd':
h->curset->domain = parse_number (arg);
if (errno)
PERR (errno, "Invalid domain");
break;
Testing it with settrans works great, but when trying it with fsysopts,
the behavior is the same, h->curset->domain ends up set to 0 and
permission over all devices is granted.
In the debugger, I see that errno is correctly set to EINVAL and PERR is
called, but after that the thread continues, it reaches the case
ARGP_KEY_SUCCESS and the new permissions are applied.
Any idea on why it's this patch working fine for settrans but not for
fsysopts?
- Help to fix a bug on the arbiter,
Joan Lledó <=