linux-kernel - Re: [patch 2/13] signal/timer/event fds v6

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <m1mz29xi8g.fsf@ebiederm.dsl.xmission.com>
Date:	Mon, 19 Mar 2007 11:20:47 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Davide Libenzi <davidel@...ilserver.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Oleg Nesterov <oleg@...sign.ru>
Subject: Re: [patch 2/13] signal/timer/event fds v6 - signalfd core ...

Davide Libenzi <davidel@...ilserver.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
-
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/