Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1300035 > unrolled thread

Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl

Started bySudip Mukherjee <sudipm.mukherjee@gmail.com>
First post2016-01-02 07:40 +0100
Last post2016-01-07 16:20 +0100
Articles 6 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-01-02 07:40 +0100
    Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl Arnd Bergmann <arnd@arndb.de> - 2016-01-02 23:50 +0100
      Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl Sudip Mukherjee <sudipm.mukherjee@gmail.com> - 2016-01-04 14:20 +0100
        Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl Arnd Bergmann <arnd@arndb.de> - 2016-01-04 14:30 +0100
        Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl Bamvor Jian Zhang <bamvor.zhangjian@linaro.org> - 2016-01-06 14:00 +0100
          Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl Arnd Bergmann <arnd@arndb.de> - 2016-01-07 16:20 +0100

#1300035 — Re: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl

FromSudip Mukherjee <sudipm.mukherjee@gmail.com>
Date2016-01-02 07:40 +0100
SubjectRe: [Y2038] [PATCH v2 2/2] ppdev: add support for compat ioctl
Message-ID<qMo13-4Eu-1@gated-at.bofh.it>
On Fri, Jan 01, 2016 at 11:09:45PM +0100, Arnd Bergmann wrote:
> On Friday 01 January 2016 10:34:25 Sudip Mukherjee wrote:
> > > Did you happen to check with both 32-bit and 64-bit user space on a
> > > 64-bit kernel? This is one of the things that was not working originally
> > > but should work now.
> > 
> > I dont think I can manage 32 bit userspace on 64-bit kernel here. But I
> > can definitely check it on a kvm guest.
> 
> Just to be sure we are talking about the same thing: you mean running a 64-bit
> kernel in a kvm guest with a 32-bit file system, right? Running a 32-bit
> kvm guest on a 64-bit host would not be interesting of course.

The kvm (actually qemu, started from virt-manager with -enable-kvm) that
I just configured shows the following:

lscpu shows:

Architecture:          i686
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 6
Stepping:              3
CPU MHz:               2993.200
BogoMIPS:              5986.40
Virtualization:        VT-x
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              4096K

uname -i shows:
i686


Will it be ok to test in this one?

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1300142

FromArnd Bergmann <arnd@arndb.de>
Date2016-01-02 23:50 +0100
Message-ID<qMD9M-5yh-11@gated-at.bofh.it>
In reply to#1300035
On Saturday 02 January 2016 11:59:29 Sudip Mukherjee wrote:
> > 
> > Just to be sure we are talking about the same thing: you mean running a 64-bit
> > kernel in a kvm guest with a 32-bit file system, right? Running a 32-bit
> > kvm guest on a 64-bit host would not be interesting of course.
> 
> The kvm (actually qemu, started from virt-manager with -enable-kvm) that
> I just configured shows the following:
> 
> lscpu shows:
> 
> Architecture:          i686
> CPU op-mode(s):        32-bit, 64-bit
> Byte Order:            Little Endian
> CPU(s):                1
> On-line CPU(s) list:   0
> Thread(s) per core:    1
> Core(s) per socket:    1
> Socket(s):             1
> Vendor ID:             GenuineIntel
> CPU family:            6
> Model:                 6
> Stepping:              3
> CPU MHz:               2993.200
> BogoMIPS:              5986.40
> Virtualization:        VT-x
> Hypervisor vendor:     KVM
> Virtualization type:   full
> L1d cache:             32K
> L1i cache:             32K
> L2 cache:              4096K
> 
> uname -i shows:
> i686
> 
> 
> Will it be ok to test in this one?


If 'uname -i' reports i686, that usually means you have configured the
kernel for 32-bit. Try rebuilding the kernel with 'CONFIG_64BIT' and
'CONFIG_IA32_EMULATION' enabled to test that the 32-bit user space now
also works under a 64-bit kernel.

That reminds me, we should now remove the code from fs/compat_ioctl.c
that was handling emulating the other ioctl commands, the new .compat_ioctl
callback in ppdev takes care of that along with the PPGETTIME/PPSETTIME
calls, see below

	Arnd


diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index dcf26537c935..e65e7d932566 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -1019,28 +1019,6 @@ COMPATIBLE_IOCTL(PPPIOCGL2TPSTATS)
 /* PPPOX */
 COMPATIBLE_IOCTL(PPPOEIOCSFWD)
 COMPATIBLE_IOCTL(PPPOEIOCDFWD)
