path: root/hurd/translator
diff options
authorThomas Schwinge <>2013-10-27 19:15:06 +0100
committerThomas Schwinge <>2013-10-27 19:15:06 +0100
commit47e4d194dc36adfcfd2577fa4630c9fcded005d3 (patch)
treed16ffd2eeb74d1977fb3e9744e4a38befedb4ddf /hurd/translator
parentca39ad0592e9b99dac9d99c68bb36ef1d27f72df (diff)
Diffstat (limited to 'hurd/translator')
10 files changed, 1131 insertions, 41 deletions
diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn
index 7fd4832c..10cfb3aa 100644
--- a/hurd/translator/auth.mdwn
+++ b/hurd/translator/auth.mdwn
@@ -8,7 +8,8 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
-The *auth server* (or, *authentification server*).
+The *auth server* (or, *authentification server*) is a key component managing
+[[authentication]] in a Hurd system.
It is stated by `/hurd/init`.
diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn
index e038ba84..95f5ab0c 100644
--- a/hurd/translator/discussion.mdwn
+++ b/hurd/translator/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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,7 +10,8 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_documentation open_issue_hurd]]
-IRC, freenode, #hurd, 2011-08-25:
+# IRC, freenode, #hurd, 2011-08-25
< frhodes> how can I replace an existing running server with a new one
without rebooting?
@@ -23,3 +24,24 @@ IRC, freenode, #hurd, 2011-08-25:
< antrik> in some cases, you might even be able simply to remove the old
translator... but obviously only for non-critical stuff :-)
+# IRC, freenode, #hurd, 2013-10-21
+ <braunr> mhmm, there is a problem with thread destruction
+ <braunr> actually, translator self destruction
+ <braunr> if a request arrives after the last thread servicing a port set
+ returns from mach_msg because of a timeout, but before the translator is
+ detached from its parent, the client will get an error
+ <braunr> it should very rarely happen, but if it does, we could face the
+ same kind of issues we have when a server crashes
+ <braunr> e.g. sshd looping over select() returning EBADF, consuming all cpu
+ <braunr> not sure we want to introduce such new issues
+ <braunr> i don't think i'll be able to make translators disappear reliably
+ ..
+ <braunr> but at least, thread consumption will correctly decrease with
+ inactivity
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index e2f6b044..cfd09502 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -163,6 +163,11 @@ small backend stores, like floppy devices.
<youpi> ok
+#### IRC, freenode, #hurd, 2013-10-08
+ <braunr> ogi: your ext2fs patches were finally merged upstream :)
## Sync Interval
[[!tag open_issue_hurd]]
@@ -209,39 +214,6 @@ That would be a nice improvement, but only after writeback throttling is impleme
<teythoon> tschwinge: well, thanks anyway ;)
-## Increased Memory Consumption
-### IRC, freenode, #hurd, 2013-09-18
- <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
- last updated the hurd package :/
- <braunr> i wonder if my ext2fs large store patches rework have introduced a
- regression
- <braunr> the order of magnitude here is around 1.5G virtual space :/
- <braunr> it used to take up to 3 times less before that
- <braunr> looks like my patches didn't make it into the latest hurd package
- <braunr> teythoon: looks like there definitely is a new leak in ext2fs
- <teythoon> :/
- <braunr> memory only
- <braunr> the number of ports looks stable relative to file system usage
- <teythoon> braunr: I tested my patches on my development machine, it's up
- for 14 days (yay libvirt :) and never encountered problems like this
- <braunr> i've been building glibc to reach that state
- <teythoon> hm, that's a heavy load indeed
- <teythoon> could be the file name tracking stuff, I tried to make sure that
- everything is freed, but I might have missed something
- <braunr> teythoon: simply running htop run shows a slight, regular increase
- in physical memory usage in ext2fs
- <pinotree> old procfs stikes again? :)
- <teythoon> braunr: I see that as well... curious...
- <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
- to make sure that everything is freed, but I might have missed something
- <braunr> how knows, maybe completely unrelated
- <teythoon> the tracking patch isn't that big, I've gone over it twice today
- and it still seems reasonable to me
- <braunr> hm
# Documentation
* <>
diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn
index 857922fc..4132e94a 100644
--- a/hurd/translator/fifo.mdwn
+++ b/hurd/translator/fifo.mdwn
@@ -46,3 +46,9 @@ The *fifo* translator implements named pipes (FIFOs).
<pochu> gg0: got an example?
<gg0> i didn't close it myself
+## IRC, OFTC, #debian-hurd, 2013-10-04
+ <braunr> there is new-fifo, which you can try
+ <braunr> i guess none of us know what it was really meant for
diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn
index 84bacdfb..2b0d1bf7 100644
--- a/hurd/translator/magic.mdwn
+++ b/hurd/translator/magic.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 2013 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
@@ -9,7 +9,13 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
-The magic translator provides `/dev/fd`.
+The `magic` translator returns magic retry results, which are then resolved by
+[[glibc]]'s *name lookup* routines.
+# `/dev/fd`.
$ showtrans /dev/fd
/hurd/magic --directory fd
@@ -20,3 +26,253 @@ individually like this:
$ ls -l /dev/fd/0
crw--w---- 1 bing tty 0, 0 Nov 19 18:00 /dev/fd/0
+# `/dev/tty`
+ $ showtrans /dev/tty
+ /hurd/magic tty
+## Open Issues
+### IRC, OFTC, #debian-hurd, 2013-06-18
+ <XTaran>
+#### IRC, OFTC, #debian-hurd, 2013-06-19
+ <XTaran> youpi: -- Is
+ that realistic? If yes, can someone of you test it? I though would expect
+ that if /dev/tty exists everywhere, it's a chardev everywhere, too.
+ <youpi> that's not impossible indeed
+ <youpi> I've noted it on my TODO list
+#### IRC, OFTC, #debian-hurd, 2013-06-20
+ <pinotree> youpi: wrt the /dev/tty existance,
+ <pinotree> For the build logs, demonstrate that /dev/null and /dev/tty
+ exist:
+ <pinotree> ls: cannot access /dev/tty: No such device or address
+ <youpi> uh?!
+ <youpi> ah, ENODEV
+ <youpi> so that's what we was thinking, no tty -> no /dev/tty
+#### IRC, OFTC, #debian-hurd, 2013-09-20
+ <XTaran> Hi. zsh still FTBFS on Hurd due to some test failure:
+ -- IIRC I checked last
+ time on some porterbox and couldn't reproduce the failure there. Any
+ insight if /dev/tty is not accessible on the buildds inside the chroot?
+ Or is it no character device there? I checked on strauss and there it is
+ a character device.
+ <XTaran> My only other option to debug this (didn't think of that yesterday
+ before the upload unfortunately) would be to override dh_auto_test with
+ "ls -l /dev/tty; dh_auto_test". Do you think that would be helpful?
+ <pinotree> i see /dev/tty on exodar, in the root system and in the chroot
+ <XTaran> pinotree: And it is a character device?
+ <XTaran> ... in both cases?
+ <pinotree> crw--w---- 1 pino tty 0, 0 Sep 20 10:20 /dev/tty
+ <pinotree> yes
+ <XTaran> pinotree: Hrm.
+ <pinotree> (/dev in the chroot is a firmlink to the system /dev, iirc)
+ <XTaran> pinotree: What is a firmlink? :)
+ <XTaran> pinotree: /dev/tty belongs to your user in the example above.
+ <pinotree> something between a (sym)link and an union mount
+ <XTaran> pinotree: Is it possible that /dev/tty is not visible if the
+ buildd runs without a connected terminal?
+ <pinotree> that i'm not sure
+ <XTaran> I see.
+ <pinotree> wouldn't it be possible to skip only that check, instead of the
+ whole test suite?
+ <pinotree> maybe something like
+ <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print)
+ <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c $zerolength ]]
+ / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty ]] (no tty
+ found)' / [[ ! -c $zerolength ]] / fi
+ <pinotree> (never used zsh, so please excuse me if i wrote something silly
+ above)
+ <XTaran> re
+ <XTaran> pinotree: Yeah, sure. That would be one way to get the thing
+ building again, if that's really the cause.
+ <pinotree> i guess it would find any of the available tty* devices
+ <pinotree> it does that for block devices, why not with tty devices, after
+ all? :)
+ <XTaran> pinotree: I just wonder if the failing test is because the test
+ doesn't work properly on that architecture or because it indicates that
+ there is a bug in zsh which only is present on hurd.
+ <pinotree> wouldn't the change proposed above help in determining it?
+ <XTaran> If I'm sure that it's a broken test, I'll try to disable that
+ one. If not I'd report (more details) to upstream. :)
+ <XTaran> pinotree: Oh, indeed.
+ <pinotree> if you get no warning, then a tty device was found with find
+ (using its -type c option), so the failing condition would be a zsh (or
+ maybe something in the stack below) bug
+ <pinotree> with the warning, somehow there were no tty devices available,
+ hence nothing to test -c with
+ <XTaran> So basically doing a check with dash to see if we should run the
+ zsh test.
+ <pinotree> dash?
+ <XTaran> Well, whatever /bin/sh points to. :)
+ <pinotree> ah, do you mean because of $(find ...)?
+ <XTaran> Ah, right, -type c is from find not /bin/sh
+ <XTaran> pinotree: That's my try:
+ <pinotree> o_O
+ <pinotree> isn't that a bit... overcomplicated?
+ <XTaran> pinotree: Yeah, it's a little bit more complicated as the tests
+ itself are not pure shell code but some format on their own.
+ <pinotree> why not the "thing" i wrote earlier?
+ <XTaran> pinotree: Actually it is what I understand you wanted to do, just
+ with more debug output. Or I dunderstood
+ <XTaran> pinotree: Actually it is what I understand you wanted to do, just
+ with more debug output. Or I understood your thing wrongly.
+ <pinotree> <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print)
+ <pinotree> <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c
+ $zerolength ]] / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty
+ ]] (no tty found)' / [[ ! -c $zerolength ]] / fi
+ <XTaran> pinotree: Yeah, I know.
+ <pinotree> that is, putting these lines instead of the current two
+ tty=/dev/tty + following
+ <pinotree> imho that should be fit for upstream
+ <XTaran> pinotree: You mean inside C02cond.ztst?
+ <pinotree> yep
+ <XTaran> pinotree: No, IMHO that's a bad idea.
+ <pinotree> why?
+ <XTaran> pinotree: That file is to test the freshly compiled zsh. I can't
+ rely on their code if I'm testing it.
+ <pinotree> uh?
+ <pinotree> the test above for -b is basically doing the same
+ <XTaran> pinotree: Indeed. Hrm.
+ <pinotree> that's where i did c&p most of it :)
+ <XTaran> So upstream relies on -n in the testsuite before it has tested it?
+ Ugly.
+ <pinotree> if upstream does it, why cannot i too? :D
+ <XTaran> pinotree: You've got a point there.
+ <XTaran> Ok, rethinking. :)
+ <pinotree> otoh you could just move the testcase for -n up to that file, so
+ after that you know it works already
+ <XTaran> pinotree: Well, if so, upstream should do that, not me. :)
+ <pinotree> you could suggest them to, given the -n usage in the -b testcase
+ <XTaran> pinotree: Looks alphabetically sorted, so I guess that's at least
+ not accidentially.
+ <XTaran> pinotree: Ok, you've convinced me. :)
+ <pinotree> :D
+ <XTaran> Especially because this is upstream-suitable once it proved to fix
+ the Hurd FTBFS. :)
+ <XTaran> pinotree: The previous upstream code (laast change 2001) instead
+ of the hardcoded /dev/tty was btw "char=(/dev/tty*([1]))", so I suspect
+ that the find may work on Cygwin, too.
+ <XTaran> s/aa/a/
+ <pinotree> ah, so that's that comment about globbing on cygwin was
+ referring to
+ <XTaran> Yep
+ <pinotree> cool, so incidentally i've solved also that small issue :9
+ <pinotree> :)
+ <XTaran> pinotree: I hope so. :)
+ <XTaran> Then again, I hope, external commands like find are fine for
+ upstream.
+ <pinotree> then they should rework the already existing testcases ;)
+ <XTaran> pinotree: Ah, I fall again for the same assumptions. :)
+ <XTaran> Seems as I would really build test suites with a different
+ approach. :)
+ <pinotree> nothing bad in that, i'd say
+ <XTaran> I'd try to make the tests as far as possible independent from
+ other tools or features to be sure to test only the stuff I want to test.
+ <XTaran> Warning: Not testing [[ -c tty ]] (no tty found)
+ <XTaran> Interesting. I didn't expect that outside a chroot. :)
+ <pinotree> where's that?
+ <XTaran> pinotree: A plain "debuild on my Sid VM.
+ <pinotree> ah
+ <XTaran> Linux, amd64
+ <XTaran> (and Debian of course ;-)
+ <XTaran> pinotree: Ah, my fault, I kept upstreams char= but didn't change
+ it in your code. :)
+ <pinotree> hehe
+ <XTaran> pinotree: Will be included in the next zsh upload. But I don't
+ want to upload a new package before the current one moved to testing (or
+ got an RC bug report to fix :-)
+ <pinotree> oh sure, that's fine
+ <XTaran> pinotree:
+ <XTaran> (I've reverted my previous commit)
+ <pinotree> \o/
+#### IRC, OFTC, #debian-hurd, 2013-09-30
+ <XTaran> Anyone knows why the building of zsh on ironforge restarted? It
+ was at something like "building 4h20m" when I looked last and it now is
+ at "building 1h17m" but there's no old or last log, so it does still look
+ like the first build.
+ <pinotree> most probably got stuck
+ <XTaran> Oh, ok.
+ <XTaran> pinotree: So there are cases where the log is not kept?
+ <pinotree> looks so
+ <youpi> when the machine crashes, yes :)
+ <XTaran> youpi: Ooops. Was that me?
+ <youpi> no, I just rebooted the box
+ <youpi> I didn't easily find which process to kill
+ <XTaran> Ok. Then I'll check back tomorrow morning if pinotree's fix for
+ zsh's test suite on hurd worked. :)
+ <youpi> it seems to be hung on
+ /build/buildd-zsh_5.0.2-5-hurd-i386-vO9pnz/zsh-5.0.2/obj/Test/../Src/zsh
+ <youpi> ../Src/zsh ../../Test/ztst.zsh ../../Test/Y02compmatch.ztst
+ <XTaran> :(
+ <XTaran> At least pinotree's patch worked as it then likely passed
+ C02cond.ztst. :)
+ <XTaran> youpi: For how long? There are multiple tests which take at least
+ 3 seconds per subtest.
+ <youpi> one hour already
+ <XTaran> Ok.
+ <XTaran> That's far too long
+#### IRC, OFTC, #debian-hurd, 2013-10-01
+ <XTaran> pinotree: I've just checked
+ manually: Your fix unfortunately seemed not to help, but another test
+ failed, too, and that one came later and was hence suspected as primary
+ failing issue.
+ <XTaran> pinotree: But "+ find: `/dev/tty': No such device or address"
+ gives some hint. I just have no idea, why find issues that message.
+ * XTaran really wonders how that message can be caused.
+ <XTaran> So find sees /dev/tty, but gets an error if it tries to access
+ (maybe only stat) it while not being connected to a terminal.
+ <XTaran> Bingo: This reproduces the issue (note the missing -t option to
+ ssh): ssh "find /dev/ -nowarn -maxdepth 1 -name 'tty*'
+ -type c -ls"
+ <XTaran> Even clearer: $ ssh "ls -l /dev/" | grep 'tty$'
+ <XTaran> ls: cannot access /dev/tty: No such device or address
+ <XTaran> ?????????? ? ? ? ? ? tty
+ <XTaran> I'd say this is a bug somewhere deep down, either in libc or the
+ kernel.
+ <pinotree> or in the console translator
+ <XTaran> pinotree: Never heard of that so far. :)
+ <XTaran> pinotree: Someone from zsh upstream suggests to use /dev/null or
+ /dev/zero instead of /dev/tty* -- will try that for the next upload.
+ <pinotree> ah right, /dev/null should be standard POSIX
+ <XTaran> I hope so. :)
+ <pinotree> check in POSIX
+ <pinotree> in any case, sorry for the troubles it is giving you...
+ <XTaran> pinotree: I'm more concerned about the hanging second test. I
+ think I can get that test working with using /dev/null.
+ <XTaran> Now that I've understood why the original test is failing.
+ <XTaran> pinotree: Shall I write a bug report for that issue? If so,
+ against which package?
+ <pinotree> XTaran: not sure it is worth at this stage, having a clearer
+ situation on what happens could be useful
+ <pinotree> it is something that can happen sporadically, though
+ <XTaran> pinotree: Well, it seems a definitely unwanted inconsistency
+ between what the directory listing shows and which (pseudo) files are
+ accessible. Independently of where the bug resides, this needs to be
+ fixed IMHO.
+ <pinotree> sure, nobody denies that
+ <XTaran> pinotree: I'd call it easily reproducible. :)
+ <pinotree> not really
+ <XTaran> ... once you know where to look for.
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 0734e1e6..973fb938 100644
--- a/hurd/translator/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -2103,7 +2103,245 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
<youpi> anyway, got to run
-## IRC, freenode, #hurd, 2013-09-20
+## Memory Leak
+### IRC, freenode, #hurd, 2013-09-18
+ <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+ last updated the hurd package :/
+ <braunr> i wonder if my ext2fs large store patches rework have introduced a
+ regression
+ <braunr> the order of magnitude here is around 1.5G virtual space :/
+ <braunr> it used to take up to 3 times less before that
+ <braunr> looks like my patches didn't make it into the latest hurd package
+ <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+ <teythoon> :/
+ <braunr> memory only
+ <braunr> the number of ports looks stable relative to file system usage
+ <teythoon> braunr: I tested my patches on my development machine, it's up
+ for 14 days (yay libvirt :) and never encountered problems like this
+ <braunr> i've been building glibc to reach that state
+ <teythoon> hm, that's a heavy load indeed
+ <teythoon> could be the file name tracking stuff, I tried to make sure that
+ everything is freed, but I might have missed something
+ <braunr> teythoon: simply running htop run shows a slight, regular increase
+ in physical memory usage in ext2fs
+ <pinotree> old procfs stikes again? :)
+ <teythoon> braunr: I see that as well... curious...
+ <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+ to make sure that everything is freed, but I might have missed something
+ <braunr> how knows, maybe completely unrelated
+ <teythoon> the tracking patch isn't that big, I've gone over it twice today
+ and it still seems reasonable to me
+ <braunr> hm
+### IRC, freenode, #hurd, 2013-09-25
+ <braunr> seems like a small leak per file access
+ <braunr> but htop makes it obvious because it makes lots of them
+ <braunr> shouldn't be too hard to find
+ <braunr> since it might also come from the large store patch, i'll take a
+ look at it
+### IRC, freenode, #hurd, 2013-09-27
+ <braunr> teythoon: found the leak :)
+ <braunr> although its origin is weird
+ <teythoon> braunr: where is it?
+ <braunr> i'm still building packages to make sure that's it
+ <braunr> see
+ <braunr> which you changed in
+ <braunr> line 306 is "return error" instead of "goto out"
+ <braunr> has been so since 1994
+ <braunr> what is unclear is why this code path is now run
+ <braunr> patch is here:
+ <teythoon> I see, weird indeed
+ <braunr> teythoon: the system also feels slower somehow
+ <braunr> such errors might have introduced unexpected retries
+ <teythoon> i think it's possible to write a coccinelle patch to find such
+ errors
+### IRC, freenode, #hurd, 2013-09-28
+ <youpi> braunr: bah, I havent noticed the leak on my box, even after
+ building eglibc & hurd several times
+ <braunr> that's weird
+ <braunr> are you sure it's up to date ?
+ <braunr> also, is procfs correctly attached to /proc ?
+ <braunr> that's what seems to trigger it
+ <youpi> yes, 20130924-2, with procfs on /proc
+ <teythoon> braunr: that turned out to be the leak indeed? and somehow my
+ changes triggered it? did you discover why?
+ <braunr> teythoon: yes, yes, no
+ <braunr> but youpi didn't see the leak on his system
+ <teythoon> ^^ cool that you found it
+ <teythoon> I did
+ <braunr> oh yes you mean you saw the leak
+ <teythoon> yes
+### IRC, freenode, #hurd, 2013-10-01
+ <braunr> the fix i did in libdiskfs might have fixed other issues
+ <braunr> apparently, it's the code path taken when error isn't ENOENT,
+ including no error (translator started)
+ <pinotree> the memory leak fix, you mean?
+ <braunr> yes
+ <braunr> it might haved fixed reference counting too
+ <braunr> although i'm not sure if we actually ever run into that issue in
+ the past
+ <braunr> the weird thing is, that path is taken when starting a passive
+ translator
+ <braunr> (i think)
+ <braunr> (it might be any kind of translator, and just doing nothing if
+ alcready active)
+ <braunr> already*
+ <braunr> anyway, the fact that the leak was so visible means this code was
+ run very often
+ <braunr> which doesn't make sense
+ <braunr> hm ok, it seems that code was run every time actually
+ <braunr> but the leak became visible when it concerned memory
+ <pinotree> which side-effects did the old code produce?
+ <braunr> teythoon added a dynamically allocated path that wasn't freed
+ <braunr> reference leaks
+ <braunr> which might explain the assertion on reference we sometimes see
+ with ext2fs
+ <braunr> when a counter overflows and becomes 0
+ <pinotree> hmm
+ <braunr> which is why i'm mentioning it
+ <braunr> :)
+ <braunr> i'll try to reproduce the assertion
+ <pinotree> libdiskfs/node-drop.c: assert (np->dn_stat.st_size == 0); ←
+ this one?
+ <braunr> yes
+ <braunr> hm no
+ <pinotree> oho
+ <braunr> no, not that one
+ <pinotree> no-oho
+ <braunr> well maybe by side effect
+ <braunr> but i doubt it
+ <pinotree> iirc you constantly get that when building ustr
+ <braunr> (e.g., because the object was freed and reallocated quickly,
+ st_size has been reset, something like that)
+ <braunr> is ustr a package ?
+ <pinotree> yes
+ <braunr> ok
+ <braunr> thanks
+ <braunr> pinotree: indeed, it's still present
+ <braunr> pinotree: actually, after a more in-depth look, reference counting
+ looks valid before the fix too
+ <pinotree> ok, thanks for checking
+ <braunr> pinotree: the assertion affects the root translator, and is
+ triggered by a test that stresses memory
+ <pinotree> memory as in ram, or as in disk storage?
+ <braunr> malloc
+ <pinotree> ok
+ <braunr> i suspect the code doesn't handle memory failure well
+ <pinotree> iirc the ustr tests are mostly disk-intensive
+ <braunr> this one is really about enonmem
+ <braunr> enomem
+ <braunr> i'll make ext2fs print a stack trace
+ <pinotree> (might be wrong, but did not investigate further, sorry)
+ <braunr> no worries
+ <braunr> i'm doing it now :)
+### IRC, freenode, #hurd, 2013-10-02
+ <braunr> i've traced the problem up to truncate
+ <braunr> which gets a negative size
+ <braunr> shouldn't take long to find out where it comes from now
+ <pinotree> it seems our truncate doesn't handle negative values well though
+ <braunr> EINVAL The argument length is negative or larger than the
+ maximum file size.
+ <braunr> i still have to see whether it comes from the user (unlikely) or
+ if it's an internal inconsistency
+ <braunr> i suspect some code wrongly handles vm_map failures
+ <braunr> leading to that inconsistency
+ <braunr> pinotree: looks like glibc doesn't check for length >= 0
+ <pinotree> yeah
+ <braunr> servers should do it nonetheless
+ <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both?
+ <braunr> it appears a client does the truncate
+ <braunr> i'd say both
+ <braunr> can you take the glibc part ? :)
+ <pinotree> i was going to do the hurd part... :p
+ <pinotree> ok, i'll pick libc
+ <braunr> well i'm doing it already
+ <braunr> i want to write a test case first
+ <braunr> to make sure that's the problem
+ <pinotree> already on the hurd part, you mean?
+ <braunr> yes
+ <pinotree> ok
+ <braunr> ok looks like it
+ <pinotree> would you share the test you are doing, so i don't need to write
+ it again? :)
+ * pinotree lazy
+ <braunr> :)
+ <braunr> as soon as darnassus is restarted
+ <pinotree> ideally we could have some repository with all the testcases
+ written over time to fix bugs in implementations/compatibility/etc
+ <braunr> i noticed the system doesn't automatically reboot when e2fsck says
+ reboot, and no unexpected inconsistency was found
+ <braunr> is that normal ?
+ <pinotree> or having something like posixtestsuite, but actively maintained
+ <braunr> pinotree: polishing the test before sending it
+ <pinotree> sure, no hurry :)
+ <braunr> i can't reproduce the assertion but it does make ext2fs freeze
+ <braunr> pinotree:
+ <pinotree> merci
+ <braunr> pinotree: ustr builds
+ <pinotree> wow
+ <braunr> the client code (ustr) seems to perform a ftruncate with size
+ ((size_t)-1) whereas lengths are signed ..
+ <braunr> i'll check other libraries and send a patch soon
+ <teythoon_> braunr: btw, did you fix the leak?
+ <braunr> yes
+ <braunr>
+ <braunr> 1h after tagging 0.5 (
+ <braunr> :(
+ <teythoon> ah yes, I've seen that commit
+ <teythoon> I just wanted to know whether this settled the issue
+ <braunr> it does :)
+ <teythoon> good
+ <braunr> i still can't figure out why youpi didn't had it
+ <braunr> the code path is run when no error (actually error != ENOENT)
+ <braunr> which explains why the leak was so visible
+ <teythoon> so my patch exposed this b/c of the allocation I added, makes
+ sense
+ <teythoon> it's funny actually, b/c this wasn't an issue for me as well, I
+ had my development vm running on that patches for two weeks
+### IRC, freenode, #hurd, 2013-10-03
+ <braunr> youpi: i've committed a fix to hurd that checks for negative sizes
+ when truncating files
+ <braunr> this allows building the ustr package without making ext2fs choke
+ on an assertion
+ <braunr> pinotree is preparing a patch for glibc
+ <braunr> see truncate/ftruncate
+ <braunr> with an off_t size parameter, which can be negative
+ <braunr> EINVAL The argument length is negative or larger than the
+ maximum file size.
+ <braunr> hurd servers were not conforming to that before my change
+## Multiple mtab Translators Spawned
+### IRC, freenode, #hurd, 2013-09-20
<braunr> teythoon: how come i see three mtab translators running ?
<braunr> 6 now oO
@@ -2113,10 +2351,250 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
<braunr> teythoon: more bug fixing for you :)
-## IRC, freenode, #hurd, 2013-09-23
+### IRC, freenode, #hurd, 2013-09-23
<teythoon> so it might be a problem with either libnetfs (which afaics has
never supported passive translator records before) or procfs, but tbh I
haven't investigated this yet
+### IRC, freenode, #hurd, 2013-09-26
+ <braunr> teythoon: hum, i just saw something disturbing
+ <braunr> teythoon: to isolate the leak, i created my own proc directory
+ <braunr> and the mtab translators it spawns seem to be owned by root oO
+ <teythoon> braunr: but how is that possible? are you sure? have you checked
+ with 'ids'?
+ <braunr> no i'm not sure
+ <braunr> also, ext2fs seems to ignore --writable when started as a passive
+ translator
+ <braunr> < teythoon> braunr: but how is that possible?
+ <braunr> messup with passive translators i guess
+ <braunr> teythoon: actually, it looks like it has effective/available id
+ <braunr> it has no*
+ <braunr> this feature doesn't map well in unix
+ <teythoon> braunr: ah yes, htop doesn't handle this well and shows root
+ indeed, our ps shows - as username
+ <braunr> yes
+### [[!debbug 724868]]
+### IRC, freenode, #hurd, 2013-10-03
+ <braunr> i can't manage to find out where the hurd stores information about
+ active translators ...
+ <braunr> there is this transbox per node
+ <braunr> but where are nodes stored ?
+ <braunr> what if they are are dropped ?
+ <pinotree> braunr: iirc, see libfshelp
+ <braunr> well i have
+ <braunr> i still can't find it
+ <braunr> i fear that it works for ext2fs because that particular translator
+ implements a cache of open nodes
+ <braunr> whereas things like procfs drop and recreate nodes per open
+ <braunr> which would be the root cause for the multiple mtab bug
+ <pinotree> doesn't tmpfs support translators?
+ <braunr> good idea
+ <braunr> although it's still a libdiskfs based one
+ <braunr> no problem for tmpfs, so it would be a netfs/procfs issue
+ <braunr> better than what i feared :)
+ <braunr> now, how is libdiskfs able to find active translators ..
+ <braunr> ah, there is a name cache in libdiskfs ..
+ <braunr> nope, looks fine
+### IRC, freenode, #hurd, 2013-10-04
+ <braunr> nodes with a translator seem to keep a reference in libdiskfs and
+ not in libnetfs
+ <braunr> mhmmpf
+ <braunr> oh great ..
+ <braunr> each libdiskfs that "works" seems to implement its own
+ diskfs_cached_lookup function
+ <braunr> so both ext2fs and tmpfs actually maintain a list of nodes,
+ keeping a reference on those with a translator
+ <braunr> while procfs simply doesn't
+ <braunr> teythoon: ^
+ <braunr> *sigh*
+ <teythoon> braunr: ok, thanks, I'll look into that
+ <braunr> i'm not sure how to fix it
+ <braunr> we can either fix node destruction to cleanly shut down
+ translators
+ <braunr> but this would mean starting mtab on each access
+ <braunr> or we could implement a custom cache in procfs
+ <braunr> or perhaps a very custom change in the lookup callback for mounts
+ <braunr> i'll try the latter
+ <teythoon> err, shouldn't we try to fix this in lib*fs?
+ <braunr> unless you really want to work on it
+ <braunr> i dont' know
+ <teythoon> ah, so the node is destroyed but the translator is kept running?
+ that's what you mean by the above?
+ <teythoon> and ext2fs makes an effort of killing it in its node cleanup
+ code?
+ <braunr> yes
+ <braunr> grmbl, i'm lagging a lot
+ <braunr> i'm not sure
+ <braunr> ext2fs maintains it
+ <braunr> with ext2fs, translators can only be explicitely removed
+ <braunr> i mean, ext2fs keeps all node descriptors alive once accessed
+ <braunr> while procfs doesn't
+ <braunr> teythoon: ok, looks like i have a working patch that merely caches
+ the node for mounts
+ <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a
+ translator
+ <braunr> i'll fix it too
+ <braunr> i installed my fixed procfs on darnassus, only one mtab :)
+ <teythoon> nice :)
+ <braunr> now, why is there no /home in df output ?
+ <teythoon> not sure
+ <teythoon> note how /dev/tty* end up in /proc/mounts, those are passive
+ translators too, no?
+ <braunr> yes
+ <braunr> but that's a good thing i guess
+ <braunr> or was mounts intended for file systems only ?
+ <braunr> well, in the unix traditional meaning
+ <teythoon> I think its nice too, yes
+ <teythoon> but why are they fine and your /home is not...
+ <braunr> that's weirder
+ <braunr> also, mounts actually doesn't show passive translators
+ <braunr> teythoon: does your code perform any kind of comparison ?
+ <braunr> i see /servers/socket/26 but not /servers/socket/2
+ <braunr> s/comparison/filter/g
+ <teythoon> hmm
+ <teythoon> well, yes, try /hurd/mtab --insecure /
+ <teythoon> (I cannot connect to darnassus from here...)
+ <braunr> ok but that looks unrelated
+ <braunr> both /servers/socket/26 and /servers/socket/2 refer to the same
+ translator
+ <braunr> i was wondering if mtab was filtering similar entries based on
+ that
+ <teythoon> no
+ <braunr> that's weird too then, isn't it ?
+ <teythoon> yes ;)
+ <braunr> ok
+ <teythoon> btw, how is that done with the same traanslator being bound to
+ two nodes? settrans cannot do that, can it?
+ <braunr> no it can't
+ <braunr> the translator does it when started
+ <teythoon> ah
+ <braunr> (which means there is a race if both are started simulatneously,
+ although it's very rare and not hard to solve)
+ <teythoon> a weird beaving translator then :)
+ <braunr> i have a fix for the multiple mtab issue, will send a patch
+ tonight
+ <braunr> teythoon: if ext2fs is set active, mtab output reports it
+ <braunr> teythoon: looks like this bug is what allows mtab not to deadlock
+ <braunr> teythoon: when i attach it as an active translator, cat freezes
+ <braunr> teythoon: if (control && control->pi.port_right == fsys)
+ <braunr> that's the filtering i was previously talking about
+ <braunr> oh please don't name global variables "path" ...
+ <braunr> youpi: i fixed procfs on ironforge and exodar to be started as
+ procfs -c -k 3
+ <braunr> without -k 3, many things as simple as top and uptime won't work
+### IRC, freenode, #hurd, 2013-10-06
+ <antrik> teythoon: pty-s also bind to two nodes, not only pfinet
+### IRC, freenode, #hurd, 2013-10-07
+ <braunr> teythoon: please tell us when you're available, we need to work
+ out the last mtab issues
+ <teythoon> braunr: I'm available now :)
+ <teythoon> I'm sorry, I've been very busy the last two weeks, but I've
+ plenty of time now
+ <braunr> great :)
+ <braunr> did you see youpi's mail ?
+ <braunr> i have the exact same question
+ <teythoon> I did
+ <braunr> it seems your code registers active translators
+ <braunr> but parent translators don't seem to register them when they're
+ created from passive translators
+ <braunr> or am i mistaken ?
+ <teythoon> I'll need a moment to get my hurd machine and myself up to
+ speed...
+ <teythoon> braunr: I concur with youpi, hooking into fshelp_fetch_root
+ should do just fine
+ <teythoon> I'll just try that
+ <braunr> ok
+ <braunr> how do you deal with mtab reporting itself ?
+ <teythoon> o_O does it do that?
+ <braunr> no, but it should
+ <braunr> when i set it as an active translator, i get a deadlock
+ <braunr> hm
+ <braunr> teythoon: before you change libfshelp, i'd like you to try
+ something else
+ <braunr> use more appropriate names for global variables in mtab.c
+ <braunr> in particular, the variable path clashes with local names
+ <teythoon> noted
+ <braunr> teythoon: as a side note (i'm not asking to rewrite anything)
+ <braunr> i strongly recommend a very explicit object oriented style of
+ coding
+ <braunr> (or data-oriented as it's sometimes called)
+ <braunr> use prefixes for all your interfaces so they can be made public if
+ needed (which acts as a namespace and avoids lots of collisions
+ naturally)
+ <braunr> use "constructors" and "destructors" (functions that both allocate
+ and initialize)
+ <braunr> this helps avoiding leaks a lot too
+ <teythoon> hm, I thought I did that, could you be more specific?
+ <braunr> ok didn't see the comment
+ <braunr> /* XXX split up */ error_t mtab_populate (...
+ <braunr> :)
+ <braunr> as a better example, see your code in libfshelp/translator-list.c
+ <braunr> struct translator should have been treated as an object
+ <braunr> this would probably have completely avoided any leaks in the first
+ place
+ <teythoon> braunr: right, I deviated from that style there
+ <braunr> teythoon: these are minor details, don't mind them too much, i
+ just find it helps me a lot
+ <teythoon> braunr: sure, I appreciate the feedback :)
+### IRC, freenode, #hurd, 2013-10-08
+ <teythoon> braunr: I'm on to the passive translator not getting registered
+ issue
+ <teythoon> however, removing them from the list if the active translator is
+ killed does not work as expected... I still need to fiddle with the
+ notifications to get this right
+ <braunr> ok
+### IRC, freenode, #hurd, 2013-10-16
+ <teythoon> braunr: btw, I fixed the 'passive translator not showing up in
+ proc/mounts'-issue
+ <teythoon> but 4 ports do leak each time a translator is killed and
+ reinstalled
+ <teythoon> this happens with passive ones as well as active ones
+ <braunr> teythoon: is that issue tied to your changed ?
+ <braunr> changes*
+ <teythoon> I'm not sure tbh, testing that is on my list of things to do
+ <braunr> ok
+ <braunr> first thing to know i guess
+ <teythoon> yes
+## Memory Leak in `translator_ihash_cleanup`
+### IRC, freenode, #hurd, 2013-10-04
+ <braunr> teythoon: isn't there a leak in translator_ihash_cleanup ?
+ <teythoon> braunr: looks like, yes
+ <teythoon> braunr: I probably forgot to add the free (element->name) when I
+ added the name field
+ <braunr> teythoon: ok
+ <braunr> teythoon: i let you fix that :p
+ <teythoon> braunr: sure ;)
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
index d5e0960c..75bfb8fd 100644
--- a/hurd/translator/proc.mdwn
+++ b/hurd/translator/proc.mdwn
@@ -63,6 +63,35 @@ It is stated by `/hurd/init`.
something special
+## IRC, freenode, #hurd, 2013-09-25
+ <braunr> so nice to finally see proc in top :)
+ <braunr> hm cute, htop layout has become buggy, top just won't start
+ <teythoon> braunr: make sure your procfs knows the correct kernel pid
+ <teythoon> # showtrans /proc
+ <teythoon> /hurd/procfs -c -k 3
+ <teythoon> we could have handled this nicer if procfs were integrated
+ upstream
+ <teythoon> we should probably just update the default
+ <braunr> teythoon: mhm
+ <braunr> $ fsysopts /proc
+ <braunr> /hurd/procfs --stat-mode=444 --fake-self=1
+ <braunr> $ showtrans /proc
+ <braunr> /hurd/procfs -c
+ <pinotree> -c == --stat-mode=444 --fake-self=1
+ <braunr> better indeed
+ <braunr> teythoon: thanks
+## IRC, freenode, #hurd, 2013-10-24
+ <gg0> braunr: i'm using your repo and i can't see cpu percentage in htop
+ anymore, all zeroes, confirmed?
+ <braunr> gg0: no
+ <braunr> gg0: you probably need to reset procfs
+ <braunr> gg0: settrans /proc /hurd/procfs -c -k 3
# Process Discovery
## IRC, freenode, #hurd, 2013-08-26
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index fc071337..018db7b2 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -436,6 +436,72 @@ Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for
`#ifdef __linux__`.
+### IRC, freenode, #hurd, 2013-10-03
+ <camm`> what's the equivalent of cat /proc/self/maps on hurd?
+ <braunr> camm`: for now, /proc/self doesn't work as expected
+ <camm`> thanks, I just want to get a list of maps and protection status for
+ a running process -- how?
+ <braunr> vminfo
+ <camm`> thanks so much! I'm trying to debug an unexec failure on hurd when
+ a linker script is present. All works with the default script, but when
+ the text address is changed, unexec fails, running into a page with no
+ access in the middle of the executable: 0xc4b000[0x1000] (prot=0,
+ max_prot=RWX, offs=0xb55000)
+ <camm`> I get a segfault when trying to read from this page.
+ <braunr> unexec ?
+ <camm`> emacs/gcl/maxima/acl2/hol88/axiom use unexec to dump a running
+ image into a saved executable elf file.
+ <braunr> what is unexec ?
+ <braunr> ok looks like a dirty tool
+ <braunr> camm`: what is segfaulting, unexec or the resulting executable ?
+ <camm`> unexec opens the file from which the running program was originally
+ executed, finds its section start addresses, then writes a new file
+ replacing any data in the old file with possibly modified versions in
+ running memory. The reverse of 'exec'.
+ <camm`> the read from running memory delimited by the addresses in the
+ executable file is hitting a page which has been protected with *no*
+ access, and is segfaulting. Somehow, when the binary file is loaded,
+ hurd turning off all rights to this page.
+ <camm`> let me check the stack location ...
+ <camm`> ok I think I've got it -- hurd moves the sbrk(0) address away from
+ the end of .data (as reported by readelf) if the addresses are low,
+ presumably to avoid running into the stack.
+ <camm`> starting sbrk(0)! on hurd
+ <braunr> i'm not sure there is anything like the heap on the hurd
+ <braunr> sbrk is probably implemented on top of mmap
+ <braunr> camm`: hm no, i'm wrong, glibc implements brk and sbrk mostly as
+ expected, but remapping the area isn't atomic
+ <braunr> "Now reallocate it with no access allowed"
+ <braunr> then, there is a call to vm_protect
+ <braunr> and no error checking
+ <braunr> ...
+ <camm`> ok, that's fine, but need to know -- in general there is no
+ relationship between the address returned by sbrk(0) and the .data
+ addresses reported by readelf on the file, (hurd only) yes?
+ <braunr> i don't know about that
+ <braunr> there should be ..
+ <camm`> Specific example: readelf -a -> [24] .data PROGBITS
+ 000f5580 0c4580 000328 00 WA 0 0 32
+ <camm`>
+ <camm`> sbrk(0)->(void *) 0x8021000
+ <braunr> camm`: is that on an executable or a shared object ?
+ <camm`> executable
+ <braunr> 000f5580 looks very low
+ <camm`> This is using a linker script. The default setup works just fine.
+ <camm`> I think it (might) make sense for hurd to silently do this give the
+ placement of the C stack, but the assumptions behind my algorithm need
+ changing (perhaps).
+ <camm`> (I probe in configure the allowable range of __executable_start,
+ and then choose a value to either ensure a large free signed range around
+ NULL, or a low data start to maximize heap)
+ <camm`> braunr: are there any guarantees of sbrk(0) without a
+ linker script?
+ <braunr> camm`: i'm not sure at all
+ <braunr> sbrk isn't even posix
+ <camm`> thanks
# `/proc/[PID]/mem`
Needed by glibc's `pldd` tool (commit
@@ -471,3 +537,19 @@ Needed by glibc's `pldd` tool (commit
<braunr> both htop and top seem to have problems report the cpu time
<braunr> so i expect the problem to be in procfs
+# IRC, freenode, #hurd, 2013-10-03
+ <braunr> teythoon: any reason the static variable translator_exists isn't
+ protected by a lock in procfs/rootdir.c ?
+## IRC, freenode, #hurd, 2013-10-04
+ <braunr> teythoon: can you tell me why translator_exists isn't protected
+ from shared access in rootdir_mounts_exists ?
+ <teythoon> braunr: hm, dunno tbh, I probably thought the race was harmless
+ enough
+ <braunr> it probably is
+ <braunr> settrans -Rg doesn't work on procfs :(
diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn
new file mode 100644
index 00000000..667677a7
--- /dev/null
+++ b/hurd/translator/term.mdwn
@@ -0,0 +1,207 @@
+[[!meta copyright="Copyright © 2013 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
+The *term* translator implements POSIX termios discipline.
+# Open Issues
+## [[open_issues/Term_Blocking]]
+## Leaks/Not Re-used/Not Terminating
+[[!tag open_issue_hurd]]
+### IRC, freenode, #hurd, 2013-10-14
+ <braunr> good news
+ <braunr> the terminal leak is related to privilege separation
+ <atheia> I love how, as an unknowing by-stander, that is somehow good news
+ :-)
+ <braunr> :)
+ <braunr> it's a good news because 1/ we have more knowledge about the issue
+ <braunr> and 2/ it may not even be a hurd bug
+ <braunr> but rather an openssh-on-hurd bug
+ <braunr> this explains why i didn't see the issue on anything else
+ (mach/hurd consoles, x terminals)
+ <braunr> and this will also indirectly solve the screen lockup issue
+ <teythoon> braunr: good catch :)
+ <braunr> s/a good news/good news/
+ <atheia> ah, yes, both definitely good news. Congrats on the progress.
+ <braunr> i remember we used to disable privilege separation in the past
+ <braunr> i'll have to dig what made us use it
+ <braunr> interesting, screen seems to be affected nonetheless
+ <braunr> so it's something common to both screen and ssh privsep
+ <braunr> apparently, what sshd+privse and screen have in common is a fifo
+ <braunr> so it's probably a tricky hurd bug actually
+### IRC, freenode, #hurd, 2013-10-16
+ <braunr> pflocal is leaking ports ..
+ <braunr> this might be what blocks terminals
+ * pinotree gives braunr a stick of glue
+ <braunr> thanks
+ <braunr> pflocal leaks struct sock ..
+ <braunr> grmbl
+ <braunr> hm nice, pflocal leaks each time a socket is bound and/or accepted
+ on
+ <braunr> looks like a simple ref mess
+ <pinotree> braunr: really?
+ <braunr> yes
+ <pinotree> a leak in pflocal feels strange, never noticed it taking lots of
+ memory (and it's used a lot)
+ <braunr> it's a port leak
+ <braunr> well
+ <braunr> no it's both a memory and port leak
+ <braunr> not sure which one is the root cause yet
+ <braunr> i guess server sockets aren't automatically unbound
+ <braunr> if you want to see the leak, just disable priv separation in ssh
+ (to avoid the terminal leak ....) and write a shell loop to start ssh
+ your_server echo hello
+ <braunr> google shows mails about the leak in the past
+ <braunr> i also hope it fixes the terminal leak, although i'm really not
+ sure :(
+### IRC, freenode, #hurd, 2013-10-17
+ <braunr> hm nice, apparently, there is no pflocal leak
+ <braunr> but a libdiskfs one !
+ <braunr> since ext2fs enables the ifsock shortcut
+ <braunr> seems like it leaks a reference on sock node deletion
+ <teythoon> braunr: have you looked at libdiskfs/dead-name.c?
+ <teythoon> braunr: I think I'm hunting a very similar problem
+ <braunr> i'm doing it now
+ <teythoon> I had the problem of dead name notifications not being delivered
+ <braunr> wow
+ <teythoon> b/c I held no reference to the ports_info thing, so the dead
+ name handler in libports could no longer find the pi struct, so the
+ notification was silently dropped
+ <braunr> i see
+ <braunr> but it looks like dropping a node makes sure the associated
+ sockaddr has been deleted if any
+ <teythoon> are you sure the node is dropped in the first place?
+ <braunr> no
+ <braunr> well
+ <braunr> i see something happenning at the pflocal side when removing the
+ node
+ <braunr> but there is still a send right lingering somewhere
+ <braunr> (see why we need a global lsof :p)
+ <teythoon> indeed
+ <braunr> i'll try portinfo with that option we talked about
+ <teythoon> yes
+ <braunr> 121 => 1682: send (refs: 1)
+ <braunr> yep, ext2fs still has it
+ <teythoon> (I wonder how portinfo does that...)
+ <braunr> i guess it imports rights from the target task
+ <braunr> and see if it gets the same name as a local right
+ <teythoon> makes sense
+ <braunr> easy to check
+ <teythoon> well, no, it cannot do that for receive rights
+ <braunr> it creates an empty task just for that purpose
+ <braunr> and uses mach_port_extract_right
+ <teythoon> but it works as you described, yes
+ <braunr> so yes it does work for receive rights too
+ <teythoon> yes
+ <teythoon> cool :)
+ <braunr> so it assumes identical port names are part of the ipc interface
+ <braunr> something neal said we shouldn't rely on
+ <braunr> iirc
+ <teythoon> yes, I remember something like that too
+ <braunr> here is the strange thing
+ <braunr> node->sockaddr is deallocated on a dead name notification
+ <braunr> drop_node checks that sockaddr is null
+ <braunr> so how can the dead name notification occur before the node is
+ dropped ?
+ <braunr> so maybe the node is still around indeed
+ <braunr> apparently, libdiskfs considers the address holds a reference on
+ the node
+ <braunr> on the other hand, the server socket won't get released unless the
+ address gets a no-sender notification ...
+ <braunr> this should probably be turned into a weak reference
+ <braunr> teythoon: indeed, the node is leaked
+ <braunr> pflocal crashes when removing correctly deallocating addresses and
+ removing server sockets :/
+ <braunr> ok, pflocal bug fixed
+ <braunr> still have to fix the libdiskfs leak
+ <braunr> and libdiskfs leak fixed too
+ <braunr> :)
+ <braunr> i'll build hurd packages with my changes to make sure i don't
+ break something before comitting
+ <braunr> and see if this fixes the term issue
+ <braunr> looks like my patches work just fine :)
+ <braunr> it doesn't solve the term issue though
+ <braunr> so, according to portinfo, pflocal has send rights to terminals oO
+ <braunr> mhhhmmmmmm
+ <braunr> openssh seems to pass terminal file descriptors through unix
+ sockets when using privilege separation
+ <pinotree> braunr: i a write(sock, &pid, sizeof int) (or the like)?
+ <pinotree> *ie
+ <braunr> not pid, file descriptors
+ <braunr> SCM_RIGHTS
+ <pinotree> ah ok
+ <braunr> the socket send/recv interface does support passing mach ports
+ <braunr> and the leaked ports do turn into dead names when i kill terminals
+ <pinotree> yes, we support with a patch pochu did few years ago
+ <braunr> so it seems the leak is related to libpipe this time
+ <braunr> ok got it :)
+ <braunr> pflocal used copy_send instead of move_send
+ <braunr> \o/
+ <braunr> that bug was such a pain
+ * braunr happy
+ <teythoon> :)
+ <pinotree> speaking of it, in pflocal' S_socket_recv is it correct the
+ "out_flags = 0;"?
+ <braunr> nice catch
+ <braunr> although i wonder why flags are returned
+ <braunr> it may have been set to null to tell us that we don't want to
+ return flags
+ <braunr> pfinet seems to use it
+ <pinotree> but you change a local variable anyway
+ <braunr> yes it's not useful
+ <braunr> hmm
+ <braunr> out_flags is what gets in struct msghdr -> msg_flags
+ <braunr> so i guess it makes sense to fix it to *out_flags = 0, just to be
+ safe
+ <braunr> pinotree: do you want me to push it tonight along with the others
+ ?
+ <pinotree> yes please
+ <braunr> ok
+ <pinotree> thanks!
+ <braunr> pflocal seems to not leak any memory or ports at all
+ <braunr> great :>
+ <braunr> there, patches pushed :)
+## `screen` Logout Hang
+[[!tag open_issue_hurd]]
+### IRC, freenode, #hurd, 2013-10-14
+ <braunr> i fixed term so that screen can shutdown properly
+ <braunr> read() wouldn't return EIO after terminal hangup
+### IRC, freenode, #hurd, 2013-10-17
+ <braunr> and the missing EOI prevented screen from correctly shutting down
+ windows
diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn
index 20aba837..8c332d84 100644
--- a/hurd/translator/tmpfs/discussion.mdwn
+++ b/hurd/translator/tmpfs/discussion.mdwn
@@ -430,3 +430,40 @@ License|/fdl]]."]]"""]]
<youpi> ok
<youpi> but that indeed means writeback of ext2fs works, which is a good
sign :)
+# IRC, freenode, #hurd, 2013-10-04
+ <teythoon> btw, I noticed that fifos do not work on tmpfs
+ <braunr> teythoon: tmpfs seems limited, yes
+ <teythoon> that's annoying b/c /run is a tmpfs on Debian and sysvinit
+ creates a crontrol fifo there
+ <teythoon> I wonder why I didn't notice that before
+ <braunr> also, fifos, like symlinks, can be shortcircuited in libdiskfs
+ <braunr> i wonder if that has anything to do with the problem at hand
+[[mtab/discussion]], *Multiple mtab Translators Spawned*.
+ <teythoon> b/c this breaks reboot & friends
+ <teythoon> I do too
+ <teythoon> b/c I cannot find any shortcut related code in tmpfs
+ <braunr> well, it's optional normally
+ <braunr> so that's ok
+ <braunr> but has it really been tested when the option wasn't there ? :)
+ <teythoon> yes, but the tmpfs requests this by setting diskfs_shortcut_fifo
+ = 1;
+ <pinotree> hm i remember tmpfs was said to be working with
+ sockets/fifos/etc, back then when it was fixed
+ <braunr> teythoon: oh
+## IRC, freenode, #hurd, 2013-10-11
+ <teythoon> this will have to wait for the next hurd pkg unfortunately, b/c
+ I broke tmpfs by accident :-/
+ <pinotree> how so?
+ <teythoon> the dropping of privileges broke passive translators and mkfifo
+ <braunr> there actually is a reason why those are run as root or with the
+ privilege of their owner
+ <braunr> privileges should be decoupled from identity
+ <teythoon> yes