Jeunder Yu wrote:
> > geteuid may be better. though i would hope the difference doesn't matter.
>
> The difference is very important for me.
>
> In my application, I am root and change to different uid, create semaphore
> and share memory, make some hand sharking to client app with different uid.
2015年11月20日 下午2:46於 "Ted Unangst" 寫道：
>
> 游俊德 wrote:
> > Hello,
> >
> > I have a question about source code of shm_open and sem_open functions.
> >
> > int
> > shm_open(const char *path, int flags, mode_t mode)
> > {
> >
游俊德 wrote:
> Hello,
>
> I have a question about source code of shm_open and sem_open functions.
>
> int
> shm_open(const char *path, int flags, mode_t mode)
> {
> (skipped)
>
> if (sb,st_uid != getuid()) {
> close(fd
Hello,
I have a question about source code of shm_open and sem_open functions.
int
shm_open(const char *path, int flags, mode_t mode)
{
(skipped)
if (sb,st_uid != getuid()) {
close(fd);
errno = EPERM;
return -1
2013/11/21 Ted Unangst :
> Read the standard again and discovered some more missing features.
>
> 1. sem_open allows setting the value via a fourth argument. Fixed.
>
> 2. Multiple sem_open calls of the same path in the same process are
> supposed to return the same pointer. Not
Read the standard again and discovered some more missing features.
1. sem_open allows setting the value via a fourth argument. Fixed.
2. Multiple sem_open calls of the same path in the same process are
supposed to return the same pointer. Not the same semaphore, the same
pointer. This is mind
On Wed, Nov 20, 2013 at 23:12, Stuart Henderson wrote:
> On 2013/11/20 18:09, Ted Unangst wrote:
>> On Wed, Nov 20, 2013 at 21:59, Stuart Henderson wrote:
>> > graphics/ilmbase hangs during autoconf; it runs something close to this
>>
>> The diff I previously posted seems to fix this. At least, I c
On 2013/11/20 18:09, Ted Unangst wrote:
> On Wed, Nov 20, 2013 at 21:59, Stuart Henderson wrote:
> > graphics/ilmbase hangs during autoconf; it runs something close to this
>
> The diff I previously posted seems to fix this. At least, I could
> repro with a snapshot and now I can't reproduce after
tted one more bug, but it shouldn't affect i386 or amd64.
The spinlock needs to be initialized in sem_open.
> #include
> int
> main()
> {
> sem_t mysem;
>
> if (sem_init(&mysem, 1, 1) == 0) {
> if (sem_wait(&mysem) == 0) {
> sem_post(&mysem);
> sem_destroy(&mysem);
> }
> }
> }
graphics/ilmbase hangs during autoconf; it runs something close to this
#include
int
main()
{
sem_t mysem;
if (sem_init(&mysem, 1, 1) == 0) {
if (sem_wait(&mysem) == 0) {
sem_post(&mysem);
sem_destroy(&mysem);
- sem_t sem = *semp;
+ sem_t sem;
int r;
- if (!semp || !*semp) {
+ if (!semp || !(sem = *semp)) {
errno = EINVAL;
return (-1);
}
@@ -316,7 +313,7 @@ sem_open(const char *name, int oflag, ..
char sempath[SEM_PATH_SIZE];
/lib/librthread/rthread_sem.c,v
retrieving revision 1.12
diff -u -p -r1.12 rthread_sem.c
--- rthread_sem.c 20 Nov 2013 03:16:39 - 1.12
+++ rthread_sem.c 20 Nov 2013 03:32:36 -
@@ -338,7 +338,17 @@ sem_open(const char *name, int oflag, ..
errno = EPERM;
> This may or may not be a working implementation of sem_open.
This is a bit improved version of Ted's diff:
* Add support of shared=1 for sem_init()
* Less memory leaks in error paths
* More strong checks where applicable
This is RFC/FYI status only, still under testing.
--
zhuk@
2013/10/26 Ted Unangst :
> This may or may not be a working implementation of sem_open.
>
> Using tricks similar to those used in shm_open, we create a semaphore
> in a tmp file shared by mmap. This lets other processes share the
> spinlock and counter. Our thrsleep and thrwakeup
> On Sat, Oct 26, 2013 at 00:54, Vadim Zhukov wrote:
> >> +/* SHA256_DIGEST_STRING_LENGTH includes nul */
> >> +/* "/tmp/" + sha256 + ".sem" */
> >
> > Shouldn't this respect the TMPDIR envvar?
>
> No, it's an internal artifact of the implementation.
And furthermore, making additional library fu
On Sat, Oct 26, 2013 at 00:54, Vadim Zhukov wrote:
>> +/* SHA256_DIGEST_STRING_LENGTH includes nul */
>> +/* "/tmp/" + sha256 + ".sem" */
>
> Shouldn't this respect the TMPDIR envvar?
No, it's an internal artifact of the implementation.
2013/10/26 Ted Unangst :
> This may or may not be a working implementation of sem_open.
>
> Using tricks similar to those used in shm_open, we create a semaphore
> in a tmp file shared by mmap. This lets other processes share the
> spinlock and counter. Our thrsleep and thrwakeup
This may or may not be a working implementation of sem_open.
Using tricks similar to those used in shm_open, we create a semaphore
in a tmp file shared by mmap. This lets other processes share the
spinlock and counter. Our thrsleep and thrwakeup syscalls don't really
work between processes,
18 matches
Mail list logo
