From: Bodo S. <bst...@fu...> - 2005-04-06 13:28:07
Attachments:
patches-2.6.11-prepare-s390.tar.gz
|
Here are the patches (tarball attached), that I've applied to UML 2.6.11 + incrementals, before adding s390-files. These patches are tested a bit on x86, but not on x86_64. s390 implementation is *not* included in tarball, this will be posted later, when thing are more stable. Please see patches and commented series-file for further information. Bodo |
From: Jeff D. <jd...@ad...> - 2005-04-06 18:51:12
|
On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > Here are the patches (tarball attached), that I've applied to > UML 2.6.11 + incrementals, before adding s390-files. > These patches are tested a bit on x86, but not on x86_64. I merged these, except for the restartnointr one because I don't have ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. Jeff |
From: Bodo S. <bst...@fu...> - 2005-04-06 18:57:55
|
Jeff Dike wrote: > On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > >>Here are the patches (tarball attached), that I've applied to >>UML 2.6.11 + incrementals, before adding s390-files. >>These patches are tested a bit on x86, but not on x86_64. > > > I merged these, except for the restartnointr one because I don't have > ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. > > Jeff That's bad. Do you have any suggestions how to solve this? Bodo |
From: Bodo S. <bst...@fu...> - 2005-04-06 18:59:27
|
Jeff Dike wrote: > On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > >>Here are the patches (tarball attached), that I've applied to >>UML 2.6.11 + incrementals, before adding s390-files. >>These patches are tested a bit on x86, but not on x86_64. > > > I merged these, except for the restartnointr one because I don't have > ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. > > Jeff And sorry, I forgot: Thank you for merging most of them! Bodo |
From: Bastian B. <ba...@wa...> - 2005-04-06 19:16:33
|
On Wed, Apr 06, 2005 at 04:35:58PM -0400, Jeff Dike wrote: > I merged these, except for the restartnointr one because I don't have > ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. 2.6.11 shows: | $ grep ERESTARTNOINTR -r . | ./linux/errno.h:#define ERESTARTNOINTR 513 And it is there since 2.5. Bastian --=20 No one wants war. -- Kirk, "Errand of Mercy", stardate 3201.7 |
From: Blaisorblade <bla...@ya...> - 2005-04-06 19:23:21
|
On Wednesday 06 April 2005 21:16, Bastian Blank wrote: > On Wed, Apr 06, 2005 at 04:35:58PM -0400, Jeff Dike wrote: > > I merged these, except for the restartnointr one because I don't have > > ERESTARTNOINTR in my Please note: > > /usr/include > > , inside a #ifdef KERNEL or not. > > 2.6.11 shows: > | $ grep ERESTARTNOINTR -r . > | ./linux/errno.h:#define ERESTARTNOINTR 513 > > And it is there since 2.5. Yes, what you say is true, but non significant. He's speaking about the host include (and there are good reasons to do so) and we cannot rely on 2.6 host kernel headers. Bye -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Bodo S. <bst...@fu...> - 2005-04-06 19:34:02
|
Bastian Blank wrote: > On Wed, Apr 06, 2005 at 04:35:58PM -0400, Jeff Dike wrote: > >>I merged these, except for the restartnointr one because I don't have >>ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. > > > 2.6.11 shows: > > | $ grep ERESTARTNOINTR -r . > | ./linux/errno.h:#define ERESTARTNOINTR 513 > > And it is there since 2.5. > > Bastian > TX for the info, but sorry, I guess you missunderstood. We were not talking about kernel's include/linux/errno.h, but about host's /usr/include/linux/errno.h, included in a user-obj in UML. Even kernel 2.4 defines ERESTARTNOINTR, but there seem to be some distros, that don't have it in /usr/include/linux/errno.h. And I really wanted to have host's ERESTARTNOINTR! Bodo |
From: Bastian B. <ba...@wa...> - 2005-04-06 20:03:06
|
On Wed, Apr 06, 2005 at 09:33:56PM +0200, Bodo Stroesser wrote: > Bastian Blank wrote: | Mail-Followup-To: use...@li...=20 Please fix your MUA. > TX for the info, but sorry, I guess you missunderstood. We were not talki= ng > about kernel's include/linux/errno.h, but about host's=20 > /usr/include/linux/errno.h, > included in a user-obj in UML. Even kernel 2.4 defines ERESTARTNOINTR, > but there seem to be some distros, that don't have it in=20 > /usr/include/linux/errno.h. > And I really wanted to have host's ERESTARTNOINTR! Since when does glibc support building itself against anything else than the Linux headers? But anyway, this errno is internal. So there exists no "host's ERESTARTNOINTR". Bastian --=20 Insufficient facts always invite danger. -- Spock, "Space Seed", stardate 3141.9 |
From: Blaisorblade <bla...@ya...> - 2005-04-06 20:05:21
|
On Wednesday 06 April 2005 22:02, Bastian Blank wrote: > On Wed, Apr 06, 2005 at 09:33:56PM +0200, Bodo Stroesser wrote: > > Bastian Blank wrote: > > > | Mail-Followup-To: use...@li... > > Please fix your MUA. > > > TX for the info, but sorry, I guess you missunderstood. We were not > > talking about kernel's include/linux/errno.h, but about host's > > /usr/include/linux/errno.h, > > included in a user-obj in UML. Even kernel 2.4 defines ERESTARTNOINTR, > > but there seem to be some distros, that don't have it in > > /usr/include/linux/errno.h. > > And I really wanted to have host's ERESTARTNOINTR! > > Since when does glibc support building itself against anything else than > the Linux headers? The outdated ones, for instance? (I.e. 2.4)? > But anyway, this errno is internal. So there exists > no "host's ERESTARTNOINTR". > > Bastian -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Bodo S. <bst...@fu...> - 2005-04-07 09:40:06
|
Bastian Blank wrote: > But anyway, this errno is internal. So there exists > no "host's ERESTARTNOINTR". As Blaisorblade pointed out, ptrace interface also is part of the ABI. User programs using ptrace *can* see ERESTARTNOINTR and all the other ERESTARTXXXX. So there exists "host's ERESTARTNOINTR", but sometimes it's missing in the headers. See, what strace-programmers do in syscall.c to define the possibly missing ERESTARTXXXX macros. We will have to do something similar in UML. Bodo |
From: Bodo S. <bst...@fu...> - 2005-04-07 15:58:06
Attachments:
check-restart-skipping.patch
|
Jeff Dike wrote: > On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > >>Here are the patches (tarball attached), that I've applied to >>UML 2.6.11 + incrementals, before adding s390-files. >>These patches are tested a bit on x86, but not on x86_64. > > > I merged these, except for the restartnointr one because I don't have > ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. > > Jeff Here is a revised patch, that solves the problem according to Blaisorblade's suggestion, to use kernel's definition of ERESTARTNOINTR, if host headers do not provide it. So UM_ERESTARTNOINTR is added to kern_constants.h and used depending on what host's errno.h gave us. Bodo |
From: Blaisorblade <bla...@ya...> - 2005-04-06 19:12:34
|
On Wednesday 06 April 2005 20:57, Bodo Stroesser wrote: > Jeff Dike wrote: > > On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > >>Here are the patches (tarball attached), that I've applied to > >>UML 2.6.11 + incrementals, before adding s390-files. > >>These patches are tested a bit on x86, but not on x86_64. > > > > I merged these, except for the restartnointr one because I don't have > > ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. > > > > Jeff > > That's bad. Do you have any suggestions how to solve this? Add it to the compilation-generated header files (the output of mk_constants, mk_thread and such), so we catch it from the definition given by ourselves and expose to the whole of UML. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Bodo S. <bst...@fu...> - 2005-04-06 19:26:49
|
Blaisorblade wrote: > On Wednesday 06 April 2005 20:57, Bodo Stroesser wrote: > >>Jeff Dike wrote: >> >>>On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: >>> >>>>Here are the patches (tarball attached), that I've applied to >>>>UML 2.6.11 + incrementals, before adding s390-files. >>>>These patches are tested a bit on x86, but not on x86_64. >>> >>>I merged these, except for the restartnointr one because I don't have >>>ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. >>> >>> Jeff >> >>That's bad. Do you have any suggestions how to solve this? > > Add it to the compilation-generated header files (the output of mk_constants, > mk_thread and such), so we catch it from the definition given by ourselves > and expose to the whole of UML. Yeah, tx, that would be possible. But the reason for using /usr/include/linux/errno.h was to have the host's definition, not the one from guest. Currently they are the same for 2.4 and 2.6, but worst case that might change in future versions. Only debugger could note this, as ERESTART_XXXX is unvisible to user programs. So, when implementing your idea, maybe I should add a further test, that our ERESTARTNOINTR *does* trigger a syscall restart on the host. Bodo |
From: Blaisorblade <bla...@ya...> - 2005-04-06 19:45:28
|
On Wednesday 06 April 2005 21:26, Bodo Stroesser wrote: > Blaisorblade wrote: > > On Wednesday 06 April 2005 20:57, Bodo Stroesser wrote: > >>Jeff Dike wrote: > >>>On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > >>>>Here are the patches (tarball attached), that I've applied to > >>>>UML 2.6.11 + incrementals, before adding s390-files. > >>>>These patches are tested a bit on x86, but not on x86_64. > >>> > >>>I merged these, except for the restartnointr one because I don't have > >>>ERESTARTNOINTR in my /usr/include, inside a #ifdef KERNEL or not. > >>> > >>> Jeff > >> > >>That's bad. Do you have any suggestions how to solve this? > > > > Add it to the compilation-generated header files (the output of > > mk_constants, mk_thread and such), so we catch it from the definition > > given by ourselves and expose to the whole of UML. > > Yeah, tx, that would be possible. > But the reason for using /usr/include/linux/errno.h was to have the host's > definition, not the one from guest. > Currently they are the same for 2.4 and 2.6, but worst case that might > change in future versions. Yes maybe in principle, however the errno values are part of the ABI. > Only debugger could note this, as ERESTART_XXXX > is unvisible to user programs. Well, the debugger is a user program, so even this one, which is almost internal, is part of the ABI. Actually, you might ask on LKML if you want. > So, when implementing your idea, maybe I should add a further test, that > our ERESTARTNOINTR *does* trigger a syscall restart on the host. Well, maybe adding a runtime test is worth, however let's start by fixing it compile-time as I say below. I don't know if adding a test now is "excessive planification and over-coding", but I feel like this (especially even for the above ABI reasons). A simpler idea: get our value as I said get the host value if defined (it's a macro so no problem) #ifdef HOST_ERESTARTNOINTR #define ERESTARTNOINTR HOST_ERESTARTNOINTR #else #define ERESTARTNOINTR KERN_ERESTARTNOINTR #endif Or, actually: #ifndef ERESTARTNOINTR #define ERESTARTNOINTR KERN_ERESTARTNOINTR #endif Btw, we currently solved this for PTRACE_SYSEMU, SETOPTIONS and many similar things by copying the value we provide. It wouldn't be bad, when applicable (not PTRACE_SYSEMU since mainline hasn't the SYSEMU patch), to use the above construct (i.e. taking the fallback value from the kernel instead of specifying it and copying it - they aren't supposed to change, but anyway). However, I'll have to merge the refactoring of the userspace programs sooner or later. Don't let this stop you, anyway. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Bodo S. <bst...@fu...> - 2005-04-07 09:54:20
|
Blaisorblade wrote: > On Wednesday 06 April 2005 21:26, Bodo Stroesser wrote: >>Currently they are the same for 2.4 and 2.6, but worst case that might >>change in future versions. > > Yes maybe in principle, however the errno values are part of the ABI. I agree. > >>Only debugger could note this, as ERESTART_XXXX >>is unvisible to user programs. > > Well, the debugger is a user program, so even this one, which is almost > internal, is part of the ABI. I agree. > #ifndef ERESTARTNOINTR > #define ERESTARTNOINTR KERN_ERESTARTNOINTR > #endif This is the solution, I like. Here is, what strace programmers do, to decode ERESTARTXXXXX results (from syscall.c): ... snip ... #include <errno.h> ... snip ... #ifdef LINUX #ifndef ERESTARTSYS #define ERESTARTSYS 512 #endif #ifndef ERESTARTNOINTR #define ERESTARTNOINTR 513 #endif #ifndef ERESTARTNOHAND #define ERESTARTNOHAND 514 /* restart if no handler.. */ #endif #ifndef ENOIOCTLCMD #define ENOIOCTLCMD 515 /* No ioctl command */ #endif #ifndef ERESTART_RESTARTBLOCK #define ERESTART_RESTARTBLOCK 516 /* restart by calling sys_restart_syscall */ #endif #ifndef NSIG #define NSIG 32 #endif #ifdef ARM #undef NSIG #define NSIG 32 #undef NR_SYSCALL_BASE #define NR_SYSCALL_BASE __NR_SYSCALL_BASE #endif #endif /* LINUX */ ... snip ... So, I'll modify my patch as you suggested. Bodo |
From: Blaisorblade <bla...@ya...> - 2005-04-08 01:16:54
|
On Wednesday 06 April 2005 15:27, Bodo Stroesser wrote: > Here are the patches (tarball attached), that I've applied to > UML 2.6.11 + incrementals, before adding s390-files. > These patches are tested a bit on x86, but not on x86_64. > > s390 implementation is *not* included in tarball, this will > be posted later, when thing are more stable. > > Please see patches and commented series-file for further > information. add-stub-vmas has already your notes in it, and I agree with the notes. delay-pure-arch: forgot EXPORT_SYMBOL on x86_64, also if every arch will provide them leave the EXPORT inside arch-independent ksyms.c. Also I don't like a function copied over subarchs. Move them to generic code with an ifdef ARCH_WANT_WHATEVER. Copied code *always* gets out of sync (and that's not only in UML, I found by accident a case where ext2 was updated and ext3 wasn't and didn't use i_size_read, leading to possible race conditions). Btw, that's why Andi Kleen delayed a lot the merge of Xen, refusing that it be a separate arch/xen folder. elf.h-symlink.patch: other includes also have a -generic.h file, like processor-generic.h, for common stuff. insert-ARCH_SIGHDLR_PARAM.patch: this coding is very awkward (not mentioned in CodingStyle because they didn't think to it) - I don't know the handle's use. However, some commenting will be needed, as this is *not* a widespread construct. You'll also tell me how you'll handle the different params if the code stays the same... I'd instead use a "do_alarm_handler" that takes everything as a param and an arch-specific caller passing the params, in general... but I don't really realize what will you do there. I fear a hidden param in ARCH_GET_SIGCONTEXT... ptrace-subarch: forgot the "#if 0" for x86_64, possibly preventing it from compiling. Actually, from looking to /usr/include/sys/user.h, it will compile but be bogus. Keep the XXX comment but change the "addr >>= 2" to "addr >>= 3" (because the various debug regs are each 8 and not 4 bytes long). I'll have to additionally check the manuals, however, this is why I ask to keep the comment. rename-COMMAND_LINE_SIZE.patch: it's against an outdated part of Jeff's tree (i.e. code movements). I patched it in a different way in mainline - I thinl that code-movements patches should be merged the day they are written, or one day they are written. I.e. they must be rewritten when merging them, to avoid moving outdated code. split-sys_call_table.patch: the current way of maintaining it has lead to too many problems, so I'm converting the code to a different way, i.e. including directly the original syscall table (with some defines, for instance #define sys_iopl sys_ni_syscall ). I didn't send them because I need that Jeff tests the x86_64 ones. In i386 case, I split away the table from entry.S. In the s390 case, they already did this for theirselves and for us. You'll have to check if any function has been renamed in a strange way. I'll maybe do the check myself... Also, the below is just bogus, -#ifdef CONFIG_NFSD +#if defined(CONFIG_NFSD) || defined(CONFIG_NFSD_MODULE) #define NFSSERVCTL sys_nfsservctl #else #define NFSSERVCTL sys_ni_syscall #endif because the correct code is this: #define NFSSERVCTL sys_nfsservctl kernel/sys_ni.c will alias sys_nfsservctl (and *MANY* other syscalls) to sys_ni_syscall if needed, through weak symbols. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Blaisorblade <bla...@ya...> - 2005-04-17 17:22:39
|
On Friday 08 April 2005 09:12, Bodo Stroesser wrote: > Blaisorblade wrote: > > On Wednesday 06 April 2005 15:27, Bodo Stroesser wrote: > >>s390 implementation is *not* included in tarball, this will > >>be posted later, when thing are more stable. > > Thank you for all your comments! > > I don't wan't to give to the wide world, before it is more stable. > But maybe this can answer some of your questions / remarks. I assume you already sent it to Jeff, so I'm not forwarding it. Now, some more little issues: * arch_fixup() should be implemented but cannot cause problems currently. UML currently does not use the .fixup mechanism (which requires using some asm() inserts - maybe that can be limited to gas pseudo-instruction without real code), but only the fault_catcher and fault_address one, which is an inferior design (some runtime cost). Last time I looked there were some difficulties about * ARCH_SIGHDLR_PARAM works like I feared - you'd probably need {} (or do {} while (0)) around the ARCH_GET_SIGCONTEXT because you declare a var at the beginning... and that function will likely break if not commented (because who patches the code won't go checking what actually happens). I also understand why you can't use the trick used elsewhere... I have no better solution than long comments. * About ptrace_faultinfo: Jeff said that S390 "has complex fault informations", while they seem not very complicate inside the S390 patch (I was asking about the generalization of the "is_write" fault info). I want to know this for the purpose of working on a mergeable version of PTRACE_FAULTINFO (which will probably be an extension of PTRACE_SIGINFO) Probably struct thread_struct has a more correct definition of those info... and arch/s390/mm/fault.c:do_exception even more. However, only some of that will be needed; we only need, in practise, the write/read (and maybe exec) type of the exception. Also, I've given a look and it wouldn't be difficult making PTRACE_SIGPENDING, just a bit long: update asm-generic/siginfo.h: struct siginfo : _sigfault (maybe depending on the arch), and all the callers. * for glibc-bug.c, you might as well use an "alias, weak" attribute - see the below from asm-i386/unistd.h: /* * "Conditional" syscalls * * What we want is __attribute__((weak,alias("sys_ni_syscall"))), * but it doesn't work on all toolchains, so we just do it by hand */ #ifndef cond_syscall #define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall"); #endif Note that the asm code only contains pseudo-op so it should work as-is on s390, right? Other issues follow, which refer to copied code going out-of-date wrt. my local tree (which I have snapshotted some time ago, after I started writing this mail). This is the problem with copying code - and you're starting experiencing it! * important changes for TLS support, clone(), and so on. * add a CHOOSE_MODE to arch_switch (since the current code is used only in TT mode) - I'm going to start calling it from SKAS mode and actually needing it for TLS support. Some changes to ptrace_user.c will also happen. * CONFIG_64_BIT must become CONFIG_64BIT, as I'm doing for the other UML subarchs (the '_' is bogus, by comparison with other 64-bit archs). Also I'll have to clean up the Makefiles (USER_OBJS got fixed finally - they got dependency tracking, and the common boilerplate code is now in arch/um/scripts/Makefile.rules - more stuff has shifted there since when you did the patch). And there's no need to readd the end "Emacs" comments, we are gradually getting rid of them. However, I'll take care myself of all these trivial QA (quality assurance) issues. -- Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Bodo S. <bst...@fu...> - 2005-04-18 10:55:19
|
Blaisorblade wrote: > On Friday 08 April 2005 09:12, Bodo Stroesser wrote: > >>Blaisorblade wrote: >> >>>On Wednesday 06 April 2005 15:27, Bodo Stroesser wrote: >>> >>>>s390 implementation is *not* included in tarball, this will >>>>be posted later, when thing are more stable. >> >>Thank you for all your comments! >> >>I don't wan't to give to the wide world, before it is more stable. >>But maybe this can answer some of your questions / remarks. > > I assume you already sent it to Jeff, so I'm not forwarding it. > > Now, some more little issues: > > * arch_fixup() should be implemented but cannot cause problems currently. UML > currently does not use the .fixup mechanism (which requires using some asm() > inserts - maybe that can be limited to gas pseudo-instruction without real > code), but only the fault_catcher and fault_address one, which is an inferior > design (some runtime cost). Last time I looked there were some difficulties > about Yes. I saw arch_fixup() being unused, so I decided not to implement it on s390, currently. > > * ARCH_SIGHDLR_PARAM works like I feared - you'd probably need {} (or do {} > while (0)) around the ARCH_GET_SIGCONTEXT because you declare a var at the > beginning... and that function will likely break if not commented (because who > patches the code won't go checking what actually happens). There is a reason for my decision, not to use "{}" here. s390 doesn't have fields for error-address and trap_no in its sigcontext. Because of alignment, there is an empty area in the sigcontext, that is big enough to hold an additional pointer. But there isn't enough place for error-address and trap_no. So I create a local struct faultinfo, write error-address and trap_no to it and add its address to the sigcontext. Now the sigcontext containing all info can be passed to the routine, which has to handle the signal. If the additional struct faultinfo would be declared inside of a "{}", I guess there would be no guarantee, that this structure still is valid outside the "{}". But it needs to be valid at the same level, from where sigcontext is passed to the called handler. The current solution should be used immediately after definition of local variables. Maybe, this should be commented, too. > > I also understand why you can't use the trick used elsewhere... I have no > better solution than long comments. > > * About ptrace_faultinfo: Jeff said that S390 "has complex fault > informations", while they seem not very complicate inside the S390 patch (I > was asking about the generalization of the "is_write" fault info). I want to > know this for the purpose of working on a mergeable version of > PTRACE_FAULTINFO (which will probably be an extension of PTRACE_SIGINFO) > > Probably struct thread_struct has a more correct definition of those info... > and arch/s390/mm/fault.c:do_exception even more. However, only some of that > will be needed; we only need, in practise, the write/read (and maybe exec) > type of the exception. s390 fault information is complex to handle only regarding sighandlers / sigcontext. Else it is even more simple than i386, as i386 has address, fault_type and trap, while s390 has address and trap_no only. What is the faultinfo used for in UML? First, it is used to handle pagefaults. Second, it is used to give error-information to sighandlers of UML-user-programs. So, PTRACE_FAULTINFO should give the caller *all* information, that a sighandler would get. All this info should be stored in thread_struct. Then, UML internally uses arch-specific macros to extract "is_write" and to see, if segment violation might be fixable. PTRACE_FAULTINFO on i386 unfortunately doesn't give UML all info. This should be fixed in a mainline solution, as the current implementation can't distinguish between a page-fault and a segment-fault. So a user-program in SKAS3 might loop on a segment-fault instead of being interrupted by SIGSEGV. (See use of PTRACE_FULL_FAULTINFO in arch/um/kernel/skas/process.c) > > Also, I've given a look and it wouldn't be difficult making PTRACE_SIGPENDING, > just a bit long: update asm-generic/siginfo.h: struct siginfo : _sigfault > (maybe depending on the arch), and all the callers. PTRACE_SIGPENDING currently is unused. I don't know, if there will be need for it in future. IMHO, this should be removed. > > * for glibc-bug.c, you might as well use an "alias, weak" attribute - see the > below from asm-i386/unistd.h: > > /* > * "Conditional" syscalls > * > * What we want is __attribute__((weak,alias("sys_ni_syscall"))), > * but it doesn't work on all toolchains, so we just do it by hand > */ > #ifndef cond_syscall > #define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x ",sys_ni_syscall"); > #endif > > Note that the asm code only contains pseudo-op so it should work as-is on > s390, right? I've experimented with __attribute__((weak)) in C-code and had no success. IIRC, the "weak" simply was ignored. So I decided to go forward and make s390 run, before clearing those "minor" problems. > > Other issues follow, which refer to copied code going out-of-date wrt. my > local tree (which I have snapshotted some time ago, after I started writing > this mail). This is the problem with copying code - and you're starting > experiencing it! > > * important changes for TLS support, clone(), and so on. I've seen, that I'll have to implement the small support of TLS in s390. That's on my todo > > * add a CHOOSE_MODE to arch_switch (since the current code is used only in TT > mode) - I'm going to start calling it from SKAS mode and actually needing it > for TLS support. Some changes to ptrace_user.c will also happen. Great. I also want to have arch_switch for skas, as I would like to have full debugging support in skas. > > * CONFIG_64_BIT must become CONFIG_64BIT, as I'm doing for the other UML > subarchs (the '_' is bogus, by comparison with other 64-bit archs). Also I'll > have to clean up the Makefiles (USER_OBJS got fixed finally - they got > dependency tracking, and the common boilerplate code is now in > arch/um/scripts/Makefile.rules - more stuff has shifted there since when you > did the patch). And there's no need to readd the end "Emacs" comments, we are > gradually getting rid of them. However, I'll take care myself of all these > trivial QA (quality assurance) issues. Your help is very welcome. I also have to scan all the new file to add some correct Copyright comments. This is a further reason for not publishing s390 yet. Bodo |
From: Blaisorblade <bla...@ya...> - 2005-04-19 19:41:52
|
On Monday 18 April 2005 12:54, Bodo Stroesser wrote: > Blaisorblade wrote: > > On Friday 08 April 2005 09:12, Bodo Stroesser wrote: > > * ARCH_SIGHDLR_PARAM works like I feared - you'd probably need {} (or do > > {} while (0)) around the ARCH_GET_SIGCONTEXT because you declare a var = at > > the beginning... and that function will likely break if not commented > > (because who patches the code won't go checking what actually happens). > There is a reason for my decision, not to use "{}" here. > s390 doesn't have fields for error-address and trap_no in its sigcontext. > Because of alignment, there is an empty area in the sigcontext, that is b= ig > enough to hold an additional pointer. But there isn't enough place for > error-address and trap_no. So I create a local struct faultinfo, write > error-address and trap_no to it and add its address to the sigcontext. Now > the sigcontext containing all info can be passed to the routine, which has > to handle the signal. > > If the additional struct faultinfo would be declared inside of a "{}", I > guess there would be no guarantee, that this structure still is valid > outside the "{}". There is the guarantee that the identifier is NOT valid, and so the datas m= ay=20 be invalidated... > But it needs to be valid at the same level, from where=20 > sigcontext is passed to the called handler. Ok... > The current solution should be used immediately after definition of local > variables. Maybe, this should be commented, too. Yes, it's the minimum needed... as said we *will* get that broken by somebo= dy=20 otherwise. > > I also understand why you can't use the trick used elsewhere... I have = no > > better solution than long comments. > s390 fault information is complex to handle only regarding sighandlers / > sigcontext. Else it is even more simple than i386, as i386 has address, > fault_type and trap, while s390 has address and trap_no only. > What is the faultinfo used for in UML? First, it is used to handle > pagefaults. Second, it is used to give error-information to sighandlers of > UML-user-programs. So, PTRACE_FAULTINFO should give the caller *all* > information, that a sighandler would get. All this info should be stored = in > thread_struct. > Then, UML internally uses arch-specific macros to extract "is_write" and = to > see, if segment violation might be fixable. > PTRACE_FAULTINFO on i386 unfortunately doesn't give UML all info. This > should be fixed in a mainline solution, as the current implementation can= 't > distinguish between a page-fault and a segment-fault. So a user-program in > SKAS3 might loop on a segment-fault instead of being interrupted by > SIGSEGV. > (See use of PTRACE_FULL_FAULTINFO in=20 > arch/um/kernel/skas/process.c) > > > Also, I've given a look and it wouldn't be difficult making > > PTRACE_SIGPENDING, just a bit long: update asm-generic/siginfo.h: struct > > siginfo : _sigfault (maybe depending on the arch), and all the callers. > > PTRACE_SIGPENDING currently is unused. I don't know, if there will be need > for it in future. IMHO, this should be removed. Agreed, even Jeff confirmed it should be removed... but in the above lines = I=20 was really referring to PTRACE_SIGINFO. > > * for glibc-bug.c, you might as well use an "alias, weak" attribute - s= ee > > the below from asm-i386/unistd.h: > > > > /* > > * "Conditional" syscalls > > * > > * What we want is __attribute__((weak,alias("sys_ni_syscall"))), > > * but it doesn't work on all toolchains, so we just do it by hand > > */ > > #ifndef cond_syscall > > #define cond_syscall(x) asm(".weak\t" #x "\n\t.set\t" #x > > ",sys_ni_syscall"); #endif > > > > Note that the asm code only contains pseudo-op so it should work as-is = on > > s390, right? > > I've experimented with __attribute__((weak)) in C-code and had no success. > IIRC, the "weak" simply was ignored. =46rom my experience, it's possible that you used a declaration instead of = a=20 definition: This: int proc() __attribute__((weak)); does not work when it's actually called, but it does not give "unresolved=20 symbol" when you take its address; while this: int proc() __attribute__((weak)) { } works in any case and does not give "already defined symbol" errors. > So I decided to go forward and make=20 > s390 run, before clearing those "minor" problems. > > * important changes for TLS support, clone(), and so on. > > I've seen, that I'll have to implement the small support of TLS in s390. > That's on my todo > > * add a CHOOSE_MODE to arch_switch (since the current code is used only > > in TT mode) - I'm going to start calling it from SKAS mode and actually > > needing it for TLS support. Some changes to ptrace_user.c will also > > happen. > Great. I also want to have arch_switch for skas, as I would like to have > full debugging support in skas. > > * CONFIG_64_BIT must become CONFIG_64BIT, as I'm doing for the other UML > > subarchs (the '_' is bogus, by comparison with other 64-bit archs). Also > > I'll have to clean up the Makefiles (USER_OBJS got fixed finally - they > > got dependency tracking, and the common boilerplate code is now in > > arch/um/scripts/Makefile.rules - more stuff has shifted there since when > > you did the patch). And there's no need to readd the end "Emacs" > > comments, we are gradually getting rid of them. However, I'll take care > > myself of all these trivial QA (quality assurance) issues. > Your help is very welcome. I also have to scan all the new file to add so= me > correct Copyright comments. This is a further reason for not publishing > s390 yet. > Bodo =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Bodo S. <bst...@fu...> - 2005-04-26 11:31:28
|
Blaisorblade wrote: > Other issues follow, which refer to copied code going out-of-date wrt. my > local tree (which I have snapshotted some time ago, after I started writing > this mail). This is the problem with copying code - and you're starting > experiencing it! > > * important changes for TLS support, clone(), and so on. I'm going to implement TLS support in UML/s390. I could do this in arch/um/sys-s390/syscalls.c/sys_clone() without any need to change generic UML code. But I guess, for i386 there will be a need for arch-specific code in copy_thread(), maybe something like arch_copy_thread(). If so, s390 TLS support should be inserted using in the same manner. Do you already have some code for this, that I could base on? Bodo |
From: Blaisorblade <bla...@ya...> - 2005-04-28 20:49:32
|
On Tuesday 26 April 2005 13:31, Bodo Stroesser wrote: > Blaisorblade wrote: > > Other issues follow, which refer to copied code going out-of-date wrt. my > > local tree (which I have snapshotted some time ago, after I started > > writing this mail). This is the problem with copying code - and you're > > starting experiencing it! > > > > * important changes for TLS support, clone(), and so on. > > I'm going to implement TLS support in UML/s390. I could do this in > arch/um/sys-s390/syscalls.c/sys_clone() without any need to change generic > UML code. > But I guess, for i386 there will be a need for arch-specific code in > copy_thread(), maybe something like arch_copy_thread(). > If so, s390 TLS support should be inserted using in the same manner. > Do you already have some code for this, that I could base on? On my web-site I've uploaded my personal devel-tree snapshot against -rc3. Currently I've had to add a "clear_flushed_tls()" to copy_thread(), which probably should be wrapped in a arch_copy_thread() (with a macro/inline in some header). As a side note: the TLS code currently does not work yet, so don't rely on it. There are also some issues to (later?) consider, which are indicated in the patch itself; and there will be something to add to the host SKAS patch, because the current implementation would be a bit too slow probably. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Jeff D. <jd...@ad...> - 2005-04-22 01:38:19
|
On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > Here are the patches (tarball attached), that I've applied to > UML 2.6.11 + incrementals, before adding s390-files. > These patches are tested a bit on x86, but not on x86_64. The COMMAND_LINE_SIZE patch was required because this was conflicting with the userspace s390 COMMAND_LINE_SIZE? I think this is true because in the kernel, asm-s390/setup.h doesn't get pulled in. This stems from the fact that my tree had add_arg in os-Linux/util.c, which seems wrong. Blaisorblade had it moved to um_arch.c, which is right, and where it is in my tree now. So, I think UML_COMMAND_LINE_SIZE is not needed, and I've removed it. Jeff |
From: Blaisorblade <bla...@ya...> - 2005-04-24 14:50:58
|
On Friday 22 April 2005 03:32, Jeff Dike wrote: > On Wed, Apr 06, 2005 at 03:27:50PM +0200, Bodo Stroesser wrote: > > Here are the patches (tarball attached), that I've applied to > > UML 2.6.11 + incrementals, before adding s390-files. > > These patches are tested a bit on x86, but not on x86_64. > > The COMMAND_LINE_SIZE patch was required because this was conflicting with > the userspace s390 COMMAND_LINE_SIZE? I think this is true because in the > kernel, asm-s390/setup.h doesn't get pulled in. > > This stems from the fact that my tree had add_arg in os-Linux/util.c, which > seems wrong. Blaisorblade had it moved to um_arch.c, which is right, and > where it is in my tree now. So, I think UML_COMMAND_LINE_SIZE is not > needed, and I've removed it. The patch moving add_arg() was *before* the os-* work, so you might move (if needed, which I don't know) it again to os-Linux/util.c if you want (which didn't exist at that time). It came from arch/um/kernel/user_util.c, in fact. Btw, many of the code movement things are just cut'n'paste things, so for them there is no reason to delay them. Now we are going to merge them for 2.6.13-rc1 (for .12 it's too late), but every other delay increases the possibility that we fix somehow the code we are moving and forget to do the same on the moved code. Finally, about the syscall table patches for s390: I'm going to merge into -mm the syscall table patches you can find in the last -devel snapshot I put on my page (the uploaded ones maybe are out-of-date, but I'll cc you on patches). They entirely remove the UML syscall table to replace it with the $(SUBARCH) one (there is some hand-work to do for each subarch but it's much less than before). While doing this I also fixed various little bugs about this subject. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |
From: Jeff D. <jd...@ad...> - 2005-04-24 16:55:57
|
On Sun, Apr 24, 2005 at 04:44:37PM +0200, Blaisorblade wrote: > The patch moving add_arg() was *before* the os-* work, so you might move (if > needed, which I don't know) it again to os-Linux/util.c if you want (which > didn't exist at that time). It came from arch/um/kernel/user_util.c, in fact. Yeah, I was thinking that maybe it belonged under os, but I decided it really should stay in kernel. That's the kernel's version of the command line, not what was passed in from the host. > Btw, many of the code movement things are just cut'n'paste things, so for them > there is no reason to delay them. Now we are going to merge them for > 2.6.13-rc1 (for .12 it's too late), but every other delay increases the > possibility that we fix somehow the code we are moving and forget to do the > same on the moved code. Yeah, that's a concern. I'm holding onto the code movement because I want to look at the os interface that resulted from it, and see if it can be cleaned up. > Finally, about the syscall table patches for s390: I'm going to merge into -mm > the syscall table patches you can find in the last -devel snapshot I put on > my page (the uploaded ones maybe are out-of-date, but I'll cc you on > patches). What patch is this? All I see is a patch which makes some small fixes to the sys_call_table. > They entirely remove the UML syscall table to replace it with the $(SUBARCH) > one (there is some hand-work to do for each subarch but it's much less than > before). While doing this I also fixed various little bugs about this > subject. Don't send that anywhere until I've seen it. Your description of it makes me nervous. Jeff |
From: Blaisorblade <bla...@ya...> - 2005-04-24 18:46:58
|
On Sunday 24 April 2005 18:51, Jeff Dike wrote: > On Sun, Apr 24, 2005 at 04:44:37PM +0200, Blaisorblade wrote: > > Btw, many of the code movement things are just cut'n'paste things, so for > > them there is no reason to delay them. Now we are going to merge them for > > 2.6.13-rc1 (for .12 it's too late), but every other delay increases the > > possibility that we fix somehow the code we are moving and forget to do > > the same on the moved code. > Yeah, that's a concern. I'm holding onto the code movement because I want > to look at the os interface that resulted from it, and see if it can be > cleaned up. Happy for that. > > Finally, about the syscall table patches for s390: I'm going to merge > > into -mm the syscall table patches you can find in the last -devel > > snapshot I put on my page (the uploaded ones maybe are out-of-date, but > > I'll cc you on patches). > What patch is this? All I see is a patch which makes some small fixes to > the sys_call_table. No, I don't mean -bs, I mean the DEVEL snapshot. It's under patches/devel-guest/, and other will follow (when I have broad-band). However the updated patches are flying to you (plural, since they also relate with s390 port). > > They entirely remove the UML syscall table to replace it with the > > $(SUBARCH) one (there is some hand-work to do for each subarch but it's > > much less than before). While doing this I also fixed various little bugs > > about this subject. > > Don't send that anywhere until I've seen it. Your description of it makes > me nervous. I'm sending it for -mm only, and it's marked as such. Also it won't silently slip since it acts a bit on i386. -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade |