linux-kernel - Re: Which one corresponds to ioctl in the file

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: <201112011245.16461.arnd@arndb.de>
Date:	Thu, 1 Dec 2011 12:45:16 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Tvrtko Ursulin <tvrtko.ursulin@...lan.co.uk>
Cc:	Peng Yu <pengyu.ut@...il.com>, linux-kernel@...r.kernel.org
Subject: Re: Which one corresponds to ioctl in the file_operations struct in linux/fs.h?

On Thursday 01 December 2011, Tvrtko Ursulin wrote:
> On Thursday 01 Dec 2011 07:40:49 Peng Yu wrote:
> > Hi,
> > 
> > I have some driver code for older version of kernel. It refers to
> > ioctl in the file_operations struct. But this field is change in
> > kernel 3.0.0-13
> > 
> > I find the following in linux/fs.h
> > 
> > 1566   long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
> > 1567   long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
> > 
> > Does anybody know which one I should use in order to migrate the
> > driver code to the newer version of kernel? Thanks!
> 
> From Documentation/filesystems/vfs.txt:
> 
>   unlocked_ioctl: called by the ioctl(2) system call.
> 
>   compat_ioctl: called by the ioctl(2) system call when 32 bit system calls
>          are used on 64 bit kernels.
> 
> You don't need compat_ioctl if your ioctl arguments are 32/64-bit safe.

Actually, you should always provide a .compat_ioctl pointer, but if
all commands are 32/64 bit safe, it can point to the same function,
or (slightly safer) be a wrapper like

static long my_compat_ioctl(struct file *f, unsigned int cmd, unsigned long arg)
{
	return my_ioctl(f, cmd, (unsigned long)compat_ptr(arg));
}

Strictly speaking, the first option assumes that all commands
take no argument or integers directly encoded in the 'arg', while
the second option assumes that all commands take either no argument
or a pointer to an argument in memory.

	Arnd
--
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/