ioctl, copy string from user

[Lukáš Czerner]

On Thu, 29 Apr 2010, Lukáš Czerner wrote:

> Date: Thu, 29 Apr 2010 22:28:31 +0200 (CEST)
> From: Lukáš Czerner <czerner.lukas at gmail.com>
> To: John Baldwin <jhb at freebsd.org>
> Cc: Lukáš Czerner <czerner.lukas at gmail.com>, freebsd-hackers at freebsd.org
> Subject: Re: ioctl, copy string from user
> 
> On Thu, 29 Apr 2010, John Baldwin wrote:
> > > > 
> > > > On Thursday 29 April 2010 1:52:45 pm Lukáš Czerner wrote:
> > > > > Hi,
> > > > > 
> > > > > I know that there are plenty of examples in the kernel code, but I
> > > > > just can not get it working, so maybe I am doing some stupid mistake
> > > > > I am not aware of. Please give me a hint if you can.
> > > > > 
> > > > > What I want to do is simply call the ioctl from the userspace with
> > > > > (char *) argument. Then, in kernel ioctl handling function copy the
> > > > > string argument into the kernel space. I have tried it various ways,
> > > > > everything without any success.
> > > > > 
> > > > > *** Userspace ***
> > > > > char name[MAXLEN];
> > > > > 
> > > > > strncpy(name, argv[1], MAXLEN);
> > > > > fprintf(stdout,"Name: %s\n",name);
> > > > > 
> > > > > if (ioctl(fd, MYIOCTL, name)) {
> > > > 
> > > > On BSD systems, ioctl() copies the data into the kernel for you ahead of 
> > time.  
> > > > What does the definition of MYIOCTL look like?
> > > 
> > > #define MYIOCTL _IOW('M', 0, char *)
> > 
> > Ok.  In that case the argument to ioctl needs to be a pointer to a char *,
> > not the raw char * itself.  Try doing 'ioctl(fd, MYIOCTL, &name)' from 
> > userland to see if that fixes it.
> 
> I have already tried that, but still without any success. The buffer
> remains unchanged (which is weird IMO).
> 
> Just FYI I am using FreeBSD-8.
> > 
> > > > > And the second question. I have commented that I can allocate buffer
> > > > > dynamically, but I suppose that there will be some locks involved so
> > > > > I think I can not just use M_WAITOK, am I right ?
> > > > 
> > > > malloc() and free() acquire their own locks internally, you do not need to 
> > > > hold any locks to call them.
> > > 
> > > I probably does not express what I meant very clearly. My concern is
> > > that when I am calling malloc with M_WAITOK I can sleep (be
> > > rescheduled) and it may be bad thing if I am holding some lock,
> > > because I can block others, am I right ?
> > 
> > Generally yes, but it depends on the lock.  If it is the vn_lock lock then it 
> > is ok to do a blocking malloc().  As a general rule I do try to call malloc()
> > before acquiring locks (basically preallocating) whenever possible.
> 
> So I suppose M_NOWAIT will do the trick when there is no other way
> (preallocations etc..) ? Of course I should test if it does not
> return NULL then.
> 
> Thanks.

Ok, so I have manage to get it working, but I doubt this is the
proper way of doing this:

#define MYIOCTL _IOW('M', 0, char[MAXLEN])

** Userspace **
ioctl(fd, MYIOCTL, &name)

** Kernel **
name = (char *)ap->a_data;
uprintf("Name : %s\n", name);


Apparently I need to tell ioctl how big is the variable I am
providing to it ([MAXLEN]). The odd thing is, when I have a structure
like this:

struct lrfs_attach_info {
	char *name;
	int priority;
};

and I pass the pointer to that structure to the ioctl, it just
works. I can even use the 'name' string from the structure without
any problems, apparently it translates the pointer properly, but I
did not expect this...