diff options
Diffstat (limited to 'hurd')
| -rw-r--r-- | hurd/authentication.mdwn | 20 | ||||
| -rw-r--r-- | hurd/translator/mtab/discussion.mdwn | 135 | ||||
| -rw-r--r-- | hurd/translator/proc.mdwn | 24 | ||||
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 37 | ||||
| -rw-r--r-- | hurd/translator/term.mdwn | 7 |
5 files changed, 86 insertions, 137 deletions
diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index 36d18fbb..09dfb821 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -36,6 +36,26 @@ For more details, see section 2.3 of the [[critique]]. [[!tag open_issue_hurd]] +## 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 + + ## IRC, freenode, #hurd, 2013-09-28 <braunr> mhmm diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn index ef5e8cbd..bac32906 100644 --- a/hurd/translator/mtab/discussion.mdwn +++ b/hurd/translator/mtab/discussion.mdwn @@ -2111,6 +2111,10 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. ## Memory Leak +Fixed in 2013-09-28 Hurd commit a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb +(libdiskfs), and 2013-10-04 Hurd commit +98b6f846b628e858acbae9258bac78cf54126d27 (libnetfs). + ### IRC, freenode, #hurd, 2013-09-18 <braunr> ext2fs is using a ginormous amount of memory on darnassus since i @@ -2227,23 +2231,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <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 @@ -2253,65 +2240,10 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <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: http://darnassus.sceen.net/~rbraun/test_ftruncate.c - <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> @@ -2331,22 +2263,18 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. had my development vm running on that patches for two weeks -### IRC, freenode, #hurd, 2013-10-03 +### IRC, freenode, #hurd, 2013-10-02 - <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 + <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a + translator + <braunr> i'll fix it too ## Multiple mtab Translators Spawned +Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a? + + ### IRC, freenode, #hurd, 2013-09-20 <braunr> teythoon: how come i see three mtab translators running ? @@ -2365,25 +2293,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. [[open_issues/libnetfs_passive_translators]]. -### 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]] @@ -2449,12 +2358,18 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <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> i have a fix for the multiple mtab issue, will send a patch + tonight + + +## `/home` Missing + +### IRC, freenode, #hurd, 2013-10-04 + <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 @@ -2491,9 +2406,6 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. 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 @@ -2501,11 +2413,8 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <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 + <braunr> oh please don't name global variables "path" ... ### IRC, freenode, #hurd, 2013-10-06 @@ -2881,7 +2790,7 @@ In context of [[open_issues/mig_portable_rpc_declarations]]. <teythoon> braunr: i'm afraid it might be your patch 3a3fcc81 that breaks proc -[[libpthread_set_stack_size]]. +[[open_issues/libpthread_set_stack_size]]. <braunr> teythoon: but anyway, it does look like your patches are actually fine diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn index 39840e99..924abc99 100644 --- a/hurd/translator/proc.mdwn +++ b/hurd/translator/proc.mdwn @@ -67,30 +67,6 @@ It is stated by `/hurd/init`. ## 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 diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 8ac48a59..54de54c2 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -599,3 +599,40 @@ Needed by glibc's `pldd` tool (commit enough <braunr> it probably is <braunr> settrans -Rg doesn't work on procfs :( + + +# Kernel PID + +## IRC, freenode, #hurd, 2013-09-25 + + <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-04 + + <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-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 diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn index 5ae52abe..834ef9bd 100644 --- a/hurd/translator/term.mdwn +++ b/hurd/translator/term.mdwn @@ -24,6 +24,10 @@ The *term* translator implements POSIX termios discipline. <braunr> good news <braunr> the terminal leak is related to privilege separation + +[[tschwinge]] confirming (using `ssh -t [machine] tty`) that with privilege +separation enabled there is this problem, and once disabled it goes away. + <atheia> I love how, as an unknowing by-stander, that is somehow good news :-) <braunr> :) @@ -38,6 +42,9 @@ The *term* translator implements POSIX termios discipline. <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 + +[[news/2010-09]]. + <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 |