linux-kernel - Re: Kevent POSIX timers support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20061127.102443.74556125.davem@davemloft.net>
Date:	Mon, 27 Nov 2006 10:24:43 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	drepper@...hat.com
Cc:	johnpol@....mipt.ru, akpm@...l.org, netdev@...r.kernel.org,
	zach.brown@...cle.com, hch@...radead.org,
	chase.venters@...entec.com, johann.borck@...sedata.com,
	linux-kernel@...r.kernel.org, jeff@...zik.org, aviro@...hat.com
Subject: Re: Kevent POSIX timers support.

From: Ulrich Drepper <drepper@...hat.com>
Date: Mon, 27 Nov 2006 10:20:50 -0800

> Evgeniy Polyakov wrote:
> >> We need to pass the data in the sigev_value meember of the struct 
> >> sigevent structure passed to timer_create to the caller.  I don't see it 
> >> being done here nor when the timer is created.  Do I miss something? 
> >> The sigev_value value should be stored in the user/ptr member of struct 
> >> ukevent.
> > 
> > sigev_value was stored in k_itimer structure, I just do not know where
> > to put it in the ukevent provided to userspace - it can be placed in
> > pointer value if you like.
> 
> sigev_value is a union and the largest element is a pointer.  So, 
> transporting the pointer value is sufficient and it should be passed up 
> to the user in the ptr member of struct ukevent.

Now we'll have to have a compat layer for 32-bit/64-bit environments
thanks to POSIX timers, which is rediculious.

This is exactly the kind of thing I was hoping we could avoid when
designing these data structures.  No pointers, no non-fixed sized
types, only types which are identically sized and aligned between
32-bit and 64-bit environments.

It's OK to have these problems for things designed a long time ago
before 32-bit/64-bit compat issues existed, but for new stuff no
way.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/