[parisc-linux] fdisk problems 2.4 <-> 2.6

[parisc-linux] fdisk problems 2.4 <-> 2.6

[Ruediger Scholz]

Hi there,

it's me again. I repartioned a IBM-hd with 4330 MB but when running 
fdisk with 2.6.0-test8-pa4, fdisk  told me:

--------><------------
gandalf:~# fdisk /dev/sdb

Befehl (m für Hilfe): p

Platte /dev/sdb: 40 MByte, 40239104 Byte
134 Köpfe, 62 Sektoren/Spuren, 9 Zylinder
Einheiten = Zylinder von 8308 * 512 = 4253696 Bytes

    Gerät Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1           8       33201   f0  Linux/PA-RISC boot
/dev/sdb2               9          23       62310   83  Linux
/dev/sdb3              24          83      249240   82  Linux Swap
/dev/sdb4              84        1019     3888144   8e  Linux LVM

Befehl (m für Hilfe):
------><-------------

Cause some bytes are missing ;)  I booted 2.4.22-pa13 and fdisk is now 
telling the correct values:

-------><--------
gandalf:~# fdisk /dev/sdb

Befehl (m für Hilfe): p

Platte /dev/sdb: 4335 MByte, 4335206400 Byte
134 Köpfe, 62 Sektoren/Spuren, 1019 Zylinder
Einheiten = Zylinder von 8308 * 512 = 4253696 Bytes

    Gerät Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1           8       33201   f0  Linux/PA-RISC boot
/dev/sdb2               9          23       62310   83  Linux
/dev/sdb3              24          83      249240   82  Linux Swap
/dev/sdb4              84        1019     3888144   8e  Linux LVM

Befehl (m für Hilfe): q

gandalf:~#
----------><--------

I have a 715/100 with 128 MB, a 2GB Seagate and a 4GB IBM-HD.
With my 2GB fdisk seems to have no problem:
------>2.6.0-test8-pa4<---------
gandalf:~# fdisk /dev/sda

Befehl (m für Hilfe): p

Platte /dev/sda: 2147 MByte, 2147678720 Byte
67 Köpfe, 62 Sektoren/Spuren, 1009 Zylinder
Einheiten = Zylinder von 4154 * 512 = 2126848 Bytes

    Gerät Boot      Start         End      Blocks   Id  System
/dev/sda1               1          11       22816   f0  Linux/PA-RISC boot
/dev/sda2              12          32       43617   83  Linux
/dev/sda3              33          96      132928   82  Linux Swap
/dev/sda4              97        1009     1896301   83  Linux

Befehl (m für Hilfe):
-----><-----------
----->2.4.22-pa13<----------
gandalf:~# fdisk /dev/sda

Befehl (m für Hilfe): p

Platte /dev/sda: 2147 MByte, 2147678720 Byte
67 Köpfe, 62 Sektoren/Spuren, 1009 Zylinder
Einheiten = Zylinder von 4154 * 512 = 2126848 Bytes

    Gerät Boot      Start         End      Blocks   Id  System
/dev/sda1               1          11       22816   f0  Linux/PA-RISC boot
/dev/sda2              12          32       43617   83  Linux
/dev/sda3              33          96      132928   82  Linux Swap
/dev/sda4              97        1009     1896301   83  Linux

Befehl (m für Hilfe):
----------><----------

Anybody encounter the same problems with fdisk?

Greetings,
    Ruediger

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Matthew Wilcox]

On Wed, Nov 05, 2003 at 09:21:14PM +0100, Ruediger Scholz wrote:
> it's me again. I repartioned a IBM-hd with 4330 MB but when running 
> fdisk with 2.6.0-test8-pa4, fdisk  told me:
> 
> --------><------------
> gandalf:~# fdisk /dev/sdb
> 
> Befehl (m für Hilfe): p
> 
> Platte /dev/sdb: 40 MByte, 40239104 Byte

Oh oh.  We have an interesting problem here.

> Platte /dev/sdb: 4335 MByte, 4335206400 Byte

4335206400 - 4294967296 = 40239104

So we've lost the top 32 bits of the value.  Can you run it under strace
and tell me what ioctls fdisk is calling?  I bet it's calling BLKGETSIZE64
and our put_user() is broken.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

> [...] I bet it's calling BLKGETSIZE64 and our put_user() is broken.

I trusted that Grant merged the same code in 2.4 and 2.6 for put_user() some
time ago?

Is it the same with 64bits kernels?

hth,
    Joel


-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Ruediger Scholz]

