User-mode Linux kernel port

On Thursday 08 December 2005 03:13, Antoine Martin wrote:
> I'm still trying to get a regular FC4 image to boot with the latest x86
> tls support code.
Mainline kernel or with jdike patchset?
> (since Gentoo works fine) 
> but this is what I get:
> # fsck.ext3 -a /dev/ubda
> set_thread_area failed when setting up thread-local storage
> Segmentation fault

> Is this glibc? Any ideas?

Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread, but it 
seems to do that.

Also, different glibc are more or less happy in using modify_ldt() rather than 
set_thread_area() - it seems that latter is better.

> Thanks
> Antoine

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

On Fri, 2005-12-09 at 18:52 +0100, Blaisorblade wrote:
> On Thursday 08 December 2005 03:13, Antoine Martin wrote:
> > I'm still trying to get a regular FC4 image to boot with the latest x86
> > tls support code.
> Mainline kernel or with jdike patchset?
Latest jdike from sf
> > (since Gentoo works fine) 
> > but this is what I get:
> > # fsck.ext3 -a /dev/ubda
> > set_thread_area failed when setting up thread-local storage
> > Segmentation fault
> 
> > Is this glibc? Any ideas?
> 
> Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread, but it 
> seems to do that.
I wasn't even thinking about that! So true, why on earth would fsck
require threading!?

> Also, different glibc are more or less happy in using modify_ldt() rather than 
> set_thread_area() - it seems that latter is better.
Ahh, is it planned or do I have to make heavily modified distro images?

Antoine

On Friday 09 December 2005 19:39, Antoine Martin wrote:
> On Fri, 2005-12-09 at 18:52 +0100, Blaisorblade wrote:
> > On Thursday 08 December 2005 03:13, Antoine Martin wrote:
> > > I'm still trying to get a regular FC4 image to boot with the latest x86
> > > tls support code.
> >
> > Mainline kernel or with jdike patchset?

> Latest jdike from sf

> > > (since Gentoo works fine)
> > > but this is what I get:
> > > # fsck.ext3 -a /dev/ubda
> > > set_thread_area failed when setting up thread-local storage
> > > Segmentation fault

> > > Is this glibc? Any ideas?

> > Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread,
> > but it seems to do that.

> I wasn't even thinking about that! So true, why on earth would fsck
> require threading!?

> > Also, different glibc are more or less happy in using modify_ldt() rather
> > than set_thread_area() - it seems that latter is better.

> Ahh, is it planned 
What?
> or do I have to make heavily modified distro images? 
I'm not suggesting that...

And, hold on this - Jeff has made a big progress on this, diagnosing what had 
been happening.

I'm not sure how well it works, but in the incrementals page there's the new 
result. Give it a run and tell us the result, if it works it might go in 
2.6.15-bs and 2.6.16.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

> > > Also, different glibc are more or less happy in using modify_ldt() rather
> > > than set_thread_area() - it seems that latter is better.
> 
> > Ahh, is it planned 
> What?
I was wondering if this was being worked on, (you answered this below)
> > or do I have to make heavily modified distro images? 
> I'm not suggesting that...
Good!

> And, hold on this - Jeff has made a big progress on this, diagnosing what had 
> been happening.
> 
> I'm not sure how well it works, but in the incrementals page there's the new 
> result. Give it a run and tell us the result, if it works it might go in 
> 2.6.15-bs and 2.6.16.
I've tried these patches:
* there was one suspicious offset on:
patching file arch/um/kernel/skas/process_kern.c
Hunk #1 succeeded at 126 (offset 3 lines).

* CC      arch/um/os-Linux/tls.o
arch/um/os-Linux/tls.c: In function `os_set_thread_area':
arch/um/os-Linux/tls.c:22: error: dereferencing pointer to incomplete
type
arch/um/os-Linux/tls.c: In function `os_get_thread_area':
arch/um/os-Linux/tls.c:36: error: dereferencing pointer to incomplete
type
make[1]: *** [arch/um/os-Linux/tls.o] Error 1
make: *** [arch/um/os-Linux] Error 2

with GCC 3.4.4 and GCC 3.3.4

