Re: sysfs: duplicate filename 'card0' can not be created
On Wed, Feb 13, 2008 at 03:09:21PM +, Luciano Rocha wrote: > On Wed, Feb 13, 2008 at 03:21:38PM +0100, Takashi Iwai wrote: > > At Wed, 13 Feb 2008 14:05:27 +0000, > > Luciano Rocha wrote: > > > > > > Hello, > > > > > > Is this known? I got the error while connecting usb headphones, running > > > vanilla 2.6.24. > > > > Not known. In which situation does it happen and is reproducible? > > > > Disconnecting and reconnecting doesn't result in error. I'll try a > reboot later. After a reboot I still don't get the error (tryed connecting and reconnecting the headset). Do you have any tests you want me to make? -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpwJmCLMW4vL.pgp Description: PGP signature
Re: sysfs: duplicate filename 'card0' can not be created
On Wed, Feb 13, 2008 at 03:09:21PM +, Luciano Rocha wrote: On Wed, Feb 13, 2008 at 03:21:38PM +0100, Takashi Iwai wrote: At Wed, 13 Feb 2008 14:05:27 +, Luciano Rocha wrote: Hello, Is this known? I got the error while connecting usb headphones, running vanilla 2.6.24. Not known. In which situation does it happen and is reproducible? Disconnecting and reconnecting doesn't result in error. I'll try a reboot later. After a reboot I still don't get the error (tryed connecting and reconnecting the headset). Do you have any tests you want me to make? -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpwJmCLMW4vL.pgp Description: PGP signature
Re: sysfs: duplicate filename 'card0' can not be created
On Wed, Feb 13, 2008 at 03:21:38PM +0100, Takashi Iwai wrote: > At Wed, 13 Feb 2008 14:05:27 +, > Luciano Rocha wrote: > > > > Hello, > > > > Is this known? I got the error while connecting usb headphones, running > > vanilla 2.6.24. > > Not known. In which situation does it happen and is reproducible? > Disconnecting and reconnecting doesn't result in error. I'll try a reboot later. -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpDOqoYUAT8O.pgp Description: PGP signature
sysfs: duplicate filename 'card0' can not be created
Hello, Is this known? I got the error while connecting usb headphones, running vanilla 2.6.24. Error: [.361992] usb 1-1.3: new full speed USB device using ehci_hcd and address 13 [.448232] usb 1-1.3: configuration #1 chosen from 1 choice [.506787] sysfs: duplicate filename 'card0' can not be created [.506796] WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() [.506802] Pid: 794, comm: khubd Not tainted 2.6.24lcfs1 #1 [.506819] [] sysfs_add_one+0x54/0xb7 [.506835] [] sysfs_create_link+0xbe/0x109 [.506846] [] device_add+0x132/0x447 [.506856] [] kobject_init+0x27/0x37 [.506866] [] device_create+0x77/0x97 [.506873] [] snd_card_register+0x3f/0x254 [.506883] [] usb_driver_claim_interface+0x6b/0x86 [usbcore] [.506944] [] usb_audio_probe+0x6c7/0x76e [snd_usb_audio] [.506990] [] usb_probe_interface+0xa2/0xda [usbcore] [.507010] [] driver_sysfs_add+0x36/0x53 [.507018] [] driver_probe_device+0xdd/0x15a [.507025] [] klist_next+0x50/0x82 [.507032] [] __device_attach+0x0/0x5 [.507037] [] bus_for_each_drv+0x32/0x58 [.507045] [] device_attach+0x5d/0x70 [.507049] [] __device_attach+0x0/0x5 [.507055] [] bus_attach_device+0x26/0x73 [.507062] [] device_add+0x25d/0x447 [.507073] [] usb_set_configuration+0x3f6/0x469 [usbcore] [.507099] [] generic_probe+0x50/0x91 [usbcore] [.507125] [] usb_probe_device+0x32/0x37 [usbcore] [.507142] [] driver_probe_device+0xdd/0x15a [.507148] [] klist_next+0x50/0x82 [.507154] [] __device_attach+0x0/0x5 [.507159] [] bus_for_each_drv+0x32/0x58 [.507167] [] device_attach+0x5d/0x70 [.507172] [] __device_attach+0x0/0x5 [.507177] [] bus_attach_device+0x26/0x73 [.507184] [] device_add+0x25d/0x447 [.507195] [] usb_new_device+0x41/0x7e [usbcore] [.507217] [] hub_thread+0x6b6/0xa93 [usbcore] [.507243] [] autoremove_wake_function+0x0/0x35 [.507253] [] schedule+0x1e2/0x22e [.507258] [] hub_thread+0x0/0xa93 [usbcore] [.507276] [] kthread+0x36/0x5d [.507280] [] kthread+0x0/0x5d [.507285] [] kernel_thread_helper+0x7/0x10 [.507294] === [.511876] input: USB Audio as /devices/pci:00/:00:1e.0/:02:04.2/usb1/1-1/1-1.3/1-1.3:1.3/input/input7 [.537041] input: USB HID v1.00 Device [USB Audio] on usb-:02:04.2-1.3 -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpvlKBiSmUVN.pgp Description: PGP signature
sysfs: duplicate filename 'card0' can not be created
Hello, Is this known? I got the error while connecting usb headphones, running vanilla 2.6.24. Error: [.361992] usb 1-1.3: new full speed USB device using ehci_hcd and address 13 [.448232] usb 1-1.3: configuration #1 chosen from 1 choice [.506787] sysfs: duplicate filename 'card0' can not be created [.506796] WARNING: at fs/sysfs/dir.c:424 sysfs_add_one() [.506802] Pid: 794, comm: khubd Not tainted 2.6.24lcfs1 #1 [.506819] [c04a07cd] sysfs_add_one+0x54/0xb7 [.506835] [c04a1415] sysfs_create_link+0xbe/0x109 [.506846] [c05db991] device_add+0x132/0x447 [.506856] [c057e9ba] kobject_init+0x27/0x37 [.506866] [c05dbf12] device_create+0x77/0x97 [.506873] [c0611fa1] snd_card_register+0x3f/0x254 [.506883] [f083fa71] usb_driver_claim_interface+0x6b/0x86 [usbcore] [.506944] [f09b7cbb] usb_audio_probe+0x6c7/0x76e [snd_usb_audio] [.506990] [f083f960] usb_probe_interface+0xa2/0xda [usbcore] [.507010] [c05dd14b] driver_sysfs_add+0x36/0x53 [.507018] [c05dd2ab] driver_probe_device+0xdd/0x15a [.507025] [c0688f9a] klist_next+0x50/0x82 [.507032] [c05dd328] __device_attach+0x0/0x5 [.507037] [c05dc7ce] bus_for_each_drv+0x32/0x58 [.507045] [c05dd3a5] device_attach+0x5d/0x70 [.507049] [c05dd328] __device_attach+0x0/0x5 [.507055] [c05dc74f] bus_attach_device+0x26/0x73 [.507062] [c05dbabc] device_add+0x25d/0x447 [.507073] [f083e316] usb_set_configuration+0x3f6/0x469 [usbcore] [.507099] [f0844ba7] generic_probe+0x50/0x91 [usbcore] [.507125] [f083f763] usb_probe_device+0x32/0x37 [usbcore] [.507142] [c05dd2ab] driver_probe_device+0xdd/0x15a [.507148] [c0688f9a] klist_next+0x50/0x82 [.507154] [c05dd328] __device_attach+0x0/0x5 [.507159] [c05dc7ce] bus_for_each_drv+0x32/0x58 [.507167] [c05dd3a5] device_attach+0x5d/0x70 [.507172] [c05dd328] __device_attach+0x0/0x5 [.507177] [c05dc74f] bus_attach_device+0x26/0x73 [.507184] [c05dbabc] device_add+0x25d/0x447 [.507195] [f0839c0f] usb_new_device+0x41/0x7e [usbcore] [.507217] [f083ad51] hub_thread+0x6b6/0xa93 [usbcore] [.507243] [c042fc93] autoremove_wake_function+0x0/0x35 [.507253] [c06895dc] schedule+0x1e2/0x22e [.507258] [f083a69b] hub_thread+0x0/0xa93 [usbcore] [.507276] [c042fbd9] kthread+0x36/0x5d [.507280] [c042fba3] kthread+0x0/0x5d [.507285] [c0404a1b] kernel_thread_helper+0x7/0x10 [.507294] === [.511876] input: USB Audio as /devices/pci:00/:00:1e.0/:02:04.2/usb1/1-1/1-1.3/1-1.3:1.3/input/input7 [.537041] input: USB HID v1.00 Device [USB Audio] on usb-:02:04.2-1.3 -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpvlKBiSmUVN.pgp Description: PGP signature
Re: shared memory
On Sun, Dec 16, 2007 at 05:01:17PM -0300, Rafael Sisto wrote: > Thank you for the quick answer, but It's a college project, and I must > share user level memory. I also must build my own system calls... > But I can look what is already done and make something similar. Do you > think shmget would do? Does it share user level memory? Yes. They both do, but the Posix one is based on a ramfs or tmpfs on /dev/shm and shared mmaps. I think analyzing the SysV version will be better for your needs. shmget: create the memory region shmat: attach the memory region to this process. -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpx15LttUygt.pgp Description: PGP signature
Re: shared memory
On Sun, Dec 16, 2007 at 04:51:39PM -0300, Rafael Sisto wrote: > Hi, Im working on a project working on linux kernel 2.6.17 > I have to share memory on user level... I have to build something like > a server process that "exports" a portion of his virtual memory, and > other client process may ask the kernel for that memory and use it (as > its own). > I managed to build a structure on the kernel. Why? Aren't SysV IPC or Posix IPC enough? See "man shm_open", for the new Posix version, and "man shmget" for the old SysV IPC version. -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpDNI6k42fna.pgp Description: PGP signature
Re: shared memory
On Sun, Dec 16, 2007 at 05:01:17PM -0300, Rafael Sisto wrote: Thank you for the quick answer, but It's a college project, and I must share user level memory. I also must build my own system calls... But I can look what is already done and make something similar. Do you think shmget would do? Does it share user level memory? Yes. They both do, but the Posix one is based on a ramfs or tmpfs on /dev/shm and shared mmaps. I think analyzing the SysV version will be better for your needs. shmget: create the memory region shmat: attach the memory region to this process. -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpx15LttUygt.pgp Description: PGP signature
Re: shared memory
On Sun, Dec 16, 2007 at 04:51:39PM -0300, Rafael Sisto wrote: Hi, Im working on a project working on linux kernel 2.6.17 I have to share memory on user level... I have to build something like a server process that exports a portion of his virtual memory, and other client process may ask the kernel for that memory and use it (as its own). I managed to build a structure on the kernel. Why? Aren't SysV IPC or Posix IPC enough? See man shm_open, for the new Posix version, and man shmget for the old SysV IPC version. -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpDNI6k42fna.pgp Description: PGP signature
Re: ldminfo compilation
On Wed, Dec 12, 2007 at 03:29:55PM +, Luciano Rocha wrote: > On Wed, Dec 12, 2007 at 04:57:39PM +0200, Alon Bar-Lev wrote: > > On 12/12/07, Luciano Rocha <[EMAIL PROTECTED]> wrote: > > > Those are for the kernel module setting the partition tables. If you're > > > only interested in the ldminfo utility: > > > make -C ldmutil CPP='g++ -static' > > > > > > Substitute g++ for the C++ compiler you want to use. > > > > Hi! > > Thank you for your reply! > > > > I don't really understand how to use the output of ldmutil in order to > > do the dmsetup... All the instructions are for ldminfo... > > Ah, sorry. Somehow I got the impression that the ldmutil directory > included the ldminfo binary. I'll see if I can compile the ldminfo > statically in an older system I have. OK, the statically compiled version is at: ftp://gil.di.uminho.pt/pub/users/strange/ldminfo sha1sum: 71c1451f9cbd1a4256bb072d4c930418acc8e2fb Anyway, how to compile with the sources of: - linux-2.4.20 - linux-ldm-0.0.8 ldm=linux-ldm-0.0.8 kernel=linux-2.4.20 1. Decompress linux-ldm-0.0.8: curl -s http://dl.sourceforge.net/sourceforge/linux-ntfs/$ldm.tar.bz2 \ | tar xjf - 2. Enter the directory: cd $ldm 3. Decompress the Linux kernel sources: curl -s ftp://ftp.di.uminho.pt/pub/kernel/v2.4/$kernel.tar.bz2 \ | tar xjf - 4. Change test/Makefile to compile ldminfo statically: sed -e 's/ -o/ -static &/' -i test/Makefile 5. Correct KERNEL path in Makefile: sed -e "s,KERNEL.*=.*,KERNEL = $PWD/$kernel," -i Makefile 6. Force i386 arch in Makefile: sed -e 's/-march=.*/-march=i386/' -i Makefile 7. Generate kernel's option files: yes n | make -C $kernel ARCH=i386 oldconfig dep 8. Compile ldminfo and ldmutil: make ARCH=i386 This worked on a Centos 3.8, 32bits but running x86_64 kernel, but not on my Fedora 8. YMMV. Shell script: ldm=linux-ldm-0.0.8 kernel=linux-2.4.20 curl -s http://dl.sourceforge.net/sourceforge/linux-ntfs/$ldm.tar.bz2 \ | tar xjf - && cd $ldm && curl -s ftp://ftp.di.uminho.pt/pub/kernel/v2.4/$kernel.tar.bz2 \ | tar xjf - && sed -e 's/ -o/ -static &/' -i test/Makefile && sed -e "s,KERNEL.*=.*,KERNEL = $PWD/$kernel," -i Makefile && sed -e 's/-march=.*/-march=i386/' -i Makefile && yes n | make -C $kernel ARCH=i386 oldconfig dep && make ARCH=i386 -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpUfpx5h5mvx.pgp Description: PGP signature
Re: ldminfo compilation
On Wed, Dec 12, 2007 at 04:57:39PM +0200, Alon Bar-Lev wrote: > On 12/12/07, Luciano Rocha <[EMAIL PROTECTED]> wrote: > > Those are for the kernel module setting the partition tables. If you're > > only interested in the ldminfo utility: > > make -C ldmutil CPP='g++ -static' > > > > Substitute g++ for the C++ compiler you want to use. > > Hi! > Thank you for your reply! > > I don't really understand how to use the output of ldmutil in order to > do the dmsetup... All the instructions are for ldminfo... Ah, sorry. Somehow I got the impression that the ldmutil directory included the ldminfo binary. I'll see if I can compile the ldminfo statically in an older system I have. > > And the C++ dependency does not work well with uclibc... I tried to > compile this using uclibc++, but the exception handling of uclibc++ is > broken for some strange reason... And I don't wish to introduce the > overhead of the C++ libraries to my system... > > If ldmutil contain all the information, I will backport this to C and > be happy... :) > Can you please tell me how you use the output of this utility to merge > a spanned partition on two separate disks? I don't have a Windows dynamic disk, so I can't imagine out to convert the output for dmsetup. Do you have a sample output? -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpWwbpYEhsfr.pgp Description: PGP signature
Re: ldminfo compilation
On Wed, Dec 12, 2007 at 04:39:18PM +0200, Alon Bar-Lev wrote: > Hello, > > I need to compile the ldminfo utility of linux-ntfs's package > linux-ldm. I need this as static or uclibc based. > > The author stated in the Documentation/filesystems/ntfs.txt: > """You will find the precompiled (i386) ldminfo utility there. NOTE: > You will not be able to compile this yourself easily so use the binary > version!""" > > I don't like to use binary versions, but this is not so important > I cannot use this dynamic linked x86 anyway. > > Looking at the sources, it seems that the linux headers used in order > to build this are out of date... Those are for the kernel module setting the partition tables. If you're only interested in the ldminfo utility: make -C ldmutil CPP='g++ -static' Substitute g++ for the C++ compiler you want to use. -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpXM5F17obdA.pgp Description: PGP signature
Re: [RFT] Port 0x80 I/O speed
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote: > Good day. > > Would some people on x86 (both 32 and 64) be kind enough to compile and run > the attached program? This is about testing how long I/O port access to port > 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting. > $ sudo ./port80 cycles: out 2729, in 1872 $ sudo ./port80 cycles: out 2729, in 1872 $ sudo ./port80 cycles: out 2711, in 1856 $ sudo ./port80 cycles: out 2711, in 1856 model name : Intel(R) Pentium(R) 4 CPU 1.90GHz stepping: 2 cpu MHz : 1917.229 cache size : 256 KB -- Luciano Rocha <[EMAIL PROTECTED]> Eurotux Informática, S.A. <http://www.eurotux.com/> pgpNPo6XbBfoE.pgp Description: PGP signature
Re: [RFT] Port 0x80 I/O speed
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote: Good day. Would some people on x86 (both 32 and 64) be kind enough to compile and run the attached program? This is about testing how long I/O port access to port 0x80 takes. It measures in CPU cycles so CPU speed is crucial in reporting. $ sudo ./port80 cycles: out 2729, in 1872 $ sudo ./port80 cycles: out 2729, in 1872 $ sudo ./port80 cycles: out 2711, in 1856 $ sudo ./port80 cycles: out 2711, in 1856 model name : Intel(R) Pentium(R) 4 CPU 1.90GHz stepping: 2 cpu MHz : 1917.229 cache size : 256 KB -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpNPo6XbBfoE.pgp Description: PGP signature
Re: ldminfo compilation
On Wed, Dec 12, 2007 at 04:39:18PM +0200, Alon Bar-Lev wrote: Hello, I need to compile the ldminfo utility of linux-ntfs's package linux-ldm. I need this as static or uclibc based. The author stated in the Documentation/filesystems/ntfs.txt: You will find the precompiled (i386) ldminfo utility there. NOTE: You will not be able to compile this yourself easily so use the binary version! I don't like to use binary versions, but this is not so important I cannot use this dynamic linked x86 anyway. Looking at the sources, it seems that the linux headers used in order to build this are out of date... Those are for the kernel module setting the partition tables. If you're only interested in the ldminfo utility: make -C ldmutil CPP='g++ -static' Substitute g++ for the C++ compiler you want to use. -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpXM5F17obdA.pgp Description: PGP signature
Re: ldminfo compilation
On Wed, Dec 12, 2007 at 04:57:39PM +0200, Alon Bar-Lev wrote: On 12/12/07, Luciano Rocha [EMAIL PROTECTED] wrote: Those are for the kernel module setting the partition tables. If you're only interested in the ldminfo utility: make -C ldmutil CPP='g++ -static' Substitute g++ for the C++ compiler you want to use. Hi! Thank you for your reply! I don't really understand how to use the output of ldmutil in order to do the dmsetup... All the instructions are for ldminfo... Ah, sorry. Somehow I got the impression that the ldmutil directory included the ldminfo binary. I'll see if I can compile the ldminfo statically in an older system I have. And the C++ dependency does not work well with uclibc... I tried to compile this using uclibc++, but the exception handling of uclibc++ is broken for some strange reason... And I don't wish to introduce the overhead of the C++ libraries to my system... If ldmutil contain all the information, I will backport this to C and be happy... :) Can you please tell me how you use the output of this utility to merge a spanned partition on two separate disks? I don't have a Windows dynamic disk, so I can't imagine out to convert the output for dmsetup. Do you have a sample output? -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpWwbpYEhsfr.pgp Description: PGP signature
Re: ldminfo compilation
On Wed, Dec 12, 2007 at 03:29:55PM +, Luciano Rocha wrote: On Wed, Dec 12, 2007 at 04:57:39PM +0200, Alon Bar-Lev wrote: On 12/12/07, Luciano Rocha [EMAIL PROTECTED] wrote: Those are for the kernel module setting the partition tables. If you're only interested in the ldminfo utility: make -C ldmutil CPP='g++ -static' Substitute g++ for the C++ compiler you want to use. Hi! Thank you for your reply! I don't really understand how to use the output of ldmutil in order to do the dmsetup... All the instructions are for ldminfo... Ah, sorry. Somehow I got the impression that the ldmutil directory included the ldminfo binary. I'll see if I can compile the ldminfo statically in an older system I have. OK, the statically compiled version is at: ftp://gil.di.uminho.pt/pub/users/strange/ldminfo sha1sum: 71c1451f9cbd1a4256bb072d4c930418acc8e2fb Anyway, how to compile with the sources of: - linux-2.4.20 - linux-ldm-0.0.8 ldm=linux-ldm-0.0.8 kernel=linux-2.4.20 1. Decompress linux-ldm-0.0.8: curl -s http://dl.sourceforge.net/sourceforge/linux-ntfs/$ldm.tar.bz2 \ | tar xjf - 2. Enter the directory: cd $ldm 3. Decompress the Linux kernel sources: curl -s ftp://ftp.di.uminho.pt/pub/kernel/v2.4/$kernel.tar.bz2 \ | tar xjf - 4. Change test/Makefile to compile ldminfo statically: sed -e 's/ -o/ -static /' -i test/Makefile 5. Correct KERNEL path in Makefile: sed -e s,KERNEL.*=.*,KERNEL = $PWD/$kernel, -i Makefile 6. Force i386 arch in Makefile: sed -e 's/-march=.*/-march=i386/' -i Makefile 7. Generate kernel's option files: yes n | make -C $kernel ARCH=i386 oldconfig dep 8. Compile ldminfo and ldmutil: make ARCH=i386 This worked on a Centos 3.8, 32bits but running x86_64 kernel, but not on my Fedora 8. YMMV. Shell script: ldm=linux-ldm-0.0.8 kernel=linux-2.4.20 curl -s http://dl.sourceforge.net/sourceforge/linux-ntfs/$ldm.tar.bz2 \ | tar xjf - cd $ldm curl -s ftp://ftp.di.uminho.pt/pub/kernel/v2.4/$kernel.tar.bz2 \ | tar xjf - sed -e 's/ -o/ -static /' -i test/Makefile sed -e s,KERNEL.*=.*,KERNEL = $PWD/$kernel, -i Makefile sed -e 's/-march=.*/-march=i386/' -i Makefile yes n | make -C $kernel ARCH=i386 oldconfig dep make ARCH=i386 -- Luciano Rocha [EMAIL PROTECTED] Eurotux Informática, S.A. http://www.eurotux.com/ pgpUfpx5h5mvx.pgp Description: PGP signature
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 06:35:25PM +0100, Pierre Ossman wrote: > On Sat, 24 Nov 2007 17:22:36 + > Luciano Rocha <[EMAIL PROTECTED]> wrote: > > > On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote: > > > It most certainly does not. gcc will assume that an int* has int > > > alignment. memcpy() is a builtin, which gcc can translate to pretty much > > > anything. And C specifies that a pointer to foo, will point to a real > > > object of type foo, so gcc can't be blamed for the unsafe typecasts. I > > > have tested this the hard way, so this is not just speculation. > > > > Yes, on *int and other assumed aligned pointers, gcc uses its internal > > version. > > > > However, my point is that those pointers, unless speaking of packed > > structures, can safely be assumed aligned, while char*/void* can't. > > > > I get the sensation we're violently in agreement here, just misunderstanding > each other. :) That's it. :) Sorry for the noise,... -- lfr 0/0 pgprb39HuMXhL.pgp Description: PGP signature
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> On Sat, 24 Nov 2007 15:50:52 +
> Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> >
> > Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
> > in any case. Intelligent ones, like the one provided in glibc, first copy
> > bytes till output is aligned (C file) *or* size is a multiple (i686 asm
> > file)
> > of word size, and then it copies word-by-word.
> >
> > Linux's x86_64 memcpy does the opposite, copies 64bit words, and then
> > copies the last bytes.
> >
> > So, in effect, as long as no packed structures are used, memcpy should
> > be safer on *int, etc., than *char, as the compiler ensures
> > word-alignment.
> >
>
> It most certainly does not. gcc will assume that an int* has int alignment.
> memcpy() is a builtin, which gcc can translate to pretty much anything. And C
> specifies that a pointer to foo, will point to a real object of type foo, so
> gcc can't be blamed for the unsafe typecasts. I have tested this the hard
> way, so this is not just speculation.
Yes, on *int and other assumed aligned pointers, gcc uses its internal
version.
However, my point is that those pointers, unless speaking of packed
structures, can safely be assumed aligned, while char*/void* can't.
> In other words, memcpy() does _not_ save you from alignment issues. If you
> cast from char* or void* to something else, you better be damn sure the
> alignment is correct because gcc will assume it is.
Nothing does, even memcpy doesn't check alignment of the source, or
alignment at all in some assembly implementations (only word-copy,
without checking if at word-boundary).
--
lfr
0/0
pgpSqyJvQFOo9.pgp
Description: PGP signature
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 02:34:41PM +0100, Pierre Ossman wrote:
> On Fri, 23 Nov 2007 00:15:53 + (GMT)
> Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> > Being spoilt by the luxuries of i386/x86_64 I've never really had a good
> > grasp on unaligned memory access problems on other architectures and decided
> > it was time to figure it out. As a result I've written this documentation
> > which I plan to submit for inclusion as
> > Documentation/unaligned_memory_access.txt
> >
> > Before I do so, any comments on the following?
> >
>
> A very nice, and much needed document. I think you should include one thing
> though:
>
> memcpy() is _only_ safe when one of the pointers is char* or void*. If it is
> anything more complex than that, gcc will assume alignment and optimise based
> on that. E.g. memcpy() of two long:s generates the same assembly as doing an
> assignment.
Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
in any case. Intelligent ones, like the one provided in glibc, first copy
bytes till output is aligned (C file) *or* size is a multiple (i686 asm file)
of word size, and then it copies word-by-word.
Linux's x86_64 memcpy does the opposite, copies 64bit words, and then
copies the last bytes.
So, in effect, as long as no packed structures are used, memcpy should
be safer on *int, etc., than *char, as the compiler ensures
word-alignment.
--
lfr
0/0
pgpQa3znDcMST.pgp
Description: PGP signature
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 02:34:41PM +0100, Pierre Ossman wrote:
On Fri, 23 Nov 2007 00:15:53 + (GMT)
Daniel Drake [EMAIL PROTECTED] wrote:
Being spoilt by the luxuries of i386/x86_64 I've never really had a good
grasp on unaligned memory access problems on other architectures and decided
it was time to figure it out. As a result I've written this documentation
which I plan to submit for inclusion as
Documentation/unaligned_memory_access.txt
Before I do so, any comments on the following?
A very nice, and much needed document. I think you should include one thing
though:
memcpy() is _only_ safe when one of the pointers is char* or void*. If it is
anything more complex than that, gcc will assume alignment and optimise based
on that. E.g. memcpy() of two long:s generates the same assembly as doing an
assignment.
Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
in any case. Intelligent ones, like the one provided in glibc, first copy
bytes till output is aligned (C file) *or* size is a multiple (i686 asm file)
of word size, and then it copies word-by-word.
Linux's x86_64 memcpy does the opposite, copies 64bit words, and then
copies the last bytes.
So, in effect, as long as no packed structures are used, memcpy should
be safer on *int, etc., than *char, as the compiler ensures
word-alignment.
--
lfr
0/0
pgpQa3znDcMST.pgp
Description: PGP signature
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
On Sat, 24 Nov 2007 15:50:52 +
Luciano Rocha [EMAIL PROTECTED] wrote:
Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
in any case. Intelligent ones, like the one provided in glibc, first copy
bytes till output is aligned (C file) *or* size is a multiple (i686 asm
file)
of word size, and then it copies word-by-word.
Linux's x86_64 memcpy does the opposite, copies 64bit words, and then
copies the last bytes.
So, in effect, as long as no packed structures are used, memcpy should
be safer on *int, etc., than *char, as the compiler ensures
word-alignment.
It most certainly does not. gcc will assume that an int* has int alignment.
memcpy() is a builtin, which gcc can translate to pretty much anything. And C
specifies that a pointer to foo, will point to a real object of type foo, so
gcc can't be blamed for the unsafe typecasts. I have tested this the hard
way, so this is not just speculation.
Yes, on *int and other assumed aligned pointers, gcc uses its internal
version.
However, my point is that those pointers, unless speaking of packed
structures, can safely be assumed aligned, while char*/void* can't.
In other words, memcpy() does _not_ save you from alignment issues. If you
cast from char* or void* to something else, you better be damn sure the
alignment is correct because gcc will assume it is.
Nothing does, even memcpy doesn't check alignment of the source, or
alignment at all in some assembly implementations (only word-copy,
without checking if at word-boundary).
--
lfr
0/0
pgpSqyJvQFOo9.pgp
Description: PGP signature
Re: [RFC] Documentation about unaligned memory access
On Sat, Nov 24, 2007 at 06:35:25PM +0100, Pierre Ossman wrote: On Sat, 24 Nov 2007 17:22:36 + Luciano Rocha [EMAIL PROTECTED] wrote: On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote: It most certainly does not. gcc will assume that an int* has int alignment. memcpy() is a builtin, which gcc can translate to pretty much anything. And C specifies that a pointer to foo, will point to a real object of type foo, so gcc can't be blamed for the unsafe typecasts. I have tested this the hard way, so this is not just speculation. Yes, on *int and other assumed aligned pointers, gcc uses its internal version. However, my point is that those pointers, unless speaking of packed structures, can safely be assumed aligned, while char*/void* can't. I get the sensation we're violently in agreement here, just misunderstanding each other. :) That's it. :) Sorry for the noise,... -- lfr 0/0 pgprb39HuMXhL.pgp Description: PGP signature
Re: can't change euid 0 to uid != running user
On Fri, Oct 05, 2007 at 08:28:50AM -0700, Ray Lee wrote:
> On 10/5/07, Luciano Rocha <[EMAIL PROTECTED]> wrote:
> > I have the following problem:
> > $ sudo -u ie -s # or sudo su ie
> > unable to change to runas uid: Resource temporarily unavailable
> >
> > Works:
> > $ sudo su, followed by su ie
> >
> > The first sudo also worked while I had a shell under user ie.
> >
> > When I exited, it stopped working, but it is now working every time I
> > trie it.
> >
> > dmesg shows:
> >
> > [82602.729330] kobject_add failed for 504 with -EEXIST, don't try to
> >register things with the same name in the same directory.
> > [82602.729365] [] kobject_shadow_add+0x16e/0x1a0
> > [82602.729383] [] kobject_set_name+0x29/0x92
> > [82602.729504] [] user_kobject_create+0x6a/0x90
> > [82602.729520] [] alloc_uid+0x18f/0x1d7
> > [82602.729530] [] set_user+0x1c/0x8f
> > [82602.729539] [] sys_setresuid+0xd5/0x162
> > [82602.729552] [] syscall_call+0x7/0xb
> > [82602.729575] ===
> >
> > $ git describe
> > v2.6.23-rc9-156-ga95dacb
> >
> > (Clone of Linus' tree, after rc9, with some patches from
> > mingo/linux-2.6-sched-devel.git, and a fix for lguest (didn't link due
> > to kasprintf)).
>
> Hmm, it works for me under 2.6.23-rc6, so it's either a difference
> between our .configs or a late regression. If you could bisect the
> problem (starting with reverting Ingo's sched devel patches and lguest
> patches, and trying that), then that would tell us where the issue is.
>
Without the patches, i.e., a clean Linus tree (v2.6.23-rc9-41-g804b3f9),
I can't reproduce it anymore.
The commits since v2.6.23-rc9:
804b3f9a16e446cb023417faec58b6506c834052 Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
3e0ca2f148f97c5748f52bcf2a69dd17cb2b1d13 Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
c7659e2c139d0be4647bef89188a932e0254d709 Merge branch 'upstream' of
git://ftp.linux-mips.org/pub/scm/upstream-linus
66b1f1a982bf4dbad9fa0de25b8d95c4936f05c4 Merge branch 'for-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6
991bf528f602882580d0918842b125255d246a19 drivers/ata/pata_ixp4xx_cf.c: ioremap
return code check
90925d3050253ff7b4f5d1660071df75f44bd0ff Ata: pata_marvell, use ioread* for
iomap-ped memory
4007b493ee6e4a52c2b618ab8361847fba5bf116 libata: fix for sata_mv >64KB DMA
segments
bda0233b89c10ae46ccecb78bffdaf0fd7833d17 ocfs2: Unlock mutex in local alloc
failure case
529d303e075aa6d988f30935b8995ffb382ad38e sky2: jumbo frame regression fix
5c55c434917429f229a1bf43def97fd421f444c6 Merge branch 'fixes-jgarzik' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 into
upstream-fixes
cda6a20b68c1f21f4b4bc9cd3ee08494e7ebf0d5 Blackfin arch: fix PORT_J BUG for
BF537/6 EMAC driver reported by Kalle Pokki <[EMAIL PROTECTED]>
c58c2140f08de4ad0b0dbd48f6e78168dc321042 Blackfin arch: gpio pinmux and
resource allocation API required by BF537 on chip ethernet mac driver
9ea0f043fec38fadb0101fbf29563a5635f42e93 [MIPS] Terminally fix
local_{dec,sub}_if_positive
fef74705ea310acd716c2722bfeb0f796cf23640 [MIPS] Type proof reimplementation of
cmpxchg.
f6a9e6dec537dc1d9d2c62d7b8ad205d0993bddc [MIPS] pg-r4k.c: Fix a typo in an
R4600 v2 erratum workaround
ee0a8169b693e1c708d0f9af0a5e4ade65a65439 [PATCH] softmac: Fix compiler-warning
4365e99f9587b94010e9818a4237ce2b1c734e91 [PATCH] bcm43xx: Correct printk with
PFX before KERN_
f778089cb2445dfc6dfd30a7a567925fd8589f1e Merge branch 'sas-fixes' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6
db7a89db5e3bc6ba131965183577b15fd6fc92cc Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
2910ca6f8ae69648623b3c05b79be87dd7bda73d Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
d237098c03eb91cef240e9a1b248c0e1ecd1c80c Merge
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched
114d5b1ca265f8a582dcbf0030da20ccdddbe8e1 Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
2b3b29080d702e5488f214276170ab46adc40ee5 Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
e80eaf9904d5b19512265e1435372b2e12146a5f Merge branch 'merge' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
d136552e8beadcf5e59089292e2ba44f09e3aad8 aic94xx: fix DMA data direction for
SMP requests
f662fe5a0b144efadbfc00e8040e603ec318746e dm9601: Fix receive MTU
593ff56ef2a23ed3a66ee87d9c9b33044b9fb193 mv643xx_eth: Do not modify struct
netdev tx_queue_len
50626297b1beb0a29c0f174be39f36485533216c qla3xxx: bugfix: Fix VLAN rx
completion
Re: can't change euid 0 to uid != running user
On Fri, Oct 05, 2007 at 08:28:50AM -0700, Ray Lee wrote:
On 10/5/07, Luciano Rocha [EMAIL PROTECTED] wrote:
I have the following problem:
$ sudo -u ie -s # or sudo su ie
unable to change to runas uid: Resource temporarily unavailable
Works:
$ sudo su, followed by su ie
The first sudo also worked while I had a shell under user ie.
When I exited, it stopped working, but it is now working every time I
trie it.
dmesg shows:
[82602.729330] kobject_add failed for 504 with -EEXIST, don't try to
register things with the same name in the same directory.
[82602.729365] [c04b9195] kobject_shadow_add+0x16e/0x1a0
[82602.729383] [c04b9480] kobject_set_name+0x29/0x92
[82602.729504] [c04238ea] user_kobject_create+0x6a/0x90
[82602.729520] [c0423cce] alloc_uid+0x18f/0x1d7
[82602.729530] [c0427030] set_user+0x1c/0x8f
[82602.729539] [c0428b5f] sys_setresuid+0xd5/0x162
[82602.729552] [c0403e6a] syscall_call+0x7/0xb
[82602.729575] ===
$ git describe
v2.6.23-rc9-156-ga95dacb
(Clone of Linus' tree, after rc9, with some patches from
mingo/linux-2.6-sched-devel.git, and a fix for lguest (didn't link due
to kasprintf)).
Hmm, it works for me under 2.6.23-rc6, so it's either a difference
between our .configs or a late regression. If you could bisect the
problem (starting with reverting Ingo's sched devel patches and lguest
patches, and trying that), then that would tell us where the issue is.
Without the patches, i.e., a clean Linus tree (v2.6.23-rc9-41-g804b3f9),
I can't reproduce it anymore.
The commits since v2.6.23-rc9:
804b3f9a16e446cb023417faec58b6506c834052 Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
3e0ca2f148f97c5748f52bcf2a69dd17cb2b1d13 Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
c7659e2c139d0be4647bef89188a932e0254d709 Merge branch 'upstream' of
git://ftp.linux-mips.org/pub/scm/upstream-linus
66b1f1a982bf4dbad9fa0de25b8d95c4936f05c4 Merge branch 'for-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/cooloney/blackfin-2.6
991bf528f602882580d0918842b125255d246a19 drivers/ata/pata_ixp4xx_cf.c: ioremap
return code check
90925d3050253ff7b4f5d1660071df75f44bd0ff Ata: pata_marvell, use ioread* for
iomap-ped memory
4007b493ee6e4a52c2b618ab8361847fba5bf116 libata: fix for sata_mv 64KB DMA
segments
bda0233b89c10ae46ccecb78bffdaf0fd7833d17 ocfs2: Unlock mutex in local alloc
failure case
529d303e075aa6d988f30935b8995ffb382ad38e sky2: jumbo frame regression fix
5c55c434917429f229a1bf43def97fd421f444c6 Merge branch 'fixes-jgarzik' of
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6 into
upstream-fixes
cda6a20b68c1f21f4b4bc9cd3ee08494e7ebf0d5 Blackfin arch: fix PORT_J BUG for
BF537/6 EMAC driver reported by Kalle Pokki [EMAIL PROTECTED]
c58c2140f08de4ad0b0dbd48f6e78168dc321042 Blackfin arch: gpio pinmux and
resource allocation API required by BF537 on chip ethernet mac driver
9ea0f043fec38fadb0101fbf29563a5635f42e93 [MIPS] Terminally fix
local_{dec,sub}_if_positive
fef74705ea310acd716c2722bfeb0f796cf23640 [MIPS] Type proof reimplementation of
cmpxchg.
f6a9e6dec537dc1d9d2c62d7b8ad205d0993bddc [MIPS] pg-r4k.c: Fix a typo in an
R4600 v2 erratum workaround
ee0a8169b693e1c708d0f9af0a5e4ade65a65439 [PATCH] softmac: Fix compiler-warning
4365e99f9587b94010e9818a4237ce2b1c734e91 [PATCH] bcm43xx: Correct printk with
PFX before KERN_
f778089cb2445dfc6dfd30a7a567925fd8589f1e Merge branch 'sas-fixes' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/misc-2.6
db7a89db5e3bc6ba131965183577b15fd6fc92cc Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6
2910ca6f8ae69648623b3c05b79be87dd7bda73d Merge branch 'upstream-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev
d237098c03eb91cef240e9a1b248c0e1ecd1c80c Merge
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/linux-2.6-sched
114d5b1ca265f8a582dcbf0030da20ccdddbe8e1 Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6
2b3b29080d702e5488f214276170ab46adc40ee5 Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6
e80eaf9904d5b19512265e1435372b2e12146a5f Merge branch 'merge' of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc
d136552e8beadcf5e59089292e2ba44f09e3aad8 aic94xx: fix DMA data direction for
SMP requests
f662fe5a0b144efadbfc00e8040e603ec318746e dm9601: Fix receive MTU
593ff56ef2a23ed3a66ee87d9c9b33044b9fb193 mv643xx_eth: Do not modify struct
netdev tx_queue_len
50626297b1beb0a29c0f174be39f36485533216c qla3xxx: bugfix: Fix VLAN rx
completion handling.
b323e0e49fe9331ee3a7a336af879d6e303b16b3 qla3xxx: bugfix: Add memory barrier
before accessing rx completion.
4c74d4ec3524a8f31deadd115139dd93bc91d598 ata_piix: add another TECRA M3 entry
to broken suspend list
Re: can't change euid 0 to uid != running user
On Fri, Oct 05, 2007 at 08:28:50AM -0700, Ray Lee wrote: > On 10/5/07, Luciano Rocha <[EMAIL PROTECTED]> wrote: > > I have the following problem: > > $ sudo -u ie -s # or sudo su ie > > unable to change to runas uid: Resource temporarily unavailable > > > > Works: > > $ sudo su, followed by su ie > > > > The first sudo also worked while I had a shell under user ie. > > > > When I exited, it stopped working, but it is now working every time I > > trie it. > > > > dmesg shows: > > > > [82602.729330] kobject_add failed for 504 with -EEXIST, don't try to > >register things with the same name in the same directory. > > [82602.729365] [] kobject_shadow_add+0x16e/0x1a0 > > [82602.729383] [] kobject_set_name+0x29/0x92 > > [82602.729504] [] user_kobject_create+0x6a/0x90 > > [82602.729520] [] alloc_uid+0x18f/0x1d7 > > [82602.729530] [] set_user+0x1c/0x8f > > [82602.729539] [] sys_setresuid+0xd5/0x162 > > [82602.729552] [] syscall_call+0x7/0xb > > [82602.729575] === > > > > $ git describe > > v2.6.23-rc9-156-ga95dacb > > > > (Clone of Linus' tree, after rc9, with some patches from > > mingo/linux-2.6-sched-devel.git, and a fix for lguest (didn't link due > > to kasprintf)). > > Hmm, it works for me under 2.6.23-rc6, so it's either a difference > between our .configs or a late regression. If you could bisect the > problem (starting with reverting Ingo's sched devel patches and lguest > patches, and trying that), then that would tell us where the issue is. I'll try a clean Linus' tree tomorrow and see if I can reproduce the problem. -- lfr 0/0 pgpG7vguKTZ9j.pgp Description: PGP signature
lguest compilation problem in 2.6.23-rc9
$ git describe v2.6.23-rc9 $ make ... BUILD arch/i386/boot/bzImage Root device is (254, 3) Setup is 11496 bytes (padded to 11776 bytes). System is 1233 kB Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 282 modules ERROR: "kasprintf" [drivers/lguest/lg.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Latest Linus' kernel tree: $ git describe v2.6.23-rc9-41-g804b3f9 $ make oldconfig ... $ make BUILD arch/i386/boot/bzImage Root device is (254, 3) Setup is 11496 bytes (padded to 11776 bytes). System is 1234 kB Kernel: arch/i386/boot/bzImage is ready (#2) Building modules, stage 2. MODPOST 282 modules ERROR: "kasprintf" [drivers/lguest/lg.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Config follows. -- lfr 0/0 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc9 # Fri Oct 5 15:33:00 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="luc2" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="anticipatory" # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_PARAVIRT=y # CONFIG_XEN is not set # CONFIG_VMI is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y
can't change euid 0 to uid != running user
Hello, I have the following problem: $ sudo -u ie -s # or sudo su ie unable to change to runas uid: Resource temporarily unavailable Works: $ sudo su, followed by su ie The first sudo also worked while I had a shell under user ie. When I exited, it stopped working, but it is now working every time I trie it. dmesg shows: [82602.729330] kobject_add failed for 504 with -EEXIST, don't try to register things with the same name in the same directory. [82602.729365] [] kobject_shadow_add+0x16e/0x1a0 [82602.729383] [] kobject_set_name+0x29/0x92 [82602.729504] [] user_kobject_create+0x6a/0x90 [82602.729520] [] alloc_uid+0x18f/0x1d7 [82602.729530] [] set_user+0x1c/0x8f [82602.729539] [] sys_setresuid+0xd5/0x162 [82602.729552] [] syscall_call+0x7/0xb [82602.729575] === $ git describe v2.6.23-rc9-156-ga95dacb (Clone of Linus' tree, after rc9, with some patches from mingo/linux-2.6-sched-devel.git, and a fix for lguest (didn't link due to kasprintf)). -- lfr 0/0 pgphUXeEs2R5R.pgp Description: PGP signature
can't change euid 0 to uid != running user
Hello, I have the following problem: $ sudo -u ie -s # or sudo su ie unable to change to runas uid: Resource temporarily unavailable Works: $ sudo su, followed by su ie The first sudo also worked while I had a shell under user ie. When I exited, it stopped working, but it is now working every time I trie it. dmesg shows: [82602.729330] kobject_add failed for 504 with -EEXIST, don't try to register things with the same name in the same directory. [82602.729365] [c04b9195] kobject_shadow_add+0x16e/0x1a0 [82602.729383] [c04b9480] kobject_set_name+0x29/0x92 [82602.729504] [c04238ea] user_kobject_create+0x6a/0x90 [82602.729520] [c0423cce] alloc_uid+0x18f/0x1d7 [82602.729530] [c0427030] set_user+0x1c/0x8f [82602.729539] [c0428b5f] sys_setresuid+0xd5/0x162 [82602.729552] [c0403e6a] syscall_call+0x7/0xb [82602.729575] === $ git describe v2.6.23-rc9-156-ga95dacb (Clone of Linus' tree, after rc9, with some patches from mingo/linux-2.6-sched-devel.git, and a fix for lguest (didn't link due to kasprintf)). -- lfr 0/0 pgphUXeEs2R5R.pgp Description: PGP signature
lguest compilation problem in 2.6.23-rc9
$ git describe v2.6.23-rc9 $ make ... BUILD arch/i386/boot/bzImage Root device is (254, 3) Setup is 11496 bytes (padded to 11776 bytes). System is 1233 kB Kernel: arch/i386/boot/bzImage is ready (#1) Building modules, stage 2. MODPOST 282 modules ERROR: kasprintf [drivers/lguest/lg.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Latest Linus' kernel tree: $ git describe v2.6.23-rc9-41-g804b3f9 $ make oldconfig ... $ make BUILD arch/i386/boot/bzImage Root device is (254, 3) Setup is 11496 bytes (padded to 11776 bytes). System is 1234 kB Kernel: arch/i386/boot/bzImage is ready (#2) Building modules, stage 2. MODPOST 282 modules ERROR: kasprintf [drivers/lguest/lg.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 Config follows. -- lfr 0/0 # # Automatically generated make config: don't edit # Linux kernel version: 2.6.23-rc9 # Fri Oct 5 15:33:00 2007 # CONFIG_X86_32=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_X86=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION=luc2 # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_USER_NS is not set CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=15 # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory # # Processor type and features # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # CONFIG_SMP is not set CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set CONFIG_PARAVIRT=y # CONFIG_XEN is not set # CONFIG_VMI is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MCORE2 is not set CONFIG_MPENTIUM4=y # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=7 CONFIG_X86_XADD=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_TSC=y CONFIG_X86_CMOV=y CONFIG_X86_MINIMUM_CPU_FAMILY=4 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y CONFIG_X86_MCE=y
Re: can't change euid 0 to uid != running user
On Fri, Oct 05, 2007 at 08:28:50AM -0700, Ray Lee wrote: On 10/5/07, Luciano Rocha [EMAIL PROTECTED] wrote: I have the following problem: $ sudo -u ie -s # or sudo su ie unable to change to runas uid: Resource temporarily unavailable Works: $ sudo su, followed by su ie The first sudo also worked while I had a shell under user ie. When I exited, it stopped working, but it is now working every time I trie it. dmesg shows: [82602.729330] kobject_add failed for 504 with -EEXIST, don't try to register things with the same name in the same directory. [82602.729365] [c04b9195] kobject_shadow_add+0x16e/0x1a0 [82602.729383] [c04b9480] kobject_set_name+0x29/0x92 [82602.729504] [c04238ea] user_kobject_create+0x6a/0x90 [82602.729520] [c0423cce] alloc_uid+0x18f/0x1d7 [82602.729530] [c0427030] set_user+0x1c/0x8f [82602.729539] [c0428b5f] sys_setresuid+0xd5/0x162 [82602.729552] [c0403e6a] syscall_call+0x7/0xb [82602.729575] === $ git describe v2.6.23-rc9-156-ga95dacb (Clone of Linus' tree, after rc9, with some patches from mingo/linux-2.6-sched-devel.git, and a fix for lguest (didn't link due to kasprintf)). Hmm, it works for me under 2.6.23-rc6, so it's either a difference between our .configs or a late regression. If you could bisect the problem (starting with reverting Ingo's sched devel patches and lguest patches, and trying that), then that would tell us where the issue is. I'll try a clean Linus' tree tomorrow and see if I can reproduce the problem. -- lfr 0/0 pgpG7vguKTZ9j.pgp Description: PGP signature
data disclosure in ioctl sg inquiry
(Please keep me CC'ed. Thanks.)
Hello,
While testing the SG INQUIRY command to a locked hard drive, connected
with USB, I noted that the command result included garbage that seemed
part of some other's process memory. Like bash functions, command
arguments, etc..
I make sure to memset the buffers before running the ioctl, so this seem
to be data leaked from the kernel.
Most of the code is verbatim from the example in the SCSI Generic HOWTO
(<http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html>).
I include the code I used and sample output with data from running
processes (or files?).
I can't reproduce this on a firewire connected HDD, but I can with
another USB connecte one (not locked).
Regards,
Luciano Rocha
--
lfr
0/0
# sda is firewire, unlocked, sdb is usb, locked, and sdc is usb, unlocked
$ ./keytool /dev/sda
Some of the INQUIRY command's response:
00 00 04 02 1f 00 00 00 53 41 4d 53 55 4e 47 20 SAMSUNG
48 44 35 30 31 4c 4a 20 20 20 20 20 20 20 20 20 HD501LJ
43 52 31 30 00 00 00 00 00 00 00 00 00 00 00 00 CR10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 1d c0 ff ff ff c1 ff
INQUIRY duration=3 millisecs, resid=0
# always the same output for sda
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32 3.AA#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08 340.H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72 Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20 --exclude .svn
INQUIRY duration=3 millisecs, resid=60
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 2e 70 6c 20 73 79 6e 63 20 78 70 74 3.AA.pl sync xpt
6f 20 7a 62 72 20 7c 20 6c 65 73 73 00 4c 11 08 o zbr | less.L..
f0 c8 11 08 11 00 00 00 23 31 31 38 38 32 32 32 #1188222
33 34 30 00 11 00 00 00 68 c0 11 08 48 c0 11 08 340.h...H...
INQUIRY duration=3 millisecs, resid=60
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 21 00 00 00 10 2f 12 08 18 2f 12 08 3.AA!/.../..
00 00 00 00 00 00 00 00 00 00 00 00 24 00 00 00 $...
01 00 00 00 19 00 00 00 98 1b 12 08 6d 65 2f 6c me/l
75 63 69 61 6e 6f 00 7d 22 00 10 08 19 00 00 00 uciano.}"...
INQUIRY duration=0 millisecs, resid=60
$ ./keytool /dev/sdc
Some of the INQUIRY command's response:
00 00 00 00 23 00 00 00 57 44 43 20 57 44 32 35 #...WDC WD25
30 30 42 42 2d 30 30 52 44 41 30 20 20 20 20 20 00BB-00RDA0
32 30 2e 30 06 7b 25 07 08 3a 11 08 40 e9 12 08 20.0.{%..:[EMAIL PROTECTED]
10 3a 11 08 3b 00 00 00 28 f8 11 08 11 00 00 00 .:..;...(...
df df df df df df df df 30 00 00 00 11 00 00 00 0...
80 54 13 08 18 20 00 00 00 00 00 00 19 00 00 00 .T... ..
INQUIRY duration=0 millisecs, resid=56
$ ./keytool /dev/sdc
Some of the INQUIRY command's response:
00 00 00 00 23 00 00 00 57 44 43 20 57 44 32 35 #...WDC WD25
30 30 42 42 2d 30 30 52 44 41 30 20 20 20 20 20 00BB-00RDA0
32 30 2e 30 06 7b 25 07 73 73 68 20 70 00 11 45 20.0.{%.ssh p..E
00 00 00 00 11 00 00 00 23 31 31 38 38 32 30 32 #1188202
34 32 30 00 11 00 00 00 58 e0 12 08 38 e0 12 08 420.X...8...
00 00 00 00 21 00 00 00 63 64 20 2f 70 72 69 76 !...cd /priv
INQUIRY duration=3 millisecs, resid=56
...
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static void dump(const unsigned char *b, int l)
{
int i;
while (l) {
for (i = 0; i < l && i < 16; ++i)
printf("%02x ", b[i]);
printf(" ");
for (i = 0; i < l && i < 16; ++i) {
if (b[i] < 0x20 || b[i] > 0x7e) {
printf(".");
} else {
printf("%c", b[i]);
}
}
printf("\n");
b += i;
l -= i;
}
}
enum { INQ_REPLY_LEN = 96, INQ_CMD_CODE = 0x12, INQ_CMD_LEN = 6 };
static void hdd_ident(const char *device)
{
unsigned char inqCmdBlk[INQ_CMD_LEN] = {
INQ_CMD_CODE, 0, 0, 0, INQ_REPLY_LEN, 0
};
unsigned char inqBuff[INQ_REPLY_LEN];
unsigned char sense_buffer[32];
union {
data disclosure in ioctl sg inquiry
(Please keep me CC'ed. Thanks.)
Hello,
While testing the SG INQUIRY command to a locked hard drive, connected
with USB, I noted that the command result included garbage that seemed
part of some other's process memory. Like bash functions, command
arguments, etc..
I make sure to memset the buffers before running the ioctl, so this seem
to be data leaked from the kernel.
Most of the code is verbatim from the example in the SCSI Generic HOWTO
(http://tldp.org/HOWTO/SCSI-Generic-HOWTO/pexample.html).
I include the code I used and sample output with data from running
processes (or files?).
I can't reproduce this on a firewire connected HDD, but I can with
another USB connecte one (not locked).
Regards,
Luciano Rocha
--
lfr
0/0
# sda is firewire, unlocked, sdb is usb, locked, and sdc is usb, unlocked
$ ./keytool /dev/sda
Some of the INQUIRY command's response:
00 00 04 02 1f 00 00 00 53 41 4d 53 55 4e 47 20 SAMSUNG
48 44 35 30 31 4c 4a 20 20 20 20 20 20 20 20 20 HD501LJ
43 52 31 30 00 00 00 00 00 00 00 00 00 00 00 00 CR10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 1d c0 ff ff ff c1 ff
INQUIRY duration=3 millisecs, resid=0
# always the same output for sda
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 11 00 00 00 23 31 31 38 38 32 32 32 3.AA#1188222
33 34 30 00 11 00 00 00 48 00 12 08 28 00 12 08 340.H...(...
00 00 00 00 59 00 00 00 64 69 66 66 20 2d 75 72 Y...diff -ur
20 2d 2d 65 78 63 6c 75 64 65 20 2e 73 76 6e 20 --exclude .svn
INQUIRY duration=3 millisecs, resid=60
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 2e 70 6c 20 73 79 6e 63 20 78 70 74 3.AA.pl sync xpt
6f 20 7a 62 72 20 7c 20 6c 65 73 73 00 4c 11 08 o zbr | less.L..
f0 c8 11 08 11 00 00 00 23 31 31 38 38 32 32 32 #1188222
33 34 30 00 11 00 00 00 68 c0 11 08 48 c0 11 08 340.h...H...
INQUIRY duration=3 millisecs, resid=60
$ ./keytool /dev/sdb
Some of the INQUIRY command's response:
00 00 00 00 1f 00 00 00 4d 41 58 54 4f 52 20 53 MAXTOR S
54 4d 33 32 35 30 38 32 30 41 20 20 20 20 20 20 TM3250820A
33 2e 41 41 21 00 00 00 10 2f 12 08 18 2f 12 08 3.AA!/.../..
00 00 00 00 00 00 00 00 00 00 00 00 24 00 00 00 $...
01 00 00 00 19 00 00 00 98 1b 12 08 6d 65 2f 6c me/l
75 63 69 61 6e 6f 00 7d 22 00 10 08 19 00 00 00 uciano.}...
INQUIRY duration=0 millisecs, resid=60
$ ./keytool /dev/sdc
Some of the INQUIRY command's response:
00 00 00 00 23 00 00 00 57 44 43 20 57 44 32 35 #...WDC WD25
30 30 42 42 2d 30 30 52 44 41 30 20 20 20 20 20 00BB-00RDA0
32 30 2e 30 06 7b 25 07 08 3a 11 08 40 e9 12 08 20.0.{%..:[EMAIL PROTECTED]
10 3a 11 08 3b 00 00 00 28 f8 11 08 11 00 00 00 .:..;...(...
df df df df df df df df 30 00 00 00 11 00 00 00 0...
80 54 13 08 18 20 00 00 00 00 00 00 19 00 00 00 .T... ..
INQUIRY duration=0 millisecs, resid=56
$ ./keytool /dev/sdc
Some of the INQUIRY command's response:
00 00 00 00 23 00 00 00 57 44 43 20 57 44 32 35 #...WDC WD25
30 30 42 42 2d 30 30 52 44 41 30 20 20 20 20 20 00BB-00RDA0
32 30 2e 30 06 7b 25 07 73 73 68 20 70 00 11 45 20.0.{%.ssh p..E
00 00 00 00 11 00 00 00 23 31 31 38 38 32 30 32 #1188202
34 32 30 00 11 00 00 00 58 e0 12 08 38 e0 12 08 420.X...8...
00 00 00 00 21 00 00 00 63 64 20 2f 70 72 69 76 !...cd /priv
INQUIRY duration=3 millisecs, resid=56
...
#include sys/types.h
#include sys/stat.h
#include sys/ioctl.h
#include fcntl.h
#include unistd.h
#include errno.h
#include error.h
#include stdio.h
#include stdlib.h
#include string.h
#include scsi/sg.h
#include linux/hdreg.h
static void dump(const unsigned char *b, int l)
{
int i;
while (l) {
for (i = 0; i l i 16; ++i)
printf(%02x , b[i]);
printf( );
for (i = 0; i l i 16; ++i) {
if (b[i] 0x20 || b[i] 0x7e) {
printf(.);
} else {
printf(%c, b[i]);
}
}
printf(\n);
b += i;
l -= i;
}
}
enum { INQ_REPLY_LEN = 96, INQ_CMD_CODE = 0x12, INQ_CMD_LEN = 6 };
static void hdd_ident(const char *device)
{
unsigned char inqCmdBlk[INQ_CMD_LEN] = {
INQ_CMD_CODE, 0, 0, 0, INQ_REPLY_LEN, 0
};
unsigned char inqBuff[INQ_REPLY_LEN];
unsigned char sense_buffer[32];
union {
struct