[-- Attachment #1: Type: text/plain, Size: 310 bytes --]

Matthew Wilcox schrieb:

>So we've lost the top 32 bits of the value.  Can you run it under strace
>and tell me what ioctls fdisk is calling?  I bet it's calling BLKGETSIZE64
>and our put_user() is broken.
>
Yes, it's calling BLKGETSIZE64... Full Output of 'strace fdisk' is attached.

Greetings,
    Ruediger

[-- Attachment #2: fdisk-2.6.log --]
[-- Type: text/plain, Size: 6401 bytes --]


gandalf:~# strace fdisk /dev/sdb
execve("/sbin/fdisk", ["fdisk", "/dev/sdb"], [/* 14 vars */]) = 0
newuname({sys="Linux", node="gandalf", ...}) = 0
brk(0)                                  = 0x3a000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 35026, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40019000
close(3)                                = 0
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\1\365"..., 512) = 512
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 1446800, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40029000
mprotect(0x40172000, 99216, PROT_NONE)  = 0
mmap(0x40181000, 32768, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x148000) = 0x40181000
mmap(0x40189000, 5008, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40189000
close(3)                                = 0
munmap(0x40019000, 35026)               = 0
open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=0, st_size=0, ...}) = 0
mmap2(NULL, 1860304, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4018b000
close(3)                                = 0
brk(0)                                  = 0x3a000
brk(0x5b000)                            = 0x5b000
brk(0)                                  = 0x5b000
open("/dev/sdb", O_RDWR|O_LARGEFILE)    = 3
read(3, "\200\0PALO\0\3\0\4\200\0\0)\323\375\0\0\0\0\0\0\0\0002"..., 512) = 512
newuname({sys="Linux", node="gandalf", ...}) = 0
ioctl(3, BLKSSZGET, 0xfaf004c8)         = 0
fstat64(3, {st_mode=0, st_size=6, ...}) = 0
ioctl(3, 0x301, 0xfaf004c8)             = 0
ioctl(3, BLKGETSIZE64, 0xfaf00530)      = 0
_llseek(3, 0, [0], SEEK_SET)            = 0
read(3, "\200\0PALO\0\3\0\4\200\0\0)\323\375\0\0\0\0\0\0\0\0002"..., 8192) = 8192
fstat64(1, {st_mode=0, st_size=5, ...}) = 0
ioctl(1, 0x40245410, {B9600 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40019000
write(1, "\n", 1
)                       = 1
open("/usr/share/locale/locale.alias", O_RDONLY) = 4
fstat64(4, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000
read(4, "# Locale name alias data base.\n#"..., 4096) = 2539
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x4001a000, 4096)                = 0
open("/usr/share/locale/de_DE@euro/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de@euro/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de_DE/LC_MESSAGES/util-linux.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/de/LC_MESSAGES/util-linux.mo", O_RDONLY) = 4
fstat64(4, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 163630, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40352000
close(4)                                = 0
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/gconv/gconv-modules", O_RDONLY) = 4
fstat64(4, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000
read(4, "# GNU libc iconv configuration.\n"..., 4096) = 4096
read(4, ".B1.002//\nalias\tJS//\t\t\tJUS_I.B1."..., 4096) = 4096
read(4, "859-3\t1\nmodule\tINTERNAL\t\tISO-885"..., 4096) = 4096
read(4, "9-14//\nalias\tLATIN8//\t\tISO-8859-"..., 4096) = 4096
read(4, "CSEBCDICES//\t\tEBCDIC-ES//\nalias\t"..., 4096) = 4096
read(4, "IBM284//\nalias\tEBCDIC-CP-ES//\t\tI"..., 4096) = 4096
read(4, "ias\t864//\t\t\tIBM864//\nalias\tCSIBM"..., 4096) = 4096
read(4, "\tIBM937\t\t1\nmodule\tINTERNAL\t\tIBM9"..., 4096) = 4096
read(4, "UC-JP//\nmodule\tEUC-JP//\t\tINTERNA"..., 4096) = 4096
read(4, "143IECP271//\tIEC_P27-1//\nalias\tI"..., 4096) = 4096
read(4, "\nmodule\tINTERNAL\t\tISO_10367-BOX/"..., 4096) = 4096
read(4, "\t\tto\t\t\tmodule\t\tcost\nmodule\tShift"..., 4096) = 222
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x4001a000, 4096)                = 0
open("/usr/lib/gconv/ISO8859-15.so", O_RDONLY) = 4
read(4, "\177ELF\1\2\1\3\0\0\0\0\0\0\0\0\0\3\0\17\0\0\0\1\0\0\7"..., 512) = 512
fstat64(4, {st_mode=0, st_size=0, ...}) = 0
mmap(NULL, 73040, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x4037a000
mprotect(0x4037c000, 64848, PROT_NONE)  = 0
mmap(0x4038b000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 4, 0x1000) = 0x4038b000
close(4)                                = 0
write(1, "Befehl (m f\374r Hilfe): ", 22Befehl (m für Hilfe): ) = 22
fstat64(0, {st_mode=0, st_size=5, ...}) = 0
ioctl(0, 0x40245410, {B9600 opost isig icanon echo ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4001a000
read(0, p
"p\n", 4096)                    = 2
write(1, "\n", 1
)                       = 1
write(1, "Platte /dev/sdb: 40 MByte, 40239"..., 41Platte /dev/sdb: 40 MByte, 40239104 Byte
) = 41
write(1, "134 K\366pfe, 62 Sektoren/Spuren, 9"..., 42134 Köpfe, 62 Sektoren/Spuren, 9 Zylinder
) = 42
write(1, "Einheiten = Zylinder von 8308 * "..., 53Einheiten = Zylinder von 8308 * 512 = 4253696 Bytes

) = 53
write(1, "    Ger\344t Boot      Start       "..., 63    Gerät Boot      Start         End      Blocks   Id  System
) = 63
write(1, "/dev/sdb1   *           1       "..., 75/dev/sdb1   *           1           8       33201   f0  Linux/PA-RISC boot
) = 75
write(1, "/dev/sdb2               9       "..., 62/dev/sdb2               9          23       62310   83  Linux
) = 62
write(1, "/dev/sdb3              24       "..., 67/dev/sdb3              24          83      249240   82  Linux Swap
) = 67
write(1, "/dev/sdb4              84       "..., 66/dev/sdb4              84        1019     3888144   8e  Linux LVM
) = 66
write(1, "\n", 1
)                       = 1
write(1, "Befehl (m f\374r Hilfe): ", 22Befehl (m für Hilfe): ) = 22
read(0, q
"q\n", 4096)                    = 2
close(3)                                = 0
write(1, "\n", 1
)                       = 1
munmap(0x40019000, 4096)                = 0
exit(0)                                 = ?
gandalf:~#

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Grant Grundler]

On Fri, Nov 07, 2003 at 06:52:58PM +0100, Joel Soete wrote:
> > [...] I bet it's calling BLKGETSIZE64 and our put_user() is broken.
> 
> I trusted that Grant merged the same code in 2.4 and 2.6 for put_user() some
> time ago?

put_user()?
I don't recall.

> Is it the same with 64bits kernels?

Can you point me at the modified 2.4 file and I'll check.

thanks,
grant

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

Grant Grundler wrote:
> On Fri, Nov 07, 2003 at 06:52:58PM +0100, Joel Soete wrote:
> 
>>>[...] I bet it's calling BLKGETSIZE64 and our put_user() is broken.
>>
>>I trusted that Grant merged the same code in 2.4 and 2.6 for put_user() some
>>time ago?
> 
> 
> put_user()?
> I don't recall.
> 
> 
>>Is it the same with 64bits kernels?
> 
> 
> Can you point me at the modified 2.4 file and I'll check.
> 
IIRC include/asm-parisc/uaccess.h

I do not work more on this stuff because I am awaiting patch that 
Randolph (always iirc) should still have in its tree to change the 
management of exception (which Matthew assumes to never occur in kernel 
mode iirc) (sorry but I just spend half an hour to find back this thread 
but without success :( )

hth,
	Joel

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Grant Grundler]

On Sat, Nov 08, 2003 at 10:59:20AM +0000, Joel Soete wrote:
> IIRC include/asm-parisc/uaccess.h

get/put user stuff looks the same to me in both 2.4/2.6 cvs.
I'm likely to forget forward porting 2.4 changes to 2.6 but I thought
I got that in the last round. If someone trolls the parisc-linux-cvs
archive and compares my commits for the past 2-3 monthes...

thanks,
grant

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

Any way, should it be this stuff (I don't notice it before):
----------><----------
--- uaccess.h.orig	2004-04-20 19:58:08.000000000 +0200
+++ uaccess.h-t1	2004-04-20 20:10:09.000000000 +0200
@@ -42,8 +42,8 @@
  #if BITS_PER_LONG == 32
  #define LDD_KERNEL(ptr) __get_kernel_bad();
  #define LDD_USER(ptr) __get_user_bad();
-#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr)
-#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
+#define STD_KERNEL(x, ptr) __put_kernel_asm64(x,ptr)
+#define STD_USER(x, ptr) __put_user_asm64(x,ptr)
  #else
  #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
  #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
----------><----------

But I presume it should reuired some cast so would it be better:
----------><----------
--- uaccess.h.orig	2004-04-20 19:58:08.000000000 +0200
+++ uaccess.h-t2	2004-04-20 20:10:41.000000000 +0200
@@ -42,8 +42,8 @@
  #if BITS_PER_LONG == 32
  #define LDD_KERNEL(ptr) __get_kernel_bad();
  #define LDD_USER(ptr) __get_user_bad();
-#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr)
-#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
+#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr)
+#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr)
  #else
  #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
  #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
----------><----------

I don't test it but hth,
	Joel



Grant Grundler wrote:
> On Sat, Nov 08, 2003 at 10:59:20AM +0000, Joel Soete wrote:
> 
>>IIRC include/asm-parisc/uaccess.h
> 
> 
> get/put user stuff looks the same to me in both 2.4/2.6 cvs.
> I'm likely to forget forward porting 2.4 changes to 2.6 but I thought
> I got that in the last round. If someone trolls the parisc-linux-cvs
> archive and compares my commits for the past 2-3 monthes...
> 
> thanks,
> grant
> 

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

Ok Ok :)

Matthew you have right:

Joel Soete wrote:
> ----------><----------
> --- uaccess.h.orig    2004-04-20 19:58:08.000000000 +0200
> +++ uaccess.h-t2    2004-04-20 20:10:41.000000000 +0200
> @@ -42,8 +42,8 @@
>  #if BITS_PER_LONG == 32
>  #define LDD_KERNEL(ptr) __get_kernel_bad();
>  #define LDD_USER(ptr) __get_user_bad();
> -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr)
> -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
> +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr)
> +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr)
>  #else
>  #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
>  #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
> ----------><----------
I just test it and it seems to be a fix (among others):
hpalin:~# fdisk /dev/sda

Command (m for help): p

Disk /dev/sda: 4294 MB, 4294816768 bytes
133 heads, 62 sectors/track, 1017 cylinders
Units = cylinders of 8246 * 512 = 4221952 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          16       65937   f0  Linux/PA-RISC boot
/dev/sda2              17          48      131936   fd  Linux raid 
autodetect
/dev/sda3              49          79      127813   fd  Linux raid 
autodetect
/dev/sda4              80         993     3768422    5  Extended
/dev/sda5              80         496     1719260   fd  Linux raid 
autodetect
/dev/sda6             497         558      255595   fd  Linux raid 
autodetect
/dev/sda7             559         589      127782   fd  Linux raid 
autodetect
/dev/sda8             590         620      127782   fd  Linux raid 
autodetect
/dev/sda9             621         993     1537848   83  Linux

Can somebody re-test it and ci for me?

hth,
	Joel

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Matthew Wilcox]

On Sun, Nov 09, 2003 at 01:50:49PM +0000, Joel Soete wrote:
> Joel Soete wrote:
> >----------><----------
> >--- uaccess.h.orig    2004-04-20 19:58:08.000000000 +0200
> >+++ uaccess.h-t2    2004-04-20 20:10:41.000000000 +0200
> >@@ -42,8 +42,8 @@
> > #if BITS_PER_LONG == 32
> > #define LDD_KERNEL(ptr) __get_kernel_bad();
> > #define LDD_USER(ptr) __get_user_bad();
> >-#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr)
> >-#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
> >+#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr)
> >+#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr)
> > #else
> > #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
> > #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
> >----------><----------
> I just test it and it seems to be a fix (among others):

I figured this out in Chicago airport yesterday.  Grant just pointed
me to this mail after I checked in the fix deleting the cast entirely.
Thanks for testing though.

-- 
"It's not Hollywood.  War is real, war is primarily not about defeat or
victory, it is about death.  I've seen thousands and thousands of dead bodies.
Do you think I want to have an academic debate on this subject?" -- Robert Fisk

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

Just for remainder here is the alignement of uaccess.h (i just finished 
to test on my c110 :)):
----------><----------
--- uaccess.h.orig      2004-04-20 21:03:59.000000000 +0200
+++ uaccess.h   2003-11-09 18:47:06.000000000 +0100
@@ -42,8 +42,8 @@
  #if BITS_PER_LONG == 32
  #define LDD_KERNEL(ptr) __get_kernel_bad();
  #define LDD_USER(ptr) __get_user_bad();
-#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr)
-#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
+#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr)
+#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr)
  #else
  #define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
  #define LDD_USER(ptr) __get_user_asm("ldd",ptr)
@@ -213,41 +213,33 @@
                 : "=r"(__pu_err)                            \
                 : "r"(ptr), "r"(x), "0"(__pu_err))

-static inline void __put_kernel_asm64(u64 x, void *ptr)
-{
-       u32 hi = x>>32;
-       u32 lo = x&0xffffffff;
-       __asm__ __volatile__ (
-               "\n1:\tstw %1,0(%0)\n"
-               "\n2:\tstw %2,4(%0)\n"
-               "3:\n"
-               "\t.section __ex_table,\"a\"\n"
-                "\t.word\t1b\n"
-                "\t.word\t(3b-1b)+1\n"
-                "\t.word\t2b\n"
-                "\t.word\t(3b-2b)+1\n"
-                "\t.previous"
-               : : "r"(ptr), "r"(hi), "r"(lo));
-
-}
-
-static inline void __put_user_asm64(u64 x, void *ptr)
-{
-       u32 hi = x>>32;
-       u32 lo = x&0xffffffff;
-       __asm__ __volatile__ (
-               "\n1:\tstw %1,0(%%sr3,%0)\n"
-               "\n2:\tstw %2,4(%%sr3,%0)\n"
-               "3:\n"
-               "\t.section __ex_table,\"a\"\n"
-                "\t.word\t1b\n"
-                "\t.word\t(3b-1b)+1\n"
-                "\t.word\t2b\n"
-                "\t.word\t(3b-2b)+1\n"
-                "\t.previous"
-               : : "r"(ptr), "r"(hi), "r"(lo));
+#define __put_kernel_asm64(x, ptr)                         \
+       __asm__ __volatile__ (                              \
+               "\n1:\tstw\t%2,0(%1)\n"                     \
+               "2:\tstw\t%R2,4(%1)\n"                      \
+               "3:\n"                                      \
+               "\t.section __ex_table,\"a\"\n"             \
+                "\t.word\t1b\n"                            \
+                "\t.word\t(3b-1b)+1\n"                     \
+                "\t.word\t2b\n"                            \
+                "\t.word\t(3b-2b)+1\n"                     \
+                "\t.previous"                              \
+               : "=r"(__pu_err)                            \
+               : "r"(ptr), "r"(x), "0"(__pu_err))

-}
+#define __put_user_asm64(x, ptr)                           \
+       __asm__ __volatile__ (                              \
+               "\n1:\tstw\t%2,0(%%sr3,%1)\n"               \
+               "2:\tstw\t%R2,4(%%sr3,%1)\n"                \
+               "3:\n"                                      \
+               "\t.section __ex_table,\"a\"\n"             \
+                "\t.word\t1b\n"                            \
+                "\t.word\t(3b-1b)+1\n"                     \
+                "\t.word\t2b\n"                            \
+                "\t.word\t(3b-2b)+1\n"                     \
+                "\t.previous"                              \
+               : "=r"(__pu_err)                            \
+               : "r"(ptr), "r"(x), "0"(__pu_err))

  #endif

----------><----------

Cheers,
	Joel

PS: I also attach the patch for easy apply
and here I need the cast.



Matthew Wilcox wrote:
> On Sun, Nov 09, 2003 at 01:50:49PM +0000, Joel Soete wrote:
> 
>>Joel Soete wrote:
>>
>>>----------><----------
>>>--- uaccess.h.orig    2004-04-20 19:58:08.000000000 +0200
>>>+++ uaccess.h-t2    2004-04-20 20:10:41.000000000 +0200
>>>@@ -42,8 +42,8 @@
>>>#if BITS_PER_LONG == 32
>>>#define LDD_KERNEL(ptr) __get_kernel_bad();
>>>#define LDD_USER(ptr) __get_user_bad();
>>>-#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr)
>>>-#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
>>>+#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr)
>>>+#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr)
>>>#else
>>>#define LDD_KERNEL(ptr) __get_kernel_asm("ldd",ptr)
>>>#define LDD_USER(ptr) __get_user_asm("ldd",ptr)
>>>----------><----------
>>
>>I just test it and it seems to be a fix (among others):
> 
> 
> I figured this out in Chicago airport yesterday.  Grant just pointed
> me to this mail after I checked in the fix deleting the cast entirely.
> Thanks for testing though.
> 

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Grant Grundler]