-/* ppdev */
-COMPATIBLE_IOCTL(PPSETMODE)
-COMPATIBLE_IOCTL(PPRSTATUS)
-COMPATIBLE_IOCTL(PPRCONTROL)
-COMPATIBLE_IOCTL(PPWCONTROL)
-COMPATIBLE_IOCTL(PPFCONTROL)
-COMPATIBLE_IOCTL(PPRDATA)
-COMPATIBLE_IOCTL(PPWDATA)
-COMPATIBLE_IOCTL(PPCLAIM)
-COMPATIBLE_IOCTL(PPRELEASE)
-COMPATIBLE_IOCTL(PPYIELD)
-COMPATIBLE_IOCTL(PPEXCL)
-COMPATIBLE_IOCTL(PPDATADIR)
-COMPATIBLE_IOCTL(PPNEGOT)
-COMPATIBLE_IOCTL(PPWCTLONIRQ)
-COMPATIBLE_IOCTL(PPCLRIRQ)
-COMPATIBLE_IOCTL(PPSETPHASE)
-COMPATIBLE_IOCTL(PPGETMODES)
-COMPATIBLE_IOCTL(PPGETMODE)
-COMPATIBLE_IOCTL(PPGETPHASE)
-COMPATIBLE_IOCTL(PPGETFLAGS)
-COMPATIBLE_IOCTL(PPSETFLAGS)
 /* Big A */
 /* sparc only */
 /* Big Q for sound/OSS */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300741

FromSudip Mukherjee <sudipm.mukherjee@gmail.com>
Date2016-01-04 14:20 +0100
Message-ID<qNddg-3WR-15@gated-at.bofh.it>
In reply to#1300142
On Sat, Jan 02, 2016 at 11:40:51PM +0100, Arnd Bergmann wrote:
> On Saturday 02 January 2016 11:59:29 Sudip Mukherjee wrote:
> > > 
> > > Just to be sure we are talking about the same thing: you mean running a 64-bit
> > > kernel in a kvm guest with a 32-bit file system, right? Running a 32-bit
> > > kvm guest on a 64-bit host would not be interesting of course.
> > 
> > The kvm (actually qemu, started from virt-manager with -enable-kvm) that
> > I just configured shows the following:
> > 
> > lscpu shows:
> > 
> > Architecture:          i686
> > CPU op-mode(s):        32-bit, 64-bit
> > Byte Order:            Little Endian
> > CPU(s):                1
> > On-line CPU(s) list:   0
> > Thread(s) per core:    1
> > Core(s) per socket:    1
> > Socket(s):             1
> > Vendor ID:             GenuineIntel
> > CPU family:            6
> > Model:                 6
> > Stepping:              3
> > CPU MHz:               2993.200
> > BogoMIPS:              5986.40
> > Virtualization:        VT-x
> > Hypervisor vendor:     KVM
> > Virtualization type:   full
> > L1d cache:             32K
> > L1i cache:             32K
> > L2 cache:              4096K
> > 
> > uname -i shows:
> > i686
> > 
> > 
> > Will it be ok to test in this one?
> 
> 
> If 'uname -i' reports i686, that usually means you have configured the
> kernel for 32-bit. Try rebuilding the kernel with 'CONFIG_64BIT' and
> 'CONFIG_IA32_EMULATION' enabled to test that the 32-bit user space now
> also works under a 64-bit kernel.

done... tested with CONFIG_64BIT and CONFIG_IA32_EMULATION. The original
ppdev code failed with my userspace test code. After applying patch 1/2
of v3 it still failed, but after applying 2/2 of v3 it worked.
will you take v3 through your y2038 tree? or I can keep them for,
ummmmm, 4.6 merge window.

> 
> That reminds me, we should now remove the code from fs/compat_ioctl.c
> that was handling emulating the other ioctl commands, the new .compat_ioctl
> callback in ppdev takes care of that along with the PPGETTIME/PPSETTIME
> calls, see below

Bamvor, care to send a patch for these also...

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1300746

FromArnd Bergmann <arnd@arndb.de>
Date2016-01-04 14:30 +0100
Message-ID<qNdmW-40K-11@gated-at.bofh.it>
In reply to#1300741
On Monday 04 January 2016 18:44:52 Sudip Mukherjee wrote:
> > 
> > If 'uname -i' reports i686, that usually means you have configured the
> > kernel for 32-bit. Try rebuilding the kernel with 'CONFIG_64BIT' and
> > 'CONFIG_IA32_EMULATION' enabled to test that the 32-bit user space now
> > also works under a 64-bit kernel.
> 
> done... tested with CONFIG_64BIT and CONFIG_IA32_EMULATION. The original
> ppdev code failed with my userspace test code. After applying patch 1/2
> of v3 it still failed, but after applying 2/2 of v3 it worked.

