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: <4A592C09.8060104@msgid.tls.msk.ru>
Date:	Sun, 12 Jul 2009 04:19:21 +0400
From:	Michael Tokarev <mjt@....msk.ru>
To:	Pavel Machek <pavel@....cz>
CC:	Linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: compat ioctl32 for /dev/snapshot?

Pavel Machek wrote:
> On Mon 2009-05-04 13:29:22, Michael Tokarev wrote:
>> Is there any reason why 32-bit uswsusp &Friends does not work
>> on 64bits kernel?
>>
>> For one, 32bits s2disk produces the following when trying to
>> suspend:
>>
>>  ioctl32(s2disk:4134): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12} arg(ff853554) on /dev/snapshot
>>  ioctl32(s2disk:4134): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000805) on /dev/snapshot
>>
>> this is coming from:
>>
>>     error = ioctl(dev, SNAPSHOT_SET_SWAP_AREA, &swap);
>>     if (error && !offset)
>>             error = ioctl(dev, SNAPSHOT_SET_SWAP_FILE, blkdev);
>>
>> but I guess (just guess!) that other SNAPSHOT_* operations will
>> also fail the same way.
>>
>> Is there a reason why those are not in compat_ioctl?
> 
> Lazyness...?
> 
> Patch would be welcome.

Pavel, you really should take a look at the original thread.

As I mentioned in my first email, I'm not the right person to
do the patch.  But regardless, I spent about a day understanding
this stuff (or trying to, anyway) - 100% useless day - and when
I thought I have a patch someone else spoken up and said this
way (compat_ioctl) is the wrong approach now.  And sent another,
also trivial patch, adding compat calls right to the proper
place in kernel/power.c.  Which (the patch) has been ignored
too.

So "welcome" is a wrong word here, and I'm sorry about that.

 > On 4GB machine, running 64bit kernel (but
> staying with 32bit userland) makes sense...

This is exactly what I'm running here by the way.
But regardless, uswsusp should be fixed too before it will
be useful for that.  And fixing uswsusp is not trivial,
unlike kernel side.  But having in mind amount of useless
jumping needed just for the trivial kernel part, for a
20-minute patch, -- there's not much hope really.  (I
wanted to fix it too, initially, -- not any more).

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