On Sat, Apr 23, 2016 at 10:42:52PM +0200, Kamil Rytarowski wrote:
> >> I read in the POSIX resources that the limit is defined by
> >> PATH_MAX or its variation:
> >>
> >> ENAMETOOLONG The length of the name argument exceeds {PATH_MAX}
> >> or a pathname component is longer than {NAME_MAX}.
> >
> > Wait, are sem_open() names names (single components) or whole
> > paths? I thought they were single components.
>
> There are possible limits for whole paths and components. NetBSD keeps
> 14 for the whole name.
That wasn't the question -- the question is what the semantics of
sem_open() names are supposed to be.
The code we have will return EINVAL if the name contains anything
other than a leading slash. Therefore, NAME_MAX seems to be the
applicable limit.
> >> If so, could we export SEM_MAX_NAMELEN to userland header.
> >
> > let's not; it just encourages code that does
> >
> > char name[SEM_MAX_NAMELEN+1];
> >
> > that makes it impossible to safely raise the limit later.
>
> I see, so I think pathconf(2) or similar check is preferred.
Currently there isn't such a check that can return SEM_MAX_NAMELEN.
Best bet is to use NAME_MAX (or PATH_MAX) for buffers you might want
to put semaphore names in, but avoid generating long ones yourself.
> >> Additionally I noted that SEM_VALUE_MAX is defined at least twice
> >> in the code-base, in <semaphore.h> and sys/kern/uipc_sem.c
> >> (thankfully with the same value: ~0U).
> >
> > That would be a bug.
namely: please fix :-)
> >> FreeBSD seems to respect the PATH_MAX property of the name
> >> argument:
> >>
> >> sem_t * _sem_open(const char *name, int flags, ...) { char
> >> path[PATH_MAX];
> >
> > Never put a value of size PATH_MAX on the kernel stack...
> >
> > I don't see any overt reason not to raise the limit to NAME_MAX,
> > though. Seems to be just a matter of how much kernel memory the
> > names are allowed to use.
>
> I'm fine with 14 characters here... but checking the kernel code for
> limit isn't convenient.
Well, it seems reasonable to raise the limit. I have now checked
carefully and there's no reason the limit can't be raised to any value
such that a temporary name buffer can still reasonably be placed on
the kernel stack.
I also noticed that if you read() one of these semaphores you get the
name back... including a null terminator. Where (if anywhere) is the
read behavior documented, and is it supposed to include the null
terminator or not?
--
David A. Holland
dholl...@netbsd.org
