diff options
Diffstat (limited to 'open_issues')
54 files changed, 1731 insertions, 5 deletions
diff --git a/open_issues/automatic_backtraces_when_assertions_hit.mdwn b/open_issues/automatic_backtraces_when_assertions_hit.mdwn new file mode 100644 index 00000000..1cfacaf5 --- /dev/null +++ b/open_issues/automatic_backtraces_when_assertions_hit.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <azeem> tschwinge: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. + <youpi> it'd be great if we could have backtraces in such case + <youpi> at least just the function names + <youpi> and in this case (static), just addresses would be enough diff --git a/open_issues/automatically_checking_port_deallocation.mdwn b/open_issues/automatically_checking_port_deallocation.mdwn new file mode 100644 index 00000000..fb8cfd01 --- /dev/null +++ b/open_issues/automatically_checking_port_deallocation.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <youpi> we really need something that is able to automatically check port deallocation + <youpi> at least for the trivial cases, for which we do have bugs I'm currently fixing... + <pochu> test suite? :) + <pochu> won't magically find them though, so not what you've asked for... + <youpi> test suites can trigger some of the bugs yes + <youpi> which is already a good thing + <youpi> of course the coverage can't be perfect + <youpi> one of the bugs I fixed happened only for setuid binaries for instance diff --git a/open_issues/bash_interrupted_system_call.mdwn b/open_issues/bash_interrupted_system_call.mdwn new file mode 100644 index 00000000..9feab6ff --- /dev/null +++ b/open_issues/bash_interrupted_system_call.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date. + + <virtuoso015> i seem to be getting this message from the shell "-bash: /dev/fd/62: Interrupted system call" + <virtuoso015> is it significant ? + <youpi> I've seen this issue already yes + <youpi> it's not + <youpi> it's bash not handling EINTR properly + <antrik> youpi: so this is actually a bug in bash, not Hurd generating a bogus error? + <youpi> well, it's Hurd generating an error which bash doesn't expect to see diff --git a/open_issues/chroot_difference_from_linux.mdwn b/open_issues/chroot_difference_from_linux.mdwn new file mode 100644 index 00000000..f2009bd8 --- /dev/null +++ b/open_issues/chroot_difference_from_linux.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +\#hurd, freenode, 2010 + + <cfhammar> weird, even fd = open("/"), chroot("/tmp/chroot"), openat(fd, "/tmp/chroot/..) opens /tmp/chroot in linux + <pochu> cfhammar: isn't that expected? + <cfhammar> pochu: well, i didn't expect it :-) + <cfhammar> pochu: in hurd, /tmp gets opened, which i think is more natural + <pochu> cfhammar: oh right, didn't notice the ".." :-) diff --git a/open_issues/debootstrap.mdwn b/open_issues/debootstrap.mdwn new file mode 100644 index 00000000..8e6c4900 --- /dev/null +++ b/open_issues/debootstrap.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +\#hurd, freenode, 2010 + + <azeem_> you know, you would really help the Hurd if you tried debootstrap instead + <tschwinge> Oh? Does that have everying in place by now? + <azeem_> applying the patch in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498731#25 + <azeem_> they are waiting for feedbacl + <azeem_> feedback* + +\#hurd, freenode, June (?) 2010 + + <azeem_> jd823592: if you want to use debootstrap, you should apply a patch + <azeem_> and test + <azeem_> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=25;filename=debootstrap_hurd.patch;att=1;bug=498731 + <azeem_> we desperately need somebody to test the patch diff --git a/open_issues/dir-lookup_authority.mdwn b/open_issues/dir-lookup_authority.mdwn new file mode 100644 index 00000000..64866eb5 --- /dev/null +++ b/open_issues/dir-lookup_authority.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> I have discovered a bug in the dir-lookup protocol though + <cfhammar> Currently, I'm investigating the bug a bit further + <cfhammar> when doing dir-lookups with several path components, the look-up is done with the authority of the user who opened the directory, as opposed to the user doing the lookup + <cfhammar> e.g, consider foo/bar/baz, where bar can only be used by its owner and foo and baz are world readable + <cfhammar> if foo is opened, then transferred to another user, he can open baz, which he shouldn't be able to + <cfhammar> this is possible where foo/bar/baz is within a single translator, and the lookup is done in a single dir-lookup + <antrik> cfhammar: I'm not sure this is a bug + <cfhammar> I have a test case that triggers the bug, and another that doesn't which currently confuses me + <antrik> cfhammar: it's probably not very usual to pass around open directory ports; but if somebody does it, it's probably actually desired that it keeps the authority + <antrik> it's kinda consistent with passing normal FDs + <cfhammar> antrik: it should only allow accesses to entries not sub-entries + <cfhammar> antrik: it isn't allowed in Linux atleast, and I'm guessing it's mandated by posix + <cfhammar> also note that a more common scenario is a process that opens a directory and then drops authority + <cfhammar> probably more common, that is + <antrik> cfhammar: I'm not really familiar with directory access functions... I wasn't even aware that it's possible to pass around directory FDs + <antrik> but if it is, it would indeed be good to know what POSIX says about this + <antrik> cfhammar: I don't see how this is related?... + <cfhammar> antrik: after the process has dropped authority it can still make lookups in directories that it should no longer be able to + <antrik> cfhammar: interesting point... + <antrik> cfhammar: do you think this is fixable? + <cfhammar> antrik: Not without (defacto) changing the interface + <cfhammar> e.g only looking up a singe path component at a time + <cfhammar> or doing the auth check lazily on io_reauthenticate + <antrik> cfhammar: yeah, obviously it's not possible without an API change. I just wonder whether it's possible without throwing the current auth/lookup mechanism overboard alltogether... + <cfhammar> antrik: both my solutions are only minor changes to the API, but fairly major in the sense that we need to change all callers :-( + <cfhammar> diskfs_S_dir_lookup is a very large function, for example + <antrik> cfhammar: OK + <antrik> cfhammar: I wonder whether there is a possible transition path without breaking all existing installations... + <cfhammar> we could provide a new RPC while supporting the old one + <cfhammar> note that changing fs.defs only affects glibc and the Hurd, normal apps should be fine + <antrik> cfhammar: have you posted your findings to the ML yet? + <cfhammar> No, I'm still investigating why my second test-case doesn't trigger the bug + <cfhammar> Intrestingly it's the one using all POSIX functions... + <cfhammar> Perhaps its a bug that maskes the lookup bug ;-) + <antrik> I guess there is some quirk which you do not fully understand yet :-) + <cfhammar> Oh, there's always a new quirk to find in the Hurd :-) + <cfhammar> antrik: seems that dir_lookup isn't buggy after all + <cfhammar> antrik: as all FDs are reauthenticated on setauth + <antrik> ah + <cfhammar> antrik: and (presumably) ports are unauthenticated and reauthenticated when transfered + <antrik> yeah, that's the idea behind the auth protocol... + <antrik> users obtain specific capabilities by authenticating generic ports against their own ID + <cfhammar> I didn't really have a coherent view on how open flags are handled on reauth + <cfhammar> it seems open flags always win, so that a O_READ port that is unauthed is still readable + <antrik> not sure what you mean + <cfhammar> if I open a file to read it, then reauth it with a user that isn't permitted to read it, I can still read from it + <cfhammar> (as it should be) + <cfhammar> by contrast permission to do lookups in a directory is determined by who authed it + <cfhammar> so I won't be able to do lookups after a reauth, if it's not permitted by the file bits + <youpi> Mmm, openat should however be able to + <youpi> since you've first opened the directory with the auth + <cfhammar> it isn't since open FDs are reauthed on setauth + <cfhammar> not sure whether it should though, Linux behaves the same way atleast + <cfhammar> though it could be done with POSIX.2008's O_SEARCH open flag diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn new file mode 100644 index 00000000..6a0632ac --- /dev/null +++ b/open_issues/e2fsck_i_file_acl_hi.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date. + + <Duck> something's broken in ext2, fsck, or the like + <Duck> /dev/hd0s1: i_file_acl_hi for inode 81872 (/proc) is 32, shoud be 0. + <Duck> youpi: the other problem is probably related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526524 + <Duck> i'll just check when it is fixed + <antrik> youpi: I've seen a lot of these fsck errors since the upgrade to 1.41.x + <antrik> youpi: seems to happen whenever a passive translator is still active while the machine reboots + <Duck> antrik: ho, so in my example this could be related to procfs then + <antrik> Duck: don't know... I got it with various terminal-related nodes + <antrik> other translators get terminated before ext2 it seems, so the problem doesn't happen there + <antrik> unless the machine crashes of course + <antrik> ah, right, it told you that it's the /proc node :-) + <antrik> was it the only node it complained about? + <antrik> Duck: ^ + <Duck> antrik: yes, the only one + <youpi> so it's most probably i + <youpi> t + <Duck> but currently i don't have much translators around besides the base install + <antrik> that's strange... my theory about translators active at reboot seems wrong then + <youpi> well, maybe procps is not behaving properly + <youpi> procfs* + <antrik> youpi: I doubt it. I regularily get the same issue with various term nodes; and when the machine crashes rather than rebooting cleanly, many other nodes as well + <youpi> k + <antrik> but it's always passive translator nodes diff --git a/open_issues/elinks.mdwn b/open_issues/elinks.mdwn new file mode 100644 index 00000000..ee372971 --- /dev/null +++ b/open_issues/elinks.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, unknown channel, 2008-05-26 and later + + <paakku> In elinks/src/network/state.h, there is an assumption that values of errno are between 0 and 100000. Now looking at glibc-2.5/sysdeps/mach/hurd/bits/errno.h, I see that you're using values outside this range. Have there been problems because of this? + <youpi> eeerf + <youpi> I had never seen a program assuming that + <youpi> that sucks + <paakku> It can be fixed, but that'd require some work, so I'd like to first have a clear idea of the effects. + <youpi> fixed where ? + <paakku> in elinks + <youpi> k + <paakku> by allocating just one number from our enum connection_state for system errors, and then stashing the errno value in a separate variable. + <paakku> Anyway, if you see this cause any user-visible bugs in ELinks, please report. + + <kahmalo> I mentioned here on 2008-05-26 that ELinks assumes errno values are between 0 and 100000 whereas the Hurd uses other values. I fixed this in ELinks last weekend; the most recent 0.12 and 0.13 snapshots should include the fix. If you find any remaining errno assumptions, please post to: http://bugzilla.elinks.cz/show_bug.cgi?id=1013 + <kahmalo> or to one of our mailing lists. + <kahmalo> I guess the pflocal select() bug http://savannah.gnu.org/bugs/?22861 is the primary hindrance to running ELinks on the Hurd. Has any decision been made on how that will be fixed? diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn new file mode 100644 index 00000000..1806983a --- /dev/null +++ b/open_issues/exec.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang + <youpi> support in exec* I meant + + <youpi> now a funny bug: if I disable gzip/bzip2 support from exec + <youpi> trying to run a zero-byte file hangs diff --git a/open_issues/extern_inline.mdwn b/open_issues/extern_inline.mdwn new file mode 100644 index 00000000..a56d4902 --- /dev/null +++ b/open_issues/extern_inline.mdwn @@ -0,0 +1,74 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <tschwinge> youpi: Did you ever review the Savannah hurd branch master-fix_extern_inline? + <youpi> why static inlines instead of extern lines ? + <youpi> +in + <youpi> static inlines can lead to space waste where it isn't inlined + <tschwinge> Are you sure about that -- I don't think so. + <tschwinge> At least with 99 inlining. + <youpi> what can the compiler do where it isn't inlined ? + <youpi> include a copy + <youpi> thus space waste + <youpi> 00000000004004b1 t f + <youpi> 00000000004004d5 t f + <youpi> I've juste checked + <youpi> two copies of my inline function + <youpi> one per .o + <tschwinge> Yes, but isn't it expected tobe that way? ARen't these functions those that are never included in a libarary, as opposed to those which I switched to __extern_inline in the next patch? + <tschwinge> It's been a long time that I had a look at this... + <tschwinge> The problem with the patch from the Debian package is that the functions didn't end up in the libraries anymore. + <youpi> ah you mean these are private functions and thus shouldn't be exposed (unexpected_reply for instance) + <youpi> but the duplication issue still holds + <youpi> the functions not ending up in the library is a concern indeed + <tschwinge> That's what my second patch fixes, I think. + <youpi> grah, callisto rebooted for no reason + <youpi> ah, indeed the second patch fixes things correctly + <youpi> uh, indeed it's --dbg-package=hurd in there + <youpi> how odd + <youpi> tschwinge: for the libftpconn case, yes unexpected_reply should probably be a static inline + <tschwinge> Is this true: + <tschwinge> static inline -- either inline or emit a local symbol vs. extern inline -- either inline or emit a reference to an external symbol. + <youpi> so as to not expose it + <youpi> for other cases we can keep an extern inline as they are just programs + <tschwinge> Then everything that's not expected to end up in a libarary must be static inline, as otherwise, when the compiler can't inline, there wouldn't be a reference to it available. + <youpi> and that avoids duplicate code + <youpi> yes + <youpi> but as long as you provide the extern inlines by compiling an xinl.c there's no problem + <tschwinge> Sure, that'd be the alternative. + <youpi> for libraries you need to take care of the symbols you want to export (which can thus be in xinl.c), and those you don't want to export (and thus keep static inlines) + <tschwinge> So you say it'd be better to do that (xinl.c) instead of static inline? + <youpi> for programs, you can just keep them all extern inlines + <youpi> yes, it shares code + <youpi> it's only in the case of symbols that shouldn't be exported by the library that we need to use static inlines + <tschwinge> ANd in .c files that are part of programs I'd also use extern inline or static inline? + <youpi> for programs just always use extern lines + <youpi> +in + <youpi> as you don't care about symbol exposure + <youpi> unless the inline is defined in a .c file of course, in that case it's useless to make it extern + <tschwinge> But then I also always need xinl.c files for those, which we apparently don't have in a few places. + <youpi> yes + <tschwinge> But probably didn't notice so far, as the functions could always be inlined. + <youpi> probably because we used to have luck + <youpi> yes + <tschwinge> Yes, I was thinking about the term/munge.c thing. + <tschwinge> OK, I think I get it now. Then I'll try to fix this accordingly. + <tschwinge> But not now. Thanks for the help! + <youpi> ok, thanks + <tschwinge> It was quite a bit confusing to me. + <tschwinge> Due to the mostly reversed definition of extern inline in glibc (I think). + <youpi> inline definitely is confusing + <youpi> especially since the semantic has changed over time and according to standards :) + <tschwinge> And then GCC changing that according to C99. + <tschwinge> Yes. diff --git a/open_issues/fdisk.mdwn b/open_issues/fdisk.mdwn new file mode 100644 index 00000000..ece8fc89 --- /dev/null +++ b/open_issues/fdisk.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + Command (m for help): w + The partition table has been altered! + + Calling ioctl() to re-read partition table. + *Segmentation fault* + +Changes have been saved, though. + +Perhaps realted to the [[BLKRRPART_IOCTL]]? diff --git a/open_issues/fsync.mdwn b/open_issues/fsync.mdwn new file mode 100644 index 00000000..d36a75ad --- /dev/null +++ b/open_issues/fsync.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date + + <youpi> azeem: I think I found why apt-get throws Hurd down sometimes + <youpi> the problem is that it basically write(file, 20MB); fsync(); + <youpi> i.e. it throws a storm of dirty-writeback to ext2fs + <youpi> which thus goes into throttling threads + <youpi> since posix explicitely says that fsync() can be void, I think I'll patch apt-get on the buildd + <youpi> (that bug has bitten me too many times in the past days to let it go further) + <youpi> for now it works + * youpi crosses fingers diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn index 76832165..3209d5b0 100644 --- a/open_issues/gcc.mdwn +++ b/open_issues/gcc.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -47,4 +48,4 @@ Additionally: * [[`libmudflap`|libmudflap]]. - * [[C++]]. + * [[Boehm_GC]]. diff --git a/open_issues/gcc/boehm_gc.mdwn b/open_issues/gcc/boehm_gc.mdwn new file mode 100644 index 00000000..2ee88a2b --- /dev/null +++ b/open_issues/gcc/boehm_gc.mdwn @@ -0,0 +1,29 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gcc]] + +IRC, unknown channel, unknown date. + + <tschwinge> youpi: The Debian GCC 4.3 package also has this change: + <tschwinge> --- boehm-gc/dyn_load.c.orig 2007-08-13 09:10:48.215678000 +0200 + <tschwinge> +++ boehm-gc/dyn_load.c 2007-08-13 09:11:09.743969000 +0200 + <tschwinge> @@ -26,7 +26,7 @@ + <tschwinge> * None of this is safe with dlclose and incremental collection. + <tschwinge> * But then not much of anything is safe in the presence of dlclose. + <tschwinge> */ + <tschwinge> -#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE) + <tschwinge> +#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) && !defined(_GNU_SOURCE) + <youpi> yes, these are needed + <youpi> and that's the kind of fix needed for java + +--- + +<http://lists.debian.org/debian-hurd/2000/03/msg00305.html> diff --git a/open_issues/gdb_config.mdwn b/open_issues/gdb_config.mdwn new file mode 100644 index 00000000..4f031c8f --- /dev/null +++ b/open_issues/gdb_config.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb]] + + * Have a look at config/i386/i386gnu.mh. + + * configure.tgt + + * glibc-tdep et al. also for GNU/Hurd? diff --git a/open_issues/gdb_qemu_debugging_gnumach.mdwn b/open_issues/gdb_qemu_debugging_gnumach.mdwn new file mode 100644 index 00000000..d3105f50 --- /dev/null +++ b/open_issues/gdb_qemu_debugging_gnumach.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gdb open_issue_gnumach]] + +\#hurd, freenode, June (?) 2010 + + <jkoenig> is there a way to get gdb to map addresses as required when debugging mach with qemu ? + <jkoenig> I can examine the data if I manually map the addresses th 0xc0000000 but maybe there's an easier way... + <youpi> jkoenig: I haven't found a way + <youpi> I'm mostly using the internal kdb + diff --git a/open_issues/glibc_ioctls.mdwn b/open_issues/glibc_ioctls.mdwn new file mode 100644 index 00000000..14329d0f --- /dev/null +++ b/open_issues/glibc_ioctls.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <pinotree> d'oh, broken defines for ioctl()! + <pinotree> http://paste.debian.net/45021/ ← any idea about this? looks like something fishy with the SIO* defines + <pinotree> tschwinge: ↑ know anything about this? + <pinotree> #define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← looks like it is missing for bits/ioctls.h + <pinotree> eglibc patch submitted-ioctl-unsigned-size_t.diff should be pimped a bit + + <pinotree> youpi: while trying to compile ossp-uuid (needed by pgsql 8.4, needed by various other stuff), i found a bug in a hurd libc header + <youpi> that's possible + <pinotree> it has a ioctrl() using an id with a value having type 'struct arpreq' + <youpi> ah, that's not a bug then + <youpi> see the ioctl section of the porting page of the wiki + <pinotree> due to the sort of "mangling" done in bits/ioctrls.h, there should be an helper macro for the size of the struct arpreq + <pinotree> +#define _IOT_arpreq _IOT_SIMPLE (struct arpreq) ← adding this before any header was enough + * pinotree looks + <youpi> it's not to be done so simply + <youpi> see the page :) + <youpi> I'm afraid _IOT_arpreq can't be properly defined + * pinotree is not finding it... + <pinotree> the closest i see is http://lists.gnu.org/archive/html/bug-hurd/2006-03/msg00025.html + <youpi> that's it yes + <youpi> I mean, that's the kind of thing + <youpi> but not the wiki page, let me look + <youpi> http://www.gnu.org/software/hurd/hurd/porting/guidelines.html + <pinotree> i also saw a glib patch adding few types like that (char, short, int) + <youpi> yes that's the same kind of thing + <pinotree> i see + <youpi> setting it to _IOT_SIMPLE(struct arpreq) would probably work with 32bit gnumach and 32bit userland, but may not with e.g. 64bit gnumach and 32bit userland and such + <pinotree> hmmm, sockaddr,sockaddr,int,sockaddr,char[16] + <pinotree> so basically it would support at most 3 elements in a passed struct? + <pinotree> s/elements/fields/ + <youpi> 3 kinds of fields + <youpi> as you provide a count + <pinotree> youpi: so basically: #define _IOT_arpreq _IOT (_IOTS (struct sockaddr), 3, _IOTS (int), 1, _IOTS (char), 16) ? + <pinotree> ie the order of the fields in the struct does not matter, it seems? + <youpi> the order of the fields does matter + <youpi> as this encodes how mig will read the struct to send them + <pinotree> uhm + <youpi> also, _IOTS(struct sockaddr) won't work + <pinotree> yeah i should define it too + <youpi> no, it even needs to be replaced by its content + <pinotree> ah + <pinotree> it is possible to compose the _IOTS()? + <pinotree> (to build structs with more than 3 kind of fields) + <youpi> no + <pinotree> d'oh + <youpi> that's a hard shortcoming of the whole ioctl encoding + * pinotree scratches his head + <youpi> there's no way but redefining ioctl(), really + <youpi> it was a funny trick to encode it this way, but unrealistic + <pinotree> i see, yes + <youpi> not to mention ioctls which contain pointers, which just can not be passed to mig + <pinotree> indeed + <youpi> actually it's not mach's ioctl issue + <youpi> as mach doesn't know ioctl + <youpi> but the hurd ioctl interface + <pinotree> right + <youpi> which might end up in mach, other processes, other machines, etc. + * pinotree s/Mach/Hurd/ :) diff --git a/open_issues/glibc_libpthread_robust_mutexes.mdwn b/open_issues/glibc_libpthread_robust_mutexes.mdwn new file mode 100644 index 00000000..a92c984d --- /dev/null +++ b/open_issues/glibc_libpthread_robust_mutexes.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +libpthread: glibc 44e2ad5ab8c21dbfed3e384ba2ed31d7a8fc4744 +998e5fc14595229101561d76282036839e5b66ab -- The robust mutex functions are in +POSIX 2008. + +--- + +IRC, #hurd, unknown date. + + <youpi> neal: bad news: you remember the PTHREAD_RECURSIVE_MUTEX_INITIALIZER that points to a global __pthread_recursive_mutexattr? + <youpi> that doesn't work + <youpi> because some libraries like libstdc++ do not link against libpthread, while still using pthread_mutex_lock/unlock (counting on them being provided by either libc or libpthread-stubs) + <CIA-1> sthibaul-guest * r626 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): + <CIA-1> * debian/patches/libpthread_rwlock_initializer.patch: Disable patch for now: + <CIA-1> our initializer does not work when the application does not link against + <CIA-1> libpthread. + + <CIA-1> sthibaul-guest * r629 pkg-hurd/hurd/trunk/debian/ (changelog patches/series): do not disable adding PTHREAD_RWLOCK_INITIALIZER, that's not the one that poses problems + <CIA-1> sthibaul-guest * r630 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_no_recursive_mutex_initializer.patch: New patch + <CIA-1> to drop undefined references to __pthread_recursive_mutexattr. + + <youpi> I'm thinking about how to fix the PTHREAD_RECURSIVE_MUTEX_INITIALIZER + <youpi> instead of a pointer to a static attribute variable, which posed problem + <youpi> could we perhaps consider that page 0 is never mapped + <youpi> and thus not only pointer 0 but also 1 2, etc. are invalid + <neal> I think that is a good solution + <youpi> and use them as special values + <neal> alternatively, we could assume that -PAGESIZE is never valid + <youpi> that makes us test it in all pthread_mutex_* functions, but it's not so bad + <neal> I'm not sure which is better + <youpi> why isn't it? + <neal> because the kernel is mapped there normally + <youpi> the kernel could be elsewhere + <neal> true + <youpi> in a 64bit adressing space for instance + <neal> I think your solution is a good one + <youpi> ok + + <CIA-1> sthibault * r633 pkg-hurd/hurd/trunk/debian/ (3 files in 2 dirs): + <CIA-1> * debian/patches/libpthread_recursive_mutex_initializer.patch: New patch + <CIA-1> to fix the recursive mutex initializers usage in libraries not linking + <CIA-1> against libpthread. diff --git a/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn new file mode 100644 index 00000000..47f104c6 --- /dev/null +++ b/open_issues/glibc_tls_segment_tcbhead_t_dtv_offset.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> you can hardcode DTV_OFFSET as 4 for now + <youpi> it's the offset of the dtv field in the tcbhead_t structure from hurd/libpthread + <tschwinge> youpi: May very well be that I'm misunderstanding something, but wouldn't it rather be the offset of tcb in __pthread + the offset of dtv in tcbhead_t (which indeed is 4)? + <youpi> what you don't know is that DTV_OFFSET is not relative to __pthread, but to the tls segment + <tschwinge> Oh, aha. Thanks. + <youpi> and drepper abused the fact that in nptl __pthread appears at the start of the tls segment + +kFreeBSD, glibc: + + ++#if 0 + + DTV_OFFSET offsetof(struct pthread, header.dtv) + ++#else + ++DTV_OFFSET offsetof(struct _pthread_descr_struct, p_header.data.dtvp) + ++#endif diff --git a/open_issues/glusterfs.mdwn b/open_issues/glusterfs.mdwn new file mode 100644 index 00000000..68518938 --- /dev/null +++ b/open_issues/glusterfs.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, unknown channel, unknown date. + + <antrik> "GlusterFS is one of the most sophisticated file system in terms of features and extensibility. It + <antrik> borrows a powerful concept called Translators from GNU Hurd kernel." + <antrik> seems to be more similar to libstore than actual translators, though diff --git a/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn new file mode 100644 index 00000000..2df74301 --- /dev/null +++ b/open_issues/gnumach_general_protection_trap_gdb_vm_read.mdwn @@ -0,0 +1,142 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <antrik> youpi: I have found an interesting Mach problem, but I'm a bit scared of debugging it... + <antrik> (it is related to VM stuff) + <antrik> I have a memory region that is mapped by the iopl device (it's an mmio region -- graphics memory to be precise) + <antrik> when gdb tries to read that region with vm_read() (for a "print" command), it triggers a general protection trap... + <youpi> antrik: does the general protection trap kill the whole kernel or just gdb? + <antrik> kernel + <antrik> kernel: General protection trap (13), code=0 + <antrik> pmap_copy_page(41000000,49f2000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(209c1c54,41000000,1000,1,20994908) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(209c1c54,41000000,1000,20994908,2099490c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(209ba6e4,2c000,1000,0,25394ec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(209ba6e4,2c000,1000,208d303c,25394f00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(2095cfe4,208d3010,0,1fff3e48,2095cfd4) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(2095cfd4,2095cfe4,28,127ca0,0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(1024440,3,28,30,2c) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x102441c + <antrik> BTW, is it useful at all to write down the paramenters as well?... + <antrik> argments I mean + <youpi> in the trace you mean? + <antrik> yes + <youpi> apparently the problem here is that the call to vm_fault_page() didn't perform its task + <youpi> which address is faulty? + <antrik> not sure what you mean + <youpi> ah shit the gpf wouldn't tell you + <youpi> does examine 49f2000 work? + <youpi> oh, wait, 4100000, that can't work + <youpi> +0 + <youpi> which physical address is your mmio at? + <antrik> haven't tried it... but I can provoke the fault again if it helps :-) + <youpi> we have the 1GB limitation issue + <antrik> oh... lemme check + <youpi> no need to, I think the problem is that + <youpi> the iopl driver should check that it's not above phys_last_addr + <antrik> it's only vm_read() that fails, though... + <antrik> the actual program I debugged in gdb works perfectly fine + <youpi> yes, but that's because it's accessing the memory in a different way + <youpi> in the case of direct reads it just uses the page table + <youpi> in the case of vm_read() it uses kernel's projection + <youpi> but in that case it's not in the kernel projection + <antrik> phys = 1090519040 + <youpi> that's it, it's beyond 1GB + <youpi> there's not much to do except changing mach's adressing organization + <antrik> yeah, that's the 0x41000000 + <antrik> hm... I guess we could make the vm_read() bail out instead of crashing?... + <youpi> yes + <youpi> but there are a lot of places like this + <antrik> still, it's not exactly fun when trying to debug a program and the kernel crashes :-) + <youpi> right :) + <antrik> I could try to add the check... if you tell me where it belongs ;-) + <youpi> antrik: it's not just one place, that's the problem + <youpi> it's all the places that call pmap_zero_page, pmap_copy_page, copy_to_phys or copy_from_phys + <youpi> and since we do want to let the iopl device create such kind of page, in principle we have to cope with them all + <youpi> pmap_zero_page should be ok, though + <youpi> the rest isn't + <antrik> is that tricky, or just a matter of doing it in all places? + + <antrik> hm... now it crashed in "normal" usage as well... + <antrik> hm... a page fault trap for a change... + <antrik> hm... now gdb tried to vm_read() something that is mapped to physical address 0x0... + <antrik> so I guess I fucked something up in the mapping code + <antrik> is it expected that such a vm_read() causes a kernel page fault, though?... + <antrik> youpi: ^ + <youpi> nope + <youpi> in principle the check for validity of the page is done earlier + <youpi> physical address 0x0 makes sense, though + <antrik> OK, here is the trace: + <antrik> Kernel page fault (14), code=0 at address 0x0 + <antrik> pmap_copy_page(0,6e54000,1,0,1) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../i386/i386/phys.c:62 + <antrik> vm_object_copy_slowly(20a067b0,0,1000,1,0acacec) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1150 + <antrik> vm_object_copy_strategically(20a067b0,0,1000,20acacec,20acacf0) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_object.c:1669 + <antrik> vm_map_copyin(20a0f1c4,120d000,1000,0,253cdec8) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_map.c:3297 + <antrik> vm_read(20a0f1c4,120d000,1000,20a5703c,253cdf00) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../vm/vm_user.c:228 + <antrik> _Xvm_read(20a52c80,20a57010,253cdf40,20ae33cc,20a52c70) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/kern/mach.server.c:1164 + <antrik> ipc_kobject_server(20a52c70,20a52c80,28,20873074,20873070) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../kern/ipc_kobject.c:201 + <antrik> mach_msg_trap(10247d0,3,28,30,2f) + <antrik> /build/buildd/gnumach-1.3.99.dfsg.cvs20090220/build-dbg/../ipc/mach_msg.c:1367 + <antrik> Bad frame pointer: 0x10247ac + <antrik> seems to be exactly the same, except for the different arguments... + <antrik> hm... interesting... it *does* write something to the framebuffer, before it crashes... + <antrik> (which unfortunately makes it a bit hard to read the panic message... ;-) ) + <LarstiQ> heh :) + <antrik> wait, it must write to something else than the frame buffer as well, or else the debugger should just paint over the crap... + <antrik> or perhaps it crashes so hard that the debugger doesn't even work? ;-) + <antrik> hm... I guess the first thing I should actually do is finding out what's up with e2fsck... this make testing crashes kinda annoying :-( + <antrik> oh, "interesting"... I ran it on one of my other hurd partitions, and it complained about an endless number of files... (perhaps all) + <antrik> however, the value for the normal files was different than for the passive translator nodes + <antrik> it doesn't happen only on crashes; it seems that all passive translators that are still in use at time of shutdown (or crash) have the offending bit set in the inode + <antrik> ouch... seems it doesn't write into the framebuffer after all, but rather scribbles all over the first 4 MiB of memory -- which includes also the VGA window, before it goes on killing the kernel... + <youpi> which iopl driver are you using ? + <antrik> ? + <youpi> the one from the debian patch? + <youpi> upstream, gnumach doesn't have an iopl device any more + <antrik> I guess so... standard Debian stuff here + <antrik> oh. how does X map the memory, then? + <youpi> X does yes + <antrik> ? + <youpi> X uses the iopl() device to access the video memory, yes + <youpi> I don't know if that was what you were asking for, but that's what I meant by my answer :) + <antrik> yeah, I know how it does *currently* do it -- I stole the code from there :-) + <antrik> my question is, how is X supposed to get at the framebuffer, when there is no iopl device anymore? + <youpi> ah, I hadn't noticed the "how" word + <youpi> in Debian there is + <LarstiQ> !debian → !x? + <youpi> the clean "access device memory" interface is yet to be done + <antrik> err... that sounds like Xorg philosophy + <youpi> what, to wait for a nice interface ? + <antrik> "let's kill the old stuff, fuck regressions... maybe someone will figure out how to do it with the new stuff at some point. if not, not our problem" + <youpi> that's also a GNU philosophy + <youpi> ah, that one + <antrik> anyone know how device_map() is supposed to behave? the documentation isn't really clear... + <antrik> my understanding was then when an offset is specified, then the resulting object will be relative to that object; i.e. the offset of a later vm_map() on this object is applied on top of the object's internal offset... + <antrik> but that doesn't seem to be how it works for the iopl device, if I read the xf86 code correctly... + <antrik> yeah, the offset parameter seems a nop when doing device_map() on the iopl device diff --git a/open_issues/gnumach_tlb_flushing.mdwn b/open_issues/gnumach_tlb_flushing.mdwn new file mode 100644 index 00000000..45d0730d --- /dev/null +++ b/open_issues/gnumach_tlb_flushing.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <tschwinge> gianluca, youpi: Why the value 32 for the TLB flushing decision, by the way? + <youpi> completely arbitrary + <tschwinge> I thought whether that might perhaps be worth a macro definition with a comment? + <verte> what's the typical TLB size these days? + <youpi> tschwinge: right + <youpi> note that the 32 value would be probably different between native and xen + <gianluca> tschwinge: just arbitrary diff --git a/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn new file mode 100644 index 00000000..b1eaf9a5 --- /dev/null +++ b/open_issues/hurd_file_name_lookup_retry_FS_RETRY_MAGIC.mdwn @@ -0,0 +1,21 @@ +[[!meta copyright="Copyright © 2009, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, #hurd, 2009-08-25 + + <cfhammar> also I fixed (what I think is) a bug in hurd_file_name_lookup_retry when opening FDs with FS_RETRY_MAGIC + <cfhammar> it didn't actually reopen the FD, rather it just (effectively) duped it + <scolobb> cfhammar: That's great! I think I had some problems because of not being able to truly reopen a port to a file. + <antrik> cfhammar: what is the difference, and why do you consider it a bug?... + <cfhammar> antrik: for one thing you can't change open modes, and it doesn't reset the file cursor + <cfhammar> (which I actually needed, though I could have done it manually) + <cfhammar> antrik: and also it isn't consistant with linux + <cfhammar> you can trigger the bug from the shell: cat /dev/fd/3 3>> /tmp/foo + <antrik> cfhammar: I can't say that I understand the test case... but I can at least confirm that it behaves differently on Hurd and on Linux :-) diff --git a/open_issues/kvm.mdwn b/open_issues/kvm.mdwn new file mode 100644 index 00000000..6dfffc9a --- /dev/null +++ b/open_issues/kvm.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Issues when running Hurd under KVM: un-synced filesystems, etc. No problems +with Virtualbox. + +2010-07-28, #hurd + + <youpi> pochu: you were the one reporting issues with qemu/kvm and hurd, right? + <youpi> is your machine somehow smp (like multicore for instance) + <youpi> ? + <pochu> youpi: yes, it's a Core 2 Duo + <pochu> so 2 cores + <youpi> ok, you might want to try to bind qemu/kvm + <youpi> e.g. install hwloc, and prepend "hwloc-bind 1 --" before the qemu/kvm command line + <pochu> ok, ty + +2010-07-31, GNU Mach commit 039176372b4271f370ef38eb2ee5d43923a5b28b. diff --git a/open_issues/libasyncns.mdwn b/open_issues/libasyncns.mdwn new file mode 100644 index 00000000..bbd34bff --- /dev/null +++ b/open_issues/libasyncns.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, unknown channel, unknown date. + + <pinotree> tschwinge: btw, would you be able to tell if and what's wrong with a socket-related problem? + <pinotree> it is reproducible with a very small self-contained C library + <pinotree> http://0pointer.de/lennart/projects/libasyncns/ + <pinotree> it has a test case with it, which fails + <pinotree> tschwinge: if that can ring some bell, imho the problem is related to SOCK_STREAM sockets created with socketpair and used with send/recv diff --git a/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn new file mode 100644 index 00000000..1e4a6acb --- /dev/null +++ b/open_issues/libdiskfs_dot_dot-dot_relevant_for_libnetfs.mdwn @@ -0,0 +1,20 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <tschwinge> By the way: your libdiskfs ., .. fix -- is that relevant for libnetfs as well? (Didn't look it up so far.) + <youpi> it could be a good idea to protect netfs users directly from there yes + <tschwinge> But probably the backend (e.g., NFS server) would protect us in the netfs case, right? + <youpi> possibly, but we could have locking issues in between like in libdiskfs + <youpi> and POSIX says it's invalid anyway + <youpi> so we'd probably better just forbid it diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn index 68195758..16b6d098 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_glibc open_issue_pthread]] +[[!tag open_issue_glibc open_issue_libpthread]] GSoC project idea: [[community/gsoc/project ideas/pthreads]] diff --git a/open_issues/libpthread_weak_symbols.mdwn b/open_issues/libpthread_weak_symbols.mdwn new file mode 100644 index 00000000..6f135979 --- /dev/null +++ b/open_issues/libpthread_weak_symbols.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_libpthread]] + +IRC, unknown channel, unknown date. + + <youpi> btw, the issue with pthread_cancel is tricky + <youpi> I'm afraid there might be no fix + <youpi> clean fix, I mean + <pinotree> oh, hm + <pinotree> where it the problem located, actually? + <youpi> it's a lot more than just one place + <youpi> in some c++ header there is a weak reference to pthread_cancel + <youpi> libpthreadstubs0 provides a weak definition of pthread_cancel, which can suit well + <youpi> problem comes when also linking with a library which pulls libpthread + <youpi> oops no libpthreadstubs0 doesn't provide a weak definition of pthread_cancel + <youpi> it couldn't implement it anyway + <youpi> and the problem here is that the linker seems to be looking for pthread_cancel in the libpthreadstubs0 library, not libpthread + <youpi> and can't find it + <youpi> I don't know how this translate to english, but we're “walking on eggs + <youpi> ” on this issue + <pinotree> i see + <youpi> i.e. we already know we're not respecting the ELF standard + <youpi> we need a feature that is not in the standard to make pthread symbols working + <youpi> the solution would be to integrate libpthread into the glibc + <pinotree> you mean in the sources, but still providing separate libc.so and libpthread.so? + <youpi> yes + <pinotree> would that be difficult/tricky? + <youpi> because that permits to put pthread_* functions forwarding directly in the glibc, as is done on linux + <youpi> problem is upstream, you know... + <youpi> if we put libpthread there, it'll be difficult for us to maintain it + <pinotree> ah, the friendly ulrich mate? + <youpi> we already have difficults to get almost trivial patches commited + <youpi> and the "yes I'll handle it someday" Roland mate + <youpi> Roland is supposed to be the GNU part maintainer, but he doesn't have a box running at the moment + <youpi> what we could do is to do it in Debian for the moment + <pinotree> yeah + <pinotree> iirc eglibc is maintained within git, isn't it? + <pinotree> maybe you could do a hurd branch, putting all the hurd patches and the pthread sources, and then releasing from that + <youpi> we're already moving to something like that, yes + <youpi> at least for all the other glibc patches we have + <youpi> maybe we'll just do that on sourceware actually diff --git a/open_issues/lisp_cross-compile.mdwn b/open_issues/lisp_cross-compile.mdwn new file mode 100644 index 00000000..c9100aec --- /dev/null +++ b/open_issues/lisp_cross-compile.mdwn @@ -0,0 +1,11 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +flaviocruz-soc2008-lisp-branch: lisp stuff can't be cross-compiled. diff --git a/open_issues/lsof.mdwn b/open_issues/lsof.mdwn new file mode 100644 index 00000000..2cbf2302 --- /dev/null +++ b/open_issues/lsof.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +We don't have a `lsof` tool. Perhaps we could cook something with having a +look at which ports are open at the moment (as [[`portinfo`|hurd/portinfo]] +does, for example)? diff --git a/open_issues/ltrace.mdwn b/open_issues/ltrace.mdwn new file mode 100644 index 00000000..cf0df759 --- /dev/null +++ b/open_issues/ltrace.mdwn @@ -0,0 +1,19 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <youpi> it'd be good to have ltrace eventually + <youpi> rpctrace has too many issues to be usable + <youpi> (and a lot of them are hard to fix iirc) + <youpi> ltrace traces library calls + <youpi> in principle it should just work at the dynamic linker stage, so should be portable diff --git a/open_issues/mach-defpager_vs_defpager.mdwn b/open_issues/mach-defpager_vs_defpager.mdwn new file mode 100644 index 00000000..d6976706 --- /dev/null +++ b/open_issues/mach-defpager_vs_defpager.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +\#hurd, 2010, end of May / beginning of June + + <cfhammar> whats the difference between mach-defpager and defpager? + <cfhammar> i'm guessing defpager is a hurdish version that uses libstore but was never finished or something + <cfhammar> found an interesting thread about it: http://mirror.libre.fm/hurd/list/msg01232.html + <slpz> antrik: an interesting thread, indeed :-) + <pochu> slpz: btw is mach-defpager linked statically but not called mach-defpager.static on purpose? + <slpz> antrik: also, I can confirm that mach-defpager needs a complete rewrite ;-) + <slpz> pochu: I think the original defpager was launched by serverboot + <slpz> pochu: that could be the reason to have it static, like ext2fs + <slpz> and since there's no need to execute it again during the normal operation of the system, they probably decided to not create a dynamically linked version + <slpz> (but I'm just guessing) + <slpz> of perhaps they wanted to prevent mach-defpager from the need of reading libraries, since it's used when memory is really scarce (guessing again) diff --git a/open_issues/magic_translator_machtype.mdwn b/open_issues/magic_translator_machtype.mdwn new file mode 100644 index 00000000..1c62b762 --- /dev/null +++ b/open_issues/magic_translator_machtype.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="/hurd/magic machtype"]] + +[[!tag open_issue_hurd open_issue_glibc]] + + tschwinge@clubber:~ $ settrans -ca machtype /hurd/magic machtype + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. + thomas@dirichlet:~ $ ssh clubber + Warning: Permanently added '[clubber.bddebian.com]:2251' (RSA) to the list of known hosts. + Last login: Tue Dec 30 08:52:58 2008 from dslb-084-057-196-016.pools.arcor-ip.net + tschwinge@clubber:~ $ cat machtype + Segmentation fault + tschwinge@clubber:~ $ l machtype + Segmentation fault + tschwinge@clubber:~ $ l mach<TAB>Connection to clubber.bddebian.com closed. diff --git a/open_issues/mig_error_reply.mdwn b/open_issues/mig_error_reply.mdwn new file mode 100644 index 00000000..21a5b217 --- /dev/null +++ b/open_issues/mig_error_reply.mdwn @@ -0,0 +1,68 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_mig]] + +\#hurd, freenode, 2010-05-19 + + <cfhammar> ugh, mig server stubs generated from *_reply.defs don't call the server functions when the reply is an error, since the message size is too small... + <cfhammar> term seems to get around it by turning of type checking + <cfhammar> s/of/off + <cfhammar> but streamio doesn't + <cfhammar> luckily the only other program that makes use of a *_reply.defs is crash, and crash_reply.defs' routines only return an error code so it isn't affected + <slpz> cfhammar: could you point me to a stub with that problem? + <cfhammar> slpz: trans/device_replyServer.c:_Xdevice_open_reply (in build dir) + <slpz> cfhammar: So, if I understand it correctly, the problem is that GNU Mach generated stub doesn't properly set the size of the message if there's an error in the function, thus the type checking in user generated stub discards the reply + <cfhammar> slpz: the size is correct, error messages contain just a return value + <cfhammar> slpz: it is the type checking that is at fault imho + <slpz> cfhammar: even when a server wants to return an error, the size of the message should be the same as the reply structure previously defined + <slpz> cfhammar: on the other hand, I can't understand why streamio is using device_open_request (async RPC) instead of device_open (sync RPC)... + <cfhammar> slpz: the server does not always know the proper size, e.g. when it doesn't understand the message + <slpz> cfhammar: what do you mean by "doesn't understand the message"? + <cfhammar> slpz: if it doesn't implement that interface or is the wrong type, etc. + <cfhammar> slpz: in that case the mig stub needs to send out a generic error reply + <cfhammar> slpz: i don't know why streamio uses it either + <slpz> cfhammar: OK, now I see your point. If the server answers with a generic error code (as MIG_*), device_open_reply will not be called, and device_open_request doesn't get an error. + <slpz> cfhammar: good catch :-) + <cfhammar> slpz: all errors are handled the same way, MIG_* is just an example of why it does so + <slpz> cfhammar: on an unrealted note, I think we should get rid of all asynchronous messages sent from the user to the kernel, since they aren't asynchronous except for sending the reply to a different port (the process is really done by the thread calling mach_msg) + <cfhammar> slpz: i'm not not all that familiar with the low-level parts of message passing so i can't really comment + <slpz> cfhammar: in that point I disagree. If the server function can understand the message (so there isn't a MIG_* error), it can send a reply message with the proper size + <cfhammar> slpz: it could, but what is the advantage if we still need to handle generic errors? + <cfhammar> slpz: "sending the reply to a different port", different from what? + <slpz> cfhammar: to differentiate between message marshalling errors and errors generated by the called function + <slpz> cfhammar: in a synchronous RPC, the same call to mach_msg will send the request and receive the reply by providing a mig generated reply port + <slpz> cfhammar: but in an asynchronous, the reply is received by a port previously generated by the function requesting the message + <cfhammar> slpz: ah, that's a clever optimization + <slpz> cfhammar: if the "asynchronous" message is sent to the kernel, the thread calling for mach_msg will execute the server's function, but the reply will be sent to one of these previously generated ports + <slpz> cfhammar: actually you have a synchronous operation replying to a different port. That doesn't make much sense to me :-) + <antrik> slpz: note that most kernel functions can be implemented by userspace servers, in which case they could be really async... + <cfhammar> slpz: not sure how differentiating mig errors from server errors is useful... + <slpz> antrik: define "most kernel functions" ;-) + <cfhammar> slpz: if nothing else kernel rpcs can be proxied, e.g. rpctrace + <slpz> cfhammar: well, think of device_open_request. If the result is not a mig error, you can still device_open_reply an expect it to properly process the return code from the message + <cfhammar> slpz: it should be able to handle all kinds of errors anyway, the result should be the same as with syncronous rpcs + <slpz> cfhammar: yes, you're right. User generated stub should be able to fill the reply with the error code and call to the reply function. + <slpz> cfhammar: Then someone needs to introduce some changes in MiG's magic... + <cfhammar> slpz: yes, a flag to generate reply side of an interface would be ideal + <cfhammar> slpz: then we could toss out *_reply.defs altogether + <slpz> cfhammar: well, that's a different change from what I was thinking + <cfhammar> slpz: how would you change it? + <slpz> cfhammar: just generating stubs which, in case of error, will properly call to the reply function with the error code in its arguments + <cfhammar> slpz: ah yes, i considered that as well, but i don't think mig can actually distinguish the error code from any other int argument + <cfhammar> slpz: i should double check it though + <slpz> cfhammar: I tag can be used to point to argument of this nature + <slpz> cfhammar: s/I/A/ + <cfhammar> slpz: oh, it already is tagged with retcode, intresting + <slpz> cfhammar: OMG, I'm thinking like MiG! ;-P + <cfhammar> slpz: is that a good or bad ; + <cfhammar> slpz: ;-) + <slpz> cfhammar: I don't know, but it's somewhat scary ;-) + <cfhammar> slpz: apparently retcode is only there for comatibility, mig just ignores it... diff --git a/open_issues/neals_hurd-misc_papers.mdwn b/open_issues/neals_hurd-misc_papers.mdwn new file mode 100644 index 00000000..7f4e1e3b --- /dev/null +++ b/open_issues/neals_hurd-misc_papers.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +<http://walfield.org/pub/people/neal/papers/hurd-misc/> + + <tschwinge> neal: We could put that into the wiki some day, I think. + <neal> sure diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn new file mode 100644 index 00000000..daec8b11 --- /dev/null +++ b/open_issues/nptl.mdwn @@ -0,0 +1,27 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + <tschwinge> Other question: how difficult is a NPTL port? Futexes and some kernel interfaces for scheduling stuff etc. -- what else? + <youpi> actually NPTL doesn't _require_ futexes + <youpi> it just requires low-level locks + <youpi> Mmm, it seems to be so only in principle + <youpi> I can see futex names here and there in the generic code + <youpi> looks like Drepper isn't disciplined enough in that area either + <tschwinge> (well, why would he...) + <youpi> I'm not sure we really want to port NPTL + <tschwinge> OK. + <youpi> Drepper will keep finding things to add + <youpi> while the interface between glibc and libpthread isn't increasing _so_ much + <tschwinge> ... and even less so the interfavce that actual applications are using. + <tschwinge> We'd need to evaluate which benefits NPTL would bring. diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn new file mode 100644 index 00000000..7594ae76 --- /dev/null +++ b/open_issues/packaging_libpthread.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_libpthread open_issue_glibc]] + +IRC, #hurd, 2010-07-31 + + <tschwinge> My idea was to have a separate libpthread package. What do you think about that? + <youpi> in the long term, that can't work with glibc + <youpi> because of the thread stub stuff + <youpi> it's not really possible to keep synchronized + <youpi> because you have to decide which package you unpack first + <youpi> (when upgrading) + <tschwinge> Hmm, how is that different if two shared libraries are in one package vs. two packages? It isn't atomic either way? Aren't sonames / versioned library packages solving that? + <tschwinge> ... for incompatible forward changes? + <youpi> that'd be a mess to maintain + <youpi> Drepper doesn't have this constraint and thus adds members of private fields at will + <tschwinge> OK, but how is it different then if the libpthread is in the Hurd package? + <youpi> I'm not saying it's better to have libpthread in the Hurd package + <tschwinge> OK. + <youpi> I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc + <tschwinge> Then, to goal is to have it in glibc? + <tschwinge> OK. :-) + <tschwinge> OK, I can accommodate to that. Isn't not that we'd want to switch libpthread to something else so quickly. + <tschwinge> So our official goal is to have libpthread in glibc, at least for Debian purposese? + <youpi> for any port purpose + <tschwinge> Ack. + <youpi> provided you're using glibc, you're deemed to ship libpthread with it + <youpi> because of the strong relations Drepper puts between them + <youpi> (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance) + <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used + <pinotree> (would be nice to not have those issues anymore...) + <tschwinge> So -- what do we need to put it into glibc? We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.) + <tschwinge> Does that sound about right, or am I missing something fundamental? + <youpi> I actually don't know what a git submodule permits :) + <youpi> looks like a good thing for this, yes + <tschwinge> Unfortunately I can't allocate much time at the moment to work on this. :-/ + <youpi> well, as long as I know where we're going, I can know how to package stuff in Debian + <tschwinge> That sounds like a plan to me. libpthread -> glibc as submodule. + <youpi> (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so) diff --git a/open_issues/populate_hurd_git_with_submodules_etc.mdwn b/open_issues/populate_hurd_git_with_submodules_etc.mdwn new file mode 100644 index 00000000..c89b95e9 --- /dev/null +++ b/open_issues/populate_hurd_git_with_submodules_etc.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="populate hurd.git with submodules, etc."]] + +Populate the top-level *[Savannah]/hurd.git* with a bunch of submodules +(various translators; everything that's intersting), have it serve as sort of a +tested distribution (because the submodules are versioned), plus adding build +machinery / cross-compilation support, etc. diff --git a/open_issues/pth.mdwn b/open_issues/pth.mdwn index bf9c70d7..12bf5098 100644 --- a/open_issues/pth.mdwn +++ b/open_issues/pth.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -10,8 +11,18 @@ is included in the section entitled [[!tag open_issue_porting]] +IRC, unknown channel, unknown date. + <azeem> seems pth still doesn't work <bddebian> Doesn't build or doesn't work? <azeem> both <azeem> some configure test keep grinding the CPU, same for the test suite <azeem> which apparently runs pth_init() and never returns + + <azeem> actually, pth fails to build right now + <azeem> pth_mctx.c:477: error: request for member '__pc' in something not a structure or union + + <azeem> I know the pth test suite fails (it locks up the machine) or used to fail, so I guess porting work for pth would be needed + <azeem> < marcusb> from reading the pth/PORTING document, porting libpth shouldn't be too hard... + + <youpi> dropped pth [from the channel's topic], as we think we know why it fails (sigaltstack is bogus) diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index ab233dbb..1723d7d3 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -24,3 +25,5 @@ These issues are what Neal Walfield is working on with his new kernel # Examples * [[configure max command line length]] + + * [[zalloc_panics]] diff --git a/open_issues/resource_management_problems/zalloc_panics.mdwn b/open_issues/resource_management_problems/zalloc_panics.mdwn new file mode 100644 index 00000000..09710022 --- /dev/null +++ b/open_issues/resource_management_problems/zalloc_panics.mdwn @@ -0,0 +1,56 @@ +[[!meta copyright="Copyright © 2005, 2007, 2008, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +Written by antrik / Olaf Buddenhagen, last updated: 12 Apr 2007. + +The Hurd sometimes crashes with a kernel panic saying someting like: "Panic: zalloc failed: zone map exhausted". + +These panics are generally caused by some kind of kernel resource exhaustion, but there are several differnt reasons for that. + +It used to happen very often under heavy disk load (like large compile jobs), or in a reproducible test case by opening a large number of ports to /dev/null and then closing them all very quickly. The reason for this particular problem has been identified a while back: The multithreaded Hurd servers create a new worker thread whenever a new request (RPC) comes in while all existing threads are busy. When the server is hammered with lots of requests -- which happens both under heavy disk load, and when quickly closing many ports to one server -- it will create an absurd number of threads, causing the resource exhaustion. + +The Debian hurd package contains a patch by k0ro (Sergio Lopez), which fixes this by limiting the amount of created threads in a rather simplistic but very effective manner. This patch however hasn't been included in upstream CVS so far. A more elegant solution, suitable for upstream inclusion, would be desirable. + +Some panics still seem to happen in very specific situations, like the one described at <https://savannah.gnu.org/bugs/?19426> . These are probably the result of bugs that cause port leaks, accidental fork bombs, or similar problems. + +In principle, resource exhaustion can also happen by normal use, though this is rather unlikely in the absence of bugs or malicious programs. Nevertheless, all these problems could be avoided (or limited in effect) by introducing some limits on number of processes per user, number of threads and ports per process/user etc. + +Trying to track down causes for the panics, I got some interesting results. (UPDATE: Many of my original observations were clearly related to the server thread explosion problem. To avoid confusion, I now removed these, as this is no longer an open issue.) + +* It all started with someone (probably azeem) mentioning that builing some package always crashes Hurd at the same stage of the Debian packaging process (UPDATE: Almost all of these panics when building packages were a result of the thread explosion and don't happen anymore.) +* Someone (maybe he himself) pointed out that this stage is characterized by many processes being quickly created and destroyed +* Someone else (probably hde) started some experimenting, to get a reproducible test case +* He realized that just starting and killing five child processes in quick succession suffices to kill some Hurd systems +* I tried to confirm this, but it turned out my system is more robust + +As I could never reproduce the problem with a small number of quickly killed processes, I can't say whether this problem still exists. While I could reproduce such an effect with first opening and then very quickly closing many ports (which is more or less what happens when quickly killing many processes), I needed really large numbers of processes/ports for that. The thread throtteling patch fixed my test case; but it seems unlikely that killing only five processes could have caused a thread explosion, so maybe hde's observation was a different problem really... + +I started various other experiments with creating child processes (fork bombs), resulting in a number of interesting observations: + +* Just forking a large number of processes crashes the Hurd reliably (not surprising) +* The number of processes at which the panic occurs is very constant (typicallly +-2) under stable conditions, as long as forking doesn't happen too fast +* The exact number depends on various conditions: + * Run directly from the Mach console, it's around 1040 on my machine (given enough RAM); however, it drops to 940 when started through a raw ssh session, and to 990 when run under screen through ssh (TODO: check number of ports open per process depending on how it is started) UPDATE: In a later test, I got somewhat larger numbers (don't remember exactly, but well above 1000), but still very constant between successive runs. Not sure what effected this change. + * It doesn't depend on whether normal user or root + * With only 128 MiB of RAM, the numbers drop slightly (like 100 less or so); no further change between 256 and 384 MiB + * Lowering zone\_map\_size in mach/kern/zalloc.c reduces the numbers (quite exactly half from 8 MiB to 4 MiB) + * There seems to be some saturation near 16 MiB however: The difference between 8 MiB and 16 MiB is significantly smaller + * Also, with 8 MiB or 4 MiB, the difference between console/ssh/screen becomes much more apparent (500 vs. 800, 250 vs. 400) + * With more than 16 MiB, Mach doesn't even boot +* Creating the processes very fast results in a sooner and less predictable crash (TODO: Check whether this is still the case with thread throtteling?) +* Creating processes recursively (fork only one child which forks the next one etc.) results in faster crash +* rpcinfo shows that child processes have more ports open by default, which is very likely the reason for the above observation +* Opening many ports from a few processes doesn't usually cause a system crash; there are only lots of open() failures and translator faults once some limit is reached... Seems the zalloc-full condition is better caught on open() than on fork() (TODO: investigate this further, with different memory sizes, different zone\_map\_size, different kinds of resources using zalloc etc.) +* After opening/leaking lots of ports to /dev/null (32768 it seems), the NULL translator somehow becomes disfunctional, and a new instance is started + +While most of these Observations clearly show an exhaustion of kernel memory which is not surprising, some of the oddities seem to indicate problems that might deserve further investigation. diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn new file mode 100644 index 00000000..ab6af90b --- /dev/null +++ b/open_issues/select.mdwn @@ -0,0 +1,23 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +There are a lot of reports about this issue, but no thorough analysis. + +--- + +IRC, unknown channel, unknown date. + + <paakku> This is related to ELinks... I've looked at the select() implementation for the Hurd in glibc and it seems that giving it a short timeout could cause it not to report that file descriptors are ready. + <paakku> It sends a request to the Mach port of each file descriptor and then waits for responses from the servers. + <paakku> Even if the file descriptors have data for reading or are ready for writing, the server processes might not respond immediately. + <paakku> So if I want ELinks to check which file descriptors are ready, how long should the timeout be in order to ensure that all servers can respond in time? + <paakku> Or do I just imagine this problem? diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn new file mode 100644 index 00000000..1f4de59c --- /dev/null +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -0,0 +1,91 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, unknown channel, unknown date. + + <pinotree> Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2722 + <pinotree> 2722: Credentials: s_uid 1000, c_uid 1000, c_gid 100, c_pid 2724 + <pinotree> \o/ + <youpi> \o/ + <pinotree> the patch is even short, after all: http://paste.debian.net/54795/ + --- a/sysdeps/mach/hurd/sendmsg.c + +++ b/sysdeps/mach/hurd/sendmsg.c + @@ -18,6 +18,7 @@ + + #include <errno.h> + #include <string.h> + +#include <unistd.h> + #include <sys/socket.h> + #include <sys/un.h> + + @@ -45,6 +46,7 @@ + mach_msg_type_number_t amount; + int dealloc = 0; + int i; + + struct sockaddr_storage sa; + + /* Find the total number of bytes to be written. */ + len = 0; + @@ -122,6 +124,34 @@ + err = EIEIO; + } + + + memset (&sa, 0, sizeof (struct sockaddr_storage)); + + if (addr) + + { + + memcpy (&sa, addr, addr_len); + + } + + else + + { + + getsockname (fd, (struct sockaddr *) &sa, &addr_len); + + } + + addr = (struct sockaddr_un *) &sa; + + if (message && (addr->sun_family == AF_LOCAL)) + + { + + struct cmsghdr *cm; + + struct msghdr *m = (struct msghdr *) message; + + for (cm = CMSG_FIRSTHDR (m); cm; cm = CMSG_NXTHDR (m, cm)) + + { + + if (cm->cmsg_level == SOL_SOCKET && cm->cmsg_type == SCM_CREDS) + + { + + struct cmsgcred *cred = (struct cmsgcred *) CMSG_DATA (cm); + + cred->cmcred_pid = __getpid (); + + cred->cmcred_uid = __getuid (); + + cred->cmcred_euid = __geteuid (); + + cred->cmcred_gid = __getgid (); + + cred->cmcred_ngroups = getgroups (sizeof (cred->cmcred_groups) / sizeof (gid_t), cred->cmcred_groups); + + } + + } + + } + + + err = HURD_DPORT_USE (fd, + ({ + if (err) + <youpi> what checks that the pid is correct? + <youpi> and uid, etc. + <pinotree> hm? + <youpi> credential is not only about one claiming to the other his uid & such + <youpi> it's about the kernel or whatever authority tell to an end the identity of the other end + <pinotree> yep + <pinotree> but given that the data is then send to pflocal, this code is the last part that runs on the application side + <youpi> pflocal could as well just request the info from proc + <youpi> it will have to anyway, to check that it's true + <pinotree> hm + <pinotree> yeah, though about that, chose this approach as "quicker" (of course not definitive) + <youpi> well at least it shows we're able to transmit something :) + <pinotree> well it just manipulates the data which gets send nicely already ;) + <youpi> but really, it's most probably up to pflocal to check authentication from proc and give it to the other end + <youpi> the application sender part would be just the RPC authentication calls + <youpi> Mmm, just realizing: so receiver part already exists actually, right? + <youpi> (since it's just about letting the application reading from the message structure) + <pinotree> yep + <youpi> ok, good :) diff --git a/open_issues/sudo_date_crash.mdwn b/open_issues/sudo_date_crash.mdwn new file mode 100644 index 00000000..53303abc --- /dev/null +++ b/open_issues/sudo_date_crash.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, unknown channel, unknown date. + + <grey_gandalf> I did a sudo date... + <grey_gandalf> and the machine hangs diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn new file mode 100644 index 00000000..f1fbb4e0 --- /dev/null +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach open_issue_hurd]] + +\#hurd, 2010, end of May / beginning of June + + [runnign sync, but sill unclean filesystem at next boot] + <slpz> guillem: when libpager syncs an object, it sends an m_o_lock_request and waits (if the synchronous argument was specified) for a m_o_lock_completed. But m_o_lock_completed only means that dirty pages have been sent to the translator, and this one still needs to write them to the backing storage + <slpz> guillem: there's no problem if sync() returns before actually writting the changes to disk, but this also happens when shutting down the translator + <slpz> guillem: in theory, locking mechanisms in libpager should prevent this from happening by keeping track of write operations, but this seems to fail in some situations diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn new file mode 100644 index 00000000..778933a7 --- /dev/null +++ b/open_issues/syslog.mdwn @@ -0,0 +1,7 @@ +IRC, unknwon channel, unknown date. + + <tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 I see that you intend(ed) to use syslog for logging debug messages. I thought I'd point you to http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no idea if that's still an issue or what went wrong at that time. Perhaps you can have a look? + <scolobb> tschwinge: Thanks for information! Currently I'm logging some debug messages to a simple file, but I'll now check whether the issue you've pointed out is still present. + <scolobb> tschwinge: I am getting absolutely abnormal results: when I call syslog() from a simple C program for the first time, the message goes to the system log. However, any further calls to syslog() do just nothing... I am able to send something to syslog only after reboot (it doesn't help if I restart syslogd). + + diff --git a/open_issues/threads_issues.mdwn b/open_issues/threads_issues.mdwn new file mode 100644 index 00000000..aec216e0 --- /dev/null +++ b/open_issues/threads_issues.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +List of issues w.r.t. the Hurd's many-threads paradigm. + +[[!tag open_issue_hurd]] + + * [[fsync]] diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn new file mode 100644 index 00000000..25a74456 --- /dev/null +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -0,0 +1,54 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc open_issue_hurd]] + +\#hurd, freenode, June (?) 2010 + + <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port? + <marcusb> there is a way + <pochu> marcusb: which one would that be? + <marcusb> I forgot + <marcusb> there is an implementation in libc + <marcusb> realpath has a similar job + <marcusb> but that's not what I mean + <marcusb> pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for + <marcusb> maybe it works only for directories + <marcusb> yeah + <marcusb> pochu: check the getcwd() implementation of libc + <marcusb> sysdeps/mach/hurd/getcwd.c + <marcusb> _hurd_canonicalize_directory_name_internal + * pochu looks + <pochu> marcusb: interesting + <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file + <marcusb> right + <pochu> oh you already said that :) + <marcusb> actually, I am not sure that's correct + <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in + <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that + <marcusb> the hurd is strange + <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-) + <marcusb> yep + <pochu> ok. interesting + <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you? + <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip + <marcusb> there you go + <marcusb> or the other way round: would you be surprised if "cat somedir" would work? + <pochu> I think so. if it did, what would it do? + <marcusb> originally, cat dir would list the directory content! + <marcusb> in the old unix times + <pochu> I was surprised the first time I typed `vi somedir` by accident + <marcusb> and some early BSDs + * pochu feels young :-) + <marcusb> he don't worry, I didn't see those times either + <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface + <marcusb> which combines file and directory operations + <marcusb> of course, files and directories implement those functions differently + <antrik> marcusb: do you know why this behavior (cat on directories) was changed? diff --git a/open_issues/translator_environment_variables.mdwn b/open_issues/translator_environment_variables.mdwn new file mode 100644 index 00000000..cae5a494 --- /dev/null +++ b/open_issues/translator_environment_variables.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, unknown channel, unknown date. + + <cfhammar> BTW, is settrans -a supposed to clear all env variables? + <cfhammar> or can I consider it a bug ;-) + <cfhammar> scolobb: yeah, seems the problem is in libfshelp + <scolobb> cfhammar: Are you talking about fshelp_start_translator_long? + <scolobb> (I can remember that it does something to the environment indeed) + <cfhammar> scolobb: yes, I think it's the culprit + <cfhammar> clearing the environment makes sense for passive translators I guess, but not active ones + <scolobb> Hm, searching ``env'' in hurd/libfshelp/start-translator-long.c gives me nothing :-( + <scolobb> I think the problem might be in the fact that fshelp_start_translator_long just doesn't copy the environment, but I may be wrong. + <cfhammar> scolobb: yeah, that's my guess also + <scolobb> Well, I don't know proc, but there might be a way to copy the environment to a task when you know its ID, what do you think? + <scolobb> I can see proc_set_arg_locations in process.defs, which sees to set something connected with environment, but I'm not sure whether it suits your needs. + <cfhammar> scolobb: it seems that the env isn't passed to file_exec in fshelp_start_translator_long + <scolobb> cfhammar: Yeah, that's right + <scolobb> I wonder what could the motivation for not passing the environment to a child process + <cfhammar> hmm... fshelp_start_translator_long parameterizes everything except env... + <cfhammar> perhaps there needs to be a fshelp_start_translator_longer ;-) diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn new file mode 100644 index 00000000..e0828b28 --- /dev/null +++ b/open_issues/translator_stdout_stderr.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +Decide / implement / fix that (all?) running (passive?) translators' output +should show up on the (Mach / Hurd) console / syslog. diff --git a/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn new file mode 100644 index 00000000..5d3c3aab --- /dev/null +++ b/open_issues/translators_O_NOTRANS_O_NOFOLLOW_namespace-based_selection.mdwn @@ -0,0 +1,148 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd open_issue_glibc]] + +bug-hurd email from 2010-07-28: *O_NOTRANS & O_NOFOLLOW* + +2010-07-29, #hurd + + <antrik> cfhammar: I think that touches on a rather fundamental problem... it's always hard to decide how to handle translators, as the most useful approach depends a lot on context + <antrik> this was actually part of the idea behind namespace-based translator selection + <cfhammar> or perhaps we should just drop the whole O_NOFOLLOW == O_NOTRANS and only apply it for link like translators + <pochu> cfhammar: from what I read in [glibc]/hurd/lookup-retry.c, the problem is that some translators can lie about that + <antrik> cfhammar: at some point I considered the possibility of adding a couple of special flags describing translators ("link" and "device" being some, but also introducing a few new ones) to decide standard behaviour in various situations + <pochu> so you can't really know whether they are links without O_NOTRANS + <cfhammar> pochu: yeah, this would have to be considered carefully + <pochu> antrik: care to explain what namespace based translator selection means? :) + <antrik> pochu: the basic idea is that you add special suffixes to the file name during a lookup, which change the behaviour of lookups + <antrik> the most basic use would be adding a suffix that automatically runs an annonymous translator on the file + <cfhammar> antrik: doesn't stat cover most of those flags (except for firmlink i guess) + <antrik> (scolobb mostly implemented that part) + <antrik> but the idea was also to selectively activate/deactivate static translators based on patterns + <antrik> (this is implemented partially, but recursion is completely missing so far) + <antrik> cfhammar: some of them, yes. but I think there are some cases where the standard stat information is not enough to decide on useful handling + <antrik> let's take the example of a translator that mangles the underlying file -- like xmlfs, mboxfs etc. + <antrik> these aren't device file nor links, but should not really be handled like "normal" (store) filesystems either + <antrik> hm... is there any information in the stat that indicates mount points? + <antrik> I guess that would be good enough to flag "normal" filesystems + <pochu> I'm not sure I understand. you add a suffix during a lookup, based on what? whatever, including e.g. flags? + <antrik> pochu: well, an exmple would be "cat foo.gz,,u" + <antrik> where "u" would be a shorthand for "unzip" + <antrik> and it would launch a translator that uncompresses the underlying file + <pochu> what if there are a foo.gz and a foo.gz,,u files? + <antrik> (I think storeio with gzip store can do that... though some more generic translator might be useful, to cover other compression/archieve types as well) + <antrik> pochu: than you are SOL ;-) + <antrik> pochu: I chose ",," as the suffix after some careful examination that this is *extremely* unlikely to occur in normal use + <antrik> pochu: actually, we introduced an escaping scheme too, so it is still possible to access files with ",," in the name... but that's of limited use, as programs not aware of this will still break + <cfhammar> hmm i wonder why glibc handles O_NOFOLLOW to begin with, since the test it does presumes trust in the containing directory the fs could do it just as securely + <antrik> cfhammar: the FS could do what? + <pochu> another problem I've found is that an open(symlink, O_RDONLY | O_NOFOLLOW, 0) should fail with ELOOP according to POSIX, but it doesn't fail on Hurd + <antrik> pochu: yeah, saw that + <antrik> shouldn't be too hard to fix I hope?... + <cfhammar> antrik: libc test whether the node is a symlink or a (trusted) root owned translator, which it would follow + <pochu> antrik: probably not, though I haven't looked at it closely + <antrik> cfhammar: in what situation would the filesystem do the test? + <antrik> cfhammar: and what advantage would it have over the current approach? + <antrik> pochu: OK + <cfhammar> antrik: the point of the test is to approximate symlink vs. mount point but the fs seems to be in a better position to answer this + <antrik> cfhammar: why? I think this information should be fully available to glibc... if it's not, I'd consider this a bug, or at least a major omission + <cfhammar> antrik: well take fifos for instance, they should be considered part of the containing filesystem but would not by glibc + <cfhammar> antrik: we could make an exception in glibc for fifos but not for other future situations in new translators + <cfhammar> antrik: i mean, we could but this leaves control at the translators hand and let different translators handle things their own way + <cfhammar> generally, it seems more flexible to leave policy to servers rather than to bake it into the (implicit) protocol (which glibc implements) + <antrik> cfhammar: I don't see though why handling it in the filesystem would help here... if the filesystem has the information about how the translator should be handled, it can pass it to the clients + <antrik> hm... that's actually a tricky point. we have many situations where we have to choose between handling things in the client library or server-side... I'm haven't really formed an opinion yet which is preferable in general + <pochu> with cfhammar's proposal, you wouldn't need O_NOTRANS when you specify O_NOFOLLOW, right? + <cfhammar> pochu: i don't think my proposal would even work with O_NOTRANS + <antrik> cfhammar: hm, perhaps we are talking past each other. do you want the handling to be in the filesystem containing the underlying node, or in the actual translator implementing the node? + <antrik> hrm + <cfhammar> antrik: the containing filesystem + <cfhammar> (since this is a security issue) + <pochu> yeah, otherwise the trust issue would still be there + <antrik> then why wouldn't it work with O_NOTRANS? + <antrik> BTW, what security issue are you talking about? do you mean the fact that a translator can redirect the lookups to another file, but hide the fact that it's a link? + <pochu> antrik: I mean the O_NOTRANS & O_NOFOLLOW comment in [glibc]/hurd/lookup-retry.c + <cfhammar> antrik: because O_NOTRANS means don't follow translators (including symlinks) and O_NOFOLLOW means don't follow (any) link but do follow translators + <antrik> pochu: I must admit that I never fully understood what that one is about :-) + <cfhammar> antrik: i imagine O_NOTRANS|O_NOFOLLOW == O_NOTRANS + <antrik> cfhammar: I see + <antrik> cfhammar: but I guess that's totally orthogonal from handling in glibc vs. handling in the FS?... + <pochu> AFAIU, it's that if you do an open(translator, O_NOFOLLOW, 0), the translator can lie about it being a symlink. So you need to do an O_NOTRANS lookup + <pochu> hence hurd/hurdlookup.c adds O_NOTRANS if O_NOFOLLOW is present in flags + <antrik> ah, OK + <antrik> so the idea here is that instead of doing that, glibc would only pass on O_NOFOLLOW, and the filesystem would handle the O_NOTRANS part itself + <cfhammar> antrik: if you have O_NOTRANS the filesystem will never follow any translators including non-link ones, so it can't really handle O_NOFOLLOW to exclude link translators + <cfhammar> antrik: yeah + <antrik> AIUI the problem is that with the current scheme, using O_NOFOLLOW will also ignore non-link translators? + <cfhammar> antrik: exactly, including fifos + <cfhammar> antrik: of course, there's still the problem of determining that it is a non-link translator + <antrik> cfhammar: but why can't this be fixed keeping the current scheme? wouldn't it suffice for glibc to ask the filesystem whether there is a link (with O_NOTRANS), and if not, do the actual lookup without O_NOTRANS?... + <pochu> antrik: there's still the problem of translators lying about them being symlinks or not, right? so instead of a blacklist (is it a symlink?) you would need a whitelist + <antrik> pochu: sure. I just don't see how an implementation in the filesystem would do any better on that score than one in glibc + <cfhammar> antrik: the fs is better at maintaining the whitelist, e.g. you could have different whitelist for different translators + <cfhammar> antrik: the fs also knows who own the fs, so it could make exeptions for the owner's translators + <cfhammar> like glibc does for the root user, currently + <antrik> I'm not really convinced so far that having these policies in the filesystem is really preferable to having them in the client-side library... + <cfhammar> antrik: we want to put /hurd/fifo in the whitelist for all users but we can't determine whether an active translator on the underlying node is /hurd/fifo or not, but the FS can if it started the translator itself + <cfhammar> antrik: of course, this can also be done by hiding the /hurd/fifo translator so that glibc doesn't do the test in the first place + <cfhammar> antrik: but this isn't pretty, you'd have to proxy it afaics :-/ + <antrik> cfhammar: TBH, I don't like the whole whilelisting idea + <antrik> seems to me this is really just another manifestation of the infamous firmlink problem + <antrik> as I said in past discussions, I tend to think that the only way to fix it *properly* is changing the way authentification is handled + <antrik> we actually discussed this at some point... when crossing translator boundries, the client shouldn't use it's full permissions on the new translator, but rather the intersection of it's own permissions and that of the parent translator + <antrik> this way, "secret" links should cease to be dangerous... + <cfhammar> yeah, but that'll take way too long for poor pochu ;-) + <antrik> cfhammar: true... but I'm not convinced that a whitelisting hack in the meantime is really worthwhile + <cfhammar> antrik: we already have a whitelisting hack (root user's translators), we're just moving it to the filesystem and adding /hurd/fifo + <antrik> cfhammar: nope, allowing all root translators is a general policy, not a whitelisting hack + <antrik> not elegant either, but a very different class + <cfhammar> antrik: i don't remember the details but fixing firmlink problem seemed to require some fundamental changes, it might even turn out to be unfeasible + <antrik> BTW, it's still not clear to my why the filesystem is supposed to have a better idea which translators to whitelist than glibc?... + <cfhammar> antrik: huh, i don't think i've seen that policy elsewhere, only for root clients not servers + <cfhammar> antrik: for one it can keep track of if the current active translator is the current passive one, and thus know which program it runs + <antrik> do I get it right that in the case of fifo, the client can't generally trust the user running the translator, and thus the idea is instead to trust the translator program?... + <cfhammar> O_NOFOLLOW implies that the client does not trust the file not to redirect it anywhere and we know /hurd/fifo will not do this + <antrik> cfhammar: was that a "yes"?... + <cfhammar> antrik: yes + <antrik> hm... I think I already said it in the context of object migration: I really don't like the idea of trust based on the program being executed... + <antrik> this workaround also has other shortcomings: what if the transaltor is started actively? + <cfhammar> hmm the owner of the translator could hijack it and the fs wouldn't know + <antrik> I must admit though that I don't see another short-term solution either :-( + <antrik> oh, right, that's another problem + <cfhammar> seems like the fs must implement the fifo itself (or atleast hide the /hurd/fifo translator behind a proxy) + <antrik> BTW, what is the specific manifestation of the problem with fifos being ignored on NOFOLLOW? + <pochu> there are two problems + <pochu> one is that with O_NOFOLLOW, it's ext2fs who checks the file permissions, and denies it (dunno the reason for that) + <pochu> the other one is that if you stat the fifo with O_NOFOLLOW and without it, the device will look different (and thus cp believes the file has changed and fails) + <pochu> that's because an stat on the fifo will return the fifo translator's PID as the device + <antrik> ah + <pochu> while one with O_NOFOLLOW will return the partition device + <antrik> so the specific problem here is that the stat info is differenet with the fifo translator than without + <pochu> I'm not sure whether it would be correct & possible to return the device of the parent translator in libtrivfs, instead of the PID + <pochu> yes + <pochu> that, and the permission one (they are different) + <pochu> though both would be solved if O_NOFOLLOW didn't imply O_NOTRANS :) + <antrik> what exactly do you mean by "device" here? + <pochu> I mean st_dev in struct stat + <antrik> well, I wonder whether the permission problem shouldn't actually be considered a bug in fifo. i sthere a good reason why the permissions are not propagated to the underlying node, as with most other translators? + <pochu> I don't think that's the problem + <antrik> what else? + <pochu> it's rather that if you open the fifo with O_NOTRANS, you don't get the underlying node, and then it's ext2fs (and so libdiskfs) who checks the permissions, and it denies them for whatever reason + <pochu> antrik: libdiskfs/dir-lookup.c has this: + <pochu> if (((type == S_IFSOCK || type == S_IFBLK || type == S_IFCHR) + <pochu> >------- && (flags & (O_READ|O_WRITE|O_EXEC))) + <pochu> >------- || (type == S_IFLNK && (flags & (O_WRITE|O_EXEC)))) + <pochu> >-------error = EACCES; + <pochu> so it returns EACCES for the fifo + <pochu> I wonder whether there's a good reason (that I'm missing) for that + <cfhammar> pochu: i think the reason might be that ext2fs denies access because it does not implement those file types itself + <cfhammar> i.e. ext2fs expects them to be opened without O_NOTRANS + <cfhammar> (or opened exclusively for non rwx reasons such as stat or settrans) diff --git a/open_issues/viengoos_make_clean.mdwn b/open_issues/viengoos_make_clean.mdwn new file mode 100644 index 00000000..af2920e7 --- /dev/null +++ b/open_issues/viengoos_make_clean.mdwn @@ -0,0 +1,22 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge: If I do a make clean n the root directory, follow that with a configure, configure fails with: configure: error: C compiler cannot create executables + <neal> this is in config.log: /home/neal/src/hurd-l4/build/lib/gcc/i686-pc-viengoos-gnu/4.2.2/../../../../i686-pc-viengoos-gnu/bin/ld: cannot find -lc + <neal> rt + <tschwinge> neal: Should make clean also remove srcdir/gcc/gcc and binutils, as you do it with newlib? + <neal> I'd prefer it not to + <neal> as I use make clean to prep the tree for new configure changes + <neal> and build gcc takes a long time + <neal> (as does newlib, but newlib in this case needs to be rebuilt) diff --git a/open_issues/viengoos_tls_gcc.mdwn b/open_issues/viengoos_tls_gcc.mdwn new file mode 100644 index 00000000..92499903 --- /dev/null +++ b/open_issues/viengoos_tls_gcc.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_viengoos]] + +IRC, unknown channel, unknown date. + + <neal> tschwinge : I'm trying to enable tls for viengoos. This requires compiling gcc with --enable-tls, which enables threading, which pulls in libpthread, which requires newlib headers. + <neal> tschwinge : Unfortunately, I don't see how to install the newlib headers without having gcc + <neal> tschwinge : Have you got any ideas? diff --git a/open_issues/xen_domu_with_ro_hd.mdwn b/open_issues/xen_domu_with_ro_hd.mdwn new file mode 100644 index 00000000..efbd2d18 --- /dev/null +++ b/open_issues/xen_domu_with_ro_hd.mdwn @@ -0,0 +1,35 @@ +[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Xen domU with a read-only HD"]] + +[[!tag open_issue_xen]] + +read-only hd3 + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 5 + re-open, hd3 count 6 + /dev/hd3 was not cleanly unmounted, check forced. + Pass 1: Checking inodes, blocks, and sizes + Pass 2: Checking directory structure + Pass 3: Checking directory connectivity + Pass 4: Checking reference counts + Pass 5: Checking group summary information + /dev/hd3: 2729/262144 files (0.2% non-contiguous), 34116/524288 blocks + Error writing block 1 (Attempt to write block from filesystem resulted in short write). Ignore error<y>? yes + + foobar:~# e2fsck /dev/hd3 + e2fsck 1.40.11 (17-June-2008) + re-open, hd3 count 7 + re-open, hd3 count 8 + e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/hd3 + Could this be a zero-length partition? |