Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 May 2013 16:12:04 -0400
From:      John Baldwin <jhb@FreeBSD.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        arch@freebsd.org
Subject:   Re: Extending MADV_PROTECT
Message-ID:  <51914914.805@FreeBSD.org>
In-Reply-To: <20130511043606.GE3047@kib.kiev.ua>
References:  <201305071433.27993.jhb@freebsd.org> <201305090814.52166.jhb@freebsd.org> <20130509123147.GT3047@kib.kiev.ua> <201305101535.50633.jhb@freebsd.org> <20130511043606.GE3047@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 5/11/13 12:36 AM, Konstantin Belousov wrote:
> On Fri, May 10, 2013 at 03:35:50PM -0400, John Baldwin wrote:
>> Ok, here is a patch for 8 that reworks this to use a procctl().  If this looks
>> reasonable I will port this to HEAD as two pieces: the first to add
>> procctl() and the second to add PROCSPROTECT.
> 
> This looks fine.
> 
> Do we need the genericity of the ioctl for procctl ?
> Ptrace(2) does not need the size encoded.
> 
> I mean, the call is never marshalled to some unknown driver which needs
> a size of parameters unknown to the generic layer. I suppose that all
> additions to procctl() would have the size of the control structures
> pre-defined. Then, you could just do copyin and, if needed, copyout
> discrimating on the command code, and not on the encoding of the size in
> the command.
> 
> Also, command could be int and not long then, eliminating the need for
> compat32 wrapper.

Well, the generic-ness of ioctl() seemed useful to me.  Also, I think
with this model you could make fo_ioctl() for a process fd just do this:

proc_ioctl(..., u_long cmd, caddr_t data)
{

	pid = <get pid from f_data>;
	return (kern_procctl(td, P_PID, pid, cmd, data));
}

So you could reuse procctl constants as ioctls for proc descriptors.  It
is true that unlike drivers there is currently no method to provide a
"hook" to support new commands (they would just have to be added by hand
into sys_process.c for now).  Also, if we need to "thunk" structures for
compat32 support in the future it is better if the kern_procctl()
version takes a KVA rather than a UVA.

OTOH, it is more boilerplate code to put in.

In terms of a compat32 wrapper: id_t is a uint64_t, so a wrapper would
be required regardless.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51914914.805>