This fixes Wstringop-overflow and Wstringop-truncation GCC warnings.
See https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059
Also, fix a bug where a string was not properly null-terminated.
---
lib.c | 4 ++--
stow.c | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib.c
This fixes multiple build errors.
---
lib.c| 1 +
lib.h| 1 +
lnode.c | 1 +
lnode.h | 1 +
node.c | 1 +
stow.c | 2 ++
ulfs.c | 1 +
update.c | 1 +
8 files changed, 9 insertions(+)
diff --git a/lib.c b/lib.c
index e7f3aa9..01cdbd0 100644
--- a/lib.c
+++ b/lib.c
@@ -23,6 +23,7 @
hing wrong.
[0]: https://www.gnu.org/software/hurd/hurd/translator/unionfs.html
Sergey Bugaev (3):
Implement MiG intran payload support
Add some missing includes
Don't use strncat() with length derived from source string
lib.c| 5 +++--
lib.h| 1 +
l
This fixes a build error.
---
stow-mutations.h | 1 +
stow-priv.h | 4
stow.c | 9 +
3 files changed, 14 insertions(+)
diff --git a/stow-mutations.h b/stow-mutations.h
index d36280d..95c1e7f 100644
--- a/stow-mutations.h
+++ b/stow-mutations.h
@@ -21,6 +21,7 @@
/* Onl
On Mon, Apr 26, 2021 at 9:02 PM Jessica Clarke wrote:
> > - strncpy (filepath, path, length);
> > - strncat (filepath, filename, strlen (filename));
> > + strcpy (filepath, path);
> > + strcat (filepath, filename);
>
> This is dubious. We should be using safe interfaces where possible.
To exp
On Mon, Apr 26, 2021 at 11:10 PM Samuel Thibault
wrote:
> Err, but wouldn't the compiler be able to determine that the size was
> properly computed, and avoid emitting a false-positive warning?
It is my understanding, based on
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=88059, that GCC does not
When reading from or writing to a node that has an attached pager,
use pager_memcpy () instead of accessing the cache directly. This
enables tarfs_read_node () and tarfs_write_node () too see and affect
the changes made to the file through the memory mapping.
---
tarfs.c | 89 +
---
Makefile | 2 +-
main.c | 12
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index e3936bfda..6e2eb422e 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ CFLAGS += -DDEBUG_ZIP # zip stores debugging
# Note: -lz has to be first otherwise
/libnetfs_io_map.html
[1]: https://paste.gg/p/anonymous/7de6f56e7a1c4babbab17bd6ccc2db46
Sergey Bugaev (6):
Plumb io_map () through the backend layer
Link to libpager and initialize it on startup
Implement basic read-only mmap support
Implement basic support for writable mappings
Attempt to
---
backend.h | 3 +++
netfs.c | 36 ++--
tarfs.c | 9 +
3 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/backend.h b/backend.h
index 82bbee77b..0b281f686 100644
--- a/backend.h
+++ b/backend.h
@@ -110,6 +110,9 @@ struct fs_backend
Each node can have a pager attached. The pager gets created
the first time io_map () is invoked on the node, and destroyed
once it has no clients. The pager gets its data the same way
tarfs_read_node () does: by ask the cache to copy out the data.
Note that this ommit only implement read-only mapp
No mmap coherence is implemented yet.
---
pager.c | 30 +++---
tarfs.c | 2 +-
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/pager.c b/pager.c
index ecd564020..8756a2a4b 100644
--- a/pager.c
+++ b/pager.c
@@ -11,6 +11,9 @@
#include "pager.h"
#include "c
---
BUGS | 1 -
TODO | 2 --
2 files changed, 3 deletions(-)
diff --git a/BUGS b/BUGS
index 1c946b366..4b88e85d1 100644
--- a/BUGS
+++ b/BUGS
@@ -4,7 +4,6 @@ Known tarfs bugs
1. General
-* io_map () not implemented (gcc uses it unfortunately).
* netfs.c (netfs_get_dirents): too much memory
On Sat, May 1, 2021 at 6:38 PM Samuel Thibault wrote:
> Actually I'd say the pager should replace the cache. The pager is
> already a cache by itself, we should not need to keep both the pager and
> the cache, particularly since it means having to keep both coherent.
Well, yes, I've considered th
On Sat, May 1, 2021 at 6:23 PM Samuel Thibault wrote:
> This is missing the copyright head:ng.
Ah yes, sorry. Should I just put myself there, or "Hurd developers",
or "Free Software Foundation, Inc."?..
> > + err = create_pager (node, &obj);
>
> Is the pager getting cleaned at some point?
On Sat, May 1, 2021 at 7:38 PM Samuel Thibault wrote:
> > on the other hand, the tar format, with its 512-byte
> > blocks, sounds very much like a filesystem image to me. isofs uses
> > diskfs, why doesn't tarfs?
>
> It's not exactly the same since you have compression in the way. But
> yes, that
On Sat, May 1, 2021 at 8:05 PM Samuel Thibault wrote:
> > And in case of tarfs, the compression is handled by the store
> > abstraction, which makes it transparent to the rest of the logic.
>
> Ah, ok.
> And in the zip case?
As I understand it, zip is a different model that basically combines
fun
On Sat, May 1, 2021 at 8:48 PM Samuel Thibault wrote:
> Since this is not part of the main hurd repo there is no copyright
> assignment requirement, so you can put your name. You can also assign
> copyright and then put the FSF name.
OK, I'll put my own name for now then.
I'm fine with assigning
_pager_pagemap_resize () returns an error or 0 on success,
not a boolean.
---
libpager/offer-page.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/libpager/offer-page.c b/libpager/offer-page.c
index 9f090bcb..ddea236a 100644
--- a/libpager/offer-p
pager_offer_page () is documented to may ignore the offered page if
the kernel already has a copy in core (indeed, that's what Mach does).
However the current behavior is the inverse of that: it asks the kernel
to flush (i.e. drop) its in-core copy, and replace it with the offered
one. Fix this by
previously returned void. This should
not break any callers though.
I have tested that the modified libpager builds without warnings, and
tmpfs seems to work as expected with libpager.so replaced.
Sergey Bugaev (6):
libpager: Fix mixing up success and error
libpager: Do not flush in-core page
Instead of ignoring errors, we might as well return them to the caller.
This technically changes the function signatures, but should not break
any users since they can continue to ignore the return value.
---
doc/hurd.texi | 16 ++--
libpager/data-unlock.c | 13 +-
libp
On a 64-bit system, there can be a lot more pages
than a 32-bit int can fit.
---
libpager/pagemap.c | 2 +-
libpager/priv.h| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libpager/pagemap.c b/libpager/pagemap.c
index 963f6567..63c5f44d 100644
--- a/libpager/pagemap.c
+++
The code tried to round up the allocation size to a multiple of page size.
But we actually allocate newsize * sizeof (*p->pagemap) bytes, not newsize
bytes, which meant allocations were sizeof (*p->pagemap) times larger than
they needed to be.
---
libpager/pagemap.c | 9 +
1 file changed,
libc already implements the functionality for allocating and managing
memory blocks like the pagemap. Using libc functions gives us some
additional niceties like overflow checking in reallocarray (). it also
means that we will not allocate a whole page of memory if we need to
store just a few integ
There's yet another bug: libpager just throws away clean precious
pages (those previously offered with pager_offer_page (precious = 1))
upon receiving them from the kernel, since it mistakes them for
evicted pages it's being notified about. This is obviously very
problematic.
I'm attaching a patch
On Thu, May 6, 2021 at 3:56 PM Sergey Bugaev wrote:
> - newaddr = mmap (0, newsize * sizeof (*p->pagemap),
> - PROT_READ|PROT_WRITE, MAP_ANON, 0, 0);
> + void *newaddr = reallocarray (p->pagemap, off,
> +sizeof (
Hello yet again,
I'm hitting the following issue when trying to re-set a translator on
a node whose translator has previously died:
$ settrans -acP /tmp/yes ~/dev-yes/hurd/yes
Translator pid: 1039
Pausing...
$ kill 1039
$ settrans -ag /tmp/yes ~/dev-yes/hurd/yes
settrans: /tmp/yes: (os/kern) inva
On Sat, May 8, 2021 at 2:39 PM Samuel Thibault wrote:
> I pushed the revert, thanks!
Thank you!
I'm attaching another patch that tries to make settrans handle this
case a tiny bit better: if we failed to set the translator (either
because of this issue, or for any other reason), let's shut the
t
On Sat, May 8, 2021 at 2:36 PM Samuel Thibault wrote:
>
> Hello,
>
> Just to be sure: this is not only because of your previous patch
> libpager: Do not flush in-core pages on offer
> ?
Yes; this issue is completely orthogonal to that fix (but there's an
interesting interaction I haven't thought
On Sat, May 8, 2021 at 2:40 PM Samuel Thibault wrote:
> Ah, seeing zipstores.c I thought zipfiles were supported, so I was
> wondering how since, as you say, they combine both.
By the way, upstream libstore itself supports gzip & bzip2; I have
only briefly looked into why tarfs needs to ship its
Clarify this in the documentation, and fix the storeio implementation.
---
doc/hurd.texi | 6 +++---
libpager/pager.h| 6 +++---
storeio/pager.c | 8 +++-
tmpfs/pager-stubs.c | 6 +++---
4 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/doc/hurd.texi b/doc/hurd.tex
The kernel invokes memory_object_data_return () with dirty = 0 in two
cases: if notification on eviction was requested, or when returning
precious pages. Properly distinguish between the two cases, and only
throw the clean page away in the former case.
---
libpager/data-return.c | 54 +
unmap call from
storeio.
Sergey Bugaev (4):
libpager: pager_write_page () should not unmap page
libpager: Store omit_data in an array
libpager: Track which pages are precious
libpager: Do not throw away precious pages
doc/hurd.texi | 6 ++--
libpager/data-return.c
While this is less efficient than using a single bit per page,
there is no guarantee that the kernel will not send us more than
32 pages at a time. Indeed, one can easily craft a situation where
it will send more by unmapping a large mapping.
Also, this function already uses on-stack arrays for tr
This introduces the PM_PRECIOUS bit, which gets set when a precious
page is offered to the kernel using pager_offer_page () with the
precious argument set, and cleared when the page is returned back.
---
libpager/data-return.c | 3 ++-
libpager/offer-page.c | 2 ++
libpager/priv.h| 1 +
3
I've noticed that even a simple hello world does a lot of gsync calls:
$ rpctrace echo hello world |& grep -c gsync
53
These are in fact all identical gsync_wake () calls on a single address:
$ rpctrace echo hello world |& grep gsync | uniq
task132(pid18549)->gsync_wake (202820 0 0);
This immed
On Sat, May 8, 2021 at 10:54 PM Samuel Thibault wrote:
> Don't bother looking at the existing implementation, its roots dates
> before we really had gsync working.
Interesting!
As far as I can see, this implementation was committed (by you) in
2018; and gsync has not seen significant changes sin
This moves the Hurd gsope implementation to be more like the Linux
one.
---
sysdeps/generic/ldsodefs.h | 2 --
sysdeps/htl/dl-thread_gscope_wait.c | 36 +
sysdeps/mach/hurd/i386/tls.h| 22 ++
sysdeps/mach/hurd/tls.h | 20 ---
This patch is probably bogus; but I'm including it anyway.
I've noticed that THREAD_GSCOPE_IN_TCB is actually being used not to
check whether the thread global scope state is being stored in TCB,
but rather as a general flag to distinguish between NPTL and HTL.
When THREAD_GSCOPE_IN_TCB is define
The next commit is going to introduce a new implementation of
THREAD_GSCOPE_WAIT, which needs to access the list of threads. Since
it must be usable from the dynamic laoder, we have to move the
symbols for the list of threads into the loader.
This is my attempt at doing so.
---
elf/dl-support.c
testrun.sh /bin/uname
GNU
~/glibc/build$ ./testrun.sh --tool=rpctrace /bin/uname |& grep gsync
~/glibc/build$
Sergey Bugaev (3):
XXX: Rename THREAD_GSCOPE_IN_TCB -> THREAD_GSCOPE_LINK_MAP
XXX: Move __pthread_threads to ld.so
XXX: Reimplement gscope
elf/dl-reloc.c
Hello,
I use rpctrace a lot, but I'm not particularly fond of its output
format. Other tracing tools, like strace [0] on Linux and Darling's
xtrace [1] can symbolicate many flags and structures, producing
something that looks much closer to C code, and comprehensible at a
glance.
[0]: https://str
On Wed, May 12, 2021 at 11:48 PM Samuel Thibault
wrote:
> > * Symbolicated flags and file paths (potentially, also proc and auth
> > handles)
>
> For file path it'll probably be much harder since there can be several
> path (or even no path!) for a given file port.
And as far as I can see, there
On Wed, May 12, 2021 at 11:48 PM Samuel Thibault
wrote:
> It'd probably mean introducing types
> here and there, but that'd be a really good thing to do.
>
> The port type is useful indeed and is most often available in the types
> already.
Oh, do you mean the types specified in .defs? If so, the
As luck would have it, I have found a serious issue in a core
component of the Hurd. It is a denial of service, which can then be
turned into privilege escalation.
I have developed an exploit. Here is it in action:
sergey@sergey-hurd-box:~/hax$ id
uid=1000(sergey) gid=1000(sergey)
groups=1000(ser
On Fri, May 14, 2021 at 4:30 PM Samuel Thibault wrote:
> We don't have anything set up for disclosures, you can drop me an e-mail
> (ciphered if you can).
OK, I'll prepare a write-up and send it to you. And I will attempt to
use GPG for it.
I asked about this on the Fediverse; and got (among oth
On Sat, May 15, 2021 at 4:56 PM Samuel Thibault wrote:
> > * rpctrace has to learn to parse defs, instead of (or in addition to) msgids
> > * GNU MIG needs to be taught to emit more info into msgids files
>
> Either of those. Probably the latter would be more interesting
> long-term. We could intr
On Sat, May 15, 2021 at 5:09 PM Samuel Thibault wrote:
> This can't go to the generic-purpose dl-support.c file.
> Create a sysdeps/mach/hurd/dl-thread_gscope_wait.c file, it's already
> getting included by elf/Makefile's routine variable.
I'm creating sysdeps/htl/dl-thread_gscope_wait.c in the n
On Fri, May 14, 2021 at 7:33 PM Sergey Bugaev wrote:
> Oh, and you would not believe this, but in the past couple of hours I
> have discovered *another* vulnerability, unrelated to the first one;
> it's even easier to exploit and also gives you root
And one more, unrelated to eithe
If no output width limit has been set explicitly, and we're not printing
to a tty, do not limit output width.
In particular, this fixes grepping ps output.
---
utils/ps.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/utils/ps.c b/utils/ps.c
index 2cf6e4bd..8e39c2c5 100644
--- a/utils/p
This fixes the procfs crash that happens on shutdown, previously discussed
here: https://lists.debian.org/debian-hurd/2021/04/msg00035.html
Sergey Bugaev (1):
procfs: Fix use-after-free
procfs/rootdir.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.31.1
Fix several issues with reference counting in
rootdir_make_translated_node ():
* Grab an additional reference while still holding the lock.
* Give the node an additional reference for being pointed to
by the ops.
* Reference the existing node if we find it on the second try,
not only if we f
Hello,
while hacking on rpctrace -p, I once again ran into gsync_wait () calls
permanently hanging rpctrace.
The reason for this is simple: once rpctrace logs the gsync_wait () call it
receives from a traced task, it forwards the same gsync_wait () call to the
actual task port of the traced ta
Instead, delay the reply message until the corresponding
gsync_wake () call is made.
TODO: Handle the case of reply port dying.
---
include/mach/gnumach.defs | 4 ++
kern/gsync.c | 112 +++---
kern/gsync.h | 8 ++-
3 files changed, 89
r directory
$ file /tmp/demo
/tmp/demo: broken symbolic link to no-such-file
$ ls -l /tmp/demo
lrwxrwxrwx 1 sergey sergey 12 Jun 21 16:11 /tmp/demo -> no-such-file
Sergey Bugaev (1):
trans/symlink.c: Rewrite on top of trivfs
trans/Makefile | 10 +-
---
trans/Makefile | 10 +-
trans/symlink.c | 243 +++-
2 files changed, 137 insertions(+), 116 deletions(-)
diff --git a/trans/Makefile b/trans/Makefile
index 6cf50e7a..c04220a2 100644
--- a/trans/Makefile
+++ b/trans/Makefile
@@ -25,7 +25,7 @@ targe
On Wed, Jul 28, 2021 at 10:39 PM wrote:
> Thanks for working on this!
I don't believe it: I finally got my own "OFF TOPIC PRAISE" letter!
Thank you for your kind words :)
> I'm wanting to learn more about trivfs for my caesar
> cipher eventually, but looking that how to write trivial translators
On Wed, Jul 28, 2021 at 11:25 PM Sergey Bugaev wrote:
> On Wed, Jul 28, 2021 at 10:39 PM wrote:
> > It would be cool to have a gemini translator. It would only take a few 100
> > lines of code.
>
> Oh yes, a Gemini translator actually sounds like a perfect exercise!
&g
On Tue, Aug 10, 2021 at 5:04 AM Samuel Thibault wrote:
> In the past months, Sergey Bugaev has been working on fixing some
> Hurd security vulnerabilities.
Well I certainly wasn't doing it alone :)
Samuel and me have been working together over the past few months to
design and impl
For what it's worth, a few years ago I was able to successfully run
Xfce, LXDE, GNUstep, parts of GNOME, and even Plan 9 from User Space.
Since then things have regressed. At one point Xorg was failing to
find any displays at all, lately it's been starting just fine and
displaying simple windows p
Hello!
On Tue, Aug 10, 2021 at 2:53 PM Richard Braun wrote:
> I have issues mounting /home (or rather, keeping it mounted) on
> darnassus.sceen.net since the reboot. Samuel already has root access
> so he can look at it when he has time.
That's... not good. I hope we'll figure it out.
By the wa
On Tue, Aug 10, 2021 at 4:42 PM Almudena Garcia
wrote:
>
> > Since then things have regressed. At one point Xorg was failing to
> > find any displays at all, lately it's been starting just fine and
> > displaying simple windows properly, but it's unable to take any input
> > from my mouse and keyb
On Tue, Aug 10, 2021 at 11:41 PM Samuel Thibault
wrote:
> Are you at the console while running this? Normally vcs is a symlink to
> /dev/vcs/1 or such.
Good point, that works from the console. Is it supposed to be
dependent on who's asking, like /dev/console in Unix? (If so, why
doesn't it like p
On Wed, Aug 11, 2021 at 12:04 AM Samuel Thibault
wrote:
> > What the hell? How'd that file get there? I certainly didn't write it.
>
> No idea, and
>
> https://codesearch.debian.net/search?q=auto-all.conf&hl=en
>
> doesn't know about it either.
Well in any case, removing that file made input work
On Fri, Aug 13, 2021, 01:25 Samuel Thibault wrote:
> So as usual, along the Debian release, we will have a Debian Hurd
> release. I have drafted the following list of news since the 2019
> release: <...>
> Is there some other big line that I am forgetting?
>
Perhaps "multiple security improvemen
On Fri, Aug 13, 2021, 10:05 Sergey Bugaev wrote:
> Perhaps "multiple security improvements" deserve a mention?
>
Oh, or is it not going to make it into the release because of the
unfinished copyright assignment? :(
Sergey
>
On Sat, Aug 14, 2021 at 8:43 AM Michael Banck wrote:
> The fact that this process potentially or apparently took (or rather,
> has been taking) months for Sergey (I don't know when it was initiated),
> is a pretty good indicator that it is more than a nuisance.
Well, this is partly my own fault:
On Mon, Aug 16, 2021 at 9:17 PM Samuel Thibault wrote:
> > > I'd rather see a
> > > hurd-specific libpciaccess function to get the pager.
> >
> > That's better, but we'd have to add that function in both hurd_pci.c and
> > x86_pci.c. I don't like the idea of adding Hurd specific code to x86_module
On Mon, Aug 16, 2021 at 10:28 PM Samuel Thibault
wrote:
> Sergey Bugaev, le lun. 16 août 2021 21:59:47 +0300, a ecrit:
> > IMO the proper way to get mremap () is vm_remap ()
>
> But that doesn't answer Joan's need for getting a memory object, to be
> able to put a prox
On Mon, Aug 16, 2021 at 11:43 PM Samuel Thibault
wrote:
> Here, possibly proxies can indeed work properly. But please do look at
> what Joan's situation is to make sure it does.
I don't think I understand enough about the situation. It would help
if you or Joan were to kindly give me some more co
On Tue, Aug 17, 2021 at 12:10 AM Samuel Thibault
wrote:
> Yes, and we want to implement nesting: providing a sub-hurd with a
> partial view of the PCI space.
Interesting. But I still don't think I understand what the problem you
are running into.
boot(1) already emulates Mach devices; it would i
On Tue, Aug 17, 2021 at 7:44 PM Almudena Garcia
wrote:
> But, in fstab, the drives are registered as /dev/hd0s1 (root partition in
> harddisk), and /dev/hd2 (cdron drive).
> I can try to change them to sdX naming, but is a bit risky
fstab only comes into play later in the boot process (certainly
On Tue, Aug 17, 2021 at 12:38 AM Samuel Thibault
wrote:
> The root pci-arbiter uses libpciaccess' x86 backend to access PCI
On Tue, Aug 17, 2021 at 9:47 PM Joan Lledó wrote:
> Yes, and the arbiter can play two roles: root arbiter, which uses x86
> module in libpciacces; and nested arbiter, which
On Tue, Aug 17, 2021 at 9:14 PM Joan Lledó wrote:
> > The underlying question is getting the memory object of a given memory
> > range, like vm_region does.
>
> Yes, I see that could be useful. Is vm_region not workig for proxies?
>
> > We need to be careful since we don't want any process to be
On Wed, Aug 18, 2021 at 8:34 PM Joan Lledó wrote:
> El 18/8/21 a les 0:13, Sergey Bugaev ha escrit:
> > you can no longer get the underlying memory object with vm_region ()
>
> How so? reading the docs I understood it does:
>
> https://www.gnu.org/software/hurd/gnumach-doc/M
On Wed, Aug 18, 2021 at 8:43 PM Joan Lledó wrote:
> El 18/8/21 a les 0:02, Sergey Bugaev ha escrit:
> > To me it sounds like libpciaccess should have a Hurd-specific API
> > addition that would let the user get the memory object
>
> That's a solution and can be done.
riable's name to better
reflect what it's used for. I haven't really been able to come up with a good
name, though.
Alternatively, it could just be left as is for now.
Sergey Bugaev (4):
htl: Move thread table to ld.so
htl: Reimplement GSCOPE
testrun.sh: Add support for --tool
x27;s a good or even acceptable approach.
Signed-off-by: Sergey Bugaev
---
elf/dl-reloc.c | 21 -
elf/dl-support.c | 14 --
elf/dl-tls.c | 39
sysdeps/htl/dl-support.c
while to get rid of
this flag, or at least rename it to better reflect what it's used for.
This patch does neither, though.
Signed-off-by: Sergey Bugaev
---
elf/dl-support.c| 1 -
sysdeps/generic/ldsodefs.h | 4 ---
sysdeps/htl/dl-thread_gscope_w
The next commit is going to introduce a new implementation of
THREAD_GSCOPE_WAIT which needs to access the list of threads.
Since it must be usable from the dynamic laoder, we have to move
the symbols for the list of threads into the loader.
Signed-off-by: Sergey Bugaev
---
htl/Versions
rpctrace(1) is a Hurd RPC tracer tool, which is used similar to how
strace(1) is used on GNU/Linux.
Signed-off-by: Sergey Bugaev
---
Makefile | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index f98d5a9e67..a49870d3d1 100644
--- a/Makefile
+++ b
Thanks for looking into it!
On Mon, Aug 30, 2021 at 6:37 PM Florian Weimer wrote:
> You could kick the can down the road by switching to PTHREAD_IN_LIBC.
> In some cases, that might actually be correct replacement.
Ack; that should be easy to do. Nevertheless, please do look at patch
4/4 and say
Hello!
Since this is bug-hurd and not just discuss-hurd, let me actually
report some bugs I just ran into.
Since recently, sudo has been broken:
$ sudo echo hi
Sorry, try again.
Sorry, try again.
sudo: 3 incorrect password attempts
It never even asks for the password, just errors out all by its
to verify the same on the Hurd due to the general flakiness of GDB there,
but I have ran the program with the patched glibc multiple times and it doesn't
crash, so I assume it's working fine.
Sergey Bugaev (5):
elf: Replace most uses of THREAD_GSCOPE_IN_TCB
htl: Move thread table to ld
rpctrace(1) is a Hurd RPC tracer tool, which is used similar to how
strace(1) is used on GNU/Linux.
Signed-off-by: Sergey Bugaev
---
Makefile | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index f98d5a9e67..a49870d3d1 100644
--- a/Makefile
+++ b
All the ports now have THREAD_GSCOPE_IN_TCB set to 1. Remove all
support for !THREAD_GSCOPE_IN_TCB, along with the definition itself.
Signed-off-by: Sergey Bugaev
---
elf/dl-support.c | 3 ---
sysdeps/aarch64/nptl/tls.h| 1 -
sysdeps/alpha/nptl/tls.h | 1 -
sysdeps/arc
aking THREAD_GSCOPE_WAIT () slower.
The largest win is the elimination of many redundant gsync_wake () RPC
calls; previously, even simplest programs would make dozens of fully
redundant gsync_wake () calls.
Signed-off-by: Sergey Bugaev
---
sysdeps/htl/dl-thread_gscope_wait.c
The next commit is going to introduce a new implementation of
THREAD_GSCOPE_WAIT which needs to access the list of threads.
Since it must be usable from the dynamic laoder, we have to move
the symbols for the list of threads into the loader.
Signed-off-by: Sergey Bugaev
---
htl/Versions
do with whether libc has access to the
list of thread structures and therefore can initialize thread-local
storage.
The parts of code that actually depend on whether the GSCOPE flag is in
TCB are left unchanged.
Signed-off-by: Sergey Bugaev
---
elf/dl-reloc.c | 4 ++--
elf/dl
Hello,
On Sat, Sep 11, 2021 at 12:27 PM Joan Lledó wrote:
> Note the additional parameter *mach_msg_type_name_t objectPoly* in
> memory_object_create_proxy. I don't know why is it there but I can't
> compile the pci arbiter anymore because of that. What can I do?
This is a little change that Sam
On Wed, Sep 15, 2021 at 2:27 AM Samuel Thibault wrote:
> Please rather use __libc_rwlock_wrlock etc.
Thanks, I did not realize there were actually more internal
synchronization primitives implemented on top of lll. I will send out
a new version shortly.
> Even if for now they are actually locks
On Wed, Sep 15, 2021 at 5:34 PM Samuel Thibault wrote:
> so it's probably not
> worth spending time on making a separate __libc_rwlock implementation,
> and rather spend it on making pthread_rwlock use gsync, like was done
> for pthread_mutex and sem
Oh, it currently doesn't? That's horrifying. T
:
$ rpctrace -o >(grep -c wake) /bin/uname
GNU
58
After:
$ ./testrun.sh --tool=rpctrace /bin/uname 2> >(grep -c wake)
GNU
0
Sergey Bugaev (3):
htl: Move thread table to ld.so
htl: Reimplement GSCOPE
elf: Remove THREAD_GSCOPE_IN_TCB
elf/dl-support.c | 3 --
htl
The next commit is going to introduce a new implementation of
THREAD_GSCOPE_WAIT which needs to access the list of threads.
Since it must be usable from the dynamic laoder, we have to move
the symbols for the list of threads into the loader.
Signed-off-by: Sergey Bugaev
---
htl/Versions
aking THREAD_GSCOPE_WAIT () slower.
The largest win is the elimination of many redundant gsync_wake () RPC
calls; previously, even simplest programs would make dozens of fully
redundant gsync_wake () calls.
Signed-off-by: Sergey Bugaev
---
sysdeps/htl/dl-thread_gscope_wait.c
All the ports now have THREAD_GSCOPE_IN_TCB set to 1. Remove all
support for !THREAD_GSCOPE_IN_TCB, along with the definition itself.
Signed-off-by: Sergey Bugaev
---
elf/dl-support.c | 3 ---
sysdeps/aarch64/nptl/tls.h| 1 -
sysdeps/alpha/nptl/tls.h | 1 -
sysdeps/arc
On Wed, Sep 15, 2021 at 8:22 PM Samuel Thibault wrote:
> Did you run make check to verify that you didn't break the world? :)
>
> (i.e. no more failures than before the patch)
Not yet; it takes a long time here, I'll leave it running overnight
and report tomorrow.
By the way, for a project as im
Hello everyone.
I'm likely getting conscripted for military service some time soon.
When exactly, I don't yet know, but it could happen any day now.
What does it have to do with the Hurd? Well, it most likely means I
will be offline (and so, unable to contribute or to read and respond
to any mess
On Tue, Oct 12, 2021 at 3:37 PM Joan Lledó wrote:
> Hi,
>
> I'm working on the gnumach rpc to return a pager from a task and an
> address mapped in that task.
Cool! What's the RPC signature?
> For security reasons I'd like to check if the calling task is the same
> as the one the given map belon
1 - 100 of 850 matches
Mail list logo
