B1;2005;0c(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Tue, 3 Nov 2009, [email protected] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14537
>
> Summary: missing compat_ioctl on x86_64
> Product: Platform Specific/Hardware
> Version: 2.5
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: x86-64
> AssignedTo: [email protected]
> ReportedBy: [email protected]
> Regression: No
>
>
> I used to run 64bit userspace on 64bit kernel but I recently tried to run a
> 64bit kernel with as minimal as possible as 64bit userspace (that is
> rpm+glibc+... in order to mananage 64bit kernel packages).
>
> This revealed several missing compat_ioctl.
> Running 32bit gnome-terminal on a 64 bit kernel results in the following in
> dmesg:
>
> - with gnome-terminal:
> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> arg(48111345) on /dev/pts/0
> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> arg(4811134a) on /dev/pts/0
> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> arg(48111351) on /dev/pts/0
That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL
which has no ioctl nr 0xb. Also I have no idea why a sound sequencer
ioctl should work on /dev/pts/0 :)
> - with X:
> ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on
> /var/log/Xorg.0.log
> ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on
> /var/log/Xorg.0.log
'd' is used by pcmcia and DRM. DRM sounds more likely for X, but I
have a hard time to understand why a DRM ioctl should work on
/var/log/Xorg.0.log :)
For both gnome-terminal and X strace should tell you more.
> - when trying to suspend:
> ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12}
> arg(ffc190ec) on /dev/snapshot
> ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000806)
> on /dev/snapshot
snapshot_ioctl seems to lack compat support completely. Raphael ??
> Of course we'd better run 64bit userspace on 64bit kernel but 32bit
> applications are supposed to still work.
> Some may say some of them are too hardware specific but still it would be best
> to fix them...
>
> Tested with 2.6.31.5 and 2.6.32-rc5.
Thanks,
tglx
Thomas Gleixner <[email protected]> writes:
>> - with gnome-terminal:
>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
>> arg(48111345) on /dev/pts/0
>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
>> arg(4811134a) on /dev/pts/0
>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
>> arg(48111351) on /dev/pts/0
>
> That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL
> which has no ioctl nr 0xb. Also I have no idea why a sound sequencer
> ioctl should work on /dev/pts/0 :)
ioctl numbers are not always unique (I haven't checked if this is the
case here). But it might be that it's some other ioctl actually.
One easy way to check is to install debuginfo and set break points
on ioctl in gdb and then look at the sources in the backtrace.
-Andi
--
[email protected] -- Speaking for myself only.
Andi Kleen <[email protected]> writes:
> Thomas Gleixner <[email protected]> writes:
>
>>> - with gnome-terminal:
>>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
>>> arg(48111345) on /dev/pts/0
>>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
>>> arg(4811134a) on /dev/pts/0
>>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
>>> arg(48111351) on /dev/pts/0
>>
>> That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL
>> which has no ioctl nr 0xb. Also I have no idea why a sound sequencer
>> ioctl should work on /dev/pts/0 :)
>
> ioctl numbers are not always unique (I haven't checked if this is the
> case here). But it might be that it's some other ioctl actually.
'S' is also used for streams ioctls, 0x530b is I_FIND.
Andreas.
--
Andreas Schwab, [email protected]
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84 5EC7 45C6 250E 6F00 984E
"And now for something completely different."
On Wed, 04 Nov 2009 16:41:34 +0100 Andreas Schwab wrote:
> Andi Kleen <[email protected]> writes:
>
> > Thomas Gleixner <[email protected]> writes:
> >
> >>> - with gnome-terminal:
> >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> >>> arg(48111345) on /dev/pts/0
> >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> >>> arg(4811134a) on /dev/pts/0
> >>> ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> >>> arg(48111351) on /dev/pts/0
> >>
> >> That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL
> >> which has no ioctl nr 0xb. Also I have no idea why a sound sequencer
> >> ioctl should work on /dev/pts/0 :)
> >
> > ioctl numbers are not always unique (I haven't checked if this is the
> > case here). But it might be that it's some other ioctl actually.
>
> 'S' is also used for streams ioctls, 0x530b is I_FIND.
Is that last 'S' in the kernel source tree?
If so, I'll have to find/add it to Documentation/ioctl/ioctl-number.txt,
which I sent an update patch for about 2 weeks ago. For 'S', it now lists:
'S' all linux/cdrom.h conflict!
'S' 80-81 scsi/scsi_ioctl.h conflict!
'S' 82-FF scsi/scsi.h conflict!
+'S' 00-7F sound/asequencer.h conflict!
---
~Randy
On Wednesday 04 November 2009, Thomas Gleixner wrote:
> B1;2005;0c(switched to email. Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Tue, 3 Nov 2009, [email protected] wrote:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=14537
> >
> > Summary: missing compat_ioctl on x86_64
> > Product: Platform Specific/Hardware
> > Version: 2.5
> > Platform: All
> > OS/Version: Linux
> > Tree: Mainline
> > Status: NEW
> > Severity: normal
> > Priority: P1
> > Component: x86-64
> > AssignedTo: [email protected]
> > ReportedBy: [email protected]
> > Regression: No
> >
> >
> > I used to run 64bit userspace on 64bit kernel but I recently tried to run a
> > 64bit kernel with as minimal as possible as 64bit userspace (that is
> > rpm+glibc+... in order to mananage 64bit kernel packages).
> >
> > This revealed several missing compat_ioctl.
> > Running 32bit gnome-terminal on a 64 bit kernel results in the following in
> > dmesg:
> >
> > - with gnome-terminal:
> > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> > arg(48111345) on /dev/pts/0
> > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> > arg(4811134a) on /dev/pts/0
> > ioctl32(gnome-terminal:1755): Unknown cmd fd(19) cmd(0000530b){t:'S';sz:0}
> > arg(48111351) on /dev/pts/0
>
> That looks more like an application problem. 'S' is SNDRV_SEQ_IOCTL
> which has no ioctl nr 0xb. Also I have no idea why a sound sequencer
> ioctl should work on /dev/pts/0 :)
>
> > - with X:
> > ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on
> > /var/log/Xorg.0.log
> > ioctl32(X:2803): Unknown cmd fd(0) cmd(40086408){t:'d';sz:8} arg(ff840a68) on
> > /var/log/Xorg.0.log
>
> 'd' is used by pcmcia and DRM. DRM sounds more likely for X, but I
> have a hard time to understand why a DRM ioctl should work on
> /var/log/Xorg.0.log :)
>
> For both gnome-terminal and X strace should tell you more.
>
> > - when trying to suspend:
> > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12}
> > arg(ffc190ec) on /dev/snapshot
> > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000806)
> > on /dev/snapshot
>
> snapshot_ioctl seems to lack compat support completely. Raphael ??
It does, but that wouldn't work anyway. s2disk is one of the things that have
to be native.
Rafael
Hi!
> > > - when trying to suspend:
> > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12}
> > > arg(ffc190ec) on /dev/snapshot
> > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000806)
> > > on /dev/snapshot
> >
> > snapshot_ioctl seems to lack compat support completely. Raphael ??
>
> It does, but that wouldn't work anyway. s2disk is one of the things that have
> to be native.
Actually... it would be nice to fix that one day, if someone submitted
nice patch... :-).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Saturday 07 November 2009, Pavel Machek wrote:
> Hi!
>
> > > > - when trying to suspend:
> > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12}
> > > > arg(ffc190ec) on /dev/snapshot
> > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000806)
> > > > on /dev/snapshot
> > >
> > > snapshot_ioctl seems to lack compat support completely. Raphael ??
> >
> > It does, but that wouldn't work anyway. s2disk is one of the things that have
> > to be native.
>
> Actually... it would be nice to fix that one day, if someone submitted
> nice patch... :-).
It must be fixed in s2disk first, but that would probably require us to drop
support for older kernels. Which is not unthinkable, but might hurt some
users.
Thanks,
Rafael
Hi!
> > > > > - when trying to suspend:
> > > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(400c330d){t:'3';sz:12}
> > > > > arg(ffc190ec) on /dev/snapshot
> > > > > ioctl32(s2disk:8164): Unknown cmd fd(4) cmd(4004330a){t:'3';sz:4} arg(00000806)
> > > > > on /dev/snapshot
> > > >
> > > > snapshot_ioctl seems to lack compat support completely. Raphael ??
> > >
> > > It does, but that wouldn't work anyway. s2disk is one of the things that have
> > > to be native.
> >
> > Actually... it would be nice to fix that one day, if someone submitted
> > nice patch... :-).
>
> It must be fixed in s2disk first, but that would probably require us to drop
> support for older kernels. Which is not unthinkable, but might hurt some
> users.
It should be possible to check compat_task() and provide interface
userland expects.
But yes, improving interface to be same for 32 and 64bit would
probably be the way, too. (Or did you have something else in mind?)
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Saturday 07 November 2009, Rafael J. Wysocki wrote:
> > Actually... it would be nice to fix that one day, if someone submitted
> > nice patch... :-).
>
> It must be fixed in s2disk first, but that would probably require us to drop
> support for older kernels. Which is not unthinkable, but might hurt some
> users.
You don't need to drop support for older kernels if s2disk simply tries the
new interface first and falls back to the current one if that fails.
Arnd <><
On Saturday 07 November 2009, Arnd Bergmann wrote:
> On Saturday 07 November 2009, Rafael J. Wysocki wrote:
> > > Actually... it would be nice to fix that one day, if someone submitted
> > > nice patch... :-).
> >
> > It must be fixed in s2disk first, but that would probably require us to drop
> > support for older kernels. Which is not unthinkable, but might hurt some
> > users.
>
> You don't need to drop support for older kernels if s2disk simply tries the
> new interface first and falls back to the current one if that fails.
Compat ioctls support is not possible with the old interface.
Thanks,
Rafael
On Saturday 07 November 2009, Rafael J. Wysocki wrote:
> On Saturday 07 November 2009, Arnd Bergmann wrote:
> > On Saturday 07 November 2009, Rafael J. Wysocki wrote:
> > > > Actually... it would be nice to fix that one day, if someone submitted
> > > > nice patch... :-).
> > >
> > > It must be fixed in s2disk first, but that would probably require us to drop
> > > support for older kernels. Which is not unthinkable, but might hurt some
> > > users.
> >
> > You don't need to drop support for older kernels if s2disk simply tries the
> > new interface first and falls back to the current one if that fails.
>
> Compat ioctls support is not possible with the old interface.
Right, but that doesn't imply dropping support for something that is
working right now. The interesting case is people upgrading the user
space or the kernel without breaking stuff.
Arnd <><
On Sat, 7 Nov 2009, Rafael J. Wysocki wrote:
> On Saturday 07 November 2009, Arnd Bergmann wrote:
> > On Saturday 07 November 2009, Rafael J. Wysocki wrote:
> > > > Actually... it would be nice to fix that one day, if someone submitted
> > > > nice patch... :-).
> > >
> > > It must be fixed in s2disk first, but that would probably require us to drop
> > > support for older kernels. Which is not unthinkable, but might hurt some
> > > users.
> >
> > You don't need to drop support for older kernels if s2disk simply tries the
> > new interface first and falls back to the current one if that fails.
>
> Compat ioctls support is not possible with the old interface.
That does not matter.
If you create a new interface which is 32/64bit safe and keep the old
interface around for compability reasons then a new user space will
try the new interface first and if that is not available due to older
kernel version it uses the old interface. If old user space talks to a
newer kernel it will use the old interface with its current
limitations. Over time you can phase out the old interface in the
kernel.
Thanks,
tglx