On Sun, Nov 09, 2003 at 06:59:48PM +0000, Joel Soete wrote:
> Just for remainder here is the alignement of uaccess.h (i just finished 
> to test on my c110 :)):
> ----------><----------
> --- uaccess.h.orig      2004-04-20 21:03:59.000000000 +0200
> +++ uaccess.h   2003-11-09 18:47:06.000000000 +0100
> @@ -42,8 +42,8 @@
>  #if BITS_PER_LONG == 32
>  #define LDD_KERNEL(ptr) __get_kernel_bad();
>  #define LDD_USER(ptr) __get_user_bad();
> -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,ptr)
> -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
> +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr)
> +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr)

willy just removed the (u32) cast and things seem to work for him.
Do you need the (u64) cast?

...
> -static inline void __put_kernel_asm64(u64 x, void *ptr)
...
> +#define __put_kernel_asm64(x, ptr)                         \
...

Why replace the static inline with a macro?
static inline provides type checking and
type "coercion" when it's not exactly right.

> +       __asm__ __volatile__ (                              \
> +               "\n1:\tstw\t%2,0(%1)\n"                     \
> +               "2:\tstw\t%R2,4(%1)\n"                      \

What is "%R2" intended to be?
Randolph pointed out this is broken before and I was wrong
to commit this chunk to the 2.4 tree (I'm working on
removing it now).

thanks,
grant

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Grant Grundler]

