linux-ext4 - Re: ioctl32

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 25 Jul 2009 10:46:10 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Eric Sandeen <sandeen@...hat.com>,
	Andreas Dilger <adilger@....com>,
	Ron Johnson <ron.l.johnson@....net>, linux-ext4@...r.kernel.org
Subject: Re: ioctl32

On Fri, Jul 24, 2009 at 06:26:56PM +0200, Andi Kleen wrote:
> > /* pointer to compatible structure or no argument */
> > #define COMPATIBLE_IOCTL(cmd) \
> >         { (cmd), do_ioctl32_pointer },
> 
> 
> The modern way to do this is to use the ->compat_ioctl VFS
> method. COMPATIBLE_IOCTL etc are all obsolete.
> 
> > I think adding COMPATIBLE_IOCTL(FS_IOC_FIEMAP); to fs/compat_ioctl.c
> > should be enough, I'll try to get it tested tomorrow.
> 
> Nope, add a ->compat_ioctl 
> 
> When your ioctl is already a unlocked_ioctl you can just use
> the same function. If not convert to unlocked_ioctl first.

fiemap is handled in generic code and never enters ->whatever_ioctl.
Because of that there are only two ways to handle it:

  (1) add it to the static translation table in fs/compat_ioctl.c
  (2) add a special case to compat_sys_ioctl

Number one is the much simpler solution for a fully compatible ioctl.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html