* another /lib vs lib32 vs lib64 issue with pcap when compiling with
SUBARCH=i386 on this Gentoo system I had to add -r /usr/lib32/libpcap.a:
ld -r -dp -o arch/um/drivers/pcap.o arch/um/drivers/pcap_kern.o
arch/um/drivers/pcap_user.o  -m elf_i386
-r /usr/lib32/libpcap.a /usr/lib/gcc-lib/x86_64-pc-linux-gnu/3.3.4/../../../../lib/libpcap.a
Otherwise it moans about linking 64-bit libs with 32-bit... which is
fair enough I guess.

Antoine

On Friday 09 December 2005 12:39, Antoine Martin wrote:

> > > Is this glibc? Any ideas?
> >
> > Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread,
> > but it seems to do that.
>
> I wasn't even thinking about that! So true, why on earth would fsck
> require threading!?

fsck -A does all filesystems in fstab in one run, and the single case 
apparently defaults to one thread.

I didn't say it was a good design... :)

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.

On Sunday 11 December 2005 07:34, Rob Landley wrote:
> On Friday 09 December 2005 12:39, Antoine Martin wrote:
> > > > Is this glibc? Any ideas?
> > >
> > > Yes, I see that on Debian Sarge too. Don't ask me why fsck uses thread,
> > > but it seems to do that.
> >
> > I wasn't even thinking about that! So true, why on earth would fsck
> > require threading!?
>
> fsck -A does all filesystems in fstab in one run, and the single case
> apparently defaults to one thread.
>
> I didn't say it was a good design... :)

In fact, I expect a core Unix utility to be grown up in the good old Unix 
school, i.e. fork() and exec()!

We met The One* Unix coder thinking "I like new things!".

* Every reference to "The One Ring" is purely casual and fruit of paranoid 
imagination of the reader. (Yes, you don't know that, but anyhow...)
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it

On Sun, 11 Dec 2005, blaisorblade@... whispered secretively:
> On Sunday 11 December 2005 07:34, Rob Landley wrote:
>> On Friday 09 December 2005 12:39, Antoine Martin wrote:
>> > I wasn't even thinking about that! So true, why on earth would fsck
>> > require threading!?

It doesn't, at least not as of e2fsprogs-1.38.

>> fsck -A does all filesystems in fstab in one run, and the single case
>> apparently defaults to one thread.
>>
>> I didn't say it was a good design... :)

e2fsprogs-1.38/misc/fsck.c:check_all() repeatedly invokes fsck_device(),
which invokes execute(), which does a perfectly normal fork()/exec().
No threads here. Nor is there use of aio_*(), which might use threads
(well, POSIX allows it).

> In fact, I expect a core Unix utility to be grown up in the good old Unix 
> school, i.e. fork() and exec()!

It is. :)

> We met The One* Unix coder thinking "I like new things!".

Thankfully, Ted Ts'o is not a Nazgul (despite his close involvement in
the flashy new things of Kerberos and IPSec).

-- 
`I must caution that dipping fingers into molten lead
 presents several serious dangers.' --- Jearl Walker

> e2fsprogs-1.38/misc/fsck.c:check_all() repeatedly invokes fsck_device(),
> which invokes execute(), which does a perfectly normal fork()/exec().
> No threads here. Nor is there use of aio_*(), which might use threads
> (well, POSIX allows it).

Sorry, and what's the conclusion?

fork() calles set_thread_area()?

On Wednesday 14 December 2005 04:05, Sven K=F6hler wrote:
> > e2fsprogs-1.38/misc/fsck.c:check_all() repeatedly invokes fsck_device(),
> > which invokes execute(), which does a perfectly normal fork()/exec().
> > No threads here. Nor is there use of aio_*(), which might use threads
> > (well, POSIX allows it).
>
> Sorry, and what's the conclusion?
>
> fork() calles set_thread_area()?

Interesting... yep, it could.

Ok, picture down:

a) in NPTL, getpid() caches the result of the syscall in the TLS - so each =
new=20
process at startup (i.e. after exec!) calls set_thread_area(). But that's=20
normal.

b) I know that in clone()*, and I presume that in fork(), the pid cache mus=
t=20
be invalidated / updated. So while fork() maybe doesn't use set_thread_area=
=20
(and it could, seeing that no TLS setup has been done, and retrying) it wan=
ts=20
to puzzle with the TLS content.

* We know that as glibc once didn't and UML was the one user of clone() +=20
getpid(), and we discovered the hard way that glibc forgot that. Workaround=
ed=20
with a real getpid().

At bug report time we got an angry Ulrich saying "it's already fixed in lat=
est=20
version", luckily.
=2D-=20
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com