On Sun, Nov 09, 2003 at 09:45:56PM -0700, Grant Grundler wrote:
> What is "%R2" intended to be?
> Randolph pointed out this is broken before and I was wrong
> to commit this chunk to the 2.4 tree (I'm working on removing it now).

For reference:
http://lists.parisc-linux.org/pipermail/parisc-linux/2002-November/018441.html

grant

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[John David Anglin]

> Why replace the static inline with a macro?
> static inline provides type checking and
> type "coercion" when it's not exactly right.
> 
> > +       __asm__ __volatile__ (                              \
> > +               "\n1:\tstw\t%2,0(%1)\n"                     \
> > +               "2:\tstw\t%R2,4(%1)\n"                      \
> 
> What is "%R2" intended to be?

"%R2" should cause the second register name of a register pair to
be printed.  It's used for long long support on 32-bit ports.  See
case 'R' in the function print_operand in pa.c.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Randolph Chung]

> What is "%R2" intended to be?
> Randolph pointed out this is broken before and I was wrong
> to commit this chunk to the 2.4 tree (I'm working on
> removing it now).

Just a clarification:

%R2 is not *wrong* -- it points to the right side of argument register 
2 (jda explained this in an earlier thread), but I am not 100% sure 
%R2 will do the right thing for a 32-bit build though -- if you are 
running on a pa1.1 machine and the register is only 32-bit, does %R2 
automatically do the right thing with 64-bit arguments?  I guess it's 
easy enough to tell by looking at the code gcc generates...

anyway, i think we should stick with the inline version of the code
too....

thx
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[John David Anglin]

> %R2 is not *wrong* -- it points to the right side of argument register 
> 2 (jda explained this in an earlier thread), but I am not 100% sure 
> %R2 will do the right thing for a 32-bit build though -- if you are 
> running on a pa1.1 machine and the register is only 32-bit, does %R2 
> automatically do the right thing with 64-bit arguments?  I guess it's 
> easy enough to tell by looking at the code gcc generates...

'R' simply adds 1 to the register number specified for operand 2.
This is the right thing to do for a DImode value running 32-bit code.
In the code that gcc generates, we use a specific set of register
pairs for long doubles (see HARD_REGNO_MODE_OK).  The main question
that I would have is is the register created in the asm consistent
with the register allocation needed for a DImode value.  I think it
would be if the mode/type for the input/output was specified
correctly.  This can be done with a cast in the asm.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

>-- Original Message --
>To: tausq@debian.org
>From: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
>Cc: grundler@parisc-linux.org, soete.joel@tiscali.be,
>	willy@debian.org, parisc-linux@lists.parisc-linux.org
>Date: Mon, 10 Nov 2003 00:25:42 -0500 (EST)
>Subject: Re: [parisc-linux] fdisk problems 2.4 <-> 2.6
>
>
>> %R2 is not *wrong* -- it points to the right side of argument register

> 2 (jda explained this in an earlier thread), but I am not 100% sure 
> %R2 will do the right thing for a 32-bit build though -- if you are 
> running on a pa1.1 machine and 
>he register is only 32-bit, does %R2 
> automatically do the right thing with 64-bit arguments?  I guess it's 
> easy enough to tell by looking at the code gcc generates...

'R' simply adds 1 to the register number specified for operand 2.
This is
>the right thing to do for a DImode value running 32-bit code.
In the code that gcc generates, we use a specific set of register
pairs for long doubles (see HARD_REGNO_MODE_OK).  The main question
that I would have is is the register created in the a
>m consistent
with the register allocation needed for a DImode value.  I think it
would be if the mode/type for the input/output was specified
correctly.  This can be done with a cast in the asm.

Dave
-- 
J. David Anglin                         
>        dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-li
>ux.org/mailman/listinfo/parisc-linux



-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

Dave,

Thanks a lot you explain all better I while I was trying to find a sleep
(too coffee even if not java :) ).

