Re: [uml-devel] Clearing kmalloc_ok during shutdown is broken - malloc will clear our data.
I'm not understanding why glibc would break the registers at will. From setjmp: /* NOTE: The machine-dependent definitions of `__sigsetjmp' assume that a `jmp_buf' begins with a `__jmp_buf' and that `__mask_was_saved' follows it. Do not move these members or add others before it. */ Seems to indicate to me that this isn't gonna change, and I'm using the bits/setjmp.h defines, so if they do change, the code should just follow along with the change. Am I missing something? Allan Blaisorblade wrote: On Sunday 02 October 2005 03:08, Jeff Dike wrote: On Thu, Sep 29, 2005 at 04:14:02PM +0200, Blaisorblade wrote: I now even found (by chance) the original mail from Allan Graves - and the changes in arch/um/include/sysdep-x86_64/ptrace.h weren't in his patch and are unrelated. Plus, I think they're also bogus (those registers exist), but I may be wrong, The patch uses UPT_REG apparently for the first time. Those registers exist, but there are no defines for them in the x86_64 ptrace.h. UPT_REG is never called with any of those as its argument, so it's easy to just remove those cases. Ah, ok. The only problem I see is that we need to test it on a wide glibc range - you're using an internal header detail, so glibc will break it at will. Yeah, it's bad. The other way to do it is to explictly save the registers in the thread struct, which is effectively the reimplementing setjmp option which you mentioned. At least, if we save them separately from the jmpbuf_t, we can use them for sysrq t, without reimplementing setjmp() and longjmp(). Not nice, wastes 24 bytes, but would work. I have the doubt that the location of those registers is part of the ABI, (pending: find an example where I can be statically linked to glibc and dynamically linked to a library dynamically linked to glibc, and must pass jmpbuf_t between the two implementations) even if the C names aren't part of the API, so we could copy the structure. Probably, however, it's just better to test on, say, a Slackware 8.1, and hope for the best and go doing a fix when things change. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] Clearing kmalloc_ok during shutdown is broken - malloc will clear our data.
On Monday 03 October 2005 15:40, Allan Graves wrote: > I'm not understanding why glibc would break the registers at will. > From setjmp: > /* NOTE: The machine-dependent definitions of `__sigsetjmp' >assume that a `jmp_buf' begins with a `__jmp_buf' and that >`__mask_was_saved' follows it. Do not move these members >or add others before it. */ > Seems to indicate to me that this isn't gonna change, the comments above are mostly relative to the definitions of __sigsetjmp, i.e. to glibc internal code. Also, it's related to the layout of the structure, while our main problem is not the structure layout. > and I'm using the > bits/setjmp.h defines, so if they do change, the code should just follow > along with the change. Am I missing something? I didn't even see those constants - I stopped earlier, at __jmp_buf_tag. Given that it feels like a Glibc private thing, I worried. Since those constants are explicitly exported, I guess that's for userspace programs as well, so Glibc provides that API as a public one. -- 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 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] Using __initcall from um/drivers/chan_kern.c / fun with keyboard
On Monday 03 October 2005 08:02, Nelson Castillo wrote: > Hi, I'm sending a patch that allows me to query the > number of keys pressed by the user (I'll copy [4]). > -- > # cat /proc/keystrokes > 29 > -- > I read [1] and skimmed over [2] and I think I'm using > the __init and __initcall macros well, but I get this > error when I try to use them: > > CC arch/um/drivers/chan_kern.o > arch/um/drivers/chan_kern.c:111: error: `proc_kst_init' undeclared > here (not in a function) > arch/um/drivers/chan_kern.c:98: warning: `proc_kts_init' defined but not If you pasted the correct error message and the correct code, they both say "kst" on one line and "kts" on the other. You have a trivial typo. > What should I do/try? > Can I use these macros in um/drivers/chan_kern.c? Yes, take the right include and you can (use , not arch/um/include/init.h) > Blaisorblade told me to it in serio[3], but I don't know > where I should put the hooks. I think I can also use > drivers/char/keyboard.c If it's arch-independent, you maybe can. But you'd better ask this on LKML, probably. -- 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 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] a question about sigsetjmp() in copy_from/to_user()
On Sunday 02 October 2005 20:31, Jeff Dike wrote: > On Sun, Oct 02, 2005 at 12:23:14PM +0200, Blaisorblade wrote: > > Sorry, any reference will fault, unless it is done on a allocated present > > page, which the UML kernel freed but the host didn't. And remember, btw, > > you've planned to make this impossible... > You are not making any sense t me here. /dev/anon - when the UML kernel frees a page, we ask the host to free it too. > > Sorry, Jeff, which page are you going to evict? It can be a dirty page. > > Unless you mean that since that page is still accounted in the FS, Linux > > will leave a RAM page free to allow it to be re-read, while still > > swapping the page. > Swapped pages are accounted in the FS all the time and there's obviously > no dedicated page left free for them when they are next pulled in. All > disk-based filesystems account pages that are on disk and not in memory. > tmpfs is no different, except that its disk is the swap partition. Exactly what I knew... However, I was in error... I just saw that filling the disk, or tmpfs, is rather different than going OOM. OOM causes SIGKILL, while SIGBUS (as you correctly said) comes from full disk/partition, or filled disk quota. I only checked tmpfs, but that gives at least a feeling. -- 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 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] Re: UML/2.6.14-rc3 doesn't work fixes
On Sunday 02 October 2005 20:37, Al Viro wrote: > On Sun, Oct 02, 2005 at 08:01:21PM +0200, Blaisorblade wrote: > > On Sunday 02 October 2005 17:51, Jeff Dike wrote: > > Al, is that ok for you if we follow this original plan? > > > > In this case, I'll post the dropping patch and re-send the Kbuild fix of > > my last batch (conflicted with Al's patch, but now it's needed again). > Up to Jeff; IMO it's easier to restore the variant past his review (with > incremental replacing that DEFINE_LONGS), but maintainer gets to decide; > that was the reason for Cc when patch got sent to Linus, after all... My only worry is that some other bug may have slipped through - it's not the case that we are perfect, nor we have a real test-suite to catch this sort of thing (especially, there are sections of FPU handling which are buggy anyway - there is a really big patch which copies whole sections of i386 low level messing up with FPU, which I requested Jeff to hold some time ago). -- 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 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
[uml-devel] Re: UML/2.6.14-rc3 doesn't work fixes
On Sunday 02 October 2005 22:54, Al Viro wrote: > BTW, speaking of Kbuild cleanups (and that one is definitely 2.6.15 > fodder): patch below > * kills messing with lib vs. core for uml-amd64 (we don't need that > anymore) I'm even curious why we needed that in first place. > * kills symlinks in arch/um/sys-*/ > * kills foo.c-dir - we simply give HOST_OBJS= under arch/$(SUBARCH)> and that's it (no SYMLINKS either) > Price: use of make feature I really, really hate - $(eval ...). I looked at make Changelog, time ago, and this feature was added in make 3.80, so you'd need to update Documentation/Changes. Make 3.80 was released in 2002-10-03, so I hope it's not a problem (should check on Debian Woody though, maybe). > I'm using > it to generate and process > > bar-y := ../../$(SUBARCH)/foo/bar.o > ... > for all HOST_OBJS elements. If there are better suggestions, I'd be glad > to hear them... The first thing is that HOST_OBJS is totally confusing... SUBARCH_OBJS or something else is better. The second is that, even if x86_64 uses things such as (from arch/x86_64/mm/Makefile): obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o hugetlbpage-y = ../../i386/mm/hugetlbpage.o (because hugetlbpage.o is conditional) we could as well do subarch-y := ../../$(SUBARCH)/name (even with foreach) for most things (see arch/x86_64/oprofile/Makefile), and for highmem and module I'd just do that by hand: highmem-y := $(SUBARCH_DIR)/mm/highmem.o module-y := $(SUBARCH_DIR)/kernel/module.o with SUBARCH_DIR defined in arch/um/Makefile. -- 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 --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] Using __initcall from um/drivers/chan_kern.c / fun with keyboard
On 10/3/05, Blaisorblade <[EMAIL PROTECTED]> wrote: >You have a trivial typo. Yup :( Thanks. -- Homepage : http://geocities.com/arhuaco The first principle is that you must not fool yourself and you are the easiest person to fool. -- Richard Feynman. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
Re: [uml-devel] a question about sigsetjmp() in copy_from/to_user()
On Mon, Oct 03, 2005 at 08:35:54PM +0200, Blaisorblade wrote: > /dev/anon - when the UML kernel frees a page, we ask the host to free it too. Yeah, /dev/anon is a completely different story, but I thought we were talking about normal tmpfs. Jeff --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
[uml-devel] Re: UML/2.6.14-rc3 doesn't work fixes
On Mon, Oct 03, 2005 at 08:30:23PM +0200, Blaisorblade wrote: > The second is that, even if x86_64 uses things such as (from > arch/x86_64/mm/Makefile): > > obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o > hugetlbpage-y = ../../i386/mm/hugetlbpage.o > (because hugetlbpage.o is conditional) > > we could as well do > > subarch-y := ../../$(SUBARCH)/name > (even with foreach) Err... Kbuild won't know what to do with your subarch-y. The way it works is simple - we are saying that e.g. bitops.o is a multi-part object with only one part, namely ../../i386/lib/bitops.o. Said part is built by the normal Kbuild logics and then we get (dummy) linking, creating bitops.o. > for most things (see arch/x86_64/oprofile/Makefile), and for highmem and > module I'd just do that by hand: > > highmem-y := $(SUBARCH_DIR)/mm/highmem.o > module-y := $(SUBARCH_DIR)/kernel/module.o > > with SUBARCH_DIR defined in arch/um/Makefile. Hrm... That just might be usable, _if_ we never run into modular suckers; in that case we can do the following: ifneq ($(subarch-objs-y),) obj-y += subarch.o subarch-y = $(addprefix ../../$(SUBARCH),$(subarch-objs-y)) endif in arch/um/scripts/Makefile.rules with subarch-y = . subarch-$(CONFIG_MODULE) += kernel/module.o etc. in arch/um/sys-.../Makefile The thing is, if we _ever_ need a potentially modular object pulled from the underlying architecture that trick will break. So far we do not and since $(eval...) *is* a vile mess straight from the GNU intestine... --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ User-mode-linux-devel mailing list User-mode-linux-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
