Re: [patch 2/13] signal/timer/event fds v6 - signalfd core ...

[ebiederm@xmission.com (Eric W. Biederman)]

Davide Libenzi <davidel@xmailserver.org> writes:

> struct signalfd_siginfo {
> 	__u32 signo;	/* si_signo */
> 	__s32 err;	/* si_errno */
> 	__s32 code;	/* si_code */
> 	__u32 pid;	/* si_pid */
> 	__u32 uid;	/* si_uid */
> 	__s32 fd;	/* si_fd */
> 	__u32 tid;	/* si_fd */  
> 	__u32 band;	/* si_band */
> 	__u32 overrun;	/* si_overrun */
> 	__u32 trapno;	/* si_trapno */
> 	__s32 status;	/* si_status */
> 	__s32 svint;	/* si_int */
> 	__u64 svptr;	/* si_ptr */
> 	__u64 utime;	/* si_utime */
> 	__u64 stime;	/* si_stime */
> 	__u64 addr;	/* si_addr */
> };

Shouldn't we pad this to 128 bytes like we do siginfo in case there are
more fields we need to include, or we need to extend the size of some
field?

I'm tempted to suggest we have a per arch function that tests current
to see if we are in a compat process or not so we can just use
siginfo.  But that is probably overkill.

> +
> +
> +struct signalfd_ctx {
> +	struct list_head lnk;
> +	wait_queue_head_t wqh;
> +	sigset_t sigmask;
> +	struct task_struct *tsk;
> +};

I think you want to use a struct pid *pid instead of a pointer to the
task struct here.  It is slightly less efficient (one more
dereference) but it means that we won't pin the task struct in memory
indefinitely.  Pinning the task_struct like this makes for a very
interesting way to get around the limits on the number of processes a
user can have.

Eric