Just to remaind the following of the tread that Grant mentioned before:
<http://lists.parisc-linux.org/pipermail/parisc-linux/2002-November/018443.html>

>  I think it would be if the mode/type for the input/output was specified
> correctly.  This can be done with a cast in the asm.

Yes, that is why I need cast in this case.

That says, obviously I just had enough time to test it with success before
submit it :)

Finaly, for the history, before 'BLKGETSIZE64' was used in evms and xfs,
I tried to write it as a macro because there was (as there are still) macro
for 32bit world on a pa1.1 and also for 64bits on pa2.0 and so I would like
to continue the same style :)

Thanks again to all for your attention,
    Joel

-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

That is Ok for me, Do you still have the patch to revert it?

Joel

>-- Original Message --
>From: Grant Grundler <grundler@parisc-linux.org>
>To: Joel Soete <soete.joel@tiscali.be>
>Cc: Matthew Wilcox <willy@debian.org>,
>	parisc-linux@lists.parisc-linux.org,
>	Grant Grundler <grundler@parisc-linux.org>
>Date: Sun, 9 Nov 2003 21:45:56 -0700
>Subject: Re: [parisc-linux] fdisk problems 2.4 <-> 2.6
>
>
>On Sun, Nov 09, 2003 at 06:59:48PM +0000, Joel Soete wrote:
> Just for remainder here is the alignement of uaccess.h (i just finished

> to test on my c110 :)):
> ----------><----------
> --- uaccess.h.orig      2004-04-20 21:03:59.000000000 +0200