Ok, great!

> will you take v3 through your y2038 tree? or I can keep them for,
> ummmmm, 4.6 merge window.

My preference would be for you to pick it up. I try to only use the
y2038 tree for patches to drivers that have no maintainer.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302736

FromBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Date2016-01-06 14:00 +0100
Message-ID<qNVR0-1e8-23@gated-at.bofh.it>
In reply to#1300741
Hi, Sudip

On 01/04/2016 09:14 PM, Sudip Mukherjee wrote:
> On Sat, Jan 02, 2016 at 11:40:51PM +0100, Arnd Bergmann wrote:
>> On Saturday 02 January 2016 11:59:29 Sudip Mukherjee wrote:
>>>>
>>>> Just to be sure we are talking about the same thing: you mean running a 64-bit
>>>> kernel in a kvm guest with a 32-bit file system, right? Running a 32-bit
>>>> kvm guest on a 64-bit host would not be interesting of course.
>>>
>>> The kvm (actually qemu, started from virt-manager with -enable-kvm) that
>>> I just configured shows the following:
>>>
>>> lscpu shows:
>>>
>>> Architecture:          i686
>>> CPU op-mode(s):        32-bit, 64-bit
>>> Byte Order:            Little Endian
>>> CPU(s):                1
>>> On-line CPU(s) list:   0
>>> Thread(s) per core:    1
>>> Core(s) per socket:    1
>>> Socket(s):             1
>>> Vendor ID:             GenuineIntel
>>> CPU family:            6
>>> Model:                 6
>>> Stepping:              3
>>> CPU MHz:               2993.200
>>> BogoMIPS:              5986.40
>>> Virtualization:        VT-x
>>> Hypervisor vendor:     KVM
>>> Virtualization type:   full
>>> L1d cache:             32K
>>> L1i cache:             32K
>>> L2 cache:              4096K
>>>
>>> uname -i shows:
>>> i686
>>>
>>>
>>> Will it be ok to test in this one?
>>
>>
>> If 'uname -i' reports i686, that usually means you have configured the
>> kernel for 32-bit. Try rebuilding the kernel with 'CONFIG_64BIT' and
>> 'CONFIG_IA32_EMULATION' enabled to test that the 32-bit user space now
>> also works under a 64-bit kernel.
> 
> done... tested with CONFIG_64BIT and CONFIG_IA32_EMULATION. The original
> ppdev code failed with my userspace test code. After applying patch 1/2
> of v3 it still failed, but after applying 2/2 of v3 it worked.
> will you take v3 through your y2038 tree? or I can keep them for,
> ummmmm, 4.6 merge window.
> 
>>
>> That reminds me, we should now remove the code from fs/compat_ioctl.c
>> that was handling emulating the other ioctl commands, the new .compat_ioctl
>> callback in ppdev takes care of that along with the PPGETTIME/PPSETTIME
>> calls, see below
> 
> Bamvor, care to send a patch for these also...
Sure. Should I send this patch with previous two patches in v4 or send this
single patch to Alexander Viro and linux-fsdevel@vger.kernel.org?

Regards

Bamvor
> 
> regards
> sudip
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303653

FromArnd Bergmann <arnd@arndb.de>
Date2016-01-07 16:20 +0100
Message-ID<qOkw2-1qX-15@gated-at.bofh.it>
In reply to#1302736
On Wednesday 06 January 2016 20:56:28 Bamvor Jian Zhang wrote:
> >>
> >> That reminds me, we should now remove the code from fs/compat_ioctl.c
> >> that was handling emulating the other ioctl commands, the new .compat_ioctl
> >> callback in ppdev takes care of that along with the PPGETTIME/PPSETTIME
> >> calls, see below
> > 
> > Bamvor, care to send a patch for these also...
> Sure. Should I send this patch with previous two patches in v4 or send this
> single patch to Alexander Viro and linux-fsdevel@vger.kernel.org?
> 
> 

I'd say it should go along with the rest of the patches. The fs/compat_ioctl.c
file is really shared across multiple drivers and Al doesn't care about the
driver specific changes in it.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web