>> +++ uaccess.h   2003-11-09 18:47:06.000000000 +0100
> @@ -42,8 +42,8 @@
>  #if BITS_PER_LONG == 32
>  #define LDD_KERNEL(ptr) __get_kernel_bad();
>  #define LDD_USER(ptr) __get_user_bad();
> -#define STD_KERNEL(x, ptr) __put_kernel_asm64((u32)x,
>tr)
> -#define STD_USER(x, ptr) __put_user_asm64((u32)x,ptr)
> +#define STD_KERNEL(x, ptr) __put_kernel_asm64((u64)x,ptr)
> +#define STD_USER(x, ptr) __put_user_asm64((u64)x,ptr)

willy just removed the (u32) cast and things seem to work for him.

>Do you need the (u64) cast?

...
> -static inline void __put_kernel_asm64(u64 x, void *ptr)
...
> +#define __put_kernel_asm64(x, ptr)                         \
...

Why replace the static inline with a macro?
static inline provides type checki
>g and
type "coercion" when it's not exactly right.

> +       __asm__ __volatile__ (                              \
> +               "\n1:\tstw\t%2,0(%1)\n"                     \
> +               "2:\tstw\t%R2,4(%1)\n"                      \


>hat is "%R2" intended to be?
Randolph pointed out this is broken before and I was wrong
to commit this chunk to the 2.4 tree (I'm working on
removing it now).

thanks,
grant
_______________________________________________
parisc-linux mailing l
>st
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux



-------------------------------------------------------------------------
Tiscali ADSL: 3 mois GRATUITS! L'Internet rapide, c'est pour tout le monde.

http://reg.tiscali.be/default.asp?lg=fr

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Grant Grundler]

On Mon, Nov 10, 2003 at 10:51:32AM +0100, Joel Soete wrote:
> That is Ok for me, Do you still have the patch to revert it?

yes - I'll test/commmit that this morning.

thanks,
grant

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

Randolph Chung wrote:
>>What is "%R2" intended to be?
>>Randolph pointed out this is broken before and I was wrong
>>to commit this chunk to the 2.4 tree (I'm working on
>>removing it now).
> 
> 
> Just a clarification:
> 
> %R2 is not *wrong* -- it points to the right side of argument register 
> 2 (jda explained this in an earlier thread), but I am not 100% sure 
> %R2 will do the right thing for a 32-bit build though -- if you are 
> running on a pa1.1 machine and the register is only 32-bit, does %R2 
> automatically do the right thing with 64-bit arguments?  I guess it's 
> easy enough to tell by looking at the code gcc generates...
> 

Good idea and just for curiosity (i don't want to insist to maintain 
some line of code which soon or later would have to be change ), I can 
try to find back a test case I used to prepare. (Just be patient)

> anyway, i think we should stick with the inline version of the code
> too....
> 
> thx
> randolph

thx also for attention,
	Joel

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Ruediger Scholz]

Thanks for all your help! Everything works fine for me now.

Greetings,
    Ruediger

Re: [parisc-linux] fdisk problems 2.4 <-> 2.6

[Joel Soete]

Joel Soete wrote:
> 
> 
>>
>> %R2 is not *wrong* -- it points to the right side of argument register 
>> 2 (jda explained this in an earlier thread), but I am not 100% sure 
>> %R2 will do the right thing for a 32-bit build though -- if you are 
>> running on a pa1.1 machine and the register is only 32-bit, does %R2 
>> automatically do the right thing with 64-bit arguments?  I guess it's 
>> easy enough to tell by looking at the code gcc generates...
>>
> 
> Good idea and just for curiosity (i don't want to insist to maintain 
> some line of code which soon or later would have to be change ), I can 
> try to find back a test case I used to prepare. (Just be patient)
> 
So here is my test-case:
---------><---------
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

#define KERNEL_DS       ((mm_segment_t){0})
#define USER_DS         ((mm_segment_t){1})

#define segment_eq(a,b) ((a).seg == (b).seg)

#define get_ds()        (KERNEL_DS)
#define get_fs()        (current->addr_limit)
#define set_fs(x)       (current->addr_limit = (x))

#define put_user __put_user

#define STD_USER(x, ptr)  __put_user_asm_64(x, ptr)

#define __put_user(x,ptr)                                       \
({                                                              \
         register long __pu_err __asm__ ("r8") = 0;              \
                                                                 \
             switch (sizeof(*(ptr))) {                           \
             case 1: __put_user_asm("stb",x,ptr); break;         \
             case 2: __put_user_asm("sth",x,ptr); break;         \
             case 4: __put_user_asm("stw",x,ptr); break;         \
             case 8: STD_USER(x,ptr); break;         \
             default: printf("Bug"); break;                              \
             }                                                   \
                                                                 \
         __pu_err;                                               \
})

/*
  * The "__put_user/kernel_asm()" macros tell gcc they read from memory
  * instead of writing. This is because they do not write to any memory
  * gcc knows about, so there are no aliasing issues.
  */

#define __put_user_asm(stx,x,ptr)                           \
         __asm__ __volatile__ (                              \
                 "\n1:\t" stx "\t%2,0(%%sr3,%1)\n"           \
                 "2:\n"                                      \
                 "\t.section __ex_table,\"a\"\n"             \
                  "\t.word\t1b\n"                            \
                  "\t.word\t(2b-1b)+1\n"                     \
                  "\t.previous"                              \
                 : "=r"(__pu_err)                            \
                 : "r"(ptr), "r"(x), "0"(__pu_err))

#define __put_user_asm_64(x, ptr)                      \
         __asm__ __volatile__ (                              \
                 "\n1:\tstw\t%2,0(%%sr3,%1)\n"           \
                 "2:\tstw\t%R2,4(%%sr3,%1)\n"           \
                 "3:\n"                                      \
                 "\t.section __ex_table,\"a\"\n"             \
                  "\t.word\t1b\n"                            \
                  "\t.word\t(3b-1b)+1\n"                     \
                  "\t.word\t2b\n"                            \
                  "\t.word\t(3b-2b)+1\n"                     \
                  "\t.previous"                              \
                 : "=r"(__pu_err)                            \
                 : "r"(ptr), "r"(x), "0"(__pu_err))

typedef unsigned long long u64;
typedef u_int8_t  BOOLEAN;

typedef struct
{
     unsigned char b7, b6, b5, b4, b3, b2, b1, b0;
}
EightBytes;

int main(int argc, char * * argv, char * * env) {

     unsigned long long TU64;
     unsigned long long * PTU64=(unsigned long long *) 
malloc(sizeof(unsigned long long));
     int err;

     union
     {
         unsigned long long U64;
         EightBytes B8;
     }
     Uu64;

     Uu64.U64 = 0xf7f6f5f4f3f2f1f0LL;
     TU64 = Uu64.U64;

     err = put_user(TU64, PTU64);

     printf("TestU64 is of len: %u\n", sizeof(Uu64.U64));
     printf("Address of TestU64: %p\n", &TU64);

     printf("Value of Uu64.U64: %0Lx\n", Uu64.U64);

     printf("Value of Uu64.U64l: %0x\n", (unsigned int) Uu64.U64 );

     printf("Value of Uu64.U64h: %0x\n", (unsigned int) (Uu64.U64 >> 32) );

     printf("Value of Uu64.U64b0: %0x\n", (unsigned char) Uu64.B8.b0 );

     printf("Address of Uu64.U64: %p\n", &(Uu64.U64));
     printf("Address of Uu64.U64b7: %p\n", &(Uu64.B8.b7));
     printf("Address of Uu64.U64b0: %p\n", &(Uu64.B8.b0));

     printf("PTU64 is of len: %u\n", sizeof(*PTU64));
     printf("Address of PTU64: %p\n", PTU64);
     printf("Value of PTU64: %0Lx\n", *PTU64);

     return err;
}
---------><---------

And the generated code by gcc 3.3.2:
[...]
main:
         .PROC
         .CALLINFO FRAME=128,CALLS,SAVE_RP,SAVE_SP,ENTRY_GR=4
         .ENTRY
         stw %r2,-20(%r30)
         copy %r3,%r1
         copy %r30,%r3
         stwm %r1,128(%r30)
         stw %r8,32(%r3)
         stw %r26,-36(%r3)
         stw %r25,-40(%r3)
         stw %r24,-44(%r3)
         ldi 8,%r26
         bl malloc,%r2
         nop
         copy %r28,%r19
         stw %r19,16(%r3)
         ldil L'-202182160,%r20
         ldil L'-134810124,%r19
         ldo R'-134810124(%r19),%r19
         ldo R'-202182160(%r20),%r20
         stw %r19,24(%r3)
         stw %r20,28(%r3)
         ldw 24(%r3),%r19
         ldw 28(%r3),%r20
         stw %r19,8(%r3)
         stw %r20,12(%r3)
         ldi 0,%r8
         ldw 16(%r3),%r21
         ldw 8(%r3),%r19
         ldw 12(%r3),%r20
#APP

1:      stw     %r19,0(%sr3,%r21)
2:      stw     %r20,4(%sr3,%r21)
3:
         .section __ex_table,"a"
         .word   1b
         .word   (3b-1b)+1
         .word   2b
         .word   (3b-2b)+1
         .previous
#NO_APP
         stw %r8,20(%r3)
         ldil LR'.LC1,%r19
         ldo RR'.LC1(%r19),%r26
         ldi 8,%r25
         bl printf,%r2
         nop
         ldil LR'.LC2,%r19
[...]

Please let me know if I miss something ;)

Cheers,
	Joel